Some questions on the interval package

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
18 messages Options
Reply | Threaded
Open this post in threaded view
|

Some questions on the interval package

Urathai
Hi!

I have begun the work on adding support for constructing and printing
N-dimensional interval arrays. Most of the functions are just wrappers
around Octaves standard functions and thus do not need much
changes. However for some functions I'm not sure how to handle the
changes for. I list the ones I have questions about. More information about
the rest of the work will come in a blog-post tomorrow or on Friday. I
have pushed most of the changes to my remote repository, so if you want
to try the new functionality you can clone that.

disp.m: When printing an array with more than 2 dimensions I have
followed the normal Octave style. It looks like
 ans(:,:,1) =

   [0]   [0]
   [0]   [0]
Should we use an equality sign here only when the representation is
exact and a subset sign otherwise? It might happen that some submatrices
are exact and others not. Should we use a subset sign on all submatrices
if at least one is not exact? Currently I use equality signs everywhere.

linspace.m and mince.m: In the standard implementation these can only
take scalars or vectors as input. They could however be generalized to
also allow for N-dimensional arrays as input, but this has not been
done. Should we implement this for intervals? The same questions goes
for mince.m which is just an interval generalization if linspace.m.

interval_bitpack, __split_interval_literals__.m, exacttointerval.m: I
see no obvious way to generalize these to N dimensions. For example the
standard bitpack only returns vectors. The function
__split_interval_literals__ is used to split up a string representing a
vector or a matrix of intervals. As far as I know there is no way to
create an array with more than 2 dimensions using strings.

meshgrid.m, ndgrid.m: The interval package has no implementation of
ndgrid so my idea was to add it. Then I realized that the standard
implementation of ndgrid actually works for intervals as well. That is
the case for the standard meshgrid as well. There is however a
difference compared to the interval version of meshgrid, the standard
version does no convert all input to intervals, it allows non-uniform
output (try for example [x y] = ndgrid (infsup (1:3), 4:6)). This is
probably intended, in some cases you might want a grid of different
types. However since the interval version of meshgrid overloads the
standard version this cannot be done for intervals. The question is:
should we overload ndgrid with one that converts all input to interval
or should we remove meshgrid and fall back to the standard
implementation? I at least think it is reasonable to handle them both in
the same way.

I think that is all the questions I have for now.

Regards,
Joel

Reply | Threaded
Open this post in threaded view
|

Re: Some questions on the interval package

siko1056
Hi Joel,

Urathai wrote
disp.m: When printing an array with more than 2 dimensions I have
followed the normal Octave style. It looks like
 ans(:,:,1) =

   [0]   [0]
   [0]   [0]
Should we use an equality sign here only when the representation is
exact and a subset sign otherwise? It might happen that some submatrices
are exact and others not. Should we use a subset sign on all submatrices
if at least one is not exact? Currently I use equality signs everywhere.
>> A = infsup(zeros(2),0)
A = 2×2 interval matrix

   [0]   [0]
   [0]   [0]

>> A(1,1) += 0.1
A ⊂ 2×2 interval matrix

   [0.1, 0.10001]   [0]
              [0]   [0]

>> A(2,2)
ans = [0]
>> A(1,1)
ans ⊂ [0.1, 0.10001]

I think the convention becomes clear from this. If *all displayed* (vs. *all*) matrix elements are exact, use the equal sign, otherwise the subset sign.

Urathai wrote
linspace.m and mince.m: In the standard implementation these can only
take scalars or vectors as input. They could however be generalized to
also allow for N-dimensional arrays as input, but this has not been
done. Should we implement this for intervals? The same questions goes
for mince.m which is just an interval generalization if linspace.m.
I would not extend them to N-d arrays. For linspace Octave extends the functionality to vector inputs (which is not Matlab compatible)  the output is/are a row vector/s. For matrices or N-d arrays one really has to think about what the result should be and where this is useful? The mince function was introduced by Oliver to partition an interval (his intention seems to be that of a scalar interval quantity) to support his plotting of intervals. I see three options to proceed with mince: a) make it private, just for the plotting purpose b) document that is was only for scalars and check for it c) make an element-wise operation (recursion) in case of N-d arrays. I favor b).

