@bernie The question -- which I thought might make it easier for responders -- is whether the dummy in that M(r) is the same dummy of integration (by ApproximateInt, which I suspect) or of the outer dsolve/numeric.

It seems from earlier responses that you need better speed on this, is that right? Perhaps it could be rewritten as an expanded DE system so that dsolve/numeric handled the integration. That might be able to give the best accuracy and speed combination.

Maybe good to keep in mind that there is little point in requesting better accuracy from the integrator (be it ApproximateInt or evalf/Int or dsolve/numeric itself) than can be obtained from the given accuracy in the computed approximate dsolve/numeric results.

I'd like to look into this example, but I'm afraid that my spare time is limited these days.

This looks like another recasting of your questions posted on Oct 30 and Nov 19 and (in its followups) of April 17?

Why are you using ApproximateInt?

I find the use of `r` unnecessarily confusing, and somewhat dubious. Consider this snippet of the code,

vrad(x)=(1+r)^(-1/2)*ApproximateInt((1+r)^(1/2)*M(r)/r^2,r=x..10^(20),
                                     output=sum,partition=50):

Why use `r` as the variable of integration (for the quadrature, in ApproximateInt), when it's also being used in the higher scope (eventually, as variable of integration in dsolve/numeric)? Which `r` is it supposed to be, in the M(r) in that fragment?

acer

I don't see how the methodology of the SSP code is suitable for the described task. The SSP routine returns just a single way of attaining 150 with 3 shots, and a single way with 5 shots, and with 4 shots, etc (there is no solution for doing it in 1 shot or two shots, for the given data).

But the SSP routine doesn't look for all 4-shot solutions, say.

Also, the description mentions using 4 darts only. But your usage of the code seems to indicate that you want 5-shot solutions as well?!

I would guess that some other approach would be more suitable to what you've described as the goal. Perhaps a routine which generates all possibilities of 4 shots and then sieves them would be simplest. Or (slightly more involved) a routine similar to that but which abandons any sequence as soon as it is determined to be a guaranteed failure, or one which adjusts its pool of candidates on the basis of its running sum.

acer

For uniform distributions I find that it is easier and faster to use the RandomMatrix and RandomVector commands from the LinearAlgebra package. Their `generator` option is useful.

For other distributions I find that Statistics:-Sample with a RandomVariable or Distribution is fast and easier to understand than RandomTools. But that's just me.

I quite rarely turn to the RandomTools package (an exception being for list creation with random entries). The `makeproc` command does as it suggests and produces a procedure that can emit values. That's why it works in your example of using it with `Matrix`, since that command accepts an initializer (initializing procedure). There is no "list" constructor per se, unless you consider `seq` as being the sequence constructor. (You could do much worse than think of a list as a pair of square brackets around a sequence. The `[]` turns a sequence into a list (at low cost), just as `op` turns a list into a sequence (also cheaply).)

> f:=RandomTools:-Generate(integer(range=1..100),makeproc=true):

> [seq(f(), i=1..5)];

                              [93, 45, 96, 6, 98]

> Vector[row](5, f);

                             [59, 44, 100, 38, 69]

> L := [seq(f(), i=1..5)];

                           L := [1, 70, 77, 39, 92]

> s := op(L);  
           
                            s := 1, 70, 77, 39, 92

> `[]`(s);  
              
                              [1, 70, 77, 39, 92]

> evalb(% = L); # that last list is the very same object as L (lists are immutable)

                                     true


> with(LinearAlgebra):

> RandomVector[row](5,generator=1..100);  # only provides for uniform distr.

                             [57, 72, 73, 92, 27]

> RandomVector[row](5,generator=1.0..100.0);

       [79.4285256263958814, 91.6578169937176455, 42.7543669800012225,
        15.0467475240943180, 80.2277664199912124]

acer

What I'm trying to show about the endpoints is that the piecewise could exclude both (and use symbol=circle) from the support, or include both (and use symbol=solidcircle).

Download uniform2.mw

acer

What I'm trying to show about the endpoints is that the piecewise could exclude both (and use symbol=circle) from the support, or include both (and use symbol=solidcircle).

Download uniform2.mw

acer

Over the years, we have seen the ``() operator get used many times to suppress automatic simplification. Sure, it has its shortcomings: often it needs to be applied in several places throughout the input, and displaying its unevaluated function calls shows with round brackets around its arguments.

It's a bit of a strange beast, this ``() operator. Could it be given a print-slash extension, as a way to get around those round brackets?

In other words, can it be used to get an effect like this, without the extra bracketing,

Download namefun0.mw

acer

Over the years, we have seen the ``() operator get used many times to suppress automatic simplification. Sure, it has its shortcomings: often it needs to be applied in several places throughout the input, and displaying its unevaluated function calls shows with round brackets around its arguments.

It's a bit of a strange beast, this ``() operator. Could it be given a print-slash extension, as a way to get around those round brackets?

In other words, can it be used to get an effect like this, without the extra bracketing,

Download namefun0.mw

acer

@Alejandro Jakubi Yes, indeed. And that flexible procedure can also be applied to manipulate just the sign (or not).

restart:

dividend:=proc(ex,f:=numer(ex),t:=[expand,expand])
local n,d;
n:=t[1](numer(ex)/f):
d:=t[2](denom(ex)/f);
n/d;
end proc:

