@acer 

The problem was that the purpose of the comment: "describe somewhat what the code is doing" was unclear, in my opinion. So, expanding on it was necessary. And yes, you should pay more attention to the problems of documentation, rather than blaming the OP or other people.

At a superficial level, I am also amused at seeing your efforts in trying to hide you actual identity. But seriously, it seems to me that keeping this behavior along so many years may be the symptom of some disorder.

@acer 

Yes, people (like the OP) frequently use length. But how would you expect them using something different if that command is what they find in the documentation? Is `simplify/size/length` documented anywhere? If not, how would you expect people using it? Certainly no "See Also" help link for it exists in ?length . Are you aware of any place in the documentation providing comparable information on this issue as in your (angry?) reply?

So, I am very happy of reading your comments in a different way (not surprising as our mindsets/backgrounds/interests are quite different). In particular, your reply here does illuminate your previous comment and I find it very interesting. No doubt, it would have been a pitty not "pinching" you about this issue... Nevertheless, I would have no problem in discussing with you about "reading"/"interpretation" issues here or by private mail.  

@acer 

Your comment:

# Three different commands to measure the "size" of an expression.
# Using `length` to measure simplification is not so sensible.
# The command `simplify/size/length` is what simplify(...,size) uses.

deserves further discussion. First, I wonder what is the criteria for a sensible "size" measure in your opinion. I mean theoretical argument favouring any of these commands or some other method. Then, for sure, the command length is being used in many procedures of the simplify family, e.g.:

> showstat(`simplify/Diff`,8);
`simplify/Diff` := proc(e)
local zz, z1;
       ...
   8         if z1 or length(lhs(z1)) < length(e) then
               ...
             end if
       ...
end proc
> showstat(`simplify/Jacobi`,37);
`simplify/Jacobi` := proc(a)
local c0, c1, f, f1, n, n1, d, d1, s, S, SJacobi, err, jacobi;
       ...
  37         if length(f1) < length(f) then
               ...
             end if
       ...
end proc
> showstat(`simplify/Normal`,18);
`simplify/Normal` := proc(r)
local x, r1;
       ...
  18     if length(r1) < 2*length(r) then
           ...
         else
           ...
         end if
       ...
end proc

So, is this usage not sensible? If so, they should be fixed, isn't it?

@Bryon 

Do these improvements include restoring the articles that have been deleted?

@Preben Alsholm 

Yes, it looks like an issue hitting ordinary (non named) modules, like sqrt or int. And actually, what the Maple 2015 Standard GUI shows is a (random?) global name with a lower dash prefix like:

eval(sqrt);
        module() ...  end module
lprint(%);
_m3015132160
eval(_m3015132160);
        module() ...  end module

@Jerome BENOIT 

No, it is also an issue in 2015.1. Actually, I do not expect any fix if Maplesoft developers interpret this change of behavior in the Standard GUI as a non-bug...

@Carl Love 

I see no change in the output of any of the interfaces when executing previously interface(verboseproc= 2). Certainly, I have checked that the kernel is sending to the Standard GUI as result the full sequence of locals. It is the interface that is not showing them.

@tomleslie 

The menu above means the menu on top of this page. White letters on dark background. "More" is on its right end, with a downward arrow.

@tomleslie 

In the menu above: More > Submit Software Change Request . You go here.

Now, getting an acknowledgement from Maple HQ is another issue... I could send you a pair of comments/advices, but they should go by private mail, in case you were interested.

@tomleslie 

I do not understand the linkage that you are making between your location and where you report. For sure, you can use the SCR form of this site from anywhere with internet connection to it (as you seem to have).

@Carl Love 

This procedure `dsolve/numeric/DAE/make_proc` is copyrighted 2003, and the first version that I have installed, and includes it, is Maple 9.50, dated April 2004 (9.03 does not include it, at least with that name). The last line number (after showstat) of this version is 582. So, it looks as this procedure was born already as a "monster", with some later growth jumps, like 595 lines in 11.02  to 717 lines in 12.02.

Your account reminds me this one.

@maple fan 

That idea of using a single non-vanishing component of a vector field as a representation of the scalar field, by f(x,y,z) --> f(x,y,z)*e[x], say, is nice, as the length of the arrow represents the magnitude of the scalar field and the direction represents its sign. So, in principle, there would be no additional information in need of using color.

Now yes, the help page ?plots,fieldplot3d is quite obscure in regards to coloring of the arrows. As far as I could see, the default coloring scheme (used when no color option is given) is not produced in the library code but later, in the renderer itself. Now, the procedure that controls/processes the admissible color option syntax is `plot/control`, and apparently an Array of color values could work, but it would need some experimentation.

So, as a shortcut or hack, I have bypassed it, again manipulating directly the plot structure. For instance, this command produces arrows all red:

> plots:-fieldplot3d([(x*y*z),0,0], x=-1..1,y=-1..1,z=-1..1,color=red):

and the information of color is contained in this COLOR function call:

> p:=plots:-fieldplot3d([(x*y*z),0,0], x=-1..1,y=-1..1,z=-1..1,color=red):
> c:=op(indets(p,specfunc(anything,CURVES))):
> op(-1,c);
                         COLOR(RGB, 1.00000000, 0., 0.)

So, colours can be given to the arrows by substituting this COLOR function call with a HUE function call containing a sequence of float values for each arrow list, as in this test:

> n:=nops(c):
> colorseq:=seq(evalf(i/(n-1)),i=1..n-1):
> subs(COLOR(RGB, 1.00000000, 0., 0.)=COLOR(HUE, colorseq),p);

PD. I have got this plot in Maple 18.02. It seems like a there is change/regression in Maple 2015 spoiling coloring.

@maple fan 

Your question is clear and good, I would say. But a preliminary issue is deciding how to represent a scalar field in the 3-dimensional space (to be seen on a 2-D screen). Something that I have tried, long time ago, was an approximated representation by means of a 3-D (cubic) array of points. Each point's colour represented the value of the field at the point. May be that you or somebody else has a different/better idea for a representation.

@Carl Love 

In my opinion, this property continuous is very poorly documented. See discussions in this thread and the linked one.