Re: [Scilab-users] On computational speed

2023-12-01 Thread Federico Miyara


Christophe,

I'm not making a general comparison between multiplication and
exponentiation, I'm comparing exponentiation to the power 2 using the
hat operator ^ with a valid --and simpler-- procedure to get the same
result, i.e., multiplying the base times itself.

I believe that functions and operators should parse the input arguments
to exploit some special cases in which much more efficiency can be
attained. The square is one such case, very important for its prevalence
in many technical computations.

My timings show that it is even more efficient to compute the general case

c =  a^b

by

c = exp(b*log(a)).

So the algorithm being used for the general case is already more
inefficient than it could be even by scripting, which is always more
inefficient than a built-in. So it is not just a whim motivated by my
use case but, rather, exposing a case which is susceptible of improvement.

You say "It is a fact that amongst the several ways to compute one
result, some are more efficient than others." OK, then, why not use the
most efficient one?

Another example: gamma() vs factorial(). Factorial is a special case of
gamma function, yet it is slower. Try this:

// Generate random integers
--> tic, u = floor(20*rand(1, 1e6)); toc
 ans  =
   0.087116

// Compute factorial directly
--> tic, v = factorial(u); toc
 ans  =
   0.7588414

// Compute factorial using gamma
--> tic, v = gamma(u+1); toc
 ans  =
   0.2418619

Timing may vary across machines and operating systems, but the ratios
are similar.

Factorial is three times slower than using a special function. By the
way, for integers up to 20, which yield numbers compatible with the
precision of the arithmetic, the results are identical; above that the
relative error is vanishingly small (about 1e-14)

I have no idea which algorithm is being used for factorial (obviously,
not multiplying all the factors), but its performance still leaves much
to be desired.

Regards,

Federico Miyara


Except that the power is not a multiplication.
It is a fact that amongst the several ways to compute one result, some are more 
efficient than others.
Is the power function too slow regarding the algorithm it uses? Maybe, I don't 
know, but the comparison with the multiplication is not fair.

https://help.scilab.org/power

Regards

--
Christophe Dang Ngoc Chan
Mechanical calculation engineer
Technology & Open Innovation
Product Management & Development

Sidel Group
Sidel Blowing & Services
Avenue de la Patrouille de France
CS 60627, Octeville-sur-Mer
76059 Le Havre cedex, France


Tel: 33(0)2 32 85 89 32
Fax: 33(0)2 32 85 91 17




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
Click here to unsubscribe: 
https://lists.scilab.org/mailman/listinfo/users
This email and any attachments are intended solely for the use of the 
individual or entity to whom it is addressed and may be confidential and/or 
privileged.

If you are not one of the named recipients or have received this email in error,

(i) you should not read, disclose, or copy it,

(ii) please notify sender of your receipt by reply email and delete this email 
and all attachments,

(iii) Dassault Systèmes does not accept or assume any liability or 
responsibility for any use of or reliance on this email.


Please be informed that your personal data are processed according to our data 
privacy policy as described on our website. Should you have any questions 
related to personal data protection, please contact 3DS Data Protection Officer 
https://www.3ds.com/privacy-policy/contact/





--
Este correo electrónico ha sido analizado en busca de virus por el software 
antivirus de Avast.
www.avast.com
___
users mailing list - users@lists.scilab.org
Click here to unsubscribe: 
https://lists.scilab.org/mailman/listinfo/users
This email and any attachments are intended solely for the use of the 
individual or entity to whom it is addressed and may be confidential and/or 
privileged.

If you are not one of the named recipients or have received this email in error,

(i) you should not read, disclose, or copy it,

(ii) please notify sender of your receipt by reply email and delete this email 
and all attachments,

(iii) Dassault Systèmes does not accept or assume any liability or 
responsibility for any use of or reliance on this email.


Please be informed that your personal data are processed according to our data 
privacy policy as described on our website. Should you have any 

Re: [Scilab-users] On computational speed

2023-12-01 Thread Dang Ngoc Chan, Christophe
Hello,


General

-Message d'origine-
De : users  De la part de Federico Miyara
Envoyé : jeudi 30 novembre 2023 16:52
>
> confirm that, [...] the simple squaring operation takes much longer than it 
> should.

Except that the power is not a multiplication.
It is a fact that amongst the several ways to compute one result, some are more 
efficient than others.
Is the power function too slow regarding the algorithm it uses? Maybe, I don't 
know, but the comparison with the multiplication is not fair.

