Hello Adelson,
Le 27/02/2017 à 15:46, Adelson Oliveira a écrit :
Hi,
Let's take fft as an example.
In scilab 5 one could call fft specifying parameters like dim and incr
by name,
fft(A,-1,dim=100,incr=1)
Here names are simply ignored. There would be a true call by names if
the order would not matter, while it does:
-->Fp2 = fft(A,-1,incr=1,dim=100);
!--error 999
fftw: Wrong values for input argument #3: Elements must be greater than 1.
I guess that this is because fft() is a built-in, not a "macro".
But even for functions written in Scilab language (aka macros), passing
named parameters is strongly discouraged:
* this sets a formal link between the calling level and the inner
called one. Then, any change of the parameters names in the function
definition breaks such calls.
* the definition of most (say 99%) scilab functions test input
parameters against their position rather than their name. It is not
robust, but so it is. So (provided that fft() would be a macro) when
calling fft(1,-1,incr=1), incr is detected at the third position
while in the definition it is listed in the 4th one. Really
efficient to get a mess ;)
function test(a, b)
mprintf("RHS=%d, exists(a)=%d exists(b)=%d\n", argn(2), exists("a","l"),
exists("b","l"))
endfunction
-->test(b=1)RHS=1, exists(a)=0 exists(b)=1-->test(b=1,a=2)RHS=2,
exists(a)=1 exists(b)=1
So, Tim is right. Calls with named parameters make the code fragile, or
make somewhat harder to code the analysis of input arguments in a robust
way. This coding way still increases functions overheads, that make them
slower.
Samuel
_______________________________________________
users mailing list
[email protected]
http://lists.scilab.org/mailman/listinfo/users
