Greetings,
Thank you all for the help previously given. I have a couple more quick
questions:
* Is there a precedence problem with some arithmetic operators ?
* Is last call optimisation supported ?
To illustrate the first problem, note the two versions of the function
below:
hsumiA: func [n /local sum] [
sum: 0.0
repeat i n [sum: sum + 1.0 / i]
sum
]
hsumiB: func [n /local sum] [
sum: 0.0
repeat i n [sum: sum + (1.0 / i)]
sum
]
Calling each with the same argument results in different return values:
hsumiA 5 ==> 0.28333333333333
hsumiB 5 ==> 2.28333333333333
even though the precedence of the aritmetic division / operator is higher
than the addition operator, so the grouping used here:
sum + (1.0 / i)
would ordinarily be redundant, and be identical to:
sum + 1.0 / i
Clearly, though, there *is* a difference as evidenced by the different
return values. Would anyone care to clarify [or have I again missed
something obvious :)] ?
The other query concerns last call optimisation. Tail recursive versions of
the earlier functions:
hsumA: func [n a] [either n == 0 [a][hsum n - 1 a + 1.0 / n]]
hsumB: func [n a] [either n == 0 [a][hsum n - 1 a + (1.0 / n)]]
both fail when an argument of about 8000 is passed:
hsumB 8000 0.0
** Internal Error: Stack overflow
** Where: hsumB
** Near: hsumB n - 1 a
So my query is:
* Have I correctly implemented tail recursive versions of the
above functions, and, if so,
* Does this mean that last call optimisation is not implemented,
and that iterative rather tail recursive algorithms should be
preferred ?
Cheers,
Anthony Borla
P.S.
Is there a way of preventing the screen from being cleared when a result is
printed to the console ? Whilst this doesn't occur when working
interactively, it is an annoyance when used in shell scripts.
--
To unsubscribe from the list, just send an email to
lists at rebol.com with unsubscribe as the subject.