sand15

807 Reputation

11 Badges

10 years, 83 days

MaplePrimes Activity


These are replies submitted by sand15

@Thomas Richard ... I believe I have discovered the source of the problem.

 

My function f depends on x and on many other parameters (the number of them is not known a priori) named `P.1`, `P.2`, ...
So this is a simple example that mimics what happens

f := (x, `P.1`) -> x*`P.1` ;

CodeGeneration[Matlab](f, output=string);

If I use more "conventional" names (here f:=(x,a) -> x*a) all goes perfectly well and Maple does no replacement at all.
As I am not familiar with Matlab, I simply guess that `P.1` is not an authorized syntax for the name of a Matlab variable ... so the need for a translation.

If I am right, please consider the question as over.

In any event, thank you for your answer

 

PS :  I thumb up for the disagreement

 

 

 

@Joe Riel  I have received your message loud and clear and it will be very useful for me.
Thanks a lot

@Kitonum  acer has provided an answer syntactically simpler than yours (no offfense here) which fits me just fine.

Your answer corresponds probably to the code I had expected for ... but as it often appears in Maple a simple workaround (see acer's reply) may exist.

Thanks again  for the work you did

@tomleslie 

Dear Tom,

no offence, but I think we should end this fruitless exchange before unnecessarily hurtful words shall be written.

I appreciate reading your many contributions on mapleprimes and this is what does matter.

As far as I am concerned I turn the page and it is fine.

Looking forward to hearing from you about other topics,

Respectfully.



PS : I have deleted my initial question

@tomleslie 
Dear Tom,
no offence, but  I think we could end this fruitless exchange to avoid that unnecessarily hurtful words will be written.
I appreciate the general quality of your contributions and this does matter.
I propose you to remove personaly the initial question.

Looking forward to hearing from you on other topics.

respectfully

@Joe Riel 
I have a question already discussed here (see "How to handle a very long Module ?"  / January 12 2007 boirac 104 )


To avoid problems with the Java environment when I develop a module with many procedures, I
use to proceed this way :

(Worksheet + Maple notation)


restart:

> proc1 := proc(...)
....
end proc:

> proc2 := proc(...)
....
end proc:
.
.
.
.
.

> MyModule := module():
option package:
export  proc1 := eval(:-proc1),
           proc2 := eval(:-proc2),
           .
           .
           .
           procn := eval(:-procn):
end module:


Is this a "good" way to proceed or do you recommend to write procedures in mpl files and use the
$include <....mpl> syntaxes ?

Thanks for your answer.

@tomleslie   but I'm not sure I was waiting this kind of advice from you.
Maybe I'm not so foolish than you make think ?

Have a good day

@tomleslie  Thank you for your answer Tom, but with all due respect I know perfectly that  Mapleprimes users, including me, are able to upload files with no problems.
And I've never suspected MaplePrimes to suffer of some disfunction on this topic.

By asking this question I hoped that someone else, who would have already encountered this kind of problem, could give me some "solution" to try to fix it (you are probably right : there is some barrier in my site security process)

My browser is very classical (Google, not even Chrome nor Firefox ... but I could do a test with this latter).
Trying to do the same operation in "similarlish" websites is a good suggestion from you.
I already know I can upload files in DropBox or in other cloud facilities

Thanks again

@mmcdara 

You are perfectly right, I made a mistake in copying the formula for S2.

Thanks for your correction.

@John Fredsted The well known result you refer to suggests another way to pose the problem :

Find all integers M and N such that (N+M)^2 - (N-M+1)^2 = 3375

(this difference of squares is just the sum of odd numbers of rank N-M+1 to N+M included)

To catch only the solutions everibody considerer, additional constraints on M and N are necessary.
I'll write them latter (see S3)

S1 := isolve(  (N+M)^2 - (N-M+1)^2 = 3375 ): # returns 32 solutions.

S2 := map(u -> [ 2*rhs(u[1])+1, 2*rhs(u[1])+1], [S1]) ;

# add constraints

S3 := map(u -> if u[2]-u[1] > 0 and u[2] > 0 then u end if, S2);

Here are the 8 "positive" solutions written [m, n] where n is the mean point of the sequence and m is the number of odd integers before and after n.
For instance [1, 1125] means the sequence is [1123, 1125, 1127]



It is interesting to look to the 32 solutions S1 contains, not only for the 16 solutions Kitonum or mcmdara refer to.

@acer 

Answer to vv

 

Point 1 : The writing  F = a*x is a typing error I made when I copied the source manually (separated professsionnal networks)

Point 2 : For the point you raise « [a=0..1] ==> only two integers values » you are perfectly right  … I acted over hastily during this copy

 

I use Maple 2015.1 on a Windows XP machine (64 bits)

I also tried some hours ago with Maple 2015.2 (iMac) : same behavior than Maple 2015.1 with XP

 

 

 Answer to acer 

 

This « special-evaluation rule » of yours  works perfectly 

(Where did you get all of this from? )

 

 

Thank you to both of you

Observations :

*
   Explore(plot(a*x, x=0..1), parameters = [a=0..1])                 
WORKS

*
 
 F := (x,a)  -> a*x:
    Explore(plot(F(x,a), x=0..1), parameters = [a=0..1])               
WORKS

*
 
 F := a*x:
     F := unapply(F,  
(x,a) )
     Explore(plot(F(x,a), x=0..1), parameters = [a=0..1])
                WORKS

*
 
 F = a*x:
     Explore(plot(F, x=0..1), parameters = [a=0..1])
                         DOESN’T  WORK AS EXPECTED
     (no syntax error returned but the slider doesn’t work)


In the help[Explore] page it is mentioned that the argument of Explore “must be an expression or a function”
What is confusing here is that
    F:=x  : plot(F, x=0..1):  
works correctly.
Thus it seemed natural to reproduce this kind of syntax when my invoking Explore.


The syntactic rules have been identified it remains to me to respect them.
Remember the function F
 
to explore is automatically constructed and so are the names of the parameters it contains
Let us suppose F is something like that :
 F := (x, P||1, P||2, P||3, … ) ->  some expression

I know from my initial question that the syntax P||k is not “legal” so the first thing to do is to capture the names of the parameters and to change then

# OldParams
  denotes  
the list of the parameters (x excluded) returned by the construction process

NewParams :=[ some list of “legal” names to use with Explore]:

Old2New := zip((u,v) -> u=v, OldParams, NewParams)
Old2New := convert(Old2New, set):
NewG := subs(Old2New, G)
                                     # G(=parameter ranges)  
is defined in my initial post
NewF := subs(Old2New, F(x, op(OldParams)) ):  
# F was the function to explore
Unknowns := [x, op(NewParams)]:
NewF := unapply(NewF,
 
Unknowns):
Explore(plot(NewF(op(Unknowns)), x=0..1), parameters = NewG):

In the last instruction I cannot write explicitly NewF(x, …) because I do not know in advance what NewParams contains and that I do not want to write any ad hoc code.
Unfortunately this doesn’t work : probably because the arguments of plot have to be fully evaluated before Explore begins the job ?

Does anyone have an idea to fix this ?
 
 
 
 
 
 
 

 

 

I probably did something wrong : after repeating the sequence with P__k instead of P||k it's not working anymore.

But here for other reasons : add does not evaluate P__k to the value of k (finding for what reason it is so will be a good exercice for me)

@Carl Love  ... even if  I do not completely agree with the argumentation ... which is of course questionable.

Thank you Carl for keeping a close eye on everything said here

sand@vv 

It comes from my writing  (I use your notations)

pA:=PLOT( CURVES(A) ,LEGEND("1st"), COLOR(RGB,1,0,0) ) ):

instead of

pA:=PLOT( CURVES (A ,LEGEND("1st"), COLOR(RGB,1,0,0) ) ):


There is a logic in defining the legend as a CURVE argument : that explains that my previous coding was wrong.

My confution originates in the COLOR(...) argument : although it is also another CURVE argument (and then should be defined as such, enclosed in CURVES(...) ), it is correctly accounted for whatever its position :

pA:=PLOT( CURVES(A), COLOR(RGB,1,0,0) ) ):

and

pA:=PLOT( CURVES(A , COLOR(RGB,1,0,0) ) ):

both return the same thing


The reason why LEGEND and COLOR do not behave in the same way is a mistery for me  (have you such explanation on your side ?)

In any event thank you for your information

 

 

First 22 23 24 25 Page 24 of 25