Isn't that time-hounoured way (using unprotection and replacement of the global/top-level routines) actually considerably worse? It seems a real stretch to call it better.

Doesn't the replacement method affect the instances of use of the name in routines stored in Maple's own Library archives? Not all such routines will be designed to use such a redefinition. But with the module approach, pretty much only interactive use gets the new name, while savelib'd routines continue to use the global name (eg. :-sin) that they expect and for which they were designed.

Apart from printing needs, it would also need Joe's trick of returning a call to 'procname' for a non-numeric argument. Otherwise sin(x); eval(%,x=30); will simply be wrong.

acer

Why is the only answer you could use mainly the one with %(and which is that, by the way)?

I don't think that you've answered the question, at all, of just what is wrong with various approaches presented. What, precisely, are the outstanding problems and objections? I don't mean just examples, but a clear wording of what's wrong with them.

acer

Why is the only answer you could use mainly the one with %(and which is that, by the way)?

I don't think that you've answered the question, at all, of just what is wrong with various approaches presented. What, precisely, are the outstanding problems and objections? I don't mean just examples, but a clear wording of what's wrong with them.

acer

As far as I can tell, the most surefire solution is to run a Maple version only on an operating system (OS) which is or was officially supported for that version. A possible alternative might be to ensure that the glibc (and/or X runtime libs) as well as the JRE will match those of one of the officially supported distributions.

I have only seen the problem you describe on Linux distributions which are somewhat older that the officially supported ones. Perhaps you could try running your Maple 12.02 on a more recent distribution.

note: a clarification for anyone else reading, based on some earlier responses. This is not a problem with 2D Math output, or with any output. It's a redraw problem in the Standard GUI in which the whole session goes blank and is unresponsive for about 5-10sec merely upon pasting in input. It could even be 1D input pasted to a Worksheet, with trailing full colon.

acer

As far as I can tell, the most surefire solution is to run a Maple version only on an operating system (OS) which is or was officially supported for that version. A possible alternative might be to ensure that the glibc (and/or X runtime libs) as well as the JRE will match those of one of the officially supported distributions.

I have only seen the problem you describe on Linux distributions which are somewhat older that the officially supported ones. Perhaps you could try running your Maple 12.02 on a more recent distribution.

note: a clarification for anyone else reading, based on some earlier responses. This is not a problem with 2D Math output, or with any output. It's a redraw problem in the Standard GUI in which the whole session goes blank and is unresponsive for about 5-10sec merely upon pasting in input. It could even be 1D input pasted to a Worksheet, with trailing full colon.

acer

Well, exactly. And most of it is in the same highly inefficient style, so no wonder it is slow.

I'm not sure that it's good form to post other people's complete programs (especially when a link is possible, as Axel showed.)

acer

Well, exactly. And most of it is in the same highly inefficient style, so no wonder it is slow.

I'm not sure that it's good form to post other people's complete programs (especially when a link is possible, as Axel showed.)

acer

I looked at SHA_ROTL, and then could not look at the rest.

acer

I looked at SHA_ROTL, and then could not look at the rest.

acer

These ideas seem to suffer from skewness, either in placement of the values toward an endpoint or in respect to the distribution of the size of the jumps (while the combinat solutions apparently don't).

acer

These ideas seem to suffer from skewness, either in placement of the values toward an endpoint or in respect to the distribution of the size of the jumps (while the combinat solutions apparently don't).

acer

Very nice.

Can it stay so simple, while getting the ability to restrict the maximum stepsize as the submitter mentioned in a postscript?

acer

Very nice.

Can it stay so simple, while getting the ability to restrict the maximum stepsize as the submitter mentioned in a postscript?

acer

If you add the location of your new .mla Library archive to libname, then you ought to be able to access its contents. The ?libname help-page gives examples (Unix, but easy to adjust for MS-Windows style paths).

The command to modify the read-write permissions of a Library archive is LibraryTools:-WriteMode. Trying to use that on Maple's own installed archives would generally be a very bad idea.

Adding custom written prodecures to private archives, and reusing them after augmenting libname, is common practice. There should be no need to overwrite anything in Maple's own archives (even patches and fixes aren't implemented as direct in-place edits, but are pushed out as alternate versions in a new archive which gets found first by having a higher internal access-priority).

acer

If you add the location of your new .mla Library archive to libname, then you ought to be able to access its contents. The ?libname help-page gives examples (Unix, but easy to adjust for MS-Windows style paths).

The command to modify the read-write permissions of a Library archive is LibraryTools:-WriteMode. Trying to use that on Maple's own installed archives would generally be a very bad idea.

Adding custom written prodecures to private archives, and reusing them after augmenting libname, is common practice. There should be no need to overwrite anything in Maple's own archives (even patches and fixes aren't implemented as direct in-place edits, but are pushed out as alternate versions in a new archive which gets found first by having a higher internal access-priority).

acer