SOLVED

ABS function issue

%3CLINGO-SUB%20id%3D%22lingo-sub-2748589%22%20slang%3D%22en-US%22%3EABS%20function%20issue%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-2748589%22%20slang%3D%22en-US%22%3E%3CP%3EThe%20following%20formula%20always%20show%20false%20when%20J6%20is%20between%2069.1-70%20and%20I6%20is%2068%20in%20Microsoft%20365%2016.0.14228.20216%20but%20it%20shows%20correct%20answer%20%3D%20true%20in%20MS%20Office%202013%26nbsp%3B%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3E%3DABS((ROUNDDOWN(J6%2C2)-ROUNDDOWN(I6%2C2)))%26gt%3B%3D0.01%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EPlease%20advise%20am%20I%20miss%20anything.%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-LABS%20id%3D%22lingo-labs-2748589%22%20slang%3D%22en-US%22%3E%3CLINGO-LABEL%3EExcel%3C%2FLINGO-LABEL%3E%3CLINGO-LABEL%3EFormulas%20and%20Functions%3C%2FLINGO-LABEL%3E%3CLINGO-LABEL%3EOffice%20365%3C%2FLINGO-LABEL%3E%3C%2FLINGO-LABS%3E%3CLINGO-SUB%20id%3D%22lingo-sub-2748730%22%20slang%3D%22en-US%22%3ERe%3A%20ABS%20function%20issue%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-2748730%22%20slang%3D%22en-US%22%3E%3CP%3E%3CA%20href%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fuser%2Fviewprofilepage%2Fuser-id%2F457431%22%20target%3D%22_blank%22%3E%40SomTony%3C%2FA%3E%26nbsp%3B%3C%2FP%3E%3CP%3EIt%20looks%20okay%20for%20me%3C%2FP%3E%3CP%3ECheck%20it%20by%20formula%20evaluation%20(Ribbon%20Formulas%20%26gt%3B%26gt%3B%20Evaluate%20formula)%3C%2FP%3E%3CP%3E%3CSPAN%20class%3D%22lia-inline-image-display-wrapper%20lia-image-align-inline%22%20image-alt%3D%22JulianoPetrukio_0-1631617209585.png%22%20style%3D%22width%3A%20400px%3B%22%3E%3CIMG%20src%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fimage%2Fserverpage%2Fimage-id%2F310282i3AA0E33166D0AA19%2Fimage-size%2Fmedium%3Fv%3Dv2%26amp%3Bpx%3D400%22%20role%3D%22button%22%20title%3D%22JulianoPetrukio_0-1631617209585.png%22%20alt%3D%22JulianoPetrukio_0-1631617209585.png%22%20%2F%3E%3C%2FSPAN%3E%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EOne%20likelihood%20can%20be%20the%20%3CA%20href%3D%22https%3A%2F%2Fwww.microsoft.com%2Fen-us%2Fmicrosoft-365%2Fblog%2F2008%2F04%2F10%2Funderstanding-floating-point-precision-aka-why-does-excel-give-me-seemingly-wrong-answers%2F%23%3A~%3Atext%3DThe%2520IEEE%2520754%2520floating%252Dpoint%2Ccan%2520be%2520used%2520in%2520calculations.%26amp%3Btext%3DThis%2520number%2520cannot%2520be%2520represented%2C17%2520when%2520it%2520is%2520stored.%22%20target%3D%22_self%22%20rel%3D%22noopener%20noreferrer%22%3EFloating%20Point%20Precision%20%22Error%22%20caused%20by%20IEEE%20754%20Standard%3C%2FA%3E%3C%2FP%3E%3CP%3EBut%20I%20guess%20it%20is%20not%20the%20case.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-2750874%22%20slang%3D%22en-US%22%3ERe%3A%20ABS%20function%20issue%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-2750874%22%20slang%3D%22en-US%22%3E%3CP%3E%3CA%20href%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fuser%2Fviewprofilepage%2Fuser-id%2F457431%22%20target%3D%22_blank%22%3E%40SomTony%3C%2FA%3E%26nbsp%3B%20wrote%3A%20%60%60The%20following%20formula%20always%20show%20false%20when%20J6%20is%20between%2069.1-70%20and%20I6%20is%2068%60%60%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3E%3CFONT%20color%3D%22%23FF0000%22%3EPlease%20attach%20an%20Excel%20file%20(redacted)%20%3CU%3E%3CEM%3Ethat%20demonstrates%20when%20the%20formula%20returns%20FALSE%3C%2FEM%3E%3C%2FU%3E%20unexpectedly.%3C%2FFONT%3E%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EOstensibly%2C%2069.1%20-%2068%20is%20too%20large%20a%20difference%20for%20the%20comparison%20with%200.01%20to%20be%20FALSE%2C%20even%20if%20we%20assume%20that%20J6%20and%20I6%20are%20not%20exactly%20the%20values%20that%20they%20appear%20to%20be.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EWith%20the%20smallest%20possible%20value%20in%20J6%20and%20the%20largest%20possible%20value%20in%20I6%2C%2069.05%20-%2068.5%20%3D%200.55%2C%20not%20at%20all%20close%20to%200.01.%26nbsp%3B%20And%20that%20is%20even%20more%20true%20as%20we%20increase%20J6.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3E(FYI%2C%20the%20largest%20value%20in%20I6%20is%20really%2068.4999999999999%20%2B%204.2632564145606E-14.)%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EBe%20that%20as%20it%20may....%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3E-----%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3E%3CA%20href%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fuser%2Fviewprofilepage%2Fuser-id%2F767933%22%20target%3D%22_blank%22%3E%40Juliano-Petrukio%3C%2FA%3E%26nbsp%3B%20wrote%3A%20%60%60One%20likelihood%20can%20be%20the%20%3CA%20href%3D%22https%3A%2F%2Fwww.microsoft.com%2Fen-us%2Fmicrosoft-365%2Fblog%2F2008%2F04%2F10%2Funderstanding-floating-point-precision-aka-why-does-excel-give-me-seemingly-wrong-answers%2F%23%3A~%3Atext%3DThe%2520IEEE%2520754%2520floating%252Dpoint%2Ccan%2520be%2520used%2520in%2520calculations.%26amp%3Btext%3DThis%2520number%2520cannot%2520be%2520represented%2C17%2520when%2520it%2520is%2520stored.%22%20target%3D%22_self%22%20rel%3D%22noopener%20noreferrer%22%3EFloating%20Point%20Precision%20%22Error%22%20caused%20by%20IEEE%20754%20Standard%3C%2FA%3E.%20But%20I%20guess%20it%20is%20not%20the%20case.%60%60%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EThat%20is%20still%20a%20valid%20issue.%26nbsp%3B%20And%20the%20work-around%20is%3A%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3E%3DABS(%3CFONT%20color%3D%22%23FF0000%22%3EROUND(%3C%2FFONT%3EROUNDDOWN(J6%2C2)-ROUNDDOWN(I6%2C2)%3CFONT%20color%3D%22%23FF0000%22%3E%2C%202)%3C%2FFONT%3E)%26gt%3B%3D0.01%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EThe%20problem%20is%20with%20the%20(binary)%20subtraction.%26nbsp%3B%20It%20has%20nothing%20to%20do%20with%20ABS.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EIn%20general%2C%20whenever%20we%20%3CFONT%20color%3D%22%23FF0000%22%3Eexpect%3C%2FFONT%3E%20a%20calculation%20that%20involves%20or%20results%20in%20a%20decimal%20fraction%20to%20be%20accurate%20to%20some%20number%20of%20decimal%20places%2C%20we%20should%20%3CFONT%20color%3D%22%23FF0000%22%3Eexplicitly%20round%3C%2FFONT%3E%20to%20%3CU%3E%3CEM%3Ethat%20number%3C%2FEM%3E%3C%2FU%3E%20of%20decimal%20places%20(and%20%3CU%3E%3CEM%3Enot%3C%2FEM%3E%3C%2FU%3E%20to%20an%20arbitrary%20number%20like%2010)%2C%20even%20if%20the%20individual%20values%20are%20rounded%20properly.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EFor%20example%2C%2010.01%20-%2010%20%3D%200.01%20returns%20FALSE(!).%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-2751278%22%20slang%3D%22en-US%22%3ERe%3A%20ABS%20function%20issue%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-2751278%22%20slang%3D%22en-US%22%3E%3CP%3E%3CA%20href%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fuser%2Fviewprofilepage%2Fuser-id%2F146717%22%20target%3D%22_blank%22%3E%40Joe%20User%3C%2FA%3E%26nbsp%3B%3C%2FP%3E%3CP%3EThanks%20for%20all%20of%20the%20replies.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EHere%20is%20the%20testing.%26nbsp%3B%20The%20same%20formula%20for%2068.1%25-67.00%25%20%3D%200.01%2C%20but%2069.1%25-68.00%25%20%3D%200.0099999999%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EThis%20is%20the%20point%20which%20I%20don't%20get%20it.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3E%3CSPAN%20class%3D%22lia-inline-image-display-wrapper%20lia-image-align-inline%22%20image-alt%3D%22SomTony_0-1631671613487.png%22%20style%3D%22width%3A%20605px%3B%22%3E%3CIMG%20src%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fimage%2Fserverpage%2Fimage-id%2F310471i50621B6FDE724A4B%2Fimage-dimensions%2F605x466%3Fv%3Dv2%22%20width%3D%22605%22%20height%3D%22466%22%20role%3D%22button%22%20title%3D%22SomTony_0-1631671613487.png%22%20alt%3D%22SomTony_0-1631671613487.png%22%20%2F%3E%3C%2FSPAN%3E%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-2751375%22%20slang%3D%22en-US%22%3ERe%3A%20ABS%20function%20issue%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-2751375%22%20slang%3D%22en-US%22%3E%3CP%3E%3CA%20href%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fuser%2Fviewprofilepage%2Fuser-id%2F457431%22%20target%3D%22_blank%22%3E%40SomTony%3C%2FA%3E%26nbsp%3B%20wrote%3A%20%60%60The%20same%20formula%20for%2068.1%25-67.00%25%20%3D%200.01%2C%20but%2069.1%25-68.00%25%20%3D%200.0099999999%60%60%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EAha!%26nbsp%3B%20You%20are%20comparing%2069%3CFONT%20color%3D%22%23FF0000%22%3E%25%3C%2FFONT%3E%20-%2068%3CFONT%20color%3D%22%23FF0000%22%3E%25%3C%2FFONT%3E%20with%200.01%2C%20not%2069%20-%2068.%26nbsp%3B%20You%20misspoke%20in%20the%20original%20posting.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EI%20do%20not%20see%20any%20comparison%20of%20Office%20365%20Excel%20and%20Excel%202013%20results.%26nbsp%3B%20So%20I%20assume%20that%20you%20realize%20now%20that%20they%20return%20the%20same%20results%20for%20%3CU%3E%3CEM%3Eexactly%3C%2FEM%3E%3C%2FU%3E%20the%20same%20data.%26nbsp%3B%20The%20operative%20word%20is%20%22exactly%22.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EAs%20to%20your%20question%3A%20why%20does%20ABS(...)%26gt%3B%3D0.01%20return%20FALSE%20in%20most%20of%20your%20examples%3F%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3E%3CA%20href%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fuser%2Fviewprofilepage%2Fuser-id%2F767933%22%20target%3D%22_blank%22%3E%40Juliano-Petrukio%3C%2FA%3E%26nbsp%3Balready%20pointed%20you%20to%20a%20MSFT%20explanation%2C%20albeit%20unnecessarily%20complex%20and%20inaccurate%2C%20IMHO.%26nbsp%3B%26nbsp%3B%20And%20as%20I%20noted%20previously%2C%20the%20problem%20has%20nothing%20to%20do%20with%20ABS.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EMore%20importantly%2C%20I%20already%20demonstrated%20the%20work-around%2C%20to%20wit%3A%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3E%3DABS(%3CFONT%20color%3D%22%23FF0000%22%3EROUND(%3C%2FFONT%3EROUNDDOWN(B5%2C2)-ROUNDDOWN(A5%2C2)%3CFONT%20color%3D%22%23FF0000%22%3E%2C%202)%3C%2FFONT%3E)%26gt%3B%3D0.01%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3Eor%20equivalently%3A%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3E%3D%3CFONT%20color%3D%22%23FF0000%22%3EROUND(%3C%2FFONT%3EABS(ROUNDDOWN(B5%2C2)-ROUNDDOWN(A5%2C2))%3CFONT%20color%3D%22%23FF0000%22%3E%2C%202)%3C%2FFONT%3E%26gt%3B%3D0.01%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EThe%20point%20is%3A%26nbsp%3B%20in%20most%20of%20your%20examples%2C%20the%20difference%20is%20not%200.01%20(1%25)%2C%20but%200.00999999999999999%20(approximately).%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EAnd%20obviously%2C%200.00999999999999999%26gt%3B%3D0.01%20is%20FALSE.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3ESo%20your%20question%20should%20be%3A%26nbsp%3B%20why%20is%20the%20difference%200.00999999999999999%20instead%20of%200.01%3F%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EThe%20simpler%20explanation%20(IMHO)%20is....%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EExcel%20uses%2064-bit%20binary%20floating-point%20to%20represent%20numbers%20internally%2C%20and%20%3CFONT%20color%3D%22%23FF0000%22%3Emost%20decimal%20fractions%20cannot%20be%20represented%20exactly%20in%20that%20binary%20form%3C%2FFONT%3E.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EMoreover%2C%20%3CFONT%20color%3D%22%23FF0000%22%3Ethe%20binary%20approximation%20of%20a%20particular%20decimal%20fraction%20(e.g.%200.01)%20might%20vary%2C%20depending%20on%20the%20magnitude%20of%20the%20number%3C%2FFONT%3E.%26nbsp%3B%20That%20is%20why%2010.01-10%26gt%3B%3D0.01%20returns%20FALSE(!).%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EExcel%20complicates%20our%20ability%20to%20understand%20the%20problem%20because%20it%20arbitrarily%20limits%20the%20number%20of%20digits%20that%20it%20displays%20to%20up%20to%2015%20significant%20digits%20(rounded).%26nbsp%3B%20Consequently%2C%20there%20might%20be%20infinitesimal%20%22residuals%22%20that%20we%20cannot%20see%20by%20formatting.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EIn%20general%2C%20the%20work-around%20is....%20When%20we%20%3CFONT%20color%3D%22%23FF0000%22%3Eexpect%3C%2FFONT%3E%20a%20calculation%20that%20involves%20or%20results%20in%20a%20number%20with%20a%20decimal%20fraction%20to%20be%20accurate%20to%20some%20number%20of%20decimal%20places%2C%20we%20should%20%3CFONT%20color%3D%22%23FF0000%22%3Eexplicitly%20round%3C%2FFONT%3E%20to%20%3CU%3E%3CEM%3Ethat%20number%3C%2FEM%3E%3C%2FU%3E%20of%20decimal%20places%20(and%20%3CEM%3E%3CU%3Enot%3C%2FU%3E%3C%2FEM%3E%20to%20an%20arbitrary%20number%20like%2010)%2C%20even%20if%20the%20individual%20numbers%20appear%20to%20be%20rounded%20appropriately.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3ESee%20columns%20D%3AH%20in%20the%20%22sheet1%20corrected%22%20worksheet%20in%20the%20attached%20file.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3ELMK%20if%20you%20have%20further%20questions.%3C%2FP%3E%3C%2FLINGO-BODY%3E
New Contributor

