log(x) versus ln(x)

347 views
Skip to first unread message

William Stein

unread,
Aug 23, 2009, 4:47:10 PM8/23/09
to sage-devel, Mike Hansen, Burcin Erocal, sage...@googlegroups.com
Hi,

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

Harald Schilly

unread,
Aug 23, 2009, 5:14:17 PM8/23/09
to sage-devel
+1 for change back.

I think that's maybe a reminiscence from the age of pocket calculators
or even slide rules.

h

Tim Lahey

unread,
Aug 23, 2009, 5:18:45 PM8/23/09
to sage-...@googlegroups.com
On Aug 23, 2009, at 5:14 PM, Harald Schilly wrote:

> 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

William Stein

unread,
Aug 23, 2009, 5:25:15 PM8/23/09
to sage-...@googlegroups.com
On Sun, Aug 23, 2009 at 2:18 PM, Tim Lahey<tim....@gmail.com> wrote:
>
> On Aug 23, 2009, at 5:14 PM, Harald Schilly wrote:
>
>> 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.

At least we do have ln = log somewhere, so you can always type "ln".

For the record, the engineering-oriented MATLAB does not have ln in any way:

>> ln(5)
??? Undefined command/function 'ln'.

>> log(5)
ans =
1.6094

Mathematica does not have Ln in any way:

In[2]:= N[Ln[2]]
Out[2]= Ln[2.]
In[3]:= N[Log[2]]
Out[3]= 0.693147

Maple *does* have ln and even turns "log(x)" into "ln(x)".

> evalf(log(2));
0.6931471806
> evalf(ln(2));
0.6931471806
> log(x);
ln(x)
> ln(x);
ln(x)


So since Tim's from Waterloo that might explain his preference for ln.

> Cheers,
>
> Tim.
> ---
> Tim Lahey
> PhD Candidate, Systems Design Engineering
> University of Waterloo
> http://www.linkedin.com/in/timlahey
>
>
> >
>



Tim Lahey

unread,
Aug 23, 2009, 5:35:46 PM8/23/09
to sage-...@googlegroups.com

On Aug 23, 2009, at 5:25 PM, William Stein wrote:

>
> 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,

William Stein

unread,
Aug 23, 2009, 5:54:32 PM8/23/09
to sage-devel
On Sun, Aug 23, 2009 at 2:35 PM, Tim Lahey <tim....@gmail.com> wrote:


On Aug 23, 2009, at 5:25 PM, William Stein wrote:

>
> 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).

Good point.  In fact, in retrospect my experience matches yours, since all my textbooks used ln until I was in my junior year as an undergrad engineering major. Then I switched majors from math to engineering, and started taking upper level math classes, and suddenly every textbook used "log" for "log-to-the-base-e".
 
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).

Unfortunately it doesn't mean that.  I think it just means that "ln" is a shortcut for "log", but otherwise works just like "log". 
 
 -- William

William Stein

unread,
Aug 23, 2009, 6:00:32 PM8/23/09
to sage-devel
On Sun, Aug 23, 2009 at 2:54 PM, William Stein<wst...@gmail.com> wrote:
>
>
> On Sun, Aug 23, 2009 at 2:35 PM, Tim Lahey <tim....@gmail.com> wrote:
>>
>>
>> On Aug 23, 2009, at 5:25 PM, William Stein wrote:
>>
>> >
>> > 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).

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)."


---

Tim Lahey

unread,
Aug 23, 2009, 6:25:54 PM8/23/09
to sage-...@googlegroups.com

On Aug 23, 2009, at 5:54 PM, William Stein wrote:

>
> 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.

Dr. David Kirkby

unread,
Aug 24, 2009, 3:25:26 AM8/24/09
to sage-...@googlegroups.com
William Stein wrote:

> * 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.

Stan Schymanski

unread,
Aug 24, 2009, 10:46:40 AM8/24/09
to sage-...@googlegroups.com
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.

Stan

William Stein

unread,
Aug 24, 2009, 10:59:18 AM8/24/09
to sage-...@googlegroups.com
On Mon, Aug 24, 2009 at 7:46 AM, Stan Schymanski <schy...@gmail.com> wrote:

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.

I think that would be too cumbersome.
 
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:

As you point out below, that can be fixed by making a clear statement about this part of the first sentence.
 


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 very strongly agree.    Any chance you could be convinced to submit a patch to do this?

William

Ondrej Certik

unread,
Aug 24, 2009, 9:33:40 PM8/24/09
to sage-...@googlegroups.com
On Sun, Aug 23, 2009 at 1:47 PM, William Stein<wst...@gmail.com> wrote:
>
> Hi,
>
> 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 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

Jason Grout

unread,
Aug 24, 2009, 9:52:49 PM8/24/09
to sage-...@googlegroups.com

Of course. That sounds reasonable. I can see students being confused
that they typed "ln" and it said back "log".

So +1.

Jason

William Stein

unread,
Aug 24, 2009, 9:56:24 PM8/24/09
to sage-...@googlegroups.com

Yes, +1 to this. We can have our cake and eat it too!

