> m:=[1,5,3]:

> p := proc(L)
> local thelist;
> thelist:=eval(L);
> seq( cat(L,thelist[i]), i=1..nops(thelist) );
> end proc:

> p('m');
                                  m1, m5, m3

> p := proc(L::evaln)
> local thelist;
> thelist:=eval(L);
> seq( cat(L,thelist[i]), i=1..nops(thelist) );
> end proc:

> p(m);
                                  m1, m5, m3

Which one you use may vary according to your taste, and possibly to what else you might wish to accomplish inside or outside that procedure.

acer

> m:=[1,5,3]:

> p := proc(L)
> local thelist;
> thelist:=eval(L);
> seq( cat(L,thelist[i]), i=1..nops(thelist) );
> end proc:

> p('m');
                                  m1, m5, m3

> p := proc(L::evaln)
> local thelist;
> thelist:=eval(L);
> seq( cat(L,thelist[i]), i=1..nops(thelist) );
> end proc:

> p(m);
                                  m1, m5, m3

Which one you use may vary according to your taste, and possibly to what else you might wish to accomplish inside or outside that procedure.

acer

I've had a little time to look at the worksheet you uploaded.

At first glance I thought that it might turn out to be a memory leak, with my money being on dsolve(..,numeric) as the most likely cause. But now I'm running it with runs:=100 and watching the OS (Linux & `top`) against the status bar. They stay mostly close (within 85% or so), as far as what they both claim memory allocation to be. And kernelopts(bytesalloc) agrees quite closely with `top`. So that may be out, as a principal culprit.

Sure, using LinearAlgebra instead of linalg might make some savings. But the code uses arrays for storage mostly, rather than for linear algebra computation. So the savings would be relatively small, I think.

The thing to get to the heart of is: why does memory allocation just keep rising and rising with each iteration, in an apparently uncollectible manner?

In an earlier post I mentioned the usual need to place iterating code within procedures (or procedures within procedures) so that garbage collection (gc) of transcient intermediate objects may take place when control rises periodically to a higher level.

Now, on first glance the code looks OK, as far as being generally gc'able. It's got procedures, which themseleves call procedures, to get the work done. And you mentioned that results from one iteration are generally not needed for the next, etc. There are a few globals, for example,

pts_up,pts_down,label_time,delabel_time,label_type,
 constantmu,model,noise,noise_val,dir,saturation

but I don't see any of those being huge across multiple iterations.

There are one or two places where an inefficient mechanism like this is used,

problemseed:=[op(problemseed),i]

but that should produce collectible garbage.

So, if I get a chance I will try to run it under Maple's nprofile tool, to see what is allocating what. I still wonder about dsolve(..,numeric), and whether it might somehow be generating non-collectible "foreign DAG" rtables in its own external-call library. That might be hard to see in nprofile output.

acer

I've had a little time to look at the worksheet you uploaded.

At first glance I thought that it might turn out to be a memory leak, with my money being on dsolve(..,numeric) as the most likely cause. But now I'm running it with runs:=100 and watching the OS (Linux & `top`) against the status bar. They stay mostly close (within 85% or so), as far as what they both claim memory allocation to be. And kernelopts(bytesalloc) agrees quite closely with `top`. So that may be out, as a principal culprit.

Sure, using LinearAlgebra instead of linalg might make some savings. But the code uses arrays for storage mostly, rather than for linear algebra computation. So the savings would be relatively small, I think.

The thing to get to the heart of is: why does memory allocation just keep rising and rising with each iteration, in an apparently uncollectible manner?

In an earlier post I mentioned the usual need to place iterating code within procedures (or procedures within procedures) so that garbage collection (gc) of transcient intermediate objects may take place when control rises periodically to a higher level.

Now, on first glance the code looks OK, as far as being generally gc'able. It's got procedures, which themseleves call procedures, to get the work done. And you mentioned that results from one iteration are generally not needed for the next, etc. There are a few globals, for example,

pts_up,pts_down,label_time,delabel_time,label_type,
 constantmu,model,noise,noise_val,dir,saturation

but I don't see any of those being huge across multiple iterations.

There are one or two places where an inefficient mechanism like this is used,

problemseed:=[op(problemseed),i]

but that should produce collectible garbage.

So, if I get a chance I will try to run it under Maple's nprofile tool, to see what is allocating what. I still wonder about dsolve(..,numeric), and whether it might somehow be generating non-collectible "foreign DAG" rtables in its own external-call library. That might be hard to see in nprofile output.

acer

I would expect that the authors of mapleprimes posts retain all the usual rights (eg. copyrights) of such material published on-line.

