Unless the datatype is a hardware type, or a software float type, the underlying data structure for a storage=sparse rtable is, I believe, a Maple sparse table. If instead, for datatype=, the data structure were similar to that used for those hardware or float datatypes, then some start might be made for sparse exact linear algebra. I mean storage in a triple of C arrays: two as integer arrays for the row and column indices and one, well, one for say ALGEB pointers. There'd still be a lot of work to do, but this might be a start. I wanted to suggest this for datatype=rational, but that could mean a lot of work up front for somebody, to make sure that such rtables continue to work as usual all through Maple. Maybe it would be "easier" if it were done for some new combination, like storage=sparse,datatype=algeb. Gosh, I don't know. It's also good to be realistic. Sparse exact linear algebra could be a good addition for Maple as well as be lower down a great many people's priority lists. If that's true, then maybe someone other than Maplesoft might try to do it. Most if not all the knowledge to do it are in the external-calling details in the advanced programming guide. acer

Thanks very much, Axel, for the explanation. The timings in the worksheet indicate that your maple-language implementations, the translations, might be 4-5 times faster than Maple's own when run outside of evalhf, is that right? And far more importantly, your implementations are evalhf'able! The BesselK1 implementation seems to be quite accurate, except perhaps for very small arguments, judging by the graph. I find this to be very exciting. acer

My point was probably not clear enough, sorry. I am quite familiar with how procedures manage their returns. My issue is with what each of the procedures prints. My issue is that outerproc is printing exp(0) while innerproc is printing 1. But y is an array, which has last-name eval. And, more to the issue, y is a local variable of outerproc, so I don't see why it should be getting that many levels of evaluation by the time the innerproc gets it (for printing, or what have you). I expected to see exp(0) within innerproc as well. acer

Where's your mint symlink? acer

The readme.txt file in bessel.tar.gz says, "copyright Copyright(C) 1996 Takuya OOURA (email: ...). You may use, copy, modify this code for any purpose and without fee. You may distribute this ORIGINAL package." Is that what was in the source that you translated, may I ask, Axel? I couldn't see from it whether one it gives permission to distribute the code in modified or translated form. I know very little about the legalities of such things; perhaps someone here could explain it to me... acer

The symlinks shouldn't have been necessary. Could you not simply have run, % maple -binary IBM_INTEL_LINUX to run the 32bit version that you had installed? Given that the above works, you should be able to install and run both the 32bit and 64bit versions under the same principal location. But with those symlinks in place, you could only install the two instances to two completely separate locations, with the duplication (and disk use) of having two full identical sets of the .mla archives and .hdb help-databases (which are platform independent). acer

I realize that the loop code example was just meant to be rough and quick. But it bears mentioning efficiency once again. The programming method of appending to a list, within a loop, is quite unnecessarily inefficient. By that, I mean things like this, Indexf:=[ ]; for i from... do Indexf:=[op(Indexf),i]; end od: This produces a new list, to be garbage-collected, each time through the loop. At problem size of 1000000 the garbage collection and list creation swamp the rest of the task, and on my machine the selection takes over 1000sec (!) and allocates over 115MB of memory. The simple conversion of the original Array to a list, followed by a call to select, takes about 5sec and uses about 33MB of allocated memory. The posted rtable_scanblock approach, with the final conversion to a list removed and returning table G instead, takes about 13sec and uses about 27MB of allocated memory. I wish it could be made faster, although really its strength is that it can be extended to do more involved tasks. It's a good idea to always try to think a little about efficiency and the complexity (cycles and memory) of one's implementation. It'll help greatly, when one comes to writing code for larger or more involved problems. It all adds up, eventually, whether O(n) or O(n^2), etc. It's not so much a race or competition to find the very fastest method, so much as that it can make or break an implementation to at least get the complexity of the implementation right. acer

I realize that the loop code example was just meant to be rough and quick. But it bears mentioning efficiency once again. The programming method of appending to a list, within a loop, is quite unnecessarily inefficient. By that, I mean things like this, Indexf:=[ ]; for i from... do Indexf:=[op(Indexf),i]; end od: This produces a new list, to be garbage-collected, each time through the loop. At problem size of 1000000 the garbage collection and list creation swamp the rest of the task, and on my machine the selection takes over 1000sec (!) and allocates over 115MB of memory. The simple conversion of the original Array to a list, followed by a call to select, takes about 5sec and uses about 33MB of allocated memory. The posted rtable_scanblock approach, with the final conversion to a list removed and returning table G instead, takes about 13sec and uses about 27MB of allocated memory. I wish it could be made faster, although really its strength is that it can be extended to do more involved tasks. It's a good idea to always try to think a little about efficiency and the complexity (cycles and memory) of one's implementation. It'll help greatly, when one comes to writing code for larger or more involved problems. It all adds up, eventually, whether O(n) or O(n^2), etc. It's not so much a race or competition to find the very fastest method, so much as that it can make or break an implementation to at least get the complexity of the implementation right. acer

