The axiom command:

axiom

x^1 abc[y]

(1)

Type: Fraction(Polynomial(Integer))

does not produce any syntax error while

axiom

x abc[y]

   There are no library operations named x 
      Use HyperDoc Browse or issue
                                 )what op x
      to learn if there is any operation containing " x " in its name.

   Cannot find a definition or applicable library operation named x 
      with argument type(s) 
                                   Symbol

      Perhaps you should use "@" to indicate the required return type, 
      or "$" to specify which version of the function you need.

does produce an error message.

It seems that 1 abc[y] is parsed as something unusual

axiom

1 abc[y]

(2)

Type: UnivariatePolynomial(*01abc(y),Integer)

What is Type: UnivariatePolynomial(*01abc y,Integer)?

To explain this, you have to understand several syntax conventions in Axiom. When two expressions are separated by a space, it means "apply" as in f x meaning f(x). Exactly what "apply" does depends on f and x. When f is a symbol and x is a list, this application produces a subscripted symbol. Also "apply" has higher precedence than any other operation. Finally, a subscripted symbol cd when displayed on the Type info line is written as *01c d.

So abc[y] is the same as abc [y] (because clearly the left '[' terminates the symbol abc) and so this is a subscripted symbol abcy.

axiom

abc [y]

(3)

Type: Symbol

axiom

x [1,2,3]

(4)

Type: Symbol

Now if b is a symbol, then 1 b is 1 applied to b. Axiom tries to find what operation this application is, and finds one in UP(b,INT) where the application means evaluate the element 1::UP(b,INT) as a function at the value b (substitution), which gives 1.

axiom

1 (b::Symbol)

(5)

Type: UnivariatePolynomial(b,Integer)

This is the same as

axiom

elt(1::UP(b,INT),b::UP(b,INT))$UP(b,INT)

(6)

Type: UnivariatePolynomial(b,Integer)

The results reported above are therefore all obtained by the these rules. The input 'x abc[y]' produces an error because this apply can only take place in UP (the fact that UP has only one variable makes the substitution unambiguous) and although it actually makes sense under suitable domains, the interpreter is not smart enough to find it.

axiom

(x::UP(x, POLY INT)) (b::UP(x, POLY INT))

(7)

Type: UnivariatePolynomial(x,Polynomial(Integer))

and actually, the construction UP(x, POLY INT) is not kosher, but somehow the extra parentheses helped.

axiom

x::UP(x, POLY INT) b::UP(x, POLY INT)

   There are no library operations named Type 
      Use HyperDoc Browse or issue
                                )what op Type
      to learn if there is any operation containing " Type " in its 
      name.

   Cannot find application of object of type Type to argument(s) of 
      type(s) 
                                 Variable(b)

Not a syntax error

Thu, 17 Feb 2005 06:09:33 -0600 reply

Second, it is clear from the original description that it is "not a syntax error". The bug report said: "should be a syntax error". So maybe you mean "should not be a syntax error"?

Third most of your "explanation" is quite easy to find in the Axiom book (see page 818)

"Univariate polynomials can also be used as if they were functions."

but the fact that abc[y]? when appearing in a Type is displayed as *01abc y is not described anywhere. This notation is especially odd since it is not a valid input form. So perhaps you might have proposed to change the category of this issue to Axiom Documentation and leave the status Open?

But I am not at all convinced that Axiom should behave in this strange manner. The idea that:

  1 x[k]

is the unit of the domain of univariate polynomials over the variable x[k]? is extraordinarily obscure and does not seem to have any obvious application to me. Further the fact that:

  1 x

is not defined (because the type of x is of type *Variable x and not Symbol and for some reason the interpreter does not consider the obvious coercion of x to Symbol while something more complicated like 'x[k]?' is of type Symbol by defautl) is at best very awkward and bordering on the bizarre.

I am not sure whether to blame the interpreter (which is apparently only following a fairly well defined search strategy) or perhaps better to blame the implementation of UnivariatePolynomial for allowing this form of abbreviated composition of polynomials (which I think should be seen as at best idiosyncratic) as something so ubiquitous in Axiom as function application. I think there are very good reasons to distinguish polynomials and expressions in general from functions (i.e. the lambda abstraction).

