Does the .mw file itself save any preferences that dictate how "ambiguous" typed 2D input expressions such as 2(x+y) is to be parsed? If not, then how do you debug a problematic worksheet sent from someone else? Or does the input somehow become an "object", as opposed to mere syntax? Would the typesetting itself embed the distinction, and if so would one still need to convert it to 1D maple input in order to understand it for debugging purposes? acer

Forgetting the original posted problem for now, suppose that one wants eigenvectors corresponding to eigenvalue of 1, and only if 1 is indeed an eigenvalue. In such a scenario, computing all the eigenvalues and eigenvectors, and then checking for eigenvalue 1, is a bad algorithm and not use of a golden hammer. One reason for this is that it may do at least n times too much work trying to get explicit results, since not all eigensolutions could be needed for the result. A second reason is that testing a polynomial for a given candidate root is a completely different and far less difficult problem in general than trying to solve for all roots and then checking whether 1 is such a root. For high degree polynomials, these two tasks are not at all in the same class. acer

Forgetting the original posted problem for now, suppose that one wants eigenvectors corresponding to eigenvalue of 1, and only if 1 is indeed an eigenvalue. In such a scenario, computing all the eigenvalues and eigenvectors, and then checking for eigenvalue 1, is a bad algorithm and not use of a golden hammer. One reason for this is that it may do at least n times too much work trying to get explicit results, since not all eigensolutions could be needed for the result. A second reason is that testing a polynomial for a given candidate root is a completely different and far less difficult problem in general than trying to solve for all roots and then checking whether 1 is such a root. For high degree polynomials, these two tasks are not at all in the same class. acer

Did you write that the system is 28x28 with exact entries? If you only can make use of eigenvectors corresponding to a specific value as an eigenvalue, then why not test that eigenvalue first? You can test it quickly by using the characteristic polynomial. Then, if 1 is indeed a root, you could substitute 1 into the charcteristic matrix and then get the nullspace of that for the corresponding eigenvectors. And to get the nullspace, you could also use LinearSolve with the RHS as zero-Vector, in which case you could control via Normalizer & Testzero how hard you would want it to work on RootOfs. ps. It'd be a relatively nice shortcut, to have a function to compute an eigenspace of a Matrix, for a given eigenvalue. It'd be useful for floats, too. acer

Did you write that the system is 28x28 with exact entries? If you only can make use of eigenvectors corresponding to a specific value as an eigenvalue, then why not test that eigenvalue first? You can test it quickly by using the characteristic polynomial. Then, if 1 is indeed a root, you could substitute 1 into the charcteristic matrix and then get the nullspace of that for the corresponding eigenvectors. And to get the nullspace, you could also use LinearSolve with the RHS as zero-Vector, in which case you could control via Normalizer & Testzero how hard you would want it to work on RootOfs. ps. It'd be a relatively nice shortcut, to have a function to compute an eigenspace of a Matrix, for a given eigenvalue. It'd be useful for floats, too. acer

I see that I misunderstood you, Robert. Sorry. Perhaps I am just too used to the notion of the kernel not making the same checks for recursive assignment, within procedure calls as at the top-level, to be surprised by it. Here's another simple example, V := Vector(1,V); restart: p := proc() local V; V := Vector(1,V); end proc: p(): %; Quite a few (and maybe most) of the checks on recursive assignment done at the top-level can be defeated with a bit of ingenuity. Because of that, I suspect that the checks form a somewhat loose grab-bag of techniques. Perhaps the task of checking is currently impossible to make bulletproof in the maple engine. I don't know whether the rationale for not checking within procedure calls is that it is more technically difficult, or that it is considered less crucial for the programming "expert", or that there simply have not been resources to do it yet. acer

