acer

30214 Reputation

29 Badges

18 years, 242 days
Ontario, Canada

Social Networks and Content at Maplesoft.com

MaplePrimes Activity


These are replies submitted by acer

Yes, these waters can get muddy. I guessed that he was having problems with implicit multiplication because I had to fill in the missing `*`s when using the 1D input from the properties of his post's gif image. But I wasn't sure that it wasn't an artefact of some conversion by mapleprimes. So I just filled in the corrections and added a sidenote. Implicit multiplication, and 2D Math input in general, is harder to debug when the code is not one's own because of such additonal ambiguities. I suppose that his claim about failing with combine was stronger evidence.

May I ask, how did you yourself get his expression into Maple? Is there some easier way, when the 2D Math gets put up here in a post as an image?

acer

I ran the above code with Digits=32, in Maple 11 on 64bit Linux. After 1880 iterations through the loop Maple claimed to have allocated 80 million words of memory while the OS `top` utility showed the resident memory allocation slowly climb to 750MB.

That indicates a memory leak, likely related to software float external calling. It may be similar to the what was reported here for Maple 10.

acer

I ran the above code with Digits=32, in Maple 11 on 64bit Linux. After 1880 iterations through the loop Maple claimed to have allocated 80 million words of memory while the OS `top` utility showed the resident memory allocation slowly climb to 750MB.

That indicates a memory leak, likely related to software float external calling. It may be similar to the what was reported here for Maple 10.

acer

It's not true that, "when the number of equations equals the number of unknowns there was a unique solution."

There are three possibilities, when there are n linear equations in n unknowns.

The first possibility is that there are no solutions. The system of equations is usually called inconsistent in this situation. An example could be something like this,

x + y = 2;
2*x + 2*y = 11;

A second possibility is that there are infinitely many solutions. This is often called an underdetermined system. It can arise when one of the equations is a multiple of another (or a linear combination of several other) of the equations. As a result of that, there is not enough data to forcibly pin the variables down to single unique solution values. A simple example is this,

x + y = 2;
2*x + 2*y = 4;

The third possibility is that there is a unique solution.

A discipline of mathematics that formalizes all the above and provides ways to look at and get insight into it is Linear Algebra. Representing the linear multivariate equations as a Matrix, and manipulating that object, can provide nice neat ways to demonstrate which of the three situations above (related to the number of possible solutions) is the case at hand for given data.

acer

It's not true that, "when the number of equations equals the number of unknowns there was a unique solution."

There are three possibilities, when there are n linear equations in n unknowns.

The first possibility is that there are no solutions. The system of equations is usually called inconsistent in this situation. An example could be something like this,

x + y = 2;
2*x + 2*y = 11;

A second possibility is that there are infinitely many solutions. This is often called an underdetermined system. It can arise when one of the equations is a multiple of another (or a linear combination of several other) of the equations. As a result of that, there is not enough data to forcibly pin the variables down to single unique solution values. A simple example is this,

x + y = 2;
2*x + 2*y = 4;

The third possibility is that there is a unique solution.

A discipline of mathematics that formalizes all the above and provides ways to look at and get insight into it is Linear Algebra. Representing the linear multivariate equations as a Matrix, and manipulating that object, can provide nice neat ways to demonstrate which of the three situations above (related to the number of possible solutions) is the case at hand for given data.

acer

Some years ago, I was faced with a similar problem. And using resultant() is not always a possible solution, since the two surfaces or curves might not be represented as polynomials. In my situation, there were a pair of surfaces given as (blackbox, say) procedures of x- and y-parameters.

