The original data was exact, so it would not be appropriate if Maple were automatically to convert the data to floating-point and then give a corresponding floating-point result (which is what those super fast methods above do).

acer

That paragraph is in the section covering the zip() function. It's not surprising that sqrt() may not be one of the affected routines. The zip() routine "zips" an action across two parameters, while sqrt() takes the square root of a single parameter.

About the only way I can see to even make zip(sqrt,A,B) valid is for B to be merely an option such as 'symbolic'. But that wouldn't be particularly apt here and would likely not help much in the hardware datatype rtable case, which is also central (but left out, above) to that quoted paragraph covering zip's enhancements..

acer

That paragraph is in the section covering the zip() function. It's not surprising that sqrt() may not be one of the affected routines. The zip() routine "zips" an action across two parameters, while sqrt() takes the square root of a single parameter.

About the only way I can see to even make zip(sqrt,A,B) valid is for B to be merely an option such as 'symbolic'. But that wouldn't be particularly apt here and would likely not help much in the hardware datatype rtable case, which is also central (but left out, above) to that quoted paragraph covering zip's enhancements..

acer

Well.. most of the posted answers were reasonably efficient, in terms of computation time and use of memory resources. One can also get almost identical performance (on this example task) with,

p := (L::uneval) -> seq(cat(L,x),x in eval(L));

The main reason that I posted a procedure (not just entered as an arrow operator) was, as I mentioned, that I didn't know what else you might want to inject in and around the concatenating bit. Judging by your earlier tries, it seemed that I should focus on the bit that did the trick -- the evaln|uneval|quoted-args. It's a bit of a sliding scale, between the map2 solution, through the above code, and on to this next below, and then the others posted.

p := proc(L::uneval)
  seq(cat(L,x),x in eval(L));
end proc:

I would agree, that it's usually a good idea to check the relative performance of candidate implementations, especially if it's for something that you intend on using a great deal at some low level. Sometimes that, and other issues like which methods are more easily debugged, etc, can end up making more difference on once-coded stuff than does compactness of the code representation.

acer

Well.. most of the posted answers were reasonably efficient, in terms of computation time and use of memory resources. One can also get almost identical performance (on this example task) with,

p := (L::uneval) -> seq(cat(L,x),x in eval(L));

The main reason that I posted a procedure (not just entered as an arrow operator) was, as I mentioned, that I didn't know what else you might want to inject in and around the concatenating bit. Judging by your earlier tries, it seemed that I should focus on the bit that did the trick -- the evaln|uneval|quoted-args. It's a bit of a sliding scale, between the map2 solution, through the above code, and on to this next below, and then the others posted.

p := proc(L::uneval)
  seq(cat(L,x),x in eval(L));
end proc:

I would agree, that it's usually a good idea to check the relative performance of candidate implementations, especially if it's for something that you intend on using a great deal at some low level. Sometimes that, and other issues like which methods are more easily debugged, etc, can end up making more difference on once-coded stuff than does compactness of the code representation.

acer

The question was also asked on comp.soft-sys.math.maple , and Robert Israel gave a (more specialized) answer there on the following day.

acer

(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

(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