2 ms·

Show HN: calcl – A Programmatic Calculator

8 points by codr7 7y ago

theamk 7y ago
The magic precision fixed point numbers are super cool. However, if you don't need them, I don't see an advantage over regular languages - for example, Python's interactive shell will do the same and much more
- codr7 7y ago
  Glad you like them, one of the most underrated abstractions in software if you ask me. Floats are just plain evil for most use cases. I spent 13 years maintaining a 2Mloc accounting system written using an exotic mix of float types and layers upon layers of failed attempts to control the resulting rounding chaos. Agreed, same is true of many general purpose languages. One advantage is a stronger compiler with more static guarantees than Python that produces significantly faster code. What is gained from restricting the use case is simplification of syntax and semantics. Once you don't have to cover all bases any more, you don't have to make as many compromises. I'm barely getting started here, once I get around to defining functions/equations/integrals etc. it will become more obvious. Easier embedding/integration is another good reason. Let's say you need to evaluate formulas in some application. Adding Python as a build dependency is serious business and writing your own means reinventing a lot of infrastructure along the way. Finally, building on top of cidk [0] means smooth integration with any language targeting the same framework. The calc opcode mentioned in the README is a good example. [0] https://github.com/codr7/cidk https://github.com/codr7/cidk
stdcall83 7y ago
Nicely done. did you using shunting yard algorithm for parsing the expressions? I also developed developers calculator, but I didn't add support for float as you did. https://www.github.com/mellowcandle/bitwise https://www.github.com/mellowcandle/bitwise
- codr7 7y ago
  Thank you :) Sorry, no. I used to be really into parsing algorithms and tools, and I still consider them useful for more mundane tasks. But the last thing I need when exploring the syntax of a new language is someone else's arbitrary limitations. My language parsers [0] tend to be rather messy recursive-decentish creations. But I think that's fine; since in a new language the syntax should be allowed to move around freely, and prematurely nailing it to the floor to check a box isn't really going to help anyone. What usually happens is I'll tighten the parser as needed along the way when I feel confident enough. Which brings us to the issue with parsing tools, they're all in from the start rather than gradual. https://github.com/codr7/g-fu/blob/master/v1/src/gfu/read.go https://github.com/codr7/g-fu/blob/master/v1/src/gfu/read.go https://github.com/codr7/cidk/blob/master/src/cidk/read.cpp https://github.com/codr7/cidk/blob/master/src/cidk/read.cpp

8 points by codr7 7y ago

The magic precision fixed point numbers are super cool. However, if you don't need them, I don't see an advantage over regular languages - for example, Python's interactive shell will do the same and much more

codr7 7y ago
Glad you like them, one of the most underrated abstractions in software if you ask me. Floats are just plain evil for most use cases. I spent 13 years maintaining a 2Mloc accounting system written using an exotic mix of float types and layers upon layers of failed attempts to control the resulting rounding chaos. Agreed, same is true of many general purpose languages. One advantage is a stronger compiler with more static guarantees than Python that produces significantly faster code. What is gained from restricting the use case is simplification of syntax and semantics. Once you don't have to cover all bases any more, you don't have to make as many compromises. I'm barely getting started here, once I get around to defining functions/equations/integrals etc. it will become more obvious. Easier embedding/integration is another good reason. Let's say you need to evaluate formulas in some application. Adding Python as a build dependency is serious business and writing your own means reinventing a lot of infrastructure along the way. Finally, building on top of cidk [0] means smooth integration with any language targeting the same framework. The calc opcode mentioned in the README is a good example. [0] https://github.com/codr7/cidk https://github.com/codr7/cidk

stdcall83 7y ago

Nicely done. did you using shunting yard algorithm for parsing the expressions? I also developed developers calculator, but I didn't add support for float as you did. https://www.github.com/mellowcandle/bitwise https://www.github.com/mellowcandle/bitwise

codr7 7y ago
Thank you :) Sorry, no. I used to be really into parsing algorithms and tools, and I still consider them useful for more mundane tasks. But the last thing I need when exploring the syntax of a new language is someone else's arbitrary limitations. My language parsers [0] tend to be rather messy recursive-decentish creations. But I think that's fine; since in a new language the syntax should be allowed to move around freely, and prematurely nailing it to the floor to check a box isn't really going to help anyone. What usually happens is I'll tighten the parser as needed along the way when I feel confident enough. Which brings us to the issue with parsing tools, they're all in from the start rather than gradual. https://github.com/codr7/g-fu/blob/master/v1/src/gfu/read.go https://github.com/codr7/g-fu/blob/master/v1/src/gfu/read.go https://github.com/codr7/cidk/blob/master/src/cidk/read.cpp https://github.com/codr7/cidk/blob/master/src/cidk/read.cpp