help links subscribe changes refresh edit

	IssueTracker
#98 configure script does not handle MAC OSX "Darwin" ←	↑

#99 x^1 abc[y] should be a syntax error

Edit detail for #99 x^1 abc[y] should be a syntax error revision 1 of 1

	1
Editor: Time: 2007/11/17 23:05:32 GMT-8
Note: links updated after rename

changed:
-
The axiom command:
\begin{axiom}
x^1 abc[y]
\end{axiom}

does not produce any syntax error while
\begin{axiom}
x abc[y]
\end{axiom}

does produce an error message.

It seems that <code>1 abc![y]</code> is parsed as something unusual
\begin{axiom}
1 abc[y]
\end{axiom}

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 'c'<SUB>'d'</SUB> when displayed on the Type info line is written as '*01c d'.

So <code>abc![y]</code> is the same as <code>abc ![y]</code> (because clearly the
left <code>'['</code> terminates the  symbol 'abc') and so this is a subscripted
symbol 'abc'<SUB>'y'</SUB>.

\begin{axiom}
abc [y]
x [1,2,3]
\end{axiom}

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

\begin{axiom}
1 (b::Symbol)
\end{axiom}

This is the same as

\begin{axiom}
elt(1::UP(b,INT),b::UP(b,INT))$UP(b,INT)
\end{axiom}

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.

\begin{axiom}
(x::UP(x, POLY INT)) (b::UP(x, POLY INT))
\end{axiom}

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

\begin{axiom}
x::UP(x, POLY INT) b::UP(x, POLY INT)
\end{axiom}

From unknown Thu Feb 17 06:09:33 -0600 2005
From: 
Date: Thu, 17 Feb 2005 06:09:33 -0600
Subject: Not a syntax error
Message-ID: <20050217060933-0600@page.axiom-developer.org>

Status: open => closed 

From BillPage Thu Feb 17 15:05:52 -0600 2005
From: Bill Page
Date: Thu, 17 Feb 2005 15:05:52 -0600
Subject: annoying
Message-ID: <20050217150552-0600@page.axiom-developer.org>

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?

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

From WilliamSit Thu Feb 17 19:19:21 -0600 2005
From: William Sit
Date: Thu, 17 Feb 2005 19:19:21 -0600
Subject: [#99 x^1 abc[y] should be a syntax error] annoying
Message-ID: <421542A6.ABB4CF71@cunyvm.cuny.edu>

Bill Page wrote:
> 
> 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 <code>*01abc y</code> 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

\begin{axiom}
t:=1 x[y[z]]
dom:=typeOf t
h:dom:=monomial(2,3)
\end{axiom}

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 <code>1 x[y]</code> 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 <code>[y]</code>, the interpreter figures out the correct map with
target domain Symbol, which helps it to locate
<code>UP(x<sub>y</sub>,INT)</code>. 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":99X1AbcYShouldBeASyntaxError#msg20050217150552-0600@page.axiom-developer.org
> 

William

From BillPage Thu Feb 17 22:14:54 -0600 2005
From: Bill Page
Date: Thu, 17 Feb 2005 22:14:54 -0600
Subject: bad day? not really :)
Message-ID: <20050217221454-0600@page.axiom-developer.org>

\begin{axiom}
)clear all
\end{axiom}
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
\begin{axiom}
integrate(z^2 ln[z],z)
\end{axiom}

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.

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

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.

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

---------
Bill Page

