acer

32343 Reputation

29 Badges

19 years, 326 days
Ontario, Canada

Social Networks and Content at Maplesoft.com

MaplePrimes Activity


These are replies submitted by acer

@nm Ok, so you only need assertion-checking for the local-variable and return-value type checks of your own procedures. That's more detail.

In that case either of the ways I showed of temporarily disabling certain kinds of assertion-checking in your calls to Library code might help with the kind of example you've shown.

@nm You've written a little more about how you set it, but I was talking about how you need to use it. Without an adequate description of your usage requirements most answers will be guesses.

Do you have an example showing how it might be done standalone with UMFPACK, without use of Maple? That would be a useful first step, showing how (and whether) it could be done. If possible and provided, then a Maple custom external-calliing wrapper might be based upon it.

@Tokoro In future please put your more general query (along with specialized cases) in a single Question thread, instead of unhelpfully splitting the details and responses amongst several distinct Question threads.

Please stop submitting your queries as Posts, instead of Questions.

@Tamour_Zubair It's not really clear what you're trying to accomplish.

Could it be something like this?

evalf[15](Int(p*cos((1/2)*p+(1/2)*q)/(p^2+q^2)^(1/2),
              [p=0..1, q=0..1]));

                       0.553945861053642

Do you know a numeric value for the unknown t?

@Carl Love The stock EscapeTime command constructs an Image (or an Array of values) with a B&W layer of values based on the number of iterations required to escape (or possibly another layer, of abs value).

It does not classify & colour the values according to the root to which it converges -- as requested by the OP.

Somewhere I have a modified and reasonably fast version that does that... but I'm quite pressed right now.

@Rouben Rostamian  Here's one way to implement such conversions (just the double-angle, not a full trig combine) in the other direction, optionally recursing.

convert_double_angle.mw

