Raw use of 'is' is not recommended. It is safer (and much more powerful) to replace is(t>m) with signum(t-m)=1. signum actually calls is multiple times with different questions which can help resolve the problem.

Raw use of 'is' is not recommended. It is safer (and much more powerful) to replace is(t>m) with signum(t-m)=1. signum actually calls is multiple times with different questions which can help resolve the problem.

I like the point about CorelDraw -- it agrees with what I just said in another thread about pointy-clicky solutions being sub-optimal because they do not scale up nicely.

All my instincts as a programmer and designer scream "there is a bug here". The bug might be in the design, but this kind of inconsistency pretty much always leads to bugs; they can be patched, but that usually leads to more bugs in the long run.

All my instincts as a programmer and designer scream "there is a bug here". The bug might be in the design, but this kind of inconsistency pretty much always leads to bugs; they can be patched, but that usually leads to more bugs in the long run.

Read the tea leaves -- or in this case, the What's New, for say Maple V R4 until Maple 11. Create a nice tally chart of the amount of relative effort spent on different parts of the system and in different categories (core improvements, bug fixing and rationalization, new features asked for by users, ``innovative'' features). You'll see clear and obvious trends [not all linear!], although it will be hard to judge how much bug fixing has really happened. Note that there is also a strong correlation between this timeline and the professionalization of Maple development. In other words, over that same timeframe, Maple development shifted from being done 90% in research labs, 10% at the company, to 10/90. So a strong shift towards things that can ``sell''. It is also important to note that the developers (at least the ones I know) at Maplesoft really would love to make a lot of core improvements. They all have long personal lists of improvements that they would really like to see done. But, unlike developers working at Google, their schedule does not allow them the time for that. That is really one of the huge dilemma facing a company like Maplesoft: how much time should be spent on creating new features that will sell more product versus spending time on core features to make the product better. It is interesting to contrast Maplesoft's path with Wolfram Research's. Creating a similar tally chart from their What's New for the same period creates a completely different picture, with emphasis over time on completely different areas!

Read the tea leaves -- or in this case, the What's New, for say Maple V R4 until Maple 11. Create a nice tally chart of the amount of relative effort spent on different parts of the system and in different categories (core improvements, bug fixing and rationalization, new features asked for by users, ``innovative'' features). You'll see clear and obvious trends [not all linear!], although it will be hard to judge how much bug fixing has really happened. Note that there is also a strong correlation between this timeline and the professionalization of Maple development. In other words, over that same timeframe, Maple development shifted from being done 90% in research labs, 10% at the company, to 10/90. So a strong shift towards things that can ``sell''. It is also important to note that the developers (at least the ones I know) at Maplesoft really would love to make a lot of core improvements. They all have long personal lists of improvements that they would really like to see done. But, unlike developers working at Google, their schedule does not allow them the time for that. That is really one of the huge dilemma facing a company like Maplesoft: how much time should be spent on creating new features that will sell more product versus spending time on core features to make the product better. It is interesting to contrast Maplesoft's path with Wolfram Research's. Creating a similar tally chart from their What's New for the same period creates a completely different picture, with emphasis over time on completely different areas!

Especially in the second case. If the .mw format is an accurate representation of internal data-structures of the GUI (and why would it be otherwise?), then it appears that having multiple commands on one line will be a problem. It is unclear which manipulations will bring the problem to light, but the evidence is there to search for such a bug. It seems that only the first command is "acknowledged" as existing. Of course, it could be that the .mw format does not correspond closely to the internal data-structures. But since the .mw format is proprietary (and undocumented?), and the GUI is done in an OO style, the likelyhood that this is true seems rather remote. And if so, is rather frightening.

email support@maplesoft.com, they are in the best position to help with such platform-specific issues.

Remember that a lot of advanced users of Maple do not do things once or twice, they do it 1000 or 10,000 times. So while you are correct that that is indeed an alternate solution, it is seriously sub-optimal. The whole point of programming languages is to automate tasks; and Maple has particularly powerful programming language at its core. One ``real'' solution is to figure out how to use the Maple programming language to script GUI actions. Rather like the old Worksheet package allows the manipulation of static worksheets and Maplets allow the creation of GUI pieces. [Speaking of which, is there a package like Maplets to create embedded components?]

Remember that a lot of advanced users of Maple do not do things once or twice, they do it 1000 or 10,000 times. So while you are correct that that is indeed an alternate solution, it is seriously sub-optimal. The whole point of programming languages is to automate tasks; and Maple has particularly powerful programming language at its core. One ``real'' solution is to figure out how to use the Maple programming language to script GUI actions. Rather like the old Worksheet package allows the manipulation of static worksheets and Maplets allow the creation of GUI pieces. [Speaking of which, is there a package like Maplets to create embedded components?]

Very cool. Note that you have just taken your first steps towards the land that I am currently enjoying so much: programs-that-write-programs. Postscript is a full-fledged programming languages (which is a fact not enough people know); it just happens that it was mostly designed as a domain specific language (DSL) for ``printing'', even though it can be used for general purposes too. So writing a C program to generate Postscript really is writing a program-that-writes-programs. And you also stumbled upon another important point: some programs are hard to write by hand, but relatively easy to generate. And to tie it in with Maple: mathematical programs are particularly easy to generate with Maple. Some time next week, I hope to have a blog post on just that.

The problem comes in when you symbolically differentiate your formulas (ie dF and dG). While the answers that Maple gives are correct, they are also incredibly numerically unstable. The ``normal'' differentiation rules are known to produce bad results for numerical evaluation -- but it is almost impossible to consider using any other rules (when they exist), since every Calc I instructor would be annoyed. My advice: 1) don't use abs, use piecewise 2) make sure to symbolically simplify your derivative before evaluating it [this often gets rid of trivial sources of instability] 3) consider using a series expansion instead of repeated derivatives

I was not so worried about licensing -- Vim already has a standard scheme, and I would just adopt that. There is no point with going with anything complex for a few simple add-ons to Vim which have no stand-alone value whatsoever. I was more wondering about hosting the files, providing easy access, etc. There are many different choices for this as well. I just wanted to make sure that it was easy. I also need to double-check with the original author!

First, you will get a lot of simplifications if you replace the expand with a call to simplify in the line psi2 := expand(F(r,z)^2): and the same in the next 2 lines. However, these integrals are really very tough. It is quite easy for a human to break them down into pieces which are easier to integrate, but as given, a very tough problem. I suggest you do a domain decomposition yourself, and integrate over each region separately, depending on the local/asymptotic behaviour of the integrand on each region. Specifically, at r=0, the integral in z really wants to diverge (for Izr[1,1], the E part). Maple, on its own, is not able to show that this is not the case, because this is in fact rather subtle. This is where human ingenuity still beats machine algorithms hands-down. But this is also where Maple, as a tool to help, can really make a huge difference. I figured this all out in minutes, with a few symbolic experiments on the integrand using series and asympt. THAT, to me, is still Maple's greatest strength.