Vladimir Bondarenko wrote: axiom )set message autoload on axiom for i in 1..1 repeat print(sin(i) :: Complex Float) 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) Type: Void
axiom for i in 1..3 repeat print(a:=sin(i)::Complex Float) Type: Void
Hmm, we need to understand this a bit more: axiom for i in 1..1 repeat print(a:=sin(i)::Complex Float) Type: Void
axiom for i in 1..1 repeat print(a:=(sin(i)::Complex Float)) Type: Void
all give: 0.8414709848 0789650665 At least that is a workaround. But axiom for i in 1..1 repeat print((a:=sin(i))::Complex Float) Type: Void
axiom for i in 1..1 repeat (a:=sin(i); print(a::Complex Float)) 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 forloop). 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) Type: Void
axiom for i in 1..1 repeat print(exp(i) :: Complex Float) Type: Void
axiom for i in 1..1 repeat print(log(i) :: Complex Float) Type: Void
axiom for i in 1..1 repeat print(atan(i) :: Complex Float) 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) 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 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... ... kratt6, Fri, 28 Dec 2007 14:55:39 0800 reply Category: Axiom Mathematics => Axiom Interpreter
Status: closed => open
the bug with sin is still open Name:#29 for i in 1..1 repeatprint(sin(i) :: Complex Float) => #29 for i in 1..1 repeat print(sin(i) :: Complex Float)
Status: open => closed
