On Wed, May 5, 2010 at 12:33 PM, Nathan O'Treally <[email protected]> wrote: > sage: int(1.1) # pretty valid; this is neither implicit *nor* meaning- > preserving
I hate the above too. Which is one reason why we have: sage: ZZ(1.1) Traceback (most recent call last): ... TypeError: Attempt to coerce non-integral RealNumber to Integer > So the result of float(1+2j) *could* equally well be 1.0 (a > projection, discarding information) because it is explicit, though one > should perhaps better use (1+2j).real_part() since it is more > "readable". > (Btw, Python floats do not even form a ring.) Neither do Sage rationals, since computers are finite. But yes, I know that the set of floating point numbers aren't associative, etc. > In maths, 0.0 and 0.0000 denote the same thing; in other sciences, > they usually do not (because the literals are interpreted to carry > information on the precision or accuracy, e.g. of a measurement, too). In Sage 0.0 and 0.00000000000000000000000000000000000000 should not denote the same thing, though sadly they do. Note, however, that 1.0 and 1.00000000000000000000000000000000000000 are different in Sage (as I expect): sage: 0.0 0.000000000000000 sage: 0.00000000000000000000000000000000000000 0.000000000000000 sage: parent(0.00000000000000000000000000000000000000) Real Field with 53 bits of precision sage: 1.00000000000000000000000000000000000000 1.0000000000000000000000000000000000000 sage: 1.0 1.00000000000000 sage: parent(1.00000000000000000000000000000000000000) Real Field with 130 bits of precision sage: parent(1.0) Real Field with 53 bits of precision I consider the above inconsistency a bug. http://trac.sagemath.org/sage_trac/ticket/8896 -- To post to this group, send an email to [email protected] To unsubscribe from this group, send an email to [email protected] For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
