Joe Riel

8049 Reputation

22 Badges

15 years, 10 days

MaplePrimes Activity


These are replies submitted by Joe Riel

Thanks for pointing this out, Laurent. Curiously, the palette uses indexing and power for the right side indices, rather than the builtin fields. To enter this using Maple notation (and to avoid indexing and powers) do
`#mscripts(mi("base"),mi("lr"),mi("ur"),mi("b"),mi("t"),mi("ll"),mi("ul"))`;
How it works should then be apparent. To get this to work you need to open Tools > Options > Display and set Output to "Typeset Notation" and Typesetting Level to "Extended". Also note that you can use "none()" in place of "mi(whatever)" for unused slots. That shifts the locations of the displayed indices, sometimes for the better, sometimes not.
Yes, that is one way. Experience, however, has taught me that it really isn't worthwhile to pursue. First, it doesn't look very nice, the preceding indexes do not appear to be part of the base. Second, there are problems when the superscripts are negative. That can be fixed by enclosing them in the blank function (``(superscript)), however, the result is uglier than before. Third, notice what happens if the expression is raised to a power:
# updated index4 to handle negative superscripts
index4 := proc(var,ind)
  ``[ind[3]]^``(ind[1])*var[ind[4]]^``(ind[2])
end proc;
HH^2;
Both terms in the product are squared. You can try to patch that by modifying index4 to enclose the entire expression in the blank function:
index4 := proc(var,ind)
  ``(``[ind[3]]^``(ind[1])*var[ind[4]]^``(ind[2]))
end proc;
However, the "normal" result is uglier still. I've gone this route and decided it isn't worthwhile; it is better not to attempt to coerce Maple to do something it really cannot.
Yes, that is one way. Experience, however, has taught me that it really isn't worthwhile to pursue. First, it doesn't look very nice, the preceding indexes do not appear to be part of the base. Second, there are problems when the superscripts are negative. That can be fixed by enclosing them in the blank function (``(superscript)), however, the result is uglier than before. Third, notice what happens if the expression is raised to a power:
# updated index4 to handle negative superscripts
index4 := proc(var,ind)
  ``[ind[3]]^``(ind[1])*var[ind[4]]^``(ind[2])
end proc;
HH^2;
Both terms in the product are squared. You can try to patch that by modifying index4 to enclose the entire expression in the blank function:
index4 := proc(var,ind)
  ``(``[ind[3]]^``(ind[1])*var[ind[4]]^``(ind[2]))
end proc;
However, the "normal" result is uglier still. I've gone this route and decided it isn't worthwhile; it is better not to attempt to coerce Maple to do something it really cannot.
The tty interface (cmaple for Windows users) has command completion; the tab key.
Good question, I expected it from someone. Actually, the real mystery is, why, in your first example, does add return 14 here and not in the example I gave. The answer has to do with how the arguments of add are handled. Unlike with sum, they are not evaluated (I believe). However, at the user-level (say, in a worksheet) they are (sort of). Consider the following:
 
proc()
local i,y;
    y := i^2;
    i := 100;
    return [add(y,i=1..3)
            ,add(eval(y),i=1..3)
            ,eval(add(y,i=1..3))
           ];
end proc();
                                 2
                             [3 i , 14, 30000]
Explaining this will take a bit of hand-waving and I suspect I'll get it wrong.
Good question, I expected it from someone. Actually, the real mystery is, why, in your first example, does add return 14 here and not in the example I gave. The answer has to do with how the arguments of add are handled. Unlike with sum, they are not evaluated (I believe). However, at the user-level (say, in a worksheet) they are (sort of). Consider the following:
 
proc()
local i,y;
    y := i^2;
    i := 100;
    return [add(y,i=1..3)
            ,add(eval(y),i=1..3)
            ,eval(add(y,i=1..3))
           ];
end proc();
                                 2
                             [3 i , 14, 30000]
Explaining this will take a bit of hand-waving and I suspect I'll get it wrong.
A few thousand monomials is more than I would have guessed, and enough to have an effect, as you mention. It's neat that the technique has a useful application---my write up on sorting complex values was merely a demonstration vehicle though a related problem prompted the "discovery". Over the years I've looked for a good use for attributes, but hadn't recognized any until now. They are used a fair amount in the Slode package, but I haven't looked into how.
Using SFloat to convert an integer into an "equivalent" software float, so that it can take an attribute, is a nice extension. Thanks for sharing it. For those wondering what Roman is doing, here is the idea (I assume),
sortpolys := proc(polys,vars)
local p;
    return map(attributes
               ,sort([seq](setattribute(SFloat(degree(p,vars),0),p)
                           ,p = polys)));
end proc:
sortpolys([x^3+x, 1, x^2+x+1],x);
                                 2           3
                            [1, x  + x + 1, x  + x]

However, I wouldn't think that there would be much speed advantage of this compared to my method 2 (where the keys are precomputed but pairs are used for the comparison) except for fairly long lists. How many monomials do you have to sort? Is there a similar method for making any numeric quantity attributable while permitting it to be directly compared with other such numbers? SFloat can handle floats but not fractions:
SFloat(2.3, 0);
                 2.3
SFloat(2/3, 0);
Error, invalid arguments for Float constructor
I'd be reluctant to use evalf because of the possibility of round-off.
The general way to do this is with the frontend procedure. For this case, one could do
frontend(diff, [sin(x(t)), x(t)], [{specfunc(anything,sin)},{}] );
            cos(x(t))
Some time ago I wrote a small package for generating the Lagrangian equations of motions using this technique; I'll post it on my blog when I get a chance.
See the help page for arctan. The two argument form arctan(y,x) computes the principal value of the argument (i.e. the angle from the positive real axis) of the complex value x+I*y.
I'm not sure why your example fails. Consider the following:
subsindets((a+b)*(c+d),Not(integer),Q);
                       Q(Q(Q(a) + Q(b)) Q(Q(c) + Q(d)))
subs(Q=1,%);
                       1(1(1(a) + 1(b)) 1(1(c) + 1(d)))
eval(%);
                                       1
I'll have to look at subsindets a bit closer.
I'm not sure why your example fails. Consider the following:
subsindets((a+b)*(c+d),Not(integer),Q);
                       Q(Q(Q(a) + Q(b)) Q(Q(c) + Q(d)))
subs(Q=1,%);
                       1(1(1(a) + 1(b)) 1(1(c) + 1(d)))
eval(%);
                                       1
I'll have to look at subsindets a bit closer.
Your icoeff4 looks like the way to go. I was afraid that something like that might occur with subsindets (more precisely, the Not(integer)), but couldn't come up with a failing case. Thanks for finding that. I'm calling it a night...
Your icoeff4 looks like the way to go. I was afraid that something like that might occur with subsindets (more precisely, the Not(integer)), but couldn't come up with a failing case. Thanks for finding that. I'm calling it a night...
I had already done that, but out of necessity because I already had an icoeff4.
First 173 174 175 176 177 178 179 Page 175 of 182