octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Jordi Gutiérrez Hermoso
Subject: Re: Matlab references in docs; distinguishing between ML and Octave
Date: Mon, 25 Mar 2013 16:11:42 -0400

On 25 March 2013 15:21, Philip Nienhuis <address@hidden> wrote:
> Jordi Gutiérrez Hermoso wrote:
>>
>> On 24 March 2013 14:54, Philip Nienhuis<address@hidden>  wrote:

>>>
>>> 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.

No, I didn't mean "nowhere". I meant, "wherever it's relevant". We
have to distinguish between Matlab and Octave in a bunch of places.
Just grep the sources for "@sc{Matlab}" and see all the times that we
mention Matlab in the documentation.

>> 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)".

Check if the parser accepts "#" as a valid comment character, that's
my preferred method.

>>               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".

We don't have global variables in Octave, only global functions.

> 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

Sure, this works too.

>>> 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).

It's somewhat tricky. C++ is irrelevant. See the existing bug report:

    https://savannah.gnu.org/bugs/?37755

The thing is that Octave is not built (as in, compiled) the same way
that Matlab is, so the kinds of things that computer() can report for
Octave are far more than the kinds of things that Matlab's computer()
can report.

The documentation currently has a bug in that what Octave's computer()
reports is not what Octave is running on, but what it was built for.
It reports the kind of binary that this is.

Like I said in the report, I only marked that tentatively as WONTFIX,
not that it's not really a bug.

- Jordi G. H.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]