It is an early alpha multidimensional modeling engine. The main idea is to separate the model from the grid: dimensions, cubes, rules, and views instead of spreadsheet cell formulas.
I am looking for feedback from people who have built or maintained spreadsheet models, especially on whether the abstraction is understandable.
AI code gen means that anything that is currently modeled as a spreadsheet is better modeled in code. You get all the advantages of software - libraries, open source, AI, all the complexity and expressiveness."
“Anything that is currently modeled” would be true if we could guarantee the correctness of AI-generated code.
Business people prefer the familiarity of spreadsheets, or at least some kind of grid. At the same time, I am working on this software out of frustration with spreadsheets, because users are forced to translate A1*B2-style addresses into business meaning.
So I agree that code is one possible direction. But I think there is also a middle ground: business rules over dimensions. Enterprise tools like TM1 have explored this direction for decades.
I've read the docs but I haven't tried it yet. I like the idea of storing n-dimensional data in an n-dimensional table, and I like the separation between the data ('cube') and the views and rules. I like that the rules operate on slices of the data rather than individual cells.
This occupies the space between traditional spreadsheets (simple UI but limited to 2-d) python (multi-dimensional data, and python or tensors (multi-dimensional data, but coding required).
I feel that the current data input is a bit cumbersome. There's a lot to type to enter just one cell value, and multi-dimensional tables contain a lot of cells. A more succinct alternative for data entry could be something like python/numpy multi-dimensional tables: [[[a, b, c], [d, e, f]], [[g, h, i], [j, k, l]]].
Data entry from a view grid (to a 2-d slice of the 'cube') would be more familiar, like a spreadsheet.
A data import feature (from csv, etc) would be useful too.
'Cube' has 3d connotations: 'ngrid' or 'ndata' could be less confusing.
I didn't see any functions like sum or product (or most other spreadsheet functions) to operate on data slices. I'm guessing that this is still proof of concept at the moment.
The goal of this software is to address the gap in the open source ecosystem. This multidimensional approach for modeling (and financial planning/forecasting) is over 40 years old. Systems like TM1 by IBM, Anaplan (to name just a few), have been using it for many decades.
The reason for using the word 'cube' is mainly familiarity of users with the concept of OLAP cube (https://en.wikipedia.org/wiki/OLAP_cube), which is what this tech should perhaps be called.
As for data input... indeed, there is some room for improvement: there are 3 ways of editing a rule: via the rule bar, directly on the grid, and modifying an existing rule using the rule panel. We need feedback to decide which way to keep and what to remove. UX/UI is extremely tricky. Oh, there's also a way to insert a rule via the terminal (text user interface command line).
As for operation on slices, a slice can be defined using specific items in a dimension and omitting others (which will create a data 'slice'): for example if you have a 'cube' D with dimensions A B and C, and each dimension has items 1 2 and 3, then you can define a sum over a slice through this cube via this rule "=sum(D::a.1)" or, more explicitly, "=sum(D::a.1:b.:c.)", if written directly in a cell.
You can fill the whole cube with some value, say, 1, by defining a rule `* = 1` in that particular cube via the rule bar. The rule should produce the total of 9.
I hope this is helpful. Feel free to join the project's discord server (https://discord.gg/GfU5ypAbaD) I will be happy to explain.
There's an Excel import plugin (available via menu 'Plugins') that allowed importing basic Excel files (stripping all formatting, however), but I guess it might need a few hours of work at the moment.
6 comments
[ 2.6 ms ] story [ 23.9 ms ] threadIt is an early alpha multidimensional modeling engine. The main idea is to separate the model from the grid: dimensions, cubes, rules, and views instead of spreadsheet cell formulas.
I am looking for feedback from people who have built or maintained spreadsheet models, especially on whether the abstraction is understandable.
Docs: https://cloudcell.github.io/om-docs/
"prediction re the end of spreadsheets
AI code gen means that anything that is currently modeled as a spreadsheet is better modeled in code. You get all the advantages of software - libraries, open source, AI, all the complexity and expressiveness."
Business people prefer the familiarity of spreadsheets, or at least some kind of grid. At the same time, I am working on this software out of frustration with spreadsheets, because users are forced to translate A1*B2-style addresses into business meaning.
So I agree that code is one possible direction. But I think there is also a middle ground: business rules over dimensions. Enterprise tools like TM1 have explored this direction for decades.
This occupies the space between traditional spreadsheets (simple UI but limited to 2-d) python (multi-dimensional data, and python or tensors (multi-dimensional data, but coding required).
I feel that the current data input is a bit cumbersome. There's a lot to type to enter just one cell value, and multi-dimensional tables contain a lot of cells. A more succinct alternative for data entry could be something like python/numpy multi-dimensional tables: [[[a, b, c], [d, e, f]], [[g, h, i], [j, k, l]]].
Data entry from a view grid (to a 2-d slice of the 'cube') would be more familiar, like a spreadsheet.
A data import feature (from csv, etc) would be useful too.
'Cube' has 3d connotations: 'ngrid' or 'ndata' could be less confusing.
I didn't see any functions like sum or product (or most other spreadsheet functions) to operate on data slices. I'm guessing that this is still proof of concept at the moment.
I do hope this goes further.
The goal of this software is to address the gap in the open source ecosystem. This multidimensional approach for modeling (and financial planning/forecasting) is over 40 years old. Systems like TM1 by IBM, Anaplan (to name just a few), have been using it for many decades.
The reason for using the word 'cube' is mainly familiarity of users with the concept of OLAP cube (https://en.wikipedia.org/wiki/OLAP_cube), which is what this tech should perhaps be called.
As for data input... indeed, there is some room for improvement: there are 3 ways of editing a rule: via the rule bar, directly on the grid, and modifying an existing rule using the rule panel. We need feedback to decide which way to keep and what to remove. UX/UI is extremely tricky. Oh, there's also a way to insert a rule via the terminal (text user interface command line).
As for operation on slices, a slice can be defined using specific items in a dimension and omitting others (which will create a data 'slice'): for example if you have a 'cube' D with dimensions A B and C, and each dimension has items 1 2 and 3, then you can define a sum over a slice through this cube via this rule "=sum(D::a.1)" or, more explicitly, "=sum(D::a.1:b.:c.)", if written directly in a cell.
You can fill the whole cube with some value, say, 1, by defining a rule `* = 1` in that particular cube via the rule bar. The rule should produce the total of 9.
I hope this is helpful. Feel free to join the project's discord server (https://discord.gg/GfU5ypAbaD) I will be happy to explain.
PS
The functions are documented here: https://cloudcell.github.io/om-docs/reference/functions/
There's an Excel import plugin (available via menu 'Plugins') that allowed importing basic Excel files (stripping all formatting, however), but I guess it might need a few hours of work at the moment.