One nuisance in mathematics is the "ln(x)" notation for natural
logarithms by students up to a certain age, followed by the "log(x)"
notation used for exactly the same thing after a certain age. So
I've always taken great pride that in Sage (and most other math
software), "log" is the right grown up thing. So imagine how annoyed
I was just now to find in Sage-4.1.1 that:
sage: latex(log(x))
\ln\left(x\right)
What the heck is up with that typesetting as "ln"?
Besides being annoying, this is inconsistent because log(x) prints as
"log(x)" in sage.
sage: log(x)
log(x)
Does anybody mind if this gets changed back? I'm guessing it was
introduced by accident because
of Pynac somehow during the symbolic switchover, but maybe there is
something more to it that I missed?
-- William
--
William Stein
Associate Professor of Mathematics
University of Washington
http://wstein.org
> I think that's maybe a reminiscence from the age of pocket calculators
> or even slide rules.
>
ln(x) is what's used in engineering. I dislike the use of log(x) for
ln(x)
but I'm guessing I don't have much of a choice. All use of log I learned
had a subscript to indicate the base.
Cheers,
Tim.
---
Tim Lahey
PhD Candidate, Systems Design Engineering
University of Waterloo
http://www.linkedin.com/in/timlahey
>
> So since Tim's from Waterloo that might explain his preference for ln.
I preferred ln(x) well before I learned Maple. Plus, all my textbooks
used
ln(x). As for Matlab, it might be engineering oriented, but engineers
didn't
invent it. I've rarely needed ln in Matlab, but I've used it many
times in Maple.
I'm glad that ln will work in Sage. What does the ln = log mean for the
LaTeX code? I hope that it will output ln(x) instead of log(x).
Thanks,
I preferred ln(x) well before I learned Maple. Plus, all my textbooks
On Aug 23, 2009, at 5:25 PM, William Stein wrote:
>
> So since Tim's from Waterloo that might explain his preference for ln.
used
ln(x).
As for Matlab, it might be engineering oriented, but engineers
didn't
invent it. I've rarely needed ln in Matlab, but I've used it many
times in Maple.
I'm glad that ln will work in Sage. What does the ln = log mean for the
LaTeX code? I hope that it will output ln(x) instead of log(x).
OK, Wikipedia has a pretty useful discussion. It mentions 'As
recently as 1984, Paul Halmos in his "automathography" I Want to Be a
Mathematician heaped contempt on what he considered the childish "ln"
notation, which he said no mathematician had ever used.' I read that
book, so maybe that is one reason I don't like "ln". The Wikipedia
page also says:
"If, as in "log(x)", the base is not given explicitly, it may be
understood implicitly by discipline:
* Mathematicians understand "log(x)" to mean log_e(x). Calculus
textbooks will occasionally write "log(x)" to represent "log_10(x)".
* Many engineers, biologists, astronomers, and some others write
only "ln(x)" or "log_e(x)" when they mean the natural logarithm of x,
and take "log(x)" to mean log_10(x) or, in computer science, log2(x).
* In most commonly used computer programming languages, including C,
C++, Java, Haskell, Fortran, Python, Ruby, and BASIC, the "log"
function returns the natural logarithm. The base-10 function, if it is
available, is generally "log10."
This chaos, historically, originates from the fact that the natural
logarithm has nice mathematical properties (such as its derivative
being 1/x, and having a simple definition), while the base 10
logarithms, or decimal logarithms, were more convenient for speeding
calculations (back when they were used for that purpose)."
---
>
> Unfortunately it doesn't mean that. I think it just means that "ln"
> is a shortcut for "log", but otherwise works just like "log".
Is it possible in this change to have function for ln that will
print to LaTeX and just call log behind the scenes?
Cheers,
Tim.
> * Many engineers, biologists, astronomers, and some others write
> only "ln(x)" or "log_e(x)" when they mean the natural logarithm of x,
> and take "log(x)" to mean log_10(x) or, in computer science, log2(x).
That has been pretty much my experience here in the UK - just in case
its usage is different in different countries.
Electrical engineers used 'j' for sqrt(-1) too. We use the letter 'i' to
mean current.
FWIW, Mathematica uses:
In[1]:= ?Log
Log[z] gives the natural logarithm of z
(logarithm to base e). Log[b, z] gives the logarithm to base b.
But also has Log2 and Log10. (I must admit, until a minute ago, I never
knew about the latter two. It was only when searching I found these:
In[2]:= ?Log*
Log LogicalExpand LogLogPlot
Log10 LogIntegral LogNormalDistribution
Log2 LogisticDistribution LogPlot
LogBarnesG LogitModelFit LogSeriesDistribution
LogGamma LogLinearPlot
In[3]:= ?Log2
Log2[x] gives the base-2 logarithm of x.
In[4]:=
In[4]:= ?Log10
Log10[x] gives the base-10 logarithm of x.
Hm, since we wanted to get away from implicit functions, the consistent
think to do would be to always require the base when a user wants to use
the log function. I think that this could avoid some confusion.
In every
CAS, I have to check in the documentation what the program means by
log(x). In sage I had to read through the whole doc string and get to
the examples before I was able to deduce that log(x) is the natural log
of x:
Type: function
Base Class: <type 'function'>
String Form: <function log at 0xf5f4df0>
Namespace: Interactive
Definition: log(x, base=None)
Docstring:
Return the logarithm of x to the given base.
Calls the ``log`` method of the object x when computing
the logarithm, thus allowing use of logarithm on any object
containing a ``log`` method. In other words, log works
on more than just real numbers.
TODO: Add p-adic log example.
EXAMPLES::
sage: log(e^2)
2
sage: log(1024, 2); RDF(log(1024, 2))
10
I think that the doc string should say that log(x) = log(x,e) right at
the beginning.
I just checked all my books lying on my table *at the moment* (which
means I either use them right now, or used them in the past couple
months the most frequently):
* Quantum theory of many-particle systems by Fetter, Alexander L.
* Chemical Kinetics And Dynamics by J. Steinfeld
* Applied Mathematics by Logan
* Calculus by Steward
and all use "ln(x)". That was a surprise to me too, since except the
last one, all are graduate texts, e.g. definitely "after the certain
age". I use log(x) in my own notes though. I prefer to just use one
notation for all physics. One thing is that I am not sure how to write
integrals, e.g. most quantum mechanics/field theory texts use int
<something> d^4 x, to denote integration in 4D. But let's say for
finite element formulation of something, I want to specify a surface
integral, so I sometimes use dS instead of d^2x or something. It's
inconsistent though.
Ondrej
Of course. That sounds reasonable. I can see students being confused
that they typed "ln" and it said back "log".
So +1.
Jason
Yes, +1 to this. We can have our cake and eat it too!
William
Would it get printed and typeset as "ln" or "log" if you create such a macro?
William
Python does not have "macros" (whatever those are). However the
equality "ln = log" is already set in Sage, so we have already that:
sage: ln(x)
log(x)
> You could create the macro in the other form as
> log(x) ==> 'ln(x)
> in which case log(n) will print as ln(n)
>
> It is also possible to add the ln function directly to the
> algebra so that it works in all cases. Nobody has bothered
> in 38 years so i assume that users adapt.
:-)
> Frankly, I'm sort of neutral about it but I was of the opinion
> that engineers tended toward ln while mathematicians tended
> toward log. The lastest example from the gamma book was a
> surprise and a clear counterexample.
Yep.
I think the vote from this dicussion for Sage was to make it so ln and
log are both supported and "log" is base e by default. So in the
future we'll have:
sage: ln(x)
ln(x)
sage: log(x)
log(x)
That should make most people happy.
Unrelated question: What's up with Axiom development these days? Is
there any sort of relatively recent status report? I'm just
generally curious.
-- William
>
>
> On Sep 6, 1:24 pm, William Stein <wst...@gmail.com> wrote:
--
On Sun, Sep 6, 2009 at 6:35 PM, William Stein<wst...@gmail.com> wrote:
> sage: ln(x)
> ln(x)
> sage: log(x)
> log(x)
>
> That should make most people happy.
Just a comment: having two different symbolic log functions in pynac will
imply (by default)
---------
sage: log(x) - ln(x)
log(x) - ln(x)
---------
I mean symbolically they are not equal to each other given they will
have different serial no.
Cheers,
Golam
> I think the vote from this dicussion for Sage was to make it so ln and
> log are both supported and "log" is base e by default. So in the
> future we'll have:
>
> sage: ln(x)
> ln(x)
> sage: log(x)
> log(x)
>
> That should make most people happy.
How do you think this should be implemented?
- define two independent symbolic functions that share the same code
for evaluation
- have a hidden parameter to indicate the printing preference in the
SFunction subclass that implements log
The first option means we have to normalize to one of these before any
nontrivial processing, e.g., simplification, integral transforms,
integration, etc.
Second one makes the trivial equality checking for log(x) == ln(x)
difficult.
In this new system, what will
sage: integrate(1/x, x)
return?
Cheers,
Burcin
Oh crap, I have no clue!
> - define two independent symbolic functions that share the same code
> for evaluation
>
> - have a hidden parameter to indicate the printing preference in the
> SFunction subclass that implements log
>
> The first option means we have to normalize to one of these before any
> nontrivial processing, e.g., simplification, integral transforms,
> integration, etc.
>
> Second one makes the trivial equality checking for log(x) == ln(x)
> difficult.
Of these two options, the second sounds better. Right now we have
sage: type(log)
<type 'function'>
Really it should be
sage: type(log)
<class 'sage.functions.log.Function_log'>
which you can get by doing:
sage: log = log(x).operator()
Anyway, log is just some Python class with a name() method:
sage: log.name()
'log'
If we also instantiate the class but with name returning 'ln', that might work.
>
> In this new system, what will
>
> sage: integrate(1/x, x)
>
> return?
I would have it return log(x). We do have to make some choices.
William
> If we also instantiate the class but with name returning 'ln', that
> might work.
>
>>
>> In this new system, what will
>>
>> sage: integrate(1/x, x)
>>
>> return?
>
> I would have it return log(x). We do have to make some choices.
>
How about a run-time option to control that? Alternatively, we could
require the base explicitly. So, log(x) = log(e,x) or log(x,e) as
people prefer. If we're not going to have ln(x) work as people would
expect, I'd prefer the explicit base so the base is clear when viewing
the log.
Cheers,
For my own use I dislike log because I don't understand if it's ln or log10.
I prefer use ln(x) = log (x,e) and perhaps log10 (x)=log(x,10).
I agree.
> Right now we have
>
> sage: type(log)
> <type 'function'>
>
> Really it should be
>
> sage: type(log)
> <class 'sage.functions.log.Function_log'>
>
> which you can get by doing:
>
> sage: log = log(x).operator()
>
> Anyway, log is just some Python class with a name() method:
> sage: log.name()
> 'log'
>
> If we also instantiate the class but with name returning 'ln', that
> might work.
Whenever it made a round trip to maxima, etc. it would get
"normalized" back to log. Also, would
sage: log(x) + ln(x)
2*log(x)
Just declaring ln = log, and not having ln in the output (unless
perhaps some special typesetting option was on) seems like the
simplest case to me. Having ln preserved sometimes, but not all the
time, is just asking for a complicated system and user confusion.
- Robert
That's definitely the easiest to implement, since that's what we
already have! :-)
Well, except for this bug:
sage: log(x)
log(x)
sage: latex(log(x))
\ln\left(x\right)
which of course started this whole thread.
William
>
> >> If we also instantiate the class but with name returning 'ln', that
> >> might work.
> >
> > Whenever it made a round trip to maxima, etc. it would get
> > "normalized" back to log. Also, would
> >
> > sage: log(x) + ln(x)
> > 2*log(x)
> >
> > Just declaring ln = log, and not having ln in the output (unless
> > perhaps some special typesetting option was on) seems like the
> > simplest case to me. Having ln preserved sometimes, but not all the
> > time, is just asking for a complicated system and user confusion.
I agree.
> That's definitely the easiest to implement, since that's what we
> already have! :-)
> Well, except for this bug:
>
> sage: log(x)
> log(x)
> sage: latex(log(x))
> \ln\left(x\right)
>
> which of course started this whole thread.
This is easy to fix. It will be in the next pynac release, which should
be in the next Sage release. :)
This is now:
http://trac.sagemath.org/sage_trac/ticket/6902
Do we have a planned release date so I know when to wrap up my changes
in pynac and submit them for review? Minh?
Cheers,
Burcin
On Tue, Sep 8, 2009 at 5:06 AM, Burcin Erocal<bur...@erocal.org> wrote:
<SNIP>
> Do we have a planned release date so I know when to wrap up my changes
> in pynac and submit them for review? Minh?
How about 15th September 2009 for a feature freeze date? Does that
sound reasonable to you?
--
Regards
Minh Van Nguyen
That sounds good to me, though it is during the next Sage Days.
William
+1 from me.
William
>
> On Tue, Sep 8, 2009 at 5:15 AM, William Stein<wst...@gmail.com> wrote:
>
> <SNIP>
>
> > That sounds good to me, though it is during the next Sage Days.
>
> I almost forgot about the 17th Sage Days. Let's make it 22nd September
> 2009 as the final date to get features in for the upcoming Sage 4.1.2.
> So after 22nd September, feature freeze begins. That should give
> people some time to get things in. How does that sound?
That gives me plenty of time, fine by me.
I expected something more along the lines of
"we're trying to cut a release before SD 17, so feature freeze in 3
days!"
which would mean that I'd have to stay up all night trying to put the
pieces of my Sage branch back again. Now, it prints several lines of
error messages even before the first prompt, then returns `dickman_rho`
as the result of almost anything that goes to maxima. E.g.,
sage: real(1) # don't ask why that goes to maxima
dickman_rho(1)
sage: integrate(1/x, x)
<error message about exception being ignored in cython>
dickman_rho(x)
I can share the patches if anybody is interested. :)
Cheers,
Burcin