First, I find it rather annoying that the Status was changed by an anonymous user to closed without further discussion. Maybe I would agree with a status of pending but I think it would at least be courteous to identify oneself by clicking preferences before changing a status. That way at least I know who to blame. ;) Maybe we should make it so that a user id must be specified in order to click the Change button?

Sorry, Bill. I was too hasty in closing it. But I don't see why anyone should be "annoyed". If you don't think it is right, just change it back to "open". Isn't that the reason for Wiki?

By the way, I did look all over to find where to login

I advocated that --but putting it under "preference" does not ring a bell (neither would "user options"). Login and setting preferences are two distinct functions that should not be put under one button. Preferences should be set once when one registers, but login should done each time.

Second, it was clear from the original description that it is not a syntax error. The bug report said: should be a syntax error. So maybe you mean should not be a syntax error?

Third most of your "explanation" is quite easy to find in the Axiom book (see page 818)

"Univariate polynomials can also be used as if they were functions."

I was at first very puzzled by how the outputs in the original post are obtained. Perhaps if whoever posted it knew how the outputs came about, that should be included in the post so others do not have to waste time figuring that out. I interpreted the heading (ok wrongly) as some of the expressions have syntax error. I figured that they do not. Rather, it is the inability of the interpreter to coerce some parameters to the "correct" type and find a reasonable signature. But this is nothing new and short of analyzing the interpreter code to make it even smarter, what can we do in the meantime? That is why I thought "case closed".

but the fact that abd[y]? when appearing in a Type is displayed as *01abc y is not described anywhere. This notation is especially odd since it is not a valid input form. So perhaps you might have proposed to change the category of this issue to Axiom Documentation and leave the status Open?

I disagree with your objection to *01abc y in the output message. Sure, it would be better to be able to display that as a subscripted symbol, but this is merely a device to make outputting a subscript on a line-oriented device easier. Output in most cases cannot be fed back as input (that is on the wish list). This is not part of the Axiom language, just as how TeXForm? is coded is not part of Axiom.

On the otherhand, one can use easily

t:=1 x[y[z]]

(8)

dom:=typeOf t

UnivariatePolynomial}\ } ( 01 x ( 01 y (z)) , \hbox{\axiomType{Integer}\ })" class="equation" src="images/3421699712761778963-16.0px.png" align="bottom" Style="vertical-align:text-bottom" width="352" height="18"/>

(9)

h:dom:=monomial(2,3)

(10)

In fact, precisely because Axiom wants to preserve this structural information on the variable that it outputs it this way! Had it used a two dimensional method, it would not be able recapture the type information.

But I am not at all convinced that Axiom should behave in this strange manner. The idea that:

  1 x[k]

is the unit of the domain of univariate polynomials over the variable x[k]? is extraordinarily obscure and does not seem to have any obvious application to me. Further the fact that:

  1 x

is not defined (because the type of x is of type *Variable x and not Symbol and for some reason the interpreter does not consider the obvious coercion of x to Symbol while something more complicated like 'x[k]?' is of type Symbol by defautl) is at best very awkward and bordering on the bizarre.

I am not sure whether to blame the interpreter (which is apparently only following a fairly well defined search strategy) or perhaps better to blame the implementation of UnivariatePolynomial for allowing this form of abbreviated composition of polynomials (which I think should be seen as at best idiosyncratic) as something so ubiquitous in Axiom as function application. I think there are very good reasons to distinguish polynomials and expressions in general from functions (i.e. the lambda abstraction).

You must have a pretty bad day? (three "blame" words in one message? :-)

I agree 100% with you that one should distinguish polynomials or expressions from functions. But that is on the mathematics or theory level. In computing, we need to be able to make substitutions (compose if you like under certain cases) into the polynomials or expressions -- even if you use eval, you are still considering the polynomials as functions without any change in domain or representation. It would be another nightmare of coercion if a polynomial has to be coerced into a function before any evaluation. Moreover, if a polynomial can be thought of as a function, then ground elements are constant functions. Axiom is consistent in this interpretation and any one writing 1 x intentionally would understand that to be the constant function 1 evaluated at x and the interpreter is to find the domain in which this makes sense. One way is to treat x as in a univariate polynomial ring (a multivariate polynomial ring would be ok too except that the function that does the evaluation must operate on all cases, and unless you are in a univariate situation, 1 x would only be a special case, and (a+b) x would be ambiguous because x may replace a or replace b).

