Hi all,
So far I've been refraining from posting here, since I don't have
strong feelings one way or the other, but the discussion so far has
been great and I'd like to leave a few comments.
On 7/8/07, William Stein <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> Thanks for all the feedback from everybody about symbolic variables,
> special functions, etc. For now (i.e., the very near term), I think
> the best thing to do is:
> (1) remove all predefined *symbolic* variables except x,
> leave in e, pi, and I:
> -- everybody basically wants this.
This is fine. I'm not sure which approach is better. There will be
lots of Maple/Mathematica users who will find it bizarre that they
have to manually declare their variables, but I guess there's nothing
wrong with that.
> (2) don't make any changes to how special functions behave.
> -- doesn't seem necessary.
I agree. RR(expr) is very easy to use. As is float(expr).
> (3) don't make any changes to how floating point literals behave.
> -- basically put making any changes here on hold, since
> substantial discussion still hasn't revealed a
> sufficiently good solution.
>
> If one wants purely C-library float special functions,
> doing, e.g.,
> from math import sin, cos, tan
> etc., works very well right now. And using float(2.5) or "2.5r"
> works fine now.
Agreed.
> I'm intrigued by Marshall's remark about "What I think is bad is
> that something like 1.0*sin(1) is not numerical - in mathematica
> the sin(1) would be forced into a numerical type."
>
> Here's what Maxima/Mathematica/Maple/Mupad do:
>
> sage: maxima.eval('2.5*sin(1)')
> '2.5*sin(1)'
> sage: mathematica.eval('2.5*Sin[1]')
> 2.10368
> sage: maple.eval('2.5*sin(1)')
> '2.5*sin(1)'
> sage: mupad.eval('2.5*sin(1)')
> 2.5 sin(1)
>
>
> Here's what SAGE does:
>
> sage: 2.5*sin(1)
> 2.50000000000000*sin(1)
>
> Here's what REDUCE does -- which is totally different
> (and nuts, IMHO):
>
> 1: 2.5*sin(1);
> 5*sin(1)
> ----------
> 2
>
> So Mathematica is in fact the only system that makes sin(1)
> symbolic but 2.5*sin(1) numerical. I.e., Maple, SAGE, Mupad,
> and Reduce all tend toward 2.5*sin(1) being as symbolic as
> possible for some reason.
>
> From an implementation point of view, given the SAGE rules,
> it makes way more sense for 2.5*sin(1) to remain symbolic,
> since:
> (1) this is what the backend simplification system (maxima) does,
> and
> (2) 2.5 * sin(1) in SAGE is computed by making "2.5" symbolic,
> then doing the multiply formally.
>
> I'm not saying we shouldn't find a way to make 2.5 * sin(1) possibly
> be numerical. I'm just remarking that this is a complicated issue
> and it definitely deserves further discussion.
I actually really like Mathematica's behavior on this one. I think
it's worth considering. From a pragmatic point of view, it seems to me
that if I'm multiplying something symbolic by something approximate, I
don't want to see anything symbolic in the result, since my result is
inherently limited by the approximation. It's less clear in the case
of addition.
I think ultimately we will need to get feedback from a broader group
of users. What we as developers think is best might not actually
correspond to what most people who will be using SAGE want and expect.
~Bobby
> -- William
>
> >
>
--
Bobby Moretti
[EMAIL PROTECTED]
--~--~---------~--~----~------------~-------~--~----~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~----------~----~----~----~------~----~------~--~---
