What does clisp do behind the scene if you give it (* 2 2 2)

[yesimthetaxman]

you can write (* (* 2 2) 2) or you can write (* 2 2 2)...

I am wondering what is happening behind the scenes when comparing the two.

If (* 2 2 2) is somehow converted to (* (* 2 2) 2), then that extra step used in the conversion would mean that technically it would take slightly longer for the CPU to compute right?

[yesimthetaxman]

just to add, I realize that operators like * are n-ary operators... but I am wondering specifically which one is "faster", or more efficient, aside from the argument that one is "easier to read" then the other...

[nuntius]

Don't worry about efficiency until you have a large program that runs too slowly...

A good compiler should produce the same speed code for (* x y z) and (* x (* y z)). Thus feel free to use whichever form looks better.

[yesimthetaxman]

well actually the reason I am wondering is not because I am worried about efficiency, its more of an argument. I lost marks on an assignment (an entire letter grade) because "there is a simpler solution"...

The question said: "compute 2^3"...

Anyways, I am arguing that his definition of what "simpler" is is rather ambiguous. does simpler mean an answer with the least characters? Because by that logic a much much simpler solution would have been:
>'8

or does simpler mean speed, or memory efficiency? If both answers are equivalent after the compiler has its way, then its a matter of style... not the solution itself.

Actually for the newcomer to LISP, I think my way makes more sense because in order to understand (* 2 2 2 2 2 2 2 2) you need to understand the theory of something like the reduce function. But (* (*2 2) 2) is rather easily understood after reading the first chapter of "Common LISPcraft". (* 2 2) is evaluated, then 2 is evaluated, then the outside is evaluated. It is easy to say (* 2 2 2) works, but after only reading chapter 1 it doesn't tie in with the basics.

[Duke]

If (* 2 2 2) is somehow converted to (* (* 2 2) 2), then that extra step used in the conversion would mean that technically it would take slightly longer for the CPU to compute right?

In SBCL, it actually does take a single extra operation to do (* a (* b c)) as compared to (* a b c). I'd assume CLISP adds at least as much overhead, given that SBCL is considered "better optimized" in general, but that's probably not what is meant by "simpler" in this context.

I'm not sure what IS meant by it, but maybe you were supposed to do an exponentiation function? That would be the smart answer, simplicity be damned.

[yesimthetaxman]

If (* 2 2 2) is somehow converted to (* (* 2 2) 2), then that extra step used in the conversion would mean that technically it would take slightly longer for the CPU to compute right?

In SBCL, it actually does take a single extra operation to do (* a (* b c)) as compared to (* a b c). I'd assume CLISP adds at least as much overhead, given that SBCL is considered "better optimized" in general, but that's probably not what is meant by "simpler" in this context.

I'm not sure what IS meant by it, but maybe you were supposed to do an exponentiation function? That would be the smart answer, simplicity be damned.

Well I don't think we were meant to do an exponentiation function because the posted solution was (* 2 2 2)... Basically the first lecture was administrative stuff, and the second lecture started with the basics of LISP, which was when we were given the assignment, which as you can see was relatively simple. I think that after only reading the basics of LISP, I was justified in assuming that (* 2 2 2) had more overhead then (* (* 2 2) 2), because I assumed that (* 2 2 2) had to be truncated somehow to (* (* 2 2) 2)... although now I know better

[saulgoode]

Anyways, I am arguing that his definition of what "simpler" is is rather ambiguous. does simpler mean an answer with the least characters? Because by that logic a much much simpler solution would have been:
>'8

or does simpler mean speed, or memory efficiency? If both answers are equivalent after the compiler has its way, then its a matter of style... not the solution itself.

My guess is that what was intended by "simpler" was the syntax trees representing the two expressions (that is, how the expressions were stored after reading, not worrying about eval at all).

The syntax tree for (* 2 2 2) would be (with 'v' representing a pointer/reference):

Code: Select all

[ * . v ]
    [ 2 . v ]
        [ 2 . v ]
            [ 2 . nil ]    

Whereas (* (* 2 2) 2) would be:

Code: Select all

[ * . v ]
    [ v         .           v ]
    [ * . v ]             [ 2 . nil]
        [ 2 . v ]
            [ 2 . nil]

[gugamilare]

In SBCL, it actually does take a single extra operation to do (* a (* b c)) as compared to (* a b c).

That is not the case if the code is compiled.

[Duke]

In SBCL, it actually does take a single extra operation to do (* a (* b c)) as compared to (* a b c).

That is not the case if the code is compiled.

This is off topic, but... when is the code ever not compiled in SBCL? Is there a circumstance where compiled-function-p returns nil?

[gugamilare]

This is off topic, but... when is the code ever not compiled in SBCL? Is there a circumstance where compiled-function-p returns nil?

I know the REPL is evaluated, not compiled, unless SBCL finds something it thinks it is better to compile. There is a way of changing SBCL to "evaluator mode" (I don't remember how) in which it does not compile anything unless explicitly told to, and, in this case, no function in the REPL is compiled.