@acer 

my question is not duplicate. Who are you to decide that my question is duplicate or not? How would you feel if I go delete one of your questions because I think something is wrong with it?

What kind of forum is this? This is ridiculous.

You can have this forum for yourself.  You made me not even think of using Maple for progmming anything.

@acer 

The question you deleted was not duplicate. 

That question was about why type checking does not work at global level vs. local level. It is better not to ask many questions in one question. That is why I made new separate question for that.

You should undelete my question.  

@Carl Love 

good point. `=` is better. fixed. Thanks.

@Carl Love 

This is very interesting, When I did as you suggested A:= Record('x'::integer= 1);, now Maple cought the mistype when doing A:-x :=1.5; inside the function (as you mentioned)

But when just doing A:= Record('x'= 1); Maple only detected the mismatch of the return type, at the end of the function.

Case 1

restart;
kernelopts(assertlevel=2):
TypeTools:-AddType(type_A, record(x::integer)):

foo:=proc( A::type_A ) ::type_A;
     A:-x :=1.5; #opps, wrong type, changes type of record now!
     return A;
end proc:

A:= Record('x'::integer= 1);
B:=foo(A):
eval(B)

Error, (in foo) assertion failed in assignment, expected integer, got 1.5
 

Case 2

restart;
kernelopts(assertlevel=2):
TypeTools:-AddType(type_A, record(x::integer)):

foo:=proc( A::type_A ) ::type_A;
     A:-x :=1.5; #opps, wrong type, changes type of record now!
     return A;
end proc:

A:= Record('x'= 1);
B:=foo(A):
eval(B)

Error, (in foo) assertion failed, foo expects its return value to be of type type_A, but computed A

So case 1 is even better, because now Maple detected the error of the assignment itself, which can happen much earlier than the function returns.  I would have expected both to be same, the call was defined to take in type_A which has x::integer in it allready.

So from now on, I will use type on the field when creating new Record variable. This will result in even more robust function.

Thanks

@Carl Love 

thanks. I looked it up and this is what I got. Made 2 examples. First one where the function checks inside the type of the record is what it expects. The second example is where the function signature is defined using the new type name. This way Maple catch the wrong call at the source.

Eample 1

restart;

TypeTools:-AddType(record_type_A, record(x::integer,y::integer,result::anything)):

foo3:=proc(input::record)
   local x,y,result;
   
   if not type(input,'record_type_A') then
      error "Wrong input type !"
   fi;

   x      := input:-x;
   y      := input:-y;
   result := x*y;

   #finished computation. Return result  
   input:-result := result;
   return input;      

end proc:

try
    input:=Record( 'x' = 4.0, 'y'=6, 'result'=NULL):
    r:=eval(foo3(input)):
    print(r:-result);
catch:
    print("opps, something went wrong");
    print(lasterror);
end try;

This gives 

                  "opps, something went wrong"

                      "Wrong input type !"

Becuase the field x is real and not integer. Changing it to  x=4 then it works.

Example 2

restart;

TypeTools:-AddType(record_type_A, record(x::integer,y::integer,result::anything)):

foo3:=proc(input::record_type_A)
   local x,y,result;

   x      := input:-x;
   y      := input:-y;
   result := x*y;

   #finished computation. Return result  
   input:-result := result;
   return input;      

end proc:

try
    input:=Record( 'x' = 4.0, 'y'=6, 'result'=NULL):
    r:=eval(foo3(input)):
    print(r:-result);
catch:
    print("opps, something went wrong");
    print(lasterror);
end try;

Now the call itself do not go through, since Maple checked the type of actual not same as formal

                  "opps, something went wrong"

"invalid input: %1 expects its %-2 argument, %3, to be of type ...

Again, here fixing x to be 4 instead of 4.0 then Maple is now happy and went ahead and made the function call.

I like this much more now. I need to see if this all will work in package. i.e. need to define these type names, so user can use them when calling the package.  I assume packages when loading can add type names to the type system. But need to be careful and not use type name allready present in user space.

@Carl Love 

Yes, I removed the deep copy allready before you posted your answer. I found I did not need it.

Is there a difference between 

 Record("x"= 4, "y"=6, "result"= ())

vs

 Record('x'= 4, 'y'=6, 'result'= ())

They both work the same.  As far as type checking, yes good point. But for a record of say 20 fields, I really do not want to write the type of each field like this each time I pass a record. Too much typing.

