On 9/26/05, Isaac Gouy <igouy / yahoo.com> wrote:
> Martin, perhaps you could collect this stuff and put it into your wiki
> page for future use?
>
> Austin Ziegler wrote:
> > On 9/26/05, Isaac Gouy <igouy / yahoo.com> wrote:
> > > Have you even looked at the website in the last 6 months?
> >
> > Yes. The text that makes a lie of everything you claim about the site
> > is still there on the front page, as of 26 September 2005 15.55 EDT.
>
> And that text would be?

Assuming that you actually care, look it up on the archives. The text
has not improved since the last time we talked about the alioth
shootout.

> > Further, the incorrect Ackermann result for Ruby (e.g., "error") is
> > still there (I've shown you at least four times how to fix that
> > problem -- and yet you still don't fix it -- and it has nothing to do
> > with the correctly implemented program, it has everything to do with
> > the test script). The default Perl program is still improper (Perl #4
> > is the only one that should be on the default list), Perl, Perl#2, and
> > Perl#3 all belong on the "interesting alternative implementations"
> > only. Indeed, the Python one still has a line of code that modifies
> > the same stuff as what Ruby requires you modify outside of the program
> > (where this properly belongs!). Without this line, *none* of the
> > Python runs works.
> Complaining that it's wrong for Python to provide functionality that
> allows the program to run is simply bizarre. The problem is that Ruby
> doesn't provide that functionality.

No, the problem is that you don't *run* the Ruby program with an
expanded stack size. Matz has chosen to not make this available within
Ruby. This is *not* a flaw. The problem is your test script, not the
Ruby script. You've been told this for nine months now.

> Perl#2 and Perl#3 are in alternatives - you're welcome to your opinion
> about the other Perl program.

Perl#4 is the only one that actually implements the function in a
readable and usable way. Perl (unlabeled) implements it in a way that
acknowledges that it's a cheat nearly as much as the two alternatives
(#2 and #3).

> > I pick on Ackermann, but the same flaws I pointed out in January ...
> > are still there.
> And the same limitations in Ruby's support for recursion are still
> there - as others on this list pointed out months ago.

Incorrect. With a *single* shell command, I can make the Ruby
Ackermann run perfectly (and, IIRC, better than the Python equivalent,
or at least to deeper recursion depths even with the Python language
"cheat"). This isn't undocumented; this has been mentioned to you
since January. It has *nothing* to do with the implementation of the
Ruby Ackermann, but the default stack size allocated to the Ruby
process. It's more restrictive under Windows, and that is probably a
compile-time option, but again -- it's *not* a Ruby problem. It's a
problem in your methodology and your assumptions. If you've screwed up
there, where *else* have you screwed up?

-austin
--
Austin Ziegler * halostatue / gmail.com
               * Alternate: austin / halostatue.ca