Note that "copyright" usually refers to a collection of various rights. The "right to copy" is one of those, and is usually only exclusive to the author in a time-limited way. But some of the other rights are also important, for example the right to being credited for the work, or the right to uphold the work's integrity. And so on. Some of those rights, such as the right to being credited or acknowledged as the author, do not expire under some countries laws (eg. Canada).

Given all that, I don't see how anything except explicit opt-in for such copying would be acceptable.

Personally, I would likely not agree to having my mapleprimes posts copied onto any other site (or wiki) except for whenever I post the copy myself.

acer

I would expect that the authors of mapleprimes posts retain all the usual rights (eg. copyrights) of such material published on-line.

Note that "copyright" usually refers to a collection of various rights. The "right to copy" is one of those, and is usually only exclusive to the author in a time-limited way. But some of the other rights are also important, for example the right to being credited for the work, or the right to uphold the work's integrity. And so on. Some of those rights, such as the right to being credited or acknowledged as the author, do not expire under some countries laws (eg. Canada).

Given all that, I don't see how anything except explicit opt-in for such copying would be acceptable.

Personally, I would likely not agree to having my mapleprimes posts copied onto any other site (or wiki) except for whenever I post the copy myself.

acer

The poster wrote "programmatically". That often means using the Maple programming language rather than the GUI and the mouse.

acer

The poster wrote "programmatically". That often means using the Maple programming language rather than the GUI and the mouse.

acer

I was able to add a new definition to a new .hdb file.

First I created a new Document, and as text input I typed in some short content of just a single line. I then saved that to a writable .hdb of my own, and specified the help "topic" like so,

  Definition,foobar

Then I quit maple, and restarted it entirely with the location of my owb .hdb file in libname.

Then, in a new worksheet, I entered some text. I was able to use the context-menu item Convert To -> Hyperlink to mark a word of that text as a new Dictionary reference. That is, in the Hyperlink properties pop-up I set the Type drop-down to Dictionary Topic. In the Target field I entered,

  Definition, foobar

And then I clicked on the OK button in the Hyperlink properties pop-up window.

At that point, back in my worksheet, hovering over the hyperlinked text word, it showed a tool tip that it was a Dictionary Definition. Most exciting of all, when I clicked on that text word it popped up the usual little yellow dictionary window containing my definition (and not a full help-page).

So that's it. It seems easy. It appears to just rely on making the topic be of the form "Definition,xxxxx". I don't know whether there is some length (or number of document blocks) above which it would automatically switch to full help-page view instead of the small yellow pop-up.

nb. I first tried it with a new personal .hdb file named SDictionary.hdb, since I suspected that it might only work with that filename. But then I tried it also with a personal .hdb named maple.hdb (the default, when maple creates a .hdb for you). And that worked too.

acer

I was able to add a new definition to a new .hdb file.

First I created a new Document, and as text input I typed in some short content of just a single line. I then saved that to a writable .hdb of my own, and specified the help "topic" like so,

  Definition,foobar

Then I quit maple, and restarted it entirely with the location of my owb .hdb file in libname.

Then, in a new worksheet, I entered some text. I was able to use the context-menu item Convert To -> Hyperlink to mark a word of that text as a new Dictionary reference. That is, in the Hyperlink properties pop-up I set the Type drop-down to Dictionary Topic. In the Target field I entered,

  Definition, foobar

And then I clicked on the OK button in the Hyperlink properties pop-up window.

At that point, back in my worksheet, hovering over the hyperlinked text word, it showed a tool tip that it was a Dictionary Definition. Most exciting of all, when I clicked on that text word it popped up the usual little yellow dictionary window containing my definition (and not a full help-page).

So that's it. It seems easy. It appears to just rely on making the topic be of the form "Definition,xxxxx". I don't know whether there is some length (or number of document blocks) above which it would automatically switch to full help-page view instead of the small yellow pop-up.

nb. I first tried it with a new personal .hdb file named SDictionary.hdb, since I suspected that it might only work with that filename. But then I tried it also with a personal .hdb named maple.hdb (the default, when maple creates a .hdb for you). And that worked too.

acer

Is it possible that, in your Mathematica session, the floating-point coefficients in your equation actually have greater known precision than what gets displayed (and thence copied here)?

I ask because the LHS minus the RHS of the translated equation (using FromMma) has a maximum of only around -0.0004138 at around the point 45.065.

Or are you simply talking about the left-hand side of the equation that you posted. You wrote that "it reaches 1". But it is an equation not a function nor an expression. So it's not clear what you are referring to when you write that "it reaches 1".

If you instead meant to convey that the LHS alone gets close to 1, then sure that is true near 0. And for the limited precision coefficients posted it seems to occur at about +/-0.11e-7 which was the meaning of my original reply.

I would phrase it that the LHS of the equation attains a value of 1 (ie. the RHS) at any point which satisfies the equation. Equations themselves don't attain values, although their left- and right-hand-sides do.

