My first response to this was revulsion. I find the consequences intriguing,
but also a little revolting.
sage: 173.is_prime()
True
sage: 173.integrate('t') #173 is a function?
865*t
sage: 173.sqrt()
13.1529
Ok... fine. But how do we know what type 173 is, off the bat? ZZ can be
redefined... so ZZ(173) might be quite different in certain contexts. Say, I'm
working in 4x4 matrices or something, and I don't want to always write
17*M.identity_matrix()... I don't think tab completion can be expected to know
the type of the literal 173 without executing ZZ(173) which might change the
environment somehow.
Also, if 173.sqrt() works, why shouldn't 173.12.sqrt()?
Extreme silliness:
sage: 173.<tab>
173.0 173.10 ...
173.1 173.11 ...
173.2 173.12 ...
. .
. .
. .
173.additive_order()
.
.
.
On Wed, 13 Dec 2006, David Harvey wrote:
>
> Does anyone else think that 173.binary() should be legal? Currently the
> preparser mangles it into a syntax error, it thinks the dot is a
> decimal point. One currently needs to do (173).binary() instead.
>
> David
>
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
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/
-~----------~----~----~----~------~----~------~--~---
