```On Jan 27, 2012, at 3:52 PM, Chad Perrin wrote:
> Look back at the beginning of what I said.  It boils down to this:
>=20
> One or two alternate comparison methods for Float that have known, =
clear,
> easily reasoned boundaries between where it works and where it does =
not,
> should be pretty easy to include in the Float implementation -- and to
> make succinct so we don't have to deal with fugliness in our code at
> every turn when dealing with decimal numbers.

Now we disagree. Trying to shoe-horn Floats into behaving like fixed =
point
numeric values is just the wrong approach. I understand wanting to have
a standard comparison method for Float but I don't think that is a
useful solution when you really want fixed point math (i.e. wrong tool
for the job but still a useful tool to have for other jobs).

Tony's suggestions seem like a better path to me:
> I think the real path forward here would be to propose that BigDecimal =
is
> loaded by default in Ruby 2.0, and to propose some type of literal
> representation for them, such as 1.1D that was suggested before.
>=20
> The thing that stops people from using BigDecimal right now is the
> inconvenience of doing BigDecimal("1.1"), and the output of =
BigDecimal#to_s
> and #inspect is difficult to interpret.

I do think though that the syntax/convenience thing is somewhat of a =
distraction.

In any real program (i.e. not some one-off examples via irb), you aren't =
going
to be coding explicit constructors for BigDecimal or any other numeric =
type. It
will be something more like:

sample.temperature =3D params['temperature']

Where you've previously defined the setter to do conversion from =
strings:

def temperature=3D(text_value)
self['temperature'] =3D BigDecimal(text_value)
end

In rails you can define a column to be of type :decimal and have the =
framework
manage all the conversion to/from BigDecimal.  I think this is the more =
typical
way that fixed-point math would be handled in a real program (i.e. via =
the
framework or library).

Gary Wright

```