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.

Reply via email to