But near t=45 the LHS of the posted equation does not quite attain a value of 1, I think. It only gets close, up to about 1.0 - 0.0004138 which is about 0.999586.

Or perhaps the FromMma translator is producing quite a different equation in Maple syntax. But it doesn't look like it to me.

Perhaps someone else will give a second opinion.

If you actually have some exact representation of the general formula, as opposed to a floating-point approximation, then that might be better analyzed and help clear up any questions about the precision to which the coefficient data is known.

acer

Is it possible that, in your Mathematica session, the floating-point coefficients in your equation actually have greater known precision than what gets displayed (and thence copied here)?

I ask because the LHS minus the RHS of the translated equation (using FromMma) has a maximum of only around -0.0004138 at around the point 45.065.

Or are you simply talking about the left-hand side of the equation that you posted. You wrote that "it reaches 1". But it is an equation not a function nor an expression. So it's not clear what you are referring to when you write that "it reaches 1".

If you instead meant to convey that the LHS alone gets close to 1, then sure that is true near 0. And for the limited precision coefficients posted it seems to occur at about +/-0.11e-7 which was the meaning of my original reply.

I would phrase it that the LHS of the equation attains a value of 1 (ie. the RHS) at any point which satisfies the equation. Equations themselves don't attain values, although their left- and right-hand-sides do.

But near t=45 the LHS of the posted equation does not quite attain a value of 1, I think. It only gets close, up to about 1.0 - 0.0004138 which is about 0.999586.

Or perhaps the FromMma translator is producing quite a different equation in Maple syntax. But it doesn't look like it to me.

Perhaps someone else will give a second opinion.

If you actually have some exact representation of the general formula, as opposed to a floating-point approximation, then that might be better analyzed and help clear up any questions about the precision to which the coefficient data is known.

acer

This is an interesting question. Can one add a new "maple-help-style" definition to Maple? I  don't (yet) know the answer. I don't think that it's obvious, either way.

Presumably they live in .hdb databases just like help-pages. It's reasonable to guess that the definitions are stored in lib/SDictionary.hdb and lib/classic/CDictionary.hdb.

It's reasonable to ask whether new definitions can be stored to new (user-created) .hdb files just like new .mw worksheet based help-pages can be added. (The issue that one cannot add to the read-only system .hdb files seems irrelevant to this question.)

Some definitions are very short and appear as tool tip (bubble-help) on mouse hover-over, when referenced in a worksheet. Some longer definitions appear as their own help-pages. Maybe creating new longer help-page definitions entails merely using the right form for the topic (eg. Definition,foobar). Maybe the short tool tip definitions are done the same way, if you're lucky, and the mechanism works simply according to definition length. Or maybe shorter tool tip definitions cannot be added.

acer

This is an interesting question. Can one add a new "maple-help-style" definition to Maple? I  don't (yet) know the answer. I don't think that it's obvious, either way.

Presumably they live in .hdb databases just like help-pages. It's reasonable to guess that the definitions are stored in lib/SDictionary.hdb and lib/classic/CDictionary.hdb.

It's reasonable to ask whether new definitions can be stored to new (user-created) .hdb files just like new .mw worksheet based help-pages can be added. (The issue that one cannot add to the read-only system .hdb files seems irrelevant to this question.)

Some definitions are very short and appear as tool tip (bubble-help) on mouse hover-over, when referenced in a worksheet. Some longer definitions appear as their own help-pages. Maybe creating new longer help-page definitions entails merely using the right form for the topic (eg. Definition,foobar). Maybe the short tool tip definitions are done the same way, if you're lucky, and the mechanism works simply according to definition length. Or maybe shorter tool tip definitions cannot be added.

acer

Neither the "Save as Help Page" top-menu item not the routine makehelp() are as powerful and flexible as the INTERFACE_HELP command.

If one has many .mw files to convert, then point & click tools are about as unproductive as it gets.

Several nice options for INTERFACE_HELP, such as whether to make the page "active" or to include text content directly, are apparently not available in the other mechanisms, "Save as Help Page" or makehelp.

The help and instructions for INTERFACE_HELP are (no big surprise) available in the help-system under the topic INTERFACE_HELP. In stark contrast to that, the top menu's "Save as Help Page" item produces a "Save To Database" pop-up window with no embedded help button. It's help is located only under the main help system and not as an accompanying pop-up, under the more obscure topic "worksheet,reference,addhelp". That topic is harder to locate if you don't already know that it exists and where it lives.

It would be better if all these tools clearly indicated that a writable directory can be used as the first item in libname (so that the system can create a new maple.hdb database there). As things currently are, the pop-up window alone for the menu item "Save as Help Page" gives no hint that this is possible, nor does it give any hint to the help-page which mentions it.

acer