6814 Reputation

17 Badges

10 years, 226 days

MaplePrimes Activity

These are answers submitted by tomleslie

The TimeSeries package seem to rely on equally-spaced time points (I could be wrong!!), but you seem to have more or less random time points - so timeSeries is probably(?) the wrong choice

It isn't too difficult to import the data and organise it in a more or less sensible way. The problem is to decide what is a sensible organisation, and this (probably) depends on what you are subsequently going to do with the data.

The problem is made more difficult by the fact that the two time series don't really "align", so you inevitably end up with

timeValue, QGASvalue, NULL, or

timeValue, NULL, PMEASvalue

and frankly, dealing with NULL entries is a right royal pain in the whatever.

The attached shows one option, where the data is ultimately stored as a table. The table indices are time values, and the table entries are a two-element list of [PMEASvalue, QGASvalue]. In most cases, one of these list entries is NULL, becuase no corresponding data value exists.

Whether or not you find this organisation acceptable depends very much on what you plan on doing with the data!!

as in

A := Array([[1], [2], [3]]);

As has aready been pointed out, what do you mean by logp and logd - should these be log(p) and log(d)

Also (as been noted previously), I'm pretty sure that your final equation is missing a multiplication symbol. If I make these assumptions, and just run the code

f:= 2=c/p*(1+p^2)^2,
fsolve( {f}, {c,p,d,m});

then I get the answers

{c = 0.3049933633e-2, d = 6.797845273, m = -0.1978119948e-1, p = 0.1524973909e-2}


You have numerous instances where you use the subs() command in the format

subs( {set of substitutions}, [list of expression, but only one entry]);

Now I have no idea why you are using [B1], [alpha], [theta], as the second argument in these subs() expressions, rather than simply B1, alpha, theta.

When I make these simple corrections, as shown in the attached,

I get


Now I didn't bother debugging any further, because if theta1:=0 - anything  after this point is going to be really boring

In the (sub)-section you label as an "Analytical solution", you issue the command

pds := pdsolve(pde, bcs, numeric, time = t, range = 0 .. x[max], indepvars = [x, t], spacestep = (1/1000)*x[max], timestep = (1/1000)*t[max]);

The significant operand in this command is the word 'numeric'. This means that Maple will compute a numeric solution, (not an analytic one) and the default method will be finite difference.

I have no problem with you (subsequently) trying to write your own numerical method  for solving the same problem, but before we even get into that, you have to accept that you will be comparing your numerical solution with Maple's numerical solution.

Is that really what you want?

Your actual question is unclear

The following worksheet computes/plots most things you might want to know about your ODE - and when I guess that what you want to compute is diff(f(eta), eta, eta) when eta =0, it does produce the answer .332057384255589

Sometimes this gets banjaxed by Maple permission issues.

I know that the following reference is for translating completely different help files, but you might want to read

The important(?) step is that you have to be running Maple as an administrator in order to write the new help files to the desired location. Don't think that just because you have administrator privileges, Maple has. By default, it doesn't. So try the steps in the above link, whilst running MAple as administrator

It's worked before - can't hurt to try!

A cou00le are shown in the attached worksheet


If you change the final command in your worksheet to specify the indeterminate function ( ie follow the instruction given in the error message), as in

pdsolve(sol, w(x,y));

then Maple will (correctly!) return

w(x, y) = 0.

Note that this satisfies all of your boundary conditions, and your PDE - so is definitely a solution for the problem

Somehow I have the feeling that this is not what you want!

In this case you are being warned that you should only use solve() to solve for names or functions, ie not expressions such as


presumably becuase the requested operation is not guaranteed to work correctly!

If you really, really want to, then you can turn off warnings (I do not recommend doing this). But if you precede your code with


then all warnings will be turned off. I would reset this to the default immendiately after your code, with


I suggest that you also check some of the terms in your definition of system3d: in particular




Are these really what you meant???


This wold be OK if 'x' were guaranteed to be of type 'algebraic', Now what would you expect to happen if 'x' is not of type algebraic??

If you want to know what type/algebraic actually means, the check out the help page at ?type/algebraic

There are many Maple types which are not 'algebraic'!

L[1..5] returns an array whoses indices are 1..5 and whose values are L[1], L[2], L[3], L[4], L[5]

L[3..6] returns an array whose indices are 3 ..6 and whose values are L[3], L[4], L[5], L[6].

You seem to expect that L[3..6] would return an array whose indices are 1..4 and whose values are L[3], L[4], L[5], L[6]

So the obvious question you have to ask yourself is: when you ask for L[3..6] - what are the indices of the returned array?? Are they 3..6 or 1..4???

Now I could (if I had to) come up with argument in favour of either: but at some point, somewhere in history, somebody decided that L[3..6] would return an array whose indices are 3..6 (ie not 1..4), and then decide on the best way to represent it

Without an example it is dfficult to be specific, but you should investigate the colorscheme["valuesplit"....] plot option

Consider the following "toy" example

# Generate points for an example function
    pts:=[seq([k, sin(k)], k=-evalf(Pi)..evalf(Pi),0.25)]:
# Get the y-values of the plots and sort them in
# ascending order
   lims:= sort([seq( j[2], j in pts)]):
# valuesplit the colorscheme so that the maximum
# value (given by lims[-1]) is one color, and all
# others (range is given by lims[1]..lims[-2] )
# are a differentt color
   plots:-pointplot( pts,
                           colorscheme=[ "valuesplit",
                                                [ lims[1]..lims[-2]="Red",

[{seq([ListTools:-SearchAll(j,a)], j in a)}[]];

seems to work pretty well, with the proviso that you are not too bothered aboout the order of the returned entries - which I am pretty sure I could fix with a sort command

  1. Can confirm that I get pretty much the same message as you when I try to multithread, os maybe I have to keep looking at this
  2. On the other hand if I make a small adjustemnt to your code, I (probably) wouldn't bother to multithread - the overhead of setup/result collation etc would (probably) outweigh actual calculation time in a single thread!

Modified code is as follows

  with(RealDomain): #I know, I don't need all of that here
   t1:=time(); #start timer
   cdf := x-> int(PDF(GammaDistribution(4.5/100,2.5),xi-0.068),xi=0.068..x);
   N:= 20:
# Change solve() to fsolve() - after all OP deo want a simple numeric
# answer
   sample := (i) -> fsolve( (1/(2*(N+1))+1/(N+1)*i)=cdf(x),x); #this is an equidistant sampling
#smpl := [Seq(sample(i),i=1..(N-1))]; #I try to run a multithread seq -> got it from the documentation
   smpl:=seq([i, sample(i)],i=1..N-1);

Note the use of fsolve() rather than solve() in the definition of the sample() function.

I also include the index value in the output of the above smpl() command, because when I tried the single-threaded approach with the your original sample/solve() command, some index values did return a value at all - I wanted to check this issue. But I did not resolve this. All I establishe was that for some index values solve() returned no solution

Using fsolve(), the included timer commands indicate that the single-threaded version provides the required answers in 3.3secs (on my machine). Doubt if running multi-threaded will do much better - setup and return overheads versus actual calculation time etc, etc

Of course your original calculation should run multithreaded. At the moment I can't figure out why it doesn't, but my Maple installation seems to be partially broken at the moment ( :-( ) ) so I have to get ot the bootom of that first


First 115 116 117 118 119 120 121 Last Page 117 of 140