Rick Denatale wrote: > On Sat, Nov 14, 2009 at 8:19 PM, Marnen Laibow-Koser <marnen / marnen.org> > wrote: >> >> Why? I can't see a single reason to use IEEE floats, unless you've done >> benchmarks and are absolutely certain that it's causing a performance >> problem. (Ward Cunningham did just that on a computationally intensive >> Smalltalk application that used fixed-point for all math -- and found >> that he couldn't even measure a difference in performance.) > > So Ward found that fixed point integers weren't SLOWER then floats, > what a surprise! > >> >> IEEE floats have no advantages that I can see and huge disadvantages. I >> just don't see them as being even slightly appropriate or useful for >> math. > > That's just silly if you ask me. Why? Sure, I could work around their problems, but I don't care to when BigDecimals are available. > > First of all BigDecimals are still floats, with a decimal base and a > variable length, but floats nonetheless. > > They aren't a magic bullet, and despite what you said in a slightly > later post, they are neither semantically clear: > > >> "%.20f" % ((1.85 / 10.0) * 10.0) > => "1.85000000000000008882" > > but also > > >> puts (BigDecimal.new("1.0") / 3) * 3 > 0.999999999999999999999999999999999999999999999999999999E0 > That's not a question of semantics, but of accuracy. Anyway, it's easily worked areound by using Rational. > Usually people flock to BigDecimal when they discover something like > the first example. But changing the base to 10 only > changes WHICH rational numbers can't be represented, it doesn't > eliminate the problem entirely. I know. But BigDecimal + Rational *will* eliminate the problem insofar as it's possible to do so. > > or numerically precise. > > Yes perhaps they are more precise but at an increasing cost of > performance as the 'need' to carry around extra digits increases. > Of course. That's always the cost. I'd rather calculate as accurately as possible and introduce performance hacks (such as IEEE floats) as necessary. > > I.E.E.E Floating point is just the culmination of the floating point > data types which got us to the moon in the 1960s. They are quite > usable as long as the programmer understands their properties and > limitations, BigDecimal has these limitations as well, just different > parameters on those limitations. > > Engineers back then were very used to working with primitive computers > which used floating point numbers of extremely limited precision, > maybe 2 or 3 digits in the fractional part, those computers were > called slide rules. Yes. And you know what? We're not using slide rules any more. It is silly in 2009 to be bound by the limitations of slide rules. > > When I was a young lad, it used to be that young programmers took a > semester long course on numerical analysis, which started with, and > continuously came back to dealing with the properties of floating > point numbers. > > I guess that doesn't happen much anymore. Again, I could do that or (more likely) find out how to do it. But why bother when wise use of BigDecimal and Rational will completely obviate the need? > > -- > Rick DeNatale > > Blog: http://talklikeaduck.denhaven2.com/ > Twitter: http://twitter.com/RickDeNatale > WWR: http://www.workingwithrails.com/person/9021-rick-denatale > LinkedIn: http://www.linkedin.com/in/rickdenatale Best, -- Marnen Laibow-Koser http://www.marnen.org marnen / marnen.org -- Posted via http://www.ruby-forum.com/.