*From*: Donald Permezel <djper1 student monash edu>*To*: "Andreas J. Guelzow" <aguelzow taliesin ca>*Cc*: Gnumeric Dev List <gnumeric-list gnome org>*Subject*: Re: Extending Gnumeric Documentation*Date*: Mon, 23 Aug 2004 11:27:06 +1000

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

**Follow-Ups**:**Re: Extending Gnumeric Documentation***From:*Andreas J. Guelzow

[Date Prev][Date Next] [Thread Prev][Thread Next] [Thread Index] [Date Index] [Author Index]