You'll notice a trend (which has been bemoaned here before): there are many links from new help pages to old ones, but very few from old pages towards new. curry is a new-ish command, unapply is antediluvian -- so no links.
The problem with Java is not the fundamental design (though that is a problem with AWT and Swing, but that's another story), it's the noise level around the concepts. You have to type so much to say so little, it's COBOL all over again.
You'll notice that all serious development in Java is done in high-powered IDEs (like Eclipe or IntelliJ), which are extremely successful at cutting down the noise -- its proponents are proud that they tend to type 3-4 characters and the IDE ``completes'' it to 20 or so for them. What they don't seem to get is that in other languages, you don't have that noise present at all, so super-smart IDEs are not as crucial.
By the way, I completely disagree about the whitespace thing: I have used it in Python and Haskell, and I love it. Sure, I had to get over the heresy of it all, but once I got over my brain-washing (perpetrated onto me by people who were more interested in writing efficient parsers than with human-computer interaction issues), I got to really like it.
Why go for the simple solution when I've presented some complicated ones? (Wonder what the HTML tag for sarcasm is?)
Why go for the simple solution when I've presented some complicated ones? (Wonder what the HTML tag for sarcasm is?)
The ``problem'' of Maple putting borders around its plots has been first report around Maple V Release 4. Being able to control this behaviour has been on users' wish lists ever since then. It would be nice if there were some nice online ``feature request'' portion of this site, so that 10 years from now we could see if that's still an open issue...
The only reliable way to change the border issue is to hand-edit the .eps and remove the /drawborder command. All other hacks that I have heard of are fragile.
Hopefully someone else will answer your question about part 2, because I don't know the answer to that. I know how to do that with the plotsetup() command, but that does not affect the GUI. [Because, yes, a number of features in Maple have 3 implementations, one in the core system, one in the Classic GUI and one in Standard. Makes people who call themselves ``software engineers'' tear their hair out when they hear such stories].
Maple (the language) is specialized, and not widely available, so that disqualifies it (in the eyes of most educators) as a contender. If there was a free open-source version of the *language* available (ie sans GUI and with only a core library), they might consider it.
However, I agree with your basic argument. This is why I chose to use Python when I taught an introduction to programming class. The language and interactivity are equally perfect. Plus Python even has an IDE of sorts, lots of nice textbooks, a huge library that is well-documented, a better debugger's than Maple, some nice testing frameworks, etc. Python and Maple resemble each other a lot, actually.
The submission deadline for this workshop has been updated to May 02.
Which is what SAS and related software will allow you to do, even with giant data sets. Neither Maple nor even matlab could touch that, at least in their current versions.
Once you have what you think is a signal, then you can try to find what ``model'' fits it. Still statistical stuff.
Then, once you have a model you are happy with, and you want to understand what information might be hidden in that signal, given that model, that's where Maple could kick in. Only in Maple can you manipulate the model instead of just the underlying data. Decoding the signal might require a model transformation which might not be obvious (think integral transforms, but perhaps in an unusual basis).
Once a signal region has been found that is thought to contain non-noise, then Maple could be used to do ``model fitting'' in interesting ways.
But really, this is the area of strength for SAS, SPSS and the R project. These guys not only dwarf Maplesoft, they make The MathWorks look like "the little guy". Data Analysis is one very
serious business. Ok, dwarf is too kind when you compare to a company with $1.9billion in revenues.
In full symbolic generality, given your corrections, Maple does return an expression for solving of Diff(A,Lambda[inp])=0, but it is equivalent to the input (since it uses a RootOf). Does Mathematica give a closed form that isn't essentially the input? If you have numbers for (some of) the coefficients, that would help -- especially for n and k. For plotting, you'll need to get things down to fewer variables anyways.
Have you tried to open the Mathematica Notebook using Maple? Maple's converter is pretty good, it might get you started.
In full symbolic generality, given your corrections, Maple does return an expression for solving of Diff(A,Lambda[inp])=0, but it is equivalent to the input (since it uses a RootOf). Does Mathematica give a closed form that isn't essentially the input? If you have numbers for (some of) the coefficients, that would help -- especially for n and k. For plotting, you'll need to get things down to fewer variables anyways.
Have you tried to open the Mathematica Notebook using Maple? Maple's converter is pretty good, it might get you started.
I was thinking just the same thing earlier today. However, I had thought of applywhen which would take a predicate instead of a type. Actually, having both available might be a good idea.
Some of those poll results were interesting but perhaps not expected. The polls on which version of Maple do you use, and which interface do you like for example, probably produced unflattering data: too many users are happy enough with older versions of Maple, and too many people seem to prefer not-the-new-GUI (where any in this context is probably too many!).
Of course, it also said that there were a lot of active Maple users out there who might just be convinced to upgrade, if only they were given a compelling reason to do so.
RealRangeUnion := proc() local x;
x:= OrProp(_passed);
`if`(x::specfunc(anything,OrProp), op(x), x);
end;
Your version will break if anyone has the variable X assigned. Also, if OrProp changes its behavious on names, that would break too. It's too bad, because your version is more compact that mine!
Yes, it would need special evaluation rules -- but they would be the same rules as those for
f(x) := x^3;
The biggest issue is that the above has the (very mysterious) side-effect of creating a procedure (whenever f is not already so, or is an unassigned name), and then the entry is stored in its remember table.
The example you give has generated countless calls (and emails and ...) to tech support, where a user's code "seems" to work with a variable x, but not with t or anything else, causing much puzzlement.
In my mind, if this
f(x) := x^3;
should do something, it should do
f := unapply(x^3, x);
[which is what users expect!]. If you want to assign to the remember table [which is rather rare], a less confusing syntax should be used.
