pagan

5142 Reputation

23 Badges

16 years, 318 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 replies submitted by pagan

@hirnyk Well, there is still the issue of the order of terms in the expression (w.r.t power of beta).

I deliberately did not bother to add the terms in order of descending powers of beta. It's easy to make it do that. But the point is that orders of terms in a sum (SUM dag) depends on what's been been put in Maple's `simpl` table. If the ascending sum of powers of beta has been previously simpl'd in the same session then (due to uniquification) there's no point in trying to use `add` on its own to assemble a descending sum of terms. Trying that would result in the ascending sum, all the same. And vice-versa.

So, as you showed in your Answer, `sort` is a useful way to get the terms ordered.

restart:

add(a(3-i)*beta^(3-i),i=0..3);
                    3            2                   
           a(3) beta  + a(2) beta  + a(1) beta + a(0)

sort(%,beta,ascending);
                                       2            3
           a(0) + a(1) beta + a(2) beta  + a(3) beta 

add(a(3-i)*beta^(3-i),i=0..3); # compare with first!
                                       2            3
           a(0) + a(1) beta + a(2) beta  + a(3) beta 

restart:

add(a(i)*beta^i,i=0..3);
                                       2            3
           a(0) + a(1) beta + a(2) beta  + a(3) beta 

sort(%,beta,descending);
                    3            2                   
           a(3) beta  + a(2) beta  + a(1) beta + a(0)

add(a(i)*beta^i,i=0..3); # compare, again!
                    3            2                   
           a(3) beta  + a(2) beta  + a(1) beta + a(0)

So any forced ordering could be done, using `sort`, as a last step in `factorcoeffs` or on its returned result.

@hirnyk It looks like you made a typo, and meant to refer to the original question's content as having 3*beta^2*(1-w) instead of 3*beta^2*(1-beta) as you have it in your comment above.

 

The code I showed can be adjusted for the aesthetic requirement that terms in the sum each have a form with multiplicands ordered like 3*beta^2*(1-w) rather than 3*(1-w)*beta^2, without too much difficulty.

 

restart:

expr:=-3*w*beta^2+12*w-16*beta+4+3*beta^2;
                    2                              2
           -3 w beta  + 12 w - 16 beta + 4 + 3 beta 

collect(expr,beta);
                            2                     
             (-3 w + 3) beta  - 16 beta + 12 w + 4

factorsum:=proc(ee::`+`,
                {method::identical(none,ampersand,name):=none},
                {dummy::algebraic:=1})
  local z,s,t;
  z:=op(ee);
  t:=gcd(z);
  if method='ampersand' then
    (t)&*add(s/t,s in z);
  elif method=name then
    ``(t)*add(s/t,s in z);
  else
    t*dummy*(add(s/t,s in z));
  end if;
end proc:

`value/&*`:=proc() `*`(args) end proc: # part of Preben A.'s idea

factorcoeffs:=proc(G,x,{method::identical(none,ampersand,name):=none})
  local L,locdummy;
  uses PolynomialTools;
  L:=CoefficientList(G,x);
  eval(`if`(type(L[1],`+`),
            factorsum(L[1],':-method'=method,':-dummy'=locdummy),
            L[1]),locdummy=1)
  +add(`if`(type(L[i],`+`),
            factorsum(L[i],':-method'=none,':-dummy'=x^(i-1)),
            L[i]*x^(i-1)),i=2..nops(L));
end proc:

factorcoeffs(expr,beta);
                                         2        
              12 w + 4 - 16 beta + 3 beta  (1 - w)

factorcoeffs(expr,beta,method=ampersand);
                                            2        
           4 &* (1 + 3 w) - 16 beta + 3 beta  (1 - w)

value(%);
                                         2        
              12 w + 4 - 16 beta + 3 beta  (1 - w)

factorcoeffs(expr,beta,method=name);
                                           2        
           (4) (1 + 3 w) - 16 beta + 3 beta  (1 - w)

expand(%);
                    2                              2
           -3 w beta  + 12 w - 16 beta + 4 + 3 beta 

 

