The conventional way to do this would be to save your "original" code as an m-file (ie Matlab syntax), and then within Maple use Matlab[FromMFile]  which will convert the m-fiile to Maple syntax. However (rather obviously, and as Carl has pointed out) your original code is not valid Matlab syntax, does not work in Matlab, and has never been anywhere near Matlab,  so I can guarantee that this translation command willl not work.

You have two choices

1. Supply valid Matlab code
2. Forget Matlab and ask how to solve your problem in Maple. Carl has already done this, although (as his code hints), I suspect that your code contains several (language-independent) logical errors

All you have o do is pick one!

@Carl Love 

About a year ago, and after posting a request on MaplePrimes I sent the following email to maple technical support

I tend to use

seq( f(i), i=m..n)

and

f(i) $ i=m..n

more or less interchangeably, provided that the loop variable has a unit step. However I recently found an example where the former ran 2.5x faster than the latter. See the attached two worksheets.

Is this behaviour expected?
For the future, how can I tell when one of the two implementations is going to be significantly more efficient?

The only response which I received from Maple technical support was

Hello Tom,

Thank you for contacting Maplesoft. I suspect this behaviour may be due to the thread safe ability of the seq command.

I have forwarded this problem to our second level support for review. I will keep you informed as to the outcome.

Regards,

Chris

Technical Support Analyst

I have  received no futher upfates on this issue and so I have tended to avoid using the $ construct subsequently, since I can produce cases where it runs subtantially slower than the seq() construct - and I have never found a case where the seq() contruct runs slower than $

indets(dsys3);

will list the unknowns. It tells me two things

1. You don't seem to have an unknown parameter?? You have the variable x, three functions of x, and various derivatives of these three functions
2. You have up to third derivative of f1(), and fourth for f2() and f3(), a total of 11 derivatives. However you only have 10 boundary conditions. Leaving aside (for the moment) whether you have a "valid" set of boundary conditions for the problem, I think you are going to need one more

@roman_pearce 

Need to be careful with the /\ thing on windows: you have to enter paths as

C:\\Users\\yourname\\...

or

C:/Users/yourname/...

@nm 

Rather obviously, you must have different security settings on your C drive and your G drive.

Strictly speaking this is a win7 issue rather than a Maple one, cos it looks as if Maple is obeying your win7 security settings.

