language shoot-out :-)
[1/38] from: petr:krenzelok:trz:cz at: 3-Nov-2002 19:24
Hi,
I reread interview with DocKimbel and found following link to language
comparison page:
http://www.bagley.org/%7Edoug/shootout/
So those of you having enough free time or just simply interested could
rewrite some examples into Rebol to see, where do we stand ...
Here is matrix example roughly translated form Python to Rebol ...
(http://www.bagley.org/%7Edoug/shootout/bench/matrix/)
mkmatrix: func [rows cols][
count: 1
mx: array/initial reduce [rows cols] 0
for i 1 rows 1 [
for j 1 cols 1 [
poke mx/:i j count
count: count + 1
]
]
return mx
]
mmult: func [rows cols m1 m2][
m3: array/initial reduce [rows cols] 0
for i 1 rows 1 [
for j 1 cols 1 [
val: 0
for k 1 cols 1 [
val: val + (m1/:i/:k * m2/:k/:j)
poke m3/:i j val
]
]
]
return m3
]
mxprint: func [m][
for i 1 size 1 [
for j 1 size 1 [
print [m/:i/:j newline]
]
]
]
main: func [iter size][
m1: mkmatrix size size
m2: mkmatrix size size
for i 1 iter 1 [
mm: mmult size size m1 m2
]
print [mm/1/1 mm/3/4 mm/4/3 mm/5/5]
]
start: now/time/precise
main 1 30
print ["Result time:" now/time/precise - start]
... after finishing it though I returned back to the site, but results
are not expressed in time value on certain level CPU, so any kind of
comparison is useless probably ... maybe someone here uses Python and
wants to compare? :-)
-pekr-
[2/38] from: edanaii:cox at: 3-Nov-2002 12:24
Petr Krenzelok wrote:
> Hi,
>
> I reread interview with DocKimbel and found following link to language
> comparison page:
>
> http://www.bagley.org/%7Edoug/shootout/
>
Awe, man!
They stole my idea! :)
I was actually playing with the idea of making such a site. Glad someone
else did, now I can concentrate on my other one. :)
--
Sincerely, |
Ed Dana | Nearly all men can stand adversity, but if you
Software Developer | want to test a man's character, give him power.
1Ghz Athlon Amiga | -- Abraham Lincoln
[3/38] from: carl:s:rebol at: 3-Nov-2002 17:38
An idea: May want to use REBOL/Base for some of those benchmarks in the time and memory
usage.
At 11/3/02 12:24 PM -0700, you wrote:
[4/38] from: carl:s:rebol at: 3-Nov-2002 17:42
This is quite an interesting comparison... we should coordinate on the submission for
REBOL. Has anyone started working on it?
-Carl
At 11/3/02 05:38 PM -0800, you wrote:
[5/38] from: reffy:ulrich at: 3-Nov-2002 21:21
Can you say in english what these functions are doing?
Thanks,
Dick
[6/38] from: joel:neely:fedex at: 3-Nov-2002 22:05
Hi, Carl,
I started to work up REBOL versions to submit a while back; I got
frustrated when the ackermann blew up with stack overflow at 7
(the test calls for 8).
However, I'd be interested in contributing to seeing this through.
-jn-
Carl at REBOL wrote:
> This is quite an interesting comparison... we should coordinate
> on the submission for REBOL. Has anyone started working on it?
<<quoted lines omitted: 13>>
> > >>http://www.bagley.org/%7Edoug/shootout/
> > >>
--
; Joel Neely joeldotneelyatfedexdotcom
REBOL [] do [ do func [s] [ foreach [a b] s [prin b] ] sort/skip
do function [s] [t] [ t: "" foreach [a b] s [repend t [b a]] t ] {
| e s m!zauafBpcvekexEohthjJakwLrngohOqrlryRnsctdtiub} 2 ]
[7/38] from: tim:johnsons-web at: 3-Nov-2002 19:29
* Carl at REBOL <[carl--s--rebol--com]> [021103 16:59]:
> This is quite an interesting comparison... we should coordinate on the
> submission for REBOL. Has anyone started working on it?
<<quoted lines omitted: 3>>
> >and memory usage.
> >
Hey folks:
Here's my own language shoot-out.
I am the web programmer for winemarketjournal.com.
Extensive use of search engines is made there.
I'm a relatively experienced "C" programmer, and the
site was originally developed using C++ (compiled by
Borland for Windows NT), and a compiled-in-database
(native) manager.
I have completely converted the site using rebol with
DocKimbel's MySQL protocol running on a Linux server.
Now, we might suppose that C/C++ would outperform rebol.
And I'm sure that we would see that edge on specific
benches. However, the rebol-mysql combination at
winemarketjournal noticeably out-performs the original
C++-ISAM combination.
Why? Well not because rebol is faster, but because
using rebol's TCP sockets to make requests directly
from the MySQL monitor is faster.
What's more, code maintenance and new code development
is far and away more productive using rebol
Speed ain't necessarily what it's cracked up to be.
tim: [started life as an assembler programmer]
--
Tim Johnson <[tim--johnsons-web--com]>
http://www.alaska-internet-solutions.com
http://www.johnsons-web.com
[8/38] from: greggirwin:mindspring at: 3-Nov-2002 21:53
<< This is quite an interesting comparison... we should coordinate on the
submission for REBOL. Has anyone started working on it? >>
I remember looking at it shortly after I found REBOL, but didn't make a
start on anything. It also looks like the Win32 port of the shootout
(http://dada.perl.it/shootout/) might be more active at this point. Not sure
though.
Working the functions up shouldn't be too hard (at least the first few that
I examined and whacked up), but we'd have to read up on the rules of
implementation.
--Gregg
[9/38] from: edanaii:cox at: 3-Nov-2002 21:42
Is this new, or did I not notice it when I looked at the web-site this
morning?
======================================================================
Hi, the shootout is an unfinished project. I've decided to
discontinue updates to it for now while I work on some other
things. Thanks for everyone's help.
======================================================================
Which means that such a competition would not do REBOL much good.
So maybe I could still make my idea a go.
Let me pitch it, and see what everybody thinks.
First, a little background.
Presently, I'm learning Java and REBOL both. For entirely different
reasons. Professional survival, where Java is concerned, professional
curiosity for REBOL.
Previously, I had written a Basic routine I call RandomCopy. It was a
little utility that I used in the past to randomly pick my sig, or my
answering machine message. Fairly simple, it picked a file from a
directory and copied it to the target file/directory.
Recently, I rewrote it in Java. It took me a while to figure out. But
after much weeping and wailing and gnashing of teeth, I got it to work.
More recently, I wrote a REBOL version. I wrote it in about 1/4 the time
it took me to write the Java version. While not as readable as the Java
version, it was definitely more simple, elegant and in the final
analysis, easier to understand.
That's what started my thinking. While I have not quite decided about
REBOL yet, I'm pleased with it enough to think it deserves a chance.
Since this guy says he no longer supports the site (for the moment),
here's my pitch.
I wanted to work on a web-site that had to levels.
The first level would be a "how to" site. It would give programmers,
like myself, examples in how to accomplish things in a given programming
language. These examples would be simple, utilitarian tasks that could
be used, ultimately, in actual work.
The second level would be a forum, in which members could compare,
critique and vote on the best solutions. They could compare Java, REBOL
and any other language and rate its overall performance, tallying up the
winners.
Competitions would start by specifying an algorithm (in simple easy to
understand english, no nerd-speak). Programmers could then build
solutions to meet the challenge and then would be graded on how close
they could come to the actual algorithm, how easy the solution was to
understand, which was smaller in size, which was quicker in performance.
Now, like I said, I like REBOL, but I intended this site to be
objective. All solutions submitted to be judged equally and fairly. The
intention was to let any product prove itself on its own merits.
So, any thoughts?
Carl at REBOL wrote:
>This is quite an interesting comparison... we should coordinate on the submission for
REBOL. Has anyone started working on it?
>-Carl
<<quoted lines omitted: 13>>
>>>
>>>
--
Sincerely, | We're Human Beings, with the blood of a million
Ed Dana | savage years on our hands! But we can stop it! We
Software Developer | can admit we're killers, but we're not going to
1Ghz Athlon Amiga | kill today. That's all it takes! Knowing that we're
| not going to kill... Today! -- Star Trek.
[10/38] from: petr:krenzelok:trz:cz at: 4-Nov-2002 6:36
Ed Dana wrote:
> Is this new, or did I not notice it when I looked at the web-site this
> morning?
<<quoted lines omitted: 5>>
> Which means that such a competition would not do REBOL much good.
> So maybe I could still make my idea a go.
That's the question ... as Gregg pointed out, Windows version of the
site seems to be still active -
http://dada.perl.it/shootout/
The question is, if you should reinvent the wheel .... Maybe you could
concentrate upon another project, as wrapping some interesting library,
etc. Mozilla's XPCOM anyone? :-)
-pekr-
[11/38] from: petr:krenzelok:trz:cz at: 4-Nov-2002 6:38
Carl at REBOL wrote:
>An idea: May want to use REBOL/Base for some of those benchmarks in the time and memory
usage.
>
As for memore usage, I can understand it, but whould we suppose Base
should be any faster? Maybe it boots faster, but once booted, is there
really any difference in using Base vs Core?
-pekr-
[12/38] from: maarten:koopmans:surfnet:nl at: 4-Nov-2002 12:08
The website it is an *unfinished* project and discontinued. Too bad...
--Maarten
Carl at REBOL wrote:
> This is quite an interesting comparison... we should coordinate on the submission for
REBOL. Has anyone started working on it?
> -Carl
<<quoted lines omitted: 32>>
>>[rebol-request--rebol--com] with "unsubscribe" in the
>>subject, without the quotes.
--
Maarten Koopmans
Innovation manager tel: +31 30 2 305 324
SURFnet bv fax: +31 30 2 305 329
P.O.Box 19035 email: [maarten--koopmans--surfnet--nl]
NL-3501 DA Utrecht http://www.surfnet.nl
The netherlands
[13/38] from: gscottjones:mchsi at: 4-Nov-2002 6:31
From: "Carl at REBOL"
> This is quite an interesting comparison... we should
> coordinate on the submission for REBOL. Has
> anyone started working on it?
Like Gregg, I remember running across this site a while back. I recall that
the author had a bias against certain languages being included, and REBOL
was explicitly mentioned. See question 4 at:
http://www.bagley.org/~doug/shootout/faq.shtml
Of course, now that REBOL is wildly popular, maybe an exception will be made
once he starts republishing again. Perhaps the italian site author will be
more open to comparison, at least on the Win32 platform.
--Scott Jones
[14/38] from: carl:s:rebol at: 4-Nov-2002 11:40
Nicely stated. Thanks for making that point.
At 07:29 PM 11/3/02 -0900, you wrote:
[15/38] from: carl:s:rebol at: 4-Nov-2002 11:46
I think maybe the time has come to do our own Language Comparison pages.
I don't think we need to compare as many as bagley had, many of those are
not useful for comparison - just waste of time and space.
And by "our" I mean this list, not RT.
RT would be happy to sponsor the pages on a web server.
-Carl
At 06:31 AM 11/4/02 -0600, you wrote:
[16/38] from: carl:s:rebol at: 4-Nov-2002 11:39
How deep is the stack at 7?
At 10:05 PM 11/3/02 -0600, you wrote:
[17/38] from: edanaii:cox at: 4-Nov-2002 18:10
Petr Krenzelok wrote:
> The question is, if you should reinvent the wheel .... Maybe you could
> concentrate upon another project, as wrapping some interesting
> library, etc. Mozilla's XPCOM anyone? :-)
Yep. I've no desire to reinvent it.
But, of course, what I was thinking about doing was a little different
than the ShootOut. I was leaning towards an automated forum where
members can submit solutions, refine them and then vote on them.
--
Sincerely, | For long you live and high you fly.
Ed Dana | And smiles you'll give and tears you'll cry.
Software Developer | And all you touch and all you see,
1Ghz Athlon Amiga | Is all your life will ever be.
| -- Pink Floyd, Breathe.
[18/38] from: edanaii:cox at: 4-Nov-2002 19:13
Carl at REBOL wrote:
> I think maybe the time has come to do our own Language Comparison pages.
> I don't think we need to compare as many as bagley had, many of those are
> not useful for comparison - just waste of time and space.
>
Thinking about it further, competitors should be limitted to languages
that are truly cross-platform compatible. And that should be one of the
grading criteria; how well does it perform on different hardware.
This would remove a few contenders, including VB. :)
--
Sincerely, | For long you live and high you fly.
Ed Dana | And smiles you'll give and tears you'll cry.
Software Developer | And all you touch and all you see,
1Ghz Athlon Amiga | Is all your life will ever be.
| -- Pink Floyd, Breathe.
[19/38] from: reffy:ulrich at: 4-Nov-2002 20:51
I disagree with this. If I have 5,000 of the same platforms within my company,
I really am not interested (maybe) in how it performs on other hardware.
Dick
[20/38] from: rebologue:ya:hoo at: 4-Nov-2002 19:22
--- Ed Dana wrote:
> Thinking about it further, competitors should be
> limitted to languages that are truly cross-platform
> compatible.
?!?! This is shaky ground. Not a good idea, IMO.
> And that should be one of the grading
> criteria; how well does it perform on
> different hardware.
Now we're getting more complex. Our choice of hardware
configuration will inevitably be disputed and
challenged.
> This would remove a few contenders, including VB. :)
Wouldn't that defeat the purpose? By disqualifying
noteworthy contenders, we diminish broad-appeal of the
comparison.
We should impartially compare the benefits/features of
REBOL to other popular languages. If REBOL performs
well, it stands to attract potential new users. If
some of those new users are from VB (or RealBasic,
Basic, etc.), I'd consider that a far greater victory
than if we had disqualified those languages due to
impurity
.
// Ed
__________________________________________________
Do you Yahoo!?
HotJobs - Search new jobs daily now
http://hotjobs.yahoo.com/
[21/38] from: edanaii:cox at: 4-Nov-2002 21:21
Ed O'Connor wrote:
>--- Ed Dana wrote:
>>Thinking about it further, competitors should be
<<quoted lines omitted: 24>>
>than if we had disqualified those languages due to
>"impurity".
It was a suggestion, nothing more.
Carl was suggesting that such a competition should not have too many players. I agree.
Especially for the idea that I was playing with.
So I chose an arbitrary delimiter, one that I consider of critical importance in this
modern computing era.
This would limit the competition to the three main tools I'm interested in: Java, REBOL
and Eiffel.(There are others, of course).
But if you wanna include VB, why not?
If, however, you crack that door, then others may want to be let in, and then you have
the issue Carl was concerned about, lots and lots of comparisons, too much for most people
to absorb, and certainly too much for the poor bastard that has to maintain the site.
:)
Of course, another delimiter could be chosen too. Like maybe the 10 most popular languages
in the world. You might wanna be careful with that kind of choice, it could leave REBOL
out of the competition.
--
Sincerely, | We're Human Beings, with the blood of a million
Ed Dana | savage years on our hands! But we can stop it! We
Software Developer | can admit we're killers, but we're not going to
1Ghz Athlon Amiga | kill today. That's all it takes! Knowing that we're
| not going to kill... Today! -- Star Trek.
[22/38] from: edanaii:cox at: 4-Nov-2002 21:29
Remember, REBOL is about the X Internet. Cross platform compatibility is
a critical factor in proving its worth.
So is REBOL's main competitor, Java.
Also, few companies are homogenous. Yes, they have lots of PCs. Many
also have lots of Main Frames and Servers.
You want REBOL to shine. Then compete where it competes best...
[reffy--ulrich--net] wrote:
>I disagree with this. If I have 5,000 of the same platforms within my company,
>I really am not interested (maybe) in how it performs on other hardware.
<<quoted lines omitted: 24>>
>>
>Download NeoPlanet at http://www.neoplanet.com
--
Sincerely, | We're Human Beings, with the blood of a million
Ed Dana | savage years on our hands! But we can stop it! We
Software Developer | can admit we're killers, but we're not going to
1Ghz Athlon Amiga | kill today. That's all it takes! Knowing that we're
| not going to kill... Today! -- Star Trek.
[23/38] from: edanaii:cox at: 4-Nov-2002 21:26
Ed O'Connor wrote:
>--- Ed Dana wrote:
>>Thinking about it further, competitors should be
<<quoted lines omitted: 24>>
>than if we had disqualified those languages due to
>"impurity".
It was a thought, nothing more.
Carl was suggesting that such a competition should not have too many players. I agree.
Especially for the idea that I was playing with.
So I chose an arbitrary delimiter, one that I consider of critical importance in this
modern computing era.
This would limit the competition to the three main tools I'm interested in: Java, REBOL
and Eiffel.(There are others, of course).
But if you wanna include VB, why not?
If, however, you crack that door, then others may want to be let in, and then you have
the issue Carl was concerned about, lots and lots of programs, too much for most people
to absorb, and certainly too much for the poor bastard that has to maintain the site.
:)
Of course, another delimiter could be chosen too. Like maybe the 10 most popular languages
in the world. You might wanna be careful with that kind of choice, it could leave REBOL
out of the competition.
--
Sincerely, | We're Human Beings, with the blood of a million
Ed Dana | savage years on our hands! But we can stop it! We
Software Developer | can admit we're killers, but we're not going to
1Ghz Athlon Amiga | kill today. That's all it takes! Knowing that we're
| not going to kill... Today! -- Star Trek.
[24/38] from: tomc:darkwing:uoregon at: 4-Nov-2002 23:07
I would geuss ack 3 7 blows up close to where ack 3 8 does
%ack 3 8
...
323990
323991
323992
323993
323994
323995
** Internal Error: Stack overflow
** Near: ack (x - 1) 1
On Mon, 4 Nov 2002, Carl at REBOL wrote:
[25/38] from: janko:mind-nest at: 5-Nov-2002 9:34
>
> I disagree with this. If I have 5,000 of the same platforms within my
company,
> I really am not interested (maybe) in how it performs on other hardware.
>
> Dick
>
I don't wanth to argue... but I disagree with you... I almost don't have a
company
and have only 2 computers. But use Linux and Windows. I would feel stupid if
I had
to write same thing in two diferent ways or not being able to use something
I wrote half
of time.
Janko
[26/38] from: nitsch-lists:netcologne at: 5-Nov-2002 9:45
Am Dienstag, 5. November 2002 04:22 schrieb Ed O'Connor:
> --- Ed Dana wrote:
> > Thinking about it further, competitors should be
<<quoted lines omitted: 8>>
> challenged.
> > This would remove a few contenders, including VB. :)
could be based on machine price?
> Wouldn't that defeat the purpose? By disqualifying
> noteworthy contenders, we diminish broad-appeal of the
> comparison.
>
would also include real-world-competition.
important languages on important platforms.
hmm, more based on runtimes than languages,
so including flash etc.
> We should impartially compare the benefits/features of
> REBOL to other popular languages. If REBOL performs
<<quoted lines omitted: 4>>
> "impurity".
> // Ed
-volker
> __________________________________________________
> Do you Yahoo!?
sometimes, when iam happy. but with voice, not computer ;)
[27/38] from: joel:neely:fedex at: 5-Nov-2002 7:15
Hi, Tom,
Could you please post the code which you used to generate that
output? It doesn't match what I'm getting at all!
Here's my test harness ...
8<----------------------------------------------------------------------
ackermann: make object! [
curr_depth: max_depth: tot_evals: 0
ack: func [m [integer!] n [integer!] /local result] [
max_depth: max max_depth curr_depth: curr_depth + 1
tot_evals: tot_evals + 1
result: either m = 0 [
n + 1
][
either n = 0 [
ack m - 1 1
][
ack m - 1 ack m n - 1
]
]
curr_depth: curr_depth - 1
result
]
run: func [][
repeat i 8 [
curr_depth: max_depth: tot_evals: 0
if error? try [
print [i ack 3 i max_depth tot_evals]
][
print [
"Failure at depth" curr_depth "/" max_depth
"after" tot_evals
]
]
]
]
]
8<----------------------------------------------------------------------
... and I get these results ...
>> ackermann/run
1 13 15 106
2 29 31 541
3 61 63 2432
4 125 127 10307
5 253 255 42438
6 509 511 172233
Failure at depth 709 / 709 after 250362
Failure at depth 709 / 709 after 249577
(on w95, but YMMVDOP!)
-jn-
Tom Conlin wrote:
> I would geuss ack 3 7 blows up close to where ack 3 8 does
> %ack 3 8
<<quoted lines omitted: 10>>
> > How deep is the stack at 7?
> >
--
; Joel Neely joeldotneelyatfedexdotcom
REBOL [] do [ do func [s] [ foreach [a b] s [prin b] ] sort/skip
do function [s] [t] [ t: "" foreach [a b] s [repend t [b a]] t ] {
| e s m!zauafBpcvekexEohthjJakwLrngohOqrlryRnsctdtiub} 2 ]
[28/38] from: jan:skibinski:sympatico:ca at: 5-Nov-2002 9:38
[Joel Neely complained:
" I started to work up REBOL versions to submit a while back; I got
frustrated when the ackermann blew up with stack overflow at 7
(the test calls for 8)."
Carl at Rebol asked how deep the stack was,
then Tom Conlin wrote:
> I would geuss ack 3 7 blows up close to where ack 3 8 does
> %ack 3 8
<<quoted lines omitted: 7>>
> ** Internal Error: Stack overflow
> ** Near: ack (x - 1) 1
]
=============================================
Cheating and passing with flying colors:
{Ackerman function for m = 3}
a3: func[n][either n = 0 [5][2 ** (n + 2) + a3 (n - 1)]]
a3 8
== 2045
Jan
P.S. See the longer explanation below
==============================================
Well, the Ackerman function is a sick function, specificly
designed to defeat the tail recursion elimination..
But the problem is that sooner or later something will overflow
- not necessarily stack ... it can be a "number overflow"
- unless some Big Number library is used instead of floats.
One can easily sail by the dangerous waters of ack 3 7 by redesigning
the 'ack a bit:
a0: func[n][ n + 1] ; -- [1 2 3...
a1: func[n][ n + 2] ; -- [2 3 4..
a2: func n][2 * n + 3] ; -- [3 5 7 9..
a3: func[n][either n = 0 [5][2 ** (n + 2) + a3 (n - 1)]]
map :a3 ..[0 13]
== [5 13 29 61 125 253 509 1021 2045 4093 8189 16381 32765 65533]
a3 1020
== 8.98846567431158E+307
That's as far as we can go with 'a3 before we hit 2 ** 1023 limit.
But look how perverse ack becomes for m = 4; this has nothing to do
with the stack problem, but with the math overflow problem:
From recursive definition (in Haskell):
----------------------------
ack 0 n = n+1
ack m 0 = ack (m-1) 1
ack m n = ack (m-1) (ack m (n-1))
----------------------------------
Few first entries from a4 family:
ack 4 0 = ack 3 1 = 13 ; from the list produced above
ack 4 1 = ack 3 (ack 4 0) = ack 3 13 = 65533
ack 4 2 = ack 3 (ack 4 1) = ack 3 65533 ; $%^$^$!!!
.. And obviously it will blow up here: number overwflow
happens much sooner - for ack 3 1021
-------------------------------------------------------------
Do not be discouraged by Rebol's difficulties here. The first
two best performers in Ackerman category,
Ocaml and GHC (Glassgow Haskell Compiler) are specificly
well fitted for such tasks as tail recursion elimination.
But Haskell interpreter Hugs, a tool used for teaching and prototyping,
does not do much better than Rebol does:
> ack 3 6
509
> ack 3 7
1021
> ack 3 8
... I did not have enough patience to wait for the answer.
Jan
[29/38] from: joel:neely:fedex at: 5-Nov-2002 10:13
Hi, Jan,
Not complaining, exactly, just explaining why I hadn't already done
the benchmarking myself... ;-)
Jan Skibinski wrote:
> Well, the Ackerman function is a sick function, specificly
> designed to defeat the tail recursion elimination..
>
Please allow me to disagree slightly; the point here is just to see
how the different languages being stress tested handle deep recursion.
This is an exercise in language comparison, not in programmer work-
arounds, so modifying one or more of the tests to circumvent some
language-imposed limitation really *is* "cheating", as you put it.
To quote from the web page for the Ackermann test:
About this test
For this test, each program should be implemented in the same
way. (For this test, all solutions must use recursion as
specified below. For a number of languages other (iterative)
techniques may be much faster, but that would make it a
different test.)
Each program should implement the recursive version of
Ackermann's function illustrated below.
Ackermann's function is heavily recursive, and will really
stress a language's ability to do deep recursion.
Ergo the need to implement the function literally, and the concern
over the fact that there are fairly severe limitations to the depth
of REBOL's recursion.
FWIW, I've run into other programming situations doing "real work"
where I had to stop and redesign an algorithm because it ran into
this limit.
-jn-
--
----------------------------------------------------------------------
Joel Neely joelDOTneelyATfedexDOTcom 901-263-4446
[30/38] from: tomc:darkwing:uoregon at: 5-Nov-2002 9:44
Hi Joel
I was just counting function calls
Rebol[]
e: c
ack: func [ x[integer!] y[integer!] ][
print e: c + 1
either zero? x
[y + 1]
[either zero? y
[ack (x - 1) 1]
[ack (x - 1) ack x (y - 1)]
]
]
On Tue, 5 Nov 2002, Joel Neely wrote:
[31/38] from: jan:skibinski:sympatico:ca at: 5-Nov-2002 13:32
Joel,
> >
> > Well, the Ackerman function is a sick function, specificly
<<quoted lines omitted: 5>>
> arounds, so modifying one or more of the tests to circumvent some
> language-imposed limitation really *is* "cheating", as you put it.
Not to overheat the discussion.. take it easy.. I was obviously
teasing in part.
But I have some problems with Ackerman per se. As you must
have noticed from the second part of my previous post, any
language and any implementation must fail sooner or later
on ack 4 family. From this perspective this function is
"ill conditioned", or "singular" - as some matrices are.
Your statement "this is exercise in language comparison" is
not quite accurate: it looks like this is in fact an "exercise in
language implementation comparison". Case in question:
GHC vs. Hugs. Both use Haskell 98 (classical, frozen standard),
but GHC passes the Ackerman test just after Ocaml, while Hugs
probably not. Only people deeply involved with GHC know
exactly what sort of optimization the compiler is doing to
re-write the naive recursive code. But you obviously realize this
since you elaborate on this point a bit in another post.
I have known and watched the "shootout" page for more than
a year now. But frankly, I am not sure how useful it is due
to:
+ A purpose. What does it suppose to prove? Some languages
are good for some tasks, and bad for some other tasks.
+ Different implementations of the same language
(Haskell has three: GHC (GHCI), NHC, HUGS )
+ Missing tests (for example, there are six missing tests for Haskell)
+ Quality of submissions.
+ Choice of tests.
+ And probably many more...
There is quite interesting programming contest,
running within the framework of International Conference
on Functional Programming, ICFP. This year's contest page
is hosted by OGI, Oregon, US:
http://icfpcontest.cse.ogi.edu/
For several years, the winners were using mostly Ocaml, Haskell,
Cilk, etc. In past years the teams with imperative languages, such
as Java and C/C++ were doing very poorly. Python, Smalltalk, Ruby,
etc. were also way, way behind.
This year's theme was about simulated robotic games. The winner
was again an Ocaml team - this time from Japan. But this year,
the second place was taken by a C team (surprise, surprise!),
while most of the other functional teams simply failed.
There are many justifications and excuses for this, but the basic
question is this:
"Is it really about the languages or about a quality of participants
an a bit of luck?"
Regards,
Jan
[32/38] from: tomc:darkwing:uoregon at: 5-Nov-2002 10:16
woops! sorry bout that
those should all be either 'e or 'c
not a mixture (eval OR call)
Rebol[]
c: 0
ack: func [ x[integer!] y[integer!] ][
print c: c + 1
either zero? x
[y + 1]
[either zero? y
[ack (x - 1) 1]
[ack (x - 1) ack x (y - 1)]
]
]
On Tue, 5 Nov 2002, Tom Conlin wrote:
[33/38] from: joel:neely:fedex at: 5-Nov-2002 14:19
Hi, Jan,
> Your statement "this is exercise in language comparison" is
> not quite accurate: it looks like this is in fact an "exercise in
> language implementation comparison".
>
You're absolutely correct; I was being hasty/sloppy in my terms!
Jan Skibinski wrote:
> Not to overheat the discussion.. take it easy...
> I was obviously teasing in part.
>
The temperature's just fine; no worries! It's just that I've seen
a number of posts over the years (on this list and others) where
a bit of code is offered to demonstrate an idea (esp. a limitation)
and someone responds with "Here's how you could redesign your
demonstration to avoid that problem."
I have this absurd mental image of someone saying, "I want to
enter the Olympic swimming competition in the butterfly event;
but since I don't do the butterfly stroke so well, I'm going to
ride my motorcycle instead!" ;-)
> But I have some problems with Ackerman per se. As you must
> have noticed from the second part of my previous post, any
> language and any implementation must fail sooner or later
> on ack 4 family. From this perspective this function is
> "ill conditioned", or "singular" - as some matrices are.
>
Hmmmm... (You're talking to an old Math major here... ;-) We
call a matrix "singular" because *in*principle* its inverse is
not defined. That's different from saying that an evaluation of
a given *well*defined* function may require more memory or
precision than available on my computer for some arguments.
Ackermann just happens to be a function that runs up against
implementation limits quicker than most, but it isn't inherently
ill-defined or badly-behaved (just *very* hungry for cycles! ;-)
> I have known and watched the "shootout" page for more than
> a year now. But frankly, I am not sure how useful it is due
> to...
>
Interesting observations. I posted some possible "why/who" comments
re a REBOL-vs-X shootout a little while ago. There's also the case
of language junkies who are simply interested in seeing different
ways of doing things. But, as you point out, real benchmarks are
always performed using real implementations. At least it has the
benefit of allowing one to choose an implementation (when more than
one are available) or puts pressure on the keepers of the One True
Implementation (when only one is available) to improve performance
when their performance falls behind.
-jn-
--
----------------------------------------------------------------------
Joel Neely joelDOTneelyATfedexDOTcom 901-263-4446
[34/38] from: joel:neely:fedex at: 5-Nov-2002 14:39
Hi, Tom,
Just a suggestion...
Tom Conlin wrote:
> Rebol[]
> c: 0
<<quoted lines omitted: 4>>
> [either zero? y
> [ack (x - 1) 1]
[ack x - 1 1]
> [ack (x - 1) ack x (y - 1)]
[ack x - 1 ack a y - 1]
> ]
>
> ]
>
Parens take time. In the above cases, they are not needed for
control of precedence; the function will be faster without them
(about 3% by my QAD tests).
-jn-
--
----------------------------------------------------------------------
Joel Neely joelDOTneelyATfedexDOTcom 901-263-4446
[35/38] from: g:santilli:tiscalinet:it at: 5-Nov-2002 23:15
Hi Jan,
On Tuesday, November 5, 2002, 7:32:12 PM, you wrote:
JS> running within the framework of International Conference
JS> on Functional Programming, ICFP.
They refused to accept a REBOL submission in the past.
Regards,
Gabriele.
--
Gabriele Santilli <[g--santilli--tiscalinet--it]> -- REBOL Programmer
Amigan -- AGI L'Aquila -- REB: http://web.tiscali.it/rebol/index.r
[36/38] from: carl:s:rebol at: 5-Nov-2002 16:04
Thanks Jan for clearing that up. A good explanation.
-Carl
At 09:38 AM 11/5/02 -0500, Jan Skibinski wrote:
[37/38] from: jan:skibinski:sympatico:ca at: 5-Nov-2002 19:03
Hi Gabriele,
This will change, I am sure, as Rebol gains its deserved
recognition. The rules must have been also relaxed
in the last year or so. I do not recall who was in charge
in the previous years but the organizers of this year's contest
seem to me very open. Just take a look at the list of
entries. Ruby, for example, is also a newcomer.
Hey, there was even this joker:
" Cobol 4ever! (hehe, no... it's C, which I bet you don't think is
much better)"
Regards,
jan
Gabriele Santilli wrote:
[38/38] from: carl:s:rebol at: 5-Nov-2002 16:45
That's interesting. In the past we've been invited to many such
conferences. Give it another try, and explain a little more about the
semantics of REBOL. Most casual reviewers don't understand the depth of the
language. I think they brush it off when they see the little one line
examples that do something like send a web page as email, and they don't
look further. But, they should.
I believe that there are several PHD theses that could be done on
REBOL. For example, just one such topic might be the difference REBOL deep
lexical level datatyping makes on expression optimization...this is quite
noteworthy. It offers another dimension of implied expressions. Another
PHD thesis would be the idea of dialecting with merged data and code.
Several more.
-Carl
At 11:15 PM 11/5/02 +0100, you wrote:
Notes
- Quoted lines have been omitted from some messages.
View the message alone to see the lines that have been omitted