https://help.scilab.org/power

Regards

--
Christophe Dang Ngoc Chan
Mechanical calculation engineer
Technology & Open Innovation
Product Management & Development

Sidel Group
Sidel Blowing & Services
Avenue de la Patrouille de France
CS 60627, Octeville-sur-Mer
76059 Le Havre cedex, France


Tel: 33(0)2 32 85 89 32
Fax: 33(0)2 32 85 91 17




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
Click here to unsubscribe: 
https://lists.scilab.org/mailman/listinfo/users
This email and any attachments are intended solely for the use of the 
individual or entity to whom it is addressed and may be confidential and/or 
privileged.

If you are not one of the named recipients or have received this email in error,

(i) you should not read, disclose, or copy it,

(ii) please notify sender of your receipt by reply email and delete this email 
and all attachments,

(iii) Dassault Systèmes does not accept or assume any liability or 
responsibility for any use of or reliance on this email.


Please be informed that your personal data are processed according to our data 
privacy policy as described on our website. Should you have any questions 
related to personal data protection, please contact 3DS Data Protection Officer 
https://www.3ds.com/privacy-policy/contact/



Re: [Scilab-users] On computational speed

2023-11-30 Thread Federico Miyara


Heinz,

Thank you for your timings, which confirm that, even if about an order
of magnitude faster (I use a rather old i7 laptop), the simple squaring
operation takes much longer than it should.

Regards,

Federico Miyara

On 30/11/2023 02:14, Heinz Nabielek wrote:

Thanks. In the 1960s FORTRAN, we would always write A2=A*A rather than A2=A**2.

Below the Federico examples on my M1 Apple silicon iMac:
Heinz

--> tic, u = rand(1,1e7); toc
  ans  =   0.111413

--> tic, v = sqrt(u); toc
  ans  =   0.0384130

-->  tic, v = u.*u; toc
  ans  =   0.023148

--> tic, v = u.*%pi; toc
  ans  =   0.017872

--> tic, v = u.^2; toc
  ans  =   0.156129

--> tic, v = u.^%pi; toc
  ans  =   0.1537830

--> tic, v = log(u); toc
  ans  =   0.093586

--> tic, v = exp(u); toc
  ans  =   0.0821170

--> tic, v = exp(2*log(u)); toc
  ans  =   0.139802






Am 30.11.2023 um 00:46 schrieb Federico Miyara :

Dear All,

I was trying to make some simple experiments regarding computational speed of 
several functions and operations and some results puzzled me. To perform the 
tests I used massive data to minimize the effect of idle time due to priority 
handling by the operating system or whatever.

--> tic, u = rand(1,1e7); toc
  ans  =
0.4948326

This creates ten million random numbers in half a second. Very decent 
performance. Then

--> tic, v = sqrt(u); toc
  ans  =
0.282802

The algorithm for square root seems quite fast. Multiplication

--> tic, v = u.*u; toc
  ans  =
0.1218028

--> tic, v = u.*%pi; toc
  ans  =
0.119245

is really fast. But when it comes to power or exponentiation:

--> tic, v = u.^2; toc
  ans  =
1.9633435

--> tic, v = u.^%pi; toc
  ans  =
1.958321

it is quite slow. Logarithm is much faster:

--> tic, v = log(u); toc
  ans  =
0.5166959

Even the exponential function with base e is much faster:

--> tic, v = exp(u); toc
  ans  =
0.5451482

I wonder why special cases such as small integer powers are not dealt with by 
simple multiplication. Particularly the square is very frequently used on large 
vectors representing discrete signals (for instance to get energy measures) and 
no warning is issued in the documentation.

I also notice that computing the square using this formula (a cannon to kill a 
mosquito!)

--> tic, v = exp(2*log(u)); toc
  ans  =
1.2789763

is faster than using the power operator ^.

This seems to be an inconsistent approach, since many special functions are 
painstakingly tailored to be very efficient, yet one of the simplest of all 
operations, raising to power 2, is sluggishly slow...

Regards,

Federico Miyara


Libre de virus.www.avast.com This email and any attachments are intended solely 
for the use of the individual or entity to whom it is addressed and may be 
confidential and/or privileged.
If you are not one of the named recipients or have received this email in error,
(i) you should not read, disclose, or copy it,
(ii) please notify sender of your receipt by reply email and delete this email 
and all attachments,
(iii) Dassault Systèmes does not accept or assume any liability or 
responsibility for any use of or reliance on this email.

