[Axiom-developer] Re: Mixing up variables: (was Re: conditionally defined functions)

[Martin Rubey]

Dear William,

your point of view becomes clearer and clearer to me. I am nearly convinced :-)
In the following I'm only going to correct some apparent misunderstandings.

William Sit writes:
 > 
 > 
 > Martin Rubey wrote:

 > > every domain that has (named) variables should have a function vars: R ->
 > > List Symbol and isvar?: Symbol -> Boolean.
 > > 
 > > if any?(isvar?, vars(thing))
 > > 
 > > then thing cannnot be regarded as a coefficient.
 > 
 > But the two functions vars and isvar? are kind of available, perhaps not 
 > named
 > that way, but surely there are functions similar that serve the same 
 > purpose, if
 > all you want is to test whether a domain has "variables." 

The important thing would be that all these functions would have the same name
and modeline. Otherwise I cannot test for them. The closest match is the
function variables.

 > But I still do not see how the above test can rule out a construction like
 > EXPR EXPR INT.

It wouldn't. In fact, EXPR EXPR INT would not be forbidden, only, the
coefficient domain would not be allowed to contain any variables.

In fact, for EXPR EXPR INT, to clarify, lets denote this by EXPR COEFF, the
statement

if any?(isvar?, vars(thing))

should always return false, i.e., the situation that Axiom tries to coerce
something that contains a variable to COEFF should never happen. If it does, I
misunderstood the coercion process.

Thus, I do not propose to prevent the instantiation of domains. I only propose
to throw errors when Axiom is forced to do coercions that are not good.

 > > I do admit that to integrate SUP into this picture might be tricky.
 > > 
 > It sure would be. Even for the others, you have to make sure preventing
 > "illegal" towers will not break any code.

I suspect you misunderstood me: my proposal does not make any towers
"illegal". Hence, it would not break any (well written) code.

 > > As it now stands, the way to do things is simple: don't use towers of
 > > domains with variables. (One exeption is polynomials with coefficients
 > > that are expressions not containing variables: we have to use POLY EXPR
 > > INT here...)
 > 
 > That's a good example we have to be careful if we prohibit certain
 > towers. But that is not the only example.

Again: following my proposal, POLY EXPR INT would not be prohibited. Quite the
contrary!

 > > Do I understand correctly: You propose (roughly) that variables should
 > > carry a tag that tells which domain they belong to.
 > 
 > Yes. However, the tag is tied to the coefficient domain (which may have old
 > variables of its own), not the domain with (the new) variables. This
 > corresponds better to the mathematical notion of the "variables" ("algebraic
 > indeterminates" is the precise term) being algebraically independent over
 > the coefficient domain.

Good. If you rite up your proposal, maybe you could elaborate a bit on the
precise tagging. See below.

 > Let's say I am hunting for two polynomials f(x), g(x) and I know they
 > satisfy some algebraic relations with coefficents that are polynomials. The
 > polynomials expressing these algebraic relations would then be in POLY POLY
 > INT, such as
 > 
 > h = a(x) y^3 + b(x) z^2 - c(x) 
 > 
 > where a, b, c are in POLY INT, and y, z when substituted by f, g would give
 > zero. Mathematically, it would be natural to view h as in POLY POLY INT. Of
 > course, we know it would be better to use specified variables and work in
 > DMP([y,z], DMP(x, INT)), but we are talking about "lazy" users. Now, we CAN
 > carry out these computations in POLY INT alone, but the more natural setting
 > is POLY POLY INT

This is a nice example. I'd like to use it to raise an issue with your
proposal: suppose you have somehow generated h in POLY COEFF (where COEFF =
POLY INT, just to make it easier to talk about), such that y and z are
variables in POLY COEFF and a(x), b(x) and c(x) are coefficients, i.e., in
COEFF.

The question is, how to multiply to such POLY COEFF's ?

Suppose you ask for h*x. How would you instruct Axiom to understand the
multiplier x as an element of COEFF, and how would you instruct Axiom to
understand x as a variable in h?

)set mess scope on

h::(POLY POLY INT)*x::(POLY INT)

-> x$(POLY INT)*a(x)$(POLY INT) y$(POLY POLY INT)^3 ...

versus

h::(POLY POLY INT)*x::(POLY POLY INT)

-> x$(POLY POLY INT)*a(x)$(POLY INT) y$(POLY POLY INT)^3 ...

correct?

Following my approach, you couldn't be *that* lazy. You'd have to say

h::DMP([y,z], POLY INT).

I realize right now, that I didn't consider POLY UP(x, INT) yet... As my
proposal is formulated right now, the coefficient domain would not contain any
variables. That's might not be that good, since POLY FRAC UP(x, INT) might be
an interesting domain.

 > > For example: (x*y)::UP(x, POLY INT) should be OK, in my opinion. x would 
 > > be a
 > > variable of the outer domain, y a coefficient. No confusion can arise.
 > 
 > Yes, but you would disallow the prior use of x in POLY INT, which is where we
 > started! I would interpret, when a user uses UP(x, POLY INT), that (s)he 
 > wants a
 > new indeterminate x over POLY INT. 

I wouldn't, but I see your point.

 > I don't know the mechanics of how the interpreter handles ::. We have seen
 > it uses at least more than one way (that is, it may use coerce, convert, and
 > here, makeSUP). I often don't know what map is used since ")set mess bot on"
 > does not always give output on "simple" things like this. 

It would be really nice to have )set me bo on give output here too! I suspect
that the problem is that not all of the code is in the algebra, where I think
it should be.
 
 > > I agree that your proposal (if I understood it) is also clean.
 > 
 > Thanks. I probably wrote too much!

No. It is difficult to guess what I know or understand, and what needs
explaining. You did explain many things I knew, you did explain many things I
did not know...

 > > I meant to say: "put these checks into the algebra." This is clearly 
 > > possible.
 > 
 > Not clear to me at all! Perhaps I am missing the obvious. I believe it is
 > going to be a mess even if it is possible. It would be difficult to specify
 > precisely what towers are allowed or not. 

Yes.

 > I think we should allow all towers and variables should not be mixed (in any
 > solution) and it is easier to do so with tags than with tests.

Yes. However, we have to agree on one philosophy, I'm afraid. Would you be able
to write down as cleanly as possible the two proposals and add them add them at
the bottom of 

http://page.axiom-developer.org/zope/mathaction/WhereDoVariablesBelong

?

(Write a text file, click edit on the top right, paste, click save)

 > Tests are inefficient because it is a run-time penalty; 

True.

 > while tags, except at compile time, do not exert a penalty at all -- the
 > symbol hash table is the same, just the identifiers are longer.

True.

Martin