"Excel" for the CPC - SYMCALC spreadsheet application

[Prodatron]

In 2008 I started an engine for a spreadsheet application, but due to another (stupid) hobby these routines collected dust for many many years.
Now finally I restarted the work on this spreadsheet application for SymbOS again, which is currently called "SymCalc" (not sure about the final name).
SymCalc should provide all usual functions of a more or less modern spreadsheet application. Memory and display/format handling is nearly finished now (only date/time stuff is missing), GUI stuff is mostly finished as well (like navigating, marking cells etc.).
The next big step is implementing formula handling. Yes, the most important stuff of course.
The plan is to have a full automatic recalculation of cells in any direction which wasn't usual for 80ies spreadsheet applications.
SymCell is already able to handle a field of 64x125 cells with a maximum amount of 1024 used cells. Maybe this can be extended to 64x250 and 2048 used cells, but let's see.
Currently the bottom line on the screen shots is a dummy one. The right part will be implemented. But currently I am not sure, if multiple sheets within the same file will be possible in the future, using references between sheets.

You cannot view this attachment.

You cannot view this attachment.

You cannot view this attachment.

You cannot view this attachment.

You cannot view this attachment.

You cannot view this attachment.

You cannot view this attachment.

[Gryzor]

Ok, this is seriously impressive and ambitious! 

Can you explain the bit about calculation in any direction? I didn't know it was a limitation back in the day, but why was it so?

[St-BeidE(DE/GB)]

Prodatron,  you are insane... 
I run into trouble,  next time I give students a guest lecture. How to explain, the CPC is from the 80s ? 

Steven

[McArti0]

Handle the SLK (sylk) format as it is in Multiplan under CPM as well as in the new Excel

[Prodatron]

Can you explain the bit about calculation in any direction? I didn't know it was a limitation back in the day, but why was it so?

This is what I saw at least in VisiCalc (Apple 2) and Mastercalc (CPC).

The recalculation usually starts at A1, then A2, A3 etc, then B1, B2, B3 and so on.
You could change the setting, that it does first A1,B1,C1 etc. then A2,B2,C2 and so on.

Usually this is fine, but when you have some chained references, which are hopping forward and backward, it won't update the sheet correctly automatically. In this case you could trigger an additional recalculation process manually. And if you have multiple references which are going in the wrong direction, you have to do this multiple times. Of course this is not the normal way how you create a table, so in most cases this was not an issue.

[Gryzor]

Can you explain the bit about calculation in any direction? I didn't know it was a limitation back in the day, but why was it so?

This is what I saw at least in VisiCalc (Apple 2) and Mastercalc (CPC).

The recalculation usually starts at A1, then A2, A3 etc, then B1, B2, B3 and so on.
You could change the setting, that it does first A1,B1,C1 etc. then A2,B2,C2 and so on.

Usually this is fine, but when you have some chained references, which are hopping forward and backward, it won't update the sheet correctly automatically. In this case you could trigger an additional recalculation process manually. And if you have multiple references which are going in the wrong direction, you have to do this multiple times. Of course this is not the normal way how you create a table, so in most cases this was not an issue.

Interesting. I can see how it can be an issue when you first think of it ("oh, how will we scan the table to update stuff?") but... It's not like you don't already have a matrix of what values are dependent on other values so that you can do it in an arbitrary way?

[Prodatron]

So you suggest to generate something like pathes, which define, in which order the cells have to be recalculated as soon as something has been updated. You check, if a cell is included in such a path, and when you find it, you follow the remaining part of the path and update all mentioned cells in the correct order. This would result in a very fast and always correct recalculation. As soon as you change references inside a formula you have to regenerate one of these pathes.

My current approach was to find all affected cells in realtime again and again after each update, but maybe this will become slow when having a lot of cells. Then you could at least cache the recalculation order.

Anyway that is an interesting problem

[Gryzor]

I was thinking more along the lines of your own solution (which, if I understand it correctly, does include creating some paths on the fly). But I see no need to do it realtime; you could just run it when a cell is changed?

[Prodatron]

Yes, you are right, only when a cell is changed. I just wonder, if changing a cell could take a while as soon as you have a few hundrets of them, and it always has to generate the whole path again. In this case pre-generated pathes could be a solution. Then only changing formulas would take some time, but some additional memory for storing the pathes will be required as well.

[Gryzor]

On one hand, the grid is comparatively small so you can run through it rather quickly. On the other hand, I guess it's going to introduce *some* delay when it runs, but hey, I wouldn't be bothered by it if I had a fully graphical spreadsheet on my z80 😁 Especially if there was an option to run it manually when needed.

[Prodatron]

Handle the SLK (sylk) format as it is in Multiplan under CPM as well as in the new Excel

Thanks for the hint! Phew let's see!
https://en.wikipedia.org/wiki/Symbolic_Link_(SYLK)
Maybe a basic SLK import/export function can be done when there is enough time.

[m_dr_m]

Slick and Sick. @Overflow will be able to start coding on CPC again!