SUM function resulting WRONG values when some cell contains a string

Question

A very strange problem that can result in wrong financial calculations and big mistakes...
If we have SUM function for some range of cells and one of them is treated as text string (I mean it's number in fact but Number is sure it's text string). than SUM function calulates ALL cells except this sell silently without errors and results in wrong result.
For example we have cells and values
A B
=====
1| 15 USD
2| 0 USD
3| 37 USD
4| 1 USD
5| 3 USD
here the function SUM(B1:B5) should provide the result "56 USD"
But if cell B5 is treated as text string (it can be still displayed as "3 USD" so we don't know it's treated as text string for some reason) than SUM(B1:B5) swill answer "53 USD".
The problem is we DON'T know cell B5 is treated as text and we are fully sure that we have the correct sum of all 5 cells, in reality we see sum of 4 cells only....
I think anybody working with financial or other important data can imagine how dangerous this SUM behaviour is.... I encountered several times that when importing data from Excel or by other ways numbers are imported as text strings. So if I have a lot of cells I'm not sure if all those cells are correctly styled or some of them for some unknown reason is treated as text string.
In Microsoft Excel there is a very right solution. In MS Excel if any cell in the SUM is wrong format the SUM function simply provides error as a result. But in Numbers SUM doesn't tell us about error, it simply provides us with a wrong result!
With formal logic the way SUM works in Numbers is total idiotism. If I ask to SUM B1:B5 than I definitely ask to sum ALL 5 cells, not 4, not 3, not 6 but 5 definite cells. If Numbers can't sum those exactly those 5 cells the only answer of the function should be ERROR.
But Apple Numbers answers me some result of summing those cells that it's able to sum. Apple Numbers SUM function is not confused that I asked for SUM of 5 (not 4 or 3) cells and I expect to have this sum as a result.
In fact Apple uses the right logic when we use another formula. If we use =B1B2+B3+B4B5 and any cell contains text string that we'll have error result the sam as in Microsoft Excel. So in this example Numbers behaves correctly.
So why SUM (B1:B5) can provide totally different result as =B1B2+B3+B4B5?

Answer 1

alexb2 wrote:
So when I set format for my number as my local currency it's displayed as 123 XXX (XXX is my currency but it's not in latin). I see it's not only displayed but also stored as 123 XXX. That's different from Excel that stores only numbers in cells and shows number with prefix or suffix - Numbers storex number with prefix or suffix.
No, you get this behavior because the original sheet is displaying values as currencies. I assumes that the import process pass it as a string because he doesn't recognize it as a currency value. As far as I know, Numbers stores the currency entries as a pure number and an indicator of the used currency.
Here is an example.
(a) the description of the numerical value (I underlined it: 456)
<sf:number-cell sf:flags="4" sf:value="456" sf:col="1" sf:row="2">
<sf:cell-style-ref sfa:IDREF="SFTCellStyle-46"/>
<sf:content-size sfa:w="58.659881591796875" sfa:h="14"/>
</sf:number-cell>
(b) the description of the format (I underlined the used currency: XAM)
<sf:cell-style sfa:ID="SFTCellStyle-46" sf:cell-style-default-line-height="12" sf:parent-ident="tabular-Basic-body-cell-style-id">
<sf:property-map>
<sf:SFTCellStylePropertyNumberFormat>
<sf:number-format sfa:ID="SFTNumberFormat-23" sf:format-type="1" sf:format-string="#,##0.00 &#xA4;;-#,##0.00 &#xA4;" sf:format-decimal-places="2" sf:format-currency-code="XAM" sf:format-negative-style="0" sf:format-show-thousands-separator="true" sf:format-fraction-accuracy="-3" sf:format-use-accounting-style="false"/>
</sf:SFTCellStylePropertyNumberFormat>
<sf:SFTCellStylePropertyImplicitFormatType>
<sf:number sfa:number="256" sfa:type="i"/>
</sf:SFTCellStylePropertyImplicitFormatType>
<sf:SFTCellStylePropertyFormatType>
<sf:number sfa:number="257" sfa:type="i"/>
</sf:SFTCellStylePropertyFormatType>
</sf:property-map>
</sf:cell-style>
Of course, if the original currency string is not recognized, it can't be described as such a feature and the value is treated as a simple string.
So may be at some moment my 123 XXX is treated like string value.
Yes, find and replace is a nice tool when importing data - thanks for the tip. the last problem is with already Numbers files that were imported not today (or even createde as Numbers file) where some cell becomes string value after some editing.
Here again, if you edit a currency string and replace it to a not recognized one, the result will be logically a string.
There is an other way to give this result:
copy a value from a cell formatted as XAM currency (just an example)
paste it in a cell whose format is currency Euro (once again it's just an example).
The result will be a string.
The culprit is not the program, it's the user.
I had several times this situation and last time I found error only because I have my budget in 2 programs - in Numbers and in another special budgeting program. As each program has advantages I have in fact 2 instances of the same budget.
And when I changed some string in Numbers and another program I noticed the sum is different. I was sure it's another program somewhere buggy but noticed than Numbers simply ignores one of the budget strings and sums without it... In fact it was even not the string I changed, I remember I changed the buggy string about a week ago but I haven't compared budgets that time so my budget had a mistake for some time till I noticed it. If I used only Numbers without copy of budget in another program may be even today I won't notice the mistake.
The same situation happened not once.
I think that the choice made by Apple for SUM() is correct. You feel that it is wrong. It's useless to debate more, we will not change the behavior of the function.
I try to give a workaround.
The neater one is to add columns as I described in my first response.
The given formula will clearly flag cells which aren't containing numerical values. If you move the SUM from the original range to the new one, the oddities will be flagged automatically.
Here is an alternate workaround:
The currency is XAM.
In B4 I introduced a typo so the value is no longer a numerical one.
Given that, the sum in the footer doesn't count the 34 (which is the normal behavior).
In column C1 I entered =1*B
which flagged the bad cell.
The alternate is to use an auxiliary table like aux1
In A1 I entered:
=IF(ISERROR(INDIRECT(ADDRESS(ROW(),COLUMN(),,,"main"))),"",IF(ISBLANK(INDIRECT(A DDRESS(ROW(),COLUMN(),,,"main"))),"",1*INDIRECT(ADDRESS(ROW(),COLUMN(),,,"main") )))
Exactly the same formula in B1, C1, D1, …
So, the table will automatically grab the contents of the main table (just take care to insert more columns in aux1 than in main)
In the footer row of aux1, insert a sum formula for columns where there is required.
Looking at this footer will flag columns where a value may be "wrong" so, it will be necessary (but easy) to scan the column's content to find the red triangle(s).
Yvan KOENIG (from FRANCE lundi 13 octobre 2008 13:27:40)