Ralf Hemmecke wrote:
>
> >> From what I know, SingleInteger (or MachineInteger in libaldor) need
> >> not (does not) have the same representation as Integer.
>
> > Abstractly need not (and AFAIK does not in Aldor -> C compiler), but
> > currently in Lisp backend SingleInteger is a subset of Integer.
>
> What is the trick to distinguish between SingleInteger and Integer in
> FriCAS. Looks like SingleInteger is just cosmetics. For example in
> SingleInteger we have
>
> x + y == add_SI(x, y)$Lisp
>
> where primitives.lisp defines
>
> (defmacro DEF_SI_BINOP (name op)
> `(defmacro ,name (x y) `(the fixnum (,',op (the fixnum ,x)
> (the fixnum ,y)))))
> (DEF_SI_BINOP |add_SI| +)
>
> What is (the fixnum ...) actually doing? Is it doing some conversion
> inside lisp or just pretending the given bit pattern is a 32/64 bit
> fixed size integer?
Thing are more subtle than you think. From point of view
of Lisp fixnum (our SingleInteger) is just a subrange of
integers. However, this subrange has special properties,
in particular it is supposed to have efficient
representation. Lisp puts tags on all values, so it can decide
at runtime if something is a fixnum or not and handle it
in appropriate way. '(the fixnum ...)' tells Lisp 'I am sure
that ... is a fixnum, do not bother to look at tags'. Sometimes
Lisp just trust that, sbcl at default safety settings still
checks. But even if sbcl inserts runtime checks, there is
huge preformance gain: without such promise Lisp must
consider all posiblities as valid. Since there are several
possibilities the code to handle all of them is too large
to expand inline, so Lisp performs such operations via
function calls. With promise that the result is a fixnum,
sbcl can treat all other possibilities as errors and
expand operations (possibly with checks) inline. Also
sbcl performs resoning of sort: "if arguments are fixnums
then result is a fixnum too" and normally is able to
remove large fraction of checks.
Note however, that while above I have written about tags,
this is just implementation detail. From high-level point
of view (the fixnum ...) just claim that integers stay
in appropriate range. It is up to Lisp implementation
to decide what implication this has for representation
if integers. In particular Lisp may decide to use
different representation that it would normally use
(inserting convertions if necessary).
> In a mathematical context, I actually would not like to see
> SingleInteger (which have a size depending on the architecture).
> What about a domain like IntegerRange(lower, upper) which would be
> implemented like
>
> IntegerRange(lower: Integer, upper: Integer): with ... ==
> if lower < minSingleInteger or upper > maxSingleInteger then
> Integer add
> Rep == Integer
> coerce(x: Integer): Rep == ...
> coerce(x: Rep): Integer == ...
> else
> SingleInteger add
> coerce(x: Integer): Rep == ...
> coerce(x: Rep): Integer == ...
>
> Wouldn't it be safer to give the expected range for the integers in
> question rather than using SingleInteger and relying on the fact that
> the program will never be executed on a machine where the SingleInteger
> representation is smaller then expected? I mean, SingleInteger should
> only be known to implement the above IntegerRange. All further uses
> should be with IntegerRange. Does that make sense to someone?
This is big topic which was approached in different ways in
various programing languages. IME using Pascal I found
range types of little use, others claim that they are
essential. For conreteness, important example of limited
range integres are array indices. In Lisp by definintion
of the language valid array index is a fixnum, so no
_fixed_ range would do while SingleInteger fits perfectly.
--
Waldek Hebisch
[email protected]
--
You received this message because you are subscribed to the Google Groups
"FriCAS - computer algebra system" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/fricas-devel?hl=en.