The following formula always show false when J6 is between 69.1-70 and I6 is 68 in Microsoft 365 16.0.14228.20216 but it shows correct answer = true in MS Office 2013 

 

=ABS((ROUNDDOWN(J6,2)-ROUNDDOWN(I6,2)))>=0.01

 

Please advise am I miss anything.

7 Replies

@SomTony 

It looks okay for me

Check it by formula evaluation (Ribbon Formulas >> Evaluate formula)

JulianoPetrukio_0-1631617209585.png

 

One likelihood can be the Floating Point Precision "Error" caused by IEEE 754 Standard

But I guess it is not the case.

 

 

@SomTony  wrote: ``The following formula always show false when J6 is between 69.1-70 and I6 is 68``

 

Please attach an Excel file (redacted) that demonstrates when the formula returns FALSE unexpectedly.

 

And attach __two__ files, one for Office 365 and one for Excel 2013, that demonstrate when the formula has different results for the "same" data.

 

Ostensibly, 69.1 - 68 is too large a difference for the comparison with 0.01 to be FALSE, even if we assume that J6 and I6 are not exactly the values that they appear to be.

 

With the smallest possible value in J6 and the largest possible value in I6, 69.05 - 68.5 = 0.55, not at all close to 0.01.  And that is even more true as we increase J6.

 

