Download comment.mw

"Man is the measure of all things: of those that are, that they are; and of those that are not, that they are not."

@Ronan 

Download evat_at.mw

@MAXR A duplicate of this has been deleted.

@Paras31 In order for beta to be workable as an Explore parameter here it also needs to be one of the dsolve,numeric parameters.

Here's a run at using odeplot (which can produce a decent curve more efficiently here than the plot command) inside Explore.

In order to get nice smooth, continuous behavior for, say, the beta Slider then overhead time cost of each PlotProc call must be kept low. I suspect that odeplot is the best bet here, especially if a decent curve is also wanted. You might experiment with its options.

I put the continous=false option on the Explore Sliders for x0,y0,z0 since when more than one of them is high (>10, or whatever) then odeplot can run amok and freeze everything. This option makes the exploration update -- and produce a single new frame -- only when the x0|y0|z0 Sliders stop sliding.

math_model_eco-epidemiology_v2_ac.mw

nb. Using odeplot instead of plot makes this variant of PlotProc much faster. When you use odeplot then it knows how to effectively&efficiently utilize the sols numeric solver returned by dsolve,numeric. In contrast, when you just utilize the plot command then it doesn't know how best to use that sols numeric solver returned by dsolve. All the plot command knows is that it's been passed some black-box proc(s) to use.

@Paras31 The odeplot command is not advanced Maple. It's a step above the basics. Actually, as a single command using odeplot might even be more basic that what you showed as extracting from the dsolve return.

(It just happens that odeplot serve both basic needs as well as provide some sophisticated options, etc.)

Sometimes it can serve well to show people two or three ways of doing something: the basic and naive way, the next step up, and the best way that both they and you understand.

Now that you have shown your students the most basic of approaches, why not show them some better methodology, some of which you have been shown (a few times) in other threads in the forum?

You could odeplot, which can be more versatile and efficient. That is not very advanced usage.

You could use the parameters option for dsolve, to better vary the value of beta (and efficiently construct an animation, say).

It seems as if your attached .mw file might actually be just a saved instance of that start-up worksheet.

@salim-barzani Please put your related followups to this here, instead of spawning wholly separate new Question threads for such.

@Anthrazit You just wrote, "the $include command", but it's not a Maple command. From the second bullet point in the Description of the $include Help-page:

"The preprocessor directives are not part of the Maple language and therefore cannot be entered at the Maple command prompt. However, they can be embedded within Maple files and are preprocessed during the loading or reading of the file."

If you want text file A.mpl to include source straight from text file B.mpl (both stored on directly in your OS file-system, not as workbook attachments) then you could have A.mpl contain a line like,

$include "B.mpl"

You can optionally use <> brackets. You can optionally use a relative path to B.mpl within the quotes. You can optionally adjust the include-path (search path) as mentioned in that Help-page. Note that the $ symbol is the first character in the line.

You can name the text files as you choose. I use an unofficial convention of filename extensions:
    file.mpl for the parent file that I will read
    file.mm for module members
    file.mi for definitions that I want to use in multiple places or which don't contain a procedure or module defn.

Another example,

  A := module()
    export B;
    local C;

$include "B.mm"
$include "C.mm"
  end module;

and,

B := proc(x) C(x); end proc;

and

C := proc(x) sin(x); end proc;

Then I can read in the source to that module by issuing the Maple command in either the CLI (CommandLine Interface) or the Maple Java GUI,

read "A.mpl"

I could first adjust the include-path using a suitable, kernelopts=(includepath="..."): call, or by passing some "-I" option to the OS command which launches my Maple session.

The other preprocessor directive that I used next most often is $define (and $undef) which lets me set long names (eg. module names, etc). That helps me,
  1) keep my sources terser and more legible
  2) make it easier to change such names -- set in a more centralized manner

@Anthrazit Sorry. I added a basic template to my previous Reply.

I don't use the Maple Code Editor. I use a good editor in my OS.

I use the stand-alone mint utility in the Maple "bin" directory to check my source code. (It's much more flexible than the M.C.E. for syntax checking, and historically far less buggy.)

The storage and build process I've outlined is essentially how the module packages in Maple's own maple.mla Library are stored as source and built (for over 25 years now).

@Anthrazit There are other ways to get similar development functionality. (Recall that I had to guess as to what your actual objectives might be.)

My own strong preference is to use separate text files and the $include directive, which allows me to have a separate file for every local and export procedure of my module(s).

The basic structure of the module's top source file is,

M := module()
  export a,b,c;
  local f;
$include <path_to_a_source>
$include <path_to_b_source>
$include <path_to_c_source>​​​​​​​
$include <path_to_f_source>
  end module.

I can then call read on only that parent source, and then savelib or (my preference) LibraryTools:-Save. There are no top-level assignment side-effects for the procedures.

I would never store my precious plaintext source files only in something as fragile as a Maple workbook, and I'd never want to have two running duplicate locations for it all. I keep the individual plaintext files in a structured directory hierarchy. That also allows the huge benefit of being able to use a standard version control system to track my code revisions.

By using $include andactual text files I have no need for the side effect of creating a temporary top-level procedure like in your "lib/b", and no need for using ModuleLoad to copy that, and no protection issues. I also have the choice of running the Maple "build" commands in either a worksheet or a plaintext .mpl Maple file.

To address your bullet queries:

• that is one way to make it work
• that is one way to make it work
• naturally, you can change the proc defn in "b" source, and rebuild.

@nm The parts that you see as (blue) 2D Input are so-called (Equation) Label References, and those are how Equation Label inputs/references appear if the GUI option is not set to render them as labels, ie. black ordinal within round brackets.

It's a flaw/bug that those cannot be directly copy&pasted properly (ie. to another worksheet, etc), even if the opened sheet is first re-executed.

@Paras31 I was curious they differ in a shorter time frame.

@Paras31 Do the contrary solutions (of this dynamical system that can exhibit chaotic behavior) start off similarly, and then diverge?

What solver is used for each, and what working precision, and what target accuracy?

@vv It can in fact still work, with Digits=15 at the top level and method=_d01akc (for oscillating integrand).

The various forced working precisions (the wrapping 'evalf[..]', digits=..., and even the evalf@Int tolerance epsilon) can be adjusted accordingly.

For example, Test_Int_fsolve_2.mw though I have not attemoted performance optimization because the target accuracy is as yet unstated.

In a severe case the integrand can also be unapplied with its own higher evalf[d] if necessary.

Note that your dsolve,numeric approach did not specify a final error tolerance, and the attained accuracy is as yet unshown. I'm not saying that it's less/more inaccurate, but I am saying that such would need to be established -- on both results -- before a thorough comparison is proper. (Some of the later entries in eqList are tougher than others...)

Note also that the OP has not (as yet) specified how much accuracy in the final results is desired.