So I think the answer to his question is "no, not in Classic, but it is possible in Standard".
There is most definitely a (good, safe) way to do this -- but I completely forget how to do it. It has been 5 full years since I last touched MapleNet...
You should email support@maplesoft.com, they should be able to tell you how to do this.
Whoever coded this must be a C (or Pascal) programmer who just transposed their knowledge to Maple. The code is at least 3 times larger than it needs to be, and almost every single routine is in the wrong complexity class. And the choice of data-structures is seriously sub-optimal, thereby making the problem much harder than it needs to be.
Plus, there are tons of library functions that should have been used that were re-coded from scratch.
I don't have the time to rewrite it all tonight, but if you are interested, post a reply in this thread, and I will try to get to it in August.
Whoever coded this must be a C (or Pascal) programmer who just transposed their knowledge to Maple. The code is at least 3 times larger than it needs to be, and almost every single routine is in the wrong complexity class. And the choice of data-structures is seriously sub-optimal, thereby making the problem much harder than it needs to be.
Plus, there are tons of library functions that should have been used that were re-coded from scratch.
I don't have the time to rewrite it all tonight, but if you are interested, post a reply in this thread, and I will try to get to it in August.
You don't have a triple-exponential with a kk factor. So Maple gets all confused because all the systems it tries to solve are inconsistent, so it tries a bunch of different variations. Plus, it works extra-hard because the constants involved (like exp(1)^(exp(1)) ) cannot be handled by the usual heuristics (like testeq()), so it does lead to rather complex computations.
Of course, any human can solve the problem rather quickly, since it's obvious that things are in different scales. asmpyt on 'pp' returns pp itself! I think the problem is that solve/identity only has some hacks for recognizing scales, not a full-fledged algorithm, so what you are asking involves too many simultaneous scales, which defeats the hacks.
As it turns out, I am pretty sure I know where the problem lies, but since I don't have check-in rights anymore, that doesn't help so much.
Since you don't really use your array at all but need the name, f can be shortened to
f := (z,n) -> mul(z[i],i=1..n);
then you can use it as f(x,3) as expected. This way you get the global 'x' instead of a local one (which looks the same but are different variables).
If you will be calling f a lot [with the same arguments], you might consider putting option remember on it.
Since you don't really use your array at all but need the name, f can be shortened to
f := (z,n) -> mul(z[i],i=1..n);
then you can use it as f(x,3) as expected. This way you get the global 'x' instead of a local one (which looks the same but are different variables).
If you will be calling f a lot [with the same arguments], you might consider putting option remember on it.
What I find most disconcerting about bug reports on MaplePrimes is that we have no idea whatsoever if any given bug has been noticed by someone at Maplesoft, and entered it in their tracking system. Some of the bugs reported here are really bad (in different ways, but some of the deeply mathematical errors, like the original post here, as well as some of the stranger behaviour witnessed of the GUI, really deserved a "yep, that's in the database, thanks").
With a bit of full-text-search in the help pages, you would have seen that define was introduced in Maple 4.0. Maple 4.0 was released in late 1985, i.e. 22 years ago. While define has been maintained so that it continues to work [which includes substantial implementation overhauls if I remember well], the fundamental design has not been changed.
In human mathematics, it is extremely rare to use 'n' for anything but an integer. The only reason to do so is when you want to actively confuse your audience, perhaps to test their implicit assumptions. Since this seemed like a genuine question, I did make the implicit assumption that 'n' was meant to be an integer.
This is so ingrained in human mathematics that it used to be a feature of Fortran to make assumptions on variables based on the names. That was actually a rather convenient feature!
In human mathematics, it is extremely rare to use 'n' for anything but an integer. The only reason to do so is when you want to actively confuse your audience, perhaps to test their implicit assumptions. Since this seemed like a genuine question, I did make the implicit assumption that 'n' was meant to be an integer.
This is so ingrained in human mathematics that it used to be a feature of Fortran to make assumptions on variables based on the names. That was actually a rather convenient feature!
What you are saying is that, while the language of mathematics is syntactically ambiguous, it is generally not semantically ambiguous because most mathematical statements are done in a
context from which types can be inferred, which serve to disambiguate the syntax. With this, I agree wholeheartedly.
However, Maple is a fundamentally untyped system. It is not, however, context-free. Assignments (and assume) build "context" after-all, and this context is used in all subsequent computations. Is it possible to use the current notion of context to disambiguate enough of mathematics to make things useful? I don't know, but it is certainly an interesting question.
There is another interesting book on this topic:
Cajori's A History of Mathematical Notation (never mind that it dates from 1929, nothing substantial has changed in mathematical notation since!).
The new GUI was designed for beginner users. And beginners don't do weird things like change default settings for input.
All the bugs that are being documented here are indeed bugs as far as I am concerned, but their source isn't faulty design. The source is faulty requirements analysis! At the absolute minimum, there should have been a requirement that said "these new beginner features should have no undesirable effects on advanced users", from which what you document above could clearly be identified as bugs. But it does not seem like there was such a requirement, and so no use cases (or test cases) were developed to ensure that these negative effects were not present.
The funny thing is, on another mailing list I was arguing with some of the Maple developers that it might, in fact, be a good idea if sometimes the interpretation of user input was context-dependent (i.e. so you could use notation more like standard mathematics, which is very context-dependent). I was shot down in flames by several developers, telling me how horrible it would be to have the interpretation of user input be context-dependent. And now I see that that is exactly what they implemented, albeit most probably by mistake!
But it was a fun and strange route to take to rediscover that simple general formula!
But it was a fun and strange route to take to rediscover that simple general formula!
