I advise not using Units[Natural]. Too many symbols are taken to be units, so that environment has practically no single-character symbols left for general use.

In your example, you probably intended `t` to be a free variable, while `deg` stood for Unit(degree). But under Units[Natural], `t` means tonne.

> with(Units[Natural]):

> t+kg;
                                   1001 [kg]

And that's why the exported `sin` routine choked, because it thought it was getting tonne*degree and not `t`*degree.

In the following solutions, _Z1 means "any integer".

> solve(sin(x*Pi/180)=0,AllSolutions);
                                   180 _Z1~

> restart:
> with(Units[Standard]):
> solve(sin(x*Unit(deg))=0,AllSolutions);
                                   180 _Z1~

> restart:
> with(Units[Natural]):
> solve(sin(tt*deg)=0,AllSolutions);
                                   180 _Z1~

acer

"Changing" a list to a set is a very different sort of operation. It is a (generally non-reversible) change in not only data-structure but in the data itself (ie. uniquification and re-ordering).

Changing an rtable from one form to another (Vector[row] to Vector[column], or Matrix to/from Array, or other more exotic changes) can be considered as quite different. It can preserve the underlying data (stored in a contiguous rectangular array of memory) and merely alter the named structure which controls how elements are accessed. In what sense do the associated types then match "static" in the sense cited?

acer

You appear to have misunderstood my meaning.

I meant that 'Matrix' did not appear to fully fit how you described a static type. The gist was not that `.` behaves differently, but that something of type 'Matrix' could be changed to be something of type 'Array'.

acer

Where you mention the "container" type 'Matrix', you might mean 'rtable' (which, unlike 'Matrix', is in the kernel as a constructor). Consider,

> b := Array(1..2,1..2,[[1,2],[3,4]]);
                                      [1    2]
                                 b := [      ]
                                      [3    4]
 
> b.b; # elementwise
                                   [1     4]
                                   [       ]
                                   [9    16]
 
> rtable_options(b,subtype='Matrix'); # change its type
> b.b;
                                  [ 7    10]
                                  [        ]
                                  [15    22]
 
> rtable_options(b,subtype='Array');
> b.b;
                                   [1     4]
                                   [       ]
                                   [9    16]

acer

I was trying to say that quite a bit of what I see as valuable in Mapleprimes replies aren't actually the answers to the particular question posed in the top of their thread, but rather are side material. That is why I can't quite imagine how having the specific answers to posed specific questions rise to the top will help keep all that ancillary good stuff easily found/organized.

acer

Moving forward to a new question/answer format might be useful.

But I wonder how it might also be possible to mine the first 4 years of Mapleprimes to extract the best code, hint, tips, and solutions that are contained inside the posts and responses. There is a mountain of excellent information already buried in this site.

I would predict that for the foreseeable future the first 4 years' of Mapleprimes content would continue to dwarf whatever new is posted in terms of usefulness and interest, provided that the older material could be easily accessed.

While it's true that a lot of the threads in the forums are simple questions at their inception, the discussions often subsequently branch out. Sometimes the discussions take hard turns. And that is often where the gold lies, not as answers to the original (often mudane or faq'like) questions.

One of the things that I like best about Mapleprimes is that great content (code and knowledge fragments) is availiable without the polish or obscurement of material on the applications center. But such fragments are difficult to collate, which is why I suggested functionality for storing personal site-favourites. Managing browser bookmarks is pretty old-hat. Also, no matter how good any new Search facility is it would be painful to repeat any long search with many matched results, or to have to work harder than necessary to docket side-points of interest found along the way.

In fact, there is now so much great material on this site that it might merit having some single expert wade through and collate it by hand. For example, a book on advanced plotting/graphics techniques could be generated from this site's material alone. Not a dry user-manual sort  of book, but a how-do-I book with motivational examples and lots of The Big Picture.

acer

Change Typesetting level to Extended. Close documents and open a new Worksheet. Run the above code as 1D input in a Worksheet. Then change the trailing colon at the end of the second line to a semicolon, and run it again. For me, in 13.01, the output changes from a sequence of products of pairs of distinct random numbers to a sequence of perfect squares.

That is why it is mysterious and fascinating. The fact that the result is typeset as 2D output affects the actual object that gets created. Whether the 2D output of something entered in 1D is suppressed, or not, affects the object created.

acer

Change Typesetting level to Extended. Close documents and open a new Worksheet. Run the above code as 1D input in a Worksheet. Then change the trailing colon at the end of the second line to a semicolon, and run it again. For me, in 13.01, the output changes from a sequence of products of pairs of distinct random numbers to a sequence of perfect squares.

