Re: Microrant on Ruy's Math Skills

On Sat, Jan 28, 2012 at 06:24:35AM +0900, Gary Wright wrote:
> 
> 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:
> > 
> > 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).

That may be the case, but the problem here is that we lack a succinct,
fairly intuitive syntax for fixed point numbers, apparently with no easy
way to provide it.  We're stuck with either making everybody live with
totally unobvious and cumbersome ways to do fixed point math (which means
very few people will use them, even when they should), or rewriting the
parser (apparently) -- unless we provide a couple of least-surprise
comparison methods for Float as I suggested.

Pick one.

. . . or let me know if there's another option.  Don't forget that the
"rewriting the parser" choice is likely to run into stiff opposition.


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

Really?  I think it's a huge stumbling block to adoption amongst casual
coders, and an invitation for them to show up on this mailing list and
complain about how math in Ruby is "broken" periodically.


> 
> 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 = params['temperature']
> 
> Where you've previously defined the setter to do conversion from strings:
> 
> 	def temperature=(text_value)
> 	  self['temperature'] = BigDecimal(text_value)
>         end

. . . and by "you" you mean me, evidently, or you, or one of the other
people who already knows about BigDecimal and the limitations of IEEE
standard floating point implementations.  You may not be aware of this,
but I'm pretty sure half (or more) of the people learning Ruby  right now
either don't know about the specifics of the problem and how to get
around it or have long since forgotten having heard about it and need to
be reminded.


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

That assumes . . .

1. you're using Rails

2. you know about this approach and the problem it fixes

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