pagan

5147 Reputation

23 Badges

17 years, 124 days

 

 

"A map that tried to pin down a sheep trail was just credible,

 but it was an optimistic map that tried to fix a the path made by the wind,

 or a path made across the grass by the shadow of flying birds."

                                                                 - _A Walk through H_, Peter Greenaway

 

MaplePrimes Activity


These are answers submitted by pagan

It may be that some people would not "pursue a Martingale betting strategy", unless that allows for a specified exit strategy.

If by "pursue" you mean that you have to run the course until either you win or you run out of funds, then the risk may be unacceptable to some. So, an alternate question you might ask is, "How little a bankroll would you be willing to use in an M strategy, in the absence of any allowed early-quit cutoff?"

Another question you could consider is, "How much would you need to win in order to exit a repetitive M strategy?" Suppose that you start with bankroll X and you win a very small amount. Are you then done for the day, or is that insufficient to satisfy you? If it is insufficient, then would you not simply start over again? If you are prepared to start over again and again, indefinitely, then eventually you will lose all of X. So, if you intend to repeat the gamble then an exit strategy might be wanted for that too, perhaps based on total winnings.

You could try searching this site for "abstract linear algebra" and reading through the matched message threads.

I suspect that doing so would show that there is, as yet, no facility for doing such general manipulations (even if a particular equation involving noncommutative multiplication, for example, could be handled by some set of commands).

 

Are you trying for this result?

> expr:=-(1/12)*(-g*vb-g+z*g-g^(2/3)*z+g^(2/3)*vb)*(g^(1/3)+1)^5/g^(2/3);
                                                                 5
            /                   (2/3)      (2/3)   \ / (1/3)    \ 
            \-g vb - g + z g - g      z + g      vb/ \g      + 1/ 
          - ------------------------------------------------------
                                      (2/3)                       
                                  12 g                            


> op(1,expr)*op(3,expr)*collect(op(2,expr)*op(4,expr),g);
                              5                                
               1  / (1/3)    \  /               (1/3)         \
             - -- \g      + 1/  \(-vb - 1 + z) g      + vb - z/
               12                                              

Find the general term for any point on that curve. If the x coordinate of such a general point on the curve is x, then what is the y coordinate? The y coordinate is some function of x. You've already typed it here.

Once you have the general point, find the distance from that to your given point (0,1). You should know a formula for distance between two points. Once that's done, you should have a general expression (formula) for the distance between your given point and any point on the curve. That expresssion should have only the unknown x in it, and no y.

You are trying to find the closest point on the curve, so you should be trying to minimize the distance from a point on the curve to your given point. You've worked out the expression for the distance, as a funtion of x. What have you learned about finding the minimum of a function of x?

Speed shouldn't be yout only performance concern. Memory allocation also matters, because it's a finite resource. If your algorithm consumes memory at a rate that grows like the square of the problem size then it's going to scale much less well than an algorithm whose memory allocation grows only linearly with problem size. The largest problem that the former can handle will usually be much smaller than the largest that the latter can handle.

You could try the code below, replacing 2000 (the length of `a`) with other values. Look at how much extra memory gets used. You could even plot it, for both methods.

> restart:
> a:=[seq(4*i+1,i=1..2000)]:
> t,ba:=time(),kernelopts(bytesalloc):
> for i to nops(a) do
>    a:=subsop(i = `mod`(Power(a[i],43214342341),5423524532),a):
> od:
> a:time()-t,kernelopts(bytesalloc)-ba;
                               0.717, 14284232

> restart:
> a:=[seq(4*i+1,i=1..2000)]:
> t,ba:=time(),kernelopts(bytesalloc):
> map(i->Power(i,43214342341) mod 5423524532,a):
> time()-t,kernelopts(bytesalloc)-ba;
                                0.078, 786288

For lots of algorithmic implementations in Maple, the amount of memory use affects the timing, since eventually some memory will need to get garbage collected and recycled. That takes time. So an implementation that produces more garbage will also take an extra timing hit. This can affect what standard measurement (`metric`) is is taken to represent performance. I recall when this formula for performance (in Maple) got mention,

 (elapsed time) * (memory allocation)^2

