@jimmyinhmb Here's an example, for multiplying the transpose of 50x50 Matrix A with 50x50 Matrix B one hundred thousand times.

On a fast i7 running Win 7 Pro (64bit Maple 15.01) it takes about 4 sec using the ideas laid out above, and it takes about 26 sec to do it repeatedly as C := A^%T . B

dgemm_module.mw

The benefit in speed gets less as the Matrix size goes up. But there is also the question of total memory allocation.

@jimmyinhmb Here's an example, for multiplying the transpose of 50x50 Matrix A with 50x50 Matrix B one hundred thousand times.

On a fast i7 running Win 7 Pro (64bit Maple 15.01) it takes about 4 sec using the ideas laid out above, and it takes about 26 sec to do it repeatedly as C := A^%T . B

dgemm_module.mw

The benefit in speed gets less as the Matrix size goes up. But there is also the question of total memory allocation.

The Standard GUI's debugger is awkward to use. It is awkward but (far, far worse) also has several serious bugs.

The worst bug is a tendency to lock the session, and force shutdown of that kernel and closure of the document with no option to save. (I have been recently having to use it for some debugging of mixed-GUI-related stuff, and for my task simply accidentally putting the focus back to the main sheet -- while the debugger is still in action -- will cause such a freeze up every single time. But that is just one of many ways it can go very wrong and/or crash.)

But in a relative sense I care more about being able to use a better debugger while in Standard than I do about the bugs in the current debugger being fixed. One that is not graphical, with next-to-no mouse action required. One that crashes the kernel on me once per year at most (like in the CLI) instead of once per hour.

I don't understand why the text mode of the commandline interface's debugger cannot be optionally offered in the Standard GUI. It works in Classic, and just involves plain 1D text commands as input, and so why cannot it work in Standard and push out prettyprint=1 level output?

acer

The Standard GUI's debugger is awkward to use. It is awkward but (far, far worse) also has several serious bugs.

The worst bug is a tendency to lock the session, and force shutdown of that kernel and closure of the document with no option to save. (I have been recently having to use it for some debugging of mixed-GUI-related stuff, and for my task simply accidentally putting the focus back to the main sheet -- while the debugger is still in action -- will cause such a freeze up every single time. But that is just one of many ways it can go very wrong and/or crash.)

But in a relative sense I care more about being able to use a better debugger while in Standard than I do about the bugs in the current debugger being fixed. One that is not graphical, with next-to-no mouse action required. One that crashes the kernel on me once per year at most (like in the CLI) instead of once per hour.

I don't understand why the text mode of the commandline interface's debugger cannot be optionally offered in the Standard GUI. It works in Classic, and just involves plain 1D text commands as input, and so why cannot it work in Standard and push out prettyprint=1 level output?

acer

@IanLisle I'm glad that you have a solution.

Yes, I knew of the savelib action's giving a name to the module, which is what made me suspect that one of the approaches might be as adequate as the other.

I will submit a Software Change Request, so that (if this is all true, that both work) the help-pages might indicate creation of a named module as a simpler approach.

@IanLisle I'm glad that you have a solution.

Yes, I knew of the savelib action's giving a name to the module, which is what made me suspect that one of the approaches might be as adequate as the other.

I will submit a Software Change Request, so that (if this is all true, that both work) the help-pages might indicate creation of a named module as a simpler approach.

It also works if the module is being read in from an archive (as suspected).

restart:
with(CodeTools):
M := module() option package; export f; f := proc() end proc; end module:
EncodeName(M:-f):

DecodeName(%);
Error, (in CodeTools:-DecodeName) invalid subscript selector

LibraryTools:-Create("c:/temp/moddy.mla",WRITE);
libname:="c:/temp/moddy.mla",libname:
savelib(M);


restart:
with(CodeTools):
libname:="c:/temp/moddy.mla",libname:

EncodeName(M:-f);
_Inert_ASSIGNEDLOCALNAME("f", "PROC", 0, _Inert_ATTRIBUTE(

  _Inert_EXPSEQ(_Inert_NAME("protected", 

  _Inert_ATTRIBUTE(_Inert_NAME("protected"))), _Inert_EQUATION(

  _Inert_NAME("modulename"), _Inert_ASSIGNEDNAME("M", "MODULE"))))

  )

DecodeName(%);
                              M:-f

