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

@Adri van der Meer Sorry, perhaps I didn't notice that V was constructed by reading along columns of M. So naturally you would want to reconstruct it by laying down entries from Vector V in the same way.

Is this a fix-up, to lay down the Matrix, columnwise, from given Vector V with that interpretation?

Gr:=(m,n,W) -> Matrix(m,n,
                     (i,j)->`if`(i>j, 0,
                                 W[((j-1)*(j)/2)-`if`(j>m,
                                                     (j-m-1)*(j-m)/2, 0)+i])):

I would guess that a do-loop could be faster than such an indexing function due to the hit from calling `if`(i>j,...) on all entries (because with nested loops the upper value for the inner loop's index can be a function of the outer loop's index). And indeed, your procedure performs faster.

@Adri van der Meer Sorry, perhaps I didn't notice that V was constructed by reading along columns of M. So naturally you would want to reconstruct it by laying down entries from Vector V in the same way.

Is this a fix-up, to lay down the Matrix, columnwise, from given Vector V with that interpretation?

Gr:=(m,n,W) -> Matrix(m,n,
                     (i,j)->`if`(i>j, 0,
                                 W[((j-1)*(j)/2)-`if`(j>m,
                                                     (j-m-1)*(j-m)/2, 0)+i])):

I would guess that a do-loop could be faster than such an indexing function due to the hit from calling `if`(i>j,...) on all entries (because with nested loops the upper value for the inner loop's index can be a function of the outer loop's index). And indeed, your procedure performs faster.