Always compare performance after restart (which you had -- great).

> restart:
> assume(f, RealRange(Open(0),infinity)):

> coulditbe(f,'imaginary');
                                     FAIL
Why isn't the last one `false`?

You should be able to use unapply to get what you've described, the programmatic construction of the operator.

> f:=(x1,x2,x3)->x1;
                            f := (x1, x2, x3) -> x1
 
> g:=unapply(x1,[x1,x2,x3]);
                            g := (x1, x2, x3) -> x1
 
> g(1,2,3);
                                       1
 
> f(x3,x2,x1)-g(x3,x2,x1);
                                       0
 
> g2:=unapply(x1,[seq(cat(x,i),i=1..3)]);
                           g2 := (x1, x2, x3) -> x1
 
> g2(1,2,3);
                                       1
 
> f(x3,x2,x1)-g2(x3,x2,x1);
                                       0

> expr := x1+x2+sin(x3);
                           expr := x1 + x2 + sin(x3)
 
> indets(expr,name) minus {constants};
                                 {x1, x2, x3}
 
> g3 := unapply(x1,[op(indets(expr,name) minus {constants})]);
                           g3 := (x1, x2, x3) -> x1
 
> g3(1,2,3);
                                       1
 
> f(x3,x2,x1)-g3(x3,x2,x1);
                                       0

 

The earlier response involved an unspecified RootOf. An unspecified RootOf can refer to more than a single root.

On the other hand, an indexed RootOf represents a specific root. So allvalues applied to such will return just the original single root. Of course, if your expr is a polynomial of degree greater than 5 then RootOf(expr,index=n) might not have an explicit form.

As the last paragraph in the Description section of ?RootOf mentions, you can try convert(RootOf(...),radical) if you are trying to get an explicit form in terms of radicals. For example,

> ee:=RootOf(x^3-x-1,index=2);
                                    3
                     ee := RootOf(_Z  - _Z - 1, index = 2)

> allvalues(ee);
              1/2 1/3
  (108 + 12 69   )                1
- ------------------- - ---------------------
          12                        1/2 (1/3)
                        (108 + 12 69   )

                  /            1/2 1/3                      \
              1/2 |(108 + 12 69   )               2         |
     + 1/2 I 3    |------------------- - -------------------|
                  |         6                        1/2 1/3|
                  \                      (108 + 12 69   )   /

> convert(ee,radical);
              1/2 1/3
  (108 + 12 69   )                1
- ------------------- - ---------------------
          12                        1/2 (1/3)
                        (108 + 12 69   )

                  /            1/2 1/3                      \
              1/2 |(108 + 12 69   )               2         |
     + 1/2 I 3    |------------------- - -------------------|
                  |         6                        1/2 1/3|
                  \                      (108 + 12 69   )   /

You can also try solve(op(1,Rootof(...)),Explicit), although that may return all roots (and the indexed RootOf refers to just one of those, by the index value).

If d is does not have a numeric value, then that RootOf cannot be computed as a floating-point result when evalf is applied.

To get explicit solutions of this RootOf (of a quadratic in _Z), apply the command allvalues to the RootOf.

From the last bullet point in the Description section of the ?RootOf help page:

- If r is a RootOf of a polynomial, the allvalues command returns a sequence
  of formulae (in terms of radicals) for the roots. The convert,radical
   command returns a formula for the root selected (the principal root if none
  is selected).

Notice first that your original code repeat the operation convert(a,base,10) for each value of the i  loop. That's not necessary. You could create the list of digits just once before the loop and assign to a local variable. On the other hand, you don't need a loop just to add the digits in a list.

For a recursive procedure, you could do it something like this,

> addList:=proc(a)
> local s;
>   s:=convert(convert(a,base,10),`+`);
>   if length(s)>1 then
>     procname(s);
>   else
>     s;
>   end if;
> end proc:
By the way, what happens if you just compute your first input number mod 9?

