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 |
Hi Joel,
>> 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. 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). I have also no idea right now, post this in your blog and we think later about it. 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. Looking forward for your blog post. Best, Kai |
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 |
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 |
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 |
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 |
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 |
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 |
Free forum by Nabble | Edit this page |