On Thu, Oct 03, 2002 at 02:01:49AM -0400, Tim Peters wrote: > [Oren Tirosh] > > But why would you want to convert floating point numbers to rationals > > in the first place? > > For one thing, to continue an exact calculation that has grown too large to > continue in floating-point without losing information, but where the extreme > expense of using rationals instead of floating point pushes you toward using > fp just as long as you can. > > > Floating point numbers are generally inexact. > > The IEEE-754 standard mandates an "inexact flag" (and your HW has one) for > this very kind of purpose. Your FPU knows for certain whether you've ever > lost a bit of information when doing basic fp operations; unfortunately, > it's still extremely clumsy to get at this info. The IEEE-754 standard also mandates NaNs, Infs, rounding modes and several other features. These are not supported by Python in a consistent and portable manner nor it is likely that they can be supported on all Python platforms in the foreseeable future because of the limitations of the underlying C libraries. > > Converting them to exact rationals can give a false sense of > > exactitude. > > So can printing more digits than warranted <wink>. Yes, my material strength teacher drove this point home by taking off points for results with either too many or too few digits. > > Any calculation involving a floating point number should taint > > the result with inexactitude and yield a floating point result. > > How old are you? See -- integers can be inexact too. Representation has > nothing to do with exactness, which is one part of this story Scheme got > straight. I am approaximate 61131/76 fortnights old :-) A integer is always exact and integer arithmetic is always exact with the exception of division. The mapping of this mathematical integer to some real-world meaning may be inexact, though. I won't sue anyone because the pack of rubber bands doesn't contain exactly 1000 pieces. A double precision floating point number may represent some number exactly and produce exact results for some arithmetic operations but in practice if I type 0.3 and get 0.29999999999999999 the numbers aren't exact in the first place and if I have no access to the flags that tell me if the result is exact or not I must treat all results as inexact. As usual, your arguments are flawless - in an academic sort of way. In practice, though, I think my original point about inexactness of of floats and tainting of results still stands. Oren
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4