It just occurred to me that even Maple's own help pages work as I requested.  If you want to go to the section of the help related to the topic under question, you simply hit the + button next to the title.  Only that section expands.  And one can keep walking down through the hierarchly like this expanding as one goes.  I think this is pretty standard and should be fixed.

Here is their answer:

Hello,

What you are asking for in non-auto-expanding sections at runtime is currently not possible without the use of a hide code section solution in Maple. Another possible workaround is to place all of your current relevant work into one section and the remainder into another that is easily collapsible. You may also use the "View"->"Collapse All Sections" menu command to quickly collapse the non-relevant sections.

I have forwarded your issue to our developers for review for possible future version enhancements.

I think this should be fixed.  The document workflow concept suggests that a large amount of work can be captured in one well organized document.  While that is true, if you have to fix one small area (i.e. change the value of a constant on page 50 of the 55 page document), the constant re-expansion of the entire document (55 pages) every time a change is tested is a bit ridiculous.  This is like everytime I want to pick up reading a book where I left off the last time I have to scroll page by page through the 500 page book to find that page where I was reading. 

Here is their answer:

Hello,

What you are asking for in non-auto-expanding sections at runtime is currently not possible without the use of a hide code section solution in Maple. Another possible workaround is to place all of your current relevant work into one section and the remainder into another that is easily collapsible. You may also use the "View"->"Collapse All Sections" menu command to quickly collapse the non-relevant sections.

I have forwarded your issue to our developers for review for possible future version enhancements.

I think this should be fixed.  The document workflow concept suggests that a large amount of work can be captured in one well organized document.  While that is true, if you have to fix one small area (i.e. change the value of a constant on page 50 of the 55 page document), the constant re-expansion of the entire document (55 pages) every time a change is tested is a bit ridiculous.  This is like everytime I want to pick up reading a book where I left off the last time I have to scroll page by page through the 500 page book to find that page where I was reading. 

I loaded your example and I note two things:  (a)  it works as you said, but (b) you have the atomic term on the RHS of the equation.

Perhaps the problem is that I have been doing this on the LHS as in the example I loaded earlier.  Maple gives an error if the LHS is, for example, x^2.  But I can go select x^2 on the LHS, make atomic, and then Maple is happy.  But if I try to go back and remove the atomic condition, I don't get that as an option in the pull down menu.  Probably because Maple doesn't want to let the LHS go back to the illegal x^2.

Comments?

I loaded your example and I note two things:  (a)  it works as you said, but (b) you have the atomic term on the RHS of the equation.

Perhaps the problem is that I have been doing this on the LHS as in the example I loaded earlier.  Maple gives an error if the LHS is, for example, x^2.  But I can go select x^2 on the LHS, make atomic, and then Maple is happy.  But if I try to go back and remove the atomic condition, I don't get that as an option in the pull down menu.  Probably because Maple doesn't want to let the LHS go back to the illegal x^2.

Comments?

Hi - Thanks for the quick reply.

I tried all kinds of cuts and pastes.  Close out software, restart and reopen.  Etc.

Finally I walked through each line testing my ability to convert from 2-D to 1-D without atomic code showing up.  Half way down the document I found a line I couldn't reconvert.  So I typed it back in, this worked on that line.  And then that fixed the rest of the worksheet.

I think I had an embedded bug in all the GUI code.

Thanks for looking into this for me.

Scott

Hi - Thanks for the quick reply.

I tried all kinds of cuts and pastes.  Close out software, restart and reopen.  Etc.

Finally I walked through each line testing my ability to convert from 2-D to 1-D without atomic code showing up.  Half way down the document I found a line I couldn't reconvert.  So I typed it back in, this worked on that line.  And then that fixed the rest of the worksheet.

I think I had an embedded bug in all the GUI code.

Thanks for looking into this for me.

Scott

Your "clarification" question is important to me.  I'm having the same problem.  I want to have a certain set of Worksheet Sections open (troubleshooting local code in one particular section) and most other Sections closed.  And when I want to reexecute with changes, I want the state of open/closed Sections to stay the same.  But Maple 16 always expands the entire Worksheet and all sections.

Basically, I'm looking for an operation just like in Microsoft Excel where you can hide rows or columns in a Worksheet.

Is there a property or method to mark a Section as staying hidden just like there is for hidding a Code Group?

Thanks,

Thanks for the list.

What I finally did was write the files to .txt, edit out the overhead, do a "read" of the module.txt, and then "with" works and things run.

But the links you posted purport to show how to do this inside Maple, so next time around I'll try these approaches.  It sure would make the process cleaner.

Thanks,

Thanks for the list.

What I finally did was write the files to .txt, edit out the overhead, do a "read" of the module.txt, and then "with" works and things run.

But the links you posted purport to show how to do this inside Maple, so next time around I'll try these approaches.  It sure would make the process cleaner.

Thanks,

I tried running this on Mac OS X and Windows.  I'm using Document mode.  And I've tried Remove Output which just makes the stored file smaller.  Doesn't solve the loop forever problem.

Instructions to see issue:

(1) In Mac OS open the Activity Monitor to follow Real Mem parameter for Maple 16.  Remember the Real Mem value.  [Can do this in Windows also using Task Manage view]

(2) Run the sheet with patterns = 256 (a small number).  Do this a few times (!!! button) keeping the semicolon at the "end do" statement in the brown text section labeled PROGRAM near the end of the document.