Please be informed that your personal data are processed according to our data 
privacy policy as described on our website. Should you have any questions 
related to personal data protection, please contact 3DS Data Protection Officer 
https://www.3ds.com/privacy-policy/contact/

___
users mailing list - users@lists.scilab.org
Click here to unsubscribe: 
https://lists.scilab.org/mailman/listinfo/users

___
users mailing list - users@lists.scilab.org
Click here to unsubscribe: 
https://lists.scilab.org/mailman/listinfo/users
This email and any attachments are intended solely for the use of the 
individual or entity to whom it is addressed and may be confidential and/or 
privileged.

If you are not one of the named recipients or have received this email in error,

(i) you should not read, disclose, or copy it,

(ii) please notify sender of your receipt by reply email and delete this email 
and all attachments,

(iii) Dassault Systèmes does not accept or assume any liability or 
responsibility for any use of or reliance on this email.


Please be informed that your personal data are processed according to our data 
privacy policy as described on our website. Should you have any questions 
related to personal data protection, please contact 3DS Data Protection Officer 
https://www.3ds.com/privacy-policy/contact/





--
Este correo electrónico ha sido analizado en busca de virus por el software 
antivirus de Avast.
www.avast.com
___
users mailing list - users@lists.scilab.org
Click here to unsubscribe: 
https://lists.scilab.org/mailman/listinfo/users
This 

Re: [Scilab-users] On computational speed

2023-11-29 Thread Heinz Nabielek
Thanks. In the 1960s FORTRAN, we would always write A2=A*A rather than A2=A**2.

Below the Federico examples on my M1 Apple silicon iMac:
Heinz

--> tic, u = rand(1,1e7); toc
 ans  =   0.111413

--> tic, v = sqrt(u); toc
 ans  =   0.0384130

-->  tic, v = u.*u; toc
 ans  =   0.023148

--> tic, v = u.*%pi; toc
 ans  =   0.017872

--> tic, v = u.^2; toc
 ans  =   0.156129

--> tic, v = u.^%pi; toc
 ans  =   0.1537830

--> tic, v = log(u); toc
 ans  =   0.093586

--> tic, v = exp(u); toc
 ans  =   0.0821170

--> tic, v = exp(2*log(u)); toc
 ans  =   0.139802





> Am 30.11.2023 um 00:46 schrieb Federico Miyara :
>
> Dear All,
>
> I was trying to make some simple experiments regarding computational speed of 
> several functions and operations and some results puzzled me. To perform the 
> tests I used massive data to minimize the effect of idle time due to priority 
> handling by the operating system or whatever.
>
> --> tic, u = rand(1,1e7); toc
>  ans  =
>0.4948326
>
> This creates ten million random numbers in half a second. Very decent 
> performance. Then
>
> --> tic, v = sqrt(u); toc
>  ans  =
>0.282802
>
> The algorithm for square root seems quite fast. Multiplication
>
> --> tic, v = u.*u; toc
>  ans  =
>0.1218028
>
> --> tic, v = u.*%pi; toc
>  ans  =
>0.119245
>
> is really fast. But when it comes to power or exponentiation:
>
> --> tic, v = u.^2; toc
>  ans  =
>1.9633435
>
> --> tic, v = u.^%pi; toc
>  ans  =
>1.958321
>
> it is quite slow. Logarithm is much faster:
>
> --> tic, v = log(u); toc
>  ans  =
>0.5166959
>
> Even the exponential function with base e is much faster:
>
> --> tic, v = exp(u); toc
>  ans  =
>0.5451482
>
> I wonder why special cases such as small integer powers are not dealt with by 
> simple multiplication. Particularly the square is very frequently used on 
> large vectors representing discrete signals (for instance to get energy 
> measures) and no warning is issued in the documentation.
>
> I also notice that computing the square using this formula (a cannon to kill 
> a mosquito!)
>
> --> tic, v = exp(2*log(u)); toc
>  ans  =
>1.2789763
>
> is faster than using the power operator ^.
>
> This seems to be an inconsistent approach, since many special functions are 
> painstakingly tailored to be very efficient, yet one of the simplest of all 
> operations, raising to power 2, is sluggishly slow...
>
> Regards,
>
> Federico Miyara
>
>
> Libre de virus.www.avast.com This email and any attachments are intended 
> solely for the use of the individual or entity to whom it is addressed and 
> may be confidential and/or privileged.
> If you are not one of the named recipients or have received this email in 
> error,
> (i) you should not read, disclose, or copy it,
> (ii) please notify sender of your receipt by reply email and delete this 
> email and all attachments,
> (iii) Dassault Systèmes does not accept or assume any liability or 
> responsibility for any use of or reliance on this email.
>
> Please be informed that your personal data are processed according to our 
> data privacy policy as described on our website. Should you have any 
> questions related to personal data protection, please contact 3DS Data 
> Protection Officer https://www.3ds.com/privacy-policy/contact/
>
> ___
> users mailing list - users@lists.scilab.org
> Click here to unsubscribe: 
> https://lists.scilab.org/mailman/listinfo/users