That is why it is mysterious and fascinating. The fact that the result is typeset as 2D output affects the actual object that gets created. Whether the 2D output of something entered in 1D is suppressed, or not, affects the object created.

acer

Could these incorrect and problematic automatic simplificiations in the Standard GUI be related to Extended (as opposed to Maple Standard) Typesetting level?

I realize that might be weird, if the underlying procedure bodies themselves have the incorrect simplification even when entered in 1D Maple Notation. (One might expect that for 1D input the Typesetting level would affect only the displayed 2D output, and not the underlying objects that get created.)

acer

Could these incorrect and problematic automatic simplificiations in the Standard GUI be related to Extended (as opposed to Maple Standard) Typesetting level?

I realize that might be weird, if the underlying procedure bodies themselves have the incorrect simplification even when entered in 1D Maple Notation. (One might expect that for 1D input the Typesetting level would affect only the displayed 2D output, and not the underlying objects that get created.)

acer

Thank you, Robert, for that extra detail. The fact that this is a problem with parsing of 2D Math input in any active Worksheet/Document (and not just with the process that creates the 2D Math Help for Standard) means that it a serious problem.

acer

Thank you, Robert, for that extra detail. The fact that this is a problem with parsing of 2D Math input in any active Worksheet/Document (and not just with the process that creates the 2D Math Help for Standard) means that it a serious problem.

acer

Thanks, Will. It really does seem to be much better.

On a handful of previously problematic search examples, it's now doing great. It either gets right to the best page, or places it at top (or very close).

I had success with searches for terms such as for, Im, INTERFACE_HELP, include, add, fourier, where all did much better than before.

In some cases the results are "better" ranked than in 13.01 itself (eg, search for linearsolve , fortran, Jacobian) .

I had to search for `+` to get to ?arithop, while a search for unquoted + didn't succeed. I'm not sure how you could handle that. It might be a solitary exception.

acer

Typically you would have a package development worksheet (or text file) that would contain things such as this:

# The whole package source, laid out nicely in say a module() definition.
# Comment your sources well.

# Lines to set libname, create an archive, and savelib 

Then, whenever you wanted to adjust the package wou would run that "development" source.

It is also good practice to have another "test" worksheet with the following:

# Prepend to libname, to pick up the package's archive.

# Run examples which test the functionality.

There's a lot more that can be said about ways to do these tasks. I have only described one simple approach. One could write a whole book chapter on just this topic. The key things are to find ways that 1) suit you, 2) safely keep the source and work robustly, and 3) let you easily adjust your routines' functionality.

For example, I personally would not keep my source code in a Worksheet/Document. If the sheet becomes corrupt, it might be difficult to recover the encoded contents. (It sometimes happens.) There is nothing that comes close to the integrity of a plain text file. If you don't want to run the commandline Maple interface in order to "rebuild" your .mla archive then the development worksheet could call read to get the plaintext source.

It is often possible to fully inspect the routines inside a .mla archive, but it is more involved to extract them. It's much more straightforward to simply keep the source as explicit source, and then to "rebuild" as desired. Not also that the routines inside the .mla archive no longer contain source comments.

There is also the whole question about making Help for your package.

I suggest reading the Advanced Programming Manual.

See also, read, include, LibraryTools, makehelp, INTERFACE_HELP

acer

Typically you would have a package development worksheet (or text file) that would contain things such as this:

# The whole package source, laid out nicely in say a module() definition.
# Comment your sources well.

# Lines to set libname, create an archive, and savelib 

Then, whenever you wanted to adjust the package wou would run that "development" source.

It is also good practice to have another "test" worksheet with the following:

# Prepend to libname, to pick up the package's archive.

# Run examples which test the functionality.

There's a lot more that can be said about ways to do these tasks. I have only described one simple approach. One could write a whole book chapter on just this topic. The key things are to find ways that 1) suit you, 2) safely keep the source and work robustly, and 3) let you easily adjust your routines' functionality.

For example, I personally would not keep my source code in a Worksheet/Document. If the sheet becomes corrupt, it might be difficult to recover the encoded contents. (It sometimes happens.) There is nothing that comes close to the integrity of a plain text file. If you don't want to run the commandline Maple interface in order to "rebuild" your .mla archive then the development worksheet could call read to get the plaintext source.

It is often possible to fully inspect the routines inside a .mla archive, but it is more involved to extract them. It's much more straightforward to simply keep the source as explicit source, and then to "rebuild" as desired. Not also that the routines inside the .mla archive no longer contain source comments.

There is also the whole question about making Help for your package.

I suggest reading the Advanced Programming Manual.

See also, read, include, LibraryTools, makehelp, INTERFACE_HELP

acer