Unexpected division results in arithmetic combinator

[Guardian667]

When using an
1. arithemtic combinator with division,
2. each item as an input and
3. divide the input by a value,
it seems that each single input value is divided first and the the intermediate results are summed up. I would expect that for this kind of setup first the sum of all inputs is made and then the division is executed.

See the example of the screenshot:

Expected result and calculation
(51+51+49+48+48) / 5= 49,4 -> 49 or 50, depends on rounding rules

Observed result (and assumed calculation)
51/5 + 51/5 + 49/5 + 48/5 + 48/5 = 47

[computeraddict]

It's probably doing floor(input1 / 5) + floor(input2 / 5)... The final summation is likely just a consequence of being output to a wire and not the combinator itself.

[Guardian667]

Yeah. That's exactly what I tried to describe. THX for the hint. I forgot to write the second formula correctly.

The question is if this is the intended behaviour. Since one can only set EACH as input, is could sound logical. But since you cannot set ALL as input it sounds like a lack of configurability.

[robot256]

The current behavior does not surprise me at all and is what I would expect given that signals are always integer math. Each of the integer divisions is done separately before adding to the common output signal. To do what you want, you need to have one combinator converting Each into D so they are summed, and a second combinator to divide D by T.

There has never been an option to set the sum of all signals as a monolithic input value. That would be a feature request.

[Genhis]

Thanks for the report, this works as intended.