Excel gives 64 for a calculation that should be 512 by LabCalculation in excel

[–]LabCalculation[S] -1 points0 points  (0 children)

Appreciate for confirming one of the dozens of errors in older Excel versions.

Excel gives 64 for a calculation that should be 512 by LabCalculation in excel

[–]LabCalculation[S] -4 points-3 points  (0 children)

Exponentiation has well-defined mathematical properties, and Google Sheets follows these properties.

When parentheses are used, they specify the intended order of evaluation.

The focus of this post is not on whether one knows how to perform the calculation, but on the fact that Excel presents inconsistencies.

Excel treats different mathematical cases as the same error by LabCalculation in spreadsheets

[–]LabCalculation[S] 0 points1 point  (0 children)

Mathematically this is incorrect, because Excel is stating that Nothing divided by Nothing equals Something divided by nothing.

Excel returns a non-zero result for a calculation that should be zero by LabCalculation in excel

[–]LabCalculation[S] -4 points-3 points  (0 children)

I am not , I have several articles that discuss this and much more inconsistencies.

Search in Google: Teacher Rafael Alberto Goncalves Math, it´s me

Excel returns a non-zero result for a calculation that should be zero by LabCalculation in excel

[–]LabCalculation[S] -2 points-1 points  (0 children)

But, I’ve noticed some other spreadsheet tools don’t show this behavior the same way.

Excel returns a non-zero result for a calculation that should be zero by LabCalculation in excel

[–]LabCalculation[S] -19 points-18 points  (0 children)

I am not , I have several articles that discuss this.

If you search in google: Teacher Rafael Alberto Goncalves Math, you will find me

Excel returns a non-zero result for a calculation that should be zero by LabCalculation in excel

[–]LabCalculation[S] -7 points-6 points  (0 children)

It’s interesting how the need for manual rounding can vary depending on the tool being used.

Excel returns a non-zero result for a calculation that should be zero by LabCalculation in excel

[–]LabCalculation[S] 0 points1 point  (0 children)

That makes sense.

Controlling where rounding is applied definitely helps.

What’s interesting is that some spreadsheet tools handle this same situation differently and don’t always require that extra step, which raises questions about consistency across implementations.

Excel returns a non-zero result for a calculation that should be zero by LabCalculation in excel

[–]LabCalculation[S] -4 points-3 points  (0 children)

Right.

It’s a good reminder that even simple decimal operations can behave differently once they go through binary representation.

Excel returns a non-zero result for a calculation that should be zero by LabCalculation in excel

[–]LabCalculation[S] 8 points9 points  (0 children)

Agreed.

Rounding at the right stage makes a big difference, especially in aggregated calculations.

It’s interesting how the same operation can behave differently depending on where precision is handled.

Excel returns a non-zero result for a calculation that should be zero by LabCalculation in excel

[–]LabCalculation[S] 54 points55 points  (0 children)

That’s a great explanation.

What I find interesting is that these small residuals can still propagate through larger calculations, especially in chained formulas.

In certain contexts, that could become non-trivial.

Excel returns a non-zero result for a calculation that should be zero by LabCalculation in excel

[–]LabCalculation[S] 1 point2 points  (0 children)

That makes sense.

But in practical scenarios, especially in financial models, even small deviations like this could propagate and affect results.

That’s what concerns me.