The default for Standard is a thing called a Document. But there is also a Worksheet.

One can always open a new one of either, using the File->Open menubar item.

I set my global preference to Worksheet (again, somewhere under Tools->Options).

One can use either 2D or 1D input in a Worksheet.

So, really, there are two sorts of option/choice for the Standard GUI. Both can be set separately. Bot can be set as a preference (globally, for all new sessions).

• 1D Maple input vs 2D Math input
• Worksheet vs Document

Writing cool applications with embedded components linked to live(!) tyepset 2D math equations is where I might use a Document and 2D Math input. But for everyday use, and especially for coding, I use a Worksheet and 1D Maple input.

I like 1D Maple input because what I see is what is actually there, unambiguously.

acer

I understand, if you are saying the 2D Math input in the Standard GUI is radically different (and possibly very much not to your liking) from the input mode of the Classic GUI.

But how is 1D Maple input in Standard so much different from the input mode of Classic?

When you write that, "it's practically impossible to enter the commands in Standard," I can't help but think that perhaps you're only trying it with 2D Math input.

The 1D Maple input form of Standard, however, is pretty much the same (red, non-typeset) input that I'd known in Classic. No on-the-fly typesetting of input. No implicit multiplication. No special 2D Math parser. No subscripting of table entries (in the input). I use that, in Worksheet mode, and it's ok for me.

ps. The trick of using the 32bit Classic interface with the 64bit Linux Maple 12 installation will not work completely unless all the new (new specifically in M12) binaries are added to the set of symlinks (into the "new" directory, under that scheme). It was originally done for M10, and the posted scheme seems to work by symlinking all the 64bit binaries not used  by the TTY interface's libmclient.so. But new binaries have been added bewteen M10 and M12.

acer

I understand, if you are saying the 2D Math input in the Standard GUI is radically different (and possibly very much not to your liking) from the input mode of the Classic GUI.

But how is 1D Maple input in Standard so much different from the input mode of Classic?

When you write that, "it's practically impossible to enter the commands in Standard," I can't help but think that perhaps you're only trying it with 2D Math input.

The 1D Maple input form of Standard, however, is pretty much the same (red, non-typeset) input that I'd known in Classic. No on-the-fly typesetting of input. No implicit multiplication. No special 2D Math parser. No subscripting of table entries (in the input). I use that, in Worksheet mode, and it's ok for me.

ps. The trick of using the 32bit Classic interface with the 64bit Linux Maple 12 installation will not work completely unless all the new (new specifically in M12) binaries are added to the set of symlinks (into the "new" directory, under that scheme). It was originally done for M10, and the posted scheme seems to work by symlinking all the 64bit binaries not used  by the TTY interface's libmclient.so. But new binaries have been added bewteen M10 and M12.

acer

You can set the input mode in the Standard GUI to be 1D Maple input, in Worksheets, as a preference (globally) for all new sessions.

See Tools->Options->Display.  Apologies, if you already knew that.

acer

You can set the input mode in the Standard GUI to be 1D Maple input, in Worksheets, as a preference (globally) for all new sessions.

See Tools->Options->Display.  Apologies, if you already knew that.

acer

For reasons not altogether clear, the code posted is not accepted by the 2D Math parser in Maple 12.

I suggest entering it in 1D Maple input instead of 2D Math input. (See the Tools->Options->Display tab for control of this mode. It can also be toggled directly, using the F5 key I believe.)

acer

For reasons not altogether clear, the code posted is not accepted by the 2D Math parser in Maple 12.

I suggest entering it in 1D Maple input instead of 2D Math input. (See the Tools->Options->Display tab for control of this mode. It can also be toggled directly, using the F5 key I believe.)

acer

This did work for me. I had presumed that you forgot to post the assignment of 0 to n.

n:= 0:
for i from .1 by .1 to 5 do
  n := n+1;
  P[n] := (i*2+3*i^2);
  X[n] := [n, P[n]];
end do:
plots:-listplot( [seq(X[i],i=1..50)] );

What Doug says about generating lists more efficiently is good advice. What's relevant there is that you know the length (number of entries) in advance, so you know what range to supply to `seq`, etc. But don't feel bad. Your technique actually uses Maple table structures, and is appropriate for many other sequential tasks for which one doesn't know the length in advance. The truly bad way to do such things is to create appended lists inside loops, repeatedly doing L:=[op(L), newvalue]. Use of tables is much less bad.

acer

This did work for me. I had presumed that you forgot to post the assignment of 0 to n.

n:= 0:
for i from .1 by .1 to 5 do
  n := n+1;
  P[n] := (i*2+3*i^2);
  X[n] := [n, P[n]];
end do:
plots:-listplot( [seq(X[i],i=1..50)] );

What Doug says about generating lists more efficiently is good advice. What's relevant there is that you know the length (number of entries) in advance, so you know what range to supply to `seq`, etc. But don't feel bad. Your technique actually uses Maple table structures, and is appropriate for many other sequential tasks for which one doesn't know the length in advance. The truly bad way to do such things is to create appended lists inside loops, repeatedly doing L:=[op(L), newvalue]. Use of tables is much less bad.

acer

Yes, I knew that, thanks. One reason that I mentioned that help-page was because it describes that launch option.

But that doesn't at all mean the the change couldn't have dramatic consequences. Nobody wants to distribute a 3rd part add-on package whith the stipulation that it has to be run in a session started with --setsort option. What's more, there can be consequences in Maple's own Library related to such differences in behaviour.

I was wondering if anyone had detected such behaviour changes. (..and knows the cause, naturally. People might be affected, for good or for bad and not realize the cause.)

acer

See the help-page ?plot,colornames which shows the valid names.

In the table in that page, "Orange" and "orange" have different values.

That help-page says,

- The new names in the left-most column are the commonly used HTML color
  names. The lower case names in the middle column are the colors originally
  used by Maple, and are retained for backward compatibility. In some cases
  (Blue, White, Yellow) the RGB value is the same, but in others (Maroon,
  Gold) it is quite different.

The situation for Orange is like that for Maroon, in this respect.

acer

See the help-page ?plot,colornames which shows the valid names.

In the table in that page, "Orange" and "orange" have different values.

That help-page says,

- The new names in the left-most column are the commonly used HTML color
  names. The lower case names in the middle column are the colors originally
  used by Maple, and are retained for backward compatibility. In some cases
  (Blue, White, Yellow) the RGB value is the same, but in others (Maroon,
  Gold) it is quite different.

The situation for Orange is like that for Maroon, in this respect.

acer

Instead of what you have above, try that additional option as,

parameterranges = [alpha = 1 .. 100, rho = 1 .. 100]

acer

Instead of what you have above, try that additional option as,

parameterranges = [alpha = 1 .. 100, rho = 1 .. 100]

acer

What error did you get? Perhaps more importantly, what exactly did you enter?

The following works even back to Maple 6,

M := Matrix([[-2,1,3],[-5,7*a,3],[5,-2,a]]):
values := [solve(LinearAlgebra:-Determinant(M))];
seq(LinearAlgebra:-Rank(eval(M,a=values[i])),i=1..nops(values));

acer