[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Update and questions regarding vecorization
From: |
Joel Dahne |
Subject: |
Re: Update and questions regarding vecorization |
Date: |
Thu, 22 Jun 2017 14:29:56 +0000 |
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