For some reason, geometry:-draw does its own argument checking (instead of relying on plot to do it), and it has not been updated to deal with this new option. It looks to me like the geometry package has suffered from a lot of bit-rot (at least by judging from the routine geometry:-`draw/checkopt1`).
For some reason, geometry:-draw does its own argument checking (instead of relying on plot to do it), and it has not been updated to deal with this new option. It looks to me like the geometry package has suffered from a lot of bit-rot (at least by judging from the routine geometry:-`draw/checkopt1`).
Computing the gcd of 1-x and x-1 is no harder than computing that of x+2*y and 2*x+y. The biggest difference is that -1 is an integer and 1/2 is not (but it is rational). If you look at the algorithms for computing gcd's, they don't care about this.
One drawback is that gcd's are no longer unique, they can differ by a choice of unit. But that particular flavour of non-determinism is actually fine! So, in an effort to make some things unique (gcds), non-determinism was simply moved elsewhere. However, it turns that algebraically the non-uniqueness of gcds is not so harmful, while analytically pulling out a unit is.
Computing the gcd of 1-x and x-1 is no harder than computing that of x+2*y and 2*x+y. The biggest difference is that -1 is an integer and 1/2 is not (but it is rational). If you look at the algorithms for computing gcd's, they don't care about this.
One drawback is that gcd's are no longer unique, they can differ by a choice of unit. But that particular flavour of non-determinism is actually fine! So, in an effort to make some things unique (gcds), non-determinism was simply moved elsewhere. However, it turns that algebraically the non-uniqueness of gcds is not so harmful, while analytically pulling out a unit is.
But somehow all spaces still seem to get swallowed up, and that makes code looks really ugly. That is why I prefer to use <pre> tags.
Speaking of which, I have yet to check if that same 'spacing bug' has been fixing in Maple 11's export-to-HTML?
But somehow all spaces still seem to get swallowed up, and that makes code looks really ugly. That is why I prefer to use <pre> tags.
Speaking of which, I have yet to check if that same 'spacing bug' has been fixing in Maple 11's export-to-HTML?
What he did is generally what I had in mind. And since I am wasting bandwidth, I guess I could just add that as a matter of style I would have written
restart;
Digits := 14:
out1 := table():
(count, N, L, beta) := (1, 4, 0.2e-2, .85):
cost := Vector([2000, 100, 700, 1000]):
lambda := Vector([.2, .6, .3, .7]):
Lambda := add(lambda[i], i = 1 .. N):
DFR := (s)->add(lambda[i]*add((L*lambda[i])^k*exp(-L*lambda[i])/factorial(k), k = 0 .. s[i]-1), i = 1 .. N)/Lambda:
IN := Matrix(N, N, shape = identity):
S := Vector[row](N):
maxDFR := DFR(S):
while maxDFR > beta do
prevDFR := maxDFR:
maxdelta := 0:
for k to N do
Sk := S+IN[k, 1 .. N]:
DFRk := DFR(Sk):
delta := (DFRk-prevDFR)/cost[k]:
if delta > maxdelta then
(maxdelta, maxDFR, Snxt) := (delta, DFRk, Sk):
end if:
end do:
if maxdelta = 0 then
print("cannot increase");
else
S := Snxt:
Inv := S.cost:
printf("S = %g\nSFR = %.14g\nI = %g\n\n", S, maxDFR, Inv);
out1[count] := plots:-pointplot([Inv, maxDFR]):
count := count+1:
end if:
end do:
What he did is generally what I had in mind. And since I am wasting bandwidth, I guess I could just add that as a matter of style I would have written
restart;
Digits := 14:
out1 := table():
(count, N, L, beta) := (1, 4, 0.2e-2, .85):
cost := Vector([2000, 100, 700, 1000]):
lambda := Vector([.2, .6, .3, .7]):
Lambda := add(lambda[i], i = 1 .. N):
DFR := (s)->add(lambda[i]*add((L*lambda[i])^k*exp(-L*lambda[i])/factorial(k), k = 0 .. s[i]-1), i = 1 .. N)/Lambda:
IN := Matrix(N, N, shape = identity):
S := Vector[row](N):
maxDFR := DFR(S):
while maxDFR > beta do
prevDFR := maxDFR:
maxdelta := 0:
for k to N do
Sk := S+IN[k, 1 .. N]:
DFRk := DFR(Sk):
delta := (DFRk-prevDFR)/cost[k]:
if delta > maxdelta then
(maxdelta, maxDFR, Snxt) := (delta, DFRk, Sk):
end if:
end do:
if maxdelta = 0 then
print("cannot increase");
else
S := Snxt:
Inv := S.cost:
printf("S = %g\nSFR = %.14g\nI = %g\n\n", S, maxDFR, Inv);
out1[count] := plots:-pointplot([Inv, maxDFR]):
count := count+1:
end if:
end do:
Generating a list of plots is a good idea, but doing it via adding a plot at a time to a list is a bad idea (that's quadratic in N !). That method of doing things should be well-documented as a Maple
anti-pattern.
It would be a better idea to store it in a table or Vector (of size N, indexed by k), and then if converting it to a data-structure that plots:-display can handle (it might already be able to display a Vector of plots).
Generating a list of plots is a good idea, but doing it via adding a plot at a time to a list is a bad idea (that's quadratic in N !). That method of doing things should be well-documented as a Maple
anti-pattern.
It would be a better idea to store it in a table or Vector (of size N, indexed by k), and then if converting it to a data-structure that plots:-display can handle (it might already be able to display a Vector of plots).
limit, limit/MrvRight, simplify, sqrt, signum, is. The problem asked of 'is' is quite difficult, so it is not surprising that takes a lot of time.
What is surprising is:
1) the raw call to simplify/trig in limit/MrvRight. While advantageous in some circumstances, this will definitely cause scaling issues for larger problems.
2) the huge cost of a call to (symbolic) sqrt.
In particular, what really causes things to go astray is the call
sqrt( (72*sin(`limit/X`)-168*sin(`limit/X`)*cos(`limit/X`)^2+
355*2^(1/2)*ln(-(-1+sin(`limit/X`)*2^(1/2)*cos(`limit/X`))/(1+sin(`limit/X`)*2^
(1/2)*cos(`limit/X`)))*cos(`limit/X`)^3+710*2^(1/2)*arctan((sin(`limit/X`)*2^(1
/2)+cos(`limit/X`))/cos(`limit/X`))*cos(`limit/X`)^3+710*2^(1/2)*arctan((sin(
`limit/X`)*2^(1/2)-cos(`limit/X`))/cos(`limit/X`))*cos(`limit/X`)^3+96*
`limit/X`*cos(`limit/X`)^3)/sin(`limit/X`)^3 )
where `limit/X` is known to be RealRange(Open(0),1/10). This call is not accidental, but very clearly part of the design of`simplify/trig/recurse`.
Digging a bit more, what takes a lot of time in that call to sqrt, is the following call to is:
is(72*sin(`limit/X`)-168*sin(`limit/X`)*cos(`limit/X`)^2+355
*2^(1/2)*ln(-(-1+sin(`limit/X`)*2^(1/2)*cos(`limit/X`))/(1+sin(`limit/X`)*2^(1/
2)*cos(`limit/X`)))*cos(`limit/X`)^3+710*2^(1/2)*arctan((sin(`limit/X`)*2^(1/2)
+cos(`limit/X`))/cos(`limit/X`))*cos(`limit/X`)^3+710*2^(1/2)*arctan((sin(
`limit/X`)*2^(1/2)-cos(`limit/X`))/cos(`limit/X`))*cos(`limit/X`)^3+96*
`limit/X`*cos(`limit/X`)^3, real)
This looks like something which should 'work'. More digging reveals some clear bugs. In particular this call
radnormal( RealRange(Open(1),Open(2^(1/2)*sin(1/10)+1)) )
return Error, invalid arguments. That is most definitely a plain bug -- and of course things start to go really wrong from there.
Actually, to be precise, that call to radnormal appears to be the culprit, but it works on its own. It seems that the issue is actually in the call
evalindets( evalindets(RealRange(Open(1),Open(2^(1/2)*sin(1/10)+1)),
anything^fraction, pow -> `radnormal/Radical`(op(1,pow),denom(op(2,pow)),0,rest)^numer(op(2,pow)))
In fact, past this bug (which is hidden by a nice call to 'hidebug'), there is no point in further figuring out what is going on.
The marketing material for Maple makes is sound like this should succeed, and is in fact a highly vaunted feature of Maple 11. So do try to do exactly that (how, I don't know, I don't use maple for type setting...).
If it works, great, tell us, maybe we'll start using Maple for more than its great computational power. If it does not work, complain about misleading advertising, etc, etc.
The marketing material for Maple makes is sound like this should succeed, and is in fact a highly vaunted feature of Maple 11. So do try to do exactly that (how, I don't know, I don't use maple for type setting...).
If it works, great, tell us, maybe we'll start using Maple for more than its great computational power. If it does not work, complain about misleading advertising, etc, etc.
Recommending dismantle to the unwary Maple user is not very nice. Dismantle is nice and all, but it does have three drawbacks: it is amazingly low-level, it requires deep Maple knowledge, and worst, it is display-only! [I mean, dismantle works via a side-effect of printing something, it returns NULL]
Recommending dismantle to the unwary Maple user is not very nice. Dismantle is nice and all, but it does have three drawbacks: it is amazingly low-level, it requires deep Maple knowledge, and worst, it is display-only! [I mean, dismantle works via a side-effect of printing something, it returns NULL]