___
users mailing list - users@lists.scilab.org
Click here to unsubscribe: 
https://lists.scilab.org/mailman/listinfo/users
This email and any attachments are intended solely for the use of the 
individual or entity to whom it is addressed and may be confidential and/or 
privileged.

If you are not one of the named recipients or have received this email in error,

(i) you should not read, disclose, or copy it,

(ii) please notify sender of your receipt by reply email and delete this email 
and all attachments,

(iii) Dassault Systèmes does not accept or assume any liability or 
responsibility for any use of or reliance on this email.


Please be informed that your personal data are processed according to our data 
privacy policy as described on our website. Should you have any questions 
related to personal data protection, please contact 3DS Data Protection Officer 
https://www.3ds.com/privacy-policy/contact/



[Scilab-users] On computational speed

2023-11-29 Thread Federico Miyara

Dear All,

I was trying to make some simple experiments regarding computational speed of 
several functions and operations and some results puzzled me. To perform the 
tests I used massive data to minimize the effect of idle time due to priority 
handling by the operating system or whatever.

--> tic, u = rand(1,1e7); toc
ans  =
  0.4948326

This creates ten million random numbers in half a second. Very decent 
performance. Then

--> tic, v = sqrt(u); toc
ans  =
  0.282802

The algorithm for square root seems quite fast. Multiplication

--> tic, v = u.*u; toc
ans  =
  0.1218028

--> tic, v = u.*%pi; toc
ans  =
  0.119245

is really fast. But when it comes to power or exponentiation:

--> tic, v = u.^2; toc
ans  =
  1.9633435

--> tic, v = u.^%pi; toc
ans  =
  1.958321

it is quite slow. Logarithm is much faster:

--> tic, v = log(u); toc
ans  =
  0.5166959

Even the exponential function with base e is much faster:

--> tic, v = exp(u); toc
ans  =
  0.5451482

I wonder why special cases such as small integer powers are not dealt with by 
simple multiplication. Particularly the square is very frequently used on large 
vectors representing discrete signals (for instance to get energy measures) and 
no warning is issued in the documentation.

I also notice that computing the square using this formula (a cannon to kill a 
mosquito!)

--> tic, v = exp(2*log(u)); toc
ans  =
  1.2789763

is faster than using the power operator ^.

This seems to be an inconsistent approach, since many special functions are 
painstakingly tailored to be very efficient, yet one of the simplest of all 
operations, raising to power 2, is sluggishly slow...

Regards,

Federico Miyara


[https://s-install.avcdn.net/ipm/preview/icons/icon-envelope-tick-round-orange-animated-no-repeat-v1.gif]
  Libre de 
virus.www.avast.com

This email and any attachments are intended solely for the use of the 
individual or entity to whom it is addressed and may be confidential and/or 
privileged.

If you are not one of the named recipients or have received this email in error,

(i) you should not read, disclose, or copy it,

(ii) please notify sender of your receipt by reply email and delete this email 
and all attachments,

(iii) Dassault Systèmes does not accept or assume any liability or 
responsibility for any use of or reliance on this email.


Please be informed that your personal data are processed according to our data 
privacy policy as described on our website. Should you have any questions 
related to personal data protection, please contact 3DS Data Protection Officer 
https://www.3ds.com/privacy-policy/contact/

___
users mailing list - users@lists.scilab.org
Click here to unsubscribe: 
https://lists.scilab.org/mailman/listinfo/users