Joe Riel

8338 Reputation

22 Badges

15 years, 322 days

MaplePrimes Activity


These are replies submitted by Joe Riel

@rquirt Apologies, I had forgotten about the medium, which is a parameter, not a variable.  Will have to play around with this to see if it is doable, using the Custom Port template. 

I'll submit that as a request for enhancement to the DynamicSystems package.  It shouldn't be hard to implement.

While using the GUI to build a package isn't going to improve the operation, compared to using command-line tools, that isn't necessarily the issue.  I tested by reading the package I previously mentioned from Standard; it also took 2 seconds. Am going to guess that all the warnings you mentioned are the issue; the GUI is definitely slower handling output.  Try it with
 

interface(warnlevel=0):

 

@nm To eliminate the warnings about incomplete strings, do not use strings with actual new lines.  Instead of doing this

str := "A string with an actual new line character,
Maple will complain."

Replace that with

str := "This string also gets a newline,\n"
       "but no warning is raised.";

Note that this second example, in addition to use an escaped new-line character, consists of two literal strings separated by white-space (a new line in the source [after the double-quote], and some spaces).  Maple automatically catenates such strings.
 

@vs140580 Consider doing what I suggested.  Did you try executing currentdir()?   You can always specify the absolute path, rather than the relative path, to the file in the fopen command. That way the current directory doesn't matter. For example

fd := fopen("C:\\Users\\Sriam\\Downloads\\temp_file.txt", 'WRITE');

 

@vs140580 Did you check currentdir()?  Are you sure you are attempting to write to the download directory?  The code you showed doesn't specify the directory, so Maple will use the current directory.  Another possibility is that the file already exists and is write protected. 

Note how acer used $undef statements at the end of the source.  This is good practice, as it helps ensure that the source code can be included in another file (with an $include statement).  The Maple preprocessor will not allow redefining a macro in use, it must first be undefined.

When the source code for a procedure or module with a uses statement is read by Maple, any module referenced in the statement must already be known to Maple.  For example:

(**) foo := module()
(**) option package;
(**) export
(**)     ModuleLoad := proc()
(**)         error "Eureka";
(**)     end proc;
(**) export
(**)     Bar := proc() "Bar"; end proc:
(**) end module:

(**) savelib('foo',"foo.mla"):
(**) restart;
(**) libname := "foo.mla", libname:

(**) bar := proc()
(**) uses foo;
(**)     Bar();
(**) end proc:
Error, (in bar) Eureka |

When Maple evaluated the assignment to bar, it had to load the module foo, which caused its ModuleLoad procedure to be executed, which raised the error.  Consequently, it isn't feasible to use a uses statement in a submodule that references another submodule; neither are assigned when Maple is reading the code. Using $define statements, as acer showed, is one way to allow shorter names.

In your worksheet, using your times, Scale is the fastest (by a small margin). 

A few minor comments.  Probably you don't want to use the extension mpl for the mint output file.  You can, but that is kind of strange in that the output is not Maple code. Without the -o option, mint writes to the screen (in linux that means writes to stdout, I don't know the terminology for Windows but am pretty sure it is equivalent); with the -o option it writes to the file specified by that option.

@Bendesarts You are correct in that if there are syntax errors you won't be able to create an mla file.  However, that will always be an issue.  The ideal solution is to run the file through the Maple mint utility, which detects such errors.  So far as the time taken to create an mla, that is likely not an issue.  I work with a package that loads hundreds of Maple files; it only takes a few seconds to rebuild the mla. Because I work with an editor that is readily customizable, I have it set up so that a function key does the rebuild.  Another key runs the particular file I'm working on through Maple mint.  A cautionary note:  on Windows things are likely more a pain.  I suspect that rebuilding an mla might be problematic if it is being used, say by an open Maple worksheet.  That isn't an issue on Linux. My usual workflow is to edit the Maple source, rebuild the mla, then click the Restart icon in whatever Maple worksheet I'm using to test the code.

I don't understand what you want.  How about a couple of examples of input and expected output.

@Carl Love I don't believe compiled procedures can be stored in an mla (not sure about that).  An alternative would be to rewrite the internal procedures in C and provide binaries with the Maple distribution (that's done for other stuff), but it's more work for little benefit.  When creating and debugging iterators it is convenient to be able to use compile=false and then step through the iterator in the Maple debugger; that wouldn't be feasible if the internal procedures were in C.  On the other hand, am currently (itermittently) working on a new iterator which could be significantly faster if written directly in C.

@Carl Love Please email me the info; I can add it to the internal bug report (which I haven't yet seen).  There were some changes to add (and seq) for 2021; I don't work on them.

@Ronan As Carl mentioned, using compile=false is a reasonable way to avoid the one-time delay for a small iterator. In Maple 2020 the delayed compilation method used by the Iterator package was modified so that the compilation occurs when an iterator is first generated; previously it occurred the first time an iterator was used (expanded).  So for a particular iterator type (the numerical arguments don't matter) you could assign a throw away version in the startup code. For example
 

Iterator:-CartesianProduct([1,1]):

Now any subsequent usages of a CartesianProduct iterator will not have to recompile.  That works even if they are used in separate threads

1 2 3 4 5 6 7 Last Page 1 of 186