Also, the factoring step could use something other than `gcd`. That sort of consideration is, I think, minor relative to the issue of handling (any, or the) automatic expansion.

@hirnyk It looks like you made a typo, and meant to refer to the original question's content as having 3*beta^2*(1-w) instead of 3*beta^2*(1-beta) as you have it in your comment above.

 

The code I showed can be adjusted for the aesthetic requirement that terms in the sum each have a form with multiplicands ordered like 3*beta^2*(1-w) rather than 3*(1-w)*beta^2, without too much difficulty.

 

restart:

expr:=-3*w*beta^2+12*w-16*beta+4+3*beta^2;
                    2                              2
           -3 w beta  + 12 w - 16 beta + 4 + 3 beta 

collect(expr,beta);
                            2                     
             (-3 w + 3) beta  - 16 beta + 12 w + 4

factorsum:=proc(ee::`+`,
                {method::identical(none,ampersand,name):=none},
                {dummy::algebraic:=1})
  local z,s,t;
  z:=op(ee);
  t:=gcd(z);
  if method='ampersand' then
    (t)&*add(s/t,s in z);
  elif method=name then
    ``(t)*add(s/t,s in z);
  else
    t*dummy*(add(s/t,s in z));
  end if;
end proc:

`value/&*`:=proc() `*`(args) end proc: # part of Preben A.'s idea

factorcoeffs:=proc(G,x,{method::identical(none,ampersand,name):=none})
  local L,locdummy;
  uses PolynomialTools;
  L:=CoefficientList(G,x);
  eval(`if`(type(L[1],`+`),
            factorsum(L[1],':-method'=method,':-dummy'=locdummy),
            L[1]),locdummy=1)
  +add(`if`(type(L[i],`+`),
            factorsum(L[i],':-method'=none,':-dummy'=x^(i-1)),
            L[i]*x^(i-1)),i=2..nops(L));
end proc:

factorcoeffs(expr,beta);
                                         2        
              12 w + 4 - 16 beta + 3 beta  (1 - w)

factorcoeffs(expr,beta,method=ampersand);
                                            2        
           4 &* (1 + 3 w) - 16 beta + 3 beta  (1 - w)

value(%);
                                         2        
              12 w + 4 - 16 beta + 3 beta  (1 - w)

factorcoeffs(expr,beta,method=name);
                                           2        
           (4) (1 + 3 w) - 16 beta + 3 beta  (1 - w)

expand(%);
                    2                              2
           -3 w beta  + 12 w - 16 beta + 4 + 3 beta 

 

Also, the factoring step could use something other than `gcd`. That sort of consideration is, I think, minor relative to the issue of handling (any, or the) automatic expansion.

@Alec Mihailovs Regarding that bug you show in `asympt`, with the escaped local `pt`, I don't understand the mix of try..catch and lasterror in lines 44-54 of `series/RootOf`. If a division-by-zero error is generated on line 46, then why wouldn't pt be unassigned during lines 51-54?

Also, there is a bug in the Standard GUI's prettyprinting. The `break` in the `catch` clause is not displayed (unless it is first showstat'd), at prettprint=3. A blank character is displayed instead. You can see this in a Worksheet in the Standard GUI (with typesetting level at either 'standard' or 'extended') as follows.

restart:
interface(prettyprint=3): # also problematic at 2?
f:=proc()
  local i;
  for i from 1 to 5 do
     try
        if i>3 then
          i/(i-i);
        end if;
     catch:
        break;
     end try;
     i;
  end do;
end proc:

f(); # acts as if the break is there.

eval(f); # where's the break??
eval(f); # where's the break??

showstat(f);

print(f); # oh, there it is

@Alec Mihailovs Regarding that bug you show in `asympt`, with the escaped local `pt`, I don't understand the mix of try..catch and lasterror in lines 44-54 of `series/RootOf`. If a division-by-zero error is generated on line 46, then why wouldn't pt be unassigned during lines 51-54?

