21438 Reputation

29 Badges

15 years, 115 days

Social Networks and Content at

MaplePrimes Activity

These are replies submitted by 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
Of course, yes, backwards compatibility is very important, so the behaviour cannot be changed now. But perhaps the documentation could be improved? Or am I just not finding it? On the help-page ?eval there is only this below, but no mention of this greater-than-1-level evaluation behaviour for entries of table parameters within procedures. "For example, if x := y and y := 1 in a Maple session, what is the value of x; ? In an interactive session where x and y are global variables, x would evaluate to 1 and we would say that x is ``fully evaluated''. For one-level evaluation, we would use the command eval(x, 1) which would in this case yield y. However, inside a Maple procedure, if x is a local variable or a parameter, then x evaluates to y and we would say x evaluated ``one level''." So, in the above, there is no mention of this issue. This 2-level evaluation rule for last-name-eval parameters like table also isn't mentioned on ?updates,v40 or ?lastnameevaluation , that I could see. Assigning the table to a local, in the procedure that accesses the entries, is possible then, to avoid the extra evaluation. Thank you for that. It would be nice to use rtables instead, but one of the great things about a table is that it may be resized at any time. That's not possible with rtables, so it's difficult to be efficient with them when the final data set size is not known at initial creation time. The other great thing about tables is that they may be indexed by things other than integers, but that's not so for the rtable. It would be nice to have something like a table, for resizability and ability to be indexed more loosely, but without last-name-eval, and whose entries only evaluate 1-level on access when it is a procedure parameter or a local. acer
Thanks very much for the response. My example's array parameter was actually assigned to a local (y), but only in the outer procedure. I suppose you are saying that, in any deeper nesting of procedure calls, the table parameter would again have to be assigned to a local? That is, assigned to a local, in each inner procedure in which 1-level eval was wanted? That seems onerous. I still don't see why the level of evaluation for the elements of a table are deemed correct. Running an example with a list, instead of a table, produces exp(0) even from inside the inner procedure. I would claim that the level of evaluation of the entry of the table -- over and above what is needed to accomodate last-name-eval, is wrong. It would be right, were it to produce the same result as occurs when accessing the entry as happens in the list case. Even if one accepts the rationale (which I don't, sorry) it still seems like an overly expensive hack, to get around the fact that last-name-eval tables don't get their contents fully evaluated when first passed in from the top-level. It means that extra evaluation is done upon each and every subsequent access of each table entry, instead of just once per entry up front. Wouldn't it be better to allow the programmer to choose whether to evaluate the table entries fully (just the once up front, or...)? I can see that it's tricky, of course. Suppose one wants to definitely not fully evaluate all the entries, and that one also wants somehow to get the level of evaluation that you described of some particular table entry. A mechanism for that is desirable. Having such a mechanism always take place is less desirable, although that is the current state of affairs -- excluding hacks to get around hacks. Those many test failures that might occur when changing the evaluation rule for table parameters, they occur presumably because code was programmed to work around the current behaviour. Such test failures can't be much of a justification, in and of themselves. But the behaviour still seems hackish, and makes Maple's evaluation rules more complicated. I wouldn't know where to find them in the help-pages, other than ?updates,v40 . acer
First 441 442 443 444 445 446 447 Page 443 of 450