(3)  Watch the Real Mem value continue to creep up with each run of (2).

(4)  Now try a large number for patterns, say, 4096.  Again, with the semicolon.  At least on my computer (8GB, I5 Processor, Mac OS X), the program just loops forever as it apparently keeps updating the screen.  Never ends, have to restart the computer.

(5)  Go back and try the same thing above, but use a colon instead.  Now use patterns = 10,000 or some huge number.  Runs no problem compared to 4096 and of course much faster.  But this is most likely because the amount of screen writing is now minimized because virtually everything

Download Example.mw

is colon-ed out.  CAUTION!!!  While what I write in (5) is true, there is still a small amount of creep that probably will eventually create the same problem.

I thought there might be a simple way to cause the memory to flush out the window writing file (?) or history (?) or whatever.

Thanks for your interest in looking at this.

I tried running this on Mac OS X and Windows.  I'm using Document mode.  And I've tried Remove Output which just makes the stored file smaller.  Doesn't solve the loop forever problem.

Instructions to see issue:

(1) In Mac OS open the Activity Monitor to follow Real Mem parameter for Maple 16.  Remember the Real Mem value.  [Can do this in Windows also using Task Manage view]

(2) Run the sheet with patterns = 256 (a small number).  Do this a few times (!!! button) keeping the semicolon at the "end do" statement in the brown text section labeled PROGRAM near the end of the document.

(3)  Watch the Real Mem value continue to creep up with each run of (2).

(4)  Now try a large number for patterns, say, 4096.  Again, with the semicolon.  At least on my computer (8GB, I5 Processor, Mac OS X), the program just loops forever as it apparently keeps updating the screen.  Never ends, have to restart the computer.

(5)  Go back and try the same thing above, but use a colon instead.  Now use patterns = 10,000 or some huge number.  Runs no problem compared to 4096 and of course much faster.  But this is most likely because the amount of screen writing is now minimized because virtually everything

Download Example.mw

is colon-ed out.  CAUTION!!!  While what I write in (5) is true, there is still a small amount of creep that probably will eventually create the same problem.

I thought there might be a simple way to cause the memory to flush out the window writing file (?) or history (?) or whatever.

Thanks for your interest in looking at this.

@Alejandro Jakubi 

I hear you with regards to CLI.  The reason I prefer not to use the CLI is exactly the reason I licensed Maple.  I am experienced wih Matlab and SCILAB.  Those tools are great from pure mathematical efficiency and are CLI driven, but very difficult to visualize complex equations.  I recently started using Maple because I needed the added GUI benefit of visualizing large equations in electrostatics - not easy with 300 ASCII characters in one line.

I believe what you are really saying is that I need a hybrid approach perhaps.  Work in the GUI domain when visualization is appropriate and CLI when I need to do heavy computations.  At this point I tend to reluctantly agree.

If I did this type of work regularly I'd perhaps have a different perspective, but I spend 8 weeks a year working at this level and then the rest of the year working on other specialized tools.  No time to become a permanent expert.  GUIs are great for getting up to speed quickly, right?  Up till about 2 months ago I was using SCILAB exclusively.

While I started this discussion on the topic of random vector generation, it wasn't meant to suggest that this is all or primarily what I do.  This is one small part.  Its not efficient for me to use one method for one code set, a GUI for the next code set, and then yet some hybrid for another.  But, as I wrote earlier, maybe that's going to be the only reliable method to avoid the tool locking up.

Thanks for all the discussion.  You've been very kind with your time.

@Alejandro Jakubi 

I hear you with regards to CLI.  The reason I prefer not to use the CLI is exactly the reason I licensed Maple.  I am experienced wih Matlab and SCILAB.  Those tools are great from pure mathematical efficiency and are CLI driven, but very difficult to visualize complex equations.  I recently started using Maple because I needed the added GUI benefit of visualizing large equations in electrostatics - not easy with 300 ASCII characters in one line.

I believe what you are really saying is that I need a hybrid approach perhaps.  Work in the GUI domain when visualization is appropriate and CLI when I need to do heavy computations.  At this point I tend to reluctantly agree.

If I did this type of work regularly I'd perhaps have a different perspective, but I spend 8 weeks a year working at this level and then the rest of the year working on other specialized tools.  No time to become a permanent expert.  GUIs are great for getting up to speed quickly, right?  Up till about 2 months ago I was using SCILAB exclusively.

While I started this discussion on the topic of random vector generation, it wasn't meant to suggest that this is all or primarily what I do.  This is one small part.  Its not efficient for me to use one method for one code set, a GUI for the next code set, and then yet some hybrid for another.  But, as I wrote earlier, maybe that's going to be the only reliable method to avoid the tool locking up.

Thanks for all the discussion.  You've been very kind with your time.

Thanks for the quick reply, Alejandro.  Its not necessarily that I want to see the output, although that is partially true - I'm looking at the quality of a specialized random number generator.  Rather imagine that you are working through writing code and keep rerunning the code as you fix it.  Well, everytime you run the code you increment the amount of archived memory.  So if one sits there all day writing, testing, fixing....eventually the limit creeps up and Maple hangs up.  This happened multiple times over the last day.

Thanks for the suggestions.  I'll play around some more and find something that's not so agravating.

Cheers.