Date: Sun, 10 Feb 2019 23:04:03 +0100
On Sunday, 10 February 2019 22:17:13 CET Arthur O'Dwyer wrote:
> I just took a quick look at the repo, where the important code seems to be
> https://github.com/BobSteagall/wg21/blob/master/linear_algebra/code/alt_test
> .cpp
>
> I think it would be useful to write some tests that
> (A) verify that expressions are not only well-formed but also have the
> correct results (e.g.
> https://github.com/BobSteagall/wg21/blob/cb69e22fd0/linear_algebra/code/alt_
> test.cpp#L31 should probably go on to static_assert(b001) or
> static_assert(not b001) depending on your intent).
> (B) verify that some compound expressions such as `M1 + (M2 * M3)` are
> well-formed, and also that they have the correct results
> (C) include benchmarks of speed, especially for interesting compound
> expressions (I'm sure the authors of P1417R0 can give you some interesting
> expressions which come up frequently in real applications)
> (D) include benchmarks of memory usage, especially for interesting compound
> expressions. This is particularly important IMHO because it'll force you to
> "design for testability" in this area: if you can tell how much memory is
> being used by materialized temporaries, then you can also tell me how to
> use a std::pmr::memory_resource to supply memory to this library, and you
> can tell me if some innocuous-looking expression is going to blow my stack
> segment, and so on.
>
> More pie-in-the-sky-ish, I would recommend writing test templates in terms
> of WhateverMatrix<T> and then instantiating those test templates with
> T=double, T=ThinWrapperAroundDouble, and so on. (Testing with
> ThinWrapperAroundDouble is my attempt to test the optimizability of the
> actual library code, independent of any special-case specializations it
> might have for the concrete type `double`.)
Thanks for listing out all the things required. I agree with all the points
here. I have been meaning to write a separate testable implementation of my
own (much in the lines of what you said), just to make sure that the one could
reasonably reproduce the code from the specs. But I haven't started on them
yet.
> I just took a quick look at the repo, where the important code seems to be
> https://github.com/BobSteagall/wg21/blob/master/linear_algebra/code/alt_test
> .cpp
>
> I think it would be useful to write some tests that
> (A) verify that expressions are not only well-formed but also have the
> correct results (e.g.
> https://github.com/BobSteagall/wg21/blob/cb69e22fd0/linear_algebra/code/alt_
> test.cpp#L31 should probably go on to static_assert(b001) or
> static_assert(not b001) depending on your intent).
> (B) verify that some compound expressions such as `M1 + (M2 * M3)` are
> well-formed, and also that they have the correct results
> (C) include benchmarks of speed, especially for interesting compound
> expressions (I'm sure the authors of P1417R0 can give you some interesting
> expressions which come up frequently in real applications)
> (D) include benchmarks of memory usage, especially for interesting compound
> expressions. This is particularly important IMHO because it'll force you to
> "design for testability" in this area: if you can tell how much memory is
> being used by materialized temporaries, then you can also tell me how to
> use a std::pmr::memory_resource to supply memory to this library, and you
> can tell me if some innocuous-looking expression is going to blow my stack
> segment, and so on.
>
> More pie-in-the-sky-ish, I would recommend writing test templates in terms
> of WhateverMatrix<T> and then instantiating those test templates with
> T=double, T=ThinWrapperAroundDouble, and so on. (Testing with
> ThinWrapperAroundDouble is my attempt to test the optimizability of the
> actual library code, independent of any special-case specializations it
> might have for the concrete type `double`.)
Thanks for listing out all the things required. I agree with all the points
here. I have been meaning to write a separate testable implementation of my
own (much in the lines of what you said), just to make sure that the one could
reasonably reproduce the code from the specs. But I haven't started on them
yet.
-- Best Jayesh Badwaik https://jayeshbadwaik.github.io
Received on 2019-02-10 16:05:42