Maple patch library (independent)
1099I have been wondering about the reception of an independent patch Library for Maple.
I'll lay out a few ideas, and then maybe some criticism (or indifference) might follow.
I'm a bullet-point sort of person:
- sourceforge project with a few willing experts for vetting and gatekeeping of submissions.
- Patch .mla Library archive, going into
- Self-building, with batch scripts, if copyright prevents redistribution of .mla directly. (Maple itself can do platform independent batch work.)
- Distribute only "diff" files. Scripts extract source from users own installed Maple, apply diffs, and reload into patch Library. (printlevel, writeto, eval, savelib.)
- Distribute something that describes or lists the changes, with examples.
- Version specific diff files.
- Cumulative diffs would preempt allowing pick-and-choose from multiple edits to a single routine. All or nothing.
That's the essence. Of course not all Library routines can be so easily properly extracted to source and validly reloaded. But many can.
If the idea is worth trying, then some Mapleprimes book posts would be one place to start. Tips on handling module-based packages, or routines with remember-table/Cache entries (that get shown upon print) might be nice to have here. Routines which self-modify could also need special handling.
An alternative to source diffs could be something like this "live surgery". I don't know how easily or well that might scale.
A big concern would naturally be that a patch shouldn't break anything. A test suite is needed for that. The minimum would be base tests for the altered routines. Comprehensive test suites take a great deal of resources to author. Without proper testing, patched routines are risky enough to be worthless.
The central goal would be to improve Maple. That should make it a better and more attractive product. If it's not an improvement, then it's not a good idea.
acer
- acer's blog
- Login or register to post comments
- Still trying...
4 hours 25 min ago - use coeff
5 hours 41 min ago - periodic vs aperiodic
2 hours 35 min ago - job done!
8 hours 30 min ago - module
8 hours 36 min ago - Autoexecute
11 hours 6 min ago - !!! Execution
11 hours 14 min ago - Probably it is too late
12 hours 58 min ago - That's great!Thank you!
19 hours 1 min ago - For what it's worth I have
1 day 1 hour ago
- Normal forms for quadratic functions on vector spaces
- The set of protected names
- undoing one form of symbolic root
- Computing the cumulative bivariate normal distribution
- The single argument Complex constructor
- How do I "clear" an array?
- HOW can one OUTPUT a DOUBLE-NESTED loop?
- How can I create 0-based arrays in Maple?
- MaplePrimes
- From Maple to Scientific Workplace
- The Top Ten Maple Errors
- Quick Reference Document
- Tine: A Module for Measuring Maple Performance
- Convex Optimization & Euclidean Distance Geometry
- Using try/finally to temporarily modify a global flag
- building up sets and removing redundant elements
- Guelph, Ontario
- Creemore, Ontario
- Neustadt, Ontario
- Royal Observatory, Greenwich
Comments
too hard to maintain
I'd hesitate to do this because it think it would be too hard to maintain. The Maple library often changes in a lot of small ways, and patches are very likely to introduce strange behavior in top level commands like solve, simplify, etc. It would be better, I think, to build a repository of good algorithms. Write standalone routines that perform a well-defined task and improve on Maple's. Maple's language can be very clear and concise, so if the code were documented it would be short and you could port to other languages easily.
yes
I agree with Roman. It would be more useful, not to mention a whole lot easier, to write standalone routines rather than attempting to patch the Maple library. Besides, with modules it is not always possible to modify library code (that is, without access to the actual source).
Live surgery
Note that it is possible to 'patch' anything you want using the method I called live surgery previously can be used to patch anything at all. This requires that patching be done in an init file instead of via a patch library though.
The Maple library only changes once a year (for those who continually upgrade), and for a lot of users, less often than that. But more to the point, certain bugs don't seem to get fixed in a 'timely' manner. If those same bugs can get fixed by the community, why not? It is often easy to fix a clear bug in a sub-sub-routine of simplify or of fsolve, but quite unrealistic to write a whole new simplify or fsolve.
It is true that patches can introduce unexpected behaviour. But what is a user to do? Wait 7 years for Maplesoft to get around to fixing the bug, or go with a patch that is available now that seems to work for the case at hand?
I would perfer something towards that
I would perfer something towards that, but may be for complete 'routines' (and not for a ... hm ... cryptic replacement of lines as for the '4997' didits problem).
Obe reason may be that I do not want to wait and in bad cases it might be, that it is done only together with a new release (well, I do not buy them all ...).
Of course I am aware that would be on my own risk and nobody will guarantee, that no side effects will take place ...
Whenever possible
I totally agree that full-routine, and preferably in source form, is preferable. I am just saying that when it is not, patches are still possible. In other words, there are no technical reasons why we couldn't put together a set of patches, some of which would be nice, some which would be obscure.
In the particular case of the 4997 Digits problem, that one can be done in source form! I just had too much fun showing the other method...
patch problem
Could you demonstrate how to patch the following. Assume that you want to change the value of the local x to 24. You aren't allowed to reassign f.
Here is the trick
[Sorry for the slow response, my week has been really busy]
Here are the steps, specialized for this case, but easily enough generalized.
typematch(indets(ToInert(eval(f)),specfunc(anything,_Inert_ASSIGNEDLOCALNAME))[1], _Inert_ASSIGNEDLOCALNAME(nam::string, anything, ptr::posint)); assign(pointto(ptr),24); f(); 24With a bit more care, one can find the right lexical that corresponds to the entry to be changed and change that one. But it does take all of Inert Form + pointto + assign to get the job done.
thanks
Thanks. I wasn't thinking of the hackware package (pointto), but in retrospect that makes sense. I like the use of typematch here, very neat.
typematch
is a seriously under-appreciated command in Maple. Used properly it can shorten code a lot while making its intent clearer than a similar piece of code full of nested op calls. Plus it is more robust, in that it will fail to match when given 'bad' input, unlike a sequence of op which just might succeed but result in complete gibberish.
It unfortunately has a nasty drawback: it only works with structured types that are implemented in the kernel. It will fail in weird and mysterious ways on library types. And since where a type is implemented is actually not documented information...
nasty drawback
And I do not see this limitation documented:
Maybe the drawback has been fixed?
I got bit by this in Maple 9.5 or 10. It's possible it has been fixed. It was not documented then either [I just checked]. I discovered "the hard way" that some structured types (documented in ?types,structured) are actually library functions! This was 'new' since almost all the structured types are in the kernel.
So, the issues are
1. list the structured types currently implemented in the library.
2. check whether matching against them still produce errors.
What about 'patmatch' and 'applyrule' in these cases?
And the answers are
typematch([tt[x,y]], ['ff'::anyindex(name,name)])works buttypematch([tt[x,y]], ['ff'::anyindex(a1::name,a2::name)]);doesn't.You could use patmatch and applyrule, but I don't. As far as I know, they have some long-standing bugs still unfixed. Problem is, I could be wrong and they could have been fixed. But since there is no way to find out but to exhaustively test them, that's too much trouble, so I avoid them. This is why various ideas of independent test suites and independent bug repositories would be so useful!
The other thing is that I don't think that patmatch was ever taught about the full range of possibilities for indexing [which is where typematch fails], so that it may in fact not work at all for this purpose. patmatch, unfortunately, is an 'orphaned' feature.
orphaned features
will need also to be independently listed. Either to take care, avoid or try to patch if possible and needed.
I find that pattern matching is a basic and needed feature where Maple is weak and I would have expected much more development in this area.
pattern matching
Some people agreed with you - thus 'match', 'define' and 'patmatch', 3 different attempts at features for rule-defined programming, with different strengths and weaknesses. And no follow-up.
The problem is that "pattern-matching" in Computer Algebra has, legitimately, acquired a bad name as an implementation strategy when you don't know what you are doing. Rather the same as when people use simulated annealing or neural networks to ``solve'' a problem when they have no idea what to do. Solutions to CA problems using pattern-matching tend to be very fragile.
The fallacy with this reasoning is the thought that the problem is pattern-matching. Pattern-matching can be very successfully used when you have predictable complete matching -- see Ocaml and Haskell for great uses of pattern-matching as convenient syntactic sugar for what, in Maple, usually requires some ugly op'ing around.
The problem is the attempt to solve hard problems like integration or solving differential equations via pattern-matching is essentially ``giving up'' using an intelligent solution and applying a hack that will patch over the problem. It gets worse when you have giant tables (1000s of entries,like in Mathematica or in Maple's own inttrans package). The maintenance of these is hideous. Plus these tables often hide bugs in downstream code, or worse, have a bug in them where downstream algorithmic (but often slower) code would have gotten the right answer!
continuation
Let us continue here .
Patch
assign(op([7,2],eval(f)), 24);
f();
24
what's wrong with that? Or, say,
assign(op(op(f))[-1], 71);
f();
71
Alec
Case type/anyindex
The code in this case is quite simple:
It should be not difficult to improve it. On the other hand, apparently. it does not seem that its improvement requires investigation of better algorithms.
It remains the issue of whether any change here could affect elsewhere. I wonder whether there is a straightforward method to obtain a "naive" measure of this risk.
I mean, eg. if this particular piece of code were not called elsewhere in the library, it could be said that there is no risk at this level. On the other extreme, if it were called at 1000 points, chances are that the risk is large.
Backporting
Another circumstance where patches might be relevant would be in backporting fixes or new functionality not available in earlier versions. Users of these versions could find them useful.
copyrights
One has to respect Maplesoft's copyrights. Copying new additions to libraries is presumably neither legal nor ethical. User generated patches should be fine, but they would have to be distributed as such, I assume. That is, one couldn't just patch a library (or a procedure from a library) and make the patched version available. Rather, the patch itself would have to be distributed and the users would apply it to their own copies of the Maple libraries.
user generated patches
should be the object of an independent patch library. Surely, legal issues should be taken into account beforehand to avoid problems.
My guess is that the main difficulty for backported patches would originate from the opposite side. Plain copy of new code for a command might not work in older versions because of calls to some other new functionality. So, a whole "environment" should be additionally recreated.
Backporting
As long as you mean backporting of patches, not backporting of whole packages, that's fine. One cannot take code which is new in Maple 10's library and "backport" it to an earlier version of Maple. That would be a violation of (at least) copyright.
If a new package is so appealing that it is tempting to port it to an older release, this is a sign of success (from Maplesoft's point of view), as it means that that package is a real incentive for users to upgrade. It is not in our best interest (our == the Maple community) to stand in the way of that!
bug fixes
I mean mainly bug fix patches (in fact I would find ethical that Maplesoft itself provide them...). This task is probably all that could be done from the community side anyway. Along the road, some new functionality would need to be recreated. But not more than that. I do not find realistic backporting a whole package.
Maple Advisor Database
The best that I know in this direction is Robert Israel's Maple Advisor Database.
Perhaps, people interested in adding something to it, could just post suggested additions in their blogs here.
Personally, I don't like sourceforge (their advertising system is disgusting, even worse than Google - and it is not that easy to achieve).
If there were people interested in that, I could, probably, host a website (up to say 50 GB, and reasonable bandwidth), advertising free, on my webspace (something like mapleadvisor.com - that would be my choice, .org, or .net - I'd prefer not to use .us or .info - because of some known issues).
It may have a wiki as well (MoinMoin preferably.)
Alec
Individual vs collaborative
Even the much that I admire Robert's site, the question is about the best option at present: an individually maintained site or a collaborative (wiki-like) one.
Each option has pro and cons. An individual site may be of more consistent quality,
but it may require a lot of effort to keep it updated. How long could the author be on top of it?
Indeed, this links to the recurrent issue of the Maple wiki , also here and...
I have no idea about MoinMoin, eg how it is like to enter math content. But time passes and there is no definition about the unofficial Maple wiki either. So, it may be worthwhile taking your offer.
.
mapleadvisor.com
OK, I've just registered the domain, mapleadvisor.com (since there were no other suggestions.) It will take about 2 days to propagate it to all the DNS servers and then we can start working on it.
And people involved in the project, as a bonus, will get an email address ending at that domain name (and starting with your name or whatever.)
Alec
math content
jsmath seems to be a good idea for math content, and can be simply implemented. It can be added to MoinMoin.
Alec
jsmath
I have installed jsmath fonts on Windows XP and gone through the examples of jsmath using Firefox 2.0.0.14. The quality of typesetted math is reasonable, sometimes good. Rendering is a bit slow for pages with heavy math or too much structure (as the character tables).
Speed and some issues with particular browsers are mentioned in the jsmath site, but may be that they are not too much relevant for the case of a Maple wiki. Probably some usage experience will be needed to see whether this is true. Ie, it seems to me worth trying.
Additional testing: with Opera 9.25 (also Win XP) I observe better quality of typesetting and faster rendering for the above tests. But in practice it has serious alignment problems (I see them in some equations here).
With Opera 9.5 (Win XP) the misalignment problem is solved by not displaying some equations...
the site
The site seems to be operational now (since noon, I think - things worked out even faster than I expected). I didn't have time to work on it today. Perhaps, I'll add something during weekend. If somebody is interested, contact me - alec at my last name.com. I can provide FTP (and, maybe, even SSH) access, as well as basic info about Perl, Python, PHP, MySQL etc. that can be used. The site is hosted in standard LAMP configuration. At this time, the site is almost empty - except a very simple first page, a chat room, a very basic forum, and a mailing list.
Certainly, I can do the basic setup myself, but I'd like to see at least some other people wishing to work on it as well. I don't want it to be my own project.
Alec