## 432 Reputation

15 years, 117 days

## bug in int...

Let `b` be the first operand of `expand(a)`.
`b:= op(1,expand(a));`
2*cos(t)^5*sqrt(2*cos(t)^2-1)
Maple does not integrate this correctly.
`int(b, t=-Pi/4..Pi/4);`
0 The answer is incorrect, because the integrand is positive everywhere on the open interval. Check:
`evalf(Int(b, t=-Pi/4..Pi/4));`
1.735501148
`identify(%);`
(25/64)*sqrt(2)*Pi

## Re: Understanding Maple memory usage...

Acer, kind thanks. The initializer I got from `?RandomTools,Generate`. After reading your post, I redefined `Generate` so that it printed something at each invocation. It only printed once for the `Matrix` call. So the initializer is only creating one random-number generator per Matrix. I thought that there might be more efficient ways of doing the computation. But I would still like to understand why memory usage grows so much in the `do` loop. Even if it were creating a lot of garbage, why wouldn't Maple do a `gc`, and then reuse some allocated memory? Instead, bytesused seems to grow with each iteration of the loop.

## Yes!...

Good! `for` loops over lists/Vectors/etc. can always be replaced by `fold` (assuming that there are no side effects in the loop). This is sometimes called the “universality of `fold`”. In principle, `fold` can also replace `while` loops. This is likely to lead to inefficiencies much more often than with `for` loops, however. One very small change to your code might be this: `foldl((d,l)->map((ll,d)->op(map(`+`,d,ll)),l,d),[0],op(L));`

## Yes!...

Good! `for` loops over lists/Vectors/etc. can always be replaced by `fold` (assuming that there are no side effects in the loop). This is sometimes called the “universality of `fold`”. In principle, `fold` can also replace `while` loops. This is likely to lead to inefficiencies much more often than with `for` loops, however. One very small change to your code might be this: `foldl((d,l)->map((ll,d)->op(map(`+`,d,ll)),l,d),[0],op(L));`

## interface(warnlevel) and try ... catch ?...

Is there a way to turn off warnings for expressions? Here is my first attempt.
```nowarn:= proc(_expression::uneval)
local _nowarnresult, _warnlevelsetting;
_warnlevelsetting:= interface(warnlevel = 0);
try _nowarnresult:= eval(_expression)
catch: error
finally interface(warnlevel= _warnlevelsetting)
end try;
_nowarnresult
end proc:
```
Then  `nowarn(plot([cos, sin(x)], 4 .. 6))`  displays the plot without warnings. I do not have a good understanding of all the relevant issues. So perhaps someone can improve on the above…?

## Re: Exponents >= 100...

Kind thanks. I didn't know about the restriction on ``expand/sin`` (and find it difficult to agree with).

## Re: expanding Re...

I have the same question as in John Fredsted's post. Is there a reason that ``expand/Re`` is not currently in Maple, or is the absence just an oversight? (Perhaps the code should be in my maple.ini file.) Also, what is the reason that ``expand/Re`` treats exponents >=100 differently?

## evalc...

From `?evalc`:
The fundamental assumption that evalc makes is that unknown variables represent real-valued quantities.

## constant of integration...

`?int,details` says this.
Note that the indefinite integral in Maple is defined up to a piecewise constant. Hence, the results returned by int may be discontinuous at some points.
It is usually possible to figure out the constant via `discont`. There is a minor bug in this case, because Maple concludes that there are discontinuities twice as often as there really are. `discont(F,x);`      {(1/2)*Pi+Pi*_Z6} (The bug is not fatal, but just means that retrieving the piecewise constant is twice as much work.)

## terminological problem...

I think that this is a problem with the specification in Maple: “linear” should not mean something very similar to, but significantly different than, what it means in mathematics. This issue was discussed by JacquesC and I here. Problems in the specification are likely to lead to bugs in programs. Jacques's answer here is an illustration.

## terminological problem...

I think that this is a problem with the specification in Maple: “linear” should not mean something very similar to, but significantly different than, what it means in mathematics. This issue was discussed by JacquesC and I here. Problems in the specification are likely to lead to bugs in programs. Jacques's answer here is an illustration.

## Nothing should be considered...

Answers 2 and 3 should be modified to work for an empty list. For #2, this is simple. For #3, the beauty is lessened, unfortunately.

## Physics package and QFT...

The Physics package is new to Maple 11. The Help page for Physics says as follows.
You are very welcome to contribute ideas for improvements. There is a great deal of scope for changing and improving things; let us know your suggestions writing to support@maplesoft.com.
The developers of the Physics package also have a best-selling podcast, which might be worth hearing before contacting them.

## GraphTheory...

I don't know if this is useful for your work, but if you are doing graph theory, does Maple's GraphTheory package help? (It is a fairly extensive package.)

## Knuth: TAOCP...

Thanks. See The Art of Computer Programming ( vol. 2).
 2 3 4 5 6 7 8 Last Page 4 of 13
﻿