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?
- From: robert_weir@us.ibm.com
- To: office-formula@lists.oasis-open.org
- Date: Sun, 17 Feb 2008 12:06:02 -0500
"David A. Wheeler" <dwheeler@dwheeler.com>
wrote on 02/16/2008 09:44:19 PM:
> Andreas J Guelzow:
> > I had the impression that in the past we never even entertained
> > suggestions for functions (or extension to functions) that weren't
> > implemented by at least one program that supported ODF.
>
> Our general rule has been that it had to be at least one spreadsheet,
> whether not it supported ODF. (We've made a few exceptions,
primarily on
> the grounds of portability/internationalization.) In this case,
we have an
> example - Excel. It doesn't support it the same way but we do have
an example.
>
And this certainly makes sense for the initial release
of OpenFormula, which is trying to capture the existing range of spreadsheet
functions and specify their behaviors. But once that phase of work
is complete, I think we can add additional ones, even if not already implemented
by a vendor. Remember, we have most of the ODF vendors already represented
on the ODF TC, so they can and will speak up for their interests and concerns.
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". You
can make an argument for a partition like that for a general purpose word
processor for general purpose use. But it doesn't always lead to
a useful breakdown of functionality once you get into the advanced stuff.
For example, FFT would presumably go into the "large.h"
library. But this would encompass everything from advanced financial,
to advanced engineering, to advanced string manipulation functions. Not
something that matches any real-world task.
An alternative, or supplementary way to look at this
is to have specialized libraries, akin to 'signal-processing.h' or 'bonds.h'
that would bring in specialized functions. So, if we wanted, we could
define these advanced functions in such libraries. 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.
-Rob
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]