Well it was worth a quick try.  For something like x^4 + y^(1/2) the plot carries undefined values which causes it then to choose implicitplot3d and create a graph nothing like what it should look like.

implicit=true is a good idea.  As you say to what extent does maple have to keep looking for alternative coordinate systems.  But also to what extent do we have to keep adding commands to suite our needs (no offense intended).

However, that is a nice question Jakubi asks at the end.  If adaptive mesh is used for implicitplot3d why too isn't it automatically available for plot3d?

implicit=true is a good idea.  As you say to what extent does maple have to keep looking for alternative coordinate systems.  But also to what extent do we have to keep adding commands to suite our needs (no offense intended).

However, that is a nice question Jakubi asks at the end.  If adaptive mesh is used for implicitplot3d why too isn't it automatically available for plot3d?

So it is a difficulty for the rectangular coordinate system.

So it is a difficulty for the rectangular coordinate system.

The online 3d function grapher here appears to use the Maple 12 engine

http://www.livephysics.com/tools/mathematical-tools/online-3-d-function-grapher/

hence exhibits the same results.

stranger things happen when you include the grid options or numpoints option.

That is a great point.  It was no wonder I did not know about it until Acer pointed it out. 

hm, not sure but seemed the same as this
http://www.maplesoft.com/applications/view.aspx?SID=132223&view=html

probably just that .. a test.

A welcome read. 

One graph that bugged me was this.

with(plots):
plot3d(sqrt(25-x^2-y^2),x=-6..6,y=-6..6)

Mathematica really slams Maple here

http://www.wolfram.com/mathematica/compare-mathematica/compare-mathematica-and-maple.html

Let the war begin !

Fair enough, I missed the uneval quotes. 

unassign should have separated the created data from the name and allowed gc() to clear it from memory. 

hmm.. setting the name to some smaller set of data doesn't release the memory either

temp:=Matrix(1)
gc();

kernelopts(bytesalloc)

           same large value

this would suggest maybe (I don't know I'm just speculating) that the problem lies somewhere with gc()

Fair enough, I missed the uneval quotes. 

unassign should have separated the created data from the name and allowed gc() to clear it from memory. 

hmm.. setting the name to some smaller set of data doesn't release the memory either

temp:=Matrix(1)
gc();

kernelopts(bytesalloc)

           same large value

this would suggest maybe (I don't know I'm just speculating) that the problem lies somewhere with gc()

Yes I had thought maybe it could have been unfinished code or even a bug.  But I have discovered that the problem is completely within mstring.dll

Wether it is unfinished or a bug I don't know.  If it was a simple fix it would be nice if maplesoft could simply modify the dll and make the new modified mstring.dll available.  Perhaps someone here is talented enough to fix it?  decompile the dll find the error, fix it, recompile it and make it available. 

**edit added**  I suppose I should mention how I confirmed the problem was with mstring.dll.  Transfering mstring.dll from a newer maple version into the old allows Create(ospd3) to work.  However I will not use it because there may be other unseen side effects which break other commands.

ospd3 has existed since at least M9.5 but cannot work until M15 when the mstring.dll file size jumped from 870 Kb to over 2000 Kb in size suggesting some major work was done on that dll.

Just bringing this up again as some nice applications for scrabble were added to the app center. 

Has anyone figured out why ospd3 does not work?  Is there a workaround??