(FYI, the largest value in I6 is really 68.4999999999999 + 4.2632564145606E-14.)

 

Be that as it may....

 

-----

 

@Juliano-Petrukio  wrote: ``One likelihood can be the Floating Point Precision "Error" caused by IEEE 754 Standard. But I guess it is not the case.``

 

That is still a valid issue.  And the work-around is:

 

=ABS(ROUND(ROUNDDOWN(J6,2)-ROUNDDOWN(I6,2), 2))>=0.01

 

The problem is with the (binary) subtraction.  It has nothing to do with ABS.

 

In general, whenever we expect a calculation that involves or results in a decimal fraction to be accurate to some number of decimal places, we should explicitly round to that number of decimal places (and not to an arbitrary number like 10), even if the individual values are rounded properly.

 

For example, 10.01 - 10 = 0.01 returns FALSE(!).

 

 

 

@Joe User 

Thanks for all of the replies.

 

Here is the testing.  The same formula for 68.1%-67.00% = 0.01, but 69.1%-68.00% = 0.0099999999

 

This is the point which I don't get it.

 

SomTony_0-1631671613487.png

 

best response confirmed by SomTony (New Contributor)
Solution

@SomTony  wrote: ``The same formula for 68.1%-67.00% = 0.01, but 69.1%-68.00% = 0.0099999999``

 

