[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: Very Weak String Support in ODF
David A. Wheeler wrote: > I'm not fundamentally opposed to adding a few string functions (primarily to the "Large" group), but generally we've only been including functions which are ALREADY implemented in at least ONE spreadsheet application (Excel, Gnumeric, Corel Word Perfect Quattro Pro, KSpread, Lotus 1-2-3, etc.). There's no end to the number of functions that COULD exist, and the lack of presence in ANY implementation is a sign that perhaps this isn't as widespread a need as you'd think. Spreadsheets tend to not be used for a lot of text processing (though which is the cause and which is the effect could be argued, I guess). > I like to correct this. Spreadsheets are *THE MOST* used input medium that researches use in biomedical and life-sciences. This is both true of my country and of ALL western countries I am aware of. Actually, spreadsheet use will likely increase in the future, as more data gets digital. My position permits me to fairly accurately predict this. Of course, custom solutions could replace spreadsheets, BUT then only because spreadsheets did NOT correct the primary design flaws. So, the current stance prohibits the effective use of spreadsheets in a big segment of users. The life sciences are NOT the only one affected, actually, a much broader segment of researchers are struck with these shortcomings, and even commercial businesses. I am working in a governmental office and some 30-40% of ALL spreadsheets, done by ALL employees, contain significant portions of text. (I mean with text that is analysable, NOT just labels or descriptive text!) > Also, there's always a risk that "committee invention" will have implementation or usage problems. Standards are generally better when they stick with what's already in use, and make sure that they're extensible for future experimentation. Yes, such functions certainly exist in other languages (so the risk is lower), but there's still a risk that a definition would have a hidden problem unless at least ONE supplier has implemented it with the other functions that ARE defined. #3 in particular presupposes support for arrays of variable size, which certainly NOT all implementations support (nor do they need to for many use cases). #1 and #2 are easy enough, though I'd like to know what to name #1. > STANDARDS should NOT depend on the implementation. That would be a poor standard. It usually should be the other way round. ;-) #1: FINDEX() and SEARCHEX() as already proposed in a feature request on the OOo site It is interesting that, although I extensively use *text* spreadsheets, I don't remember using the built-in FIND() and SEARCH() for years now. That says something about the usability of these functions. Actually, even my colleagues don't use them. One thing in common that every study on human errors has brought to light is that errors increase as formulas get more complex. The workaround for the FIND/SEARCH()-problem makes the formula definitely more complex, what do you think? 1.) = OR( FIND("a"; ...) ; FIND("b"; ...) ) 2.) = OR( IF( ISERR( FIND("a"; A1) ); 0 ; FIND("a"; A1) ) ; IF( ISERR( FIND("b"; A1)) ; 0 ; FIND("b"; A1) ) ) Please feel free to correct the above formula IF you find the error. I was NOT able to make OOo Calc compute it. After more that 15 minutes I gave up. 3# ARRAY functions are needed in the broader context of data analysis, NOT purely to get the array, but to do various vector operations. I am looking to the future with optimism. Sincerely, Leonard Mada > It's certainly a reasonable idea. Is there anyone else who believes we should add these functions at this time? If so, can you point to a reasonable definition for them? If there's significant support, let's do it... but if not, let's wait. > > Actively-used standards, like OpenDocument, are typically revised occasionally. So there's reason to believe that there will be a future opportunity, if they aren't included at this time. In particular, OpenFormula includes a naming scheme that will allow implementations to add new functions that don't interfere with others, and then the ones that become popular can be added to the standard space. > > --- David A. Wheeler > > Thanks for your comment!