login  home  contents  what's new  discussion  bug reports     help  links  subscribe  changes  refresh  edit

Edit detail for #29 for i in 1..1 repeat print(sin(i) :: Complex Float) revision 1 of 3

1 2 3
Editor: kratt6
Time: 2007/12/28 14:55:46 GMT-8
Note:

changed:
-
Vladimir Bondarenko wrote:

\begin{axiom}
)set message autoload on
\end{axiom}

\begin{axiom}
for i in 1..1 repeat print(sin(i) :: Complex Float)
\end{axiom}

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).

\begin{axiom}
for i in 1..3 repeat print(sin(i)::Complex Float)
for i in 1..3 repeat print(a:=sin(i)::Complex Float)
\end{axiom}

Hmm, we need to understand this a bit more:

\begin{axiom}
for i in 1..1 repeat print(a:=sin(i)::Complex Float)
for i in 1..1 repeat print(a:=(sin(i)::Complex Float))
\end{axiom}

all give::

  0.8414709848 0789650665

At least that is a work-around.

But 

\begin{axiom}
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))
\end{axiom}

Gives:

sin(1)

print is from PrintPackage, which calls
print from OutputForm, which calls
mathprint\$Lisp

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::

 --%Printest
 )abbrev package PRINTEST Printest
 Printest: T==C where
   EXPR ==> Expression
   INT  ==> Integer
   CF   ==> Complex Float
   T == with
        foo:PositiveInteger->Void
   C == add
        import EXPR INT
        foo(k)==
          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?


William


The comments below turned out to be in error:

\begin{axiom}
for i in 1..1 repeat print(sqrt(i) :: Complex Float)
for i in 1..1 repeat print(exp(i) :: Complex Float)
for i in 1..1 repeat print(log(i) :: Complex Float)
for i in 1..1 repeat print(atan(i) :: Complex Float)
\end{axiom}

I'd say that it's a bug. A workaround (not a fix...) is to say

\begin{axiom}
for i in 1..1 repeat print(sqrt(i) @ Complex Float)
\end{axiom}

It is quite clear that Axioms behaviour will be the same for all operators
(defined in op.spad).

Tracing the call with

\begin{axiom}
)set message bottom on
for i in 1..3 repeat print((sin(i))::Complex Float)
\end{axiom}


which looks quite strange: Axiom is looking for a function print with argument
of type Complex Float, but the thing it prints is not of this type...



From kratt6 Fri Dec 28 14:55:39 -0800 2007
From: kratt6
Date: Fri, 28 Dec 2007 14:55:39 -0800
Subject: 
Message-ID: <20071228145539-0800@axiom-wiki.newsynthesis.org>

Category: Axiom Mathematics => Axiom Interpreter 
Status: closed => open 

the bug with sin is still open

Submitted by : (unknown) at: 2007-11-17T22:23:18-08:00 (16 years ago)
Name :
Axiom Version :
Category : Severity : Status :
Optional subject :  
Optional comment :

Vladimir Bondarenko wrote:

axiom
)set message autoload on

axiom
for i in 1..1 repeat print(sin(i) :: Complex Float) sin(1)
Type: Void

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).

axiom
for i in 1..3 repeat print(sin(i)::Complex Float) sin(1) sin(2) sin(3)
Type: Void
axiom
for i in 1..3 repeat print(a:=sin(i)::Complex Float) 0.8414709848 0789650665 0.9092974268 256816954 0.1411200080 598672221
Type: Void

Hmm, we need to understand this a bit more:

axiom
for i in 1..1 repeat print(a:=sin(i)::Complex Float) 0.8414709848 0789650665
Type: Void
axiom
for i in 1..1 repeat print(a:=(sin(i)::Complex Float)) 0.8414709848 0789650665
Type: Void

all give:

  0.8414709848 0789650665

At least that is a work-around.

But

axiom
for i in 1..1 repeat print((a:=sin(i))::Complex Float) 0.8414709848 0789650665
Type: Void
axiom
for i in 1..1 repeat (a:=sin(i); print(a::Complex Float)) sin(1)
Type: Void

Gives:

sin(1)

print is from PrintPackage?, which calls print from OutputForm?, which calls mathprint$Lisp

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:

 --%Printest
 )abbrev package PRINTEST Printest
 Printest: T==C where
   EXPR ==> Expression
   INT  ==> Integer
   CF   ==> Complex Float
   T == with
        foo:PositiveInteger->Void
   C == add
        import EXPR INT
        foo(k)==
          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?

William

The comments below turned out to be in error:

axiom
for i in 1..1 repeat print(sqrt(i) :: Complex Float) 1
Type: Void
axiom
for i in 1..1 repeat print(exp(i) :: Complex Float) %e
Type: Void
axiom
for i in 1..1 repeat print(log(i) :: Complex Float) 0
Type: Void
axiom
for i in 1..1 repeat print(atan(i) :: Complex Float) %pi --- 4
Type: Void

I'd say that it's a bug. A workaround (not a fix...) is to say

axiom
for i in 1..1 repeat print(sqrt(i) @ Complex Float) 1.0
Type: Void

It is quite clear that Axioms behaviour will be the same for all operators (defined in op.spad).

Tracing the call with

axiom
)set message bottom on for i in 1..3 repeat print((sin(i))::Complex Float) Function Selection for sin Arguments: PI [1] signature: EXPR INT -> EXPR INT implemented: slot $$ from EXPR INT Function Selection for print Arguments: COMPLEX FLOAT [1] signature: OUTFORM -> VOID implemented: slot (Void)(OutputForm) from PRINT sin(1) sin(2) sin(3)
Type: Void

which looks quite strange: Axiom is looking for a function print with argument of type Complex Float, but the thing it prints is not of this type...

Category: Axiom Mathematics => Axiom Interpreter Status: closed => open

the bug with sin is still open