(Sorry, this site isn't letting me inline the worksheet.)

@Rouben Rostamian  You have not specified in advance what you want to happen in general. I gave a piece of code for the examples supplied so far, and suggested it might be further adjusted.

The crux of my code snippet was to selectively freeze/veil some of the trig calls present in the expression, using foldl and frontend. It need not be combine that actually applies some conversion rule -- I was just continuing on with the theme. (It may be possible to turn powers of some trig call into an unsimplified product of "distinct" terms, for which certain rules might be more readily recognized...)

The original question thread was about elementwise applyrule.

Perhaps you could put your double-angle query (characterized in full) in its own Question thread (possibly branched from here).

And perhaps you could put your half-angle query (characterized in full) in another thread (possibly branched from here). It's quite different in nature.

Providing more general examples and expectations up front helps avoid the coding version of the whack-a-mole game.

Let's consider your last example. You haven't specified precedence of intended rules for that direction, so there ambiguity in the example. Starting from your,
   4*sin(x)^2*cos(x)
it was not clear that one should produce,
    2*sin(x)*sin(2*x)
over, say,
    2*(1-cos(2*x))*cos(x)
(Sure, you've since stated which you'd prefer. But a clear characterization up front would be helpful.)

@dojodr You are the one who asked for the symbolic solution, so only you know what you wanted to do with it.

Here are some alternatives:

restart;

eq := A=P*(1+r/n)^(n*t);

A = P*(1+r/n)^(n*t)

# First way: plug in values for r and t,
# and then call `solve`.

eval(eq, [r=0.05,t=8]);
solve(%,n);

A = P*(1+0.5e-1/n)^(8*n)

-.2500000000*ln(A/P)/(2.*LambertW(-2.500000000*ln(A/P)/(A/P)^(5/2))+5.*ln(A/P))

# more general form
ans:=combine(simplify(evalindets(solve(eq,n,allsolutions),
                                 suffixed(_Z),u->0)));

-r*ln(A/P)/(LambertW(-ln(A/P)*(A/P)^(-1/(r*t))/(r*t))*r*t+ln(A/P))

# Plug in same values as before, and
# get same result (in a different way).

eval(ans, [r=0.05,t=8]);

-0.5e-1*ln(A/P)/(.40*LambertW(-2.500000000*ln(A/P)/(A/P)^2.500000000)+ln(A/P))

# Plug in numeric values for all parameters,
# and compute as floating-point with `evalf`.

evalf(eval(ans, [P=5,A=10,r=0.05,t=8]));

-0.7086797315e-1

# Alternatively, plug same values for parameters
# into the original equation, and then solve
# numerically with `fsolve`.

eval((rhs-lhs)(eq), [P=5,A=10,r=0.05,t=8]);
fsolve(%);

5*(1+0.5e-1/n)^(8*n)-10

-0.7086797317e-1

 

Download solve_ex2b.mw

As demonstrated above, you could numerically solve (fsolve) for n if all the other parameters are substituted with numeric values.

Or you could plug such numeric values for the parameters into the more symbolic solution ans.

So you might not actually need the symbolic form ans. (You asked about such a solution, which is why I showed how one such might be obtained programmatically. Only you know why you requested it.)

If you do want to deal with that symbolic solution then you cannot simply "disregard" the LambertW or another part of the symbolic expression that you might not fully understand or enjoy.

The command LambertW is a special function that expresses a solution to a special kind of equation. You probably are familiar with other special functions that express other mathematical relationships, eg. sin(x), cos(x). But because some others are so familiar you may overlook/forget that they're made-up names that act as stand-ins for the more complicated mathematical relationships.

@Rouben Rostamian  One could tweak this kind of thing,

H := E->subsindets(E, `*`,
                   u->foldl((ee,v)->frontend(combine,[ee],
                                             [{`+`,`*`,
                                               specfunc(identical(v),
                                                        {sin,cos})},{}]),
                            u, `union`(op~(indets(u,specfunc({sin,cos}))))[])):

 

4*sin(x)*cos(x)*sin(y)*cos(y);
H( % );
simplify(expand(% - %%));

4*sin(x)*cos(x)*sin(y)*cos(y)

sin(2*x)*sin(2*y)

0

3*sin(z)*cos(z);
H( % );
simplify(expand(% - %%));

3*sin(z)*cos(z)

(3/2)*sin(2*z)

0

sqrt(7*exp(1)*sin(z+p)*cos(z+p)*sin(x)^2*cos(x)^2*(2*cos(y)^2-1));
H( % );
simplify(expand(% - %%));

7^(1/2)*(exp(1)*sin(z+p)*cos(z+p)*sin(x)^2*cos(x)^2*(2*cos(y)^2-1))^(1/2)

7^(1/2)*(-(1/16)*exp(1)*cos(2*y)*(cos(4*x)-1)*sin(2*z+2*p))^(1/2)

0

Download trig_comb_sep.mw

There are interesting examples where a shortest (simplest) form can be attained by applying combine after repeatedly and selectively freezing only some of the trig terms. (Somewhere I have a variant of a "crusher" appliable-module which -- expensively -- tries combinations of such things, in a search for a shortest form.)

@mmcdara Increased memory use can be a consequence of running multiple computations in parallel. It's not necessarily a consequence only of using multiple kernels in parallel.

Even when you run multiple threads in parallel (in the same kernel) they might each get some local allocation. It depends on the nature of the computation. I just happen more often to use Threads for numeric Array computations that can often each be done "in-place" on specific portions of a preassigned hardware rtable container. So usually I don't happen to see additional memory consumption according to the number of threads. But that's just due to the kinds of computations I more often do.

I don't think that I can act in-place when using Grid, and I've also noticed a marked slowdown if a passed rtable if "too big". But sure, often there is a natural give-and-take between speed and memory consumption.

It's hard to make general statements: much of all this is problem specific.

@mmcdara The Grid package uses distinct instances of the Maple kernel (engine) for each node, with no cross-pollution of memory or assignments. Thus the issue of thread safety of the code is ameliorated.

The Threads package uses the same instance of the Maple kernel (engine) for all threads. So any code which relies (even indirectly, via whatever Library commands it calls) on global state is potentially thread-unsafe. And thread-unsafety cascades. So, for example, any Thread-ed code that calls symbolic-definite int is thread-unsafe because limit is thread-unsafe.

Many (if not most) important Library commands for symbolic computation are thread-unsafe. The situation is better for kernel builtin commands, but those are a minority.

Hence I typically use Threads only for purely numeric code that I can also run under evalhf or Compile. That is to say, code the calls few (if any) commands for symbolic computation.

@rlopez Thanks, Robert.

with(VectorCalculus): SetCoordinates('cartesian'[x,y]):

 

TangentLine(7*x^2-7*y^2-12.0*x+9.0*y+2.25-2*x*y=0,
            <0.504244923, 0.3781836925>);

-5.696938463*x+1.852714152+2.696938459*y = 0

isolate(%,y);

y = 2.112372436*x-.6869693841

Download hyp_tangVC.mw

First 112 113 114 115 116 117 118 Last Page 114 of 592