tomleslie

13876 Reputation

20 Badges

15 years, 174 days

MaplePrimes Activity


These are replies submitted by tomleslie

Consider the manual entry (my highlighting)

Given either a system of two first order autonomous differential equations, or a single first order differential equation, dfieldplot produces a direction field plot. There can be only one independent variable.

In your first use of DETools[dfieldplot}, ie

dfieldplot([eq2,eq3,eq4],[t,x],t=0..5,a=-5..5,b=-5..5,c=-5..5);

You have three equations, so even if you correct the syntax for the command it will not work

In your second use of DETools[dfieldplot}, ie

dfieldplot([eq2,eq3],[t,x],t=0..5,a=-5..5,b=-5..5);

 

You have two equations, but three dependent variables a(t), b(t), c(t) - which cannot be solved and therefore cannot be plotted (even if the syntax of the command was correct

In your third use of DETools[dfieldplot}, ie

dfieldplot([eq2a,eq3a], [a(t), b(t)], t = -5 .. 5, a = -5 .. 5, b = -5 .. 5, arrows = SLIM, color = black, dirfield = [10, 10]);

The syntax for the command is now correct, and you have two equations in two dependent variables - however the existence of the term exp(t) in these equations means that they are not autonomous (see the DEtools[autonomous] help page). So again a dfieldplot cannot be obtained

Need to think again about what is possible :-(

Which Maple version are you running - you just need to go to the 'help' toolbar entry and help->about Maple will tell you what  the version is. How hard can this be?

As I have already stated Maple 18.02 runs on Win7 64-bit: this I can check right now.

I used to run Maple 18.0 on Win7 64-bit and it worked with no problems

I suppose there is an outside chance that this is a Win8, 64-bit issue, although since no-one on this site seems to be running Win8, this might be difficult to prove either way.

The package RAEEM which you specify comprises two files: a Maple worksheet (.mws) and a module (.mpl) referenced from this worksheet). If I correct the worksheet to point its 'read' statement to the module, then everything seems to execute correctly in Maple 18.02, with a  few warnings.

However a brief examination of this package suggest that it is rather pointless. It consists of

  1. Define a differential equation
  2. Define a solution (note - not solve for a solution, just define one)
  3. Demonstrate that the defined solution satisfies the defined differential equation by simple substitution
  4. Go back to (1) above with a slightly different pde
  5. Like I said - not very useful

@Honigmelone 
You state

q1 := b(t)*(diff(c(t), t))*(diff(a(t), t))+a(t)*(diff(b(t), t));
subs(b(t)=0,convert(q1,D));
q1:=convert(%,diff);

Now try substituting b(t)=0 in your final expression, as in

q1 := b(t)*(diff(c(t), t))*(diff(a(t), t))+a(t)*(diff(b(t), t));
subs(b(t)=0,convert(q1,D));
q1:=convert(%,diff);
eval( q1, b(t)=0);

which of course will return 0. Perhaps you want b(t)=0 sometimes and bt !=0 other times????

With b(t)=0, diff(b(t),t) is identically zero! Always! If you do not believe this, come with a function which is zero for all values of its argument, and yet has  a non-zero derivative

@mmb1aes 

Now go do your homework, like a good little boy/girl

This works in Maple 18.02, Build ID 991181 and Maple 2015.2, Build ID 1097895 on 64-bit Win7.

Which precise version doesn't work for you?

When you make the assertion b(t)=0, then you are stating that the function b() is zero for all values of the argument (in this case 't'). So if you graph this function, you will get the 't'-axis. Differentiating such a function wrt 't' gives zero. Therefore your statement

"in fact b(t) = 0 but diff(b(t), t) != 0"

is contradiictory, because if b(t)=0, then diff(b(t),t)=0.

So Kitonum's solution is correct

 

Forget other packages, forget anything you are doing with march(), forget currentdir(), forget all the irrelevant stuff: start a clean Maple session and type

read("E:/Maple work/General Maple Workout/TWS.mpl");

If you get an error then I can only think of three possibilities

  1. The specified file does not exist at the specified location: check it!
  2. Maple does not have 'access' privileges for the file: most likely the file requires 'administrator' privileges for 'read' and you are running Maple as a 'User'. Obvious solution is to run Maple as 'administrator'. Alternative is to ensure that 'Users' have access to the file by changing its attributes. The precise method for doing this depends on the version of windows you are running
  3. The file is corrupt in some way. Since it has a 'mpl' extension, then it should be a simple text file which can be read in your favourite editor - eg NotePad, whatever. Can you read this file in an editor? Note that if you have 'User' privilege and the file requires 'administrator' privilege for read, then you won't be able to open it in an editor. Again the only thing you can do in this situation is change the access privileges on the file, or run you editor with 'administrator' privileges

Well first of all you type

"rearrangement method" into Google, which wil return all sorts of references, some of including pseudocode which you can translate into Maple

The you type Aitken's method into the same search engine - actually, save yourself some time: the Wikipedia article on Aitken's method is both informative, and includes pseudocode - which you can translate.

Alternatively you can provide specific information on your difficulty:

perhaps you are unable to read simple explanations on the web;

perhaps you cannot translate simple pseudocode into a specific target language

perhaps you are just too lazy and hope someone will do it for you

The first thing I do when I see something like this is to strip it down to how I would write  it, and check whether that works. So for this operation, I would write

foo := proc( ctx::list)
                   bar(ctx)
          end proc:
bar := proc( ctx::list)
                   nops(ctx)
          end proc:

foo([a,b,c]);

which returns 3, as I would expect.

Now I have the problem(s),

  1. Why did your code do what it did?
  2. Why didn't it throw a syntax error somewhere - because looking at your code, it contains "constructs" which are "unusual", and I would have expected one/some of them to break Maple somewhere!

Actually diagnosing why you got your answer could take a while - so I'd prefer it if you could figure out why the above works. If you wnat the first stage in the diagnostic process, then consider your 'function call'.

foo(ctx = [a,b,c])

This means that the procedure foo has an equation as its argument. And you wanted foo(() to have an equation as its argument, rather than a simple list - right?? (If so why?).

To go further I'd have to work out stuff about what happens to this equation, but to be honest, this seems rather irrelevant - why not just stick with the simple, basic syntax I provided above - or alternatively give me an explanation of why you are writing the weird stuff?

 

 

 

 

Let's make this really simple: under what conditions can you perform a series expansion of the HankelH1 function??

According to my investigations, only if the first parameter is assigned a numeric value. So for example

series(HankelH1(0.5,x), x);will produce something useful. So also will

series(1/HankelH1(0.5,x), x);

However the moment I set the first argument in the HankelH1 function to a non-numeric, then I am unabe to get a series expression. Doesn't matter whether I use series() or Multiseries(); I cannot produce a series expression when the first argument i anything other than a numeric. And yes I have tried restricting the first argument to the range [0..1] while laving it unspecified, as in

assume(par>0 and par <1):
series(HankelH1(par,x), x);

which just errors.

I think you are on a loser with this one

The 'caption' and 'title' options are available for 2D-plots, but so also is 'legend'. If 'legend' is considered a useful option for 2D plots (along with 'caption' and 'title'), then why is is not available for 3D plots???

Anyone with a good answer for this could probably also inform me why the 'size' option is not avaliable for 3D plots

@Markiyan Hirnyk 

Some problem with timing. When I started to post my comment, no other comments/answers were showing. Now,  sometimes when I post here, I pause and think. So even only "relatively short" comments, I may take 15mins or so. You answer (which I like) arrived between the time I started, and the time I finished

Take a chill pill

I would never deliberatley have posted such a "comment" as an "answer". I have to be really, really, sure before I post anything as an answer. Could I have hit the wrong button - possibly, but I will never know.

Take another chill pill

You do not really have to make the assumption that t>0.

You just have to realise that the integration range means that s=t, at one endpoint of the integration. Doesn't really matter if t is positive, negative, real or complex, as soon as s=t, the demominator is 0, the integrand is infinite and so is the integral

The only "extra" information which Maple is providing is that your integral may be +∞ or -∞, depending on the sign of t

@arussell 

Seems like my previous post was based on a misunderstanding. As I see it now, there are two issues

  1. Controlling the size of the plot window. This is easy for 2D plots, because there is a 'size' option. I finding being able to set the size of the plot window to (say) 1/2 the width of the worksheet, quite useful. However, for reasons which escape me, there is noequivalent  'size' option for 3D plots.  I have never undertood this, and every once in a while, I try to find a workaround - but so far, I have not succeeded :-(
  2. Even if one could set the size of the plot window, I do not think that there is a programmatic way to 'scale' the contents of the window, to the window itself (other than using the 3D plot toolbar, or the right-click plotMenu->manipulator. I have just conducted a few experiments, and (for 3D) plots the default "efficiency" actually seems to vary quite a lot. Sometimes  there is quite a large "margin" between the actual data and the plot window, and for others there is very little "margin" - the data pretty much fills the available plot window. Playing around with this, I can find no obvious relationship, between the relative sizes of the actual plot data and the enclosing plot window. I'm tempted to say that  '3d-surface' plots seem to be "more efficient" than something like spacecurve() - although I am sure that someone could come up with a counterexample

I suspect there may be no solution to you problem :-(

If I wanted to minimise a function, then

  1. I would start with minimize() - see the help page at ?minimize. If that didn't work then
  2. I would probably try Optimization[Minimize] - see the help page at ?Optimization[Minimize], and if that didn't work, then
  3. I would probably try DirectSearch[GlobalOptima] - (assuming that you have the DirectSearch package loaded), - see the help page at ?DirectSearch[GlobalOptima], and if that didn't work,
  4. I would probably conclude that no minimum can be found for the function, because I don't think that I could do better than methods built-in to any/all of the above packages
  5. Why is none of options 1-3 above acceptable?
First 158 159 160 161 162 163 164 Last Page 160 of 207