nm

11413 Reputation

20 Badges

13 years, 72 days

MaplePrimes Activity


These are replies submitted by nm

it is even more strange when comparing these 3 variations, which all should give same output. Only when using % it gives 4.

restart;
L := [1,2,3,4]:
x[j]:
seq(x[j], x[j] in L):
x[j];


restart:
L := [1,2,3,4]:
seq(x[j], x[j] in L):
x[j]


restart:
L := [1,2,3,4]:
x[j]:
seq(%, x[j] in L):
x[j]

 

@tomleslie 

The first issue relates to your use of multiline strings - anyy 'linter' which didn't flag this piece of code isn't worthy of the name.

 

This is news to me. As multilines strings is a feature touted by many programming languages over others that do not support it. 

https://en.wikipedia.org/wiki/Here_document

"Here documents originate in the Unix shell,[1] and are found in shcsh,[2] tcsh,[3] kshbash, and zsh, among others. Here document-style string literals are found in various high-level languages, notably the Perl programming language (syntax inspired by Unix shell) and languages influenced by Perl, such as PHP and Ruby. Other high-level languages such as PythonJavaScript and Tcl have other facilities for multiline strings."

C++ added multiline strings in 2011 as new big feature of the language. See the second answer here https://stackoverflow.com/questions/1135841/c-multiline-string-literal which got 408 votes up.

There is absolutely nothing wrong with multiline strings. It is a good feature and can make doing something much simpler than without it. It also works in Maple with no problem and I have used it for long time in Maple with no problems at all.

The problem is that Maple's lint says it is syntax error when used in one specific construct and not in other places.

 

@Carl Love 

"Personally, I would never use a multiline string."

That is reasonable. But this was not really the question I was asking. I would agree with you though, that it is probably best not to use it and do "A\n","B" explicitly. I am changing my code to do that.

When you say "I think that mint should be stricter than regular Maple"  I thought that mint uses the Maple language rules to check the syntax,

Where does it say that

 cat("A
      B")

is a syntax error in Maple? Or even it says one should not do this? 

I did not see it when I searched, but I could have overlooked it. Notice also that the code actually runs inside Maple with no errors.

Does mint have its own rules for what constitute a syntax error in the Maple language? If so, do you know where these are described? I use mint sometimes check for possible problems in code.

The quesiton was, why it gives syntax error only when using 

if not x in ["A","B"] then

before it. 

@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.

First 56 57 58 59 60 61 62 Last Page 58 of 91