libera/#commonlisp - IRC Chatlog
Search
12:46:58
hayley
You might also want to consider inlining, in order to avoid boxing double-floats with current compilers.
12:47:23
_death
a similar idea is declared numerics (which don't coerce, just declare).. https://github.com/binghe/GBBopen/blob/master/source/tools/declared-numerics.lisp
13:01:05
lukego
hayley: current version is defining all the operators as macros so that should take care of the inlining angle, right?
13:03:43
lukego
(the whole idea here is to be a bit dumb i.e. for times when you want to be sure of how the compiled code will be but don't want to think too hard about your type declarations)
13:06:03
lukego
and maybe declarations are putting you on the path of getting runtime errors - or invalid results if safety is low - when type conversions might be more appropriate, especially on these fancy-pants wide-backended branch-predicting types of computers we're using these days
18:30:15
pve
Is one supposed to use (the double-float ...) or (coerce ... 'double-float) to tell the compiler what to expect?
18:34:43
mfiano
The former is a promise to the compiler, which is allowed to do nothing or anything.
18:35:05
lotuseater
hm i thought with THE it's more like a promise "this shall be that type" and with coerce an instruction "transforms this to the new type"
18:37:03
aeth
(the double-float x) is very, very, very close to (prog1 x (check-type x double-float))
18:38:03
aeth
SBCL doesn't. For DECLARE, DECLAIM, THE, etc., SBCL will use a faster CHECK-TYPE that is not recoverable.
18:39:31
aeth
What I mean is, (prog1 x (check-type x double-float)) in SBCL will let you supply a new x that satisfies double-float, while (the double-float x) will fail the program if it's not a double-float
20:24:45
pjb
pve: (the double-float x) (or (declare (type double-float x))) is actually more like: { int x; *(double*)&x=3.14d0; }
20:25:37
pjb
pve: (coerce x 'double-float) is more like {int x=314; (double)x; } this can be acceptable.