520 Reputation

10 Badges

4 years, 355 days

MaplePrimes Activity

These are replies submitted by sand15

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


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])                 

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

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

 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
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,
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


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) ) ):


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



I apologize : the true syntax I used is userData := convert(userData, Matrix): 

sorry again

@Carl Love 
Sorry for the response time, I was in vacations.

(the font and the presentation are not smart due to drag and drop between different mailing systems)

I already used kernelopts(memusage) but it is not easy to interpret the data it returns.
In my case I observe that practically all the types of variables have a growing size (here a sketch of the my usage of kernelopts)
DATA := Matrix(1000, 10, [...]):
MEM := kernelopts(memusage):   #  Initial sizes
n := 10: # for primary investigations
for k from 1 to n do
  result := Myproc(...., DATA[k, ..], ...)
  MEM := < MEM | kernelopts(memusage)[.., 2..3] >:
end do:
What it is quite puzzling for me, is that he BINARY item presents the highest increase : typically its size after the first execution of the loop is very close to its initial size but increases by a factor of 5 after the second call to MyProc (which, at least explicitly doesn't contain any boolean type nor complex `if` structures not piecewise functions)
Nevertheless, I observe the memory does not inflate in the following case.
n := 10: 
TEST := 2: # or any other value in the range 1..1000
for k from 1 to n do
  result := Myproc(...., DATA[TEST, ..], ...)
  MEM := < MEM | kernelopts(memusage)[.., 2..3] >:
end do:
Some orders of magnitude of the memory (obtained with CodeTools[usage])
  • in the later case above it keeps a constant value around 70 MiB whatever the value of n (but it is probably a consequence of some remembrance process)
  • In the first case it starts from 70 MiB, jumps to 650 MiB for n=2 and increases regularly to reach 1 GiB for n of the order of 100 and 4 GiB for n=1000
At the end, I stopped using kernelopts(memusage) because I was not capable to link the many items this function returns  to the quantities the procedure MyProc handles ...
Thank you nevertheless for the answer.
It feels as if I’m going to use you second suggestion CodeTools:-Profiling:-Profile()

@acer   thank you acer

@Carl Love 

Great thanks to you Carl, I think I could have been waste a lot of time on this problem !!!

I am going to look to the many commands you mentionned and try to understand all this,

thanks again

@Preben Alsholm 

This is a complete explanation, thank you Preben


It suits me very well.

@Adri van der Meer 

Smarter than Matrix(N,N, Re~(convert(DC, list))) !!!

Nevertheless : do you observe the same behaviours I did myself ?

@Preben Alsholm

Thank you Preben, but I have this answer.

I would not offend Kitonum (who posted a  pretty solution) but the "other" was smarter.

In fact I think I rediscoverd it by myself (thanks to my anonymous inspirer) :

  1. Let A a fixed real interval
  2. let B another real interval and B(x) a translation of B of value x
  3. Question : "Do A and B(X) overlap ?"

(A) solution :

coverage := proc(A, B, x) 
    coulditbe('_u', `intersect`(SetOf(A), SetOf(map(y -> x+y, B)) ) )
end proc:

# example :

A := RealRange(0, 2);
B := RealRange(-3, -1);
coverage(A, B, 0.999):
coverage(A, B, 1.001):

No offence meant to Kitonum, and without regard of efficiency, this solution is slightly more aesthetic than the one he proposed to me  :-)

@John Fredsted I obtained the same conclusion yesterday evening by setting k=r*exp(theta*I).
It seemed a little bit simpler to analyze because r is always positive and sin(theta) is bounded

I will send you the .mw file asap. For the moment the uploading doesn't work correctly (I'm in the office and it could be related to the firewall ?)

First 11 12 13 14 Page 13 of 14