[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Axiom-developer] [#29 for i in 1..1 repeatprint(sin(i) :: Complex Float

From: anonymous
Subject: [Axiom-developer] [#29 for i in 1..1 repeatprint(sin(i) :: Complex Float)] (new)
Date: Tue, 18 Jan 2005 00:36:47 -0600

Vladimir Bondarenko wrote:
> -> for i in 1..1 repeat print(sin(i) :: Complex Float)
>    sin(1)

Hmm, we need to understand this a bit more:

for i in 1..1 repeat print(a:=sin(i)::Complex Float)
for i in 1..1 repeat print(a:=(sin(i)::Complex Float))

all give

0.8414709848 0789650665

At least that is a work-around.


for i in 1..1 repeat print((a:=sin(i))::Complex Float)


for i in 1..1 repeat (a:=sin(i); print(a::Complex Float))


print is from PrintPackage, which calls
print from OutputForm, which calls

but the problem lies in print inside a loop (any type, not just a for-loop). The
problem seems to be an interpreter problem in parsing. This is confirmed partly
by the following transcript.  When trying to code this as a package for the
compiler, it is not easy to figure out the sequence of functions to use to
coerce  sin(i) from EXPR INT to Complex Float. I finally found one way, but it
may not be what the interpreter is doing:

)abbrev package PRINTEST Printest
Printest: T==C where
  EXPR ==> Expression
  INT  ==> Integer
  CF   ==> Complex Float
  T == with
  C == add
       import EXPR INT
         for i in 1..k repeat 
           a:=sin(i::INT::Float::CF::EXPR CF)$(EXPR CF)
           print(retract(a)$(EXPR CF)@CF::OutputForm)

Of course it makes no difference whether a:= is eliminated or not. And this
works correctly. So my tentative conclusion is that the interpreter is "lazy" in
(1) to try to figure out this rather involved coercion sequence (Hey, I got it
to EXPR INT and I have no idea how to go further to Complex Float, I think it is
good enough ...:-), but in (2), it is somehow forced to work harder (Now you
want to save the result and I have to type the variable a, ok, ...). Is it a
bug? Don't know. There are limitations to the interpreter.

Tim: Do you know if there is a system limitation on the level of coercion the
interpreter will try before quitting? Can this be reset?

This example shows why a large percent of time (my low estimate is 70% and my
high is 90%) writing compiled code is spent on coercion. 

Now, there is still the question: why does this happen only inside a loop?
Can one tell more from the way the libraries are loaded (see attached
print.out)? Notice in print.out, even after foo(3) is executed, (2) still needs
to load another bunch of libraries. Why?

Start with a fresh session:
Note that neither Float nor Complex is loaded in (1), only in (2). More
surprisingly, UniversalSegment is also not loaded in (1). (it does not matter if
the segment is 1..1 or 1..3).

(1) -> for i in 1..3 repeat print(sin(i)::Complex Float)
                                                                   Type: Void
(2) -> for i in 1..3 repeat print(a:=sin(i)::Complex Float)
   0.8414709848 0789650665
   0.9092974268 256816954
   0.1411200080 598672221 + 0.3388131789 0172013563 E -20 %i
                                                                   Type: Void
(3) ->
forwarded from

reply via email to

[Prev in Thread] Current Thread [Next in Thread]