Re: Matlab references in docs; distinguishing between ML and Octave

[Philip Nienhuis]

Jordi Gutiérrez Hermoso wrote:
> On 24 March 2013 14:54, Philip Nienhuis<address@hidden>  wrote:
:
<snip>
:
> > 2. What would be a good place in the doc for a description of how to
> > distinguish between ML and Octave?
>
> Whenever it's impossible to make Octave behave like Matlab, we
> acknowledge this impossibility and make a note in the documentation.

That's an answer to another, related question :-)

If you mean to say "nowhere", please do.

> We can't document how to tell if you're in Matlab, because that job is
> for Matlab's own documentation.

For your convenience, my question could be rephrased as "how can we tell 
if we're in Octave (rather than Matlab)". Of course, once a script knows 
it isn't invoked in Octave, it must have been invoked by Matlab so it's 
merely semantical cosmetics.

>               If that method changes, it would be
> silly for our docs to go out of date. We can, however, document things
> such the OCTAVE_VERSION function that probably only exist in Octave.

Or OCTAVE_HOME, or any other built-in global variable starting with 
"OCTAVE".
FYI, what I head in mind is something along the lines of


function [ ret ] = isoctave ()

  persistent isoct;
  if (isempty (isoct))
    isoct = exist ('OCTAVE_VERSION', 'var');
  end %if
  ret = isoct;

end %function

A similar construct is currently in the Java texi file (but maybe not 
much longer).

> > 3. A way to distinguish Octave and ML, that works in both, could be to use
> > the "computer" function;
>
> There is no reason why this should be different in both. The only
> reason it's different is that we haven't figured out how to make it
> the same. We probably will never be able to make it the same in both,

??
Maybe not perpetually the same, but IMO amending "computer()" to e.g., 
return "win32" rather than "mingw32-i686" on Windows platforms, doesn't 
look like a Herculian task to me (but OK my C++ proficiency is lacking).

Or is there too much code out there relying on the current behavior of 
this function?

> but it's a quirk, not a design feature, that this function is
> different from Matlab.

Would you like me to enter a bug report for this?

Thanks Jordi,

Philip