Re: Extending Gnumeric Documentation

[Donald Permezel <djper1 student monash edu>]

Firstly, many thanks for looking over the document Andreas, I greatly appreciate it.


> Functions cannot only return single values as you indicated in your
> e-mail, but also whole arrays of values, so many `analysis tools' could
> be better implemented using a single array returning function.

I understand and agree, but I would like to comment that while I knew this at the time of writing the e-mail, 
it did take me some time to figure out both that functions can do this and how to do it 
(control-shift-enter?).  Perhaps for those functions that do return an array of values could have the 
information about how to do so in the function description?  

Furthermore, while I understand that many sorts of analysis may be better conducted by using functions, I 
think at times (while an array can be output) the one-cell nature of functions, makes some sorts of analysis 
with them inappropriate, for example most of the 'Statistical Analysis Tools'.  I think a written 'tool' 
rather than a function would be used perhaps when, for example, an engineer wishes to 'rank' (as the 'Rank 
and Percentile' tool) a multi-columned data set along quite complicated (or highly iterative) criterion.  In 
Microsoft Excel, had I wanted to so something like this I would write a VBA macro to attack the data, and put 
the result on a new sheet (as I had chance to do during my internship) - I imagine this would be the Gnumeric 
equivalent.



> Moreover, a problem I see with all analysis tools in the 1.2.x release
> and most in 1.3.x is that they provide constant values that do not
> change with any values in the source data. In my mind this contradicts
> the basic idea of a spreadsheet where values are recalculated whenever
> the source values change. In the current cvs, you may notice that
> various tools (One-way ANOVA, correlation, covariance, descriptive
> statistics,...) allow the user to choose between formulas and values
> with formulas being the default. These tools therefore build a formula
> structure in the target range that will recalculate its values on the
> fly as the source data changes. Users that want to freeze those values
> can simply choose the `values' option.

I wholeheartedly agree that the capacity to output formulas referring to the input cells in the statistical 
analysis tools is a powerful feature for obvious reasons.  I imagine the implementation is such that if 
'formulas' rather than 'values' is selected, within the analysis tool formulae are output to the sheet which 
use existing functions to show the desired values in the correct cells.  That is to say it is on an 
individual basis for each analysis tool that the developer (yourself, if I understand correctly) must 'figure 
out' the functions and formulae to go in each cell to display the same output as if 'values' had been 
selected (albeit with the 'dynamic updating' property of formulae).  As a side-note if you want any help with 
this I'd be more than glad to offer any help I can.

It is for this reason that I think the _capacity_ to only allow value output rather than value or formula 
output is a powerful feature aswell.  If you would again take my example of an engineer wishing to conduct 
very iterative analysis on data - he or she may find the implementation (development) of the tool, such that 
all the analysis is calculated with formulae on the sheet (considering its possibly highly iterative nature) 
impossible, or at best extremely time consuming.  Furthermore such situations may arise when the 
'live-update' property of formulae (rather than values) isn't very important- perhaps the data sets to be 
analyzed never (or infrequently) need to be changed after analysis.

Perhaps I could change the documentation to detail the ability to work with formula rather than values as in 
1.3.x?  With the several statistical functions already implemented with formulae as a reference I'm sure I 
could manage it.  Is there anything else you (or anyone else) think might be expanded upon or improved?



> On a more specific note, the use of dialog_tool_init requires that the
> glade file uses specific field names otherwise chaos results.

Thanks!  I'll investigate that and update the documentation as soon as I have it figured.



Many thanks again,
Don