> I remember reading a long thread on axiom-devel that was a discussion
> between Ondrej Certik and the axiom developers. It ended rather
> abruptly when one of them wrote that they were not interested at all in
> "formal symbol manipulation" and Ondrej replied that possibly non-rigorous
> formal symbol manipulation was *precisely* what he is interested in.
> There is certainly a very important place for this sort of computation.
There is just a huge difference between how pure mathematicians and
physicists and engineers are accessing the mathematics. The most
prominent example being distributions, mathematicians usually love the
notation <delta, phi> instead of writing integral(delta(0)*phi(x), x),
which is more natural, it has the same rigor and you can manipulate
with it more easily.
It's not just "undergraduate science majors", IMHO it's all engineers
and all physicists as well. I think everyone except mathematicians.
:)) Just joking. It should be done in a way, so that if you type
"sqrt(x)", or whatever, it will just do what I would expect it to do.
And of course you can specify more mathematical rigor, if you want
(like domains, etc.) if needed.
As to
y+sin
I don't see any reasonable meaning to it, so it should rise an
exception in my opinion.
> I think sin should be an instance rather than a class, and it would
> have a reasonable __call__ method. This would have the side effect of
> being consistent with Python conventions, and would be more
> consistent with the user's idea that "sin" is a function. One can
> also then do things like
This is what we do in SymPy at the moment. See below why I don't like it.
> sage: sin.is_zero()
> False
What should this particular line do? I don't understand the doctest
for is_zero either:
"
Return True if self equals self.parent()(0). The default
implementation is to fall back to 'not self.__nonzero__'.
"
I understand this though:
sage: sin(0).is_zero()
True
sage: sin(1).is_zero()
False
> I don't see the latter ever getting used, or even being exposed. It
> seems as unnatural as
>
> sage: import types
> sage: types.IntType(4) # instead of using int(4)
Well, I can see a difference:
sage: type(sin)
<class 'sage.calculus.calculus.Function_sin'>
sage: type(4)
<type 'sage.rings.integer.Integer'>
>>> type(4)
<type 'int'>
so basically the "type" says what is the class of that instance. So 4
is an instance of int or Integer in SAGE and thus should be
instantiated using int(4), or just using a syntactic sugar: 4. On the
other hand sin is an instance of Function_sin, but it shouldn't be
instantiated by Function_sin(). It seems to me like some kind of
magic, that I type "sin" and some instance of a class that I am not
supposed to import is returned. Note that we do the same in sympy
currently.
Nevertheless, it's not a big deal anyway. I just wanted to know your
opinions about this. Thanks a lot for all the ideas you wrote.
Ondrej
--~--~---------~--~----~------------~-------~--~----~
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/
-~----------~----~----~----~------~----~------~--~---