Urathai wrote
interval_bitpack, __split_interval_literals__.m, exacttointerval.m: I
see no obvious way to generalize these to N dimensions. For example the
standard bitpack only returns vectors. The function
__split_interval_literals__ is used to split up a string representing a
vector or a matrix of intervals. As far as I know there is no way to
create an array with more than 2 dimensions using strings.
I have also no idea right now, post this in your blog and we think later about it.

Urathai wrote
meshgrid.m, ndgrid.m: The interval package has no implementation of
ndgrid so my idea was to add it. Then I realized that the standard
implementation of ndgrid actually works for intervals as well. That is
the case for the standard meshgrid as well. There is however a
difference compared to the interval version of meshgrid, the standard
version does no convert all input to intervals, it allows non-uniform
output (try for example [x y] = ndgrid (infsup (1:3), 4:6)). This is
probably intended, in some cases you might want a grid of different
types. However since the interval version of meshgrid overloads the
standard version this cannot be done for intervals. The question is:
should we overload ndgrid with one that converts all input to interval
or should we remove meshgrid and fall back to the standard
implementation? I at least think it is reasonable to handle them both in
the same way.
If I get you right, you suggest that just removing @infsup/meshgrid.m generalized the application of creating grids with interval quantities? That would be good news! Can you post some demonstrations of this in your blog and Oliver can reason about this. Maybe there was a problem in prior versions of Octave just using the builtin meshgrid with user defined classes like @infsup.

Urathai wrote
I think that is all the questions I have for now.

Regards,
Joel
Looking forward for your blog post.

Best,
Kai
Reply | Threaded
Open this post in threaded view
|

Re: Some questions on the interval package

Oliver Heimlich
In reply to this post by Urathai
Hi Joel,

On 14.06.2017 12:05, Joel Dahne wrote:
> Hi!
>
> I have begun the work on adding support for constructing and printing
> N-dimensional interval arrays.

I have reviewed and merged your first bulk of work.  Review comments:

Revision 892 (@infsup/disp.m): You can probably eliminate the for loop
(1:ndims (x) - 2) with: sprintf (repmat (",%d", 1, ndims (x) - 2), …

Revision 893 (@infsup/display.m): You should start the new for loop
(3:ndims(x)) from 2, or use repmat like above to simplify the code.

Revision 895 (hull.m):
 - Why is the dimension mismatch case no longer an error?
 - Before the new check for “or (targetsize == sizes, sizes == 1)” you
should add “warning ("off", "Octave:broadcast", "local");” Otherwise
Octave 3.8 will complain.

Revision 902 (nai.m): The new test should explicitly check against the
expected result “true (2, 2, 2)”.

Revision 904 (size.m): You should change the texinfo macro @defmethod
into @deftypemethod and put the output arguments into curly braces.
Also you should format the new help text with @command{size} macros
(instead of plain quation marks).


> Most of the functions are just wrappers
> around Octaves standard functions and thus do not need much
> changes.

Nevertheless you have to check them, so no need to play down the work
that you do ;-)  It's good to see how well you handle the cases where
change is required.


> However for some functions I'm not sure how to handle the
> changes for. I list the ones I have questions about. More information about
> the rest of the work will come in a blog-post tomorrow or on Friday. I
> have pushed most of the changes to my remote repository, so if you want
> to try the new functionality you can clone that.

Done and already merged your changes.  Nice work so far!


> disp.m: When printing an array with more than 2 dimensions I have
> followed the normal Octave style. It looks like
>  ans(:,:,1) =
>
>    [0]   [0]
>    [0]   [0]

