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

[William Sit]

Hi Martin:

Martin Rubey wrote:

>  > 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.

Having the same function names and modeline of course simplifies the predicate.
What I meant was at the expense of a more complicated predicate, you can
currently make the same test without the new functions. But what you gain in the
(code) efficiency of the predicate, you pay for by adding the functions to
multiple domains.
 
>  > 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 my opinion, I think that (coefficient domain EXPR INT not allowed to have any
variables) is too drastic. Perhaps because of this view, I misunderstood you
intention was to forbid such towers through testing the presence of isvar? etc.

> 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.

Given that the test is categorically included in the constructor EXPR, if it
always return false for EXPR COEFF, it would also have to return false in COEFF
= EXPR INT. No? You did not specify where this "if" statement resides.

I don't know if there are any statement that will make Axiom coerce something
that contains a variable to COEFF, but I have shown you examples where a
variable is coerced into COEFF = POLY INT of SUP(COEFF). So yes, "it does," but
may be it still "should never happen." The "coercion process" is an entirely
interpreter process because it is trying to be "smart" for "lazy" users. I don't
understand how this is done (will have to ask Bob Sutor, or look at source
code). What I am (guess, we are) doing is observe what it does and trying to
infer how it does things. It may be what the Chinese call "the blind men feeling
an elephant." (which means each only gets part of the picture, depending on
where one place his hand).


> 
> 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.

Can you please explain step by step how the "if" line will be called into action
when  Axiom is so forced after a tower is instantiated?
 
>  > > 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.

My mistake. But you changed the semantics of the tower. Almost by definition,
any code that can be ambiguous/confusing to the reader is not well written. If
such code exists in the library, we should find them and rewrite them. Adding
code to prevent bad code is difficult, because you can never catch all of them.
(This reminds me of  programs that attempts catch students' math mistakes. The
programmers (me included) are never as ingenious as the students.)

>  > > 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
> 
> (1) h::(POLY POLY INT)*x::(POLY INT)
> 
> -> x$(POLY INT)*a(x)$(POLY INT) y$(POLY POLY INT)^3 ...
> 
> versus
> 
> (2) h::(POLY POLY INT)*x::(POLY POLY INT)
> 
> -> x$(POLY POLY INT)*a(x)$(POLY INT) y$(POLY POLY INT)^3 ...
> 
> correct?

I suppose you are asking how the interpreter can discern the meaning of h*x.
Under the tag proposal, x is already bound and tagged as x$(COEFF) by the prior
use of a(x): COEFF, and h: POLY COEFF is also bound (note that I am not using
::).  So h*x (not h:: POLY COEFF * x:: COEFF) has unambiguous meaning. If you
insist on using :: as given, then both coercions in (1) are unnecessary, and the
first coercion in (2) for h is unnecessary while the coercion x::POLY COEFF
would be the natural coercion (that is COEFF as subdomain of POLY, similiar to
saying 3::POLY INT); the multiplication would be the multiplication in POLY
COEFF, but since x is in COEFF, this is scalar multiplication (similar to 3*t in
POLY INT). In other words, both (1) and (2) produce same result and uses the
same scalar multiplication. The "scoped" output you gave for (2) is incorrect in
that the notation x$(POLY COEFF) means a (tagged) variable x of the outer POLY,
so it is a different x.

