Re: [Scilab-users] {EXT} need a more efficient and faster code: suggestions welcome

2018-01-31 Thread Stéphane Mottelet
Dear Heinz, Here is what can be done in Scilab-5.5.2 to accelerate your computations on a multi-core architecture under Linux : function out=distances(X)     function out=distance(k)     this=X(k,:);XX=X;XX(k,:)=[];     DIFF=XX-ONE*this;     out=sqrt(min((DIFF.*DIFF)*[1;1;1]));    

Re: [Scilab-users] {EXT} need a more efficient and faster code: suggestions welcome

2018-01-31 Thread Heinz
My latest tictoc is 366: would that be 6.1 minutes? I am away from my 2 iMacs at home and running Scilab on a lowly Intel Pentium CPU N3540 @ 2.16GHz Win10 laptop. Your "2.498" for 40,000 points are phenomenal regarding the fact that the running time increases with the square of the number of

Re: [Scilab-users] {EXT} need a more efficient and faster code: suggestions welcome

2018-01-31 Thread stephane . mottelet
Hello, Don't even think about using parallel_run under OSX. It used to work (with some tweaking) with scilab-5.5.1 under Mavericks, but since 5.5.2 version, it has become completely unstable. S. Heinz a écrit : My latest tictoc is 366: would that be 6.1 minutes?

Re: [Scilab-users] {EXT} need a more efficient and faster code: suggestions welcome

2018-01-31 Thread Rafael Guerra
Hi Heinz, Find herein a vectorised memory hog solution for Scilab 6, which is fast (~30 s for 20K points on Win7 laptop): // START OF CODE (Scilab 6) Clear n=2; r=23; radius = r*grand(n,1,'def').^(1/3); phi = 2*%pi*grand(n,1, 'def'); costheta = 1 - 2*grand(n,1, 'def'); radsintheta =

Re: [Scilab-users] GUI programming

2018-01-31 Thread philippe
Hi Le 24/01/2018 à 19:49, Claus Futtrup a écrit : > Hi Scilabers > > Is there a comprehensive manual or book (in English, or alt German) > about programming GUI in Scilab? (or a comprehensive web-page) programming GUI in scilab relies on a good comprehension of graphics handles. The 4th chapter

Re: [Scilab-users] {EXT} need a more efficient and faster code: suggestions welcome

2018-01-31 Thread Heinz
On my puny 250 Euro Win10 travel-laptop, I have achieved 66 tictocs for 20,000 random points with your code [not that I would understand it] in Scilab 5.5.2 and that is phenomenal and opens up new simulation possibilities. Thanks so much Heinz -Original Message- From: users

Re: [Scilab-users] {EXT} need a more efficient and faster code: suggestions welcome

2018-01-31 Thread Dang Ngoc Chan, Christophe
Hello, The following suggestions will probably not have a drastic influence (I don't see how it could be more vectorised) but his a little thing I see: > De : users [mailto:users-boun...@lists.scilab.org] De la part de Heinz > Nabielek > Envoyé : mercredi 31 janvier 2018 00:13 > >

Re: [Scilab-users] Stacked 2D plot in 3D

2018-01-31 Thread Jean-Philippe Grivet
Hi Claus, Rafeal and Samuel, Here is another method for stacked plots, which was suggested to me years ago by Serge Steer. I used it succssfully for about 12 individual curves. Cheers, JP Grivet Le 28/01/2018 20:19, Claus Futtrup a écrit : Hi Rafael and Samuel Thank you both for great

Re: [Scilab-users] ?==?utf-8?q? {EXT} need a more efficient and faster code: suggestions welcome

2018-01-31 Thread Antoine Monmayrant
Hello Stéphane, Sorry to hijack the discussion but I didn't know that there was such a difference between A.*A and A.^2. Could you tell us more about it? Why is is twice faster to use the A.*A form? Is this documented somewhere? Cheers, Antoine Le Mercredi, Janvier 31, 2018 10:53 CET,

Re: [Scilab-users] ?==?utf-8?q? ?==?utf-8?q? ?= {EXT} need a more efficient and faster code: suggestions welcom

2018-01-31 Thread Antoine Monmayrant
Argh, OK, I get it: scilab treats A.^2 exactly like A.^%pi and not like "square it". Makes sense, thank you for the info. I wonder how julia is performing with respect to A.^2 compared to A.*A... Antoine Le Mercredi, Janvier 31, 2018 11:30 CET, Stéphane Mottelet a

Re: [Scilab-users] {EXT} need a more efficient and faster code: suggestions welcome

2018-01-31 Thread Heinz
Thanks Christophe- I should have thought of it myself... I have difficulties handling the SciLab timer: how do you do this exactly? Heinz PS: Had you noticed that the resulting probability had been predicted by Prof Paul Hertz in Heidelberg, Mathematische Annalen, Vol 67 (1909), 387ff as early

Re: [Scilab-users] {EXT} need a more efficient and faster code: suggestions welcome

2018-01-31 Thread Stéphane Mottelet
Replacing     MinDist=[MinDist sqrt(min(sum(DIFF.^2,2)))]; by     MinDist=[MinDist sqrt(min(sum(DIFF.*DIFF,2)))]; will be at least twice faster. Crunching elapsed time could be done by using parallel_run (with 5.5.2 version) if you have a multi-core processor. S. Le 31/01/2018 à 09:36,

Re: [Scilab-users] {EXT} need a more efficient and faster code: suggestions welcome

2018-01-31 Thread Stéphane Mottelet
moreover,     MinDist=[MinDist sqrt(min((DIFF.*DIFF)*[1;1;1]))]; is even faster. S. Le 31/01/2018 à 10:53, Stéphane Mottelet a écrit : Replacing     MinDist=[MinDist sqrt(min(sum(DIFF.^2,2)))]; by     MinDist=[MinDist sqrt(min(sum(DIFF.*DIFF,2)))]; will be at least twice faster.

Re: [Scilab-users] ?==?utf-8?q? {EXT} need a more efficient and faster code: suggestions welcome

2018-01-31 Thread Stéphane Mottelet
I am an old school guy and have learned scientific computing with Fortran... Using mutiplication instead of power elevation is an old trick which should not be necessary with a more clever interpreter (which should detect that 2 is actually a (small) integer and use multiplication instead)