Also, there is a bug in the Standard GUI's prettyprinting. The `break` in the `catch` clause is not displayed (unless it is first showstat'd), at prettprint=3. A blank character is displayed instead. You can see this in a Worksheet in the Standard GUI (with typesetting level at either 'standard' or 'extended') as follows.

restart:
interface(prettyprint=3): # also problematic at 2?
f:=proc()
  local i;
  for i from 1 to 5 do
     try
        if i>3 then
          i/(i-i);
        end if;
     catch:
        break;
     end try;
     i;
  end do;
end proc:

f(); # acts as if the break is there.

eval(f); # where's the break??
eval(f); # where's the break??

showstat(f);

print(f); # oh, there it is

I don't think that will work, as posted, Doug. The `t` in `f` is not the same as the formal parameter `t` of `Z`. Do Z(5) to see.

Try this.

restart:
CM:=4:
f := (100-p)*(1-exp((-1)*.11*t))/(10.00000000*exp((-1)*.11*t)+1):
Z := proc(t)
local ph1;
ph1 := placeholder1;
if ph1 < CM and 0 < t then
   ph1;
 else
   placeholder2;
 end if
end proc:
Z:=subs(placeholder1=subs(p=25,f),
        placeholder2=subs(gamma = .1, p = 50,
                          (-100+p)*(1-exp((-1)*.11*t))/
                          ((-1+gamma)*(10.00000000*exp((-1)*.11*t)+1))),
        eval(Z)):
plot( Z, -10..10 );

The above should also be faster (if that matters) since the substitution for `p` doesn't get done every time the procedure `Z` is called.

I don't understand the objection to using piecewise.

restart:
CM:=4:
f := (100-p)*(1-exp((-1)*.11*t))/(10.00000000*exp((-1)*.11*t)+1):
Z:=subs(placeholder1=subs(p=25,f),
        placeholder2=subs(gamma = .1, p = 50,
                          (-100+p)*(1-exp((-1)*.11*t))/
                          ((-1+gamma)*(10.00000000*exp((-1)*.11*t)+1))),
        piecewise(placeholder1<CM and 0<t,placeholder1,placeholder2)):
plot( Z, t=-10..10 );

That revised procedure version is slightly more efficient than that piecewise version, as f only gets evaluated once for each value of t.

note to original poster: Even though it doesn't fix the problem in the procedure Doug posted, you should generally use `eval` instead of `subs` for evaluating formula `f` at a numeric point `t`, especially if Maple's evaluation rules are not entirely clear to you.

I don't think that will work, as posted, Doug. The `t` in `f` is not the same as the formal parameter `t` of `Z`. Do Z(5) to see.

Try this.

restart:
CM:=4:
f := (100-p)*(1-exp((-1)*.11*t))/(10.00000000*exp((-1)*.11*t)+1):
Z := proc(t)
local ph1;
ph1 := placeholder1;
if ph1 < CM and 0 < t then
   ph1;
 else
   placeholder2;
 end if
end proc:
Z:=subs(placeholder1=subs(p=25,f),
        placeholder2=subs(gamma = .1, p = 50,
                          (-100+p)*(1-exp((-1)*.11*t))/
                          ((-1+gamma)*(10.00000000*exp((-1)*.11*t)+1))),
        eval(Z)):
plot( Z, -10..10 );

The above should also be faster (if that matters) since the substitution for `p` doesn't get done every time the procedure `Z` is called.

I don't understand the objection to using piecewise.

restart:
CM:=4:
f := (100-p)*(1-exp((-1)*.11*t))/(10.00000000*exp((-1)*.11*t)+1):
Z:=subs(placeholder1=subs(p=25,f),
        placeholder2=subs(gamma = .1, p = 50,
                          (-100+p)*(1-exp((-1)*.11*t))/
                          ((-1+gamma)*(10.00000000*exp((-1)*.11*t)+1))),
        piecewise(placeholder1<CM and 0<t,placeholder1,placeholder2)):
plot( Z, t=-10..10 );

That revised procedure version is slightly more efficient than that piecewise version, as f only gets evaluated once for each value of t.

