I think that twixt the two methods, including Joe's contribution about the shift-return, I can get the result that I want. Time to write my first blog, I guess...;-)

 I think that twixt the two methods, including Joe's contribution about the shift-return, I can get the result that I want. Time to write my first blog, I guess...;-)

This brings to mind a new question: Does the forum editor stay in Formatted mode until I select Normal from the drop-down? And can I paste text into the code section from another source and preserve that formatting? Let's try those:

Begin Formatted text by selecting this line and then selecting Formatted I went to the end of the line and pressed shift-return. So far, so good...how about some indenting? indented 3 spaces and again and back to the left margin. Now to paste some code A = 5.123456789;
format long g
for k=1:10
disp(A)
A = A * 10;
end Well, that looks OK. Now back to Normal text mode

Well. That didn't work, did it? You can see my steps documented here. The end result is so not what I expected. It all looks like Normal text to me now, though maybe it will change when I post it.

Upon rereading Joe's post, I decided to change my approach...here is the code pasted aagain while in the Normal mode

A = 5.123456789;
format long g
for k=1:10
  disp(A)
  A = A * 10;
end
...and I pressed shift-return at the end of the "end" statement.
...and again here...now for a regular return

...and then to go back and format the code lines...

OK, the problem that I see is that I selected ONLY the 8 contiguous lines, NOT the lone above, yet, the line above now displays to me in the editor as Formatted. Let's see what happens when I post this.

________________________________

This brings to mind a new question: Does the forum editor stay in Formatted mode until I select Normal from the drop-down? And can I paste text into the code section from another source and preserve that formatting? Let's try those:

Begin Formatted text by selecting this line and then selecting Formatted I went to the end of the line and pressed shift-return. So far, so good...how about some indenting? indented 3 spaces and again and back to the left margin. Now to paste some code A = 5.123456789;
format long g
for k=1:10
disp(A)
A = A * 10;
end Well, that looks OK. Now back to Normal text mode

Well. That didn't work, did it? You can see my steps documented here. The end result is so not what I expected. It all looks like Normal text to me now, though maybe it will change when I post it.

Upon rereading Joe's post, I decided to change my approach...here is the code pasted aagain while in the Normal mode

A = 5.123456789;
format long g
for k=1:10
  disp(A)
  A = A * 10;
end
...and I pressed shift-return at the end of the "end" statement.
...and again here...now for a regular return

...and then to go back and format the code lines...

OK, the problem that I see is that I selected ONLY the 8 contiguous lines, NOT the lone above, yet, the line above now displays to me in the editor as Formatted. Let's see what happens when I post this.

________________________________

I can see it either way. There needs to be a way to predict what the random number sequence will be so that repetitive testing that relies on random numbers will yield a "predictable" sequence of random numbers. But the generator could be initialzed to some random number as you suggest, and there would be a requirement for the user to seed the generator if he wants "repeatably predictable" results from the random number generator.

 >>"Software Change Request" is nothing a user with common mind would try to search for or use ...

I actually submitted my first few bugs to the "Submit Maple Software Change Request" with some trepidation, precisely because I expected to get my hands slapped for using it to report bugs. I didn't get a [negative] response, so I'll continue using it...

 OK, so that seemed to work with only a few bugs. I could learn to use that method, too, if it behaves consistently.

 OK, so that seemed to work with only a few bugs. I could learn to use that method, too, if it behaves consistently.

Yes, that is what I tried first. It seemed obvious. Maybe I was just having a bad forum editor day, but as the new guy, I didn't know what to expect. So let's try this:

You say to select

the lines of code

then click Formatted from 

the Format drop-down...

OK, here goes...here's the first problem. I selected the /4/ lines above this one. But this one looks like code to me. ...and the editor is behaving as if /is/ code. Not what I wanted. So I clicked the Normal style in the drop-down, and /this/ line returned to "Normal". Not what I expected. I'll post this and see what it looks like. The last time I tried this (see above), I got the code style while I was editing, then it changed after I posted it.

Yes, that is what I tried first. It seemed obvious. Maybe I was just having a bad forum editor day, but as the new guy, I didn't know what to expect. So let's try this:

You say to select

the lines of code

then click Formatted from 

the Format drop-down...

OK, here goes...here's the first problem. I selected the /4/ lines above this one. But this one looks like code to me. ...and the editor is behaving as if /is/ code. Not what I wanted. So I clicked the Normal style in the drop-down, and /this/ line returned to "Normal". Not what I expected. I'll post this and see what it looks like. The last time I tried this (see above), I got the code style while I was editing, then it changed after I posted it.

 "remember when things get weird, go to 1D math input worksheet mode..."

Yeah, I guess that I need to put that in my brain and learn my way around 1D math. Makes me wonder what the value of 2D math is...

I tried this with some options and got this...

So this is a Maple bug, because if I define the matrix as below, and copy the variable name from the LHS to a new line as 2D Math, then...it gets pasted, but not as atomic. Then when I change it to atomic, it [apparently] picks up the color from the 2D Math style, and this is different from the original. I can...watch my hands...convert the result to 1D Input...delete the color reference...convert that to 2D Input...and convert that to 2D Math...it doesn't look kwite correct for the 2D Math style, but it works...then one more conversion from the menu above, to 2D Math (even though it is supposed to already /be/ 2D Math) - not the right-click Convert menu that I've been using - and it looks and acts like 2D Math. Whew!

