Whenever I have local proc inside a proc, and use local variables from the outer proc inside it, Mint tells me that the variables are not used.

This can't be right. Why does it say that? Here is MWE. I have this foo.mpl file

foo := proc()

local C1;
local y,x;

    proc()
        C1:= `tools/genglobal`(_C); 
        sol:=y(x)=  C1; 
    end proc();

end proc;

We see clearly that C1 is used, also x and y are used. There can be more code using these inside the inner proc. But this is what mint says

"C:\Program Files\Maple 2024\bin.X86_64_WINDOWS\mint.exe" foo.mpl

    |\^/|      Maple 2024 Diagnostic Program
._|\|   |/|_.  Copyright (c) Maplesoft, a division of Waterloo Maple Inc. 2024
 \  MINT   /   All rights reserved. Maple is a trademark of
 <____ ____>   Waterloo Maple Inc.
      |
Procedure foo() on lines 1 to 11
  These local variables were never used:  C1, x, y

Any idea why it says these are not used?

Also, I noticed it did not warn me that variable sol is global inside the proc. i.e. I was expecting something like this 

          These names were used as global names but were not declared: sol

Which is typical message mint gives when using a name inside a proc which was not declared,

Maple 2024.2 on Windows

I have a square matrix of data points. Each point is between 0 to 0.2. I wish to plot it and set the axes to values from 0 to 1. I want the 3D plot to be plotted with a constrained scaling. The two options I have are plots:-matrixplot and plots:-surfdata. 

* matrixplot can constrain the data, but it isn't obvious how to change the axes so that it shows from 0 to 1 in both directions. 

* In surfaceplot, it is easy to adjust the axes values, but scaling=constrained does nothing. 

(I assume someone else might also appreciate the answer. So, instead of me continuing to struggle, I post here and hope someone can answer without the use of many brain cells.) 

Example attached.

Download Scaled_matrix_plot_with_axes.mw

 always i try to apply a technique like long wave limit to get my result, but this time when i do i reach zero so the author try to use another method which really i can't reach how they did and some term are dispear and some are remain , it about substituting and apply epsilon go to zero which i don't know how they apply, anyone can figure out how they reach the result, and maybe my letter and paper are not same about small and capital but it is so clear 

Download transformation.mw

If I understand right, in the following calling an exception should be raised since the return value of the matching coercion procedure is of course not of type “set”: 

restart;
foo := (x::coerce(set, (y::rtable) -> convert(y, list))) -> x:
foo(<0>);
 = 
                              [0]

Did I miss something?

I want to remove the Lambert function (LambertW) from my equation, but I don't know how. I tried using the explicit option, but it didn't work. How can I express the equation without LambertW?

Download remove.mw

How i can add lebel inside graph  like this picture for some graph , in somecoding i have but i can't how it work i want add to  my code but i can't do the same as paper did

label.mw

I never used Physics:-Setup before. But I just found that adding

            Physics:-Setup(assumingusesAssume = true):

Makes a big difference in Maple's result. The question I have is this: Since help says that default is true for the above option, then why calling this command explicitly makes a difference? Should not result be the same regadless?

Below is one example showing the difference. I have more if needed. This is taken from old question here

Another example showing adding this makes big difference in how Maple work is here

Or may be help means that calling Physics:-Setup(assumingusesAssume) is the same as if one did Physics:-Setup(assumingusesAssum=true) ?  I understood help to mean that this option is already set to true by default when starting Maple and one does not need to do anything else.

Download physics_setup_feb_28_2025.mw

Question: Should one then always add explicit call to Physics:-Setup(assumingusesAssume = true): at start of code as this seems to change Maple results.

Hi! A basic issue.

Why view=[-2 ..1, -2 ..5]  is not useful here? According to the output, only the green line meets the view settings. I want to extend the left side of these three lines appropriately (show the intersection)

Download The_intersection_parallelism_and_coincidence_of_two_straight_lines.mw

Executive summary of the problem:

Adding assuming y(x)::positive to the first odetest() call, makes the second odetest timeout. 

Removing assuming y(x)::positive from the first odetest() call, makes the second odetest return 0 very quickly.

These are two unrelated ode's and solutions but both use the same dependent function y(x).

And this is all using Physics update starting with version 1841 only.

I also found that adding Physics:-Setup(assumingusesAssume = true): which I never used before, fixes everything! Now the first odetest does not even timeout and the second odetest returns 0 even when using y(x)::positive.

What is strange by this workaround, is that help says that default for assumingusesAssume is true ! so why is adding  Physics:-Setup(assumingusesAssume = true): made difference??  May be I should ask separate question on this.

May be this will help Maplesoft find the problem.

---------------------------------------------------------------------------------------------------------------------------------------

This is a good example showing that Maple 2024 still have internal problems when it comes to handling memory cache and remember tables (or for some other reasons other than this) since it gives different results based on order.

I have two odes and solution for each.

If I do odetest(ode_1) followed by odetest(ode_2) then ode_2 test timeouts and fails to verify.

But if I do odetest(ode_2) followed by odetest(ode_1) then now ode_2 test does not timeout.

It took me many hrs to find this. I was running a test on number of ode's in a list. When I noticed if I change the order of ode's in the list, I get different result !

These are the kind of problems I've been having with Maple for years with no solution in sight.

Why would the order makes a difference? What can one do to insure there is no internal cache issues like this each time when using Maple? Why changing the order of using odetest make a difference on its result? Is there a way to tell Maple not to remember ANYTHING internally? I can not do restart in the middle of a loop.

