logarithm with base 0 should raise an error

[DaveWitteMorris]

Steps To Reproduce

No response

Expected Behavior

Logarithms with a base of 0 do not exist, so trying to calculate one should raise a ValueError.

Actual Behavior

Sagemath seems to think that logarithms with a base of 0 are equal to 0:

sage: log(2, 0)
0
sage: log(2.0, 0)
-0.000000000000000
sage: log(x, 0)
0

Additional Information

No response

Environment

• OS: MacOS 14.6.1
• Sage Version: 10.5.b9

Checklist

• I have searched the existing issues for a bug report that matches the one I want to file, without success.
• I have read the documentation and troubleshoot guide

[user202729]

Probably because log(2, 0) = log(2)/log(0) = log(2)/(-Infinity) = 0.

We do have $\lim_(x → 0) \log(2)/\log(x) = 0$ anyway, so the behavior is not entirely unreasonable. Besides, the change breaks backwards compatibility.

On the other hand the behavior is not entirely consistent either:

sage: 8.log(0)
---------------------------------------------------------------------------
ValueError                                Traceback (most recent call last)
...
ValueError: log base must be positive
sage: (8.0).log(0.0)
-0.000000000000000

But:

sage: (8).log(-2)
---------------------------------------------------------------------------
ValueError                                Traceback (most recent call last)
...
ValueError: log base must be positive
sage: (8.0).log(-2.0)
0.139260970636224 - 0.631180872623791*I

And:

sage: log(8, oo)
0

Meanwhile the documentation of log says

Signature:      log(*args, **kwds)
Docstring:     
   Return the logarithm of the first argument to the base of the
   second argument which if missing defaults to "e".

   It calls the "log" method of the first argument when computing the
   logarithm, thus allowing the use of logarithm on any object
   containing a "log" method. In other words, "log" works on more than
   just real numbers.

[DaveWitteMorris]

Because of the limit interpretation, the value of 0 probably makes sense to a physicist (or engineer), but I think it is clearly incorrect from a mathematical point of view, because the definition of log is: b^log(a,b) = a and this is clearly not true when b = 0. (If someone wants a limit, they can take a limit.) So I think the current behaviour counts as a bug and needs to be changed (even if it breaks some code).

If anyone thinks this may be controversial, we should ask for opinions on sage-devel.

[DaveWitteMorris]

Actually, since the change could break code (and the bug has been around for a long time, so fixing it is not urgent), I think the first step would be to deprecate the use of 0 as a base. (I expect 10.5 to be released soon, so I think this will have to wait for 10.6.) A year later, we can make it raise an error. Probably the deprecation should be mentioned on sage-devel, to see if there are any objections.

[user202729]

There's also the issue that testing if a symbolic expression is zero is a very nontrivial problem, but I'm not sure this is a serious roadblock here.

[DaveWitteMorris]

I don't think testing for zero will cause a problem here. The issue is about what sagemath should do when it has determined that the base is zero, so there shouldn't be any additional checks for 0.

A related issue (perhaps a separate issue): Returning the natural logarithm is even worse than returning zero, but that's what sagemath does when 0 is specified as the base via keyword:

sage: log(6, base=0)
log(6)

The problem is in line 1141 of src/sage/misc/functional.py:

    base = kwds.pop('base', None)
    if base:
        args = args + (base,)

It should be "if base is not None", instead of "if base".

[Noel-Roemmele]

Pull Request for the sub-issue mentioned by Dave Morris has been created.

[devansh-srv]

@user202729 @DaveWitteMorris Now that Sage is on 10.6 shall the log function raise an error when it gets zero?
Also we should remove the inconsistencies in the function

[devansh-srv]

This is the definition of log function in src/sage/rings/integer.pyx
functions signature
def log(self, m=None, prec=None):
it clearly says that if a m<=0 then it raises a ValueError
but I think rather than a ValueError
it should provide an answer to it with some value of prec using mpfr as it is doing below

        cdef int self_sgn
        if m is not None and m <= 0:
            raise ValueError("log base must be positive")
        self_sgn = mpz_sgn(self.value)
        if self_sgn < 0 and prec is None:
            from sage.symbolic.ring import SR
            return SR(self).log(m)
        if prec:
            if self_sgn >= 0:
                from sage.rings.real_mpfr import RealField
                return RealField(prec)(self).log(m)
            else:
                from sage.rings.complex_mpfr import ComplexField
                return ComplexField(prec)(self).log(m)

        if m is None:
            from sage.functions.log import function_log
            return function_log(self,dont_call_method_on_arg=True)
        try:
            m = Integer(m)
        except (ValueError, TypeError):
            pass

        if isinstance(m, Integer):
            elog = self.exact_log(m)
            if elog == -sage.rings.infinity.infinity or m**elog == self:
                return elog

        if isinstance(m, Rational) and m.numer() == 1:
            elog = -self.exact_log(m.denom())
            if m**elog == self:
                return elog

        from sage.functions.log import function_log
        return function_log(self, dont_call_method_on_arg=True)/\
            function_log(m, dont_call_method_on_arg=True)

[devansh-srv]

@user202729
I just realised that removing the check for m<=0 gives

sage: 8.log(0)
0
sage: (8.0).log(0.0)
-0.000000000000000
sage: 8.log(-2)
3*log(2)/(I*pi + log(2))
sage: (8.0).log(-2.0)
0.139260970636224 - 0.631180872623791*I

which is pretty much correct and makes log consistent
should I open a PR and patch this up?