Re: [Scilab-users] unusable cat() rewritten. Call for reviewers

[Claus Futtrup]

Hi Samuel, et al.

>Doesn't it fit more to what could be expected?

Yes. Absolutely. Sorry that I don't know how to help verify the code.

/Claus

On 10-08-2017 20:03, Samuel Gougeon wrote:

Le 10/08/2017 à 19:55, Samuel Gougeon a écrit :


Dear co-scilabers,

The bug 8297  reporting the 
outstanding slowness of the cat() function was reported in 2010
but lasts since cat() was introduced. As measured and commented in 
the report, this
slowness actually makes cat() almost unusable, except for small sized 
arrays to be concatenated.


For instance, after M = rand(500,500); cat(3,M,M) takes more than 11 
days (yes)

with Scilab 5.5.2, and roughly 4 hours with Scilab 6.0.0.

So, everyone could imagine how much Scilab currently takes just to 
build a standard
1000x1000 RGB image by stacking its 3  1000x1000 R,G,B layers using 
cat(3,R,G,B).

The current algorithm is exponential with respect to the array size...

Before using GPU routines to process images, a much simpler thing can 
be done

to enable cat() for true life usages : rewritting it.
This is what is done here: https://codereview.scilab.org/#/c/19278/

Some rewievers are needed to make cat() truly available in Scilab 6.0.1.
So, do not hesitate to contribute online.



To complete: This new implementation spends 0.25 s (instead of 4 
hours) to execute

M = rand(500,500);
cat(3,M,M);

and 0.42 s to process

M = rand(1000,1000);
cat(3,M,M,M);

Doesn't it fit more to what could be expected?
SG



___
users mailing list
users@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/users



___
users mailing list
users@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/users

Re: [Scilab-users] unusable cat() rewritten. Call for reviewers

[Samuel Gougeon]

Le 10/08/2017 à 19:55, Samuel Gougeon a écrit :


Dear co-scilabers,

The bug 8297  reporting the 
outstanding slowness of the cat() function was reported in 2010
but lasts since cat() was introduced. As measured and commented in the 
report, this
slowness actually makes cat() almost unusable, except for small sized 
arrays to be concatenated.


For instance, after M = rand(500,500); cat(3,M,M) takes more than 11 
days (yes)

with Scilab 5.5.2, and roughly 4 hours with Scilab 6.0.0.

So, everyone could imagine how much Scilab currently takes just to 
build a standard
1000x1000 RGB image by stacking its 3  1000x1000 R,G,B layers using 
cat(3,R,G,B).

The current algorithm is exponential with respect to the array size...

Before using GPU routines to process images, a much simpler thing can 
be done

to enable cat() for true life usages : rewritting it.
This is what is done here: https://codereview.scilab.org/#/c/19278/

Some rewievers are needed to make cat() truly available in Scilab 6.0.1.
So, do not hesitate to contribute online.



To complete: This new implementation spends 0.25 s (instead of 4 hours) 
to execute


M = rand(500,500);
cat(3,M,M);

and 0.42 s to process

M = rand(1000,1000);
cat(3,M,M,M);

Doesn't it fit more to what could be expected?
SG

___
users mailing list
users@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/users

[Scilab-users] unusable cat() rewritten. Call for reviewers

[Samuel Gougeon]

Dear co-scilabers,

The bug 8297  reporting the outstanding 
slowness of the cat() function was reported in 2010
but lasts since cat() was introduced. As measured and commented in the 
report, this
slowness actually makes cat() almost unusable, except for small sized 
arrays to be concatenated.


For instance, after M = rand(500,500); cat(3,M,M) takes more than 11 
days (yes)

with Scilab 5.5.2, and roughly 4 hours with Scilab 6.0.0.

So, everyone could imagine how much Scilab currently takes just to build 
a standard
1000x1000 RGB image by stacking its 3  1000x1000 R,G,B layers using 
cat(3,R,G,B).

The current algorithm is exponential with respect to the array size...

Before using GPU routines to process images, a much simpler thing can be 
done

