How would one save the user-assigned variables in such a session as below?
a:=proc() local x; x; end:
x:=5;
y:=a();
Is y "user-assigned"? The fact that it was assigned an escaped local appears lost, using anames(user) or anames(alluser) and the technique suggested. Is there some easy modification to get around that?
Are there other problematic cases? (Maybe using modules, or anonymous modules created by a parent module's ModuleApply, or...?) Is a .mla sufficient to store the whole "user-defined" state? Should there be a mechanism to store everything (including the nature of the localness of all locals)?
acer
I believe that objects are all over the place, in memory. The only data that I know to be stored in a contiguous segments is that of "hardware" datatype rtables (which is why vendor or cache-tuned BLAS are used).
If memory is all over, and the simpl table stores a hash value dependent upon memory location (and if that value appears in many other objects), then compacting all stored data is problematic. So fragmentation can be a problem.
You can see what I think is evidence of this in how much large hardware rtable creation can cause somewhat "unexpected" allocation increases -- there's free memory already allocated, but not a large enough contiguous piece.
acer
I believe that objects are all over the place, in memory. The only data that I know to be stored in a contiguous segments is that of "hardware" datatype rtables (which is why vendor or cache-tuned BLAS are used).
If memory is all over, and the simpl table stores a hash value dependent upon memory location (and if that value appears in many other objects), then compacting all stored data is problematic. So fragmentation can be a problem.
You can see what I think is evidence of this in how much large hardware rtable creation can cause somewhat "unexpected" allocation increases -- there's free memory already allocated, but not a large enough contiguous piece.
acer
The colour does vary, from leaf to leaf and tree to tree. As the green chlorophyll disappears, the yellows begin to show up. The red is usually due to converted sugars, I believe, which varies from tree to tree.
A quick web search indicates that the red is due to anthocyanins in the sap (pigments also found in cranberries, cherries, etc), and the yellow and orange is due to carotene type pigments (also found in carrots).
acer
showstat(curry);
It's a programming convenience.
acer
showstat(curry);
It's a programming convenience.
acer
Could you not have delayed evaluation by using uneval quotes?
define( '`&d`' , 'orderless', &d( a::list, b::list ) = 'simplify(sqrt(add( (a[i]-b[i])^2, i=1..nops(a))))' );
[1,2,3,4,5] &d [4,3,2,1,0];
Isn't define() showing maple's usual evaluation rules?
If you would want that changed, for define(), then how precisely?
In any case, the help-page ?define could be made to explain this.
acer
Yes, of course, sorry. The rest still holds, I think.
But we seemed to agree that andmap only got called once for product 2*a, which is wrong.
I wonder whether it relates to the fact that 2*a dismantles to a SUM, and not a PROD.
acer
It looks like it is going wrong, for the multiplication.
andmap(A,2*a) is calling A just once, with argument 2.
Compare with ormap(A,c*a*b), for which A gets called three times, with arguments a, b, and c.
Interestingly, andmap(A,c*a*b) also calls A just once. It seems that andmap is considering only a single operand of a product, while ormap considers all the operands. I wonder whether the problem is restricted to andmap and products.
acer
So the user has to do this optional thing, explicitly, to get the .mw file to save enough about the parsed meaning for it to be reproducible when re-executed by someone else?
And if that optional thing (involving Typesetting[Settings]) is not done then the worksheet works for the original user regardless? And the natural method of 2D Math input can provide the user's desired parsed meaning for something, without having to do that optional thing?
That isn't a good design.
It'd be OK for some display characteristics (display of floats, etc) to be different. And different security settings should be respected. But parsed meaning of the input, that should be preserved. The author should not have to do anything special, for the intended parsed meaning to be saved along with the file, so as to allow correct reproduction upon execution elsewhere.
Moreover, the typesetting settings of any other user should control only what they themselves enter. Having the user's settings affect re-execution of pre-existing worksheets, by reparsing the input as if it were being re-entered altogether, is not good.
I'm having a hard time believing that this is the default behaviour, and that things can be that bad if the original author does not take an extra unobvious step. I'm hoping that I've misunderstood.
acer
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