While it may be unintuitive why anyone would perform an operation like 1 x, we should always bear in mind that this computation may have come about as an intermediate computation (piping), when most of the time it would be a b where a, b are both polynnomials in POLY INT, and in some situation, a becomes 1. You cannot treat 1 x differently from a b, and certainly should not be treated as a syntax error (when suitably placed, as in code intended for compilation) because it is not.

The interpreter succeeds in seemingly more complicated 1 x[y] and not 1 x may perhaps be understood the following way. More complicated expressions provide more information to the interpreter and this guides it: to apply x to [y], the interpreter figures out the correct map with target domain Symbol, which helps it to locate UP(xy,INT). Converting a Variable(x) element to Symbol is "counter-intuitive" to the interpreter, because the domain Variable(x:Symbol) starts with a symbol. Variable(x) is an unexposed domain, and the conversion (either coerce or variable) are unexposed (possibly to avoid the possibility to change it back from Symbol to Variable(x) again). So unless you explicitly make the conversion, the interpreter does not do it.

The Wiki pages are supposed to be for experts as well as for novices. When simple input like this causes some apparent problem that is "unexpected", we should explain it. For some this may sound trivial, but for others, it may not.

forwarded from 99X1AbcYShouldBeASyntaxError#msg20050217150552-0600@page.axiom-developer.org

William

)clear all

   All user variables and function definitions have been cleared.

Today I felt like taking what I think might be the point of view of a new user of Axiom. I agree completely that the Wiki pages are supposed to be for experts as well as for novices and when simple input like this causes some apparent problem that is "unexpected", that we should explain it. I think you did a good job of that. But in my opinion the explanation is rather bizarre (especially from the point of view of a new user). So this is were the experts come in: How can we make Axiom's behaviour less bizarre to new users?

I originally saw this behaviour in an simple test in the SandBox where a new user wrote something like this

integrate(z^2 ln[z],z)

(11)

I was quite sure that what they intended to compute was

integrate(z^2*log(z),z)

(12)

but I had a hard time understanding the original answer and I wondered why Axiom did not at least produce some kind of syntax error.

About the status: Closed looks like you have decided that there should be no more discussion. Yes this is a wiki and so I could simply Open it again, but I think it is better to try to develop some "rules of netiquette" so that the open collaboration allowed by the wiki can work smoothly. We are all still fairly new at this.

Perhaps I was too direct in using the word "annoyed" since I am well aware that it is very hard to correctly interpret other peoples' motives and emotional state when reading what they wrote alone. I was annoyed :) but if you had seen me in person you would have noticed that I also smiled when I said that. Of course I used the word "blame" in the same way. I did not mean it to sound like I was "finding fault" with anyone, only that I wanted to identify what might be changed to make Axiom's behaviour more intuitive.

About 'preferences': It seems that "wiki people" generally would like to avoid any perceived "login barrier". Setting preferences is just a matter of saying how you would like to be identified (and a few other details) - it is not supposed to be like "logging in". And you are right that in principle this only needs to be done once. Setting preferences sends some cookies to your browser which, depending on whether you have set your browser security to permit it or not, will allow the system to remember your preferences the next time you connect to the wiki. But maybe you are right that there might be a better label than preferences. How about something like Who Am I?

About the use of *01abc y as a symbol in a type. Maybe this notation starts to make a little more sense if you see an expression like

1 t[x,y,z]

(13)

but I still don't see why, if there is a need for some linear syntax, there would be any objection to using the same syntax as the input. Surely:

             Type: UnivariatePolynomial(t[x,y,z], Integer)

would be self explanatory, no?

About functions and expressions. There is no problem making substitutions into polynomials like this:

