From: jzakiya <jzakiya@...>
Date: 2010-01-12T05:25:10+09:00
Subject: Re: fib.rb 1.9.1/1.8.6 source code conflicts/errors

> Regarding your point (2): the code you are referring to is in the
> benchmark/ directory, so I don't think the return value is important.
> After all, the code for the other languages is doing exactly the same.
>
> The "correct" version of the code is still in the sample/ directory.
>
> Looking at 'svn log', the benchmark directory found its way into trunk
> when YARV was merged in. There's no explanation of why the code used for
> benchmarking was slightly different to the fib sample code.

Thanks for tracking down the apparent source for this code.

> You can always raise a ticket on redmine.ruby-lang.org if you are
> unhappy about the algorithms used in the benchmarks, but it seems pretty
> trivial to me.

The 'solution' to this 'problem' is to change the erroneous coding to
a correct
one, or delete the file(s) (all the other incorrect language versions
too).

This is not a 'trivial' matter. It is a matter of mindset that is
troubling to me.

The Fibonacci series has been known, taught, and used for centuries.
It is not
a matter of speculation or ambiguities. Either you write an algorithm
to do it
correctly, or you are writing an algorithm to do some other series.

This lack of an apparent need to satisfy mathematical rigor is
troubling, and
potentially dangerous. You don't know who, and for what purpose,
someone will use
Ruby for, so it needs to be as well written, and accurate, as
possible.

I use Ruby in engineering, scientific, mathematical, and educational
fields. So
doing math to me matters. Doing it correctly matters. Other people use
Ruby in
these fields too, so it matters to them as well. See this one example
below:

http://www.artcompsci.org/kali/five-year-plan3.html

That's why these releases came out, to 'fix' a mistake in the coding
that allowed security related exploits to occur. Now, someone 'could'
say these mistakes are unlikely to cause any real harm, that they're
'trivial', but you don't allow these errors to exist when you find
them. You 'fix' them, and keep looking for others.

So, since we agree the code in question is 'wrong', it should be
corrected and/or discarded.