On Mar 28, 7:18 pm, Gonzalo Tornaria <torna...@math.utexas.edu> wrote: > On Thu, Mar 22, 2012 at 4:14 PM, Robert Bradshaw > > <rober...@math.washington.edu> wrote: > > ... > > This is horrendous. Better to not have this "constant" (at least not > > in the global namespace) than behavior like this. The top level NaN, > > if we want one, could be in RR (precision doesn't really matter for > > this value). > > Agreed, that's my point. > > Working on a completely unrelated project, I was hit by a different > and unrelated bug regarding NaN: > > sage: RR(NaN) < float(1e-10) > True > > Also, I point out that the usual definition of NaN includes the fact > that "NaN == NaN" should be false. Sage doesn't behave consistently: > > sage: float(NaN) == float(NaN) > False > sage: RR(NaN) == RR(NaN) > True > sage: NaN == NaN > NaN == NaN > sage: bool(_) > True > > (this property is handy to test whether a value is nan)
probably not a good idea. There are other entities that might have that property. If you want to test if something is a NaN, you should have an IsNaN() test. NaN[xxx] where xxx is some more descriptive info could be used as a print form for something which is (a) a floating point type: single. double. extended. Probably NOT arbitrary precision, but maybe. (b) has an exponent field which is the reserved NaN exponent for that field width. Arbitrary precision might not exclude any exponents, so there may not be a NaN (or Infinity) there. Anything else and you are looking for trouble. -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
