@mmcdara 

I didn't adjust any "tickmarks" - which would be done with the 'tickmarks' option in one of the plot commands.

I decided that that there was no combination of 'axis' and 'tickmarks' plot options which would give the layout you wanted. Notice that the final display command in my earlier post uses the option axes=none, because, I don't want any 'axes' to be plotted

Instead of using any kind of built-in 'axis' options, I created a couple of lines (pl1 and pl2) and some text (pl3 and pl4). The combination of all of these looks like a pair of 'axes', with some 'tickmarks'.

The advantage(?) of doing it this way is that I can specify exactly where the lines/text occur and how they appear, because they aren't 'axes', just a couple of lines and some text

@schapplm 

using  " manual derivation", merely using Maple for your "symbolic computation" from within Matlab.

Read the help page at ?Maple Toolbox Installation

The Maple symbolic toolbox which then becomes available from within Matlab is not "everything" which is available in "stand-alone" Maple. However, as well as basic algebra, you can do symbolic differentiation, symbolic integration, solve ODEs with dsolve(), symbolic Fourier and Laplace transforms, etc, etc. So you can do a lot from within the Matlab environment.

You can only do this if the the Matlab-Maple link was correctly, which is normally done during the Maple installation process. A simple way to check is to start Matlab, access its help, and check the contents of the left-hand pane, which should have Maple Toolbox listed under the Supplemental Software.

######################################################################

In the spirit of completeness, I should point out that using the with(Matlab) package in Maple, it is als possible to use the Matlab engine from within Maple, although I rarely/ever work this way around

@Muhammad Usman 

f:=exp(eta*k2)*x^2*y^3:
algsubs( exp(eta*k2)=Z^k2, f);

@nm 

The help for the Mathematica command FunctionDomain[], is

FunctionDomain[ f, x ,dom]
considers f to be a function with arguments and values in the domain dom

with the clarification later on the help page

If dom is Reals then all variables, parameters, constants, and function values are restricted to be real.

So for your example sqrt(x)*log(y) consider the argument values, x=-4, y=1, from which we can infer

1. x is real
2. y is real
3. f=sqrt(-4)*log(1)=2*I*0=0 is real

Thus the answer given by the Mathematica command

is wrong, since it insists on x>=0.

Now (possibly) the help for Mathematica command, should state that the results of all intermediate calculations/simplifications are also required to be real???

In the spirit of a fair comparison, the closest one can probably get to this Mathematica command in Maple is to use the RealDomain() package, which would give the attached

Download isReal.mw

I don't have a problem with the first solution returned by either of the above examples, since ln(1)=0, and sqrt(x) is defined for any value of 'x', so 0*sqrt(x)=0 always.

However I do have a problem with the second solution given in both examples, where 'y' is arbitrary. If 'y' is negative, then ln(y) is undefined and 0*undefined really ought to return undefined. Thus I think that the second solution in both cases should be {x=0, y>0}, so that ln(y) is never undefined.

