On Thu, Jan 26, 2012 at 6:05 PM, Garthy D <
garthy_lmkltybr / entropicsoftware.com> wrote:

>
> Hi all,
>
> Such a large discussion from a simple initial post that was, in all
> likelihood, an attempt to troll for as many responses as possible. It looks
> like it has been wildly successful.
>
> Perhaps a response like this would have been appropriate:
>
> "Floats in Ruby are represented using the floating point numbers provided
> by the underlying system, which are generally base 2 floating point
> numbers, as per IEEE 754. They have advantages and disadvantages that are
> worth being aware of, including loss of precision for certain operations
> and values. This means that you cannot rely on testing for equality in
> certain cases, and it may be more appropriate to check to see if the result
> is within a certain epsilon. If the disadvantages are not suitable for your
> problem domain or use case, you will have to use a different numeric
> representation system more suited to your problem. All representation
> systems have their own strengths and weaknesses. BigDecimal may be more
> suitable than float in this case. A web search for 'floating point
> representation' will provided much additional useful information."
>
> In any form of software development you need to be aware of the
> capabilities and limitations of the systems that you use, and in many cases
> make an informed decision based on a set of potential systems. To remain
> wilfully ignorant of these systems, and then cry "pathetic", is
> disingenuous. To subsequently push for language changes based on such a
> shaky foundation is ludicrous. There are far better ways to stimulate
> genuine discussion on an genuinely interesting topic than through a
> deliberately inflammatory initial posting and comparable followups.
>
> IMHO.
>
> Garth
>
>
I don't think it was intended to troll, and Trans definitely understands
IEEE 754 floats. He just thinks Ruby should move beyond them.

Personally, I rarely ever use them, because of these issues. They are
unsuitable for more uses than they are suitable for, and they contradict
the idea that abstractions shouldn't leak implementation. OTOH, they're
fast and ubiquitous. So I'm not very opinionated either way, but I think
it's a discussion worth having.