octave-maintainers
[Top][All Lists]
Advanced

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

Re: Some questions on the interval package


From: Joel Dahne
Subject: Re: Some questions on the interval package
Date: Tue, 15 Aug 2017 14:03:09 +0000

Oliver Heimlich writes:

> On 15.08.2017 14:58, Joel Dahne wrote:
>> Oliver Heimlich writes:
>>> On 15.08.2017 12:36, Oliver Heimlich wrote:
>>>>>> Given the recent hints on the mailing list regarding bug #46603, I have
>>>>>> added support for “format compact” myself.  It has been a little bit
>>>>>> complicated to come up with a solution that doesn't use internal
>>>>>> functions, doesn't rely on deprecated features, and doesn't break old
>>>>>> versions of Octave.
>>>>>
>>>>> It is indeed a bit complicated. I doesn't work for Octave version 4.2.1,
>>>>> which uses __compactformat__ for this. I have attached a patch that
>>>>> fixes it for me. But please double check that it works for you as well.
>>>>
>>>> Thanks for the patch.  I'll make a private utility function from it.
>>>
>>> Ok, done.  However, during my tests in Octave 3.8.2 I have found out
>>> that “get (0, "FormatSpacing")” is broken and always returns "loose".
>>>
>>> - In Octave < 4.0 there is no way to query that information correctly.
>>> - In Octave 4.0.x we have __compactformat__ and get (0, "FormatSpacing")
>>> - In Octave 4.2.x we have only __compactformat__
>>> - In Octave > 4.3.x we have only [~, spacing] = format ()
>>
>> But it at least works for < 4.0? It does not crash?
>
> Currently, it does not crash, but the format for intervals will always
> be “loose”.  I know a kludgy workaround, but struggle to use it.
>
>>> Looking through the other BISTs on Octave 3.8.2 (see attachement), I
>>> observe:
>>>
>>> - several warnings because of automatic broadcasting (these warning are
>>> disabled in Octave >= 4.0.0 by default)
>>
>> Most likely I'm the cause for some of these. I have never tested if for
>> < 4.0.
>
> If we keep official support for Octave < 4.0, we have to disable these
> warnings in some functions (that is, mainly in the constructors).
>
>>> - errors in the postpad and prepad functions
>>
>> Why would that be? It doesn't really use any odd functions.
>
> The old builtin *-pad functions do not allow to increase the number of
> dimensions of an array.  The following kind of test tries to do that:
>
>   postpad (infsup (0), 10, 0, 3)
>
> We would need add “if (compare_versions (OCTAVE_VERSION …” around the
> test code.
>
>>> - a failing test for disp (see above)
>>>
>>> Also, I can't use the doctest package on the manual anymore, because of
>>> missing SKIP_IF expression support and the latest doctest package has a
>>> dependency on Octave 4.0.0.
>>
>> It's though when your method for detecting the version does not work on
>> some versions...
>
> The old doctest relese did not contain support for SKIP_IF
> (…expression…).  The new doctest release requires Octave 4.0.0.  I don't
> know how to fix that instead of no longer doctest'ing the manual with
> old Octave.  On the other hand, I have no problem with the manual
> reflecting the new versions.
>
>>> I guess it's time to drop support for Octave < 4.0.0 in the interval
>>> package.
>>
>> You are probably right. How much are these used? I believe Ubuntu 14.04
>> uses 3.8.1 or something similar. Even if we formally drop support of it
>> most things will sort of work at least and we get much less to test
>> against.
>
> There is version 3.8.2 in the Google play store (GNURoot Octave), which
> I still use on my Android phone.  Also this is the official version in
> Debian Jessie, users should upgrade to Debian Stretch (and Octave 4.0.3)
> until 2018-06-17 and it is pretty easy to get 4.0.3 from the
> jessie-backports repository.  On Windows, I guess most users have
> migrated to >= 4.0.0 already, because of the GUI.
>
> My current impression is that the package would still work rather nicely
> in 3.8.2 with the following drawbacks:
>  - some tests for *-pad functions are broken
>  - “format compact” not supported
>  - several unnecessary warnings because of broadcasting
>  - doctest'ing for the manual is not possible
>
> I guess it will be best if I fix these problems (I can easily test in
> 3.8.2) and—yes—apply that pesky workaround to make “format compact” work
> in 3.8.2.

Is it a problem if some tests fail? Somehow it reflects things that they
can not use (at least for *-pad functions). That the doctest fails seems
like even less of a problem. I think very few users run the doctests
themselves.

The most annoying problem is probably the broadcasting warnings. That
"format compact" does not work seems like a minor problem since we just
implemented it so no one is used to using it.

Best,
Joel

reply via email to

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