acer

Rubrum Acer

27078 Reputation

29 Badges

17 years, 70 days
Ontario, Canada

Social Networks and Content at Maplesoft.com

"You do not need to leave your room. Remain sitting at your table and listen. Do not even listen, simply wait, be quiet, still and solitary. The world will freely offer itself to you to be unmasked, it has no choice, it will roll in ecstasy at your feet." -- Franz Kafka

MaplePrimes Activity


These are replies submitted by acer

You could also do this, int(5*sec(2*x)^2, x); convert(%,tan); Note however that application of convert could turn all instances of trig functions in an expression into tan. You might not prefer the result of convert( sin(x), tan ) . acer
You could also do this, int(5*sec(2*x)^2, x); convert(%,tan); Note however that application of convert could turn all instances of trig functions in an expression into tan. You might not prefer the result of convert( sin(x), tan ) . acer
Thanks for mentioning one of the goals explicitly. It is true, in general my way would likely entail some system of symbols, chained in meaning, which would quickly become too burdensome as the examples got more involved. I do think that part of the ability to do abstract linear algebra well in Maple would also allow for the sort of symbolic manipulations of elements that you are trying to describe. Some people would want abstract linear algebra to allow for such element manipulation. Some would want to be able to act on whole subblocks, symbolically. Some would want to be able to specify dimensions of their Matrices and Vectors so as to enable size validation during arithmetic. And some would want to be able to describe one of those objects and leave the dimension unspecified. It'd be hard to please everyone. This next looks dangerous, as another attempt for your example. I keep expecting Maple to "go off forever" as it tries to access an element with a recursive definition. It also prints A not so prettily, when first defined. A_LA:=Matrix(3,3,(i,j)->''A_LA''[i,j]); B_LA := Matrix(3, 3, symbol = 'b'): C_LA := A_LA.B_LA: A[1..2,1..2]:=Matrix([[c, r], [p, q]]): 'C_LA' = C_LA; I also wonder whether indexing functions might be used in some devious way. I only got this far, `index/my_indexing_function` := proc( idx :: list(posint ), M :: Matrix, val :: list ) try a[op(idx)]; catch: 'a'[op(idx)]; end try; end proc: A_LA := Matrix(3,3,shape=my_indexing_function); B_LA := Matrix(3, 3, symbol = 'b'): a := Matrix([[c, r], [p, q]]): C_LA := A_LA.B_LA; C_LA; # whoops Perhaps someone else can think of a clever workaround. acer
This gets the result, A_LA := Matrix(3, 3, symbol = 'aa'): B_LA := Matrix(3, 3, symbol = 'b'): C_LA := A_LA.B_LA: aa := Matrix(3, 3, symbol = 'a'): aa[1..2,1..2]:=Matrix([[c, r], [p, q]]): 'C_LA' = C_LA; Sure, it is one more line. But it still looks nicer than the mess with evalm and copyinto. acer
I might also add this. The call to with(LinearAlgebra) is not needed, for this task, which is somewhat nice. Also, if you really wanted A_LA to no longer have its entries be changed whenever a[i,j] were changed, then you could do either of these at the end, A_LA := map(eval,A_LA); or, even more clear to me, A_LA := Matrix(A_LA); acer
Why did you bother with this next statement, when all you had to do was define a before querying A_LA? A_LA[1..2,1..2] := Matrix(2,2,[[c,r],[p,q]]); The following, without the above, looks easier to me than what you did to get a similar effect using linalg. There's no evalm call needed to do the multiplication, no mysterious copyinto call, both of which are quite confusing to the new user. with(LinearAlgebra): A_LA := Matrix(2,2,symbol=a); B_LA := Matrix(2,2,symbol=b); C_LA := A_LA.B_LA; a := Matrix([[c,r],[p,q]]); 'A_LA' = A_LA; 'C_LA' = C_LA; acer
An important aspect of abstract linear algebra (perhaps *the* point of it, really) is that one can query and obtain results without all the entry-wise arithmetic necessarily being done. So in a basic way, using new-style Matrices with the 'symbol' option (or some equivalent, as you had it) to attempt to "fake" non-computational abstract linear algebra is not going to get nearly what one would want in general. As a very simple example, the transpose of the transpose of a matrix should be recognizable as the matrix itself, with no computation or manipulation of the elements being performed. LinearAlgebra is not going to be able to give the user this sort of power. If it can only mimic the abstract linear algebra work desired, through exact but full explicit computations involving the elements, then it'll unnecessarily scale horribly. Consider what evalm() is able to do, buggy as it might be. O, last-name-eval. And so on. acer
The matrix exponential command is there directly, as LinearAlgebra[MatrixExponential] , so there should be no need to call LinearAlgebra[MatrixFunction] . But something is not quite right. It is super fast for pure floats, but can be slow for exact rationals when the dimension is >=3 . It appears slower by default, in that exact case, than it was in Maple 10. I suspect some simplification or normalization may be taking place within LinearAlgebra[MatrixExponential] , and which might be difficult to turn off. acer
I suggest a Linux operating system using architecture compatible with the x86-64 chipset. In particular I would suggest the Athlon64 X2 Socket AM2 running the a 64bit SuSE Linux distribution (eg 10.1). The AMD opteron is also a nice choice, and allows for SMP, though it is more expensive. If you can wait a little while, you could consider the AMD quad-core opteron. Some advantages of such a setup are: - remote login to run maple is easy and reliable - ATLAS BLAS are well tuned for this in Maple - GnuMP (gmp) now has some assembler in it for this architecture - Can install 64bit OS including 32bit runtime, after which can install both 64bit and 32bit Maple Make sure that you can run a version of Maple that supports the GlobalOptimization toolbox. You may choose to try it at some later date, say to optimize parameters in some Simulink model. It is supported on 32bit Linux. The Core2 Duo is attractive, but it's not clear that Maple is quite as well optimized for it yet. I know that I run the risk of being flamed, but I advise against OSX. Running remote X-apps is more work, it doesn't support Maple's Classic interface, and judging by reports here and on usenet it runs into more Maple 'issues' than does Linux. Apart from having reasonably good BLAS from the Intel Math Kernel Library (MKL) I see few if any reasons to run Maple on 32bit Windows for serious computaton. The remote access of Linux/UNIX is hard to beat. Multiple instances of Maple will run on a Linux machine without its blinking an eye -- something that I believe is hardly true of Windows. acer
I notice that .mla and .hdb are not present on that site. acer
Thanks. As it happens, I had already read those help-pages, but I appreciate the comment. I have not found this evaluation behaviour of tables under discussion to be documented in any help-page. The quote that I included above actually describes only the opposite behaviour for other types. It ought to be more clearly documented. I have not checked the manuals on this point. I know that there is quite a bit inside the Advanced Programming Guide which cannot be found in any help-page. I feel that is another more general problem which ideally should be corrected. acer
Perhaps the (documented) type with_unit could serve instead of has_unit. For example, > a := Unit('m'), 4*Unit('cm'), 9*Unit('ft'), 16*Unit('N')/Unit('cm'): > op(map(subsindets, [a], with_unit, z->convert(combine(z,units),unit_free) )); 1, 1/25, 3429/1250, 1600 Or, it might be tried in Joe's nice UnitsToUnity routine. acer
Perhaps the (documented) type with_unit could serve instead of has_unit. For example, > a := Unit('m'), 4*Unit('cm'), 9*Unit('ft'), 16*Unit('N')/Unit('cm'): > op(map(subsindets, [a], with_unit, z->convert(combine(z,units),unit_free) )); 1, 1/25, 3429/1250, 1600 Or, it might be tried in Joe's nice UnitsToUnity routine. acer
I heard that Mma 6 is using Qt for its GUI on Linux/Unix. If so, then I wonder whether it's very snappy. acer
I didn't mean to imply that it was necessarily different from all other objects. But it's natural to imagine that someone would want to use as a data structure an object which would not suffer from unwanted evaluations. Prior to kernel-based parameter processing (which is a very recent development) there were a slew of ways in which to inadvertantly get unwanted evaluations of data or parameter options. Consider optional keyword parameters: what else but a string could be used as such a keyword, and not be at risk of extra evaluation? How to make a keyword an unassignable name? Look at the sorts of evaluation that typical use of ProcessOptions makes. I was thinking about ways to pass about data and shield it from unwanted evaluation. So far, the rtable looks not so bad. acer
First 492 493 494 495 496 497 498 Last Page 494 of 502