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

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

I've never been able to decide whether I liked codegen[JACOBIAN]. On the one hand it often makes something which is easier to evalhf (or use Compiler:-Compile on, after maybe transcribing and editing). But on the other hand it's awkward if it fails on some of the procs, or if the input/output of data doesn't match. And I don't like how it can create workspaces internally, as I like to be able to cut out that sort of collectible garbage production.

So these days I tend to use `D`, and the newer `fdiff` routine, and the nice way that evalf(D(...)) can call fdiff.

Sometimes I use those together, evalf and D, but in two steps so that D can actually produce an explicit result for the easier procedures. Something like,

J:=unapply(Matrix(nops(funlist),numvars,(i,j)->D[j](funlist[i])(a,b)),[a,b]);

followed shortly afterwards by something like,

evalf(J(seq(X[count-1][jj],jj=1..numvars)))

So the above has that nice aspect, that the D can actually produce a new proc whose body is explicitly differentiated from the original proc. (I mention this for others here, not you of course, Robert.) And then whichever entries of J come back as unevaluated `D` calls will then get hit by evalf and the evalf(D(..)) will become fdiff calls. It's almost the best of both worlds. The only thing that I don't like about it is that it creates quite a few new Matrices, each time the Jacobian is updated with new point X, which can be inefficient even if those Matrices are collectible garbage.

So sometimes I do it instead like this,

funlist:=[f,g]:
numvars:=2: # or use nops([op(3,eval(f))])
dummyseq:=seq(dummy[i],i=1..numvars);
J:=Matrix(nops(funlist),numvars,
  (i,j)->unapply(fdiff(funlist[i],[j],[dummyseq]),[dummyseq]));
thisJ := Matrix(nops(funlist),numvars,datatype=complex(float)):

and then each iteration through I have it assign,

thisJ[i,j] := J[i,j](currXseq);

in a double-loop where,

currXseq:=seq(X[count-1][jj],jj=1..numvars);

I have an somewhat decent routine for Newton's method for procs, that works this way. Maybe I can dust it off and post it as a blog item.

acer

I've never been able to decide whether I liked codegen[JACOBIAN]. On the one hand it often makes something which is easier to evalhf (or use Compiler:-Compile on, after maybe transcribing and editing). But on the other hand it's awkward if it fails on some of the procs, or if the input/output of data doesn't match. And I don't like how it can create workspaces internally, as I like to be able to cut out that sort of collectible garbage production.

So these days I tend to use `D`, and the newer `fdiff` routine, and the nice way that evalf(D(...)) can call fdiff.

Sometimes I use those together, evalf and D, but in two steps so that D can actually produce an explicit result for the easier procedures. Something like,

J:=unapply(Matrix(nops(funlist),numvars,(i,j)->D[j](funlist[i])(a,b)),[a,b]);

followed shortly afterwards by something like,

evalf(J(seq(X[count-1][jj],jj=1..numvars)))

So the above has that nice aspect, that the D can actually produce a new proc whose body is explicitly differentiated from the original proc. (I mention this for others here, not you of course, Robert.) And then whichever entries of J come back as unevaluated `D` calls will then get hit by evalf and the evalf(D(..)) will become fdiff calls. It's almost the best of both worlds. The only thing that I don't like about it is that it creates quite a few new Matrices, each time the Jacobian is updated with new point X, which can be inefficient even if those Matrices are collectible garbage.

So sometimes I do it instead like this,

funlist:=[f,g]:
numvars:=2: # or use nops([op(3,eval(f))])
dummyseq:=seq(dummy[i],i=1..numvars);
J:=Matrix(nops(funlist),numvars,
  (i,j)->unapply(fdiff(funlist[i],[j],[dummyseq]),[dummyseq]));
thisJ := Matrix(nops(funlist),numvars,datatype=complex(float)):

and then each iteration through I have it assign,

thisJ[i,j] := J[i,j](currXseq);

in a double-loop where,

currXseq:=seq(X[count-1][jj],jj=1..numvars);

I have an somewhat decent routine for Newton's method for procs, that works this way. Maybe I can dust it off and post it as a blog item.

acer

I'd like to clarify a few things in that paragraph,

The condition number is a common measure of the closeness of a matrix to being singular. In general, we want to keep the condition number small but there is no firm limit to what small means.

The first is that conditioning is generally a quality of numerical computations, but it so happens that the condition number associated with solving linear systems (or doing matrix inversion) accurately turns out to be a property entirely of the matrix. The number which estimates the condition of this problem is often known as the condition number of a matrix.

The situation where that condition number is infinity is a usual definition of a matrix's being singular. Numbers can also be found to estimate the conditioning of some other linear algebra computations such as eigen-solving and singular value estimation.

For this particular condition number of system solving there is a firm limit of how small it may be, which is 1. What's not firm is how far from 1 the condition number must be for the term ill-conditioned to be applicable to the matrix.

acer

I'd like to clarify a few things in that paragraph,

The condition number is a common measure of the closeness of a matrix to being singular. In general, we want to keep the condition number small but there is no firm limit to what small means.

The first is that conditioning is generally a quality of numerical computations, but it so happens that the condition number associated with solving linear systems (or doing matrix inversion) accurately turns out to be a property entirely of the matrix. The number which estimates the condition of this problem is often known as the condition number of a matrix.

The situation where that condition number is infinity is a usual definition of a matrix's being singular. Numbers can also be found to estimate the conditioning of some other linear algebra computations such as eigen-solving and singular value estimation.

For this particular condition number of system solving there is a firm limit of how small it may be, which is 1. What's not firm is how far from 1 the condition number must be for the term ill-conditioned to be applicable to the matrix.

acer