Select the omega_0^2 in the original input (not output), using the mouse. Right-click to get the context-menu. Go to the submenu, 2-D Math -> Convert To Then toggle the check-box in that final submenu, titled Atomic Identifier. It should prompt you with further checkboxes, whether to include the superscript or the subscript of that selected omega_0^2 subexpression. Check only the box to "Include subscript as part of identifier". Then re-execute that input line. Then re-execute your second line to call A(omega_1) = A(omega_2). This should now treat the subscripted omega_0 as quite distinct from the name omega itself. acer

In 2dmath input mode, in a Document, enter these keystrokes: t_0 This produces t[0], which can be tested by entering lprint(%) on the next line. Now go back to the 2dmath input (not the output) of the original line. Use the mouse to select the subscripted t0. Right-click to get the context-menu. Select this context-menu command: 2-D Math -> Convert To Then, in the final submenu, toggle the box titled "Atomic identifier". Then hit return again, on the input line. Then repeat the lprint(%). This produces the same name (not t[0]!) as one gets when using the subliteral entry of the Layout palette. acer

In 2dmath input mode, in a Document, enter these keystrokes: t_0 This produces t[0], which can be tested by entering lprint(%) on the next line. Now go back to the 2dmath input (not the output) of the original line. Use the mouse to select the subscripted t0. Right-click to get the context-menu. Select this context-menu command: 2-D Math -> Convert To Then, in the final submenu, toggle the box titled "Atomic identifier". Then hit return again, on the input line. Then repeat the lprint(%). This produces the same name (not t[0]!) as one gets when using the subliteral entry of the Layout palette. acer

2dmath typeset input is quite recent and new, and that is what matters more here, I think. It is the design of 2dmath in Documents, and in input in particular, of which I was thinking most. I would accept a change to the manner in which indexed names in 2dmath output are typeset, if it meant that these problems arising out of typeset subscripted indexed names from 2dmath input were solved. As an alternative, what about Typesetting:-RuleAssistant? Couldn't the fine control be added there, with some more natural behaviour be made the default? acer

Thanks for your input, Roman. I do not suggest making t and t[0] independent names. And the difficulty is not merely that some users do not realize that they should not mix t[0] and t. The difficulty is also that in the GUI muddles them further by representing t[0] as what appears to be a quite independent name, t-subscripted-0. My suggestion was to make t_0 print a subscripted zero, and to make t[0] always print as t[0], yes. That should make matters clear to the user. I have seen many Documents, written by many different people, and I cannot recall once seeing a subscript itself treated as a variable or incremented. Of course, it's quite possible that some users would want it, but I cannot recall having yet seen it. Of course a user would continue to have available the ability to make an indexed name like t[i] get its index changed. I consider that, were it to solve the problem of users' getting caught and confused in the current muddle between unindexed name and subscripted name, removing the ability to programatically change the index of (only) a *typeset* subscripted name would be acceptable. I disagree that it would be mostly useless, because I have seen so many Documents make fine use of subscripted names without relying on that functionality at all. Even if we do not agree, I think that it's very good to hear differing opinions on this sort of thing. It's very difficult to get a design completely right, the first time. Tweaks made sooner rather than later can prevent issues from becoming ensconced in stone. acer

Does this serve? Perhaps you don't really want the second index of EBO to take values p[1] and p[2], because your later comment indicates that you want it to have columns 1 and 2. restart: p[1] := 1; p[2] := 4; EBO:=Array(1..10,1..2): for n to 2 do for s to 10 do EBO[s, n] := sum((x-s)*p[n]^x*evalf(exp(-p[n]))/factorial(x), x = s+1 .. infinity); od: od: EBO; acer

I don't see 64bit Windows (XP or Vista) as fulfilling the system requirements of Maple 11, on this webpage, http://www.maplesoft.com/products/Maple11/system_requirements.aspx acer