Two small observations:

 1. The matrix label “ans(:,:,…)” should not be indented.
 2. Before the matrix label you need an additional blank line (not
before the first one). Remark: disp.m currently only supports “format
loose”, where there are blank lines between matrix labels and matrices.
Feel free to add support for “format compact”, but I don't know how to
properly detect the current display mode.


> Should we use an equality sign here only when the representation is
> exact and a subset sign otherwise? It might happen that some submatrices
> are exact and others not. Should we use a subset sign on all submatrices
> if at least one is not exact? Currently I use equality signs everywhere.

I'd prefer to either support the subset sign at this point, or
completely get rid of the subset sign (for consistency).  If you want to
support the subset sign, you probably have to change the isexact output
argument of “intervaltotext” into an N-D array (instead of a scalar).
That means you also have to dig into mpfr_to_string_d.


> linspace.m and mince.m: In the standard implementation these can only
> take scalars or vectors as input. They could however be generalized to
> also allow for N-dimensional arrays as input, but this has not been
> done. Should we implement this for intervals? The same questions goes
> for mince.m which is just an interval generalization if linspace.m.

Yes, that'd be useful to support N-D arrays as input.  Following the
behavior of the standard linspace in Octave, I'd say that we should
simply convert the input into column vectors.  IIRC, this is already
done inside mpfr_linspace_d.  The output will always be 2-D then.


I will answer your other remaining questions later in a second mail.

Best
Oliver

Reply | Threaded
Open this post in threaded view
|

Re: Some questions on the interval package

siko1056
Oliver Heimlich wrote
[snip]
> linspace.m and mince.m: In the standard implementation these can only
> take scalars or vectors as input. They could however be generalized to
> also allow for N-dimensional arrays as input, but this has not been
> done. Should we implement this for intervals? The same questions goes
> for mince.m which is just an interval generalization if linspace.m.

Yes, that'd be useful to support N-D arrays as input.  Following the
behavior of the standard linspace in Octave, I'd say that we should
simply convert the input into column vectors.  IIRC, this is already
done inside mpfr_linspace_d.  The output will always be 2-D then.


I will answer your other remaining questions later in a second mail.

Best
Oliver
Oliver, I am afraid, that we are "over-mentoring" Joel, especially if we have different points of view about certain aspects. But I felt to answer Joel after one day. To resolve this in the future, I suggest to continue as backup mentor and provide technical help (about how to revolve errors or how to archive this or that) and leave design decisions to you Oliver as package maintainer.

Kai
Reply | Threaded
Open this post in threaded view
|

Re: Some questions on the interval package

Urathai
In reply to this post by Oliver Heimlich

Hi Oliver

Oliver Heimlich writes:

