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.
If we had a display with n (n>3) pixel colours, say (red, green, cyan, blue) for example, we could display more of the colour space. Shopping list: 4 colour channel display, 4 channel GPU, 4 channel software. Why isn't this a thing already?
5) You'd need image formats that record those channels, and that in turn would cause problems for raw bitmaps with alpha (they either get twice as big or the pixels are no longer aligned).
I'd be concerned about clay heave (where clay shrinks/expands depending on moisture content, which likely varies over the year). If the posts at each end of a panel move out of plane there will be a twisting moment on the panel, and glass doesn't like being bent.
I am not a chemist, so take this with a pinch of salt: wouldn't lead chromate + sodium bicarbonate make lead carbonate, a white precipitate? Sodium bicarbonate is likely in your kitchen cupboard already.
Not a chemist either but lead oxide is actually more soluble in water than lead chromate, so a double replacement reaction won't favor lead chromate -> lead oxide.
> Printf isn't re-entrant, and they are calling it from multiple threads.
This! Simple schedulers generally only allow system calls (such as printf) from the main thread. If you really want to 'print' from a child thread then send a message to the main thread, asking that it prints the message contents on on behalf of the child thread.
This looks useful, I wish I'd found it a month ago.
One suggestion: could we have a more printer-friendly version (ie, without large patches of colour and without large patches of black)?
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.