Yet Another Percent (%) request...

[redirect303]

Considering the confusion around the % operator, the immediate solution was to have it removed from SpeedCrunch, but that caused an even more confusing aspect: why that operator yields "invalid expression" and it cannot be used in any mathematical operation?

Please consider that many users are used to conventional calculators, or Excel, where this operator is widely used. As people wished to use the % in different ways, what harm could bring if the user could decide from a settings menu, how the operator behaves? Yes, this would bring a bit of a inconsistency, but again each of us is using their own app... i won't come to your house, to use your SpeedCrunch app.

And to make things safer, the default behavior of % should be "disabled" ... from here on, the user could enable it in the desired mode.

[Musor]

About! copy here as well: "Hello world. I don't quite understand why it was so radically delete the very demanding function of any Calculator. Take any table button calculator. As there is handled by this button? In my humble opinion, you have dealt such a discussion because of trifling issues. Because obviously, if there are several ideological interpretations and ways of use of the sign "%", therefore you just need to provide the user choose in preferences-> input format-> "%"-1) processing is disabled 2) converts the number in decimal. 3) executes the "%" the previous number. P.s. sorry for automatic translation, language does not speak." sorry for repeating.

[Pol Welter]

The percent operator was removed for good reason. See issue #239. I am not going to reiterate on the reasons why it was removed.

This issue specifically requests an option to reenable the percent operator. I strongly object to this.

1. The 'intuitive' behaviour of 5 + 10% = 5.5 is actually very ambiguous and extremely hard to parse (impossible with SC's current parser). This is the reason that there is zero consistency in existing software that do try to implement this operation. A normal calculator with the standard four operations does not know about order of operations, so the percent operation is trivial. It is not for SpeedCrunch. I am not interested in investing significant development time into such an insignificant feature, and I think the other devs agree with me. Even if it was easy, we'd still be making a lot of peaople upset, because the operation would never perform as they intended (because of the ambiguity).
2. The interpretation of a% = a/100, as was previously implemented by SC, is about the only notation that makes pefect semantic sense. Unfortunately it is also the one interpretation that almost no user cares about. So why should we have kept it? If you want an option to have that feature back, I'd be willing to discuss it, but again - no one seems to miss it really.

It is not ideological. The percent notation is fundamentally flawed and not suited for computer algebra.

TL;DR: The old way was useless. The way Excel and co. deal with percent operations are complicated and dangerous and will not happen in SC.

[Helder Correia]

@polwel Thanks for taking the time to summing it all up here :) This is a years-old discussion and we are not looking back, either with the original behavior or a new one.

[Musor]

All deal in the current parser means... I see. Well, in my defense, I can only say one thing. I learned about the existence of SpeedCrunch when I tried to find at least some calculator for windows 10. And the first place I started looking was PortableApps. In their set this program is a calculator, in the singular, there are no others... Probably have to write to their tech support to add another Calculator for ordinary people. Good luck with your development.