My solution, if I recall correctly, was to use implicitplot to produce a 2-dimensional PLOT structure (which represented how the desired 3-d spacecure would look if projected onto the x-y plane. Then the data within it could be lifted up to the height of (either, since it is where they intersect) surface, and thrown into a PLOT3D structure.

Of course, creating the implicitplot result as that first step was possible because the pair of surfaces were explicit forms for height z.

Maybe someone else (without Maple 11 say) might be able to use that approach too. I should peek into plots[intersectplot] and see if it works the same way for similar cases.

acer

There are several possible variants on the following. (Which you get might well depend on the style of whoever answered.)

EQ1:=unapply(eq1,lambda);
plot( t->fsolve(subs(alpha=t,eval(EQ1)),Pi/2..3*Pi/2), 1..2 );

acer

There are several possible variants on the following. (Which you get might well depend on the style of whoever answered.)

EQ1:=unapply(eq1,lambda);
plot( t->fsolve(subs(alpha=t,eval(EQ1)),Pi/2..3*Pi/2), 1..2 );

acer

I believe that, in the original blog entry above, I mentioned that the help-pages claim that all built-ins allow for that "global namespace" extension mechanism. I'm not sure that that is still strictly speaking true (if it ever were). It's not obvious how all builtins would work with an extension. And only the more obvious ones (obvious also in the sense that it's easier to guess how an extension would work) are documented by example.

As far as TypeTools goes, I did specifically mention it as the modern replacement to `type/XXX` global namespace extensions in the original blog article (and refrenced two other posts by you on using that). Yes, the older mechanism would have to continue to work if (by definition) backwards compatibility were to be adhered to on this issue.

It's true, I did not mention a few newer packages (like Units, or VerifyTools), partly  because they already handle extension management in more flexible or modern ways. I would rather see a Print package and a Verification package which exported their own extension management routines than I would a whole slew of "Tools" packages. That term isn't even in vogue any more, and already looks dated. But also I would like to see the extension closer to the direct use functionality, and not in separate packages unless necessary or unless there were already a top-level routine for use such as `latex` and `verify`.

The jumble of extension mechanisms in Maple is incredible. It doesn't help so much to get stuck on why or how it became so. The thing is, what can be best done about it now? I see two possibilities that are workable.

The first is to have a really ulta-consistent mechanism that works across all areas (from typesetting to type to everything else) and which is not impossible to explain. The second is to have a set of documentation which explains in minute detail all the nuances of a highly variegated (and possibly inconsistent) set of extensions mechanisms. Unfortunately, Maple currently has all the diversity and variety, but without the crystal clear documentation. Either the consistency or the documentation has to be greatly amended in order for the extension system to be good.

acer

Isn't that Vector c, when using LPSolve in that "Matrix form" of calling sequence, the coefficient vector of the linear objective function?

If that were so then that reported error message about the contraints would be misleading/mistaken.

acer

Isn't that Vector c, when using LPSolve in that "Matrix form" of calling sequence, the coefficient vector of the linear objective function?

If that were so then that reported error message about the contraints would be misleading/mistaken.

acer

Thanks for that, about mint. I don't know what I could have been thinking.

Yes, there are some gotchas when using code based on Maple 11's parameter-processing but within a Maple 10 session.

acer

Thanks for that, about mint. I don't know what I could have been thinking.

Yes, there are some gotchas when using code based on Maple 11's parameter-processing but within a Maple 10 session.

acer

It looks like the result of your last transform() call is, in Maple 8, a PLOT3D rather than a PLOT call. But the data within it looks like 2-dimensional plotting data.

So try this..

zzz := transform((x,y,z)->[x,y])(FG):
type(zzz,specfunc(anything,PLOT3D));
PLOT(op(zzz));

acer

Since freeof is not protected and may have been assigned a value by the user, or may be used alongside a local of the same same from within a procedure, that call would be better as,

select(type,expr,':-freeof'(vars)):

It bothers me a little, that the help-pages like ?type,freeof don't show it being used that way. That's also a general complaint I have about many help-pages -- the lack of uneval quotes in examples where they may be necessary in a general context. I also wonder why mint doesn't complain about this example.

 

acer

First 511 512 513 514 515 516 517 Last Page 513 of 553