[MUG] two bugs i found

[MUG] Re: two bugs i found
Author: Maple User Group    Posted: Fri, 6 Dec 2002 18:01:10 -0500 (
>> From: Maple User Group "maple_gr" -=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=- Date: Wed, 4 Dec 2002 15:43:47 -0500 (EST) From: Carl Devore "devore" To: "maple-list" Subject: two bugs i found > first, maple outputs unity when i launch the command: > >> 1^infinity; > while analysis tells us this entity is actually an indeterminate form. 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 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)); > Error, (in BesselJ) expecting 2 arguments, but received 3 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. -=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=- Date: Wed, 4 Dec 2002 17:42:17 -0500 (EST) From: Stephen Forrest "saforres" To: "maple-list" Subject: two bugs i found > first, maple outputs unity when i launch the command: > >> 1^infinity; 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)^infinity, for which Maple returns undefined + undefined*I. > 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: 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. Steve -=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=- Date: Thu, 5 Dec 2002 06:12:34 -0400 From: Vladimir Bondarenko "vvb" To: "maple-list" Subject: two bugs i found b) It IS a bug. Congratulations! By the way, you have just given me one more idea for my projects in progress (see below). If you think you are interested in such stuff please do not hesitate to contact me or our Symbolic Testing Group, we are on the lookout for gifted persons ;-) Of cause, there is nothing mystical in BesselJ(3,x), and the same bug manifests itself via, for example, series(HankelH1(3,x,x); series(KelvinKer(3,x,x); series(AiryAi(3,x,x); series(CylinderU(3,x,x); series(EllipticE(3,x,x); a) It is not a bug (cheer up! you sin in good company ;-) Please note that you are working in the SYMBOLIC mode, and consider the following. > 1^10; 1 > 1^1000000; 1 > 1^(1000^(1000)); 1 > 1^(1000^(1000^(1000))); Error, numeric exception: overflow # Derive 5.06 returns 1 here > 1^(355/113); 1 > 1^(1/333331); 1 > 1^(1/333331 + sqrt(2)*I); 1 > 1^(rand() + rand()*I); 1 > limit(1, a=infinity); 1 The term 'infinity' means that we have an (infinity) sequence of positive numbers. What are serious grounds that we should expect undefined like with, say, infinity - infinity; ? A Mathematica guru, Ted Ersek "ErsekTR" sent to MathGroup on Wed, 4 Dec 2002 03:25:51 the following laconic message I cannot fail to quote in extenso. TE> Hello, TE> Consider this: TE> TE> In[1]:= TE> 1^Infinity TE> TE> Out[1]= TE> Indeterminate TE> TE> --------- TE> I agree 1.0^Infinity is Indeterminate because 1.0 might be a bit less TE> than 1 or a bit greater than 1. TE> but isn't (1*1*1* ..... *1) simply the integer 1. Yep, of cause, it IS a bug in Mathematica 4.2. (There is none acquittal to such a math felony ;-) I am sending your information to both "support" and the Yahoo Maple Group of top Maple experts. Keep her steady! ;-) Best wishes, Vladimir Bondarenko Mathematical and Production Director Symbolic Testing Group Web : http://maple.bug-list.org/ Maple Bugs Encyclopaedia (20% ready) http://www.CAS-testing.org/ GEMM Project (95% ready) Email: "vvb" Voice: (380)-652-447325 Mon-Fri 6 a.m. - 3 p.m. GMT ICQ : 173050619 Mail : 76 Zalesskaya Str, Simferopol, Crimea, Ukraine -=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=- Date: Thu, 05 Dec 2002 07:23:32 +0100 From: Preben Alsholm "P.K.Alsholm" To: "maple-list" Subject: two bugs i found When we refer to the indeterminate form "1^infinity" we mean that an expression such as a(x)^b(x) has limit(a(x),x=x0)=1 and limit(b(x),x=x0)=infinity. If on the other hand you literally want 1^infinity, then the only reasonable meaning must be limit( 1^n, n=infinity) which clearly is 1. Maple therefore , is correct in automatically simplifying 1^infinity to 1. As far as the automatic correction of the syntax is concerned, I think you expect way too much. Surely all it is designed to do is to make the expression grammatically correct, not necessarily make it make sense. Preben Alsholm Department of Mathematics Technical University of Denmark -=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=- From: L Bernardin "lb" To: "''" Subject: two bugs i found Date: Thu, 5 Dec 2002 09:33:39 -0500 While Maple returns 1 by default for 1^infinity. > 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) best regards -Laurent -=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=- Date: Thu, 5 Dec 2002 21:08:23 -0800 (PST) From: Robert Israel "israel" To: "maple-list" Subject: two bugs i found On Wed, 4 Dec 2002, A Prashanth pg ee wrote: > first, maple outputs unity when i launch the command: > >> 1^infinity; 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 the syntax of the expression' button, > the resulting syntax produces an error as its not an acceptable maple 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. Robert Israel "israel" Department of Mathematics http://www.math.ubc.ca/~israel University of British Columbia Vancouver, BC, Canada V6T 1Z2 -=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=- From: "Dr Francis J. Wright" "F.J.Wright" To: "aprash" Subject: two bugs i found Date: Fri, 6 Dec 2002 14:33:46 -0000 > first, maple outputs unity when i launch the command: > >> 1^infinity; I don't see why. I agree with Maple that 1^anything = 1. Can you give an example where this is not true? > 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 I think that autocorrect corrects only syntax errors, and in practice that probably means only the number of closing parentheses. It doesn't correct semantic errors, such as the number of arguments to functions or even the correct location of parentheses. Note that the error you show above is a run-time error, not a parsing (syntax) error. In my (limited) experience, autocorrect tends to add closing parentheses in the wrong place. Since it's not much use I neither use it nor recommend my students to use it. Francis

Previous by date: [MUG] Re: Optimize tryhard, Maple User Group
Next by date: [MUG] Integration problem, Benj FitzPatrick
Previous thread: [MUG] HOWTO solve system where solution is piecewise?, 
Next thread: [MUG] Integration problem,  Ben Whitaker