[Axiom-developer] [#99 x^1 abc[y] should be a syntax error] [#99 x^1 abc[y] should be a syntax error] badday? not really :)

[William Sit]

Changes 
http://page.axiom-developer.org/zope/mathaction/99X1AbcYShouldBeASyntaxError/diff
--
Bill Page wrote:
> 
> Changes 
> http://page.axiom-developer.org/zope/mathaction/99X1AbcYShouldBeASyntaxError/diff
> --
> 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
> \begin{axiom}
> integrate(z^2 ln[z],z)
> \end{axiom}

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
> \begin{axiom}
> integrate(z^2*log(z),z)
> \end{axiom}
> 
> 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 <code>)set mess bot on</code>. 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
> \begin{axiom}
> 1 t[x,y,z]
> \end{axiom}
> 
> 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. 

\begin{axiom}
integrate(z^2*x[z],z)
1 x[%]
\end{axiom}

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:
> \begin{axiom}
> subst((1+b^2)::UP(b,INT),b=(t^2::UP(t,INT)))::UP(t,INT)
> \end{axiom}
> 
> or even this
> \begin{axiom}
> subst((1+c*b^2)::MPOLY([b,c],INT),b=(t^2::UP(t,INT)))::MPOLY([t,c],INT)
> \end{axiom}
> 
> 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'.

\begin{axiom}
)clear all
subst(1+c[b^2],b=t^2)
subst(1+c(b^2), b=t^2)
\end{axiom}

whereas in Mathematica, <code>1+c[b^2]/.b->t^2</code> will give
<code>1+c[t^4]</code> and <code>1+Subscript[c,b^2] /.b->t^2</code> will give
<code>1+Subscript[c,t^4]</code> 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
> \begin{axiom}
> )expose Variable
> \end{axiom}
> 
> but I did not see any change in Axiom's behaviour.
> \begin{axiom}
> 1 x
> integrate(x)
> \end{axiom}

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 http://page.axiom-developer.org/zope/mathaction/address@hidden

William

--
forwarded from http://page.axiom-developer.org/zope/mathaction/address@hidden