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

The author starts out by discussing software in general. But at some point a restriction to information software gets imposed, with "Most software is information software." A great deal of the subsequent generalizations and assertions, including those about the problems of interactivity, seem subject to that qualification. Maple is not just software for querying information -- it's also used investigatively and creatively, to do math. Mathematics is not just a large data set to be navigated. So if one were to accept ideas in the paper, as they relate to information software, it wouldn't be clear that the same conclusions would hold for Maple when in its creative software role. Of course Maple does also get used as information software, and there are several ways in which the points in the paper can be related to Maple. It is an interesting read over and above how I chose to interpret it while thinking about Maple. It's very nice that you posted it here. acer

The author starts out with an omission, claiming that modern software is experienced almost exclusively through pictures or pointing and pushing. Mathematical software, such as Maple, can also allow interaction by communicating via language. Language is another distinct and important mode of interaction and exchange of information, and it's surprising to see it overlooked in what purports to be a near complete characterization. The communication of mathematics, even when done using specialised notation, is a mechanism with linguistic aspects. acer