@Carl Love It is not necessary to convert the COLOR data to the (larger in memory) listlist structure. An Array will do (and it already is datatype=float[8] by the import).

By using ranges in the list argument to ArrayTools:-Alias (or ArrayTools:-Reshape) one can obtain an Array rather than a Matrix. Actually, a 1D Array could also serve here.

Download sphrdat.mw

@fhqtmso Yes, I understood what you wanted, I think. You want an unevaluated function call with arguments like T,z and the name of the operator should be the conjoining of capital greek Delta and lowercase greek epsilon (all nicely typeset).

I believe the problem is that Maple uses & (ampersand) in two special ways for typesetting. The older use is that a name beginng with ampersand typesets as an infix operator. This can be useful. The more recent mechanism that uses ampersand in a special way is that the underlying plaintext code representation of specially typeset names (including conjoined greek letters) are names with ampersand as first character. An unevaluated function call with a function name such as yours hits the unfortunate intersection of these two uses. 

If you just needed that call as if it were an expression tthen you could put name (single left-) quotes around the whole thing, including the (T,z) bit. But then that bracketed bit might display in italics. I don't have Maple at hand, to test. Perhaps someone could test, or think of another workaround.

@nm It's possible to imagine someone trying to create a name of so-called atomic identifiers (in undocumented TypeMK), and then finding that the 2D math output getting getting rendered as an infix call (even if lprint might reveal the structure to stop be just an unevaluated functions n call).

So, not so ridiculous on the part of the user, if it's a result of 1D/2D input awkwardness and documentation confusion.

Perhaps the OP could explain what is really wanted, in terms of the function name, font style (italic/Roman?), etc.

@nm There is no need for the `=` in the call to assign. The usual and robust way to use it in your example would be more like,

  assign( 'result' , dsolve(...) )

In that way you would not have to unassign `result`. In your previous version , on the repeated call, `assign` was being passed something other than a name as the (lhs of an equation as) first argument (normal evaluation rules).

@Mac Dude .mla can store a whole module, but in general .m cannot.

So yes indeed a module should be stored in a .mla file instead of a .m file.

The savelib command is not deprecated.

(In my not so humble opinion the save command should have been changed, so as to write out to .mla rather that .m and thus be able to handle modules etc, in Maple 6 or 7. Oh well.)

It seems that both `plot` and `Optimization` suffer because by default they both may attempt to evaluate under `evalhf` and be restricted to values (+/-) in the ranges of about 1e-307 to 1e308.

For plotting this is fixed by scaling (...and reminds me a bit of this).

For Optimization:-Maximize (NLPSolve) it suffices to prevent evalhf and bump up working precision Digits just a little. The `type` check in `H` below helps bypass evalhf-mode evaluations of the objective. The scaling of the objective is not necessary here.

By setting UseHardwareFloats to false I can get a result accurate to a handful of digits just by increasing Digits to about 12 or 13 (which normally would still allow hardware precision objective evaluations via evalhf, if UseHardwareFloats had its default value of `deduced`). But below I use Digits=30, regardless.

In short, very high working precision is not necessary to solve the problem, though it may be one easy way to force it.

restart:

f := (a, b, k) -> (Sum(exp(-x)*x^m/(m!), m = a .. b))^k:

h := f(0,0,82)*f(1,3,49)*f(4,6,47)*f(7,10,47)*f(11,15,57)*f(16,20,40)
     *f(21,25,38)*f(26,35,52)*(1-f(0,35,1))^91:

H:=proc(X)
     if not type(X,numeric) then
       return 'procname'(args);
     end if;
     evalf(subs(x=X,h)):
end proc:

Digits:=30:
UseHardwareFloats:=false:

Optimization:-Maximize(H(x),x=0..20)[2];

                    [x = 15.6881165580848572618920824132]

#plot(10^(1550)*H(x), x=0..20);

@rit You really didn't answer my queries for clarification. I'll wait for you to clarify, and answer them all, before I continue, thanks.