Yes, the code that you posted does that task. (Did it not work for you?)

> gradV:=Matrix([[a11*x1+a12*x2],[a21*x1+a22*x2]]);
                                   [a11 x1 + a12 x2]
                          gradV := [               ]
                                   [a21 x1 + a22 x2]
 
> a11:=1;
                                   a11 := 1
 
> a12:=0;
                                   a12 := 0
 
> a21:=0;
                                   a21 := 0
 
> a22:=1;
                                   a22 := 1
 
> gradV;
                                     [x1]
                                     [  ]
                                     [x2]

FYI, the command evalm was for lowercase matrix ( which was of type ?last_name_eval ), but capitalized Matrix does not require evalm (since it is not of that type).

Expression sequences get flattened when passed as arguments in a procedure call. The round-bracket delimiters don't help with that. So enclosure of arguments (intended to be passed as a group) can be attained by placing them into a data structure. Round-brackets act only as delimiters in order to control precedence, and not as a structure constructor. But square brackets act as the list constructor. See the ?syntax help page.

In other words, if grouped arguments don't get passed in some structure (such as a list) then it is not easy to pick them off inside the procedure as being the grouped value of some specific parameter.

There is as exception (as there usually is) to this. The new parameter-processing facility allows expression sequences to get passed to a specific parameter, using its seq modifer. An example is below. Notice that the special parameter which is modified to take the expression sequence as its value will scoop up all arguments (of matching type) to the left. This limits the functionality, since further parameters of the same matching type cannot get passed to other parameters (further left). Some examples,

> p := proc(x,y,z)
>   print(y); print(z);
> end proc:
> p(1,(2,3,4,5),7);
                                       2

                                       3

> p := proc(x,y::seq(integer),z::integer)
>   print(y); print(z);
> end proc:
> p(1,2,3,4,5,7);
                                 2, 3, 4, 5, 7

Error, invalid input: p uses a 3rd argument, z (of type
integer), which is missing

As you can see, it becomes problematic when the seq parameter is not the very last parameter at the left. Also, the seq modifier cannot be used for a keyword parameter of the "new" parameter-processing. The color=[..] option of plot is a keyword parameter (even though plot may not be using the "new" parameter-processing mechanisms.) Hence it would be difficult (or maybe impossible) to code up a procedure to accept an expression sequence for a keyword parameter that is supposed to be able to occur at any location in the passed arguments.

plot({[2-3*sin(t), t, t = 0..2*Pi], [2-3*cos(t), t, t = 0..2*Pi]},
scaling = constrained, coords = polar, color=[black,gold]);
> restart:
> f := x*sin(x^2)+1:
> df := diff( f, x ):

> Student:-Calculus1:-Roots(df,x=-1..3,numeric);
                  [0., 1.355211129, 2.194502750, 2.813725766]

BTW, I advise you not to define "functions" using the notation such as

  f(x):=....

even though 2D Math supports it. In 1D Maple notation that syntax does something else, and you may end up confused by the difference in behaviour. I suggest either forming an expression (as Doug showed) or an operator (procedure) and to learn the difference between them. These should work the same in both 2D and 1D input modes.

> restart:
> f := x*sin(x^2)+1; # expression
                                          2
                              f := x sin(x ) + 1

> df := diff( f, x ); # expression
                                    2       2      2
                         df := sin(x ) + 2 x  cos(x )

> eval(df,x=t); # evaluation at a value
                                 2       2      2
                            sin(t ) + 2 t  cos(t )

> f := x -> x*sin(x^2)+1; # operator
                                             2
                            f := x -> x sin(x ) + 1

> df := D(f); # operator
                                       2       2      2
                       df := x -> sin(x ) + 2 x  cos(x )

> df(t); # application at a value
                                 2       2      2
                            sin(t ) + 2 t  cos(t )

Maple 11.01 was the first point-release to officially be supported for Windows Vista. Support has continued for versions Maple 12 and 13.

First 40 41 42 43 44 45 46 Page 42 of 48