subst((1+b^2)::UP(b,INT),b=(t^2::UP(t,INT)))::UP(t,INT)

(14)

or even this

subst((1+c*b^2)::MPOLY([b,c],INT),b=(t^2::UP(t,INT)))::MPOLY([t,c],INT)

(15)

We can also explicitly use eval. So I don't understand the need to define application for univariate polynomials and to treat them like functions.

Finally, could you explain further your reasoning about why the interpreter should not coerce Variable x to Symbol? Axiom has no trouble coercing x to a Symbol in the case of an expresion like UP(x,INT). Surely it should be able to solve the problem of coercing x to Symbol in order that Symbol can be coerced to UP(x,INT) in cases like 1 x and integrate(x)?

Or is it the case that the interpreter never tries harder than just one coercion?

BTW, I tried specifying

)expose Variable

   Variable is now explicitly exposed in frame initial

but I did not see any change in Axiom's behaviour.

1 x

   Cannot find a definition or applicable library operation named 1 
      with argument type(s) 
                                 Variable(x)

      Perhaps you should use "@" to indicate the required return type, 
      or "$" to specify which version of the function you need.
integrate(x)

   There are 4 exposed and 2 unexposed library operations named 
      integrate having 1 argument(s) but none was determined to be 
      applicable. Use HyperDoc Browse, or issue
                            )display op integrate
      to learn more about the available operations. Perhaps 
      package-calling the operation or using coercions on the arguments
      will allow you to apply the operation.

   Cannot find a definition or applicable library operation named 
      integrate with argument type(s) 
                                 Variable(x)

      Perhaps you should use "@" to indicate the required return type, 
      or "$" to specify which version of the function you need.

--------- Bill Page

[#99 x^1 abc[y]? should be a syntax error] badday? not really :) --William Sit, Mon, 21 Feb 2005 01:30:46 -0600 reply

Bill Page wrote:

Today I felt like taking what I think might be the point of view of a new user of Axiom. I agree completely that the Wiki pages are supposed to be for experts as well as for novices and when simple input like this causes some apparent problem that is "unexpected", that we should explain it. I think you did a good job of that. But in my opinion the explanation is rather bizarre (especially from the point of view of a new user). So this is were the experts come in: How can we make Axiom's behaviour less bizarre to new users?

This is a tall order even though I would agree that such bizarre results may drive many away.

I originally saw this behaviour in an simple test in the SandBox where a new user wrote something like this

axiom

integrate(z^2 ln[z],z)

(16)

Type: Union(Expression(Integer),...)

A new user has to learn the basic operations and syntax. The above user may be used to Mathematica and Maple or just simply use intuition. I have the same experience myself: I am used to Mathematica and I can't stand the syntax and especially the worksheet interface of Maple (my prejudice). I made so many mistakes and got frustrated every time. But this is not to say Maple is not great for a lot of other people.

I was quite sure that what they intended to compute was

axiom

integrate(z^2*log(z),z)

(17)

Type: Union(Expression(Integer),...)

but I had a hard time understanding the original answer and I wondered why Axiom did not at least produce some kind of syntax error.

I did not find it easy either. Just because it can be explained does not mean the problem is not there. On the other hand, Axiom was designed for mathematicians and perhaps there is some assumption built in that the users would follow the rules and would realize what their mistakes are. This "apply" notion permeates all levels of Axiom and I believe it would be impossible to modify it without causing a lot of other failures, creating more problems.

About the status: Closed looks like you have decided that there should be no more discussion. Yes this is a wiki and so I could simply Open it again, but I think it is better to try to develop some "rules of netiquette" so that the open collaboration allowed by the wiki can work smoothly. We are all still fairly new at this.

Agreed. I will not close any discussion from now on. One cannot foresee the implications sometimes when the examples illustrating the bugs are already traced to such a low level. I decided to close it because the example x^1 abc[y]? was clearly artificial; had I seen this one on integration, I probably wouldn't have.

Perhaps in addition to a pin-point example, there should also be the other examples on a more complex level to illustrate the implications. For example, I would classify the problem with '1 x[y]?' as not a severe problem, but 'integrate(z^2 ln[z]?, z)' as severe, even though the cause is the same. And the two should be combined into one page, may be with a heading: Beware of Functional Applications.

Perhaps I was too direct in using the word "annoyed" since I am well aware that it is very hard to correctly interpret other peoples' motives and emotional state when reading what they wrote alone. I was annoyed :) but if you had seen me in person you would have noticed that I also smiled when I said that. Of course I used the word "blame" in the same way. I did not mean it to sound like I was "finding fault" with anyone, only that I wanted to identify what might be changed to make Axiom's behaviour more intuitive.

While this is a worthwhile goal, it may be too late in the game because these issues should have been resolved from the moment the system was designed. The interpreter is already quite different from the compiler in its handling of user input. Increasing its user friendliness will only make it even harder to learn to use the compiler, especially if the grammar is changed. Right now, I think all the interpreter does is performing coercions, lifting domains, and matching signatures. I don't believe you would get any of these problems with a compiled package because one is forced by the compiler to know exactly what one is computing. So if the "behavior" of Axiom is to be changed, one has to rewrite the interpreter, making Axiom even more different than the compiler version.

It is probably easier to change user behavior :-). I remember how new students using Mathematica forget to start the trig functions (or any built-in function) with a capital letter and enter xy to mean x times y. I would say that to a new user, when (s)he has not yet got familiar with the nuiances, many answers or error messages would seem bizarre too. But in the end they almost always learn these. I also provided a calculator type pallette for them to just click on these functions to minimize the accidental mistakes. Perhpas that's the area we need to improve Axiom on: user input interface and better tutorials. I find Mathematica's interface the best (I have used Maple, and Matlab as well). It is easy to scroll back to a previous command and edit it, wrap it inside a function for more processing, or append afterthought functions. I think these pages, as we accumulate more and reorganize them systematically, can become a good introductory set of notes (or teasers) for users to hone their Axiom skills.

