(I had to edit this, to correct it)

This works for me, in 2D Math input mode, in Maple 12,

H := x -> `if`( type(x,even), print("Even"), print("Odd") );

There was a missing end bracket in the other example just above (the one using lhs).

acer

This sounds like it could be a java problem. Did you write that you are using OSX? Isn't that the one platform where Maple's Standard GUI will use the installed system JRE rather than one which is bundled with Maple itself? Which JRE do you have installed as the default for use by applications? I suggest emailing support@maplesoft.com with the details (including OS version and installed default Java version).

acer

This sounds like it could be a java problem. Did you write that you are using OSX? Isn't that the one platform where Maple's Standard GUI will use the installed system JRE rather than one which is bundled with Maple itself? Which JRE do you have installed as the default for use by applications? I suggest emailing support@maplesoft.com with the details (including OS version and installed default Java version).

acer

The more usual (and correct, and documented) syntax for that is like this,

  interface(rtablesize=11);

The fact that what you showed works appears to be a bit of a fluke, likely due to assignment to interface's remember table and the internal display mechanism being OK with that.

> interface(verboseproc,rtablesize);
                                     1, 10
 
> interface(rtablesize):=13;
                          interface(rtablesize) := 13
 
> interface(verboseproc,rtablesize);
                                     1, 10
 
> interface(rtablesize=13);
                                      10
 
> interface(verboseproc,rtablesize);
                                     1, 13

acer

The more usual (and correct, and documented) syntax for that is like this,

  interface(rtablesize=11);

The fact that what you showed works appears to be a bit of a fluke, likely due to assignment to interface's remember table and the internal display mechanism being OK with that.

> interface(verboseproc,rtablesize);
                                     1, 10
 
> interface(rtablesize):=13;
                          interface(rtablesize) := 13
 
> interface(verboseproc,rtablesize);
                                     1, 10
 
> interface(rtablesize=13);
                                      10
 
> interface(verboseproc,rtablesize);
                                     1, 13

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

> 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