Re: Microrant on Ruy's Math Skills

On Mon, Jan 30, 2012 at 06:01:02PM +0900, Florian Gilcher wrote:
> 
> On Jan 30, 2012, at 9:32 AM, Tony Arcieri wrote:
> 
> > On Mon, Jan 30, 2012 at 12:22 AM, Robert Klemme
> > <[e-mail]>wrote:
> > 
> >> It seems many people use the "floating point mess" without major
> >> issues.  So it cannot be as bad as you make it sound.
> >> 
> > 
> > Floating points are a great choice for approximating continuous values and
> > thus working on things which require both high performance and
> > approximating real-world data sources. This includes things like games,
> > non-gaming related 3D applications, perceptual media including audio and
> > video codecs, and everything involved in working with perceptual media on
> > computers such as non-linear editing, speech synthesis, and speech
> > recognition.
> 
> Let me add "statistics gathering" to the list...
> 
> > People don't often do these things in Ruby. I'd say they're uncommon use
> > cases.
> 
> ... and suddenly, you have a _very_ common use case. I have no client
> where it doesn't happen.
> 
> Graphing is also not uncommon.
> 
> > 
> > Something people do quite often in Ruby: deal with money. Money isn't
> > continuous, it's discrete. A decimal type is a much better choice for
> > dealing with money than a floating point.
> 
> Yes, but a dedicated money type that encodes the currency is also a much better
> choice. Also the standard in handling monetary values is not using a decimal
> representation anyways: you just encode the smallest value as an Integer.

It's easy to focus on a single tree and ignore the forest.

Dealing with money is not the only use case -- and it becomes a lot more
complicated when you have to deal with exchange rates, completely blowing
the "just use cents" solution out of the running as a simple expedient.

Money is an example of the kind of use cases where having something a bit
more accuracy-predictable than Floats without imposing a lot of syntactic
overhead is a good idea.  It is not the *only* example.  Answering "For
example, there's dealing with money . . ." with a solution that only
works for money is missing the point of an example.  In fact, I'd say
that the biggest "use case" is probably the vast range of circumstances
wherein there is not a singular, systematic requirement for unsurprising
arithmetic; it is, instead, the everyday case of doing division in casual
cases where the entire point of a program is not the math itself, but the
math is expected to fit some definition of predictable accuracy.
Consider:

1. averaging (mean) small numbers from large samples for a rating system

2. simulating dice rolling and subsequent math for roleplaying games

3. using irb as a "desktop" calculator

4. figuring out distances for trip planning

5. percentages in myriad circumstances, such as offering comparisons of
relatively small differences between different customer groups' behaviors
as just one small part of a larger reporting program (or, for roughly the
same usage pattern, a ten year old learning to programming doing some
simplistic statistical work involving his or her friends' trends in
favorite ice cream flavors)

Note that none of these is as rigorously and pervasively dependent on
exactitude of painstakingly defined standards for accuracy of sub-1.0
positive numbers as you're likely to find in the work of computer
scientists working on their dissertations or specialized professional
fields, but they can still result in bugs based solely on the use of
floating point numbers with Ruby's Float comparison capabilities, thus
mandating either the use of much more verbose libraries with much more
finnicky syntax or the (re)invention of alternate comparison methods for
the Float class.

Then, of course, there's what may be the biggest use-case of all: people
who are not aware of the problem of the inconsistencies of decimal math
using the IEEE-standard floating point implementation because when they
look at documentation for Ruby's Float class all they see is Float#==
with no alternative comparison methods.


> 
> If money is the reason against float, its the wrong reason. It may be a tempting
> error, but it only shows that the developer in question did not read a single 
> line about handling money in software - which is another common problem, but
> not one that you can actually fix by the choice of literals.

It's not the only reason, and it's not a reason "against float", either.

It's just a single reason for offering *something* other than the very
limited options we currently have -- which seem designed on the
assumption that any case where the unadorned IEEE-standard floating point
type is an exceedingly rare edge case -- and offering it in a manner that
makes it as close to an equal "citizen" as we reasonably can.  As things
currently stand, it seems difficult to claim (with a straight face) that
math involving positive decimal numbers between 0 and 1 without
inaccuracies that are nontrivial to predict for the average coder even
rises to the level of second-class "citizen".

Realistically, I think the IEEE- standard floating point type is itself a
fairly rare edge case compared to other options like "truncation at Nth
decimal place" and "just get me close without a difference of 0.1 between
two potential inputs to a given expression resulting in the precedence of
two items being unexpectedly swapped thanks solely to unexpected rounding
mismatches between binary and decimal numbers."

-- 
Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ]