Author: James Swafford
Date: 16:18:40 05/29/04
Go up one level in this thread
On May 29, 2004 at 18:37:20, Sune Fischer wrote:
>On May 29, 2004 at 18:27:53, James Swafford wrote:
>
>>On May 29, 2004 at 17:47:02, Sune Fischer wrote:
>>
>>>On May 29, 2004 at 11:33:01, James Swafford wrote:
>>>>>
>>>>>How would you pass arguments to a function in an unevaluated state? Can you draw
>>>>>a stack frame showing exactly what would be done?
>>>>
>>>>The problem (well, Uri's problem) is the order in which the compiler
>>>>evaluates the expression tree. Think of 'printf' as a node in a tree
>>>>with the parameters as children.
>>>>
>>>>Apparently the children are evaluated first (bottom up), and since
>>>>they share memory, voila...
>>>>
>>>>I think printf could do something like:
>>>>
>>>>While (unevaluated parameter) {
>>>> evaluate parameter
>>>> copy results to buffer
>>>>}
>>>>print buffer
>>>>
>>>>Not as efficient, but it would work.
>>>>
>>>>Note I am _not_ saying it _should_ work this way!
>>>
>>>From what I understand the problem is not with printf, but in the way parameters
>>>are passed to functions in general.
>>>
>>>Eg. if I write F(3*x+4,0.6*y-2), then the program will first evaluate the
>>>argumens and _then_ pass them to the function, F.
>>>
>>>It is not possible for the compiler to replace that with two calls like F(3*x+4)
>>>and F(0.6*y-2), because the compiler can't possibly know if F can handle that.
>>>
>>>Printf is no exception I think, it gets treated like any other function in this
>>>respect.
>>
>>No... perhaps C can't do this because of the way the language is
>>defined, but you _can_ change the order in which expressions are
>>evaluated. Functional languages are good examples of how a
>>parameter might not get evaluated at all.
>
>I can't say I understand that.
>
>Look at it from the compilers point of view, F is a function with the prototype
>void F(float a, float b);
>
>The compiler must see to that the expressions get evaluated and stored in "a"
>and "b" so they are ready for internal use in F.
>
>In Uri's function it just turns out that "a" and "b" are actually two pointers
>which point to the same place and therefore the same result is passed twice.
Right..
>
>That's the danger of pointers and global memory (static behaves like global in
>this case). :)
No doubt...
>
>>Languages that do this use what's called 'lazy evaluation', or
>>'outside-in evaluation'.
>
>Never heard of it :)
You've seen lazy evaluation. What about conditional if's?
What if I had a tertiary function cond(a,b,c), that does
if(a) then b; else c;
Why compute a,b,and c? Just compute a and then determine
if you need to compute b or c. Braindead languages
like Visual Basic would compute b and c, but not C/C++, Java,
etc.
But...not all languages evaluate from the inside out.
What if I had a function f(x,y) ==> x + x + y.
Consider the parse tree for f(f(3,4),f(5,6)).
A bottom up,left to right evaluation would do:
f(f(3,4),f(5,6)) = f(3 + 3 + 4,f(5,6))
= f(10,f(5,6))
= f(10,5+5+6)
= f(10,16)
= 10 + 10 + 16
= 36
But.. what if I did an outside in evaluation?
f(f(3,4),f(5,6)) = f(3,4) + f(3,4) + f(5,6)
= (3+3+4) + f(3,4) + f(5,6)
= (3+3+4) + (3+3+4) + f(5,6)
= (3+3+4) + (3+3+4) + (5+5+6)
= 10 + 10 + 16
= 36
>How would a function like F work on arbitary equations passed to it?
I'm not sure... maybe that's an important distinction. :)
That and the fact that printf technically isn't a function.
--
James
>
>-S.
>>--
>>James
>>
>>
>>
>>>
>>>-S.
>>>>--
>>>>James
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.