> Hi Joel,
>
> On 14.06.2017 12:05, Joel Dahne wrote:
>> Hi!
>>
>> I have begun the work on adding support for constructing and printing
>> N-dimensional interval arrays.
>
> I have reviewed and merged your first bulk of work.  Review comments:
>
> Revision 892 (@infsup/disp.m): You can probably eliminate the for loop
> (1:ndims (x) - 2) with: sprintf (repmat (",%d", 1, ndims (x) - 2), …
>
> Revision 893 (@infsup/display.m): You should start the new for loop
> (3:ndims(x)) from 2, or use repmat like above to simplify the code.
>
> Revision 895 (hull.m):
>  - Why is the dimension mismatch case no longer an error?
>  - Before the new check for “or (targetsize == sizes, sizes == 1)” you
> should add “warning ("off", "Octave:broadcast", "local");” Otherwise
> Octave 3.8 will complain.
>
> Revision 902 (nai.m): The new test should explicitly check against the
> expected result “true (2, 2, 2)”.
>

I have fixed all of the above problems. Actually "sprintf" can handle
vectors in a nice way, so it was even easier than I thought.

> Revision 904 (size.m): You should change the texinfo macro @defmethod
> into @deftypemethod and put the output arguments into curly braces.
> Also you should format the new help text with @command{size} macros
> (instead of plain quation marks).
>

I have done these changes. I will have to learn a bit more about texinfo
to understand what I'm doing though. Is it for 'make html' that the
texinfo is used? Because from what I can tell it is not visible in the
help text inside Octave.

>> disp.m: When printing an array with more than 2 dimensions I have
>> followed the normal Octave style. It looks like
>>  ans(:,:,1) =
>>
>>    [0]   [0]
>>    [0]   [0]
>
> Two small observations:
>
>  1. The matrix label “ans(:,:,…)” should not be indented.
>  2. Before the matrix label you need an additional blank line (not
> before the first one). Remark: disp.m currently only supports “format
> loose”, where there are blank lines between matrix labels and matrices.
> Feel free to add support for “format compact”, but I don't know how to
> properly detect the current display mode.
>

I have fixed the observations you made! Have not added support for
"format compact" though, I don't know how to properly detect this
either.

>
>> Should we use an equality sign here only when the representation is
>> exact and a subset sign otherwise? It might happen that some submatrices
>> are exact and others not. Should we use a subset sign on all submatrices
>> if at least one is not exact? Currently I use equality signs everywhere.
>
> I'd prefer to either support the subset sign at this point, or
> completely get rid of the subset sign (for consistency).  If you want to
> support the subset sign, you probably have to change the isexact output
> argument of “intervaltotext” into an N-D array (instead of a scalar).
> That means you also have to dig into mpfr_to_string_d.
>

I don't think it's clear how we should do it. I wrote a bit about it on
my blog, see what you think about that.

>
>> linspace.m and mince.m: In the standard implementation these can only
>> take scalars or vectors as input. They could however be generalized to
>> also allow for N-dimensional arrays as input, but this has not been
>> done. Should we implement this for intervals? The same questions goes
>> for mince.m which is just an interval generalization if linspace.m.
>
> Yes, that'd be useful to support N-D arrays as input.  Following the
> behavior of the standard linspace in Octave, I'd say that we should
> simply convert the input into column vectors.  IIRC, this is already
> done inside mpfr_linspace_d.  The output will always be 2-D then.
>

Then I might take a look at this when I start with vectorization next
week.

Best,
Joel

Reply | Threaded
Open this post in threaded view
|

Re: Some questions on the interval package

Oliver Heimlich
In reply to this post by Urathai
Hi Joel,

thanks for your blog post [1] and let me address the remaining questions.

On 14.06.2017 12:05, Joel Dahne wrote:
> interval_bitpack, __split_interval_literals__.m, exacttointerval.m: I
> see no obvious way to generalize these to N dimensions. For example the
> standard bitpack only returns vectors. The function
> __split_interval_literals__ is used to split up a string representing a
> vector or a matrix of intervals. As far as I know there is no way to
> create an array with more than 2 dimensions using strings.

As you've already stated in the blog, there is no obvious way to denote
interval literals in 3 dimensions as strings.  So you can leave
__split_interval_literals__ as is.
*go-to-next-entry-in-third-dimension-emoji*

interval_bitpack should accept logical ND arrays as input, but the
output will always be a 2D.  That's what is supported by the built-in
bitpack function.

> meshgrid.m, ndgrid.m: The interval package has no implementation of
> ndgrid so my idea was to add it. Then I realized that the standard
> implementation of ndgrid actually works for intervals as well. That is
> the case for the standard meshgrid as well. … The question is:
> should we overload ndgrid with one that converts all input to interval
> or should we remove meshgrid and fall back to the standard
> implementation? I at least think it is reasonable to handle them both in
> the same way.

After reading your reasoning in the blog post, I agree that you should
remove the meshgrid implementation.  Additional thoughts on the topic:

 - meshgrid does not combine values from its arguments, it only combines
their size.  So this is not an interval arithmetic function (range
evaluation), where you'd expect interval enclosure for the overall
output.  Each argument is manipulated (resized) individually, so there's
no need to change types.

 - meshgrid does not introduce numeric errors.  Good.

 - meshgrid is mainly used for plotting, and it is no problem to pass
output to the plotting functions even if not all parameters are intervals.

 - If you remove meshgrid, please remember to update INDEX and describe
the changed behavior in doc/NEWS.texinfo for the upcoming release.  The
upcoming version number will be at least 2.2.0, not 2.1.1.

 - You should move the (revised) tests for meshgrid into a new file
inst/test/meshgrid.tst.  This way we can verify correctness of the
function, which is no longer part of the package.  Execute the test with
“test test/meshgrid.tst” inside Octave or with with “make test-bist” (or
as part of the full test suite “make check”).

Best
Oliver


[1] https://gsocinterval.blogspot.de/2017/06/construction-and-printing.html

Reply | Threaded
Open this post in threaded view
|

Re: Some questions on the interval package

Oliver Heimlich
In reply to this post by siko1056
On 15.06.2017 14:24, siko1056 wrote:
> Oliver, I am afraid, that we are "over-mentoring" Joel, especially if we
> have different points of view about certain aspects. But I felt to answer
> Joel after one day. To resolve this in the future, I suggest to continue as
> backup mentor and provide technical help (about how to revolve errors or how
> to archive this or that) and leave design decisions to you Oliver as package
> maintainer.

Oh, what a coincidence.  Kai, I didn't see your answer before pressing
my send button.  So we got two independent answers for Joel.

I rather see my comments as suggestions to Joel and hope that he
resolves any contradictions while coding along. ;-)  Please continue to
give advice as you see fit, since I am not available 24/7 and sometimes
require more time to answer.

