<div dir="ltr"><div>BTW, <br><br></div>Scilab has always had problems to provide interfaces to languages that accept optional parameters (but not only because of it) like modern FORTRAN.<br></div><div class="gmail_extra"><br><div class="gmail_quote">2017-02-27 18:57 GMT-03:00 Adelson Oliveira <span dir="ltr"><<a href="mailto:adelson.oliveira@gmail.com" target="_blank">adelson.oliveira@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Well, now scilab 6.0 ignores named parameters at fft calls. One can check it with<br><br></div><div>fft(eye(4,4),-1,dims=4,incr=1)<wbr>-fft(eye(4,4),-1)<br><br></div><div>the result is 4X4 matrix with zeros. This is different from (without names):<br><br></div><div>fft(eye(4,4),-1,4,1)-fft(eye(<wbr>4,4),-1).<br><br></div><div>Then, I guess it is to say optional parameters are no longer "fully" optional, they must be provided in their order ...<br><br></div><div>But anyway, it seems that my personal "macros" or functions still work with named optional parameters (opt1, opt2, ....) treated as,<br><br>   if exists('opt1','local') == 0 then<br></div><div>      opt1 = default_opt1.;<br></div><div>   end<br><br></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">2017-02-27 16:18 GMT-03:00 Samuel Gougeon <span dir="ltr"><<a href="mailto:sgougeon@free.fr" target="_blank">sgougeon@free.fr</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>Le 27/02/2017 à 19:49, Tim Wescott a écrit :<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
You misread my comments.  Tim _likes_ named parameters.  If Tim were on<br>
the C++ standards committee (which is as likely as pigs flying, BTW)<br>
Tim would agitate that named parameters be adopted into that language.<br>
  Scilab, Verilog, and (I think) VHDL have it, and particularly in a<br>
language that allows for optional parameters, I feel that when you have<br>
to have function calls with more than a few parameters it vastly aids<br>
code readability.<br>
</blockquote></span>
Sorry for my misinterpretation.<br>
I agree that it is easier to use named parameters rather than to have to count and feed many "empty" or default positions to reach useful trailing ones. But when a parameter has been badly named when designing the function (*), then it is done and over. We must bear it all the time. And this is not nice at all.<br>
Same thing when you want to add a parameter that has a meaning close to another already existing one. Then keeping things (names) clear may become hard. Moreover, things get more complicated when using varargin (that ignores names).<br>
<br>
(*) this is often the case. Scilab misses a standards committee, also to well name things.<div class="m_2350099556402636870HOEnZb"><div class="m_2350099556402636870h5"><br>
<br>
______________________________<wbr>_________________<br>
users mailing list<br>
<a href="mailto:users@lists.scilab.org" target="_blank">users@lists.scilab.org</a><br>
<a href="http://lists.scilab.org/mailman/listinfo/users" rel="noreferrer" target="_blank">http://lists.scilab.org/mailma<wbr>n/listinfo/users</a><br>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>