MaplePrimes - answers and comments on Question, Matlab to Maple

round-off

Mac Dude — Sat, 03 Nov 2012 17:02:52 Z

You are looking at round-off errors. In my environment I set Digits to 15 and I get

n=1: 1.12000000000000 E+15 (this is probably infinite as the exponent goes up with Digits)

You probably have Maple's default of 10 Digits.

For n=2 clearly Matlab is underrunning.

For n=3 Maple may be doing it symbolically and correct. You can get a similar result as Matlab if you evalhf(A3(3)) thus forcing floating-point evaluation using your computer's FPU. Floating hardware is not accurate to the last bit (many numbers cannot be represented exactly in fp) & thus the denominator can underrun to a small non-zero number rather than exact zero.

Mac Dude

singularity

acer — Sat, 03 Nov 2012 17:18:28 Z

The limits as you approach A3(3) from each side are +infinity and -infinity. Which result you get, as you compute in floating-point, might depend upon the working precision (Digits) due to numerical error.

restart:
alpha_p:=1: p:=2: mu0:=4*Pi*1e-7: Br:=1.12:

A1:=unapply(sin((n*p+1)*alpha_p*Pi/(2*p))/((n*p+1)*alpha_p*Pi/(2*p)),n):

A2:=unapply(sin((n*p-1)*alpha_p*Pi/(2*p))/((n*p-1)*alpha_p*Pi/(2*p)),n):

M1:=unapply((Br/mu0)*alpha_p*(A1(n)+A2(n)),n):

M2:=unapply((Br/mu0)*alpha_p*(A1(n)-A2(n)),n):

M3:=unapply(M1(n)+n*p*M2(n),n):

A3:=unapply(((n*p-1/(n*p))*M1(n)/M3(n)+1/(n*p)),n):
evalhf(A3(3));
                                         15
                     4.595173115007179 10  
A3c:=Compiler:-Compile(A3):
A3c(3);
                                         15
                     5.514207738008614 10  
for i from 10 to 20 do
  Digits:=i;
  q:=A3(3.0):
  printf("\nDigits: %ld   evalf(A3(3)): %e\n",Digits,evalf(q));
end do:

Digits: 10   evalf(A3(3)): -2.292637e+09

Digits: 11   evalf(A3(3)): -1.604846e+11

Digits: 12   evalf(A3(3)): -8.024228e+11

Digits: 13   evalf(A3(3)): -2.292637e+12

Digits: 14   evalf(A3(3)): -2.292637e+13

Digits: 15   evalf(A3(3)): 2.674743e+14

Digits: 16   evalf(A3(3)): 1.458951e+15

Digits: 17   evalf(A3(3)): 1.604846e+16

Digits: 18   evalf(A3(3)): -4.012114e+17

Digits: 19   evalf(A3(3)): 1.783162e+18

Digits: 20   evalf(A3(3)): -3.209691e+19

A3(3);
                                     (1/2)    
                    Float(infinity) 2        1
                  - ---------------------- + -
                               2             6
                             Pi               

limit(A3(x),x=3,left);
                        Float(infinity)

limit(A3(x),x=3,right);
                        -Float(infinity)

plot(A3, 2.5..3.5);

acer

tan

acer — Sat, 03 Nov 2012 17:43:17 Z

T:=convert(expand(simplify(convert(A3(n),rational))),tan);

                             /1     \
                          tan|- Pi n|
                             \2     /

acer

Thanks Acer but small problem

AliKhan — Sat, 03 Nov 2012 18:55:24 Z

Thanks alot for the help guys. But using evalhf I can't sum A3(n)

Sum(A3(n)*cos(n*p*theta),n=1..10)

it gives following error

Error (in A3) cannot handle unevaluated name'n' in evalhf

Is there anyway I can get series of above equation.

The solution look like this n=1, 6.935e15*cos(2*theta)+.....

Thanks in advance

Looking forward to your kind replies

A.Q

add

acer — Sat, 03 Nov 2012 21:31:13 Z

@AliKhan The Matlab result for A3(3) is wrong, The evalhf result for A3(3) is wrong. But if you really want to use evalhf then try it with `add` instead of `Sum` or `sum`.

I find that people really don't like hearing it, but one thing you might reconsider is the methodology of assigning float values to your parameters at the start of your worksheet. Such values are useful for numeric evaluation, but often make it awkward to get the best symbolic benefits before doing numeric evaluations. Maple can often be a lot more easily powerful if you don't make such assignments at the start.

@acer I'd like to second your advise about

Mac Dude — Sun, 04 Nov 2012 00:50:36 Z

@acer I'd like to second your advise about late assignment of (floating-point-) numbers to variables. Sometimes it is a little awkward to do it late, however, e.g. when modules are involved one loads by menas of "with()". In such cases I have been experimenting with a scheme where I include a list of replacements in the module, like rlist:=[p1=...,p2=...] and so on and then apply a simple subs(rlist,...) when the time comes to get to numbers. Doing this I find takes some of the tedium out of switching to numbers at a late stage.

M.D.