axiom-developer
[Top][All Lists]
Advanced

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

[Axiom-developer] Re: conditionally defined functions


From: Martin Rubey
Subject: [Axiom-developer] Re: conditionally defined functions
Date: Mon, 20 Sep 2004 13:38:09 +0000

William Sit writes:
 > > In principle, this is not too difficult. However, there is a slight 
 > > subtlety:
 > > Currently not all domains that contain variables provide such a function, 
 > > in
 > > particular, FRAC does not. Instead, there is a package RF that provides 
 > > this
 > > functionality. Well, no problem:
 > > 
 > > * move the operation variables from RF and POLYCATQ to QFCAT :
 > > 
 > >     if S has variables: S -> List Symbol then
 > >       variables: % -> List Symbol
 > >       variables f ==
 > >          mymerge(variables(numer(f)), variables(denom(f)))
 > > 
 > > and add the following to UP and MPOLY :
 > > 
 > >     if R has variables: R -> List Symbol then
 > >       coerce(r:R):% ==
 > >         if member?(x, variables(r)) then
 > >           error "coefficient contains variable"
 > >         else coerce(r)$Rep
 > > 
 > 
 > If this works, it works wrongly, because this confuses the x in the inner
 > domain of a tower with the x in the outer domain of the tower. 

I don't understand what you mean with "wrongly". I'm aiming at the following: I
want that UP(x, FRAC POLY INT) or UP(x, EXPR INT) would be a rational function
(or expression) that is a polynomial in x. I tested the code above and it does
indeed "work" (in this sense).

 > Remember that the compiler distinguishes these already. So the condition

 >          member?(x, variables(r))

 > would always return false. 

No, it does not. (at least not in the tests I ran)

 > I don't know what you meant by "fishy". The code would not work at present
 > because I don't think you can consider a function as an attribute. 

Hmm, I think you can. The code above does so.

 > The problem you raised is one of what might be called dynamic signature, 
 > that is
 > the codomain depends on the input value. The Axiom compiler can handle this
 > partly, in a category/domain constructor's signature, but not on the function
 > level. 

Yes, that's what I think, too.

 > > So, in more general terms, here's my question:
 > > 
 > > Suppose you have a category A, taking as parameter a domain P and 
 > > providing an
 > > operation f: % -> P. Furthermore, you have a category (or a domain, a 
 > > package)
 > > B, taking as parameter a domain Q. Now you want to achieve the following:
 > > 
 > > If Q is a domain in A, provide a function g: % -> P, using f.
 > > 
 > > Of course, it is not possible to provide P as a parameter of B, since B 
 > > should
 > > also be defined for Q's that are not domains in A...
 > 
 > The way to handle this is to create a special version of B, which takes a 
 > domain
 > in A as parameter, together with parameters needed for A and construct the
 > special version using the general one. This is ok because the compiler can
 > handle dynamic signature on the category/domain constructor level.
 > 
 > BforA(P:Cat1, Q: A(P)): Cat2 == B(Q) with { g:%->P }
 > 
 > You can then add the function g without a problem. The moral is: Don't Ask, 
 > Just
 > Tell.

Great! gonna try this!

Martin





reply via email to

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