So in my world, this is a bug. I have been messing with this for a few days, on and off, wondering what was going on...I guess this is my "get used to 1D math" lesson!

Thanks for figuring that out ;-)

 I should say here that I didn't expand the document block, at least not intentionally. Because I am new to Maple, I am very likely doing [what Maple 13 thinks are] strange things to Maple.

I copied some text from Help files and pasted it into a document block, formatted as 2D Input. Then, as I explored further, I found the Startup Code function, and decided to see how it worked. I copied the lines that I referenced above from the document and pasted them into the Startup Code dialog. That's when I saw the errant print () statement; it didn't show up before that. It didn't seem as if it belonged there, so I deleted it from the Startup Code dialog, and copied the result back into the document into Maple Input fields. I then changed all similar commands from 2D Input to Maple Input, which made sense at the time.

It is difficult to know when to use the different Maple styles because they are not well-documented in Help, or at least I am having difficulty finding what I want to know. Many examples, even of 2D Input math statements are shown as Maple Input in Help.

I see many authors here recommend using 1D over 2D. But 2D is exactly what I want. I appreciate the power of Maple, but I am coming here from many years of using Mathcad, and I am used to having a document mode that not only solves my problem, but facilitates a published result. My 3 main math tools are Mathcad, MATLAB, and Maple. I have used Maple on and off for a few years, but am now getting to know it on a regular basis. It has many nice documenting features, but I find that in general it is not ready for prime time wrt professional documenting. I actually didn't try to get it to meet my needs until V13, because what I want is the document interface. Without that, it's a nice tool, a powerful tool, but one that requires me to document in another environment and copy results to it.

At any rate, I am creating my own "tutorial" document, and it is filled with odd behaviors. I appreciate the responses on this list, because without them, I would have accomplished only a small fraction of my progress in using Maple, and I am determined to get the most out of it.

 I should say here that I didn't expand the document block, at least not intentionally. Because I am new to Maple, I am very likely doing [what Maple 13 thinks are] strange things to Maple.

I copied some text from Help files and pasted it into a document block, formatted as 2D Input. Then, as I explored further, I found the Startup Code function, and decided to see how it worked. I copied the lines that I referenced above from the document and pasted them into the Startup Code dialog. That's when I saw the errant print () statement; it didn't show up before that. It didn't seem as if it belonged there, so I deleted it from the Startup Code dialog, and copied the result back into the document into Maple Input fields. I then changed all similar commands from 2D Input to Maple Input, which made sense at the time.

It is difficult to know when to use the different Maple styles because they are not well-documented in Help, or at least I am having difficulty finding what I want to know. Many examples, even of 2D Input math statements are shown as Maple Input in Help.

I see many authors here recommend using 1D over 2D. But 2D is exactly what I want. I appreciate the power of Maple, but I am coming here from many years of using Mathcad, and I am used to having a document mode that not only solves my problem, but facilitates a published result. My 3 main math tools are Mathcad, MATLAB, and Maple. I have used Maple on and off for a few years, but am now getting to know it on a regular basis. It has many nice documenting features, but I find that in general it is not ready for prime time wrt professional documenting. I actually didn't try to get it to meet my needs until V13, because what I want is the document interface. Without that, it's a nice tool, a powerful tool, but one that requires me to document in another environment and copy results to it.

At any rate, I am creating my own "tutorial" document, and it is filled with odd behaviors. I appreciate the responses on this list, because without them, I would have accomplished only a small fraction of my progress in using Maple, and I am determined to get the most out of it.

 Thanks to both David and acer.

I am just beginning to invest my time in learning Maple, so many of these terms are not familiar to me. Also, I am wary because the Maple document mode seems to have many unpredictable behaviors. (One of these that I just ran into again - and that I had suggested be fixed in V12 - is the Style-Font dialog, which seems to insist on resetting the font when every I go to modify a style font. Seems to me that the dialog should have everything that describes that style highlighted, and not change anything that I didn't change.)

I'll keep in mind the comments about prototyping in worksheets rather than docs, and 1D input, which I can see as faster to enter than 2D in some instances. I also found the comment about libraries interesting, because very soon I would be looking to save my own stuff so that I can use it in multiple docs.

Thanks for taking the time for your replies!

~R~

 Thanks to both David and acer.

I am just beginning to invest my time in learning Maple, so many of these terms are not familiar to me. Also, I am wary because the Maple document mode seems to have many unpredictable behaviors. (One of these that I just ran into again - and that I had suggested be fixed in V12 - is the Style-Font dialog, which seems to insist on resetting the font when every I go to modify a style font. Seems to me that the dialog should have everything that describes that style highlighted, and not change anything that I didn't change.)

I'll keep in mind the comments about prototyping in worksheets rather than docs, and 1D input, which I can see as faster to enter than 2D in some instances. I also found the comment about libraries interesting, because very soon I would be looking to save my own stuff so that I can use it in multiple docs.

Thanks for taking the time for your replies!

~R~