Most of things is covered in ANSI-TESTS anway, these are just smoke
tests for some functionality and taking into account internal
implementation details.
numlib is similar to math operation definitions in core but these
functions are implemented in C.
- refactor functions for code clarity
- add definitions for complex float
- add ffi implementation for long-float
- add ffi implementation for (complex float) types
- add compiler optimizations and definitions for complex float
We do not add c?float common constants (long-float i.e has optimizer
for 0.0 and -0.0), because we don't know if they are common at all and
if we think about it each would have four entries counting signed
zeros).
Also add informative comment about global-entries.
During printing we cons new floats for imag and real part. We could
opencode that but that would add a lot of code for a little gain. If
this proves to be a real bottleneck we will refactor float printing.
- _Complex long double is first cast to _Complex double (just like
long double) to avoid hashing non-meaningful bits
- We adhere to the "similarity" principle, that is sxhash -0.0 is the
same as sxhash 0.0.
equalp is delegated to ecl_number_equalp. we do not treat signed zero,
infinity nor nan.
float_eql is not the same as ==, because we have signed zeros and nan
values which should be compared memory-wise.
cl_type_of: give better results for (type-of <complex>)
Instead of simply returning complex we return:
(complex real)
when code is built without complex float support, and otherwise
(complex rational)
(complex single-float)
(complex double-float)
(complex long-float)
New functions:
- ecl_to_csfloat
- ecl_to_cdfloat
- ecl_to_clfloat
What has changed:
- new types si:complex-float, si:complex-single-float,
si:complex-double-float and si:complex-long-float
- new builtin classes long-float (for completness) and
si:complex-float
- new internal function si:complex-float and si:complex-float-p for
constructing complex floats (both arguments must be of the same
float type) and a type predicate
- printer for new types (right now it conses, see below)
- a new feature :complex-float
- a new type is recognized as a type disjoint of complex and real
- cleanup: +built-in-type-list+: remove some redundancy
For instance instread of saying
(real (or integer single-float double-float ratio))
We say
(real (or integer float ratio))
etc.
Flaws which will be fixed in upcoming commits:
- complex-float hierarchy is independent of the complex hierarchy
- ecl_make_complex_float could be replaced by _ecl_make_complex_*float
- write_complex_float allocates new objects for printing
- write_complex_float does print unreadable object
- math dispatchers doesn't recognize the object
Testing things out:
> (si:complex-float 0.0d0 0.0d0)
; #<CF(0.0d0 0.0d0)>
> (si:complex-float 0.0d0 0.0s0) ; signals type error
> (+ (si:complex-float 0.0d0 0.0d0) 1) ; signals type error
lisp runtime: make si_complex-float a subtype of a number.
Complex is a macro specified in complex.h for c99 to simplify using
_Complex type. This file also contains functions to work on complex
floats. To avoid conflicts we rename internal name complex to
gencomplex and update all references to it.
When the number of digits was not specified, we were sometimes
outputting a number that was exactly halfway between the exact value
and the next higher float. When reading that number in again, one
would get a different value due to rounding issues. Therefore, we now
always output enough digits, so that the number can be reconstructed
unambigously. Fixes#500.
We do not check for c99-mandated functions for long float (we only
check for the type). We also check for complex numbers in a separate
function and define ECL_COMPLEX_FLOAT when found.
TYPE= is only used from cmpopt's typep compiler macro which optimizes
atomic complex types by other means. Compound complex types are
handled differently for subtypep and typep (the first relies on
upgraded type and the second relies on the actual types), so we can't
rely in this case on SAFE-CANONICAL-TYPE.
This reverts commit 177ad215ea.
See #493. the issue with typecase must be resolved outside the
subtypep because these numbers indeed have the same internal
representation (see clhs entry for subtypep and typep).
Introduce a configure option controlling the installation and build
the documentation during the build instead of the install phase. Targets
for installation of the html version have also been added.
Fixes#482.
In expansions such as
(loop for i of-type some-type in some-list ...)
we were declaring the type of i to be some-type instead of the
correct (or null some-type).
Only disallow struct redefinition if we are certain about subtype
relationships in slots. Otherwise, we can wrongly disallow struct
redefinitions which don't change slot types.
This leads to compiled code checking types such as (complex
single-float) with a simple call to complexp. While this may
technically be allowed by the ANSI standard, since
upgraded-complex-part-type always returns 'real, it is very confusing
since for example typep correctly discriminates between different
complex part types.
See #468.