I hope Maplesoft does not release Maple 2025 before fixing such serious problems. The order of calling Maple commands should not make them change the result they produce.

Download order_of_odetest_makes_difference_feb_25_2025.mw

Update

I also tried calling forget(all) between each call to odetest. but this had no effect. Also tried forget(all,forgetpermanent = true,reinitialize=true); and no effect. 

I also tried kernelopts(cacheclearlimit=0); and kernelopts(numcpus=1); but no change. I also tried calling gc(); before the second odetest, no effect.

So there is something else that causes this. If someone can suggest other things to try, that will be great.

Only way to get same result each time is to do restart between each call to odetest, but this is not possible to do since this is run in a loop. 

Download order_of_odetest_makes_difference_feb_25_2025_with_forgetall.mw

Update

Found the cause !

By removing Physics update form libname, then now odetest works regardless of order.

So something in Physics update is causing this. Why? Is it safe to remove Physics update from libname?  Since it has bug fixes for other things and if I remove Physics update from libname, I will lose these bug fixes.

May be this will help someone find the cause, since it is due to use Physics update for sure. I wonder which version of Physics update caused this problem.

Download order_of_odetest_makes_difference_feb_25_2025_physics_update.mw

Update

I found the Physics version which causes this problem. Version 1840 Works OK. i.e. second ode validate ok and does not timeout. Using version 1841, it fails. Same code, difference is the Physics version,

So the bug is in version 1841 of Physics.  Below two worksheet showing this.  Here is version 1841 where it fails. For me, this is serious bug. 

Download order_of_odetest_makes_difference_feb_25_2025_physics_update_1841.mw

And here is version 1840 where second ode verifies OK.

Download order_of_odetest_makes_difference_feb_25_2025_physics_update_1840.mw

Important update FEB 27, 2 AM

Just Found what causes this difference in behaviour. This is all using latest Physics update.

When  adding y(x)::positive to assuming in the first odetest call, now the second odetest timesout. Even if the second odetest call does not use y(x)::positive in its assuming.

Removing y(x)::positive from assuming on first odetest, now the second odetest returns 0 very quickly !

Everything else is the same. So the problem has to do with using y(x)::positive in assuming.

I thought that assuming added to end of a Maple command only affects the single command it is used on. But it seems assuming have global side effects that remains after the call is completed.

This only happens when using y(x)::positive. Using just assuming positive does not have such effect.

All the above happens ONLY when using latest Physics update.  And starting from V 1841.

For now, to be able to use latest Physics update, I will remove all places where I have assuming y(x)::positive and assuming y(x)::negative from my code. I added these sometime ago to help odetest verify solutions.

But this is real problem. Maple should not behave this way, and why it happens only when using Physics update starting at V 1841 is another mystery. 

Here is worksheet.
 

Download order_of_odetest_makes_difference_assuming_issue.mw

Update FEB 27, 2025 3AM

This below shows that adding Physics:-Setup(assumingusesAssume = true): fixes everything. So this tells me something changed starting Physics update V 1841 related to this.

I will add Physics:-Setup(assumingusesAssume = true): to my code. I never used this before, but since it seems to fix things, will use it. I have to do more testing.

Download order_of_odetest_makes_difference_assuming_issue_V2.mw

This first order ode diff(y(x),x)=sqrt(x*y(x)+x); generates internal dsolve exception when called with IC y(0)=1

Attached worksheet. No error if no IC is used. tracelast is shown also.

Download dsolve_internal_error_convert_feb_25_2025.mw

Hi,

I'm trying to use the Explore command to examine the effect of two parameters (mu and sigma) on the density function curve. The visualization isn't very optimal, especially with the mu parameter, and it's difficult to add options (range, color, gridlines, etc.). Any suggestions to optimize this idea? Thanks for your insights!

Q_Explore.mw

when we have ode equation we say what is type of equation then  i want solve by this method say the name of method and if possible i want to solve this equation by the method step by step too, maple can do that? also can we plot the solution or any geometricall presentation , also i have error in writing exact form of equation

Download ode-example.mw

i want try all number to my parameter for check the shape of plot there is any way for doing that?

Download control-trajectory.mw

THis IC for Abel ode is not valid and should result in no solution. But instead of returning NULL, dsolve throws internal error called Error, (in dsolve) invalid limiting point

Download internal_error_instead_of_no_solution.mw

Is there an equivalent of currentdir() which instead of returning current working directory, returns the directory of the file being read. So assume I have an ".mm" or ".mpl" file saved in some location and there is another file with a location fixed relative to this file, but not fixed in absolute location on the computer and not fixed relative with current working directory. One natural thing is to have a line in the first file that takes its current location (not current working location of the user!) and then use the fixed relative path info, and then gives the location of the second file to the user. Using currendir won't help here because current working directory is not necessarily the same as the location of the file you are reading, the first file. One may say the user is reading the first file so he knows already its location, right? Well, if the user is also the writer of the file, sure, not a problem, he can manually edit the lines of the file and put that location inside the file instead of using currentdir etc. However, if the user is not the writer and also does not know how to edit or whatever else reason, then the file should be able to inform Maple of its own location, so that's why something like currentdir() but not for the working directory, instead for currently being read file's directory is helpful. I checked FileTools package quickly and couldn't notice anything like what I want. Anyone have any clue on name of such command if exists or any other trick that does what I want (except expecting the user to do something ^_^ so all from the writer's side please ^_^).