[Scilab-Dev] SEP#96 : cross()

[Samuel Gougeon]

Hello,

The cross() function was wished by http://bugzilla.scilab.org/9941.
It is being designed at https://codereview.scilab.org/#/c/11469/
through the Scilab Enhancement Proposal SEP#96
https://codereview.scilab.org/cat/11469%2C2%2CSEP/SEP_096_cross.odt

It's a good new! Despite this SEP has not been posted here, here are 
some free
comments about its present implementation


    Rationale

cross is an elementary function that exists in Matlab which is used to 
return the vector cross product
of two column vectors of size 3-by-1. It may be useful in mathematics, 
mechanics, etc...

Why refering to Matlab? If the simple fact that something exists in 
Matlab should turn
it useful to implement in Scilab, this opens many ways to downgrade 
Scilab. We should
publish a list, if needed. Matlab has its own drawbacks, due to its own 
history. Is it really
useful to add them to Scilab, when Scilab has sometimes better solutions 
and is fighting
its own pitfalls, bad designs, etc to reduce them?
If obviously features existing elsewhere can't be all bad, IMO to be 
available elsewhere
is not an intrinsic argument.
cross() is actually expected in mechanics and many other fields of 
physics: electromagnetism,
fluid dynamics, etc. and if it was'nt available elsewhere, it would be 
useful anyway for these
reasons. So, IMO, no need to point other lab.


      Syntax and semantics

Only one calling sequence is available:
C = cross(A,B)
A and B can be: real, complex, polynomial, sparse or boolean matrix of 
size 3-by-1.

The extension to polynomials beyond decimals is excellent. AFAIK, it is 
not available in
the other lab.
The processing of booleans should be more clearly indicated: * => AND , 
+ => OR
or %T => 1, %F => 0  (that is to say, as if bool2s() was applied before 
processing. Since this
is not yet illustrated with an example, writting something about would 
be useful, as well
as in the help page).
Rational fractions are not supported. It could be worthwhile to indicate 
this limit.
Sparsity is an encoding type rather than a data type. It could be 
indicated rather after data types.

The 3x1 size of required args is uselessly demanding and should be 
extended (see below).

*Present implementation* (patch set 2)

function  c=cross(a,b)
     // This function returns the cross product of a and b
   // (checking input arguments). Then: )
     a=[a;a];
     b=[b;b];
     c=a(2:4).*b(3:5)-b(2:4).*a(3:5);
endfunction


It is tricky and efficient.
1) Unless willing to stick to the weak implementation of other labs, 
Scilab's one can be
    easily vectorized:
c = a(2:4,:).*b(3:5,:) - b(2:4,:).*a(3:5,:);
2) About accepted formats for input args, here is a suggestion:
     -  a and b must have the same format. One of their dimensions must 
be 3.
       If both dimensions have a size of 3, calculations are done 
column-wise.
       Else, calculations are done along the dimension of size 3.
     - the result r has the same format as a and b (by the way, this is 
the way Matlab
       accepts a and b and returns r: if a and b are rows, r is a row).
3) (Option) If hypermatrices are provided, argument tests could be done 
after
     applying squeeze() to them. Hypermatices are not rare in physics. 
This is even
     rather the rule.

Hope to read comments from other potential users

Regards
Samuel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.scilab.org/pipermail/dev/attachments/20130512/4bc1753e/attachment.htm>