<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">Hello Pierre-Aimé,<br>
      <br>
      Le 10/08/2016 17:56, Pierre-Aimé Agnel a écrit :<br>
    </div>
    <blockquote
      cite="mid:db8c8fe7-8ff5-bdc6-888c-20e837cdba01@scilab-enterprises.com"
      type="cite">
      <meta content="text/html; charset=windows-1252"
        http-equiv="Content-Type">
      <p><font face="Calibri">Hello,</font></p>
      <p><font face="Calibri">It was changed at resolution of <a
            moz-do-not-send="true" class="moz-txt-link-freetext"
            href="http://bugzilla.scilab.org/show_bug.cgi?id=14316"><a class="moz-txt-link-freetext" href="http://bugzilla.scilab.org/show_bug.cgi?id=14316">http://bugzilla.scilab.org/show_bug.cgi?id=14316</a></a></font></p>
      <p><font face="Calibri">I am not sure though whether enforcing the
          'vector ^ scalar' error should be reintroduced. My 2-cents:
          there are many operations that have the same behaviour that
          their dot-operation counterpart when used with a scalar.<br>
        </font></p>
      <p><font face="Calibri">I think the operation should remain
          available, but I can also enforce the obsolescence in the
          release for 6.0.0.</font></p>
    </blockquote>
    <br>
    <font face="Calibri">Thanks for your answer.<br>
      I understand that the reversion of the vector^scalar change was
      done when fixing #14316,<br>
      but as far as i understand, things are not connected. This
      reversion was not mandatory to fix #14346.<br>
      <br>
      IMO, what was planed for Scilab 6 was great. <br>
      <br>
      I know that this syntax vector^scalar instead of vector.^scalar
      was very widespread. But instead of parsing </font><font
      face="Calibri">vector^scalar as </font><font face="Calibri">vector.^scalar
      as in Scilab <6 or always yielding an error, why not making
      Scilab 6 testing whether the overload %s_p_s() (or other%@_p_@()
      overload according to operands types) exists. Then, users wanting
      to work with the old equivocal behavior could define
      deff("r=%s_p_s(a,b)","r=a.^b") in their library (or startup file)
      instead of changing all their code. Or/and include their own
      warning in their overload whether they wish to actually upgrade
      their code. And that's it.<br>
      <br>
      Best regards<br>
      Samuel<br>
    </font><br>
  </body>
</html>