[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; Re: > 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]