Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Decimal separator and thousands separator #22

Open
wants to merge 4 commits into
base: master
Choose a base branch
from

Conversation

waltertross
Copy link

No description provided.

@waltertross
Copy link
Author

I understand that this is a controversial PR, because adapting to the different conventions for writing numbers can be done in many different ways.
First of all, there is the choice between program arguments (like, e.g., -c to accept commas), that change the behavior of clac for the whole execution, and words (like, e.g., comma or cma), that change the behavior only when they are evaluated and only until they are superseded (e.g., by dot).
Then there is the choice of modes and combinations of modes. Should input and output modes be independent or not? Should the sets of alternative modes be completely orthogonal or not? Should there be a minimum number of modes in order not to confuse people, or should maximum flexibility be the goal?
As the PR stands now, I'm more undecided about the first part (arguments or words) than about the second (modes and their combinations), although the second depends on the first (e.g., because it is less useful to recognize both the dot and the comma at the same time as decimal separators.)

@waltertross
Copy link
Author

Thinking about my previous comment, I found the first big problem with this PR (and with the handling of the thousands separator in general):
if you have pi 3.14159265358979323846 in your words file, you can't use it any more if you start clac with -ct, because the dot is seen as a thousands separator and ignored :-(

@waltertross
Copy link
Author

OK, I fixed that by parsing words without -c and -t. I didn't want to ditch the -t, because I really stumbled upon that when pasting numbers from my (meager) bank account...

@waltertross
Copy link
Author

waltertross commented Jan 12, 2020

I noticed only now that -d can be mistaken to mean “dot”. That's unfortunate. I'm thinking of the following solution:
3 input modes: -b “both”, -c “comma”, -d “dot”. The default is -d. The output mode follows the input mode for -c and -d. For -b, it uses commas if it finds any commas in the input (excluding word expansion), dots otherwise.
-t is allowed with -c and -d, but not with -b. Alternatively, there is no -t, but there is -C replacing -ct and -D replacing -dt, for a total of 5 modes: -b, -c, -C, -d (default), -D. The only drawback would be that capital letters often negate an option, but we could live with that.

@waltertross
Copy link
Author

Other ideas:
-b accepts both dots and commas as decimal separator, but always output dots (less smart but more predictable).
One more mode: -B is the “smart” -b, behaving like I previously proposed for -b.

@waltertross
Copy link
Author

I decided to go with the 5 separator modes (with the “dumb” -b and without -B).

@waltertross
Copy link
Author

One last idea: -e, European mode ;-) Like -b, but displaying , as the decimal separator. Admittedly, that's a bit stretched, but -B would break orthogonality, and I haven't found a better initial yet.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

1 participant