nhatcher

11 ms·

1. 181.▲
   by nhatcher 2y ago

   I was tired when I wrote that. I think I just assumed everyone would get that reference
2. 182.▲
   by nhatcher 2y ago

   The server: * Serves the files * Stores if you click share * Converts to xlsx if you download * Imports model The engine is fully compiled to wasm and run in the browser.
3. 183.▲
   by nhatcher 2y ago

   It is a massive amount of work. Another thing I might add, not the most appealing thing to work on.
4. 184.▲
   by nhatcher 2y ago

   Woah, thanks for the kind words! This is out of date, and not a priority ATM, but we will have a TUI for it: https://github.com/ironcalc/TironCalc
5. 185.▲
   by nhatcher 2y ago

   I _think_ I saw the XLFormula-Engine. At least the name rings a bell. I guess I have some reading to do! What is the last one?
6. 186.▲
   by nhatcher 2y ago

   > 1) Any plans for programmatic manipulation of pivot tables? As soon as we possibly can 2) Will there be ability to use the engine as library? Would love to use something like this through Python bindings. That is in place already! It i
7. 187.▲
   by nhatcher 2y ago

   At the moment they are a full production ready product, we only have an MVP. If and when we reach version 1.0 we might be comparable. And you might want to use one or the other. It its difficult to say who the two product will compare in a
8. 188.▲
   by nhatcher 2y ago

   I think I understand the cult part of Excel. And to be honest, Excel is a fantastic tool. I don't think IronCalc can ever replace Excel (a boy can dream though!). But many companies need a spreadsheet of sorts they can embed in their p
9. 189.▲
   by nhatcher 2y ago

   You are right. I created a ticket to remedy this: https://github.com/ironcalc/ironcalc.github.io/issues/14
10. 190.▲
    by nhatcher 2y ago

    At the time of writing, you can use Rust, Javascript and Python bindings. The React front-end communicates with wasm compiled from Rust. Java bindings are planed but not in the next ~6 months. A client/serve architecture (like libreoff
11. 191.▲
    by nhatcher 2y ago

    The data is stored in your browser's localStorage. I think the take is a tad different form pysheets. Cool tool though!
12. 192.▲
    by nhatcher 2y ago

    The idea is to have an egine that is clearly separated from the various "skins" like a React, Vue, a TUI or a desktop app. At the moment the React component is a bit difficult to use in isolation. I need to provide a npm package t
13. 193.▲
    by nhatcher 2y ago

    Woah! I didn't realize luckysheets renamed to univerjs! I think at the time being you should stick to univerjs as it is a finalized product. Once we reach version 1.0, IronCalc should be easier to deal with and you cold consider using
14. 194.▲
    by nhatcher 2y ago

    Hi snthpy, that is planed! We used to have that, but I removed it to simplify the UI. If you don't mind compiling yourself there is a somewhat rough tool tat does that: https://github.com/ironcalc/IronCalc/blo
15. 195.▲
    by nhatcher 2y ago

    Thanks! Yes, that is exactly the top priority of the project right now.
16. 196.▲
    by nhatcher 2y ago

    Yeah, that is not our battle. At least not right now. Excel, and Google sheets, are and will be far more advanced than IronCalc. What we can do is to cater different needs. The focus is on lightweight and open source. Given the billions of
17. 197.▲
    by nhatcher 2y ago

    They are both amazing tools!
18. 198.▲
    by nhatcher 2y ago

    Thanks for the feedback. I will try to build a more detailed compatibility reference as you describe.
19. 199.▲
    by nhatcher 2y ago

    I've said this in some other comment. We can't and will never be as feature full as Excel. We want to find different use cases. A super light spreadsheet with MIT license that you can use anyway you want. If I were to go closed so
20. 200.▲
    by nhatcher 2y ago

    Oh wow! Good find!
21. 201.▲
    by nhatcher 2y ago

    Can only agree with you. I just created a ticket for this: https://github.com/ironcalc/ironcalc.github.io/issues/14 As I said somewhere else I had really bad marketing skills. Maybe I should talk to someone w
22. 202.▲
    by nhatcher 2y ago

    Thanks! There is not a detailed tracking of all Excel features. But we track: 1. Function implementations: https://github.com/ironcalc/IronCalc/labels/Functions 2. Dynamic arrays, defined names, pivot tables,
23. 203.▲
    by nhatcher 2y ago

    Yes, IronCalc is first a spreadsheet engine. Meaning it is a library you can consume from Rust or Python without any UI.
24. 204.▲
    by nhatcher 2y ago

    Yes, it is an open format: https://ecma-international.org/publications-and-standards/st...
25. 205.▲
    by nhatcher 2y ago

    Hi 8n4vidtmkvmk, the algorithms for evaluating spreadsheets are surprisingly tricky mainly because of the dependencies. The dependencies are only know at runtime and in Excel are lazy evaluated. So things like `IF(condition, value1, value2)
26. 206.▲
    by nhatcher 2y ago

    Yes, the compiled WASM is significantly faster. Easily by an order of magnitude. I might be completely wrong about this but I _think_ if the brilliant folks at Microsoft research in the calc intelligence group would have waited a few years
27. 207.▲
    by nhatcher 2y ago

    Not as of now. We first want to be a first class spreadsheet engine that implements 90% of Excel functions and features like array functions, LAMBDA, ... A goal of IronCalc is to make things like integrating Polars trivial for a developer.
28. 208.▲
    by nhatcher 2y ago

    Thanks, those things are on the roadmap :)
29. 209.▲
    by nhatcher 2y ago

    Thanks you very much! Lets continue talking on Discord in the coming days!
30. 210.▲
    by nhatcher 2y ago

    > Do you use cached calculation chains for performance optimizations? Not yet, there is heavy research in that direction. I will write on this soo-ish > Do you take volatile functions into account? Yes, for instance RANDBETWEEN and NO