[Axiom-developer] Re: [Axiom-mail] Function returning UnivariateTaylorSeries

[Stephen Wilson]

Tim, Marcus, *

I've been trying to hunt this down, and am making slow progress
(learning how to use Axiom was a snap compared to learning how to hack
it;) 

The first question I tried to answer was `is the problem
introduced at the time of domain instantiation, or at compile
time?', Now I'm asking `is the problem introduced at compile time, or
during the interpreters coersion to OutputForm?'

I still dont know which end to look at, as what follows will
illustrate. 

Tim, any suggestions at all would be appreciated (suggestions which
turn out to be dead ends are just fine, since Im learning a lot).
Some of this might have to do with the database, which I know you have
written most (all?) of.

The database is being set to hold information which is, strictly
speeking, invalid for the Foo package, but the conflict is sometimes
resolved, sometimes not.  In particular, the OPERATIONALIST being
generated for the domain (which I think of at the mement as a mapping
from a constructor name to a list of export/signature pairs).

For me, this is a kicker:

--------------------------------------
-- prob.spad is Marcus's Foo package

   Re-reading browse.daase
(1) -> )lisp (setq |$DALYMODE| t)

Value = T
(1) -> )co prob.spad
       
       -- After compilation we can query the database

(1) -> (getdatabase '|Foo| 'OPERATIONALIST)

