trick-17 / fmath Goto Github PK

• The landing page is still default: https://fmath.readthedocs.io/en/latest/

Also, more of the potential use cases should be exemplified and thoroughly explained. Especially:

• lambdas, with and without capture
• place advanced indexing/slicing in its own page with some more complicated usage examples

• min
• max
• minmax
• minmax_component

The baseline coverage is incomplete because unused template functions are not generated by the compiler. This can be fixed by instantiating templates in the unit tests. This should be all that is necessary:

template class FMath::detail::Field<FMath::Vector3, std::vector<FMath::Vector3>>;
template class FMath::detail::Field<FMath::scalar, std::vector<FMath::scalar>>;

If a function returns a field and there is no default move, the copy constructor will be used, leading to potentially significant inefficiencies.

Currently there is slicing, but more alternatives could be implemented

• slide
• chunk
• stride

See https://www.youtube.com/watch?v=-_lqZJK2vjI

See

• http://docs.conan.io/en/latest/introduction.html
• http://docs.conan.io/en/latest/howtos/header_only.html
• https://bintray.com/bincrafters/public-conan

The possibility to pass an indexing function to Field would enable use cases, such as e.g. interactions between elements of a Field.

The only other way (at least that I can currently think of) would be to implement the indexing on the library's user-side, inserting additional function(s) into the FMath namespace and then using it as if it were part of the original library.

For a very simple example, see https://godbolt.org/z/xd7abze85

Complex expressions might trigger the creation of temporaries, which might make problems even when the data memory addresses are still valid. Something like auto vf_res2 = vf1 + vf1.cross(vf2); might lead to undefined behaviour when accessing vf_res2[...] later on.

Unit tests should be written to cover the expected behaviour and guidelines should be written to explain what to avoid.

See e.g.

• https://msdn.microsoft.com/en-us/library/hh873179.aspx
• http://en.cppreference.com/w/cpp/container/unordered_map

In Field::data(), return a pointer of type T* to the first element in the Container, in analogy to std::vector<T>::data()

By adding optional template parameters, the user could choose in-code if he wants to parallelize on CPU, GPU, or not at all:

enum class Parallelisation
{
    CPU,
    GPU,
    None
}

Using constexpr if, different corresponding OpenMP code paths could be chosen.

I don't know how one could do anything like this to distinguish between cuda and cpu...

Could take some inspiration from vexcl, where traits are used e.g. to determine if a scalar may be applied to an expression with operator*.

They should be generalised to Eigen::Matrix<T> where possible and Eigen::Vector<T> otherwise.

This might make the function declaration easier, while the return type can be seen from the return statement.

This would be useful to ensure that performance is at least OK and ideally as good or better than a manually written for-loop.

In order to avoid temporaries, expression template classes need to be written for the following functions:

• norm
• squaredNorm
• normalized
• dot
• cross

It seems that the following repo must be used: https://bintray.com/danimtb/public-conan/eigen%3Adanimtb
Because the official conan repo is not up to date (v3.2, we need 3.3): https://bintray.com/conan-community/conan/eigen%3Aconan

However, I am not sure how such a recipe should look, since I do not yet use conan as a build system.