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 --~--~---------~--~----~------------~-------~--~----~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~----------~----~----~----~------~----~------~--~---
