This patch tested OK, and I only have one small question:
Why define the macro 'mk_DF' instead of using 'make_DF' function?
- Qian
On 3/8/21 6:10 AM, Waldek Hebisch wrote:
On Sun, Mar 07, 2021 at 05:32:11PM +0100, Waldek Hebisch wrote:
I will look if I can quickly change Spad compiler to produce
something that causes no trouble to sbcl. If chaging Spad
compiler requires too much work, I would go with string
version.
I have now a patch that seem to work well. I am still testing
it, but on TMFORM sbcl reports 64M memory consed, which means
we should have no memory use prolems compiling TMFORM.
The patch "optimizes" constant coercion, if integer constant
is safely in SingleInteger ranges this constant is used as-is
(saving call to "coerce"). Similar thing is done for
coercion from Float to DoubleFloat: if Float is constant
it is converted to DoubleFloat at compile time. There
is extra twist: in context expecting DoubleFloat floating
point constant should now produce DoubleFloat (up to now
this was an error).
Anyway, I am attaching it if somebody wants to comment or
test it.
Note1: Size of SingleInteger is known only at Lisp compile
time, which may be later than Spad compilation and may
use different Lisp than Spad compilation, so we know if
integer fits into SingleInteger only at Lisp compile time
and in principle Lisp compiler may produce nonsense for out-of
range constants. That is why coercion was postponed to
runtime.
BTW: For TMFORM there is workaround at Spad level, namely
instead of code like
60::SI
one could use
qconvert(60)@SI
That skip call to 'coerce' (and corresponding size check).
--
You received this message because you are subscribed to the Google Groups "FriCAS -
computer algebra system" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/fricas-devel/60e7dd33-d12f-b8fb-66df-969c88f26799%40gmail.com.
