Re: Ideas for auto BSX

[Juan Pablo Carbajal]

2011/12/14 Jordi Gutiérrez Hermoso <address@hidden>:
> 2011/12/14 Judd Storrs <address@hidden>:
>> 2011/10/1 Jordi Gutiérrez Hermoso <address@hidden>:
>>> As I've said before, I don't see "Matlab compatibility" to be anything
>>> more than source compatibility. If it runs in Matlab, it should run in
>>> Octave and produce almost the same result (perhaps slight variation in
>>> graphics is acceptable, for example). I don't see making everything in
>>> Octave working and looking exactly like Matlab to be the goal. We
>>> already have lots of other nice Octave-only language features (e.g.
>>> being able to define functions interactively without needing a
>>> separate file for each or being able to index temporaries), and that's
>>> not lack of Matlab compatibility.
>>
>> One thing that just occurred to me is: does it become much more
>> difficult to automatically translate octave code into code that will
>> run in matlab?
>
> Octave already has a bunch of code that is difficult to automatically
> translate into Matlab. Unwind-protect? Functions defined in script
> files as opposed to function files? Generating intermediate variables
> when indexing temporaries?
>
> - Jordi G. H.

Jordi I do like the auto bsx, but I agree with Judd. It may create
more problems in translation.
I am a supporter for having a clear translation table between Octave
and ML, I collaborate a lot with people that only use ML, and so far
things are going good with a small translation table, but I think, as
Judd, that this case would be not so easily detected.
One thing is to have different code (all the cases you mentioned) that
can be easily identified (even automatically), but how would you
recognize
a - b
to be
bsxfun(@minus,a,b)?

Only a parser with access to the sizes of the variables will be able
to translate that.

Just my thoughts,

-- 
M. Sc. Juan Pablo Carbajal
-----
PhD Student
University of Zürich
http://ailab.ifi.uzh.ch/carbajal/