Aha!  You are comparing 69% - 68% with 0.01, not 69 - 68.  You misspoke in the original posting.

 

I do not see any comparison of Office 365 Excel and Excel 2013 results.  So I assume that you realize now that they return the same results for exactly the same data.  The operative word is "exactly".

 

As to your question: why does ABS(...)>=0.01 return FALSE in most of your examples?

 

@Juliano-Petrukio already pointed you to a MSFT explanation, albeit unnecessarily complex and inaccurate, IMHO.   And as I noted previously, the problem has nothing to do with ABS.

 

More importantly, I already demonstrated the work-around, to wit:

 

=ABS(ROUND(ROUNDDOWN(B5,2)-ROUNDDOWN(A5,2), 2))>=0.01

 

or equivalently:

 

=ROUND(ABS(ROUNDDOWN(B5,2)-ROUNDDOWN(A5,2)), 2)>=0.01

 

The point is:  in most of your examples, the difference is not 0.01 (1%), but 0.00999999999999999 (approximately).

 

And obviously, 0.00999999999999999>=0.01 is FALSE.

 

So your question should be:  why is the difference 0.00999999999999999 instead of 0.01?

 

The simpler explanation (IMHO) is....

 

Excel uses 64-bit binary floating-point to represent numbers internally, and most decimal fractions cannot be represented exactly in that binary form.

 