And now I read the help page for CodeTools:-Profiling and see that it is mentioned there,

        Due to difficulties in resolving names, it is not possible to profile the member
        functions of a module that is not saved in a repository.  To avoid this, simply
        create a repository using march, set savelibname, and then use savelib to save the
        module.  By adding the new repository to libname, the module is available to use
        and profile.

I now wonder whether creating named modules (in the first place) is another viable workaround to the issue (and if so, obviating the general need to savelib and restart in order to profile module members).

acer

It also works if the module is being read in from an archive (as suspected).

restart:
with(CodeTools):
M := module() option package; export f; f := proc() end proc; end module:
EncodeName(M:-f):

DecodeName(%);
Error, (in CodeTools:-DecodeName) invalid subscript selector

LibraryTools:-Create("c:/temp/moddy.mla",WRITE);
libname:="c:/temp/moddy.mla",libname:
savelib(M);


restart:
with(CodeTools):
libname:="c:/temp/moddy.mla",libname:

EncodeName(M:-f);
_Inert_ASSIGNEDLOCALNAME("f", "PROC", 0, _Inert_ATTRIBUTE(

  _Inert_EXPSEQ(_Inert_NAME("protected", 

  _Inert_ATTRIBUTE(_Inert_NAME("protected"))), _Inert_EQUATION(

  _Inert_NAME("modulename"), _Inert_ASSIGNEDNAME("M", "MODULE"))))

  )

DecodeName(%);
                              M:-f

And now I read the help page for CodeTools:-Profiling and see that it is mentioned there,

        Due to difficulties in resolving names, it is not possible to profile the member
        functions of a module that is not saved in a repository.  To avoid this, simply
        create a repository using march, set savelibname, and then use savelib to save the
        module.  By adding the new repository to libname, the module is available to use
        and profile.

I now wonder whether creating named modules (in the first place) is another viable workaround to the issue (and if so, obviating the general need to savelib and restart in order to profile module members).

acer

...asked as long ago as 2007, and the question hasn't lost relevancy. I'm glad you bring it up.

acer

@Axel Vogt I was thinking about trying some variation of (one of) these two,

> f:=proc(x) holder; end proc:            

> g:=subs(holder=expand((x-1)^3),eval(f));

                  g := proc(x) x^3 - 3*x^2 + 3*x - 1 end proc

> g(4);
                                      27

> s:=unapply(expand((x-1)^3), x, proc_options=[inline]);

          s := proc(x) option inline; x^3 - 3*x^2 + 3*x - 1 end proc

> t:=proc(x) s(x); end proc;

                  t := proc(x) x^3 - 3*x^2 + 3*x - 1 end proc

> t(4);
                                      27

@Christopher2222 I gave it a brief whirl last night, and did not succeed with Maple 14. The StringTools package's user-accessible routines utilize a technique where a compiled external function (in a shared library, aka dll on MS-Windows) replaces a Library stub function upon first invocation. Even the Library part of the code is not easy to figure out completly, in the Maple debugger. I believe that some or all StringTools routines have their complete body implemented using Maple's OpenMaple API, and are compiled and thus not visible for examination. (This is one reason why the package is so very fast.) The error message that you cite gets issued when a call_external is made. The argument `ospd3` passes initial Library procedure checks, but appears to fall afoul of another check which may be in a compiled external function. It might not be possible to circumvent.

@Axel Vogt Greatstuff.

I suspect that xg and wg can be pulled out of Legendre16 (and even out of L), and passed in as arguments. And K's formula could probably be burned-in or otherwise inlined into Legendre16 (which could take x and s as 2 first args, instead of f). It looks like Legendre16 could thus become not only fully evalhf'able but also Compile'able and/or fullly exportable via CodeGeneration[C].

...which reminds me of something else.

@Christopher2222 Reading a file into memory will be much more efficient than scanning it, repeatedly, as a file. Repeated file i/o is extremely inefficient.

But there are other questions of efficiency about tasks likes this which are interesting. A great deal of the work for this and related tasks are checks on membership and position. Like use of `member` or a set of strings in Maple, say.

Ask a nine year-old to look up a given word in the dictionary. She won't start on the first page and then check every word on the page, from top to bottom, and then repeat all that on page 2, etc, etc. No, instead she'll crack the whole dictionary book at about the 3/4 mark, and then compare the top corner with the first letter of the given lookup-word. And then she'll continue seaching cleverly, and get to the right page in a dozen seconds or so.

And that is all possible because the words in dictionary are sorted usefully. If I had a dictionary which was not known to be ordered "alphabetically" then looking up words would be much less efficient.

