@Joe Riel 

we must be using different Maple or I do not understand what you meant. If I use eq:=_self:-A^2;  then the warning comes back., If I use eq:= A^2;  then the warning goes away, yes. But you are saying warning should not show up in both cases?

I tried also commenting out the USE_SELF inside the foo proc, but it made no difference.

kernelopts('assertlevel'=2):

$ifdef MINTONLY
$define USE_SELF _self;
$else
$define USE_SELF
$endif


A_class:=module()
option object;
local A :: integer :=0;
export
    ModuleCopy :: static := proc( _self, proto :: A_class,m::integer:= proto:-A)
        USE_SELF
        _self:-A := m; #initialize object private variable
end proc;

export foo :: static := proc(_self,$)
local eq;
    USE_SELF;
    eq := _self:-A^2;
    return eq;
end proc;

end module:


a := Object(A_class, 23):
foo(a);

Now

>"C:\Program Files\Maple 2022\bin.X86_64_WINDOWS\mint.exe" -i 2 A.mpl

Module A_class() on lines 10 to 26
  These local variables were assigned a value, but otherwise unused:
      A::integer

What exactly did you mean then by it is independent of whether you use _self:-A or A in the code.

Thanks

@Joe Riel 

Thanks. But I do not think I will use this workaround. The reason is, I actually prefer to write  inside a proc

          eq :=  _self:-A

vs. just

          eq :=  A

Why? Because when looking at the code, I can see that A in the first case is a variable of the object.

While in the second case, I have no idea if A is a local variable to the proc itself, or variable for the object itself which this proc is function memeber of, or even if A is global variable.

So   _self:-A is like self documenting the code. It tells the reader where A lives and this is useful for me, otherwise all variables will now look the same in terms of reference to them. I would not know looking at the code, where A came from without having each time to go look around all the code.Rigth now, if there is no _self:- then I know the variable is local to the proc right away without having to check.

I think mint should be fixed instead.

But thanks again for  the suggestion.

@Joe Riel 

The A:- are not required in foo.  Without them, mint is clean. 

I am afraid this did not solve the problem.  Yes mint is clean now. but code now gives a errors when I run it using

interface(warnlevel=4);
kernelopts('assertlevel'=2):

Which I have on all the time.  I run all my code with the above setting.

So  removing A:- made mint clean, but code does not run any more. So it is either mint is wrong, or kernelopts('assertlevel'=2): is wrong.

So I had to put these all back and live with mint warnings.

Here is worksheet so you can see for your self. It looks like mint needs a major update by Maplesoft.
 

Download mint_msg_oct_18_2022.mw

@Joe Riel 

Thanks. Do you know how to get rid of

These local variables were assigned a value, but otherwise unused

This happens like this: I have module which is object. Have local/private variables in it. In this example below, the variable is A::integer. In the constructor, this variable in initialized to a value.

Later on, in one of the object methods, this variable is accessed/read as _self:-A, and used in an equation that gets returned back to caller.

But maple mint keeps says the variable A::integer was not used.  What do I need to change to make such warnings go away? Almost every local variable I have in the object has such a warning message on it.

I think mint does not know that _self:-A refer to A:: above in the module itself?.  Because clearly A is used. It is used to make eq

The code all runs fine, been running fine for long time, but would like to get rid of these mint messages.  I do not want to get into preprocessor conditionals as I do not use them and want to keep things simple for now. I just like to understand first why Maple thinks the object variable A is not being used, that is all. Is there a way to modiy the code to get rid of this message without using mint specific preprocessor conditionals?

Download mint_msg_oct_17_2022.mw

@Carl Love 

Surely I've read it a few hundred times.

Have you thought of writing a book on Maple that  concetrates on the type system? There is no such book at all on Maple. None of the books I have on Maple go into any depth on how to use these commands and I have many. It will be a best seller.

Examples showing when to use specfunc(f) vs. specfunc(type,f) vs. anyfunc(type*) vs. specop(operator) vs. specop(type,operator) vs. anyop(type*) vs. patlist[reverse](type,type*) and so on and on.

The current help page have no real examples, (the few at the end of the page are so trivial and do not touch 99% of what is on the page above). no explantion, nothing any where. The little bullet points below, are not helpful and hard to follow and so dense.

People learn by examples not by reading something that reads as this

Thus, type(f, typefunc(t, T)) is equivalent to the logical conjunction type(f, function) and type([op(0,f)], [T]) and type([op(f)], list(t)).

That page full of commands with nothing to help the user learn when and how to use these things. Compare the help pages to Mathematica, where each page it is full of examples after examples covering every possible option and sub option.

May be consider talking to Maplesoft about wriitng such a book? May be they could sponser this effort? 

I bet there are only 5 people living who understand how to use these commands in Maple. I would be the first to buy this book.

@Carl Love 

Yes, thanks I saw your eariler reply on the other thread on solve. I was myself thinking of doing that also, make my_solve() function, as exported function in my common module, and call that instead of solve(), and inside it, do and prep work needed as you showed before calling Maple's solve or PDEtoold:-Solve as the case may be,

@Carl Love 

I see. I thought solve will use the assumption to "simplify" before solving. My assumption was wrong then. So one needs to simplify first, and then call solve.

In this case, this is a workaround without using global assumptions

restart:
eq:=sqrt(exp(y))=tanh(x);
solve(  simplify(eq,assume=[y::real,x>0]),y)

