@MuriloLobo 

To produce random numbers with a certain pdf you need the pdf. If all you have is the cumulative df then you need to look at differentiating it to get the pdf.

This, however, is less of a Maple question but more of a question for a statistician.

M.D.

@ecterrab 

I turned the geometricdifferentiation off and the particular example works fine. But there is other funky business going on. Consider the new example I have posted below. It is a (simple) derivation of the wave equation from Maxwell's eq. With geomdiff false, I get the weird differentials as in the posted sheet. With geomdiff true, I get the expected result just like in the older version I run in Maple 15. Note that the last line ends up at the wanted result in either case.

I suppose I can use the "better approach" you describe above and leave geomdiff true, but it seems to me the result with geomdiff false is odd.

M.D.

geomdiff.mw

@ecterrab 

Excellent, many thanks.

M.D.

@ThomasE 

Define "same". Pie charts are possible. The text in the slices you can put in using plots:-textplot. The arrow I don't know. The 3-d appearance I don't know either; it may have been added in later versions (but the manual will tell you).

So, if you want it to look identical pixel by pixel: probably not. If you want to convey information in the same manner (i.e. a pie chart), yes.

M.D.

@MuriloLobo 

Had a quick look. The program tries to readin a data set we don't have.

The offending line indeed gave me an "invalid sequence" error... until I fixed the comma again at which point it dutifully complained about S1 not being a module (it nowhere defined).

The dangling comma and missing S1 (and other variables) indicate you are be missing a piece or pieces of the code. As it is, it will not run. I suggest you go back to wherever you got the code from and get the missing pieces.

M.D.

The code snippet you posted is incomplete. S1 is not defined (it could be a part of a library package in which case you would have a "with(some package)" command at the top of your sheet. The last comma needs to be a semicolon.

In your snippet, seq is asked to create a sequence of equations. I am not sure that works; I have never tried that. If you want booleans (true or false) try wrapping evalb() around the equation.

Also, most of your variables are undefined so we cannot run your code to see why it fails.

Mac Dude.

@sarra 

After fixing some more minor mistakes (missing ";", missing comment flags, that Maple does flag) I get an output:

I suspect this may not be what you want. The infinities appear to arise form the GenerateMatrix commant. Note that you can use the side panel to inspect your variables for troubleshooting & checking on intermediate results.

Updated sheet attached.

M.D.

sarra.mw

@itsme 

I did not mean to be harsh, and Maple's help is a decent distance away from being perfect esp. when it comes to looking up more obscure features. But order and Order actually happen to be documented under those names; I think order may even be linked from the series page.

You >can< unprotect and then clobber these (I think, not tried) but that seems like an unwise move.

M.D.

@itsme 

The concept of "order" as in "calculation to first order" is intimately bound to series expansion. Mathematically, except in trivial cases a series expansion is what you have to do. It decomposes the expression by order and lets you truncate where you want, by calculating the derivatives and finding their coefficients. If you rely on "truncation by inspection", you run the risk of calculating to mixed order and lose the benefit of e.g. linearizing your problem. In worse cases you get an erroneous result. Maple's series command avoids problems like that and is the one to use for the general case. There may well be cases where substitution is appropriate, but only you can determine whether that is what your specific problem calls for, Maple cannot.

$0.02

M.D.

PS: order and Order are already taken in Maple and protected. RTFM.

I would argue that series >is< the built-in command. As acer pointed out, the replacement commands or rules may miss some 2nd-order terms. Simplify with siderels may do other things to your expression that you may or may not want. And, although not the case in your example, there could be terms beyond 2nd order that replacement rules would almost certainly miss. If you want terms up to a certain order, series seems the way to go. Has rarely failed me.

M.D.

@Carl Love 

Carl & Alejandro, both many thanks. I don't think I'd have figured this on my own. Can't run my worksheet right now, but I do understand the issue.

As for useInt not working: that turned out to be operator error. Been staring for too long at this.

M.D.

@Alejandro Jakubi 

Well, maybe one answer would be to use the Application center more often. I do not know the old Share Library so I cannot compare, but at least in the Application Center I can find things. Since you mentioned Fourier series: there is apparently a package by Moiseev that includes Fourier series (amongst others), and there is even a sheet by Lopez that explains some aspects of the use of the package. (I realize you used this as an example, and this may not do what you need). Ongoing maintenance is a problem even the large open source projects don't get right: lots of older packages linger and get stale. If the creator loses interest it's pretty much just tough luck.

I like the idea of something like Sage; but at this point I have invested quite a bit in Maple, it does what I need (mostly), and I have little inclination to try another one. Maple has a lot of programming constructs I really like and use (modules, records, all the semi-oop stuff) that I don't want to let go of. I highly doubt Sage has anywhere near the polish Maple has. (And yes, in daily work just trying to get something done efficiently, and trying to get e.g. publication-quality graphs done, polish counts. Even Maple has a ways to go in that department.)

(Note to self: I should consider packaging one of my programs for submittal to the Application center. It may have some appeal for others, and since its routines by now have been validated one may let it lose on the public.)

Cheers,

Mac Dude.

@Markiyan Hirnyk 

Markiyan, this was unfortunately (as far as examples are concerned) about a year ago so I do not have the broken version around anymore. What I do remember is that a part of the issue was that I had large Arrays declared as "datatype=anything". This means that Maple was not forced to numerically evaluate an expression (unless you use evalf), and at least in my case dutifully kept working in the symbolic domain. So, once I found that out I littered my code with evalf() statements until I smartened up to this datatype issue, after whch things became much better.

As far as timing was concerned, I just ran scenarios with different no. of iterations & wrote the times down. Since I allocated the arrays based on the max. number of iterations there was a component in the time per iteration that depended on the max. # of iterations.

This was, incidentally, a code converted from Mma, which was part of the issue. Mma's structure is sufficiently different from Maple's that the conversion was a lot more involved than expected.

This is probably not quite what you wanted, but I am not able to post a useful example.

Mac Dude.

@Markiyan Hirnyk 

Hi, let me just add (fbo the OP) that I have found it sometimes helpful to analyse the time used vs # of iterations. If you know the behaviour of the algorithm, a different behaviour (e.g. a higher-order dependence) points to flaws in the implementation. I once diagnosed a problem with a numerical calculation in this way: a simple calculation that should have used the same time/step no matter what, actually showed exponential use of time. It turns out that Maple was doing things symbolically rather than numerically, thus creating enormous expressions until it choked to death. The exponential time use clued me in (and the memory consumption pointed in the same direction). And there are of course endless possibilities to get trapped in array-indexing issues, some of which Maple "helpfully solves" by continuously allocating new memory for arrays...

M.D.

@Alejandro Jakubi

I fully agree re. the difficulties of single-author repo's. They come and go as the life of the author evolves and their priorities shift. Keeping up is also a very time-consuming job. Those that have the long enough view to keep it up beyond their own active involvement typically go commercial.

But what is the need we really have? One class revolves around sharing what one does anyway, assuming it may be helpful to others. This can be a very useful thing, and I would argue that the Application Center can serve a purpose here. After all, it is somewhat organized andd I can actually narrow down the field enough so I can scroll through a finite list of entries, which have a description attached to them etc.

A totally different thing would be actual developments with the aim of extending the Maple system itself. This is an area I am not qualified to talk about, but it is much more complex, and do we as a community have the critical mass to do pull such an effort off and sustain it? Is there even a "market" for this?

$0.02 $0.01

M.D.