Ja, passt so.

No, I think a vector is fine here.

Yes, I would think so.

I am no pro on this. @juhasz could you please help out?

Again, I think vectors are fine here

If you use std::min and std::max you can delete them, right? I am fairly certain that the standard function do exactly what you want. You could use a 'using' statement to define an alias so you can call them as fuzzyAnd / fuzzyOr for readability though.

Yes, I think std::min improves readability.

Keep it as it was in your old code for now so we can reproduce results as close as possible. Once everything is up and running, we can think of such things.
(maybe keep a TODO comment here)

Ok, passt. Aber bissl weiter oben is auch noch eine FRage an dich. Bei den Template typnames.

Yes, but I think that in the beginning (when a state has only one, two or a few samples inside and maybe gets discarded again), a vector makes sense. However, if the the whole sample history is full, this vector is also full. And when the size does not change anymore, an array is faster or not? Even when the history is not full, I can only check the already saved distances. Would this make sense?

Yes, but correct me if I am wrong. I think if I use std::min and std::max, I can only pass two arguments and not three or more. Furthermore, I don't know how to use "using" when I want to use it for functions. I googled but I am as stupid as I was before :D

DISTDATATYPE is the type of the distance between two values and DABDATATYPE is the type of the average between values, which is then stored in a DAB, right?
So they are both results of arithmetic operations on INDATATYPE, correct? In that case, I would agree to use only one instead of two. Maybe call it PROCDATATYPE for processed-data-type.

I don't think I understand what you mean. Let's talk about this in person.

Correct. Let's stick to fuzzyAnd/Or then.

reinterpret_cast can be used to change the type without changing the representation, compiles to nothing, it is just type information for the compiler. This is enough if you surely know that the type of the casted expression and the new type are structurally equivalent.

static_cast can be used to convert a value to another type, for example like you would construct a new instance of a class from the given value.

dynamic_cast can typically be used to convert pointers and references between different classes among base and derived classes. That also needs typically runtime type information, which we disabled in RoSA.

I'm sure you don't want to use`dynamic_cast` here. Using static_cast seems to be the solution, it does proper conversion if necessary.

It's true that std::max and friends cannot be used to an arbitrary number of arguments, so let's have these fuzzy functions.

But I don't see why use variadic arguments. Those arguments can be anything and hence it may be used in a wrong way. It would be much safer to let the compiler help you checking types.

Instead of a variadic argument, you could pass the values as an std::array (with a template argument for the length). When you pass the values as a container, you can simply use std::max_element and std::min_element to have a one-liner implementation of the these fuzzy functions.

Regarding the original question, where to put these function: they could be defined as inline function in rosa/support/math.hpp.