In Maple 8, a set in Maple had its members ordered by memory address. In Maple 12 and later, a set's members are ordered according to the value of kernelopts(setsort). And the ordering of members of a set is now done according to some rules which are quite different from mere memory address. There are a few different schemes (for different setsort values), but the chosen scheme is unchanging for any Maple kernel session. And the new schemes are largely based upon lexicographic ordering. In particular, strings in a set are now sorted in such a way that knowledge of the current setsort value could allow for more efficient membership testing of any set comprised of only strings.

The StringTools package was written before set ordering changed from being memory-address-based to being setsort-(lexicographically)-based. And unlike Matrices, say, a Maple set does not have a `datatype`. So there is no super-cheap test which indicates that a given set can only contain strings. It therefore seems doubtful that StringTools makes use of modern Maple's set ordering in order to do more efficient searches and membership tests for user-supplied sets. It's possible that it might have been updated to take advantage of setsort ordrering when operating within its internal routines on temporary sets that it constructs itself during a computation.

On the other hand, equivalent computations have longer been technically possible in Maple. A string can be converted to a Vector of hardware integers. The first entry can be used to contain the length. Programs which compare, or test for membership in large collections of such representations of words, can be compiled and made very efficient.

Running the commandline interface of Maple 15, on Unix,

% maple15 --setsort=1

> {"a","s","h","M","b","C"}; kernelopts(setsort);

                        {"C", "M", "a", "b", "h", "s"}

                                       1

> quit

% maple15 --setsort=2

> {"a","s","h","M","b","C"}; kernelopts(setsort);

                        {"s", "h", "b", "a", "M", "C"}

                                       2

I don't know whether modern Maple's StringTools relies on such orderings, when present, to do faster lookups.

@Christopher2222 Reading a file into memory will be much more efficient than scanning it, repeatedly, as a file. Repeated file i/o is extremely inefficient.

But there are other questions of efficiency about tasks likes this which are interesting. A great deal of the work for this and related tasks are checks on membership and position. Like use of `member` or a set of strings in Maple, say.

Ask a nine year-old to look up a given word in the dictionary. She won't start on the first page and then check every word on the page, from top to bottom, and then repeat all that on page 2, etc, etc. No, instead she'll crack the whole dictionary book at about the 3/4 mark, and then compare the top corner with the first letter of the given lookup-word. And then she'll continue seaching cleverly, and get to the right page in a dozen seconds or so.

And that is all possible because the words in dictionary are sorted usefully. If I had a dictionary which was not known to be ordered "alphabetically" then looking up words would be much less efficient.

In Maple 8, a set in Maple had its members ordered by memory address. In Maple 12 and later, a set's members are ordered according to the value of kernelopts(setsort). And the ordering of members of a set is now done according to some rules which are quite different from mere memory address. There are a few different schemes (for different setsort values), but the chosen scheme is unchanging for any Maple kernel session. And the new schemes are largely based upon lexicographic ordering. In particular, strings in a set are now sorted in such a way that knowledge of the current setsort value could allow for more efficient membership testing of any set comprised of only strings.

The StringTools package was written before set ordering changed from being memory-address-based to being setsort-(lexicographically)-based. And unlike Matrices, say, a Maple set does not have a `datatype`. So there is no super-cheap test which indicates that a given set can only contain strings. It therefore seems doubtful that StringTools makes use of modern Maple's set ordering in order to do more efficient searches and membership tests for user-supplied sets. It's possible that it might have been updated to take advantage of setsort ordrering when operating within its internal routines on temporary sets that it constructs itself during a computation.

On the other hand, equivalent computations have longer been technically possible in Maple. A string can be converted to a Vector of hardware integers. The first entry can be used to contain the length. Programs which compare, or test for membership in large collections of such representations of words, can be compiled and made very efficient.

Running the commandline interface of Maple 15, on Unix,

% maple15 --setsort=1

> {"a","s","h","M","b","C"}; kernelopts(setsort);

                        {"C", "M", "a", "b", "h", "s"}

                                       1

> quit

% maple15 --setsort=2

> {"a","s","h","M","b","C"}; kernelopts(setsort);

                        {"s", "h", "b", "a", "M", "C"}

                                       2

I don't know whether modern Maple's StringTools relies on such orderings, when present, to do faster lookups.

@Christopher2222 I considered that case but figured that the original post was slightly ambiguous on the issue and (much more importantly) that if I has misinterpreted then it didn't matter since a pre-check would be so trivial that anyone could write it.