Also, you bring in the user perspective for the package, which I don't have.

Oliver

Reply | Threaded
Open this post in threaded view
|

[GSoC interval package] Code Review

Oliver Heimlich
In reply to this post by Urathai
Hi Joel,

I have looked at your latest changes.

- Line continuation characters missing here after reformatting?
https://sourceforge.net/u/urathai/octave/ci/b25fbf0ad324af2e27d02379ce58983e532a9f33/tree/inst/@infsup/infsup.m#l277

On 16.06.2017 13:38, Joel Dahne wrote:
> Oliver Heimlich writes:
>> On 14.06.2017 12:05, Joel Dahne wrote:
>>> I have begun the work on adding support for constructing and printing
>>> N-dimensional interval arrays.
>>
>> I have reviewed and merged your first bulk of work.  Review comments:
>> …
> I have fixed all of the above problems. Actually "sprintf" can handle
> vectors in a nice way, so it was even easier than I thought.

Nice!

>> Revision 904 (size.m): You should change the texinfo macro @defmethod
>> into @deftypemethod and put the output arguments into curly braces.
>> Also you should format the new help text with @command{size} macros
>> (instead of plain quation marks).

> I have done these changes. I will have to learn a bit more about texinfo
> to understand what I'm doing though. Is it for 'make html' that the
> texinfo is used? Because from what I can tell it is not visible in the
> help text inside Octave.

Found more Texinfo pitfalls:

In size.m, when you change from @defmethod to @deftypemethod it is
necessary to also update the corresponding @end macro.  You can think of
\begin{x} … \end{x} in Tex.

In infsup.m and disp.m please make sure that you put 2 spaces between
two sentences which end and start on the same line.  Otherwise Texinfo
might conclude that the period is used for an abbreviation and not to
end the sentence.

More background information:
https://www.gnu.org/software/texinfo/manual/texinfo/html_node/Not-Ending-a-Sentence.html

>>> disp.m: When printing an array with more than 2 dimensions I have
>>> followed the normal Octave style. It looks like
>>>  ans(:,:,1) =
>>>
>>>    [0]   [0]
>>>    [0]   [0]
>>
>> Two small observations:
>>
>>  1. The matrix label “ans(:,:,…)” should not be indented.
>>  2. Before the matrix label you need an additional blank line (not
>> before the first one). Remark: disp.m currently only supports “format
>> loose”, where there are blank lines between matrix labels and matrices.
>> Feel free to add support for “format compact”, but I don't know how to
>> properly detect the current display mode.
>>
>
> I have fixed the observations you made! Have not added support for
> "format compact" though, I don't know how to properly detect this
> either.

