Re: Microrant on Ruy's Math Skills

On Mon, Jan 30, 2012 at 6:27 PM, Chad Perrin <[e-mail]> wrote:
> On Mon, Jan 30, 2012 at 05:22:47PM +0900, Robert Klemme wrote:
>> On Mon, Jan 30, 2012 at 6:56 AM, Chad Perrin <[e-mail]> 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:

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

Most popular programming languages have that smell.  It is also not
uncommon for complex tools to require reading a manual and making
oneself familiar with the features of the tool in order to be able to
use it properly.  Heck, there are even tools which require mandatory
training (usually to avoid hurting yourself or someone else).

>> If you need to do precise math all the time there are other tools
>> better suited for that. =A0You'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?

That's not what I suggested.  I was talking about "precise math" -
what you find in computer algebra systems.

>> So at the moment I believe the current situation is the best
>> compromise. =A0If you have suggestions for improvements which do not
>> make things worse for many when avoiding the unexpected behavior I am
>> curious to hear them. =A0For 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. =A0I really, *really* don't understand
> the resistance to this simple idea. =A0Even 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#=3D=3D 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#=3D=3D; I=
'm
> suggesting with supplement it. =A0Semantically speaking, the way Float#=
=3D=3D
> works now (as I understand it) makes perfect sense (note that I have not
> actually read the source for Ruby's Float#=3D=3D, so I'm not sure it does=
n't
> make less sense than I think). =A0What doesn't make sense to me is that
> being the only option in the class.

Thanks for the clarification!  Somehow it seemed =3D=3D should be replaced.

So you want something like this in std lib

class Numeric
  def delta_eql? x, delta
    (self - x).abs <=3D delta
  end

  def factor_eql? x, delta
    ((self / x) - 1).abs <=3D delta
  end

  def log10_eql? x
    Math.log10(self).floor =3D=3D Math.log10(x).floor
  end
...
end

The user would still have to decide which to choose and what parameter
to pick for the delta.  For that he needs to understand the matter of
numeric math.  Good documentation could help though.  Maybe these
methods should rather go into Math or Math::Eql - there could be
several more.  Question is though whether it would be more confusing
than not to have these methods.  A user would still be required to
understand the issues and pick a combination of method and values
appropriate for his use case.  It would certainly not prevent these
types of discussions. :-)

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

There is no method which does not require an additional data item
(what I called "level of imprecision"), what makes it harder to make a
proper choice.  See also:
http://www.ruby-forum.com/topic/3481172#1042651

Cheers

robert


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