Value = ((|bar| (((|UnivariateTaylorSeries| |#1| |#2| 0)) 18)))


       -- Note here we have the signature (|UnivariateTaylorSeries|
       -- |#1| |#2| 0). I think |#1| |#2| are placeholders for the
       -- `functor' arguments of Foo, which will be filled in _after_
       -- the package is instantiated with some parameters. 
       --
       -- We have:

(1) -> P := Foo(POLY INT, new()$Symbol)

   (1)  Foo(Polynomial Integer,%A)
                                                                 Type: Domain
(2) -> (getdatabase '|Foo| 'OPERATIONALIST)

Value = ((|bar| (((|UnivariateTaylorSeries| |#1| |#2| 0)) 18)))
(2) -> bar()$P

 
   >> System error:
   Caught fatal error [memory may be damaged]

protected-symbol-warn called with (NIL)
(2) -> (getdatabase '|Foo| 'OPERATIONALIST)

Value = ((|$unique|) (|bar| (((|UnivariateTaylorSeries| |#1| |#2| 0))
18 T ELT)))

      -- Now the database has changed. My guess is caching.
      --
      -- Regardless, lets spoof the database query, giving the true
      -- polynomial zero:

(2) -> (setq -new-foo-alist '((|bar| (((|UnivariateTaylorSeries| |#1|
|#2| (0 . 0))) 18))))

Value = ((|bar| (((|UnivariateTaylorSeries| |#1| |#2| (0 . 0))) 18)))
(1) -> (setq -hide-gdbase #'getdatabase)

Value = #<compiled-function GETDATABASE>

(2) -> (defun getdatabase (con key) (if (and (eq con '|Foo|) (eq key
'OPERATIONALIST)) -new-foo-alist (funcall -hide-gdbase con key)))

Value = GETDATABASE
(2) -> bar()$P

               2     3     4     5     6     7     8     9     10
               11
   (2)  %A + %A  + %A  + %A  + %A  + %A  + %A  + %A  + %A  + %A   + O(%A  )
                        Type: UnivariateTaylorSeries(Polynomial Integer,%A,0)

-------------------------------------------------------------

I have a vague idea how the database queries are passed through the
interpreter during the problematic stage of coersion to OutputForm. 

However, I think a critical relationship is given by the following simple
trace.

Starting from a clean compile of Foo, no spooffed database lookups:

--------------------------------------------------------------

  -- |UnivariateTaylorSeries;| is the domain constructor for UTS

(2) -> (trace |UnivariateTaylorSeries;|)

Value = (|UnivariateTaylorSeries;|)

  -- |FOO;bar;Uts;1| is Foo's bar function.

(2) -> (trace |FOO;bar;Uts;1|)

Value = (|FOO;bar;Uts;1|)
(2) -> (trace |coerceInteractive|)

Value = (|coerceInteractive|)
(2) -> P := Foo(POLY INT, new()$Symbol) -- uninteresting traces generated

    
(3) -> bar()$P -- interesting

  1> (|FOO;bar;Uts;1| #<vector 086eae8c>)
    2> (|UnivariateTaylorSeries;| #<vector 08f9c150> %B (0 . 0))  <--- *** 
PROPER !
    <2 (|UnivariateTaylorSeries;| #<vector 086eaccc>)
  <1 (|FOO;bar;Uts;1| ((0 . 0) "NonNullStream" #<compiled-function
    |STREAM;gen!0|> . #<vector 086ead90>))
  1> (|coerceInteractive| ((|UnivariateTaylorSeries| (|Polynomial|
    (|Integer|)) %B 0) WRAPPED (0 . 0) "NonNullStream"
    #<compiled-function |STREAM;gen!0|> . #<vector 086ead90>)
    (|UnivariateTaylorSeries| (|Polynomial| (|Integer|)) %B 0))
  <1 (|coerceInteractive| ((|UnivariateTaylorSeries| (|Polynomial|
    (|Integer|)) %B 0) WRAPPED (0 . 0) "NonNullStream"
    #<compiled-function |STREAM;gen!0|> . #<vector 086ead90>))
  1> (|coerceInteractive| ((|UnivariateTaylorSeries| (|Polynomial|
    (|Integer|)) %B 0) WRAPPED (0 . 0) "NonNullStream"
    #<compiled-function |STREAM;gen!0|> . #<vector 086ead90>)
    (|UnivariateTaylorSeries| (|Polynomial| (|Integer|)) %B 0))
  <1 (|coerceInteractive| ((|UnivariateTaylorSeries| (|Polynomial|
    (|Integer|)) %B 0) WRAPPED (0 . 0) "NonNullStream"
    #<compiled-function |STREAM;gen!0|> . #<vector 086ead90>))

  1> (|coerceInteractive| ((|UnivariateTaylorSeries| (|Polynomial|
  (|Integer|)) %B 0) WRAPPED (0 . 0) "NonNullStream"
  #<compiled-function |STREAM;gen!0|> . #<vector 086ead90>)
  (|OutputForm|))
    2> (|UnivariateTaylorSeries;| #<vector 08f9c150> %B 0)   <--- *** IMPROPER !
    <2 (|UnivariateTaylorSeries;| #<vector 086eac94>)
 
   >> System error:
   Caught fatal error [memory may be damaged]

protected-symbol-warn called with (NIL)

--------------------------------------------------------------------            
      

Interestingly, if you redo the above, but with the database being
spoofed, you do not end up generating the impoper call of the UTS
constuctor |UnivariateTaylorSeries;| _at all_ during coercion to
output form. 

During compilation, since the zero in the Foo package is constant,
perhaps the database _should_ contain the `real' zero in the
operationalist. However, as the trace shows above, it is _possible_ to
find the correct zero with which to instantiate the UTS domain
(although the correct instantiation was generated by a function within
the domain, not from inside the interpreter).

So, if anything, could I get a suggestion as to where one would like
see the bug fixed? Of the two options I see available, perhaps one is
more proper when taking the system as a whole into consideration ( a
view which I lack, unfortunately).

Should we be trusting the database info as generated during compilation
to be correct, or should we beef up the interpreters coersion routines
to do the lookups?

I hope this is not all noise.

Sincerley,
Steve



On Sat, Nov 27, 2004 at 01:56:41PM -0500, root wrote:
> Stephen, Marcus,
> 
> I'll look into this further. Thanks for the analysis so far. --t