On Monday, March 31, 2014 5:55:19 PM UTC-7, Aaron Meurer wrote: > > > > > On Mon, Mar 31, 2014 at 7:37 PM, Richard Fateman > <[email protected]<javascript:> > > wrote: > >> >> >> On Monday, March 31, 2014 3:35:23 PM UTC-7, Aaron Meurer wrote: >>> >>> >>> >>> >>> SymPy floats are not machine floats, but arbitrary precision floats. >>> These are very useful, and (at least by my understanding) far more >>> efficient to work with than rationals if that's what you want. >>> >> >> bigfloats can be expensive too. >> > > Yes, but people rarely go beyond the default precision (15, which is > roughly machine precision anyway). And anyway, bigints are also expensive... > > Well, that's not a great idea if sympy floats look like machine precision but are not. Too easy to confuse. bigints should be substantially less expensive because the computations involved with rounding are not needed. Assuming the bigints have about the same number of bits.
> >> >>> Arbitrary here means arbitrary but fixed. Rationals are arbitrary but >>> unbounded. That makes a large difference. If you care about 100 digits, but >>> only 100 digits, then you really do want to throw away anything beyond >>> that. If you used rationals, >>> >> Typically people do rational arithmetic exactly, not periodically >> truncating the results. If it was appropriate >> to truncate the results, they would be using bigfloats. >> > > That's exactly what I'm saying. If your numbers represent something > physically meaningful, then the smaller digits do not matter. > Many people use computers for calculations that are not physically meaningful. That's most of Sage. > There's no point keeping a billion digit numerator and denominator just > because you wanted to have 1.0000000...01 instead of 1.0. > It does if you exactly subtract 1 from it. > > >> Running some computations to completion with exact rationals means that >> the number of digits in the numerator and denominator tend to grow >> rapidly. Sometimes, however, you want to do this because the rational >> answer comes out right (for example, exactly zero) and the floating point >> version is non-zero and hence, relatively speaking, infinitely wrong. >> > > Yes, these false nonzeros are a pain. And they lead to wrong results if > you don't compute with them carefully (e.g., > https://github.com/sympy/sympy/issues/2949#issuecomment-38336823). But I > don't think it's intractable. You have to keep track of precision > carefully. > Unfortunately it is in general intractable. (see Daniel Richardson's results on unsolvability of the zero-equivalence problem) > > >> >> >> >>> you would have to round them down constantly (which btw is what causes >>> these "arithmetic issues", or else use 10 times as much memory and CPU time >>> than you wanted. >>> >> >> The difference in costs and memory between floats and bigfloats tends to >> be enormous. there are also libraries for double-double or "quad" >> precision floats, interval arithmetic, and other items of interest. See >> what MPFR provides as an example. But if sympy doesn't do regular >> double-float arithmetic, someone may want it later. >> RJF >> > > We probably should have a MachineFloat class that just wraps Python's > float. It might speed things up. > Sounds plausible, You might have to do a lot of fiddly work. E.g. consider the differences between cos(0.5), cos(1/2), cos(MachineFloat(1/2)), cos (sympy_bigfloat("0.5")) etc. RJf > > > -- You received this message because you are subscribed to the Google Groups "sympy" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/406adef1-d351-4bf5-bfe1-84763f88d1af%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
