[REBOL] Re: RFC: Cross-language benchmark proposal
From: joel:neely:fedex at: 7-Nov-2002 13:39
Hi, Ladislav,
No, it's not kosher, for the same reason that this isn't:
>> ack-3m: func [m [integer!]] [2 ** (m + 3) - 3]
>> repeat i 8 [print [i ack-3m i]]
1 13
2 29
3 61
4 125
5 253
6 509
7 1021
8 2045
(see below).
Ladislav Mecir wrote:
> Romano's ACK works (or does it violate any of the principles?):
>
> ack: func [
> {by Romano Paolo Tenca}
> m [integer!] n [integer!]
> /local result
> ] [
> if m = 0 [return n + 1]
> if n = 0 [result: ack m - 1 1 return result]
> result: ack m n - 1
> ack m - 1 result
> ]
>
The above definition isn't "legal" according to the "same thing"
rule (in exactly the same way as the one below that I posted with
the disclaimer yesterday).
The point of the comparison is not to find another way to get the
equivalent result, but to see how long it takes for exactly the
same algorithm to produce the specified result. Both the ACK
above and my ACK5 below break the single compound expression
ack-func m - 1 ack-func m n - 1
into the sequence of simpler expressions
temp: ack-func m n - 1
ack-func m - 1 temp
which calls for slightly different (although functionally
equivalent) behavior. I think it's appropriate to avoid even the
smallest opportunity for someone to accuse us of cooking the
benchmark results (the old "Caesar's wife" principle).
I recall a case from a few years ago in which a compiler vendor
was accused of tweaking their optimizer to recognize certain
commonly-used benchmark expressions and do naughty things that
did not occur for other (normal) code.
ack5: func [m [integer!] n [integer!] /local result] [
max_depth: max max_depth curr_depth: curr_depth + 1
tot_evals: tot_evals + 1
if m = 0 [
curr_depth: curr_depth - 1
return n + 1
]
result: either n = 0 [
1
][
ack5 m n - 1
]
result: ack5 m - 1 result
curr_depth: curr_depth - 1
result
]
The whole point of including a task such as Ackermann would be to
compare/contrast performance on recursively-defined functions. We
can meet the same objective (without hitting implementation limits)
by using some other recursive function, such as:
fib: func [n [integer!]] [
either n < 2 [n][(fib n - 1) + fib n - 2]
]
I'd consider non-comparable any submission in which someone said
You can do IT faster using this function:
cheat: func [n [integer!] /local g] [
g: 2.23606797749979
to-integer (1.0 + g / 2.0 ** n) - (1.0 - g / 2.0 ** n) / g
]
That's not a *bad* approach, just a different one! ;-)
-jn-
--
----------------------------------------------------------------------
Joel Neely joelDOTneelyATfedexDOTcom 901-263-4446
