Uses statrs for numerical functions
REFACTOR: Put statistical functions on its own module
This might seem counter-intuitive but the wasm build after this refactor
is 1528 bytes smaller :)
* update: available status for implemented functions
* update: adds xlsx test for MROUND, TRUNC and INT
* update: adds unit test for MROUND, TRUNC and INT
* update: adds unit test for EVEN and ODD functions
* update: adds xlsx test for EVEN and ODD functions
* update: adds EVEN and ODD doc pages
* update: Math and Trigonometry main page links to new functions
* update: changes to functions badge type in main Math and Trigonometry page
* update: adds DEGREES and RADIANS documentation pages
* update: adds DEGREES and RADIANS xlsx tests
* update: Math and Trigonometry main page links
* update: removes links to missing example file
* UPDATE: Adds missing information functions
Implements N, CELL, INFO and SHEETS
Note that INFO is implemented as N/IMPL! and CELL is not implemented
for those values that is not implemented in Excel for the web
* FIX: Copilot fixes
* FIX: Make clippy happy
* UPDATE: package lock
* FIX: Add function definitions
* FIX: Small fix to get FACT working
* FIX: We only need integer FACT and FACTDOUBLE
* FIX: Make clippy happy
I would like to have a text case for this. Preferably automatic.
But manual is ok, maybe we should have a series of workbooks we check
before every large deployment
# This PR introduces:
## Parsing arrays:
{1,2,3} and {1;2;3}
Note that array elements can be numbers, booleans and errors (#VALUE!)
## Evaluating arrays in the SUM function
=SUM({1,2,3}) works!
## Evaluating arithmetic operation with arrays
=SUM({1,2,3} * 8) or =SUM({1,2,3}+{2,4,5}) works
This is done with just one function (handle_arithmetic) for most operations
## Some mathematical functions implement arrays
=SUM(SIN({1,2,3})) works
This is done with macros. See fn_single_number
So that implementing new functions that supports array are easy
# Not done in this PR
## Most functions are not supporting arrays
When that happens we either through #N/IMPL! (not implemented error)
or do implicit intersection. Some functions will be rather trivial to "arraify" some will be hard
## The final result in a cell cannot be an array
The formula ={1,2,3} in a cell will result in #N/IMPL!
## Exporting arrays to Excel might not work correctly
Excel uses the cm (cell metadata) for formulas that contain dynamic arrays.
Although the present PR does not introduce dynamic arrays some formulas like =SUM(SIN({1,2,3}))
is considered a dynamic formula
## There are not a lot of tests in this delivery
The bulk of the tests will be added once we start going function by function# This PR introduces:
## Parsing arrays:
{1,2,3} and {1;2;3}
Note that array elements can be numbers, booleans and errors (#VALUE!)
## Evaluating arrays in the SUM function
=SUM({1,2,3}) works!
## Evaluating arithmetic operation with arrays
=SUM({1,2,3} * 8) or =SUM({1,2,3}+{2,4,5}) works
This is done with just one function (handle_arithmetic) for most operations
## Some mathematical functions implement arrays
=SUM(SIN({1,2,3})) works
This is done with macros. See fn_single_number
So that implementing new functions that supports array are easy
# Not done in this PR
## Most functions are not supporting arrays
When that happens we either through #N/IMPL! (not implemented error)
or do implicit intersection. Some functions will be rather trivial to "arraify" some will be hard
## The final result in a cell cannot be an array
The formula ={1,2,3} in a cell will result in #N/IMPL!
## Exporting arrays to Excel might not work correctly
Excel uses the cm (cell metadata) for formulas that contain dynamic arrays.
Although the present PR does not introduce dynamic arrays some formulas like =SUM(SIN({1,2,3}))
is considered a dynamic formula
## There are not a lot of tests in this delivery
The bulk of the tests will be added once we start going function by function
## The array parsing does not respect the locale
Locales that use ',' as a decimal separator need to use something different for arrays
## The might introduce a small performance penalty
We haven't been benchmarking, and having closures for every arithmetic operation and every function
evaluation will introduce a performance hit. Fixing that in he future is not so hard writing tailored
code for the operation
