You can either wait an undefined amount of time for the weakness to be fixed, or write your own numerical integrator that is better, or write a review of Maple for a widely circulated magazine/journal. 

You can either wait an undefined amount of time for the weakness to be fixed, or write your own numerical integrator that is better, or write a review of Maple for a widely circulated magazine/journal. 

The closest type is type 'mathfunc', which tests if Maple's knowledge of a function is deep enough that it knows it is a "mathematical function" instead of a random procedure.  This is by no means fail-safe, but it is a reasonable approximation.  I think there might be a similar type for things like Int and Sum as well, but I can't find it right now.

In general you have to treat each case individually.  This is why many functions in Maple have 'extension mechanisms', so that users can plug in new cases themselves.

The closest type is type 'mathfunc', which tests if Maple's knowledge of a function is deep enough that it knows it is a "mathematical function" instead of a random procedure.  This is by no means fail-safe, but it is a reasonable approximation.  I think there might be a similar type for things like Int and Sum as well, but I can't find it right now.

In general you have to treat each case individually.  This is why many functions in Maple have 'extension mechanisms', so that users can plug in new cases themselves.

I guess it really depends on how early ModuleLoad really executes.  If it executes as soon as the module is read from the library, then it's hopeless to figure this out easily.  If it executes the first time any part of the module is evaluated, then there might be a way to catch things (via using routines with special evaluation rules).

Hum, I wonder if stopat(AFunkyModule:-ModuleLoad) would work?

That is exactly what I am suggesting.  I believe there is enough experience around to see which usages are frequent enough to warrant the addition of new primitives.

I don't have actual suggestions to make, not right now.  But there has been enough years without that kind of addition to the kernel that 'accumulated wisdom' must have built up, and should be ready to produce a short list.

That is exactly what I am suggesting.  I believe there is enough experience around to see which usages are frequent enough to warrant the addition of new primitives.

I don't have actual suggestions to make, not right now.  But there has been enough years without that kind of addition to the kernel that 'accumulated wisdom' must have built up, and should be ready to produce a short list.

Sorry, I forgot that andmap first applies a predicate - and in my case that is just the identity.  There are laws for that case too in that paper (ie we know that [in Haskell notation] map f . map g == map (f.g),in other words that mapping g then mapping f is the same as mapping the composite f@g ).  There are similar laws involving folding after applying map.

In fact, there is a whole categorical theory of that, which greatly generalizes these results.  See the Bird-Meertens formalism, affectionately known as the Squiggol approach.  The most famous paper in that vein is surely Functional Programming with Bananas, Lenses, Envelopes and Barbed Wire.

I meant that the specialization of a short-circuiting foldl to 'and' and 'true' gets you andmap.  You may decide to hand-code andmap differently.  A gentle introduction to this is here.  Graham Hutton also wrote a more through (but readable) introduction in JFP (see page 2 in particular).

The only unbiased review(s) that I am aware of that cover a decent chunk of functionality (instead of being very very specific) are from Michael Wester, A Critique of the Mathematical Abilities of CA Systems.  Unfortunately, it is quite old (1999), so quite a lot has changed then.  Not that more than 20% of the bugs identified in that review have been fixed, but lots of new functionality has been added since.  So the overall picture needs updating.  But the time investment to do such a critique is gigantic, and under-appreciated.

Other reviews have appeared in the popular (technical) press, but I found all of them quite biased.  For example, this review in Bitwise shows really poor understanding of Maple, and so Mathematica comes out ahead.  Perhaps that review is really an indictment of how awful Maple's documentation is.  Maple is a better functional language than Mathematica, but that reviewer does not think so.  That is probably because the Mathematica documentation is not afraid to teach users new ideas, while the Maple documentation tries really hard to keep the number of concepts to an absolute minimum.  [For a student audience, Maple's approach is clearly superior.  For an audience of smart professionals, I believe that Mathematica's is better].

Would it have been better if Maple had an iron-fisted leader?  If that leader was working at and for Maplesoft, and his job/salary depended on the success/failure of the product, then yes, I think that would have made things better.  Not for the employees though -- I have talked to many very smart ex-Wolfram Research employees, and they all despised working for Stephen Wolfram.  But they were also quite proud of their accomplishments.  But having a remote boss is a very bad idea, no matter how good the boss might be.

Maplesoft currently firmly believes that it adds significant value to Maple every release, enough that it can convince the majority of its customers to upgrade.  As long as that is that case (ie that they can convince enough customers that that is the case), then there is no real business case for going open source.  Well, not completely.  There are quite a few esoteric routines that exist in Maple, where Maplesoft has no real expertise in-house, but yet contain bugs; if these bugs annoy enough people, but at the same time it is clear that there is expertise in the greater Maple community to get these bugs fixed, then some parts of Maple could be heaved off into an open source "chunk" of the library.  There are all sorts of ways this could be done in ways that could be win-win.  The other possibility is that Maplesoft finds it has a much bigger market in derivative products, and the ROI on incremental improvements to Maple itself become negative [this could happen, but is not the case now].  At that time, the issue of open source could be fruitfully reconsidered.

