Kalk issueshttps://invent.kde.org/plasma-mobile/kalk/-/issues2020-12-26T05:41:37Zhttps://invent.kde.org/plasma-mobile/kalk/-/issues/13Binary Calculator2020-12-26T05:41:37ZHan YoungBinary CalculatorAdd binary calculator write in C++ that supports basic math functions.Add binary calculator write in C++ that supports basic math functions.https://invent.kde.org/plasma-mobile/kalk/-/issues/14Scientific Mode2020-12-26T05:43:15ZHan YoungScientific ModeNew UI for scientific mode.New UI for scientific mode.https://invent.kde.org/plasma-mobile/kalk/-/issues/15Programmer Mode2021-03-03T14:31:35ZHan YoungProgrammer ModeNew mode for programming related calculation.
Some ideas:
* Logic calculation
* Base converter
* Hash calculation
* Checksum computationNew mode for programming related calculation.
Some ideas:
* Logic calculation
* Base converter
* Hash calculation
* Checksum computationhttps://invent.kde.org/plasma-mobile/kalk/-/issues/19Decide the parser archteciture2021-02-22T16:25:57ZHan YoungDecide the parser archtecitureCurrently we have flex/bison to deal with the input. All the calculation are done with built-in double type. As many in KDE pointed out, use double for precise calculation is a mistake. To meet the standards of KDE review, we have to switch infinite-precision numeric type. Luckily, knumber class from KCalc can be re-used.
Now the problem is, KCalc takes one or two input and one operator, calculate the result and display it. Kalk keeps the user entered math expression and evaluation the expression on input. Thus, we have to construct a parse tree from expression. To incorporate knumber into Kalk. The easiest way is to let flex return string, and construct knumber from string in bison. Though totally acceptable for practical reasons, we pay the price of extra regex matching (one in flex and one in knumber constructor), which is undesirable.
The other solution is to drop flex, let UI side to notify the type of input element (operator or number). In this way we parse the operators ourselves.
The upcoming binary/programmer mode also needs to take into consideration. @arenagrenade What do you think about this?Currently we have flex/bison to deal with the input. All the calculation are done with built-in double type. As many in KDE pointed out, use double for precise calculation is a mistake. To meet the standards of KDE review, we have to switch infinite-precision numeric type. Luckily, knumber class from KCalc can be re-used.
Now the problem is, KCalc takes one or two input and one operator, calculate the result and display it. Kalk keeps the user entered math expression and evaluation the expression on input. Thus, we have to construct a parse tree from expression. To incorporate knumber into Kalk. The easiest way is to let flex return string, and construct knumber from string in bison. Though totally acceptable for practical reasons, we pay the price of extra regex matching (one in flex and one in knumber constructor), which is undesirable.
The other solution is to drop flex, let UI side to notify the type of input element (operator or number). In this way we parse the operators ourselves.
The upcoming binary/programmer mode also needs to take into consideration. @arenagrenade What do you think about this?