[Axiom-developer] [#99 x^1 abc[y] should be a syntax error] [#99 x^1 abc[y] should be a syntax error] annoying

[William Sit]

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

William

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