[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: |
Fri, 16 Jun 2017 11:38:47 +0000 |
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