On the other hand, I think no software system can stand a deliberate scrutiny on all possible input errors (not to mention those that are syntactically correct but with wishful semantics). It is similar to anticipating all student errors in mathematics or their wishful laws on algebraic operations. We can't and instead we teach students the correct ways.

I recommend strongly that when users find "strange behavior" in the interpreter version that they try to analyse it by using )set mess bot on. If that does not help, then use a simple test package and compile it. They will then be forced to be explicit (and may find that the compiler uses a different set of assumptions) and find out what went wrong and thus continue with their computations in the correct way. When it is a bug in computation with the compiler, it becomes a genuine concern.

About 'preferences': It seems that "wiki people" generally would like to avoid any perceived "login barrier". Setting preferences is just a matter of saying how you would like to be identified (and a few other details) - it is not supposed to be like "logging in". And you are right that in principle this only needs to be done once. Setting preferences sends some cookies to your browser which, depending on whether you have set your browser security to permit it or not, will allow the system to remember your preferences the next time you connect to the wiki. But maybe you are right that there might be a better label than preferences. How about something like Who Am I?

That sounds like a better label. May be "Who Are You"? "whoami" is a Unix command for a different purpose. But of course, I know now where to do it. For new comers, that would certainly help.

About the use of *01abc y as a symbol in a type. Maybe this notation starts to make a little more sense if you see an expression like

axiom

1 t[x,y,z]

(18)

Type: UnivariatePolynomial(*03t(x,y,z),Integer)

but I still don't see why, if there is a need for some linear syntax, there would be any objection to using the same syntax as the input. Surely:

             Type: UnivariatePolynomial(t[x,y,z], Integer)

would be self explanatory, no?

I suppose, I was only guessing at some logic behind this "design". And actually Axiom does use your suggested notation too (indeed, mixed), and so it is again not that consistent.

integrate(z^2*x[z],z)

(19)

1 x[%]

(20)

Here in the Type message, x(z) is used instead of *01x z. You will see Axiom tries very hard to work out the type of the last one if you had )set mess bot on.

About functions and expressions. There is no problem making substitutions into polynomials like this:

axiom

subst((1+b^2)::UP(b,INT),b=(t^2::UP(t,INT)))::UP(t,INT)