Ok.  Rik has provided a way to detect the current format.  However,
since this is a feature yet to come in a future release of Octave, we
can delay this topic for now.

Best
Oliver

Reply | Threaded
Open this post in threaded view
|

Re: Some questions on the interval package

Oliver Heimlich
In reply to this post by Urathai
On 16.06.2017 13:38, Joel Dahne wrote:

>>> disp.m: When printing an array with more than 2 dimensions I have
>>> followed the normal Octave style. It looks like
>>>  ans(:,:,1) =
>>>
>>>    [0]   [0]
>>>    [0]   [0]
>> Two small observations:
>>
>>  1. The matrix label “ans(:,:,…)” should not be indented.
>>  2. Before the matrix label you need an additional blank line (not
>> before the first one). Remark: disp.m currently only supports “format
>> loose”, where there are blank lines between matrix labels and matrices.
>> Feel free to add support for “format compact”, but I don't know how to
>> properly detect the current display mode.
>>
> I have fixed the observations you made! Have not added support for
> "format compact" though, I don't know how to properly detect this
> either.

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.

Oliver


https://sourceforge.net/p/octave/interval/ci/edb13a8ea57ad674c6ac9dc5b67169e32f24e11b/

http://hg.savannah.gnu.org/hgweb/octave/rev/f84aa17075d4

Reply | Threaded
Open this post in threaded view
|

Re: Some questions on the interval package

Oliver Heimlich
On 15.08.2017 11:16, Joel Dahne wrote:

>
> Oliver Heimlich writes:
>
>> On 16.06.2017 13:38, Joel Dahne wrote:
>>>>> disp.m: When printing an array with more than 2 dimensions I have
>>>>> followed the normal Octave style. It looks like
>>>>>  ans(:,:,1) =
>>>>>
>>>>>    [0]   [0]
>>>>>    [0]   [0]
>>>> Two small observations:
>>>>
>>>>  1. The matrix label “ans(:,:,…)” should not be indented.
>>>>  2. Before the matrix label you need an additional blank line (not
>>>> before the first one). Remark: disp.m currently only supports “format
>>>> loose”, where there are blank lines between matrix labels and matrices.
>>>> Feel free to add support for “format compact”, but I don't know how to
>>>> properly detect the current display mode.
>>>>
>>> I have fixed the observations you made! Have not added support for
>>> "format compact" though, I don't know how to properly detect this
>>> either.
>>
>> 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.

Oliver

Reply | Threaded
Open this post in threaded view
|

Re: Some questions on the interval package

Oliver Heimlich
On 15.08.2017 12:36, Oliver Heimlich wrote:

> On 15.08.2017 11:16, Joel Dahne wrote:
>>
>> Oliver Heimlich writes:
>>
>>> On 16.06.2017 13:38, Joel Dahne wrote:
>>>>>> disp.m: When printing an array with more than 2 dimensions I have
>>>>>> followed the normal Octave style. It looks like
>>>>>>  ans(:,:,1) =
>>>>>>
>>>>>>    [0]   [0]
>>>>>>    [0]   [0]
>>>>> Two small observations:
>>>>>
>>>>>  1. The matrix label “ans(:,:,…)” should not be indented.
>>>>>  2. Before the matrix label you need an additional blank line (not
>>>>> before the first one). Remark: disp.m currently only supports “format
>>>>> loose”, where there are blank lines between matrix labels and matrices.
>>>>> Feel free to add support for “format compact”, but I don't know how to
>>>>> properly detect the current display mode.
>>>>>
>>>> I have fixed the observations you made! Have not added support for
>>>> "format compact" though, I don't know how to properly detect this
>>>> either.
>>>
>>> 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 ()

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)
- errors in the postpad and prepad functions
- 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.

