On Mon, Mar 31, 2014 at 7:37 PM, Richard Fateman <[email protected]> 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... > > >> 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. There's no point keeping a billion digit numerator and denominator just because you wanted to have 1.0000000...01 instead of 1.0. > 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. > > > >> 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. Aaron Meurer >> >> -- > 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/e82fd0c1-cc1a-4d4d-a174-85067cef49e6%40googlegroups.com<https://groups.google.com/d/msgid/sympy/e82fd0c1-cc1a-4d4d-a174-85067cef49e6%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- 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/CAKgW%3D6LzDt824Wja2BcU%2BcF8gMr-cNCMAHtobAK3aoAFtu7pHQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
