[Axiom-developer] Re: [Axiom-math] [Fwd: Re: EXPR POLY INT]

[Martin Rubey]

William Sit writes:
 > Martin Rubey wrote:
 > >  > > (1) provide a possibility to get the "variable free" domain of a
 > >  > >     domain, i.e.,
 > >  > >
 > >  > > POLY INT, UP(x,POLY INT) both should yield INT
 > 
 > I disagree on this approach. First, mathematically, one can take a
 > polynomial extension of any integral domain (and then its quotient ring) and
 > the "new" variables should not be mixed up with elements of the integral
 > domain. Second, not only will your approach require a mechanism to obtain
 > the parameters of ANY constructor, but it will require further need to be
 > able to RECONSTRUCT one.  What would be your resulting domain for EXPR AN?
 > (AN is AlgebraicNumber, which is the algebraic closure of the field of
 > rational numbers. However, AN has EXPR INT as Rep which is NOT visible. At
 > this time, I am not able to get an example like the one on POLY--UP
 > interaction, because I do not follow the setup for AN (among lots of other
 > things). So may be there is no such bad interaction (afterall, AN
 > mathematically are just numbers!)

 > In any case, deciding the "field/domain of constants" in an Axiom domain
 > requires more than just examining the towers. This is a difficult problem in
 > differential Galois theory (for Picard Vessiot extensions): when does an
 > extension contain no new constants? An example is the (differential field) F
 > = Q(sin^2(x), sin(x)cos(x)), where Q is the field of rational numbers, x is
 > transcendental and differentiation is D= d/dx. F can be constructed as a
 > quadratic extension Q(y,z) of Q(y) where y is a transcendental and z^2 =
 > y(1-y), Dy = 2z. In this construction, y would be retractable to a symbol
 > and z may be a kernel. It takes some work to decide whether there are new
 > constants other than those in Q (whether there are or aren't is not
 > releveant to this discussion).  Now think about EXPR F. How would you
 > "simplify" this to using a general algorithm?

Hm. I see, I was thinking too "applied". My problem was the following: I have
some field domain F, and I want to build an expression over it (basically
containing sums and products). However axiom won't let me do this -- even if
the field has OrderedSet. So I thought, well, get a domain R such that EXPR R
contains F.

But I suppose that you're right...

 > >  > > (2) make the coercion to EXPR smarter and swallow all variables...
 > >  > >
 > >  > > I'm very unsure wether we should prefer (1) or (2), mainly because I
 > >  > > still don't understand the philosophy behind EXPR.
 > >  >
 > >  > Since POLY UP(x,INT) behaves similar to EXPR POLY INT, the former may
 > >  > be an easier target to "fix".
 > > 
 > > Yes. In fact, there is another possibility to consider. In (2) I suggested
 > > that all the variables in EXPR POLY INT should belong to EXPR. In fact,
 > > this was an accident. What I meant to say is
 > > 
 > >  (3) make the coercion to EXPR smarter and let its argument domain swallow
 > >  as many variables as possible.
 > > 
 > > I think that this would be more sound. However, my feeling is that (1) is
 > > the best way.
 > 
 > See above comment on (1). (3) will not work with EXPR POLY interaction
 > because both wants to include ALL of SYMBOL, but may work with EXPR DMP (but
 > not DMP EXPR). (3) may be difficult for EXPR F (F as above). I still think
 > separating the name spaces (like any good old compilers -- think C++) is a
 > reasonable approach. So each constructor gets its own name space by using a
 > prefix.  (Mathematica does this via what it calls "Context"). Coercion may
 > be done by switching prefix in addition to any data conversion (Rep
 > conversion). However, there are probably many many implications for this
 > line of thinking and I know very little about compilers. I wonder how Aldor
 > handles this type of issues.

In fact, it seems as though there were seperate namespaces at the moment, only
the user cannot distinguish them. In this sense, maybe were heading towards a
patch of output...


-------------------------------------------------------------------------------
 > >  > > Very briefly: I think we could characterize EXPR R by saying that it
 > >  > > is the space of functions whose variables are allowed to take values
 > >  > > in R or EXPR R. However, this is not quite complete: In which domain
 > >  > > are the numbers appearing in the expression?
 > >  > >
 > >  > > For example
 > >  > >
 > >  > > (7) -> 2.0*x^2*log(2*x)
 > >  > >
 > >  > >              2
 > >  > >    (7)  2.0 x log(2.0 x)
 > >  > >                                                 Type: Expression Float
 > >  > >
 > >  > > which is good, I believe. (Note that the square stayed square, not
 > >  > > power 2.0)
 > >  >
 > >  > But notice that the 2 in 2*x has to be coerced to Float even though
 > >  > Float has RetractableTo INT.
 > > 
 > > Hm? The above was an (unfortunately trivial) example to show that not all
 > > numbers in EXPR FLOAT are FLOAT, or, more generally, not all coefficients
 > > in EXPR R are from R. In fact, it seems as though exactly the powers are
 > > not.
 > 
 > Exponents are not coefficients and technically belongs to a different domain
 > from the coefficient domain in Axiom. Check the parameters for
 > PolynomialCategory. So sure, not all "numbers" in EXPR FLOAT are FLOAT: the
 > exponents aren't.

Thanks for the pointer. In fact, this is good news for me. Maybe it does make
sense to think about an alternative to EXPR after all.

 > > The following I'd consider as a bug:
 > > 
 > > (10) -> (x^%pi)::EXPR FLOAT
 > > 
 > >           3 6701487259+-+948881364
 > >    (10)  x           \|x
 > >                                                        Type: Expression 
 > > Float
 > 
 > I don't know what you mean by a bug here. I assume the answer is correct, but
 > there should be parenthesis that may make the display better. Axiom converts 
 > any
 > decimal number with fixed precision into a rational number and allows these 
 > as
 > exponents.

Sorry, my fault.
 > 
 > >  > > Are there domains with OrderedSet and IntegralDomain which are not
 > >  > > RetractableTo Integer?
 > > 
 > >  > An integral domain of characteristic zero is always retractable to 
 > > integer. On
 > >  > the other hand, one of characteristic non-zero will contain a prime 
 > > field which
 > >  > is not an ordered set in Axiom (PrimeField has ContractableTo Integer 
 > > and
 > >  > RetractableTo(%), not RetractableTo Integer).
 > > 
 > > Yes, but could you give an example? This would be great!
 > > 
 > > Martin
 > 
 > I thought my answer above meant there can be no such examples. Every domain 
 > in
 > Axiom belonging to OrderedSet and IntegralDomain will belong to RetractableTo
 > Integer.

Again: stupid me. Sorry. On the other hand: in combfunc.spad we have


CombinatorialFunction(R, F): Exports == Implementation where
  R: Join(OrderedSet, IntegralDomain)
  F: FunctionSpace R

...

  Z   ==> Integer

and quite a bit of code for R which is not RetractableTo Z, for example:

    number?(x:F):Boolean ==
      if R has RetractableTo(Z) then
        ground?(x) or
         ((retractIfCan(x)@Union(Fraction(Z),"failed")) case Fraction(Z))
      else
        ground?(x)

(also, more importantly: iidsum, iidprod, ...)

so it seems that Bronstein thought already about allowing R's which do not have
OrderedSet...

Well, for the moment I'm happy. (Although the header of my package looks a bit
crowded)

Martin