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 requirene 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%.           
>> 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.

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

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

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.

Cheers

robert

-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/