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




--
View this message in context: 
http://octave.1599824.n4.nabble.com/Some-questions-on-the-interval-package-tp4683685p4683692.html
Sent from the Octave - Maintainers mailing list archive at Nabble.com.