William

TimDaly

unread,
Aug 24, 2009, 11:09:40 PM8/24/09
to sage-devel
In the lectures on solid state chemistry, lecture 22 the plot is shown
as the ln(x), "the natural log"... in the open courseware from MIT:
http://www.youtube.com/watch?v=TVuG75QH0kA&feature=SeriesPlayList&p=3B87AF6948F5E8F9&index=22

On Aug 24, 9:56 pm, William Stein <wst...@gmail.com> wrote:

Stan Schymanski

unread,
Aug 25, 2009, 7:54:46 AM8/25/09
to sage-...@googlegroups.com
Hi William,

Sorry, not this time as I'm travelling and only stumbled over this when
checking my emails. I hope someone else can do it.

Cheers
Stan

TimDaly

unread,
Sep 6, 2009, 10:06:12 AM9/6/09
to sage-devel
I just bought the book "Gamma" by Julian Havil, a mathematician.
In the introduction on page xix he uses ln for the natural log.
From this I conclude that the notation is in current use by
mathematicians
as well as engineers such as Prof. Sadoway at MIT.

Axiom can support this by defining a macro:
ln(x) ==> log(x)
Are macros supported in Sage?

On Aug 24, 11:09 pm, TimDaly <d...@axiom-developer.org> wrote:
> In the lectures on solid state chemistry, lecture 22 the plot is shown
> as the ln(x), "the natural log"... in the open courseware from MIT:http://www.youtube.com/watch?v=TVuG75QH0kA&feature=SeriesPlayList&p=3...

William Stein

unread,
Sep 6, 2009, 1:24:44 PM9/6/09
to sage-...@googlegroups.com
On Sun, Sep 6, 2009 at 7:06 AM, TimDaly<da...@axiom-developer.org> wrote:
>
> I just bought the book "Gamma" by Julian Havil, a mathematician.
> In the introduction on page xix he uses ln for the natural log.
> From this I conclude that the notation is in current use by
> mathematicians
> as well as engineers such as Prof. Sadoway at MIT.
>
> Axiom can support this by defining a macro:
>  ln(x) ==> log(x)

Would it get printed and typeset as "ln" or "log" if you create such a macro?

William

William Stein

unread,
Sep 6, 2009, 5:35:24 PM9/6/09
to TimDaly, sage-devel
On Sun, Sep 6, 2009 at 2:29 PM, TimDaly<da...@axiom-developer.org> wrote:
> The macro
>  ln(x) ==> log(x)
> expands log(n) so ln(n) prints as log(n)

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:

--

Golam Mortuza Hossain

unread,
Sep 6, 2009, 5:56:05 PM9/6/09
to sage-...@googlegroups.com
Hi,

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

Burcin Erocal

unread,
Sep 6, 2009, 6:00:06 PM9/6/09
to sage-...@googlegroups.com
On Sun, 6 Sep 2009 14:35:24 -0700
William Stein <wst...@gmail.com> wrote:

> 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

William Stein

unread,
Sep 6, 2009, 6:10:18 PM9/6/09
to sage-...@googlegroups.com
On Sun, Sep 6, 2009 at 3:00 PM, Burcin Erocal<bur...@erocal.org> wrote:
>
> On Sun, 6 Sep 2009 14:35:24 -0700
> William Stein <wst...@gmail.com> wrote:
>
>> 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?

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

Tim Lahey

unread,
Sep 6, 2009, 6:22:48 PM9/6/09
to sage-...@googlegroups.com

On Sep 6, 2009, at 6:10 PM, William Stein wrote:

> 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,

TimDaly

unread,
Sep 6, 2009, 6:28:19 PM9/6/09
to sage-devel

> Unrelated question: What's up with Axiom development these days?    Is
> there any sort of relatively recent status report?   I'm just
> generally curious.

