Re: Some questions on the interval package

[Joel Dahne]

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