tomleslie

13876 Reputation

20 Badges

15 years, 174 days

MaplePrimes Activity


These are replies submitted by tomleslie

You are running

Maple 18.00, X86 64 WINDOWS, Feb 10 2014, Build ID 922027

I have tried your worksheet on

Maple 18.02, X86 64 WINDOWS, Oct 20 2014, Build ID 991181 - and it works

I have difficulty believing that something as simple as matrix multiplication could be failing!

In your original post, you state that "These 2 matrices are multiplied correctly in another worksheet."

First suggestion

Close down all running Maple sessions. Using CTRL-Alt-Delete check the Windows task manager. Verify that there is no process called maplew.exe, or mserver.exe. If any of these are still running then use the "close process tree" to terminate them. Download your own worksheet F1.mw from the MaplePrimes link in your original post- don't use your local copy. Check whether the problem persists

Second Suggestion

If problem persists, add

Dimension(J_O_L1);
Dimension(q_dot);

to the end of your worksheet - the first of these should return 3,2 (ie a 3*2 matrix) and the second should return 2 (ie a 2*1 vector). This will verify the matrix dimensions and thus confirm that Maple is having a problem multiplying a 2*1 vector by a 3*2 matrix (which it obviously shouldn't!!)

 

  1. Supply the text file containing the data
  2. Specify the desired matrix structure - ie rowDimension and columnDimension
  3. Specify the data order in the input file - for example is the second entry in the input file the second entry in the first row of the desired matrix, or the second entry in the first column of the desired matrix?

Code runs with no problems in Maple18.

As returned by kernelopts(version), I tried it with

Maple 18.02, X86 64 WINDOWS, Oct 20 2014, Build ID 991181

Maybe if you could tell us exactly which verion of Maple is causing a problem, we could help??

?exportplot

AA you really have to do is figure out a format which wich is supported by both Maple and your target application.

If you want to make it look really "pretty", then play with the "style" and "numpoints" options. The following takes about 10secs to render on my machine - but it does look a lot nicer

plots:-implicitplot3d(7*x^2+22*x*y+7*y^2+14*x*z*sqrt(3)+14*y*z*sqrt(3)-5*z^2 = 180,
                              x = -50 .. 50,
                              y = -50 .. 50,
                              z = -50 .. 50,
                              axes = boxed,
                              numpoints=1000000,
                              style=surface
                            );

You claim to be using the command

grid:-seq('f[i]',[i=1,2,3,4,5,6,7,8]) and it works very well

Nonsense! If you enter this command in Maple, then you will immediately receive the error message

Error, `grid` does not evaluate to a module

So what do you mean by" it works very well"

And if you (partially) correct this command to

Grid:-seq('f[i]',[i=1,2,3,4,5,6,7,8]);

you will immediately receive the error message

Error, seq is not a command in the Grid package

And if you correct this further to

Grid:-Seq('f[i]',[i=1,2,3,4,5,6,7,8]);

you will receive the further error message

Error, (in Grid:-Seq) invalid input: Grid:-Seq expects its 2nd argument to be of type equation, but received [i = 1, 2, 3, 4, 5, 6, 7, 8]

And if you correct this still further to

Grid:-Seq('f[i]', i in [1,2,3,4,5,6,7,8]);

The this will at least be syntactically correct - although the use of square brackets [] as in f[i] means that all you will do is look up entries in a list/array/table/vector.

You really do not need any kind of parallel computation to look up entries in a list/array/table/vector.

So please explain what it is you are trying to do, and how, Becuase making statements like

"Now, i´m using " grid:-seq('f[i]',[i=1,2,3,4,5,6,7,8])" and it works very well."

is just so obviously untrue, that I cannot work out what your problem actually is!!

There is no Maple package called "shoot" (or library called "shootLib") - you must have obtained these from another source. Since no-one here has access to these packages, it is not possible to debug, but I will offer a few suggestions

  1. You have 10 equations, so you only need 10 initial/boundary conditions - you have fifteen
  2. Traditional "shooting" methods convert a boundary value problem to an initial value problem. You have 5 BCs with non-zero arguments: a shooting method might "convert" these to initial values, but since you already have ten ICs, these would either be superfluous or contradictory
  3. You appear to use the symbol '.' occasionally as a multiplication sign - don't
  4. One of you odeplot statements contains the function theta(eta). The function theta() is defined nowhere

If I ignore your BCs, and substitute values for alpha1, alpha2,..etc into ICs, then use Maple's default numerical solver, then I can solve the system up to eta~1.66 at which point Maple claims to hit a singularity. Solutions in the range eta=0..1, are easily determined.

See attached

odeProb.mw

Seriously non-expert in this kind of activity, but have you checked out the help at ?define_external - this would seem to provide pretty direct access to externally defined functions (at least in C, Fortran or Java)

Too much use of deprecated data structures/operations to be worth debugging.

Most of the code you have written might(?) be valid for Maple versions which were current ~10years ago. I don't have access to any Maple version that old, so debugging (for me) would be impossible

If you are running any "reasonably modern" Maple version - say Maple 18 or later, then I suggest you read the attached, and fix the issues which I have commented.

optimComments.mw

Whatever symbol you use for the sqare root of -1, make sure that you always have a multiplication sign: you should not ever have a "complex number Z= 2+3i", but Z= 2+3*i is fine, provided that you have used Carl's suggestion and redefined the imaginary symbol to lowercase 'i'

Safest is probably just to work with the defaults - uppercase 'I' as the imaginary symbol, and complex numbers written as Z= 2+3*I - note the multiplication symbol.

I'm not generally in favour of just killing signals by amplitude - ie if the signal is below a certain theshold, then just set it equal to zero. I grant that it can make plots look prettier

I suggest that you look at the Maple help given at

?FilteringFrequencyDomainNoise

which shows an alternative

Irrespective of the model complexity, the basic approach I suggested should always work. (So will Kitonum's - the two approaches are essentialy equivalent). When you suggest using a "more sophsticated" procedure I don't realy see why either of these methods would give any issue.

As a very general rule for a curve-fitting process, I would try to minimise the number of parameters used in the model, and maximise the number of points in the data to be fitted. Given "few" real points and "a lot" of parameters in the model, it is amazing how many models will produce a "good" fit. So generally, models with "too many" parameters are a bad idea

I'd really need to see what you mean by a "more sophsticated" procedure in order to comment further

Use the big green up-arrow in future to post code which we can copy/paste/run etc: no-one is going to retype.

One suggestion: (with a little manipulation) you *seem* to have a linear system - in which case you should probably be using LinearAlgebra:-LinearSolve. If I could manipulate your code in any way, I could verify this quite quickly.

Try using Manipulator->Pan with

plot(x^2, x=-1000..1000, numpoints=10000, view=[-10..10, -10..100])

Scaling is achieved by using Zoom In, Zoom out

There are many ways to find numerical solutions for a given problem. You should bear in mind the folowing

  1. Some only work on "simple" problems:
  2. Convergence rates (ie how many iterations are taken) can vary a lot
  3. Some work well for 1-dimensional (ie single variable) problems, and badlly on mutivariable problems
  4. Some require that the function be continuous and differentiable
  5. Probably a whole load of other criteria I have forgotten

So far as I am aware fsolve() may attempt a problem using several different methods - but it can still (occasionally?!) fail -  even when a solution exists

First 146 147 148 149 150 151 152 Last Page 148 of 207