> With the patch: > > (1) -> m := matrix([[1, 2, 3], [4, 5, 6]]) > > +1 2 3+ > (1) | | > +4 5 6+ > Type: > Matrix(Integer) (2) -> subMatrix(m, 2, 1, 1, 2) > > (2) > Type: > Matrix(Integer) (3) -> subMatrix(m, 3, 1, 1, 2) > > >> Error detected within library code: > subMatrix: bad row indices > > (3) -> m(2..1, 1..2) > > (3) > Type: > Matrix(Integer) (4) -> m(3..1, 1..2) > > (4) > Type: > Matrix(Integer) > > In current trunk line 4 signals error. For consistency it > would be good to get the same result from (2) and (4).
If you like, we can of course change that. But we could also turn around the view point: if 2..1 does not signal an error, why should 3..1 be inconsistent with the "rule"? Depends on what we take as the rule. Signaling errors is in general a good idea, hence this might give a hint on which rule to take. OTOH we need to make sure that no code ever will use the "feature" of 2..1 and run into trouble while blindly assuming it works the same for 3..1. This might give a hint on why to handle empty slices like I did. For consistency (which I agree is also important) one could potentially change the behavior of subMatrix, given this causes not problems on other spots. I'm not really sure which point here is optimal. Maybe one should even look at how matlab/octave and python/numpy handle such slices? This could give consistency across systems and potentially match user expectations best? > BTW: Empty matrices are useful to avoid special cases. This is very true once you look at "numerical" algorithms working with matrices and slices. -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/fricas-devel. For more options, visit https://groups.google.com/d/optout.