It should not be surprising that maple does not issue an error here, because the validity will depend on the value of N only when the procedure gets called. At the top-level, maple can check immediately for an invalid recursive definition. But naturally when put inside a procedure an immediate check doesn't make sense. (This is made even more so by N's being a global variable of the procedure.) The technique might be indicative of an inefficient maple programming technique, but it's not invalid in and of itself. It's an example illustrating some undesirable maple programming techniques, eg, possible repeated appending to lists, no proper argument checking, unnecesary use of a global when apparently another parameter would also serve, etc. acer

I've been playing the update game for so many years that, when a point-release comes out, I prefer to have both it *and* any earlier original. I find this pretty straightforward on Linux. I suspect that it might be awkward on Windows, if there is registry nonsense to deal with. Suppose I have Maple 11.00 installed under /usr/local/maple11 , for example. Then along comes 11.01 as an upgrade. I'll copy all of /usr/local/maple11 to, say, /usr/local/maple11.01 with something like a `cp -a` or `cp -dpr`. Then by hand I'll edit three or so scripts within the /usr/local/maple11.01/bin directory. I'll change the MAPLE variable in those scripts, to agree with this new location. And only then, will I run the updater. And of course when prompted for the whereabouts of my Maple 11 I'll tell it about the new /usr/local/maple11.01 location. And to top it all off, I usually either put in symlinks like, ln -s /usr/local/maple11.01/bin/maple /usr/local/bin/maple11.01 or I add an alias for that to my .bashrc file. By doing all this, I'll end up with both 11.01 as well as 11.00 available. Just in case. Now I just need names for the "original" 11.01 and this later modified 11.01. acer

It may do something special. It might be that it knows how to do something special in the compiled external routine 'MapleChiSquareDeviate'. Or that may have its own rootfinder. It doesn't appear to call fsolve. kernelopts(opaquemodules=false): with(Statistics): df := 29: chiSquare := RandomVariable(ChiSquare(df)): H:=Statistics:-Distributions:-DataStructure:-GetDistribution(eval(chiSquare)): lprint(eval(H)); HH:=Statistics:-Distributions:-DataStructure:-GetQuantity(H,QuantileNumeric); HH(0.95); stopat(fsolve): HH(0.85); acer

It may do something special. It might be that it knows how to do something special in the compiled external routine 'MapleChiSquareDeviate'. Or that may have its own rootfinder. It doesn't appear to call fsolve. kernelopts(opaquemodules=false): with(Statistics): df := 29: chiSquare := RandomVariable(ChiSquare(df)): H:=Statistics:-Distributions:-DataStructure:-GetDistribution(eval(chiSquare)): lprint(eval(H)); HH:=Statistics:-Distributions:-DataStructure:-GetQuantity(H,QuantileNumeric); HH(0.95); stopat(fsolve): HH(0.85); acer

That's interesting. Thanks for showing us. I wonder whether I missed seeing that, in the Typsetting help-pages or assistant. acer

That's interesting. Thanks for showing us. I wonder whether I missed seeing that, in the Typsetting help-pages or assistant. acer

Is the 11.01 update available on CD? Could a user who's purchased 11.00 get 11.01 CD, either as a partial update or as the full install? acer

The help-page ?Statistics,Fit says that it will end up calling either Statistics[LinearFit] or Statistics[NonlinearFit] to do the actual work. The routine Statistics[NonlinearFit] takes an optional argument which specifies ranges for the parameters. See ?Statistics,Regression,Options for details. An example might look something like this, Statistics[NonlinearFit](...., parameterranges = [a=0..infinity,b=0..infinity,w=0..infinity,t0=0..infinity]); acer

The help-page ?Statistics,Fit says that it will end up calling either Statistics[LinearFit] or Statistics[NonlinearFit] to do the actual work. The routine Statistics[NonlinearFit] takes an optional argument which specifies ranges for the parameters. See ?Statistics,Regression,Options for details. An example might look something like this, Statistics[NonlinearFit](...., parameterranges = [a=0..infinity,b=0..infinity,w=0..infinity,t0=0..infinity]); acer