Cosmetic fixes for --dice and --sides-as-letters options
bwbug opened this issue · comments
Thought I'd give you an easy one to tackle this time!
For the --dice
option, you currently switch from a concatenated format with a single-character width per dice roll value (123
) to a hyphenated form with a zero-prefixed double-character width (01-02-03
) when the number of dice sides is 9 or greater. This may be an off-by-one error, as it makes more sense to change the format when the number of dice sides is 10 or greater. In fact, even a sequence of 10-sided dice rolls would be uniquely decodable without the hyphens (not that I'm suggesting you should set the threshold at 11...).
For compactness, I would suggest keeping the single-character-width concatenated format for all cases except when --sides-as-letters
is false and <DICE_SIDES>
is 10 or greater. Currently, you ignore the state of --sides-as-letters
when determining the width of the dice roll format. With the suggested change, --dice 16 --sides-as-letters
would generate hexadecimal numbers.
Incidentally, in the help for --sides-as-letters
, you currently state that letters will be used to represent numbers "higher than 10". This should be "higher than 9".
Ah yeah, these dice options got a bit messy when I didn't know what to zero-index and what to 1-index.
As you suggested, I tweaked --dice 9
to output without hyphen, 1-indexed.
22626 wrecker
22627 wrecking
22628 wrench
22629 wriggle
22631 wriggly
22632 wrinkle
22633 wrinkly
22634 wrist
22635 writing
22636 written
22637 wrongdoer
22638 wronged
22639 wrongful
22641 wrongly
22642 wrongness
22643 wrought
22644 xbox
22645 xerox
22646 yahoo
22647 yam
22648 yanking
22649 yapping
22651 yard
22652 yarn
22653 yeah
22654 yearbook
22655 yearling
22656 yearly
22657 yearning
22658 yeast
22659 yelling
22661 yelp
22662 yen
--dice 10
still hyphenates, going from 01
to 10
(basically, 1-indexed).
08-08-04-04 yeah
08-08-04-05 yearbook
08-08-04-06 yearling
08-08-04-07 yearly
08-08-04-08 yearning
08-08-04-09 yeast
08-08-04-10 yelling
08-08-05-01 yelp
08-08-05-02 yen
08-08-05-03 yesterday
08-08-05-04 yiddish
08-08-05-05 yield
08-08-05-06 yin
08-08-05-07 yippee
08-08-05-08 yo-yo
08-08-05-09 yodel
08-08-05-10 yoga
08-08-06-01 yogurt
08-08-06-02 yonder
08-08-06-03 yoyo
08-08-06-04 yummy
08-08-06-05 zap
08-08-06-06 zealous
08-08-06-07 zebra
08-08-06-08 zen
08-08-06-09 zeppelin
08-08-06-10 zero
08-08-07-01 zestfully
08-08-07-02 zesty
08-08-07-03 zigzagged
There still remains a small inconsistency: For sides 10 through 36, --sides-as-letters
is always 0-indexed. But when not using --sides-as-letters
, it's 1-indexed. I think this is OK, though? Or are physical die with 10 or more sides often 0-indexed?
Incidentally, in the help for --sides-as-letters, you currently state that letters will be used to represent numbers "higher than 10". This should be "higher than 9".
I don't think this is correct? --dice 10 --sides-as-letters
just uses 0 to 9. Maybe I just tweaked that?
I did my test with v 0.2.30, so it may have changed since then, but if I specify sides as letters for dice with 12 sides, say, then the digits are 0,1,2,3,4,5,6,7,8,9,a,b. So a=10, and b=11. That's why I thought it made sense to say letters will be used for numbers "higher than 9". But I agree it gets ambiguous with the switch from 0-indexing to 1-indexing.
Perhaps you can say "double-digit values will be represented as letters".
Edited to Add:
For sides 10 through 36, --sides-as-letters is always 0-indexed. But when not using --sides-as-letters, it's 1-indexed. I think this is OK, though? Or are physical die with 10 or more sides often 0-indexed?
I think that the current scheme is OK. Will --sides-as-letters
suppress the hyphenation, though? I think it should, since there is no need for it.
Another idea is to always make sides-as-letters 0-indexed, even for dice with fewer than 10 faces. That will make the behavior consistent for any size dice.
Will --sides-as-letters suppress the hyphenation, though? I think it should, since there is no need for it.
Yes, --sides-as-letters
is never hyphenated, at least as of Tidy v 0.2.60.
Gonna leave it as it is in v 0.2.60 for now and close this issue. Feel free to reopen this issue (or make a new one) if you have suggested edits to the 0.2.60 functionality!
OK, I've played a little with version 0.2.61, and I noticed that the dice roll values are 0-indexed for --dice 2
and --dice 3
, as well as for --sides-as-letters
if and only if the dice has 10 or more sides. In my opinion, this is a bit inconsistent and unpredictable, and therefore confusing.
My suggestion for a consistent behavior, would be to always use 0-indexed values when --sides-as-letters
has been specified (even for dice with fewer than 10 sides), and to always use 1-indexed values when --sides-as-letters
is false (omitted). Hyphenation would work as it currently does: the values are only hyphenated if --sides-as-letters
is false (omitted) and the number of dice sides is 10 or greater.
This would make the --sides-as-letters
option do double duty as an option for switching from 1-indexing to 0-indexing. If you want to capture this dual functionality in the name of the option, you could rename it --sides-as-base
(because it effectively expresses the dice-roll values as numbers in a base-N system, where N is the number of sides of the dice). Thus, --dice 2 --sides-as-base
makes the dice roll values into a binary number, --dice 16 --sides-as-base
makes them hexadecimal, etc.
I hope you like this idea!
always use 0-indexed values when --sides-as-letters has been specified (even for dice with fewer than 10 sides)
Done.
always use 1-indexed values when --sides-as-letters is false
Done
Hyphenation would work as it currently does: the values are only hyphenated if --sides-as-letters is false (omitted) and the number of dice sides is 10 or greater.
Done.
This would make the --sides-as-letters option do double duty as an option for switching from 1-indexing to 0-indexing.
Yep, love the simplicity.
If you want to capture this dual functionality in the name of the option, you could rename it --sides-as-base (because it effectively expresses the dice-roll values as numbers in a base-N system, where N is the number of sides of the dice). Thus, --dice 2 --sides-as-base makes the dice roll values into a binary number, --dice 16 --sides-as-base makes them hexadecimal, etc.
Love it. Done! (v 0.2.62).
Here's how I re-wrote the help text:
--sides-as-base
When printing dice roll before word in output, print dice values according to the base
selected through --dice option. Effectively this means that letters will be used to
represent numbers higher than 10. Note that this option also 0-indexes the dice values.
This setting defaults to `false`, which will 1-indexed dice values, and use double-digit
numbers when necessary (e.g. 18-03-08)
Great!
Effectively this means that letters will be used to represent numbers higher than 10.
I still think this should be "higher than 9". I guess if you're thinking about 1-indexed dice with 10 or more sides, then "higher than [a dice roll value] of 10" would make sense. In contrast, I'm thinking about the numerical values that will be printed (which are 0-indexed), in which case it should be "higher than 9".
If you don't agree with "higher than 9", perhaps you can try something like "letters will be used to represent values that would be double-digit in base ten".
I still think this should be "higher than 9"
Whoops, yes, you're right. Fixed.
Think we're in a good place, finally. Thanks for staying on this. Closing (again) for now.