sand15

505 Reputation

10 Badges

4 years, 292 days

MaplePrimes Activity


These are replies submitted by sand15

@ThU 

 

Correction: CTRL+J doesn't work.


Thank you anyway
 

@ThU 
"Do you mean the vertical bar at the location of the cursor? " : Yes,

The problem is now solved (see my previous "auto-answer"), but I'm keeping by my side your "control-J" trick ... for the last time.
Thanks for the answer

 

 

  1. I opened the worksheet "W"  with an older Maple version (Maple 2015): it contained the vertical location bar
  2. I saved it with another name
  3. And finally opened this new fir with Maple 2018 ... and this bar was miraculously restored !!!

I let the people in charge of this site to decide for themselves  if this question/auto-answer must be retained or removed

@Carl Love 

I give up : I DON'T KNOW HOW TO DO AN OBJECTIVE COMPARISON

I used your last version of NimMatrix with parameters 5, 5  (NimMatrix(5,5))

Procedure 1 :
 T := NULL;
for r from 1 to 100 do
   T := T, CodeTools[Usage](Code(...), output=cputime)  # from your answer to the "other" thread
end do:
add(T)/100

Procedure 2 : (from acer's suggestion)
 CodeTools[Usage](Code(...), output=cputime, iterations=10


Results
  indicator                Proc 1                   Proc2            

 cpu time/run             16.9 s                     32.75 s             

memory size            0.95 GiB                  0.95 GiB

I repeated this twice and obtained the same ratio of 2 between the cpu times.
For proc1 the 10 times range between 15.49 s and 18.08 s

For "My best code" chich uses no sophisticated material nor the option remember, the cpu times are the same (up to unavoidable fluctuations) with proc1 and proc2.

Then : what is the cpu time (16 s or 32 s) I have to take to do an OBJECTIVE comparison ???

 

@acer 

 

Thank you acer.
I've read the help pages but I missed apparently this "iterations" option
 

@Carl Love 

Procedure used to evaluate the cpu time (see my brevious reply)

T := NULL;
for r from 1 to 100 do
   T := T, CodeTools[Usage](Code(...), output=cputime)  # from your answer to the "other" thread
end do:
add(T)/100

CONDITIONS : BASE = 5, K = 3 (==> NimMatrix(5, 3))

The results (Maple 2018 / Windows 7) are
"NimMatrix lastversion"    14.35 ms / run
"NimMatrix first version"   23.56 ms / run
"My best code"                         46.90 ms / run

@Carl Love 

It works well in Maple 2018.
I did probably some mistake when I used this with the older Maple's versions
(I guess you're going to think I'm familiar with that...)

@Carl Love 

I tried this but it didn't work (I used Maple 2015 ... or maybe 2016 ?)
I'm going to try again with Maple 2018 newly installed on my PC.

BTW : I just sent you two replies on the "unconventional addition" thread

Thanks

@Carl Love 

 

I did not want to sound offensive.
Put all this on blunders due to the fact that English is not my native language. Words do not have the same harshness from one language to another.

About the way I stated the problem there are, I agree, a lot of things to say and I recognize willingly that I should have done better


And don't go thinking that I'm one of those people who never admits to having made an error.
I can ensure you I never thought this about you

So, I'm sorry if I have hurt you.
Leave it there and recieve my apologies
 

@Carl Love

CodeTools[Usage] being rether inefficient to estimate the computational time (see my new question), I did this

t0 := time():
for r from 1 to 100 do   Code(...) end do:
time()-t0;

where "Code" is one among "NimMatrix first version", "NimMatrix last version", "My best code"

CONDITIONS : BASE = 5, K = 3 (==> NimMatrix(5, 3))

The results (Maple 2018 / Windows 7) are
"NimMatrix lastversion"     1.529 s  ---> 15.23 ms / run
"NimMatrix first version"    2.371 s  ---> 23.71 ms / run
"My best code"                         5.273 s  ---> 52.73 ms / run

As you've seen earlier my first comparisons where made by using CodeTools[Usage].
I tried the same here, running 10 times each of these codes and doing a restart before each new run. 
The cpu times I obtained for
"NimMatrix lastversion"     32, 63, 31, 62, 63, 32, 78, 54, 63, 63
"NimMatrix first version"    63, 47, 62, 47, 46, 47, 78, 47, 62, 46
"My best code"                         62, 78, 78, 78, 63, 62, 62, 31, 78, 78

I didn't compute the means of the CPU times but a lot of things may be observed :

  1. The times vary in a relatively large ratio (~2.5 for "NimMatrix lastversion"  or "My best code")
  2. CodeTools[Usage] seems to deliver rounded values (strabge it is that 78 or 63 appear many times)
  3. The times are roughly speaking the same and no evident ranking can be deduced from them (even if tendencies can be infered)
  4. The times are significantly larger to those obtained by the first method (which returns the real time, necessarily larger than the CPU time)


I guess that the strong differences in the results produced by the two methods comme from the fact that the first one (r=1..100) does no restart between each run.
My code doesn' use any remembre option and is probably less sensitive to the lack of restart (besides you may notive that
52.73 ms/run is not, off the top of my head, far from the mean of [ 62, 78, 78, 78, 63, 62, 62, 31, 78, 78]).

 

@nm 

I agree.
In fact there are many ways do realize this addition.
At the beginning I thought that some bitwise operations existed in Maple, but I failed to find them.
Then I decided to do may own coding and faced the problem of lists (a and b) of different length (typically I need to compute "A plus B" for each pair in {0..3^n}^2, [of course the relation "A plus B" = "B plus A" halves the number of operations)

I first wrote something more or less the same than your solution  (maybe a little bit longer) and I found it too complicated for it used ListTools[Reverse] too.
This why I have come to use a polynomial representation (my " pa := add(a[k]*x^(k-1), k=1..numelems(a))" ) .
But this looked rather "artificial".
Using gfun seemed promising because the coding was even shorter ... but I faced some difficulties at the last steps.

The key of your solution lies in the line c := parse(cat(op(a)))+parse(cat(op(b)));
A more astute way to handle lists of different length than using polynoms.

Thank you for your answer
 

@acer 

Absolutely right!
I'm ashamed not to have think to that myself :-(

Of course the few questions I posted here are just a part of a more general program but your proposal could answer them.

Than you acer 

@acer

For information ...

I keep using the Maplets package (probably no much people here still do that) and all the help pages quote option names and option values.

 

@Adam Ledger 

Surely a, ambitious and interesting initiative !

As I said working with Maplets seems to be very uncommen these days.
it feels like if Embedded components and interactive documents are in the way to take the lead now. I keep finding interesting features in Maplets, even if they suffer some drawbacks (their programming complexity and the lack of possibilities to debug them efficiently).



BTW, when I said that "I did not have MAPLE right now ", I just wanted to say that I was on a terminal where Maple wasn't installed. But I have it in my office and at home ... so dont' worry, I don't need to try an get an older version on the web :-)

@vv

Thanks (which implies I must be very carefull in using them)

4 5 6 7 8 9 10 Last Page 6 of 14