OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

office-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [office-comment] Integer Overflow and number Types in ODF

Hello Leonard,

All things considering, (and coming from the banking industry myself) I 
could not be in agreement with you more when you wrote inter alia;

> Hello David, Hello everyone,
> I tend to disagree very strongly - but I have strong arguments, too. 
> Old spreadsheet models worked *maybe* fine in the last 20 years (more 
> on this later, see ** comment). Lets try to analyse however the 
> present and the future:
> There are 2 big companies on this TC (actually more than 2):
> Sun Microsystems and IBM (and Google, and ...)
> Lets ask their representatives a simple question:
> What are the revenues of your company?
> Taking a look at Jonathan's blog, I anticipate a revenue of ~10 
> billions in 2007 (fiscal years are slightly differently defined, but 
> lets ignore this fact).
> Now, for storing a number of 10 billions, you need 10 digits. Being 
> accurate to cent level, you need an additional 2 digits. This makes a 
> total of 12 digits. Damn close to the accuracy limit of 15 digits.
> IF by chance, this number is multiplied with 1000 (for a currency 
> conversion, or any conversion, where the user first uses a 
> multiplication), you loose accuracy, and you can loose it pretty fast. 
> [* see  comment]
> Now, lets look at this issue into some other perspective:
> 1.) some companies operate revenues 1, 2 and even >3 orders of 
> magnitude bigger than the one mentioned (think of financial 
> institutions - a big bank, the stock exchange, government, ...)
> 2.) some currencies are weaker than the dollar, maybe 10 times, or 
> even 1,000 times weaker, so you end with values significantly bigger 
> than the ones mentioned
> 3.) precision needs to be sometimes more than 2 decimal places, e.g. 
> when working with exchange rates
> A precision of 15-digits is inappropriate in all these instance. 
> Auditors want every cent to be accounted for! Yet, the accuracy loss 
> would be even in the thousands of dollars, and sometimes even higher. 
> Added over time, the complete catastrophe.
> The problem is amplified by other factors as well. Spreadsheets become 
> larger and more complex. I recently experienced the limits of OOo 
> Calc. I was absolutely sure that the row limit did increase to > 
> 65535, yet I came across a document that had more rows (and it did 
> confirm me that OOo Calc still doesn't support more rows). The real 
> issue is: *I stumbled upon a large spreadsheet!*
> This wasn't supposedly an issue 20 years back. This is an issue today. 
> Errors add up, and sometimes pretty fast. Adding up 70,000 rows will 
> generate sometimes large numbers. Intermediate results might get 
> easily broken.
> Did Lotus 1-2-3 support 70,000 rows? Did it support 200,000 rows? Did 
> it compute a regression on 1,000,000 rows? Did it apply complex models 
> to forecast the needs in the health care system over the next 10 years?
> I doubt it.
> Now, health care is something I have knowledge about. The health 
> expenditures in the US for 2006 were $ 2,105.5 billions, that is $ 2.1 
> trillion - this is 13 digits long (ignoring any decimals). Working 
> with such numbers is a real challenge for every 15-digit arithmetic. ***
> For the projections in the US during 2007-2017, please see:
> http://www.cms.hhs.gov/NationalHealthExpendData/03_NationalHealthAccountsProjected.asp#TopOfPage 
> http://www.cms.hhs.gov/NationalHealthExpendData/Downloads/proj2007.pdf
> I hope therefore that spreadsheets *urgently* adapt to this situation.
> I worked up to last year for a national (governmental) institution. 
> During that time, a custom (proprietary) solution was implemented 
> (worth some 6-8 million dollars), yet - although everything was 
> covered in the program - some data (for very specific analysis) did 
> still get exported to a spreadsheet. Fate or irony?
> So, in the end, unwillingly, you end with the spreadsheet limitations. 
> Most of us do NOT even anticipate the places where a spreadsheet might 
> get used. Although their use in professional settings is dwindling, 
> some unfortunate result might still get computed using a spreadsheet.
> Sincerely,
> Leonard
Once again; (from a personal, business and professional perspective) 
rather than one year... let us consider the more complex scenarios of 20 
to 25 years of projected revenues; quite clearly then, one would be 
curious to know how the "the revenues" (projections) of a particular 
company were arrived at in the absence of the requisite computational 
tools and the methodologies for arriving at those projections. The 
question here is: Would/will those "20 year" Spread Sheet being talked 
about suffice?

Kindest regards,

Sheldon A. Britton

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]