```On 15 Nov 2009, at 01:41, Marnen Laibow-Koser wrote:
> Eleanor McHugh wrote:
>> On 15 Nov 2009, at 01:19, Marnen Laibow-Koser wrote:
>>>
>>> IEEE floats have no advantages that I can see and huge
>>> just don't see them as being even slightly appropriate or useful for
>>> math.
>>
>> Because often expressing non-integral values as floating-point in =20
>> code
>> better represents intent than using fixed-point math,
>
> True, perhaps.  Ward was doing fixed-point currency, so expressing
> amounts as pennies is semantically clear.

Well currency is an interesting problem. It can be viewed as a scalar =20=

floating-point system, or as an N-dimensional integral system =20
(conventionally 2D but =A3/s/d was a clear example of a 3D currency =20
system and there's no reason why we shouldn't generalise further).

> But that's where BigDecimal comes in.  It's clearly a floating-point
> number, but it's actually accurate.  Semantically clear, numerically
> precise.  What more could you want? :)

Something that for irrational numbers gives me a useful approximation =20=

without consuming all of the available memory would be nice :)

>> and unless the
>> latter will have a performance or accuracy advantage for a given
>> problem I consider semantic simplicity to be my primary design
>> criterion.
>
> BigDecimal is no less semantically simple than Float (particularly =20
> when
> coupled with Ruby's operator overloading), and it will always have an
> accuracy advantage for any conceivable problem.

Accuracy is not precision. It gives me little benefit to be accurate =20
if I only need to be precise to a certain number of decimal places, =20
which is the reason for the existence of floating-point in the first =20
place. One of the dirty secrets of computational physics is that =20
floating-point math is used all over the place...

Ellie

Eleanor McHugh
Games With Brains
http://slides.games-with-brains.net
----
raise ArgumentError unless @reality.responds_to? :reason

```