Earlier quoted context omitted.
I think you're remembering some papers from Dehnadi and Bornat, starting with http://www.eis.mdx.ac.uk/research/PhDArea/saeed/paper1.pdf
That looks like the paper I was thinking of. Thanks for including te link.
Can a simple algebra test predict programming aptitude?
211–216 of 216 posts
Re: Can a simple algebra test predict programming aptitude?
#212Earlier quoted context omitted.
> PS: Feel free to look for any counter example. Ok, create a loop equivalent for `(define (f g x) (g x))`.
x Though the mechanical equivalent would be something like: huge(input) { output, continue, current_function = f; do{ if (current_function == f) {input = x ; continue = true; current_function=g} if (current_function == g) { output = input; continue = false;} }while(continue); return output; } You would then add any function you would tail call optimize into that function. Granted, with the right structure (inside > o…
Mini-interpreter implementations do not count, for performance reasons. You could have called a VM bytecode interpreter loop a "loop alternative to tail call" here.
Re: Can a simple algebra test predict programming aptitude?
#213Earlier quoted context omitted.
x Though the mechanical equivalent would be something like: huge(input) { output, continue, current_function = f; do{ if (current_function == f) {input = x ; continue = true; current_function=g} if (current_function == g) { output = input; continue = false;} }while(continue); return output; } You would then add any function you would tail call optimize into that function. Granted, with the right structure (inside > o…
Mini-interpreter implementations do not count, for performance reasons. You could have called a VM bytecode interpreter loop a "loop alternative to tail call" here.
My first example of (f x) is about as fast as you can get.
The longer example is not great the point is it's a very language agnostic tradeoff of speed vs memory. Replace the ‘if’ conditionals with a case statement and its much faster you can speed it up further by using continue.
You can speed it up even more by having a jump at the end of each statement, but that stops looking like a loop and is basically just the tail call optimization.
Anyway, the important part is its low memory utilization and compiler independent.
PS: I in no way suggest tail call optimization was not useful; just you can mechanically simulate it when not available. You can usually beat that mechanical approach if you need to speed things up further.
Re: Can a simple algebra test predict programming aptitude?
#214Earlier quoted context omitted.
Mini-interpreter implementations do not count, for performance reasons. You could have called a VM bytecode interpreter loop a "loop alternative to tail call" here.
My first example of (f x) is about as fast as you can get. The longer example is not great the point is it's a very language agnostic tradeoff of speed vs memory. Replace the ‘if’ conditionals with a case statement and its much faster you can speed it up further by using continue. You can speed it up even more by having a jump at the end of each statement, but that stops looking like a loop and is basically just the…
> as fast as you can get.
But yet 10x slower than a single indirect jump.
> just you can mechanically simulate it when not available.
It's too slow to ever be anywhere near practical - for this reason, almost no JVM language implementation really does anything like this, besides kawa, bigloo and alike, which are slower than some of the dumb interpreters like SISC.
Re: Can a simple algebra test predict programming aptitude?
#215Earlier quoted context omitted.
My first example of (f x) is about as fast as you can get. The longer example is not great the point is it's a very language agnostic tradeoff of speed vs memory. Replace the ‘if’ conditionals with a case statement and its much faster you can speed it up further by using continue. You can speed it up even more by having a jump at the end of each statement, but that stops looking like a loop and is basically just the…
> as fast as you can get. But yet 10x slower than a single indirect jump. > just you can mechanically simulate it when not available. It's too slow to ever be anywhere near practical - for this reason, almost no JVM language implementation really does anything like this, besides kawa, bigloo and alike, which are slower than some of the dumb interpreters like SISC.
I don't think I was clear enough, it simplifies to zero code (not even a jump) just the original input. (I thought about saying noop but even that's wasteful.)
>"it's slow"
Again, it's just a technique; think writing embedded code with a really dumb compiler. Anyway, saying its slow is not really a counter argument if your limited to say 2,000 bytes of ram you will make lot's of tradeoffs between efficiency and speed. Perhaps you have a select statement perhaps you don't, but starting off with pure ASM is often a pain.
EDIT: This is all from the perspective of dealing with tools that don't do tail call optimization, not writing a compiler / VM etc.
Re: Can a simple algebra test predict programming aptitude?
#216Earlier quoted context omitted.
Being good at a set of abstract formal rules is probably at least some kind of indicator that you'll be good at another set of abstract formal rules.
Having recently taken a battery of psychological tests that measure several different cognitive functions, I am one living example that that is not the case.
How can you be an example that what I said "is not the case"? Are you saying that because you are not similarly good in two different sets of abstract formal systems, that this isn't a good indicator in general?