note to original poster: Even though it doesn't fix the problem in the procedure Doug posted, you should generally use `eval` instead of `subs` for evaluating formula `f` at a numeric point `t`, especially if Maple's evaluation rules are not entirely clear to you.

I think that it's site flaw that the member who asks a Question cannot give an up-vote if they lack the requisite number of reputation marks.

There is some number of reputation marks required for up-voting in general. Why can't the mapleprimes engine get a code adjustment (maybe just a 1-liner) to allow the submitter of a Question to up-vote just that particular message, as long as the reputation is nonnegative?

An alternative is the "checkmark" alloted by a Question's submitter (and possibly editable) to just one answer. Its purpose is to denote that the given Answer minimally satifies the questioner's needs. It thus may serve a different but important purpose than do up-votes (which may signal approval, admiration for technique, interest in the topic, or any number of other things).

[edited: I didn't say it originally, but my reasoning here is like longrob mentions. There are many Questions by recent newcomers, who cannot upvote Answers to their own questions in the current system. This leads to idiosyncrasies on a site with an active voting base as small as mapleprimes'.]

I think that it's site flaw that the member who asks a Question cannot give an up-vote if they lack the requisite number of reputation marks.

There is some number of reputation marks required for up-voting in general. Why can't the mapleprimes engine get a code adjustment (maybe just a 1-liner) to allow the submitter of a Question to up-vote just that particular message, as long as the reputation is nonnegative?

An alternative is the "checkmark" alloted by a Question's submitter (and possibly editable) to just one answer. Its purpose is to denote that the given Answer minimally satifies the questioner's needs. It thus may serve a different but important purpose than do up-votes (which may signal approval, admiration for technique, interest in the topic, or any number of other things).

[edited: I didn't say it originally, but my reasoning here is like longrob mentions. There are many Questions by recent newcomers, who cannot upvote Answers to their own questions in the current system. This leads to idiosyncrasies on a site with an active voting base as small as mapleprimes'.]

@elpam2 The point is that if you code it with Re() then it will always strip off your imaginary component, unless you only apply Re() after some test. But fnormal will leave it alone if the real or imaginary components are larger and set to zero either part if either is "too small". Your code likely can't just validly apply Re() without somehow finding out whether the imaginary component is small. But fnormal only touches it if it's small, and so gives you the right control automatically.

If you only have one single result to handle, within an example which will never change, and you can see that the result has negligible imaginary component, then of course applying Re() to it will get the simple result. I just figured that you'd want to be able to vary the problem at some point, and not worry about clobbering a nonneglible part.

@elpam2 The point is that if you code it with Re() then it will always strip off your imaginary component, unless you only apply Re() after some test. But fnormal will leave it alone if the real or imaginary components are larger and set to zero either part if either is "too small". Your code likely can't just validly apply Re() without somehow finding out whether the imaginary component is small. But fnormal only touches it if it's small, and so gives you the right control automatically.

If you only have one single result to handle, within an example which will never change, and you can see that the result has negligible imaginary component, then of course applying Re() to it will get the simple result. I just figured that you'd want to be able to vary the problem at some point, and not worry about clobbering a nonneglible part.

Try the first example with 11[13] instead of x. And 11[13] is not of type name or function. (It's an indexed integer, whatever that might be...)

Try the first example with 11[13] instead of x. And 11[13] is not of type name or function. (It's an indexed integer, whatever that might be...)

@pvrbik I get your point. See another recent comment on 2D Math representation for `add`.

Is there another feasible long-term improvement: for rtables to be referenced (unevaluated, without error) by nonnumeric index values? Why must A[i] incur an error, for rtable `A` and nonnumeric `i`?

@pvrbik I get your point. See another recent comment on 2D Math representation for `add`.

Is there another feasible long-term improvement: for rtables to be referenced (unevaluated, without error) by nonnumeric index values? Why must A[i] incur an error, for rtable `A` and nonnumeric `i`?

First 23 24 25 26 27 28 29 Last Page 25 of 81