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

Exporting `i` might just be super defensive -- an attempt to reduce interference between scripted Maple code to test stuff, and the stuff itself.

There are a few bits of interest, when one looks around names on the ?UndocumentedNames help-page. Take the lines that contain just 1; , and 2; , and 3; in :-SaveSession. Is that done for some purpose related to %,%%, and %%%?

acer

Exporting `i` might just be super defensive -- an attempt to reduce interference between scripted Maple code to test stuff, and the stuff itself.

There are a few bits of interest, when one looks around names on the ?UndocumentedNames help-page. Take the lines that contain just 1; , and 2; , and 3; in :-SaveSession. Is that done for some purpose related to %,%%, and %%%?

acer

I sometimes wonder to what degree apparent ubiquity of bugs may relate to strength of typing. (see python#Typing)

I also wonder why there is so little mention in the Maple manuals of techniques and facilities for testing one's code. How should one write unit tests for one's own programs and packages, for example? I'd like to put something here if I can find time, possibly using what is found in TestTools.

acer

I sometimes wonder to what degree apparent ubiquity of bugs may relate to strength of typing. (see python#Typing)

I also wonder why there is so little mention in the Maple manuals of techniques and facilities for testing one's code. How should one write unit tests for one's own programs and packages, for example? I'd like to put something here if I can find time, possibly using what is found in TestTools.

acer

You have ITS90 defined as a table(), with its entries being the procedures. You've essentially set it up as an old "table-based" package. The modern approach is to set such things up as a "module-based" package.

So, set ITS90 up as a module(). Declare Matrices A, B, C, and Q as module locals, with their explicit definitions inside the module body. Those Matrices only need to be assigned once, in order to be accessible in the procedure exports of the module (package). See my short example using module m and Matrix A above as a template for this. If you do that, then it should work, and entries of the Matrices should resolve when you call the package's procedures in your restarted sessions. For this recommended approach you should savelib to a .mla archive file.

What you are trying to do it not unusual. It's the typical sort of task for which modules were designed.

Alternatively, if you insist on using the older out-of-vogue table-based "package" set-up, then you would need to save both the table ITS90 as well as the Matrices A, B, C and Q to the .mla file. (A .m file might also work, but I would not recommend it.)

See the help-page on writing packages.

acer

You have ITS90 defined as a table(), with its entries being the procedures. You've essentially set it up as an old "table-based" package. The modern approach is to set such things up as a "module-based" package.

So, set ITS90 up as a module(). Declare Matrices A, B, C, and Q as module locals, with their explicit definitions inside the module body. Those Matrices only need to be assigned once, in order to be accessible in the procedure exports of the module (package). See my short example using module m and Matrix A above as a template for this. If you do that, then it should work, and entries of the Matrices should resolve when you call the package's procedures in your restarted sessions. For this recommended approach you should savelib to a .mla archive file.

What you are trying to do it not unusual. It's the typical sort of task for which modules were designed.

Alternatively, if you insist on using the older out-of-vogue table-based "package" set-up, then you would need to save both the table ITS90 as well as the Matrices A, B, C and Q to the .mla file. (A .m file might also work, but I would not recommend it.)

See the help-page on writing packages.

acer

I wouldn't be surprised if it needed 32bit glibc and the runtime linker ld-linux at least, because the mfsd binary under Maple's bin.X86_64_LINUX directory is linked dynamically to that. Ie,

%uname -i
x86_64

%file bin.X86_64_LINUX/mfsd
bin.X86_64_LINUX/mfsd: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.0.0, dynamically linked (uses shared libs), not stripped

%ldd bin.X86_64_LINUX/mfsd
        linux-gate.so.1 =>  (0xffffe000)
        libc.so.6 => /lib/libc.so.6 (0xf7daf000)
        /lib/ld-linux.so.2 (0xf7efa000)

So what is glibc in? Is it glibc-2.10.1-2.i586.rpm ? (Make sure, before you install anything that might clobber your 64bit runtime linker.)

As far as "not being able to locate something about the network" goes, wouldn't it help to state explicitly what the something was?

acer