Strange. I reproduce the problem with LO 6.3.2.0+ under Ubuntu.
But, if you change the formula to SUM(J8;J9;J10) you get 0 as expected.

So for me there is a bug because SUM(A1:A3) should give the same result as SUM(A1;A2;A3).

Same problem with current master.
Tested with values -47.1, 4904.1, -4857 -> exactly the same result

Checking Tools > Options > LibreOffice Calc > Calculate > Precision as shown
has not effect here.

Best regards. JBF

Created attachment 153465 [details]
sum example

i think, this is the normal behaviour if one uses IEEE 754 standard for floating point calculation.

even excel has same problems, e.g.:
https://support.microsoft.com/de-de/help/78113/floating-point-arithmetic-may-give-inaccurate-results-in-excel

4th example in attached spreadsheet will result in 0 (LO) and 2,04636E-12 (excel)

(In reply to Oliver Brinzing from comment #2)
> Created attachment 153465 [details]
> sum example
> 
> i think, this is the normal behaviour if one uses IEEE 754 standard for
> floating point calculation.

For me the main problem is that SUM(J8:J10) does not give the same result as SUM(J8;J9;J10). We have the same behavior in your test file with example in column C.

Best regards. JBF

(In reply to Jean-Baptiste Faure from comment #3)
> For me the main problem is that SUM(J8:J10) does not give the same result as
> SUM(J8;J9;J10). We have the same behavior in your test file with example in
> column C.

the sum order can influence the result:
https://www.baeldung.com/java-floating-point-sum-order

=SUM(-46,4;4904,28;-4857,88)	0
=SUM(4904,28;-46,4;-4857,88)	0
=SUM(4904,28;-4857,88;-46,4)	-3,62376795237651E-13

or: 
Bug 82865 - precision errors in sum() 
-> reproducible with LO 4.4.7.2 (with LO 5/6 result is 0)

@m.a.riosv: you might be interested in this issue.

I can't find it, but I think there was an Eike's rework about not rounded in the limit intermediate values in a sum of range.

I think it's matter of choice, solving one way change the other.

Please @Eike can you give some advice.

consider some facts: 

1. a sum resulting in '0' normally is a subtraction, 

2. summing in fp-math produces small deviations, normally < 0,5 ULP of the result and thus (fp-)precise results, 

3. in some rare cases sums produce bigger fails if the <0,5 ULP fails of the operands sum up with a fail of 0,5 ULP regarding round-on or round-off of the result to fit into (1+)52 bits of the mantissa, e.g. 0,1 + 0,2 -> 0,30000000000000004, 

4. subtractions in fp-math suffer from cancellation, which produces much bigger deviations, especially 'catastrophic cancellation' at subtraction of nearly identical values, 

5. both can be managed by 'smart rounding', but with some difficulties, 

5a. calc and excel perform some multi-step-decimal rounding while IEEE 754 already had performed a simple binary rounding, multi-step-rounding is nice for some cases and evil for others, commonly 'no good practice',  

5b. calc and ex$el don't invest too much effort in this area as ... it's difficult and is an effort that is usually not noticed or rewarded by the user

6. plenty influences mix up in a spreadsheet result, besides dec -> bin and bin -> dec conversion rounding, the operands (binary 'even' representation or endless fraction), fp-math operation fails (predominantly accumulations or reinforcements of the deviations of the binary representation), weak libraries, weak compilers or evil compiler options, programs rounding, and others also the order in which operands are processed as @Oliver Brinzing pointed to, thus expect deviations spread randomly, 

6a. calc calculates - where it is not given by formulas or calculation rules  - in different order for a range in the sheet ('=SUM(Xn;Yn)': column by column from right to left, in the columns bottom up) and in the statusbar if you select that range (inverse sequence), 

6b. calc calculates - where it is not given by formulas or calculation rules  - in a different order than ex$el does (row by row, top down, in the rows left to right), which may result in different results, sometimes visible deviations, sometimes invisible deviations, sometimes identical wrong results, in rare cases identical exact results,

Opening attachment 153465 [details] from comment 2 with LO 7.4.6 or with LO 7.6.alpha, force recalculation, the results of cells with SUM() are all shown as zero for me. WFM?

=SUM(-46.4;4904.28;-4857.88) -> not zero.
=SUM(4904.28;-4857.88;-46.4) -> zero.

@ady: I think to remember that Calc does not calculate in the  
sequence as listed -> unpredictable results.  
IEEE:  
 4904.28 has undershot representation ~ 4904.2799999999997453,  
-4857.88 has overshot representation ~ -4857.8800000000001091,  
-  46.4  has undershot representation ~  -46.3999999999999986  
  
4904.28 + -4857.88 -> 46.399999999999636,  
cancellation reg. similar but different operands,  
that + -46.4 -> -3.623767952376511E-13  
  
other sequence:  
-46.4 + 4904.28 -> 4857.88  
no cancellation reg. different magnitude of operands,  
that + -4857.88 -> 0  
no cancellation reg. identical operands.  
  
Consider that as well IEEE as Calc and cancellation  
are rather 'by chance' than 'regular'.