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


Help: OASIS Mailing Lists Help | MarkMail Help

office-formula message

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

Subject: Re: [office-formula] Add FFT() to formula spec?

> Our general rule has been that it had to be at least one spreadsheet,
> whether not it supported ODF.

Robert Weir:
>The challenge I think is how we partition the spreadsheet functions into
>interoperable libraries of related functions.  Think of C or C++ standard
>libraries.  What we have today is like having all functions in one big
>header file "library.h".  Or maybe "small.h", "medium.h", and "large.h".

No, the spec is already divided into different types of functions
(Statistical, etc.), and they are ALSO defined as groups... as well as the
small/medium/large cross-cutting groups.  We can certainly define
new groups, but there are already groups in the spec BESIDES
small/medium/large.  Take a look at the spec's table of contents -
note that it's already divided into logical groups.  These headings are already
defined to have meaning in the spec.

It's true that this grouping is not reflected in the names themselves,
simply because spreadsheets don't do so in the "real world".  It's not even
clear you WANT to do this.  Where does SUM belong, for example?

>You could even require the
>ODF file to declare or "import" them in the manifest file or in metadata
>so an application will quickly know whether they can support them.

We discussed that early on.  It is alluring, but after discussion, I think it's a bad idea.  Basically:
* No user will do that for the "built-in"s, so the usual model for programming languages doesn't make sense here.
* It could be determined automatically by the implementation, but it's extra effort not done by any extant implementation.  Basically, you have to walk through all formulas to figure out which functions or groups are used, and then to include that info in the data.  We generally avoid inventing "new things implementations must do" unless there's a clear need, and it's clearly NOT needed.
* It's work to check that when you read back in - again, done by no implementation.
* It doesn't actually help - no problem is solved by doing so!!! (Okay, so I led up to this one.  Sue me. :-)  )

Why doesn't it actually help?  Because spreadsheet implementations often implement
only the "functions they need for their users", which tend to be subsets of particular
groups.   So reporting that you use the "Engineering group" when you only need
one of their functions isn't helpful... because such a statement would require complete implementation of the group, but you really only needed one function.  So reporting on "groups" is not just misleading... it interferes with interoperability!!

Yes, you COULD list every specific function you need in the header.  But why do that?  An implementation can find out which functions are needed by reading in the file. It just doesn't take long to read in a file, and find exactly the functions you use.  (It's different for things that aren't function names.)  Saving the 0.001 seconds by reading a header instead of a file perhaps made sense with 4K computers, but it's just a false economy today.  Today, spreadsheets may be created dynamically by splicing together XML files; we do that now! For dynamism it's better to NOT require a header with such information, because trying to keep the header consistent is extra work for no benefit.  Just let the reader discover what's needed.

When writing a program with a traditional programming language, it _IS_ useful to have
library declarations.  If OpenFormula ever grows to allow function definition, then
it _would_ make sense to have such declarations.  But for "built-in" functions, I 
don't think they help much.  You can trivially determine if the functions needed
are supported without such a mechanism.  I note that many languages today have a "built-in" library that does NOT require declaration. That's the role of the functions defined in the current spec.

--- David A. Wheeler

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