Re: Update and questions regarding vecorization

[Joel Dahne]

Hi Oliver,

Oliver Heimlich writes:

> Hi Joel,
>
> On 21.06.2017 16:55, Joel Dahne wrote:
>
> Of course, you can add some hand-picked test cases at the end of the
> individual functions that you'd like to be tested, e. g., in
> inst/@infsup/sin.m you may add the cause of bug #51283.

I added this specific test!

> When you want to check all mapping functions (=functions that are
> applied element-wise on non-scalar inputs) on a large scale, I would
> suggest that we improve ITF1788:  ITF1788 currently generates a long
> list of assert statements to test arithmetic correctness of most
> functions in the package with many test cases.  The test cases are
> defined in the test/*.itl files.  That could be improved as follows:
> ITF1788 generates an Octave script, which could then generate test code
> for Octave.  The numeric test data could be stored in *.mat files and
> could then be used to (1) loop over the test data for scalar test cases
> of interval functions like the assert statements do today, to (2) test
> the mapping functions on the vectors of all test values at once, and (3)
> reshape the test data into more dimensions to also test vectorization in
> higher dimensions, and (4) check broadcasting.
>
> Do you want me to look into this during the weekend?  When you are
> unfamiliar with ITF1788, it could be distracting to start this side
> project yourself now.
I think what you propose is a good idea. Then we can generate lots of
tests for all relevant functions. This would help us to catch bugs like
the one for sinus.

If you can take a look at it that's probably a good idea. From what I
understand it's mainly a matter of adding more ways to parse the test
data?

> Do it if you like.  I have been too lazy to write an indexing expression
> to short-circuit the correct subset of the N-D array.  You may either
> send a separate patch (patch tracker) or commit it to your repo, from
> where I will eventually merge it anyway.
>
I have made a note about it at least, might fix it later on.

>> sin.m:
>> See https://savannah.gnu.org/bugs/index.php?51283. We should probably
>> add a work around for this. Or perhaps wait and see what Octave does
>> with it?
>
> Thanks for the bug report.  I have added a comment.  Please use the work
> around to also support current versions of Octave.

I added the workaround

> Did you measure execution times?  When I last checked it with
> non-broadcasting vectors, it wasn't worth the effort (except for corner
> cases).  With broadcasting this should be no different.
>
> However, this might have changed or I might be wrong.  You may try to
> find a faster solution.  The times function is not that complicated and
> we have lots of unit tests for regression testing.  If you find a faster
> algorithm that'd be good.  However, you should measure execution times
> for several input constellations.

I have not done any measurements. Made a note about it and might look at
it later on.

Best,
Joel