pagan

5127 Reputation

23 Badges

16 years, 197 days

 

 

"A map that tried to pin down a sheep trail was just credible,

 but it was an optimistic map that tried to fix a the path made by the wind,

 or a path made across the grass by the shadow of flying birds."

                                                                 - _A Walk through H_, Peter Greenaway

 

MaplePrimes Activity


These are answers submitted by pagan

Does this explain it? From the help page for `proc`.

"Within a procedure, during the execution of its statementSequence, local variables have single level evaluation. This means that using a variable in an expression will yield the current value of that variable, rather than first evaluating that value. This is in contrast to how variables are evaluated outside of a procedure, but is similar to how variables work in other programming languages."

 

A lot of numerical methods, such as for rootfinding or optimization, rely on differentiability in order to work properly. But the graph of g shows a maximum as occuring on what looks like a sharp cusp-like edge. (Hence, it would not be possible to use fsolve on the 1st partial derivatives since diff(g,y) is not zero or nicely behaved near the maximum. Ie, the surface is not flat in the y-direction at the maximum.)

If you use g as an expression then use diff instead of D (which could be more appropriate for g an operator).

> g:=
> (3*x^(2)*y^(2)+4*x^(2)*y+21*x^(2)-4*x*y^(2)-72*x*y-128*x+21*y^(2)+128*y+297)/
> ((x^(2)+2*x+2)*(y^(2)-2*y+2)*(x^(2)-8*x+17)*(y^(2)+8*y-17)):

> discont(diff(g,y),y);
           2                                      2
 {RootOf(_Z  + 8 _Z - 17, -9.744562647), RootOf(_Z  + 8 _Z - 17, 1.744562647)}

> fsolve(eval(diff(g,x),y=1.744562647),x=-2..0);
                                 -0.9993234538

> eval(g,[x=-0.9993234538,y=1.744562647]);
                                              10
                               0.2195069718 10
You might then wonder whether the plot is accurate, or whether g is unbounded near the special y value.
> evalf[30](eval(g,[x=-1.0,y=RootOf(_Z^2+8*_Z-17,1.744562647)]));
                                Float(infinity)

> evalf[30](eval(denom(g),[x=-1.0,y=RootOf(_Z^2+8*_Z-17,1.744562647)]));
                                      0.

The warning about firewalls doesn't sound like it means a firewall is definitely always the cause. It sounds like it's just saying that it might be one possible cause.

The 1815M refers to the memory usage as shown in the status bar at bottom? That's the amount that Maple's kernel is using for calculations, I think. And then, then GUI itself is consuming some. I wonder whether, taken together, some (32bit Windows?) 2GB limit has been met.

What soft of architecture is your machine? Does it have more than just a single core or CPU? (Eg. is it a Core2 Duo?)

 

Is N going to be specified, or not? It wasn't clear to me, when you wrote that N was a parameter.

> G := (N,S) -> add(k, k in {$1..N} minus S):
> G(10,{2,4,5});
                                      44

> sum(k, k=1..N) - add(k, k in {2,4,5});
                                    2
                             (N + 1)
                             -------- - N/2 - 23/2
                                2

I get just an error about incorrect usage, using exactly your array() call as posted.

What does this give you?

with(combinat, fibonacci):
array([seq([k, fibonacci(k), modp(fibonacci(k)-1, 9)+1],
           k=0..4 )]);

This code is very simple-minded and doesn't completely prevent Maple from rolling several steps together.

As you can see, it works mostly OK on the first example but less clearly on the second. Maybe using op() would do it better. You could also try to make this more sophisticated by creating a procedure which acted recursively over sums and products. That would be a way to force almost every step to be shown. That would make displaying the cumulative results harder at each step.

> p := proc(eq,z)
> local sol, dsol, nsol;
>   sol := rhs(isolate(eq,z));
>   lprint(z = sol);
>   nsol,dsol := numer(sol),denom(sol);
>   nsol := eval(nsol,i=I);
>   nsol := subs(I=i,nsol);
>   printf("z = (%a)/(%a)\n",nsol,dsol);
>   dsol := eval(dsol,i=I);
>   dsol := subs(I=i,dsol);
>   printf("z = (%a)/(%a)\n",nsol,dsol);
>   sol := nsol/dsol;
>   lprint(z = sol);
>   if type(sol,`*`) then
>     sol := eval(sol,i=I);
>     lprint(z = sol);
>   end if;
>   z = sol,Re(z) = Re(evalc(sol)), Im(z) = Im(evalc(sol));
> end proc:


> p( (1-i)^2*z+(3-4*i)/(2-i)+i^30*(2-3*i) = 0, z );
z = (-(3-4*i)/(2-i)-i^30*(2-3*i))/(1-i)^2
z = (2+4*i)/((-2+i)*(-1+i)^2)
z = (2+4*i)/(2+4*i)
z = 1
                          z = 1, Re(z) = 1, Im(z) = 0
 
>
> p( (i+1-i)^2*z+(3-4*i)/(2-i)+i^30*(2-3*i) = 0, z );
z = -(3-4*i)/(2-i)-i^30*(2-3*i)
z = (2+4*i)/(-2+i)
z = (2+4*i)/(-2+i)
z = (2+4*i)/(-2+i)
z = -2*I
                        z = -2 I, Re(z) = 0, Im(z) = -2

I divide numerator and denominator by sinh(B*L)-cosh(B*L), "simplifying" both separately before dividing one by the other. That gets something with the desired final denominator. Now to handle a numerator which the human eye can easily see contains just a single simple cosh.

So I convert to trigh, but protect the sin and cos terms from this action. Otherwise all the sin and cos terms would also get converted to trigh, and that would result in too much of a mess for simplify to handle.

> A1 := A4*((exp(B*L))^2*v+v-2*cos(B*L)*exp(B*L)*v+4*sin(B*L)*exp(B*L)*B*L)
> /(v*((exp(B*L))^2-1-2*sin(B*L)*exp(B*L))):

> Q := collect(expand(numer(A1)*convert((sinh(B*L)-cosh(B*L),exp))),v)
> /simplify(expand(convert(denom(A1),trigh)*(sinh(B*L)-cosh(B*L))));

          /                  A4                   \
          |-A4 exp(B L) - -------- + 2 A4 cos(B L)| v - 4 A4 sin(B L) B L
          \               exp(B L)                /
      1/2 ---------------------------------------------------------------
                             v (-sinh(B L) + sin(B L))


> simplify(frontend(convert,[Q,trigh],
>                  [{`+`,`*`,specfunc(anything,`exp`)},{}]));


                 A4 (v cosh(B L) - v cos(B L) + 2 sin(B L) B L)
               - ----------------------------------------------
                           v (-sinh(B L) + sin(B L))

The magic part was in choosing sinh(B*L)-cosh(B*L) by which to divide numerator and denominator. That is the same as -exp(-B L), so maybe it's not hard to guess, given A1.

L := [seq(i, i = 1 .. 66)];
map(t->isprime(igcd(t, 66)),L);
map(t->`if`(isprime(igcd(t, 66)),t,NULL),L);
seq(isprime(igcd(t, 66)), t in L);
seq(`if`(isprime(igcd(t, 66)),t,NULL), t in L);
> A := <<1,2,3>|<4,5,6>|<7,8,9>>;
                                   [1    4    7]
                                   [           ]
                              A := [2    5    8]
                                   [           ]
                                   [3    6    9]
 
> LinearAlgebra:-ColumnOperation(A, [2,3]);
                                 [1    7    4]
                                 [           ]
                                 [2    8    5]
                                 [           ]
                                 [3    9    6]
First 46 47 48 Page 48 of 48