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).
first, 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) defined on the real numbers, it is reasonable to define
f(infinity) = limit(f(x), x= infinity) if this limit exists (or is +/- infinity). In this
case, f(x) = 1^x. It is reasonable because it gives the *unique* (not indeterminate)
continuous extension of the function over the compactification.
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 infinity along any path, then \(1^(a_n)=1\) for any \(n\). So the limit is defined 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 first 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 different 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 infinity (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.