to enable cat() for true life usages : rewritting it.
This is what is done here: https://codereview.scilab.org/#/c/19278/

Some rewievers are needed to make cat() truly available in Scilab 6.0.1.
So, do not hesitate to contribute online.

Thank you.
Samuel

___
users mailing list
users@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/users

Re: [Scilab-users] Call for reviewer <= SEP: upgrading weekday()

[Samuel Gougeon]

Le 01/08/2017 à 14:24, Richard llom a écrit :

Then, for a big subset of dates, there would not be any way to
distinguish it from DD/MM/,

Yeah, thats the problem with this format (and not only in scilab).


unless for instance using a distinct separator: MM\DD\. Not sure
that this would be actually ok.
Would it? IMO, a "US" optional flag would not be more handy.

IMO the "US" optional flag would be the only reasonable solution. Also for
someone who has his source date in US-format, this optional flag would
certainly be more handy than converting the date before / inline...


Now dates prefixed with "en" (for "english") are accepted, like 
"en09/17/2015".

Cheers
Samuel

___
users mailing list
users@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/users

Re: [Scilab-users] {EXT} scilab2c toolbox query

[Dang Ngoc Chan, Christophe]

Hello,

> De : Abhinav Dronamraju
> Envoyé : jeudi 10 août 2017 08:53
>
>  if our output size depends on an element which is a part of matrix, what can 
> we do to assign the output size accordingly.

I'm not sure I understand well your question,
but maybe you should have a look at varagout

https://help.scilab.org/docs/6.0.0/en_US/varargout.html

HTH,

regards

--
Christophe Dang Ngoc Chan
Mechanical calculation engineer
This e-mail may contain confidential and/or privileged information. If you are 
not the intended recipient (or have received this e-mail in error), please 
notify the sender immediately and destroy this e-mail. Any unauthorized 
copying, disclosure or distribution of the material in this e-mail is strictly 
forbidden.
___
users mailing list
users@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/users

Re: [Scilab-users] Leading Spaces in xstring

[Samuel Gougeon]

Hi Richard,

Le 10/08/2017 à 13:58, Richard llom a écrit :

Hey All,
I have this code to print some information in the graph:
// Save info as string
infobox(1) = msprintf('Min V  %.2f V \n',min(log_data(:,3)));
infobox(2) = msprintf('Max V  %.2f V \n',max(log_data(:,3)));
infobox(3) = msprintf('Capacity   %.2f Ah\n',amphrs);
infobox(4) = msprintf('   %.2f Wh\n',watthrs);
// Print info as box on the figure
xstring(1,0.1,infobox,0,1);
boxh = gce();
boxh.font_style = 0; // Set monospace font


I agree, this forced trimming is often annoying.
There is here an easy workaround: use a 2-column matrix instead of a 
unique column:


t  =  ["abc"   "def"
 "ghij"  "kl"
 ""  "mn"
 ];
xstring(1,0.1,t,0,1);

HTH Samuel
___
users mailing list
users@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/users

[Scilab-users] Leading Spaces in xstring

[Richard llom]

Hey All,
I have this code to print some information in the graph:
// Save info as string
infobox(1) = msprintf('Min V  %.2f V \n',min(log_data(:,3)));
infobox(2) = msprintf('Max V  %.2f V \n',max(log_data(:,3)));
infobox(3) = msprintf('Capacity   %.2f Ah\n',amphrs);
infobox(4) = msprintf('   %.2f Wh\n',watthrs);
// Print info as box on the figure
xstring(1,0.1,infobox,0,1);
boxh = gce();
boxh.font_style = 0; // Set monospace font

As you can see in infobox(4) I'm using just spaces to align the values.
However unfortunately xstring isn't printing these leading spaces.
Is this expected behavior or a bug?

Any ideas to workaround that limitation?

Thanks
richard



--
View this message in context: 
http://mailinglists.scilab.org/Leading-Spaces-in-xstring-tp4036841.html
Sent from the Scilab users - Mailing Lists Archives mailing list archive at 
Nabble.com.
___
users mailing list
users@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/users