```On Mon, Jan 30, 2012 at 05:22:47PM +0900, Robert Klemme wrote:
> On Mon, Jan 30, 2012 at 6:56 AM, Chad Perrin <code / apotheon.net> wrote:
> > On Mon, Jan 30, 2012 at 10:03:04AM +0900, Gary Wright wrote:
> >>
> >> On Jan 29, 2012, at 2:26 AM, Jon Lambert wrote:
> >>
> >> > On Jan 27, 2012, at 3:26 PM, Gary Wright wrote:
> >> >> What 'value' do you expect for this expression:
> >> >>
> >> >> BigDecimal("1.0") / BigDecimal("3.0")
> >> >
> >> > Decimal math operations need use a default rounding context or require one to set a
> >> > rounding context before performing an operation.
> >> >
> >> > Do you round towards +infinity, -infinity,
> >> > towards 0, away from 0,
> >> > to nearest (and if equidistant, round down),
> >> > to nearest (and if equidistant, round up), or
> >> > to nearest (and if equidistant, round so that the last digit is even) aka. bankers rounding?
> >> >
> >> > Only then can you know what to expect.
> >>
> >> Agree 100%. ?I was just trying to illustrate that even if you have some
> >> wonderfully crafted big decimal literal syntax, you still need to address
> >> the context issues you just listed.
> >>
> >> ? ? ? 1.0D / 3.0D
> >>
> >> Might be easier to type but it is only part (perhaps a small part) of the puzzle.
> >
> > The point of offering something other than "all you get is floats and
> > libraries", of course, is that a simple set of such rules is a lot easier
> > to deal with than the floating point mess that is common now.
>
> It seems many people use the "floating point mess" without major
> issues.  So it cannot be as bad as you make it sound.

"Many" is a relative term -- and "without major issues" is even more
relative.  When your definition of "without major issues" is "reinventing
the more-useful-comparison-method all over the world all the time" or
"lots of people unaware of edge-case unexpected values", I'm inclined to
disagree with your definition.

> >
> > ?It's a lot
> > easier to deal with "it truncates decimals past the Nth place" or any
> > other such simple rule than "Uh . . . it's probably going to do some
> > weird shit when you start doing math -- weird shit that requires you to
> > do binary math to predict the outcome. ?You really just shouldn't use
> > it. ?Use some verbose library syntax instead. ?You like typing -- right?"
>
> Any other _efficient_ floating point math would have to choose a
> limited representation.  You would get unexpected (for those who are
> not aware of numerics anyway) rounding issues anyway.  That would not
> be any better than the situation today, which has the advantage of a
> long established standard, so it is known to many.  Having an
> arbitrary precision math as default would make many applications
> slower than necessary which do not need that high precision math.

I don't know whether you have been reading the ongoing discussion
subthread involving me, or whether you have the old emails handy -- or
if, conversely, you have been ignoring this particular branch for a while
and deleting the messages unread until now.  An examination of the
discussion so far would reveal that I'm not even arguing that the Float
class should necessarily be replaced by any fixed point types as the
default type for decimal literals.  All I'm trying to do is point out the
flaws in keeping on with things exactly as they are.  Considering the
long tradition of using IEEE-standard floating point numbers behind a
literal representation like 1.1, I have actually been suggesting
something like adding at least one additional comparison method to the
Float class that can be used to perform comparisons up to a given fixed
precision, or do a ratio comparison, or something well-understood that
does not require the programmer to do binary math on the fly to be able
to accurately keep track of the results of Float#== comparisons all the
time or reinvent such comparison methods regularly.

From a usability perspective, leaving it up to the programmer, assuming
all programmers are aware of the difficulties involved in floating point
accuracy and expecting them to implement work-arounds is a really stinky
language design smell, in my opinion.

>
> If you need to do precise math all the time there are other tools
> better suited for that.  You'll even find free / open source ones:
> http://en.wikipedia.org/wiki/Computer_algebra_system

Are you aware of how silly it is to tell people that wanting to do math
that doesn't surprise them in Ruby is just a non-starter, and they should
go use something else?

>
> So at the moment I believe the current situation is the best
> compromise.  If you have suggestions for improvements which do not
> make things worse for many when avoiding the unexpected behavior I am
> curious to hear them.  For a new language the situation is totally
> different of course.

I think the "best compromise" would be, as I said more than once in this
subthread of discussion, to add a couple more comparison methods to the
Float class, providing easier mental modelling of how math works within a
program, where they're more likely to be noticed and will not require
everyone to create his or her own.  I really, *really* don't understand
the resistance to this simple idea.  Even if people sometimes have to
create yet another method for specialized purposes, one more comparison
method designed to abstract away the fuzzy edges of the binary arithmetic
behind the scenes for 98% of common cases would be a *huge* improvement,
where right now the situation is that Float#== can easily bite people in
somewhere in the neighborhood of 98% of common cases (reversing the
likelihood of a sane solution).

Just to be perfectly clear, I'm not suggesting we replace Float#==; I'm
suggesting with supplement it.  Semantically speaking, the way Float#==
works now (as I understand it) makes perfect sense (note that I have not
actually read the source for Ruby's Float#==, so I'm not sure it doesn't
make less sense than I think).  What doesn't make sense to me is that
being the only option in the class.

Can someone please explain to me in clear, direct terms why there is
opposition to the simple expedient of adding at least one additional
comparison method to Float to address the vast majority of casual use
cases without having to resort to reimplementing such comparison methods
over and over again or bringing in additional libraries with onerous
syntactic verbosity?

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

```