Some questions on the interval package

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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
|  
Report Content as Inappropriate

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
|  
Report Content as Inappropriate

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
|  
Report Content as Inappropriate

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
|  
Report Content as Inappropriate

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
|  
Report Content as Inappropriate

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
|  
Report Content as Inappropriate

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
|  
Report Content as Inappropriate

[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

Loading...