That is not really a bug, that is what is referred to as an ``ordering problem''. In other words, depending on internal ordering of things, different computation paths are chosen, where some lead to a successful computation, while other lead to the Warning you see above.
In Maple parlance, these are not classified as "bugs" per se, they are instead called "weaknesses". This is because the answer is not wrong, strictly speaking, just inconvenient. And inconveniencing the user is considered to be somewhat acceptable, while giving wrong answers is not. And least the second part is easy to agree with...
That is not really a bug, that is what is referred to as an ``ordering problem''. In other words, depending on internal ordering of things, different computation paths are chosen, where some lead to a successful computation, while other lead to the Warning you see above.
In Maple parlance, these are not classified as "bugs" per se, they are instead called "weaknesses". This is because the answer is not wrong, strictly speaking, just inconvenient. And inconveniencing the user is considered to be somewhat acceptable, while giving wrong answers is not. And least the second part is easy to agree with...
Since Maple has no proper mechanism for name-binding, the k in the limits above is not properly 'scoped'. This clear design bug has a definite advantage, in that you do not need the above trickery and can simly write
limit(a, k=infinity) assuming k::integer
Of course, anyone knowing enough math (or CS) would know that that is complete nonsense because of alpha-conversion. But it seems that the early designers of Maple had never taken a course in the lambda calculus, so expression-level bound names do not really ``exist''.
Since Maple has no proper mechanism for name-binding, the k in the limits above is not properly 'scoped'. This clear design bug has a definite advantage, in that you do not need the above trickery and can simly write
limit(a, k=infinity) assuming k::integer
Of course, anyone knowing enough math (or CS) would know that that is complete nonsense because of alpha-conversion. But it seems that the early designers of Maple had never taken a course in the lambda calculus, so expression-level bound names do not really ``exist''.
No, the name MaplePlayer only describes that the technology can deal with interactivity (i.e. "play back" some interactive Maple), not that the underlying content necessarily has to be interactive -- that is obviously up to the author to decide.
MapleReader sounds very passive. Users might not ever discover that it actually supports rich interaction with a name that so under-represents what is actually possible.
From the bits that I heard, it seems that "MapleReader" is a misleading name. For one, I thought it would be a free worksheet/document 'reader' (like Mathematica's). Instead, it appears to be more like an app that can "play back" Maple sessions encoded as eBooks, no?
A true MapleReader would be quite welcome indeed -- and perhaps that name should be reserved for that application. Since things have not yet been announced in a formal way, there is still time to change the name of the current application to something more informative as to its actual purpose.
Still, acer was right, abusing the point release mechanism for the purpose of distributing some tools to a few authors is serious overkill, and rather dangerous to boot.
int( (x^2+1)^(3/2),x=0..1) and int( (x^2+1)^3/2,x=0..1) are completely different!
The first has for integral 48/35 and the second is 7/8*2^(1/2)-3/8*ln(2^(1/2)-1), both of which Maple gets easily.
int( (x^2+1)^(3/2),x=0..1) and int( (x^2+1)^3/2,x=0..1) are completely different!
The first has for integral 48/35 and the second is 7/8*2^(1/2)-3/8*ln(2^(1/2)-1), both of which Maple gets easily.
I wonder, if we ask nicely, maybe Maplesoft would agree to releasing the yacc grammar for Maple under a reasonable license. Personally, I believe that it is completely to their benefit to have 3rd party developers create various value-added products around Maple, as this kind of activity can only increase the use of Maple itself.
My guess is that inner is not type-specific, so that it has to do some typechecking dynamically (either that, or this checking is done by the internal + and *). Also, I am not sure if inner has a special case for dense vectors, so it might go through all the rtable indirection code too.
Basically, going through GMP, you are 'compiling' the routine by asserting GMP_integer+dense, thereby getting rid of a lot of indirection.
This one got me curious, so I looked. So first the magic incantations, then the code
> interface(verboseproc=2): kernelopts(opaquemodules=false):
> print(XMLTools:-ReplaceChild);
proc(spec::equation, xmlTree::function)
description "replace the Nth child of a node in an XML tree\
with a given new child";
`if`(`newFormat?`(xmlTree), NSXML:-ReplaceChild,
SimpleXML:-ReplaceChild)(args)
end proc
Here we encounter our first surprise: apparently there are 2 internal formats supported by the XML tools package. A little digging shows that NS stands for 'name space'. So basically XML with and without namespaces have different data-structures, and these are both supported.
Let's look the simple routine first:
> print(XMLTools:-SimpleXML:-ReplaceChild);
proc(spec::equation, xmlTree::function)
description "replace the Nth child of a node in an XML tree\
with a given new child";
op(0, xmlTree)(op(Attributes(xmlTree)),
op(subsop(spec, ContentModel(xmlTree))))
end proc
And here we see the direct call to subsop, and the typechecking consistent with that.
The NS routine is
> print(XMLTools:-NSXML:-ReplaceChild);
proc(spec::equation, doc)
local childPos, newChild;
childPos, newChild := op(spec);
if not type(childPos, 'posint') then error "child posi\
tion must be specified as a positive integer, but \
received %1", childPos
elif ContentModelCount(doc) < childPos then error
"position %1 is greater than the number of children",
childPos
else XMLElement(ElementName(doc), Attributes(doc),
subsop(childPos = newChild, ContentModel(doc)))
end if
end proc
which makes it clear where the error comes from. But look, the implementation also uses subsop!
Basically this looks like a pure inconsistency between the two branches of the code, where the type checking in the NS branch is overzealous.
It is not so difficult to do if you are starting from scratch. However, if you try to do it on mid 80s software architecture and designs, it is either impossible or so bug-ridden as to be unrealistic for a commercial product.
The current data-structures for plot are fundamentally one-way structures, that do not contain good hooks for two-way communication. In fact, they are also non-mutable (even though some of the pieces are mutable, the important top-level parts are not).
This is one instance where I sincerely hope that I am wrong, that I have overlooked some ``solution'' which will allow Maplesoft to make a big leap forward in plotting capabilities without having to do a complete rewrite of the whole plotting infrastructure.
Try it with
> libname := "C:\\Program Files\\Maple 11\\MyLib\\Algolib", libname;
instead. On Windows, I believe that the forward slash / confuses Maple somewhat.
In any case, to make sure you have the right version, you can do
> interface(verboseproc=3);
print(Groebner);
If you have the one from INRIA loaded up, it will have a export of GB_Internals but also a _pexports list that suppresses the printing of that export! In fact, it seems to be a bug that it sometimes is printed at all. Also, there is a copyright line on the INRIA version.
So even if with(Groebner) does not show GB_Internals in its output, it is still there. I have verified this on my own copy of Maple 11 with a fresh install of Algolib in the same directory as you have.
Try it with
> libname := "C:\\Program Files\\Maple 11\\MyLib\\Algolib", libname;
instead. On Windows, I believe that the forward slash / confuses Maple somewhat.
In any case, to make sure you have the right version, you can do
> interface(verboseproc=3);
print(Groebner);
If you have the one from INRIA loaded up, it will have a export of GB_Internals but also a _pexports list that suppresses the printing of that export! In fact, it seems to be a bug that it sometimes is printed at all. Also, there is a copyright line on the INRIA version.
So even if with(Groebner) does not show GB_Internals in its output, it is still there. I have verified this on my own copy of Maple 11 with a fresh install of Algolib in the same directory as you have.
Thank you for you comments about the branch cuts, you point out valuable issues that I should have been clearer on. I'll blame a combination of a cold and it was late when I wrote that.
On the other hand, I stand by my words on the different forms of arguments. The issue is that one form leads to a value "on top" of the cut, the other form "underneath" the cut, and so very different results. The point being that one of the more natural forms of the complex numbers (ie polar notation) captures the multi-branch issues much better than the projection back down to the cartesian version of the complex plane. In other words, in polar notation one can directly see the Riemann surface associated with the logarithm (and so easily that of the various power functions, like sqrt), which is not so easily seen otherwise.