(21)

Type: UnivariatePolynomial(t,Integer)

or even this

axiom

subst((1+c*b^2)::MPOLY([b,c],INT),b=(t^2::UP(t,INT)))::MPOLY([t,c],INT)

(22)

Type: MultivariatePolynomial?([t,c],Integer)

We can also explicitly use eval. So I don't understand the need to define application for univariate polynomials and to treat them like functions.

Univariate polynomials are just like finite sequences (streams would be infinite sequences) and all are just functions in the sense the domain is the set of indices (subscripts, exponents or more complicated scripting at times). Axiom is just treating them uniformly. In using subst, you explicitly spell out how the substitution is done. Axiom does not prevent you to use subst. But even in subst, Axiom's behavior is vastly different than, say Mathematica. For example, Axiom would not substitute every occurrence of b.

)clear all

   All user variables and function definitions have been cleared.
subst(1+c[b^2],b=t^2)

(23)

subst(1+c(b^2), b=t^2)

   There are no library operations named c 
      Use HyperDoc Browse or issue
                                 )what op c
      to learn if there is any operation containing " c " in its name.

   Cannot find a definition or applicable library operation named c 
      with argument type(s) 
                             Polynomial(Integer)

      Perhaps you should use "@" to indicate the required return type, 
      or "$" to specify which version of the function you need.

whereas in Mathematica, 1+c[b^2]/.b->t^2 will give 1+c[t^4] and 1+Subscript[c,b^2] /.b->t^2 will give 1+Subscript[c,t^4] even when c is not defined. There is a lot of differences between languages and one cannot expect Axiom to behave "like" Mathematica, which has no concept of where (that is, in what domain) the operation is taking place.

Finally, could you explain further your reasoning about why the interpreter should not coerce Variable x to Symbol? Axiom has no trouble coercing x to a Symbol in the case of an expresion like UP(x,INT). Surely it should be able to solve the problem of coercing x to Symbol in order that Symbol can be coerced to UP(x,INT) in cases like 1 x and integrate(x)?

Nope, because I was wrong! I thought it might create an infinite mutual coercion, but that is apparently not the case. I don't have any documentation on the interpreter. Like what physicists practice, the theory must follow the experiments and will change when new evidence shows up. So I now find out a situation where the interpreter actually does the coercion from Variable(x) to Symbol. (So my previous statement that claim the interpreter does not do this conversion in my last message is wrong -- I was misguided by the hyperdoc documentation that the convert and variable functions are unexposed, even if Variable() is).

See IssueTracker #110.

Or is it the case that the interpreter never tries harder than just one coercion?

No, the interpreter tries very hard sometimes. See above symbol with a complicated subscript.

BTW, I tried specifying

axiom

)expose Variable

   Variable is already explicitly exposed in frame initial

but I did not see any change in Axiom's behaviour.

axiom

1 x

   Cannot find a definition or applicable library operation named 1 
      with argument type(s) 
                                 Variable(x)

      Perhaps you should use "@" to indicate the required return type, 
      or "$" to specify which version of the function you need.
integrate(x)

   There are 4 exposed and 2 unexposed library operations named 
      integrate having 1 argument(s) but none was determined to be 
      applicable. Use HyperDoc Browse, or issue
                            )display op integrate
      to learn more about the available operations. Perhaps 
      package-calling the operation or using coercions on the arguments
      will allow you to apply the operation.

   Cannot find a definition or applicable library operation named 
      integrate with argument type(s) 
                                 Variable(x)

      Perhaps you should use "@" to indicate the required return type, 
      or "$" to specify which version of the function you need.

I don't know. According to hyperdoc, even if Variable() is exposed, the two operations convert and variable are still unexposed. But I now do not think that is the problem. Apparently, the interpreter is able to use them when it wants to.

--------- Bill Page -- forwarded from "99X1AbcYShouldBeASyntaxError#msg20050217221454-0600@page.axiom-developer.org:99X1AbcYShouldBeASyntaxError#msg20050217221454-0600@page.axiom-developer.org

William

property change

Tue, 08 Mar 2005 04:52:29 -0600 reply