What this means is that some of these assumptions passed to solve go ignored as this example shows. Compare that to Mathematica, where Solve used the assumption given without the user doing an explicit simplify.

So I need now to go change all my code which uses   solve(something,var) assuming.... to solve(  simplify(something,assume=[...]),  var)  or may be

          solve(  simplify(something,assume=[...]),  var)  assuming....

Just to be sure the assumptions are "used".

As I do not want to use global assumption at the top of the program. This will break things for me.

@Thomas Richard 

Could you elaborate more why

assume(y::real,x>0);
eq:=sqrt(exp(y))=tanh(x);
solve(eq,y);

works but

restart:
eq:=sqrt(exp(y))=tanh(x);
solve(eq,y) assuming y::real,x>0

did not?

Did you mean the second one should have worked but there is a bug somewhere that caused the assumption not to be seen by some internal routine? I do not use global assumptions.  I thought it was not recommended to do this in a program as it can have affects everywhere.

@Carl Love 

Ok. But then to remove the message, I have to write foo like this

foo:=proc(x)
local a:=1,la;
   patmatch(x,a*x,'la');   
   map(z->assign(z),la);
end proc;

and now it does not complain about anything. But I thought one should declare every symbol used inside a proc. And since I am "using" z,  I made it local to foo. There is no other place to declare it. 

So I guess the lesson of the day, is that when using symbol for map type operation like the above, that symbol should not be declared at all. So I have to change all my code now to do this to get rid of these messages from mint.

@vv 

Thanks. I did not realize it can be that simple. I put it inside the module actually, like this, since many procs() inside the module use this, so I did not want to duplicate this in each proc. This way, all proc inside the A module will see it is global.

A:=module()   
   global main_module;
   export boo:=proc()
      local o;
      o:=Object(main_module:-person_type);
      o:-foo();
   end proc;
end module;

Now the warning is gone.

@Joe Riel 

"Am working on updating the github site for mdcs, will post a message to MaplePrimes when it is ready."

Just checking if your emacs interface to the debugger have been updated to try it?

I am getting tired of using Maple's build-in debugger since the interface is very hard to use (unable to see listing as I step in the code)

@acer 

I meant exactly what select help page says

The select function selects the operands of the expression expr which satisfy the Boolean-valued procedure fcn,

may be I should not added more words myself. but I said clearly I am using select and has.

So for your examples

expr:= sin( f( diff(y(x),x) ) + Q );
select(has,expr,diff(y(x),x))

sin(f(diff(y(x), x)) + Q)

And

expr:= 3*diff(y(x),x);
select(has,expr,diff(y(x),x))

diff(y(x), x)

The only special case is when expr=diff(y(x),x) and this causes a problem. i.e. I expected that

select(has,diff(y(x),x),diff(y(x),x))

To return diff(y(x),x) and not diff(). but I know now why it does not because the way select works.

So I ended up just using an extra if, like this

expr:=diff(y(x),x);
if expr=diff(y(x),x) then
   print("nothing to select, expr is diff(y(x),x)");
else
   select(has,expr,diff(y(x),x));
fi;

And this solved the issue of the special case. Not a big deal, but was wondering if select has some option build in to handle this special case. I tried flatten and other options.

But I am ok now.

the problem in Maple is that there does not seem to be an overall guiding principle to help one figure which one of the 100's commands and comination of these are needed to simplify something.

On top of this, imagine doing this inside a program, i.e. without looking at the screen and not knowing what kind of expression one has each time.

So I find myself trying things until something work. 

Why did not simplify just work on its own? Why not with the size option? Why is combine needed in this case and not other cases?

Compare to Mathematica, where a one command Simplify is all what is needed for 95% of the cases. And if that does not work, there is another command called FullSimplify which will try even harder.

No need for the user to try 200 different commands and combinations of these each time to simplify something like with Maple.

I wish Maple would work on improving its simplification. Make new command called full_simplify() and hide all these things inside it so the user does not have to figure it out each time.

@nm 

"I still do not know why odetest verifies the solution one time but not the second time when this code is added. But that might be separate problem in odetest?"

I will make separate question on odetest as it is not related to this issue with this fix.

@Carl Love 

I found a big problem with the above.

If I just put the code you show at the top of the worksheet, then call odetest on some ode, it does not verify it. OK. But repeating the same odetest call, now it does verify the solution.

So odetest fails only first time, but not the second time.  This is all when I have your code added at the top.

If I remove your code, then now odetest fail to verify the ode each time I call it. No matter how many times.

It seems the code changes something internal in Maple. Why would odetest fail first time, but says the solution is correct the second time it is called without changing anything??

I found this when I was doing a test and found I am getting different result depending on when something is called.

Attached worksheet

Download cancel_added_bug_in_odetest.mw

Now compare what happens when I do not use your code at all. Now each time odetest is called, it returns unverified. Not just the first time.

So now I am not sure what is the correct result. is it verified or not.

Download cancel_added_bug_in_odetest_version_2.mw

But since the original reason for this code seem not to be needed any more, as in Maple 2022.1 this code does not generate an error any more

restart;
interface(warnlevel=4);
kernelopts('assertlevel'=2):
expr:=exp(x)*sin(y)-3*x^2+(exp(x)*cos(y)+1/3/y^(2/3))*Z = 0;
solve(expr,y);

So I think I will just remove all the code using SolveTools:-CancelInverses from the worksheet now.

I still do not know why odetest verifies the solution one time but not the second time when this code is added. But that might be separate problem in odetest?