Let me ask another question then, in the meantime: if you had some kind of general eigenvector solution to your problem with a mix of float entries and (at least one) symbolic entry x, then what would you do with that solution?

I notice that you have not addressed my claim that the formulas you were passing to `solve` -- in your attempt to compute the eigenvectors -- was not right. Yet in at least one other thread on this site you still mention that it leads just to the all zero-Vector trivial solution.

@rit You should characterize what you will accept as an optimal solution -- it's your example, after all.

Please stop spamming this site with repetitions and variants of the same question. If you have followup comments that are relevant, then just add them here.

@rit 

restart:

obj:=f(x1,x2,x3);

with(Student:-VectorCalculus):

Hessian(obj,[x1,x2,x3]);

Jacobian(Gradient(obj,[x1,x2,x3]),[x1,x2,x3]);

@abscissa It may be pertinent. It happens quite often that people ask computer algebra systems for the general symbolic form of a solution, not realizing that such a general symbolic result might be too large or unweildy to be useful even it it could be computed.

Sometimes it turns out that the evenutal intended use would be to evaluate that (potentially huge) result at purely numeric values. In which case it might make better sense instead to construct a procedure which accepts the numeric values and returns numeric results. Or it might be that simplification or further manipulation under certain substitutions or restrictions of the (potentially unweildy) symbolic result it intended, in which case an alternative might be to utilize such prior to attempting a symbolic solution.

These and similar situations are not uncommon. That's why I asked. If you have additional information or background to the problem then providing it here might help. Or not.

@rit You have two expressions f1 and f2, both in terms of x1 and x2. It appears that you are trying to somehow optimize both, by somehow combining both into a single objective. I think that you should tell us what definitively is the single objective that you want to optimize, or at least what are all the criteria for which you would accept x1,x2 values as representing the optimum.

If you cannot do that, explicitly, then I don't see how we could do much more than guess at what you are trying to accomplish.

Suppose that Maple were to produce a symbolic representation of the general problem, and that it were say a hundred pages long. What would you do next with it?

acer

@rit I don't understand what you are saying.

What is the reason that you cannot use LinearAlgebra:-Eigenvectors? Is it because you have an unassigned symbol as well as floats in the Matrix of your actual problem? That is, your purely float Matrix posted above is just a toy example and not your actual input Matrix?

A sign difference (only) in eigenvectors is not in itself indicative of an accuracy problem. If Vector x is an eigenvector associated with eigenvalue lambda then its negation -x is also an eigenvector. That follows from the definition, and because this is linear algebra.

If you have a discipline specific reason (Physics, say) for wanting a particular sign (or leading sign?), then that's another story. How do you expect the general readership here to understand your statements that this relates to "quantum events"?

What do you mean by, "absolute values of the eigenvectors"? If <-3, 4, -5> is an eigenvector then it doesn't follow that <3, 4, 5> has to be one too.

What do you mean by, "doing multiply operation between eigenvectors"? Is your answer to that going to consist of a discipline specific answer?

@TomM You're welcome for what I believe to be accurate answers to your several questions.

I'm not going to argue with you, however.

@TomM You also wrote, "Well, none of the deimostrations for either Math Apps or Möbius Apps work on the web. There is also no information on downloading them so that I can run from my own Maple."

Worksheets can be served up over the web from a MapleNet server. If such a worksheet contains Embedded Components (ie. are an Application) then the interactive components are accessible via the web interface (browser). Here's a example, which is very slow.

Math Apps are bundled inside your Maple installation itself, and can be found via the Help system. As for obtaining Apps from the Cloud. First open the Cloud palette in your Maple 18. There is a menu item which can show a variety of Mobius apps which can be opened straight into the current GUI session (and saved from there if you want). See the Help page here and here.

Here's an example of another App served up via MapleNet. It's no as slow as the previous one I mentioned. It allows interaction with embedded slider components.

The search facility on this page seems broken, if one restricts to say "web-ready". But I found the "Vertex of a Parabola" App mentioned in the last paragraph by just selecting "All" in the left drop-menu on that page.