s:=-(x+y)/(x+y-1);

                              x + y  
                          - ---------
                            x + y - 1

dividend(s,sign(numer(s)),
         [u->u,u->`if`(sign(u)=-1,sort(u,[x,y],ascending),u)]);

                             x + y  
                           ---------
                           1 - y - x

s:=(x+y)/(x+y-1);

                             x + y  
                           ---------
                           x + y - 1

dividend(s,sign(numer(s)),
        [u->u,u->`if`(sign(u)=-1,sort(u,[x,y],ascending),u)]);

                             x + y  
                           ---------
                           x + y - 1

s:=-x/(x-1);

                                x  
                            - -----
                              x - 1

dividend(s,sign(numer(s)),
         [u->u,u->`if`(sign(u)=-1,sort(u,[x,y],ascending),u)]);

                               x  
                             -----
                             1 - x

s:=x/(x-1);

                               x  
                             -----
                             x - 1

dividend(s,sign(numer(s)),
         [u->u,u->`if`(sign(u)=-1,sort(u,[x,y],ascending),u)]);

                               x  
                             -----
                             x - 1

I find the above sign adjustments somewhat pleasing, collectively -- it leaves it alone or not. And the very same command can work for each case. And I'm sure that there are other (different, better, etc) uses of that `dividend` procedure.

@Alejandro Jakubi Yes, indeed. And that flexible procedure can also be applied to manipulate just the sign (or not).

restart:

dividend:=proc(ex,f:=numer(ex),t:=[expand,expand])
local n,d;
n:=t[1](numer(ex)/f):
d:=t[2](denom(ex)/f);
n/d;
end proc:

s:=-(x+y)/(x+y-1);

                              x + y  
                          - ---------
                            x + y - 1

dividend(s,sign(numer(s)),
         [u->u,u->`if`(sign(u)=-1,sort(u,[x,y],ascending),u)]);

                             x + y  
                           ---------
                           1 - y - x

s:=(x+y)/(x+y-1);

                             x + y  
                           ---------
                           x + y - 1

dividend(s,sign(numer(s)),
        [u->u,u->`if`(sign(u)=-1,sort(u,[x,y],ascending),u)]);

                             x + y  
                           ---------
                           x + y - 1

s:=-x/(x-1);

                                x  
                            - -----
                              x - 1

dividend(s,sign(numer(s)),
         [u->u,u->`if`(sign(u)=-1,sort(u,[x,y],ascending),u)]);

                               x  
                             -----
                             1 - x

s:=x/(x-1);

                               x  
                             -----
                             x - 1

dividend(s,sign(numer(s)),
         [u->u,u->`if`(sign(u)=-1,sort(u,[x,y],ascending),u)]);

                               x  
                             -----
                             x - 1

I find the above sign adjustments somewhat pleasing, collectively -- it leaves it alone or not. And the very same command can work for each case. And I'm sure that there are other (different, better, etc) uses of that `dividend` procedure.

@Doug Meade With 2D Math input an operator can be created and assigned using the syntax q(t):=...

In 2D Math mode, by default that causes a disambiguation popup menu to appear, offering the choice to parse as either function definition or remember-table assignment. The default behaviour can even be controlled as a typesetting option. See `functionassign` option on this help-page.

I think that it is wrong behaviour that upon choice of "function assignment" the GUI does not replace such input with q:=t->... and in so doing make the input unambiguous and also valid for 1D.

If I may mention one more variant,

restart:

A:=Matrix([[1,2],[2,3]]):
B:=Vector([x1,x2]):
C:=Vector([c1,c2]):

Equate( A.B+C, Vector([0,0]) );

           [x1 + 2 x2 + c1 = 0, 2 x1 + 3 x2 + c2 = 0]

acer

If I may mention one more variant,

restart:

A:=Matrix([[1,2],[2,3]]):
B:=Vector([x1,x2]):
C:=Vector([c1,c2]):

Equate( A.B+C, Vector([0,0]) );

           [x1 + 2 x2 + c1 = 0, 2 x1 + 3 x2 + c2 = 0]

acer

It might be of interest to you that Maple 16's garbage collector can return collected memory to the OS. In Maple 15 and earlier, that would only happen upon restart. In other words, in Maple 16 kernelopts(bytesalloc) can decrease, without restart.

The garbage collector in Maple 16 is new. It needs a few tweaks, but overall it seems like a Good Thing. For example, there is a measurable speedup between M15 and M16 on some of those comparative performance tests that you recently posted about, and I believe that the new memory management system is due part credit. Those tests do things like floating-point linear algebra on Matrices up to size 2000, iterated several times, all in the same session.

acer

It might be of interest to you that Maple 16's garbage collector can return collected memory to the OS. In Maple 15 and earlier, that would only happen upon restart. In other words, in Maple 16 kernelopts(bytesalloc) can decrease, without restart.

The garbage collector in Maple 16 is new. It needs a few tweaks, but overall it seems like a Good Thing. For example, there is a measurable speedup between M15 and M16 on some of those comparative performance tests that you recently posted about, and I believe that the new memory management system is due part credit. Those tests do things like floating-point linear algebra on Matrices up to size 2000, iterated several times, all in the same session.

acer