[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [office-comment] Data Type Specification and Conversion likein FORTRESS
Hi, Patrick Durusau wrote: > Leonard, > > First, thanks for all the comments! They are very helpful. > > Sanity check: What you are asking for is different from 8.5.3.2 > Condition, where a condition is set to test the validity of the entry > in a cell. Yes? Unfortunately, I did not find this section 8.5.3.2 in the ODF-document I have. However, I most definitely described something else. Actually, I was referring at the FORTRESS programming language developed by Sun Microsystems, specifically: - the possibility to use various dimensions in cells AND - that the spreadsheet application performs implicit conversions of these dimensions e.g. we may enter in column 'A' the length of some objects: A1: 1 m A2: 27 cm A3: 99 inch A4: = SUM(A1:A3) and the spreadsheet application would perform the implicit conversions and calculate the accurate result. FORTRESS goes even further, e.g.: we may divide the length by a time value, and get a velocity-measure An extension would be to have user defined measures supporting variable conversions. Suppose, we build a spreadsheet, which will be used to enter various currencies: both Euro and US Dollars. So, we may want to sum up this column. First we define an explicit conversion between currencies (e.g. 1 Euro = US $ 1.27) and let the spreadsheet handle automatically the data accordingly. This conversion factor could be linked to an external foreign exchange rate. Therefore, a user may enter US $ 4.5 M => and the spreadsheet would know that this means 4.5 Million US Dollars, which is equivalent to ~3.5 Million Euro, making any automatic conversion when needed. A full description of *Unit Conversions* is given in chapter 35 - Dimensions and Unit Declarations (p260) of the Project Fortress Language Specification (see http://research.sun.com/projects/plrg/fortress.pdf). > In other words, you want to be able to declare a type for the data in > a cell, separate and apart from a validation test on the content. Yes? > > Such that I could enter a value, assume the data type is complex > number and there is no validation condition set so I could (mistakely) > enter: 5. 5i => automatic conversion to the complex number (0 + 5 * i) ;-) 3m => size:3; internal unit type: distance as meters This way, one would always know what is entered (it is 5i, or 3m, or 4.5 Million Euros). Also, because conversions are done either explicitly (by some set rules) or implicitly, propensity for ERROR declines substantially. The spreadsheet application could easily highlight the type, similarly as FORTRESS will highlight the dimension/unit. Sincerely, Leonard > It would have the correct datatype but unless I set a validation > condition, the user error will go undetected. > > Or, are you asking that datatypes be associated with cells and I could > either turn validation on or off? (Assuming I have supplied the > validation tests for any datatypes not defined by OpenDocument.) > > Hmmm, how many datatypes do you think OpenDocument should define along > with validation tests versus those that we allow to be user supplied > along with any validation test? > > Hope you are having a great day! > > Patrick > > Leonard Mada wrote: > >> A major disadvantage of every spreadsheet application is the lack of >> coding capabilities to explicitly state the type of the values. >> >> This *major design flaw* of spreadsheets makes them very error prone >> when intermingling various data formats. >> >> I really miss something like the new FORTRESS (see >> http://fortress.sunsource.net/). >> >> In my primary work, I am overseeing 100+ employees working >> extensively with worksheets. Unfortunately, there were often >> situations where 2 currencies were used, providing a perfect milieu >> for conversion errors, e.g. 1,000,000 RON equals approx. 300,000 >> Euro, BUT adding 1,000,000 or 300,000 makes a great difference (of >> 700,000 RON or Euro). The globalisation trend will only foster this >> development. >> >> The killer feature that will differentiate spreadsheets from the >> '70-'80s from modern concepts would allow the user to specify the >> type of the data, e.g.: >> A1: 30 m >> A2: 125 cm >> A3: 86 inch >> A4: = SUM(A1:A3) => implicit conversions are done >> >> 2nd example: >> A1: 1.2 M Euro >> A2: 0.67 M $ >> A3: =SUM(A1:A2) => implicit conversion using a pre-specified >> conversion rule >> >> As this feature will differentiate the flawed concepts of the past >> from the modern views, I hope that it gets implemented in the ODF >> specification. >> >> Kind regards, >> >> Leonard Mada
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]