I wish to bring the following two points to the notice of the maple user community. please elucidate what these observations of mine imply (from a maple viewpoint and also from the theory viewpoint).

ﬁrst, maple outputs unity when i launch the command:

`> 1^infinity;`

while analysis tells us this entity is actually an indeterminate form.

second, when i use the ’auto correct the syntax of the expression’ button, the resulting syntax produces an error as its not an acceptable maple syntax as the following commands list shows:

> series(BesselJ(3,x),x);

produces a correct answer; but when the command at the prompt is incorrect:

> series(BesselJ(3,x,x);

and i use the auto correct button, maple 7 produces the following which is incorrect syntax as far as the series and BesselJ functions of the package are concerned:

> series(BesselJ(3,x,x)); Error, (in BesselJ) expecting 2 arguments, but received 3

please address these observations.

` [ first, maple outputs unity ...`

Given a function `f(x)`

deﬁned on the real numbers, it is reasonable to deﬁne
`f(infinity) = limit(f(x), x= infinity)`

if this limit exists (or is +/- inﬁnity). In this
case, `f(x) = 1^x`

. It is reasonable because it gives the *unique* (not indeterminate)
continuous extension of the function over the compactiﬁcation.

When a math book says that `1^infinity`

is an indeterminate form, they mean that if f(x) or
g(x) are *unknown* functions, except that we know `limit(f(x), x=a) = 1`

and
`limit(g(x), x=a) = infinity`

, then we still don’t have enough information to compute
`limit(f(x)^g(x), x= a)`

.

If both f(x) and g(x) are known, then to say that the answer is indeterminate is simply a failure to give an answer.

` [ second, when i use the 'auto correct' ...`

It seems reasonable to me to expect an auto-correct feature to attempt to balance your parentheses, which is what is happening here. I think it is asking too much for it to check the number of arguments in each function call. Consider all that could happen:

- Procedures can have variable number of arguments. - You could have redefined BesselJ to take three arguments. - The number of arguments needed could be a function of the first argument.

You need to make a distinction between syntax and semantics. `series(BesselJ(3,x,x))`

is
correct Maple syntax.

`[ first, maple outputs unity ...`

In what sense is this an indeterminate form? If you consider a sequence of complex numbers \(\{a_n\}\) going to inﬁnity along any path, then \(1^(a_n)=1\) for any \(n\). So the limit is deﬁned and equal to 1.

As an example of something that `_is_`

an indeterminate form, take \((-1)^\infty \), for which Maple
returns `undefined + undefined*I`

.

` [second, when i use the 'auto correct' ...`

In the ﬁrst case, with `"series(BesselJ(3,x,x)"`

, the error was a missing parenthesis. In
the second case, the error was an omitted argument.

It’s too hard for Maple to check that the number of arguments to a function is correct, so it doesn’t try. It just makes sure that all the parentheses match, that you have an "end if" for every "if", etc.

While Maple returns 1 by default for \(1^\infty \)

> 1^infinity; 1

However, the fact that this is an invalid operation has been detected:

> NumericStatus(); invalid_operation = true, division_by_zero = false, overflow = false, underflow = false, inexact = false, real_to_complex = false

As with all numeric events, the default behaviour can be changed by installing a diﬀerent event handler:

> NumericEventHandler(invalid_operation=(t->undefined)); invalid_operation = default > 1^infinity; undefined > NumericEventHandler(invalid_operation=exception); invalid_operation = (t -> undefined) > 1^infinity; Error, numeric exception: invalid operation

(This is in Maple 6 and higher)

` [first, maple outputs unity ...`

Not a bug. In general, Maple is literal-minded, and you should not use 1 or inﬁnity (or, for that matter, any other constant) when what you mean is some quantity that is approaching that constant. If what you want is a limit, then use the "limit" function.

` [ second, when i use the 'auto correct' ...`

In fact the syntax of the command

series(BesselJ(3,x,x))

is correct, as far as Maple’s parser is concerned; it just happens that the `BesselJ`

function in
Maple 7 does not allow 3 arguments. I would call this a problem of semantics rather than of
syntax, since in Maple it is in general impossible to tell how many arguments a function will
accept without looking at the code.