Maple has 'lived' for 28 years.  I doubt that it is going to die anytime soon, especially as the company is quite healthy (financially).  But in software-years, 28 is very firmly into middle-age.  Maple is showing a certain amount of 'bulging up' in the middle.

The only unbiased review(s) that I am aware of that cover a decent chunk of functionality (instead of being very very specific) are from Michael Wester, A Critique of the Mathematical Abilities of CA Systems.  Unfortunately, it is quite old (1999), so quite a lot has changed then.  Not that more than 20% of the bugs identified in that review have been fixed, but lots of new functionality has been added since.  So the overall picture needs updating.  But the time investment to do such a critique is gigantic, and under-appreciated.

Other reviews have appeared in the popular (technical) press, but I found all of them quite biased.  For example, this review in Bitwise shows really poor understanding of Maple, and so Mathematica comes out ahead.  Perhaps that review is really an indictment of how awful Maple's documentation is.  Maple is a better functional language than Mathematica, but that reviewer does not think so.  That is probably because the Mathematica documentation is not afraid to teach users new ideas, while the Maple documentation tries really hard to keep the number of concepts to an absolute minimum.  [For a student audience, Maple's approach is clearly superior.  For an audience of smart professionals, I believe that Mathematica's is better].

Would it have been better if Maple had an iron-fisted leader?  If that leader was working at and for Maplesoft, and his job/salary depended on the success/failure of the product, then yes, I think that would have made things better.  Not for the employees though -- I have talked to many very smart ex-Wolfram Research employees, and they all despised working for Stephen Wolfram.  But they were also quite proud of their accomplishments.  But having a remote boss is a very bad idea, no matter how good the boss might be.

Maplesoft currently firmly believes that it adds significant value to Maple every release, enough that it can convince the majority of its customers to upgrade.  As long as that is that case (ie that they can convince enough customers that that is the case), then there is no real business case for going open source.  Well, not completely.  There are quite a few esoteric routines that exist in Maple, where Maplesoft has no real expertise in-house, but yet contain bugs; if these bugs annoy enough people, but at the same time it is clear that there is expertise in the greater Maple community to get these bugs fixed, then some parts of Maple could be heaved off into an open source "chunk" of the library.  There are all sorts of ways this could be done in ways that could be win-win.  The other possibility is that Maplesoft finds it has a much bigger market in derivative products, and the ROI on incremental improvements to Maple itself become negative [this could happen, but is not the case now].  At that time, the issue of open source could be fruitfully reconsidered.

Maple has 'lived' for 28 years.  I doubt that it is going to die anytime soon, especially as the company is quite healthy (financially).  But in software-years, 28 is very firmly into middle-age.  Maple is showing a certain amount of 'bulging up' in the middle.

algcurves[plot_real_curve] is what you are after. It is puzzling to me that implicitplot still does not have a special case for algebraic curves that uses this much better special subroutine.

The computations could be done using RootOf notation, and then only on exit can these be converted to radical notation for presentation to the user. 

Plus, it is not the Student package's job to deal with weaknesses in solve!  The problem should be fixed at the source.  I have found that, over the years, every single patch done to 'hide' a bug in some other part of Maple all too often introduces more bugs of its own.  Plus some patches very often are oblivious to improvements to the underlying system (which caused the reason for the patch to begin with), causing much code rot over time.  I have written such patches in the past, and have now come to regret doing that.  

Although I must admit to a real (but perverse) pleasure I derived by fixing several bugs in Maple by removing other people's bit-rotted patches!  Maybe I should let other developers also have that guilty pleasure, by not advocating this position too strongly!

The computations could be done using RootOf notation, and then only on exit can these be converted to radical notation for presentation to the user. 

Plus, it is not the Student package's job to deal with weaknesses in solve!  The problem should be fixed at the source.  I have found that, over the years, every single patch done to 'hide' a bug in some other part of Maple all too often introduces more bugs of its own.  Plus some patches very often are oblivious to improvements to the underlying system (which caused the reason for the patch to begin with), causing much code rot over time.  I have written such patches in the past, and have now come to regret doing that.  

Although I must admit to a real (but perverse) pleasure I derived by fixing several bugs in Maple by removing other people's bit-rotted patches!  Maybe I should let other developers also have that guilty pleasure, by not advocating this position too strongly!

andmap is by definition what you get when you unfold and simplify the definitions in

andmap := () -> foldl(`and`, true, args)

Even short-cut fusion can be integrated in that if one also 'knows' that false is absorbing for and.