is quite different. At a normal user level, it makes much more sense to be able to look at identity in the mathematical (semantic) sense than at the the low level, memory sense. So, with your vectors:

x := Vector[row]([1,2]);
                                  x := [1, 2]
 
y := Vector[row]([1,2]);
                                  y := [1, 2]
 

The comparison,

if x = y then

should be true. It just requires that `=`, when recognizing that the operands are vectors, call 'LinearAlgebra:-Equal'. Presumably, another command or option should be added for use in development, checking identity at memory level.

Surfplot.ind

Surfplot.lib

Surfplot.ind

Surfplot.lib

With the settings described in my post of that thread I get a decimal point in the graphs also.

With the settings described in my post of that thread I get a decimal point in the graphs also.

Paul,

I have inspected these library files and experimented installing them, but they seem wrong. In particular, I do not see any entry in the Surfplot.ind file. Could you check whether these files work for you?

Paul,

I have inspected these library files and experimented installing them, but they seem wrong. In particular, I do not see any entry in the Surfplot.ind file. Could you check whether these files work for you?

With the library installed:

A := [[1.14, 44.67, .3], [1.14, 44.4, .32], [1.23, 45.13, .24], 
[1.23, 44.93, .21], [1.3, 45.02, .21], [1.305, 44.47, .31], 
[1.34, 44.88, .32], [1.37, 45.19, .26], [1.39, 44.86, .2], 
[1.755, 45.31, .36]];
errorbar(A);

produces the plot.

With the library installed:

A := [[1.14, 44.67, .3], [1.14, 44.4, .32], [1.23, 45.13, .24], 
[1.23, 44.93, .21], [1.3, 45.02, .21], [1.305, 44.47, .31], 
[1.34, 44.88, .32], [1.37, 45.19, .26], [1.39, 44.86, .2], 
[1.755, 45.31, .36]];
errorbar(A);

produces the plot.

A product so general as Maple, intending to reach so diverse kind of users, cannot do it with a single approach. What is "natural" for a person or a group may be unnatural for other. And this is previous and independent to how long experience with Maple is.

On the one hand this is in part a personal issue, ie the way each mind works best. So, you have persons that are lost without a GUI and mousing around, while on the other extreme some others find comfortable only by typing commands on the OS console.

On the other hand there is an issue of group culture and investment. In the hard sciences (Mathematics, Physics, etc) it is a must and the standard to use TeX, and everybody has invested time learning it. So, within this group, it is natural, convenient and expected to use it to type and display math. In particular as it is so good in typesetting. But Maplesoft tries to reach other groups of users, may be Engineers or other, used to word processors, for which TeX may be unnatural.

Note that both points are not easily correlated: the preferences for producing TeX documents may range from using a simple editor, to WYSIWYG like interfaces.

I.e., the better and natural tool set  for each group is unavoidably different. So the point seems to be about priorities of development, diversity of the demands and "market size" of each group.

I think that there have been many requests here at MaplePrimes by members the "TeX-command-group". I may track for them if needed. And a poll or survey could be made to estimate how large fraction of the Maple users base this group is nowadays, if doubts exist on this point.

Note that several other applications addressing this market niche use TeX commands  for input (or use TeX for display). So it is nothing like an unusual request to have a LaTeX-like input alongside, and with the same functionality, as purely GUI input.

A product so general as Maple, intending to reach so diverse kind of users, cannot do it with a single approach. What is "natural" for a person or a group may be unnatural for other. And this is previous and independent to how long experience with Maple is.

On the one hand this is in part a personal issue, ie the way each mind works best. So, you have persons that are lost without a GUI and mousing around, while on the other extreme some others find comfortable only by typing commands on the OS console.

On the other hand there is an issue of group culture and investment. In the hard sciences (Mathematics, Physics, etc) it is a must and the standard to use TeX, and everybody has invested time learning it. So, within this group, it is natural, convenient and expected to use it to type and display math. In particular as it is so good in typesetting. But Maplesoft tries to reach other groups of users, may be Engineers or other, used to word processors, for which TeX may be unnatural.

Note that both points are not easily correlated: the preferences for producing TeX documents may range from using a simple editor, to WYSIWYG like interfaces.

I.e., the better and natural tool set  for each group is unavoidably different. So the point seems to be about priorities of development, diversity of the demands and "market size" of each group.

I think that there have been many requests here at MaplePrimes by members the "TeX-command-group". I may track for them if needed. And a poll or survey could be made to estimate how large fraction of the Maple users base this group is nowadays, if doubts exist on this point.

Note that several other applications addressing this market niche use TeX commands  for input (or use TeX for display). So it is nothing like an unusual request to have a LaTeX-like input alongside, and with the same functionality, as purely GUI input.

If of any interest, my approach to explore this internal form is direct. Very seldom I go to palettes, create atomic identifiers, lprint it, etc. For me this is too clumsy, and I find much more efficient  to go look at the Mathml documentation and adapt it to this particular Maple version. Or browse through my personal documentation of these tricks.

I agree that the user should not deal with this internal format. Frankly, I dislike having to do so. But what is missing is a programatical user interface that translates LaTeX-like commands to this internal form (why not using TeX as internal form?). Palletes or menues may be an alternative for simple or special cases but never a replacement as it is an approach that does not scale well with complexity and is not suitable for reuse.

If of any interest, my approach to explore this internal form is direct. Very seldom I go to palettes, create atomic identifiers, lprint it, etc. For me this is too clumsy, and I find much more efficient  to go look at the Mathml documentation and adapt it to this particular Maple version. Or browse through my personal documentation of these tricks.

I agree that the user should not deal with this internal format. Frankly, I dislike having to do so. But what is missing is a programatical user interface that translates LaTeX-like commands to this internal form (why not using TeX as internal form?). Palletes or menues may be an alternative for simple or special cases but never a replacement as it is an approach that does not scale well with complexity and is not suitable for reuse.

A 3D graphic format has somehow to store 3 coordinates for each point of the ploted object. PostScript is 2D: it stores 2 coordinates for each point, ie it describes plots on a plane. Thus, any 3D object as in your example is projected onto a plane when generating the PostScript plot. And you cannot rotate a PostScript plot about an axis in space as some information was lost in this projection.

I have realized that a detail was missing. There is an issue with spaces (ie parsing I think): a space at one side or at both sides of "V", as in this statement 

PLOT(TEXT([1., 2.], `#mi( "V" )`));

seems needed to get the double quotes in Maple 12.01:

But without spaces:

PLOT(TEXT([1., 2.], `#mi("V")`));

no double quotes are displayed. This effect seems unrelated to Maple 11 vs 12.