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/.