There should be in Maple a way to define the whole record as some type name, then one could just do

foo3a:= proc( input::my_record_type_A)
......
end proc;

Where my_record_type_A is the type name given for the full record structure  defined earlier. So maple will check I am passing the correct type for all the fields.  I do not know if this is possible in Maple, I remember reading one can define a name for their own types in Maple, and make variables of such type. so I need to look into this and figure how it works.  

I still find table syntax a little nicer.  A["x"]:=5  for me is a little nicer/easier to read than A:-x:=5   But this is minor issue.

@Carl Love 

yes, good point about the sublists issue. 

@Kitonum 

thanks. I tried many variations, except this one :) I did not think of it, since remove takes argument itself. 

But in remove~(has, A, 0);  how does ~ knows it is the second argument, which is A here hat needs to be element wise expanded and passed to remove? Why did it not look at say the third argument which is zero in this case, which is not a list ofcourse and did nothing? it seems ~  is smart and found the right thing on its RHS to expand, which is A in this case.  This is why I did not think this will work and did not try it. I  thought what is on RHS of ~  can only be list, and not the full arguments to the function.

@minhhieuh2003 

I want the expression to be a fraction, not a power of -1?

Yes, I want that also. But Maple's Latex conversion is not the best. This is well known issue for many many years. Apparently Maplesoft does not think Latex is important in the real world. Even this forum itself does not accept Latex as input.  

https://www.mapleprimes.com/posts/209333-Improving-Latex-Output-Of-Maple-For-Expressions

Notice that _LatexSmallFractionConstant:=1;  has no effect on this. Sometimes this has an effect and sometimes not. It is not really a documented thing any way.

Only way to fix this is at the source. The source is at Maplesoft headquarters. So only someone inside Maplesoft can fix these issues. We hope they will do this in the next 10-20 years time frame.

But it returns only one value: -1.000.

But why would you expect it to return more than one value? You are not collecting all the results generated inside the loop any where. The result returned is the last one as expected.

@Christopher2222 

I do not even know where the LibraryTools code is in first place, and I do not think I will be able to figure how change it myself to do what I want.

I do not even know how to copy what LibraryTools:-Browse()  shows on the screen to some text file to save me having to type all this myself.

@Pascal4QM 

Thanks for the hint, But this does not exactly do what I want. I do not want to look at call graphs. Just want to have a large view of the organizational structure of the the packages and subpackages to help one get an idea of what is there. Similar to help's table of content in a way but in a way to only look at packages/subpackages layout more easily than can be done using help.

isn't the syntax for plotting multiple functions plot( [sin(x),sin(x)],  x=0..420);  so is the bug that Maple accepted the syntax plot( [sin(x),sin(x),  x=0..420]); without giving a syntax error? 

I am trying to understand what plot( [sin(x),sin(x),  x=0..420]); is supposed to mean in the first place as the syntax itself looks wrong to me. 

@Christopher2222 

Thanks, lightmodel=none is good hint. Will use it from now on for 3D. Without it, the frame is indeed affected by view angle, when it should not be. 

@Carl Love 

THanks for the hint that one can color the tick labels separately from the axes themselves. But when I use

axis     = [tickmarks= [3, subticks= 4, color= black], thickness= 0,color= COLOR(HSV, 0, 0, .85)],

now the axes labels themselves (x,y,z) become hard to read. But the numbers on the ticks are clear. Here is what I mean

restart;
f :=-x^4-2*y^4+14*x^2*y^2/5:
axis_color        :=  COLOR(HSV, 0, 0, .85);
tick_labels_color :=  black;

plot3d(f, x=-5..5,y=-5..5,
   axes     = boxed,
   axesfont = [Helvetica, Bold, 8], #good choice
   axis     = [tickmarks= [3, subticks= 4, color= tick_labels_color ], thickness= 0, color = axis_color],
   labeldirections = [horizontal, horizontal, horizontal],        
   labels     = ['x', 'y', 'z'],   
   lightmodel=none,
   scaling  = unconstrained, view=[-5.2..5.2,-5.2..5.2,-1300..40]);

So I removed the axis_color and now it is more clear, but the frame became black again.

It looks like "labels" are affected by axis_color so when axis_color is say gray or COLOR(HSV, 0, 0, .85), the labels text color become gray and hard to read but the numbers on the ticks are still good and not affected by this change.