The reference you quote (ie http://projecteuclid.org/download/pdf_1/euclid.dmj/1077490637) is subscription-only. No-one here is going to pay to check out the background to your problem, so we are stuck with the code you supply.

I have tried a few variations on verifying equality of expressions and the answer always comes up false. This suggests to me either that

1. The reference you cite (which I can't read without paying - not going to happen) is incorrect
2. The reference you cite (which I can't read without paying - not going to happen) is correct, but you have wrongly entered the problem in Maple - since I can't check the original, I wouldn't know

My money is on (2) above - but since I can't check it, I can't help

f:=(x, y, z)-> x + y * z;

ans:=Array( -10..10, -10..10, -10..10,

            [ seq
              ( [ seq
                  ( [ seq
                      ( f(x, y, z), x=-10..10)
                    ],
                    y=-10..10
                  )
                ],
                z=-10..10
              )
            ]
          );

Because you had selected the username maple2015, I made the rash (if logical?) assumption that your were running Maple 2015 rather than Maple 18.

The operation of the min() function changed slightly between Maple 18 and Maple 2015. In the latter one can return the index of the minimum, rather than the minimum itself from a variety of data structures. I used this functionality in my original response.

The attached is essentially the same solution as before tweaked to run correctly in Maple 18, by a minor revision to the final executiion group.

TCprob2.mw

This returns the same graph and the value

8.05000000000000000000000000000

in ~19 seconds.

Your original code in takes 55seconds (in Maple 18) on my machine. So the speed-up for the same answer is still about 3x

@maple2015 

Both versions give the same answer

On my machine (running Maple2015), your original code produces a graph and the value

8.05000000000000000000000000000

in ~58seconds.

The code which I tidied up for you produces and identical graph and the same output value in 19secs

What answers did you get??

It is not clear from your question what you are trying to achieve.

A superficial examination of your code reveals some bad practice (not necessarily wrong, just poor programming practicce). Revising the code to remove the more glaring examples of bad practice, speeds up the computation by a factor of ~3.5.

The most obvious example of bad programming prctice is your use of a loop variable in an expression before the start of the loop - this isn't *wrong*, just realy, really ugly. I suggest you avoid this practice completely

The dominant term in the computation time is the evaluation of the expression F as the ratio of two integrals. Maple is obviously having to *think* to produce this expression, and as such this is the obvious place to contemplate further  speed improvement.

Since I don't really know what you are hoping to achieve, I am disinclined to do any more work on this.

I suggest you compare the attached with your original

TCprob.mw

From which code exactly, does the the message

"there is arising an arror, invalid fraction"

arise. Are we supposed to guess???

Consider using the big green up-arrow in the Mapleprimes editor to upload code exhibiting the problem for which you require a solution.

Alll I know about LAne-Emden equations is that they generally require numeric solution. From the information which you supply, no help is possible.

Your problem statement makes abolutely no sense. You seem to think that for some arbitary value x, then repreated iteration of the function the function F will result in a value between p and q. Consider a trivial example:

p=1, q=2, F(x)=x³

Now if I supply a value for x<1, then repeated iteration of F(x) will get smaller and smaller so it will never lie in the range 1..2. On the other hand, if I supply a starting value greater than 2, then repeated application of F(x) will get larger and larger and never lie in the range 1..1. Thus for trivial cases, your problem is impossible.

Are there functions and ranges for which this iteration process would work - well I can think of a couple of examples, but these are somewhat specialised -so you need to define much more carefully exactly wht you are trying to achieve.

By the way, the procedure which you have posted will never work for any values it is passed for (at least) two reasons.

1. It contains the statement x:=z, where x is a passed parameter and z is a local variable. In Maple procedures, you cannot reassign the value of a passed parameter
2. The local variable z is never assigned a value, it only ever evaluates to itself, ie the name z. This makes statements such  as if p<z, nonsensical: this boolean can only be evaluated when both arguments are numeric, which z never is

@nm 

The wikipedia entry for "Diffusion |Equation" will give you the canonical diffusion equation.

However this will not help the OP, because in the "canonical" equation the diffusion coefficient is allowed to be an arbitrary function of both the density of the diffusing medium and position (and I have never understood why it is not also permitted to be an explicit function of time). Since this function is entirely arbitrary, there is no such thing as a "canonical" solution!

The diffusion equation can be solved under various simplifying assumptions, the most common of which is that the diffusion coefficient is a constant -in which case the problem reduces to an IVP/BVP-type question. Given a "simple" function for the diffusion coefficient, together with the correct set of boundary conditions/initial values, the diffusion equation can usually be solved (albeit probably numerically)

You are going to perform a reasonably complicated operation 1685159 times: unless the operation can be performed very, very fast, you are going to have to wait for a long time.

To calibrate your expectations, I asked Maple/solve() to produce the solution of two simple linear equations in two unknowns. It took ~0.5mSecs on my machine. So doing even this simple operation 1685159 times would take ~95seconds. Now your solve() arguemnt is three equations in three unknowns, so you could probably double this to ~200secs. However, you appear to have many occasions where no solution is possible which I'm pretty sure would take even longer - for sake of argument, I'd double it again to ~400 seconds. In other words, the way that your code is written - it would take something like 7 or 8 minutes just to do the first statement of the do loop.

This sort of time penalty would set me thinking, along the following lines. You appear to generate a large number (1685159) of possibilities only to throw most of them away, because your solve() command produces no viable solutions. I would give some serious thought to generating only those possibilities for which solutions exist. From your worksheet, I have no idea whether this is possible - but like I said, I would spend significant time thinking about it!

It is always tempting to do computations in the obvious way, and rely on cpu clock rates to get you out of trouble: but at some point you have to get clever and optimise the approach as much as possible. For serious problems, wetware still beats (soft/hard)ware

Not necessarily better, but just because alternatives are a good thing to consider!

restart;
L:=Array(1..3, 0..3, [ [x4, x1, x2, x3],
                                [y4, y1, y2, y3],
                                [z4, z1, z2, z3]
                             ]
             ):
K:=(j::posint, i::integer) -> L[j, irem(i,4)]:
seq( seq( K(p,q), q=1..8), p=1..3);

If you were going to perform this function a lot - then this will probably(?) run faster, simply becuase it avoids the `if` statement in the function call, at the expense of reordering the data in the setup array