* Sam Steingold <···@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.
Erik Naggum <······@naggum.no> writes:
>
> (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.
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.
Ray
* 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.
Erik Naggum 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.
>
> 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 ····@mindspring.com
http://www.mindspring.com/~rtoy
In article <················@naggum.no>, Erik Naggum <······@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))))
or
(defun tst (x)
(declare (optimize (speed 3)))
(if x
(locally
(declare (type single-float x))
(sin x))))
> but does any particular compiler do this?
>
> (incidentally, C's sin is defined for double-floats.)
* 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.
--tim
Tim Bradshaw <···@aiai.ed.ac.uk> writes:
>
> 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.
Ray