This isn't an Axiom forum so I'll skip the details and just give
pointers.
Axiom is released every 2 months, the next one is the end of
September.
(http://axiom-developer.org/axiom-website/releasenotes.html)
It is being rewritten into literate code as books. See
(http://en.wikipedia.org/wiki/Axiom_computer_algebra_system)

John Cremona

unread,
Sep 7, 2009, 3:38:13 AM9/7/09
to sage-...@googlegroups.com
While we are at it: asin = arcsin? acos=arccos? atan=arctan? ctg =
cotan (etc etc)

John

2009/9/6 Tim Lahey <tim....@gmail.com>:

Stan Schymanski

unread,
Sep 7, 2009, 7:00:50 AM9/7/09
to sage-...@googlegroups.com
+1 for the run-time option if I have a vote. It takes some effort to get
used to having to declare all variables and yet we stick to it. Why not
make the user declare what they mean by log(x)?
Not sure about the requirement of declaring the base every time. I
previously thought this would resolve this discussion, but it would make
copying and pasting of code between applications even more pain than
what it is now.

Cheers
Stan

mirko

unread,
Sep 7, 2009, 11:54:04 AM9/7/09
to sage-devel
Would it be possible to support both ln(x) and log(x), tg(x) and tan
(x) and so on via a locale setting?
If one locale is selected log, tan and so on, will be used, if another
that ln, tg, etc.

Mirko


On Sep 7, 12:38 am, John Cremona <john.crem...@gmail.com> wrote:
> While we are at it:  asin = arcsin?  acos=arccos? atan=arctan?  ctg =
> cotan (etc etc)
>
> John
>
> 2009/9/6 Tim Lahey <tim.la...@gmail.com>:

Francois Maltey

unread,
Sep 7, 2009, 1:41:54 PM9/7/09
to sage-...@googlegroups.com
mirko wrote :

> Would it be possible to support both ln(x) and log(x), tg(x) and tan
> (x) and so on via a locale setting?
> If one locale is selected log, tan and so on, will be used, if another
> that ln, tg, etc.
>
The input and the output must be the same, even in tex output and help
files.
An input log displays only log, and the system must claim that ln
doesn't exist in this session.
And log doesn't exist if the system uses ln.

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).

Robert Bradshaw

unread,
Sep 7, 2009, 2:23:06 PM9/7/09
to sage-...@googlegroups.com

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

William Stein

unread,
Sep 7, 2009, 2:28:59 PM9/7/09
to sage-...@googlegroups.com
>> 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.

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

Burcin Erocal

unread,
Sep 7, 2009, 3:06:53 PM9/7/09
to sage-...@googlegroups.com
On Mon, 7 Sep 2009 11:28:59 -0700
William Stein <wst...@gmail.com> wrote:

>
> >> 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

Minh Nguyen

unread,
Sep 7, 2009, 3:11:14 PM9/7/09
to sage-...@googlegroups.com
Hi 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

TimDaly

unread,
Sep 7, 2009, 3:11:47 PM9/7/09
to sage-devel
I might suggest something like:

http://axiom-developer.org/axiom-website/rosetta.html

which was an attempt to provide a translation from system to system.
Sage should probably consider a translator such as

Rosetta('expression', 'sourcesystem', 'targetsystem')

On Sep 7, 3:38 am, John Cremona <john.crem...@gmail.com> wrote:
> While we are at it:  asin = arcsin?  acos=arccos? atan=arctan?  ctg =
> cotan (etc etc)
>
> John
>
> 2009/9/6 Tim Lahey <tim.la...@gmail.com>:

William Stein

unread,
Sep 7, 2009, 3:14:29 PM9/7/09
to sage-...@googlegroups.com, David Ackerman
On Mon, Sep 7, 2009 at 12:11 PM, TimDaly<da...@axiom-developer.org> wrote:
>
> I might suggest something like:
>
> http://axiom-developer.org/axiom-website/rosetta.html
>
> which was an attempt to provide a translation from system to system.
> Sage should probably consider a translator such as
>
> Rosetta('expression', 'sourcesystem', 'targetsystem')

This reminds me a little of the units package I just had a student
whip out. He might be interested in implementing something related
to this...

>
> On Sep 7, 3:38 am, John Cremona <john.crem...@gmail.com> wrote:
>> While we are at it:  asin = arcsin?  acos=arccos? atan=arctan?  ctg =
>> cotan (etc etc)
>>
>> John
>>
>> 2009/9/6 Tim Lahey <tim.la...@gmail.com>:
>>
>>
>>
>> > On Sep 6, 2009, at 6:10 PM, William Stein wrote:
>>
>> >> 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,
>>
>> > Tim.
>>
>> > ---
>> > Tim Lahey
>> > PhD Candidate, Systems Design Engineering
>> > University of Waterloo
>> >http://www.linkedin.com/in/timlahey
> >
>



William Stein

unread,
Sep 7, 2009, 3:15:34 PM9/7/09
to sage-...@googlegroups.com, sage-release

That sounds good to me, though it is during the next Sage Days.

William

Message has been deleted

William Stein

unread,
Sep 7, 2009, 3:28:31 PM9/7/09
to sage-r...@googlegroups.com, sage-...@googlegroups.com
On Mon, Sep 7, 2009 at 12:23 PM, Minh Nguyen<nguye...@gmail.com> wrote:
>
> 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?
>

+1 from me.

William

Burcin Erocal

unread,
Sep 7, 2009, 3:54:11 PM9/7/09
to sage-...@googlegroups.com
On Tue, 8 Sep 2009 05:23:23 +1000
Minh Nguyen <nguye...@gmail.com> wrote:

>
> 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


William Stein

unread,
Sep 7, 2009, 4:07:12 PM9/7/09
to sage-...@googlegroups.com
On Mon, Sep 7, 2009 at 12:54 PM, Burcin Erocal<bur...@erocal.org> wrote:
>
> On Tue, 8 Sep 2009 05:23:23 +1000
> Minh Nguyen <nguye...@gmail.com> wrote:
>
>>
>> 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!"

That's what I would save if I were actively working on Sage right now. :-)

I'm busy with my research lately, which means writing a lot of Sage
code, but in number theory (Heegner points and quaternion algebras).

William

>
> 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
>
>
>
> >
>



Reply all
Reply to author
Forward
0 new messages