On Thu, Nov 27, 2008 at 3:16 PM, John H Palmieri <[EMAIL PROTECTED]> wrote:
>
> On Nov 27, 12:34 pm, "William Stein" <[EMAIL PROTECTED]> wrote:
>
> [snip]
>
>> Moreover, Sage integers don't allow coercion from float:
>
> There is probably a good reason for this, but what is it? After all,
> int(float(1)) works, so why doesn't Integer(float(1))?  (Also int(RR
> (1)) and Integer(RR(1)) both work, for what that's worth.)

Basically, the reason is because I *really* dislike this
behavior:

sage: int(1.5)
1

Conversion X(a) should create a version of a given element
of the type (or parent) X that is equal to a.  The above behavior
does not do this and is hence -- in my opinion -- a bad and
error prone design.  It is a lot like Python's "1/3 == 0" crap.
I think it is a design mistake that was inherited from C.

William




>
> Oh, by the way, I was just looking through integer.pyx to try to
> answer my question above.  In that file, why are there two different
> lines
>
>    cdef class Integer(sage.structure.element.EuclideanDomainElement)
>
>    cdef class Integer(sage.structure.element.EuclideanDomainElement):
>
> What role does the first cdef statement play? Is it some Cython thing?
>
>  John
>
>
> >
>



-- 
William Stein
Associate Professor of Mathematics
University of Washington
http://wstein.org

--~--~---------~--~----~------------~-------~--~----~
To post to this group, send email to [email protected]
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://www.sagemath.org
-~----------~----~----~----~------~----~------~--~---

Reply via email to