I guess it's time to drop support for Octave < 4.0.0 in the interval
package.

Oliver

Octave 3.8.2 fntest.log (20K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Some questions on the interval package

Urathai

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?

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

> - errors in the postpad and prepad functions

Why would that be? It doesn't really use any odd functions.

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

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

Best,
Joel



> Oliver
Reply | Threaded
Open this post in threaded view
|

Re: Some questions on the interval package

Daniel Sebald
In reply to this post by Oliver Heimlich
On 08/15/2017 06:46 AM, Oliver Heimlich wrote:
> 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".

Several other results concerning get() don't seem correct, e.g., 'default'.

Dan

Reply | Threaded
Open this post in threaded view
|

Re: Some questions on the interval package

Oliver Heimlich
In reply to this post by Urathai
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.

Oliver

Reply | Threaded
Open this post in threaded view
|

Re: Some questions on the interval package

Urathai

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 | Threaded
Open this post in threaded view
|

Re: Some questions on the interval package

Oliver Heimlich
On 15.08.2017 16:03, Joel Dahne wrote:

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

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

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

>>>> I guess it's time to drop support for Octave < 4.0.0 in the interval
>>>> package.

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

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

I have fixed the “format compact” detection for Octave 3.8.2, added
conditional skips for the *-pad tests, and suppressed the broadcasting
warning, which have been observerd during testing.  Now, all BISTs and
all doctests for function docstrings pass in Octave 3.8.2.

We are back to full support for Octave 3.8.x :-)  IMHO, all tests must
pass for any supported version of Octave.  Otherwise, it would not be
possible to easily check correctness of the package for the user.

Regarding the postpad and prepad functions it is okay to reflect the
features of core Octave in the respective version.

Oliver

Reply | Threaded
Open this post in threaded view
|

Re: Some questions on the interval package

Urathai

Oliver Heimlich writes:

> On 15.08.2017 16:03, Joel Dahne wrote:
>> 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.
>>>>>
>>>>> 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 ()
>
>>>>> 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.
>
>>>>> - 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.
>
>>>>> I guess it's time to drop support for Octave < 4.0.0 in the interval
>>>>> package.
>
>>> 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
>
>> 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.
>
> I have fixed the “format compact” detection for Octave 3.8.2, added
> conditional skips for the *-pad tests, and suppressed the broadcasting
> warning, which have been observerd during testing.  Now, all BISTs and
> all doctests for function docstrings pass in Octave 3.8.2.
>
> We are back to full support for Octave 3.8.x :-)  IMHO, all tests must
> pass for any supported version of Octave.  Otherwise, it would not be
> possible to easily check correctness of the package for the user.
>
> Regarding the postpad and prepad functions it is okay to reflect the
> features of core Octave in the respective version.

I like you workaround for detecting "format compact". Great that you
could get everything to work.

I have not yet pushed the change I had to do to the Makefile for it to
work. That is changing "source (file)" to "source (file{:})" on line
367. Does it work for you without that change? If so, why?

I'm continuing to work on the Taylor package. It seems to be a great way
to find bugs in the Interval package!

Best,
Joel
Reply | Threaded
Open this post in threaded view
|

Re: Some questions on the interval package

Oliver Heimlich
On 16.08.2017 10:36, Joel Dahne wrote:
> I have not yet pushed the change I had to do to the Makefile for it to
> work. That is changing "source (file)" to "source (file{:})" on line
> 367. Does it work for you without that change? If so, why?

I guess that the source function is more tolerant in old Octave versions
that I use.  The old code works in Octave 4.0 and 3.8. That change
should be unproblematic.  Please also apply Mike's other compilation fix
from bug #51763.

> I'm continuing to work on the Taylor package. It seems to be a great way
> to find bugs in the Interval package!

Definitely!  So far I have barely received feedback from users.
Building a new package on top of it will be valuable quality assurance.

Oliver