* Sam Steingold <s...@usa.net> | 1. Is this desire politically correct?
well, you wouldn't get a complaint from me. that's why NIL is there.
| 2. If it is, there should be a way to declare the variable's type. | How do I do that?
(or <whatever> null)
note that this won't buy you anything. you need to declare the type of the object _after_ you have determined that it is not NIL to get any performance benefits from the declarations.
| Also, do I understand correctly that my ANSI CL proposal about | (define-format-command #\= (lambda (stream obj atp colp &rest pars))) | is dead?
looks like it.
#:Erik -- God grant me serenity to accept the code I cannot change, courage to change the code I can, and wisdom to know the difference.
> note that this won't buy you anything. you need to declare the type of > the object _after_ you have determined that it is not NIL to get any > performance benefits from the declarations.
Depends on the compiler and the code. This bit of code:
* Raymond Toy | Depends on the compiler and the code. This bit of code: | | (defun tst (x) | (declare (type (or single-float null) x) (optimize (speed 3))) | (if x (sin x))) | | can call the C version of sin because the compiler knows that by then, | x must be a single-float.
but does any particular compiler do this?
(incidentally, C's sin is defined for double-floats.)
#:Erik -- God grant me serenity to accept the code I cannot change, courage to change the code I can, and wisdom to know the difference.
> * Raymond Toy > | Depends on the compiler and the code. This bit of code: > | > | (defun tst (x) > | (declare (type (or single-float null) x) (optimize (speed 3))) > | (if x (sin x))) > | > | can call the C version of sin because the compiler knows that by then, > | x must be a single-float.
> but does any particular compiler do this?
Oops!!!! I forgot to mention that CMUCL actually does this. Perhaps others do to, but CMUCL definitely can.
> (incidentally, C's sin is defined for double-floats.)
Yes. CMUCL coerces the single-float to double, calls sin, and coerces the result back to single-float in this case.
-- --------------------------------------------------------------------------- ----> Raymond Toy r...@mindspring.com http://www.mindspring.com/~rtoy
* Erik Naggum wrote: > (or <whatever> null) > note that this won't buy you anything. you need to declare the type of > the object _after_ you have determined that it is not NIL to get any > performance benefits from the declarations.
Not necessarily -- a compiler should be able to deal with this:
(declare (type (or my-good-type null) x)) (and x (do-something-needing-good-type x))
(and cmucl can actually do this kind of inference).
What is perhaps more interesting is that in fact you ought to be able to deal with things like this
(defun test-fadd (x y) (declare (type (or single-float null) x y)) (+ x y))
because you know enough about + to be able to insert suitable checks and then compile good code. CMUCL makes noises about being able to do this, although in the one I have (18a, sparc), it seems to have a bug in this particular case. The fixnum case works though.
In article <3098218620480...@naggum.no>, Erik Naggum <cle...@naggum.no> wrote: > * Raymond Toy > | Depends on the compiler and the code. This bit of code: > | > | (defun tst (x) > | (declare (type (or single-float null) x) (optimize (speed 3))) > | (if x (sin x))) > | > | can call the C version of sin because the compiler knows that by then, > | x must be a single-float.
The compiler would have do some fairly sophisticated type inference to determine that the argument to SIN was a SINGLE-FLOAT. Usually one uses:
(defun tst (x) (declare (optimize (speed 3))) (if x (sin (the single-float x))))
> What is perhaps more interesting is that in fact you ought to be able > to deal with things like this
> (defun test-fadd (x y) > (declare (type (or single-float null) x y)) > (+ x y))
> because you know enough about + to be able to insert suitable checks > and then compile good code. CMUCL makes noises about being able to do > this, although in the one I have (18a, sparc), it seems to have a bug > in this particular case. The fixnum case works though.
Hmm, my sparc version (post 18a development) this produces this, with (speed 3):
(compile 'test-fadd) Compiling LAMBDA (X Y):
In: LAMBDA (X Y) #'(LAMBDA (X Y) (DECLARE (TYPE # X Y) (OPTIMIZE # # #)) (BLOCK TEST-FADD (+ X Y))) Note: Doing float to pointer coercion (cost 13) to "<return value>".
And a check of the disassembly shows that it uses fadds to add the two numbers. The note is because it has to box up the float so it can return it.