From WilliamSit Mon Feb 21 01:30:46 -0600 2005
From: William Sit
Date: Mon, 21 Feb 2005 01:30:46 -0600
Subject: [#99 x^1 abc[y] should be a syntax error] badday? not really :)
Message-ID: <42198E31.CF10A5D6@cunyvm.cuny.edu>

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
> \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 "99X1AbcYShouldBeASyntaxError#msg20050217221454-0600@page.axiom-developer.org:99X1AbcYShouldBeASyntaxError#msg20050217221454-0600@page.axiom-developer.org

William

From unknown Tue Mar 8 04:52:29 -0600 2005
From: 
Date: Tue, 08 Mar 2005 04:52:29 -0600
Subject: property change
Message-ID: <20050308045229-0600@page.axiom-developer.org>

The axiom command:

fricas

(1) -> x^1 abc[y]

$\label{eq1}x$

(1)

Type: Fraction(Polynomial(Integer))

does not produce any syntax error while

fricas

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

fricas

1 abc[y]

$\label{eq2}1$

(2)

Type: UnivariatePolynomial(abc[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 c_d 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 abc_y.

fricas

abc [y]

$\label{eq3}abc_{y}$

(3)

Type: Symbol

fricas

x [1,2,3]

$\label{eq4}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.

fricas

1 (b::Symbol)

$\label{eq5}1$

(5)

Type: UnivariatePolynomial(b,Integer)

This is the same as

fricas

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

$\label{eq6}1$

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

fricas

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

$\label{eq7}b$

(7)

Type: UnivariatePolynomial(x,Polynomial(Integer))

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

fricas

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

Status: open => closed

annoying --Bill Page, Thu, 17 Feb 2005 15:05:52 -0600 reply

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?

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

[#99 x^1 abc[y]? should be a syntax error] annoying --William Sit, Thu, 17 Feb 2005 19:19:21 -0600 reply

Bill Page wrote:

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

fricas

t:=1 x[y[z]]

$\label{eq8}1$

(8)

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

fricas

dom:=typeOf t

$\label{eq9}\hbox{\axiomType{UnivariatePolynomial}\ } \left({{x_{y_{z}}}, \: \hbox{\axiomType{Integer}\ }}\right)$

(9)

Type: Type

fricas

h:dom:=monomial(2,3)

$\label{eq10}2 \ {{<em> 01000 x \left({y_{z}}\right)}^{3}}$

(10)

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

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(x_y,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

bad day? not really :) --Bill Page, Thu, 17 Feb 2005 22:14:54 -0600 reply

fricas

)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

fricas

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

$\label{eq11}\frac{{z}^{3}}{3}$

(11)

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

I was quite sure that what they intended to compute was

fricas

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

$\label{eq12}\frac{{3 \ {{z}^{3}}\ {\log \left({z}\right)}}-{{z}^{3}}}{9}$

(12)

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.

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

fricas

1 t[x,y,z]

$\label{eq13}1$

(13)

Type: UnivariatePolynomial(t[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?

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

fricas

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

$\label{eq14}{{t}^{4}}+ 1$

(14)

Type: UnivariatePolynomial(t,Integer)

or even this

fricas

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

$\label{eq15}{c \ {{t}^{4}}}+ 1$

(15)

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.

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

fricas

)expose Variable

   Variable is now explicitly exposed in frame initial

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

fricas

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.

--------- 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
fricas
integrate(z^2 ln[z],z)
$\label{eq16}\frac{{z}^{3}}{3}$ (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
fricas
integrate(z^2*log(z),z)
$\label{eq17}\frac{{3 \ {{z}^{3}}\ {\log \left({z}\right)}}-{{z}^{3}}}{9}$ (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
fricas
1 t[x,y,z]
$\label{eq18}1$ (18)

Type: UnivariatePolynomial(t[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.

fricas

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

$\label{eq19}{\frac{1}{3}}\ {x_{z}}\ {{z}^{3}}$

(19)

Type: Polynomial(Fraction(Integer))

fricas

1 x[%]

$\label{eq20}1$

(20)

Type: UnivariatePolynomial(x[(1/3)*x[z]*z^3],Integer)

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:
fricas
subst((1+b^2)::UP(b,INT),b=(t^2::UP(t,INT)))::UP(t,INT)
$\label{eq21}{{t}^{4}}+ 1$ (21)

Type: UnivariatePolynomial(t,Integer)

or even this
fricas
subst((1+c*b^2)::MPOLY([b,c],INT),b=(t^2::UP(t,INT)))::MPOLY([t,c],INT)
$\label{eq22}{c \ {{t}^{4}}}+ 1$ (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.

fricas

)clear all

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

$\label{eq23}{c_{{b}^{2}}}+ 1$

(23)

Type: Expression(Integer)

fricas

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

fricas

)expose Variable

   Variable is already explicitly exposed in frame initial

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

fricas

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.

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