Comparing SS with Gnumeric, etc.

Functions

Traditional spreadsheet calculators typically provide hundreds of functions. For example, the Gnumeric function reference says:

  Gnumeric currently has 583 functions for use in spreadsheets.
  194 of these are unique to Gnumeric.

sc, one of the first spreadsheets, originally written by James Gosling, has about 60 functions.

SS currently has 76 functions (and 20 commands), so it is comparable to sc in that respect.

It is easy to add new functions to SS: to add a numeric function named foobar simply create nf/foobar.c, using one of the existing functions as a guide, and recompile.

Although more functions will surely be added to SS, current development is focused on adding features which make it different (and hopefully better) than existing spreadsheets, rather than making it more the same.

Formulas

Consider making a table of square-roots of the numbers from 1 to 50, except that row 25 will be set to a25/2 instead of sqrt(a25).

Using SS:

% cat sqrt.ss
fill a1:a50 1, 1;
b1 = sqrt(a1); copy b2:b50 b1;
b25 = a25/2;
eval; print pointers formulas values;
% SS <sqrt.ss >sqrt.ss.out
%

b1:b50 = { sqrt(a1) };

Note that the SS output contains a warning about overwriting cell B25 since the formula for that cell was changed from sqrt(a25) to a25/2. The warning could be eliminated using two copy commands which skip over B25:

b1 = sqrt(a1); copy b2:b24 b1; copy b26:b50 b1;

Looking at sqrt.ss, it is obvious that cell B25 is set to a different formula than the other cells in column B. Looking at the spreadsheet output it may not be so obvious, especially if we had used hundreds or thousands of rows instead of just 50, with one row different.

In traditional spreadsheets, the process used to create formulas is not saved (or at least is not directly visible to the user, see the Gnumeric and Excel examples below). This makes it difficult to verify that all of the formulas are correct, and is the source of many errors.

Another source of confusion, as well as errors, is what happens to formulas when rows or columns are inserted or deleted. If A1=B1/2 and a new column is interactively inserted between columns A and B, should the formula in A1 refer to the new column or the original B column? If column B is deleted should the formula in A1 represent an error or should it refer to what used to be column C? The behavior of spreadsheets for these cases can be documented but might not be obvious.

For SS the situation is simple, one can not insert or delete rows or columns so there is no confusion in that regard. During development of a spreadsheet, the flexibility provided by insertion and deletion can be achieved to some extent using C preprocessor macros to define symbolic constants and assign names to ranges, as shown for example in the documentation llsq "poly" example.

Copying and Sharing Formulas

In SS, copying and range assignment copy only a reference to a formula, which can be seen in the first part of the example output (sqrt.ss.out); the pointers in column B are all the same except for row 25. The sqrt() formula is only stored once.

This seems to also be true for Gnumeric and Excel: see gnumeric.xml and excel.xlsx.d/xl/worksheets/sheet1.xml for results saved using the default file format, using the same sqrt() example with interactive fill/copy/paste commands used to create the spreadsheets. For Gnumeric, the formula sqrt(A1) for cell B1 has ExprID="1" which is referenced by cells B2:B24,B26:B50. For Excel the formula in cell B2 is marked t="shared" ref="B2:B50" si="0" and is referenced by cells B3:B24,B26:B50.

For libreOffice Calc, copied formulas seem not to be shared, as can be seen in calc.sxc.d/content.xml and calc.ods.d/content.xml.

For sc, copied formulas are not shared, as can be seen in sqrt.sc. Interestingly, sc's interactive commands are also accepted in its input file format, so, for example, it accepts the following input, sqrt_commands.sc:

fill a1:a50 1 1
let b1 = @sqrt(a1)
copy b2:b50 b1
let b25 = a25/2