Perhaps if you change your question to simply how to coerce 'w, where 'w:Symbol,
to POLY COEFF and to COEFF, it would illustrate what is needed better (at least
one less confusion). (I'll drop the ' before w now, having made clear that w is
"virgin"). The solution is quite simple in fact (and you'll like this): having
all existing variables clearly tagged, we can assign a virgin symbol using your
outer rule! So

(3) w::POLY POLY INT
   -> w$(POLY COEFF)
(4) w::POLY INT
   -> w$COEFF
 
Of course, I am only using COEFF to clarify where w belongs. But this is really
not necessary because the way tags are *output* adopts your "outer" convention
in the sense that the variable always belong to the Varset of the outermost
domain (not that it "takes" from the inner domains). To avoid confusion, I will
refer to this as the "outer output" convention. *Internally*, w$COEFF may be a
concatenation of a hash for w and a hash for INT (as a variable over INT) and
w$(POLY COEFF) would be a concatenation of the hash for w and a hash for COEFF. 

Note that this method of tagging (to the coefficient domain and not the
polynomial ring) allows for "mixing" or lifting. If a user wants to have UP(w,
INT), that w would also be the *same* as the w in POLY INT and coercion between
the two domain is a breeze because in both case, it is actually the same symbol
(concatenation of hash for w and hash for INT). If the user wants UP(w, COEFF)
this w would be the same as the w in POLY COEFF. Again this is all natural when
we say, mathematically, let w be an indeterminate (or transcendental) over INT
-- mathematicians DON'T care which polynomial ring w belongs to! (too bad Axiom
cares). Just another example to clarify:

  w$(POLY COEFF)::UP(w, COEFF)   is perfectly ok.

  w$(POLY COEFF)::UP(w, INT)     is ok too 

(because w transcendental over COEFF=POLY INT is a fortiori transcendental over
INT)

  w$(POLY INT)::UP(w, COEFF)     becomes a ground element

 Note again: w$(POLY INT) is NOT w$(UP(w, COEFF)) because the transcendental w
over INT is not necessarily transcendental over COEFF=POLY INT --in fact in this
example, it belongs to COEFF.

> Following my approach, you couldn't be *that* lazy. You'd have to say
> 
> h::DMP([y,z], POLY INT).

Wouldn't you rather be lazier? :-)

> 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.

According to your "outer" rule, POLY UP(x, INT) would be the same as POLY INT,
and POLY FRAC UP(x, INT) would be POLY FRAC INT. So there would be no reason to
use the towers, except that the towers may be constructed "after the fact" (that
UP(x, INT) was already used in previous computations). This is exactly what I
meant by your rule, if implemented, would forbid prior use (though not the tower
itself).

>  > > 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.

What do you mean "I wouldn't"? Even under your approach, x is a new
indeterminate over POLY INT because POLY INT cannot contain x!

>  > 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 it is likely the interpreter has magic code, but I don't see how
such code be in the algebra (spad source). Because users are lazy, the
interpreter has to make the choice or guess the choice of which (often
overloaded) function the user wants. In the algebra code, you can't be lazy or
it won't compile! Sometimes I do wish the compiler gets some of the IQ from the
interpreter, it would have saved a lot of time -- when stuck with a problem on
coercion, I often go to the interpreter for help using )set mess bot on.

>  > > 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
> 

I visited your page and it is taken from your posts. However, we have posted
back and forth and as you said, comments cannot be taken out of context and in
email, we quote each other. I don't know how to do that in mathaction. 

I could be wrong, but my impression is that the attractiveness of mathaction
pages is that you can run live Axiom code and it is browser based. So I think it
is an ideal platform for documentation or summaries with examples, but a rather
poor platform for casual discussion. For example, one can only add comments at
the bottom, making it difficult to refer to lines or codes on the page. But even
if it becomes more fancy like MS Word, where you can insert comments anywhere,
the page would not be "clean". Despite the extra effort, in order that someone
not familiar with the issues can follow, the pages have to be tutorial in style.
And that takes rewriting.
I don't know how detail or how brief I should write (that is, who will be the
readers?)

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

I don't like text files and much prefer LaTeX to get pdf or dvi output. Lots of
text editors don't have good line breaks (or paragraph reflow) and arbitrarily
change them (like most email programs). Is text file the only choice?

The text file would have to include Axiom code fragments as examples. I don't
know how to get "live" axiom with mathaction, the way your pages look.

Well, I think this is truely a joint effort and fruitful discussion. I wouldn't
have thought of the problem (or proposal) if you didn't raise it. So, thanks.

 
William