So (rather depressingly) both Maple and Mathematica *seem* to return (different) incorrect answers, for the same trivial problem:-(

@farah adanan 

Attached is the solution to the problem posted in your latest worksheet. I tidied things up a little.

Download odeProb.mw

@Preben Alsholm 

OS issue?? I'm running 64-bit Win7, what are you running?

With this OS, the CUDA help page executes with no errors in

Maple 18
Maple 2015.2
Maple 2016.2
Maple 2017.3

as well as Maple 2018.1, which was the only Maple version I used for my earlier comments

If, I run the following commands, I get some information about my CUDA capabilities

CUDA:-ComputeLevel(id=0); # not sure what this means, except "bigger is better"
                               3.

CUDA:-HasDoubleSupport(id=0); # GPU supports double precision
                              true

CUDA:-Properties(); # A lot of info I don't really understand!
[TABLE(["Memory Pitch" = 2147483647, "Major" = 3,

  "Max Grid Size" = [2147483647, 65535, 65535],

  "Resisters Per Block" = 65536,

  "Max Threads Dimensions" = [1024, 1024, 64], "Minor" = 0,

  "Clock Rate" = 1058500, "Max Threads Per Block" = 1024,

  "ID" = 0, "Total Constant Memory" = 65536,

  "Total Global Memory" = 2147483648, "MultiProcessor Count" = 8,

  "Texture Alignment" = 512, "Warp Size" = 32,

  "Shared Memory Per Block" = 49152, "Name" = "GeForce GTX 680",

  "Kernel Exec Timeout Enabled" = true, "Device Overlap" = 1])]

Force the 'seed', before each call to Sample() - in which case the same sample set will be produced. However the moment you change the 'distribution parameter' which the Optimisation process will do, then a new set of samples will be generated. See the attached

Download rand2.mw

Conclusion: head, brickWall; stop using the former to hit the latter

@Bosco Emmanuel 

Simple practice beats "perception". Contemplate the following - and consider what you "expected"

Download rand.mw

which will find a solution, when no solution exists

Removing lots of useless cr*p from your worksheet, and restricting the number of calculations in the outer loop to 100 (rather than 1000, cos I can't be bothered to wait that long). I get what is shown in the attached. Rather obviously, the fsolve() command occasionally fails.

I have netiher the time nor the interest to evaluate each of these failures individually, but I wil discuss the first failure, for educational purposes. (I assume all of the othere are something more or less similar - you check them if you have the energy)

The first failure is R[16}, which is the solution of the expression

fsolve(3*exp(.2490248922/R)-exp(.8056958715/R) = 2, R, 0 .. infinity)

Now if you can't see why this equation has no solution, then I suppose you could try plotting the expression. However a braindead examination of the expression shows that as R tends to infinity, the expression tends to

3*exp(.2490248922/infinity)-exp(.8056958715/infinity), which tends to

3*exp(0)-exp(0) which tends to

3-1=2

So the only "solution" is R=infinity. However fsolve() is a mere numerical process, and 'infinity' is not a solution whihc can be obtained by any numerical means:-(

A fast 'eyeball' check shows that an identical argument can be applied to the failures at R[21], R[37], R[48], R[50], and R[58]. See hte attached

fsolveProb.mw

@Bosco Emmanuel 
as I have already observed, during a single iteration of the optimisation process, the Optimize package will make multiple calls to the function lc(), with different values of the parameters. Anytime that the values of the parameters p[1], p[2], [3] change then you will be defining a "new" distribution for the random numbers - and hence a new set of values.

"Freezing the seed" *ought* to return the same set of samples from a parameterized distribution, provided the parameter(s) used to define the distribution stay(s) the same. Since the parameters p[1], p[2], p[3] vary (in general) with each call to lc() within a single iteration, the distributions will be redefined, and new sample sets generated.

1. I can't see any way to avoid this behaviour when the parameters defining the r.v. distributions are also the parameters for which you are optimizing.
2. Hence I don't see any way that such an optimzation process can be "guaranteed" to work
3. Hence my questions about the nature of the underlying problem
4. Hence my suggestion about investigating alternatives, such as correlation

In order to fsolve(sys), it is necessary that 'sys' evaluates to something meaningful. However in your code 'sys' is defined in terms of some table entries 'eq[i,j]' whihc are nowhere defined in your worksheet.

I assume that you actually mean what is shown in the attached

(there are more efficient ways to implement this!)

Download CN.mw

@ianmccr 

1. Can you define (local) procedures withiin a module, which are available to other (exported) procedures within the module? YES
2. Can you define a sub-module within a module whose exports are available to other (exported) procedures within the parent module, but not to the 'outside world' YES
3. Can you use a procedure defined outside a module, in procedures defined within the module. Well, you can, but you shouldn't

The first two above are the "most common" situations which you might want to use.

Don't use the third - the programming purity police will visit and smash up your keyboard: it violates the whole concept of 'encapsulation' etc, which is (probably) the main point of using modules in the first place.

The attached "toy" example shows how all of the above situations can be written

Download toyModule.mw

@Carl Love 

I know that you know this stuff, so this is for the benefit of the OP.

The phrase, evaluating a procedure and executing it, is clouding your thinking There are only two stages whihc yu should consider: 'defining' a procedure, and 'executing' it.

'Defining' a procedure just means incorporating the code for the procedure which may, or may not,  ever be executed (with appropriate arguments) at some point in an application.

A procedure definition is anything which exists in the form proc(possiblySomeArguments).....end proc, and which may (or may not) be assigned to a name. So

fred:=proc(SomeArguments).....end proc;

defines a procedure, but actually doesn't achieve very much. Action only happens when the procedure is called, with

fred(theArguments)

in which case the code in the procedure will be executed with the supplied arguments and (hopefully) return a meaningful answer.

A procedure doesn't need to be assigned to a 'name', but would usually be assigned to something which makes calling it convenient. So defining it and assigning it to an entry in a table with

          entry[someName]:= proc(SomeArguments).....end proc;

is fine. Then it can be called (ie executed) with

entry[someName](theArguments)

You don't even have to assign a procedure to anything if you don't want do. The code

anAnswer:=proc(SomeArguments).....end proc(theArguments)

defines a procedure, executes it with 'theArguments' and assigns the return value to 'anAnswer'. However since the procedure has not been assigned to anything, then any subsequent use of the same procedure will require the same calling sequence - so it is generally a better idea to assign the proc(SomeArguments).....end proc to something or other: if nothing else it saves typing!

@Bosco Emmanuel 

Firstly why should it call "lc" 117 times for one iteration? I thought "lc" will be called by the Minimize only when the values of the parameters are changed. Do you mean to say that "lc" will be called multiple times for the same set of values of the parameters? I do not quite understand why it should do this.

When an optimisation evaluates the target function for a given set of parameters, this gives no indication of how the parameters should be "adjusted" to improve things. Consider a "toy" example with two parameters, f(p1, p2), then one can imagine the optimisation routine performing the simple process for one iteration

f(p1, p2) # reference value
f(p1+delta, p2) # shift p1 by +delta, is value greater than or less than reference?
f(p1-delta, p2) # shift p1 by -delta, is value greater than or less than reference?
f(p1, delta-p2) # shift p2 by +delta, is value greater than or less than reference?
f(p1, delta+p2) # shift p2 by -delta, is value greater than or less than reference?

ie five function evaluations. You might think this provides sufficient information to determine which "directions" to shift which parameters, but it leaves a number of questions unanswered: such as

1. How do you pick a value for the increment delta? Maybe you should try two or three?
2. Why would you necessarily pick the same value(s) of the increment delta for different parameters?
3. Are you certain that if f(p1-delta1, p2) is an improvement and f(p1, p2+delta2) is also an improvement, that f(p1-delta1, p2+delta2) would be better than either?
4. If you have more than two parameters, then the situation described in (3) above, starts to give a lot of combinatiions which you might want to check

So how many function evaluations do you think might be necessary per iteration??? My previous comment was based on the observation (for your problem) that the impact of changing the set of random variables for each function evaluation may mask the effect of changing the underlying parameters, so the optimisation process described above may give inconsistent results!!!

######################################################

Be very careful about describing one Optimization routine as being "better" or "more robust" than any other. There is no Otimization process on the planet which can absolutely guarantee to find a global optimum for anything other than convex functions. Some (may) be better than others for certain types of problems, but none of them is perfect!

If you took a poll on this site, then I am sure that you will find that the DirectSearch() package is (generally speaking) more robust than the in-built Optimization() package

#######################################################

The description of your fundamental problem does not *seem* to justify the use of random variables during the optimisation process.

1. You have a 'synthetic' function depending on 6 parameters - ie S(p1,p2,p3,p4,p5,p6)
2. It *seems* as if you want to compute the (possibly weighted, almost certainly wrapped, aka circular) correlation function between this synthetic function and actual patient data
3. Then use Optimization() to change the parameters p1,p2,p3,p4,p5,p6 in order to maximize the correlation function
4. No need for random variable generation anywhere????
5. I may be wrong!