Moreover, the binary approximation of a particular decimal fraction (e.g. 0.01) might vary, depending on the magnitude of the number.  That is why 10.01-10>=0.01 returns FALSE(!).

 

Excel complicates our ability to understand the problem because it arbitrarily limits the number of digits that it displays to up to 15 significant digits (rounded).  Consequently, there might be infinitesimal "residuals" that we cannot see by formatting.

 

In general, the work-around is.... When we expect a calculation that involves or results in a number with a decimal fraction to be accurate to some number of decimal places, we should explicitly round to that number of decimal places (and not to an arbitrary number like 10), even if the individual numbers appear to be rounded appropriately.

 

See columns D:H in the "sheet1 corrected" worksheet in the attached file.

 

LMK if you have further questions.

@SomTony 

 

As mentioned on my previous post you can do the following

  1. Click Microsoft Office Button -> Excel Options -> Advanced
  2. In the When calculating this workbook section, select the workbook you want, and then select the Set precision as displayed check box

JulianoPetrukio_0-1631702425471.png

 

@Juliano-Petrukio  wrote: ``select the Set precision as displayed``

 

That is strongly ill-advised, IMHO.

 

First, setting PAD does not fix @SomTony's problem because PAD applies only to the final cell value, not to values of intermediate expressions.

 

In other words, with PAD set, it is true that =ABS(ROUNDDOWN(B6,2)-ROUNDDOWN(A6,2)) in D6 results in exactly (the binary approximation of) 0.01, if D6 is formatted as Number with 2 decimal places, given A6 in 68% and B6 in 69.1%.

 

But ABS(ROUNDDOWN(B6,2)-ROUNDDOWN(A6,2))>=0.01 still returns FALSE because ABS actually returns 0.00999999999999999 (- 1.73472347597681E-18) in that context, and PAD does not "correct" it.

 

-----

 

Second, IMHO, it is ill-advised to set PAD without saving a copy of the file before setting PAD.

 

The reason is:  merely setting PAD might irrevocably change constants that are purposely formatted with less precision (e.g. interest rates); and such changes can affect the entire workbook.  Thus, if we decide later to deselect PAD, the "damage" might have been done already.

 

Fortunately, Excel gives us some warning of that side-effect when we set PAD.  Pay attention to it.

 

We know about it. That's why a comprehensive and technical explanation was given on previous article. Excel has some hidden features like that for a reason. Was achieved the reason and the why. The warning is given before the user moves forward.
There are situations that such feature is required , or other situations to handle with iterations and circular references ....

But thank you for your concerns. Its important we share different experiences on the same technical problem.