doz - a library for displaying numbers in Dozenal (base-12)

dozenal

• EDIT: Renamed the library, and redid the API at /u/egoneibre's suggestion.

This will probably be a relatively niche library, only really used by the same loons that want dozenal to replace decimal… like me.

The reason I made this library is because the standard library didn't have a way to display base-12 numbers with my own digits; the only option was to have A and B represent ten and eleven, and then replace those characters with the desired symbols. Pretty sure there's also no way to display non-decimal decimals. Figured I'd just make this library.

You can check out the documentation over on GoDoc.

I usually only program as a hobby, so this is probably the first golang library I've made for others. As such, I'd really appreciate feedback, and ways to improve my code.

For example, I've noticed the Rat() function takes a considerable amount of time to calculate fractions with a long sequence of repeating digits, likely because the check for repeating digits is expensive. Not sure how to fix it, actually.

Any input would be welcome.

---

评论：

egonelbre:

Name of the package should be clear what it contains. Seeing doz.Str(i) in code is not clear. For example, if it were base12.Amer.Int(i) it would be clear in it's intent. dozenal would also be better, however most people don't know what it means without searching.

https://github.com/TUSF/doz/blob/master/doz.go#L56 and https://github.com/TUSF/doz/blob/master/doz.go#L84 are confusing in that both functions Int and Str return a string. Use consistent naming scheme BigInt, Int, Int64 depending on what it accepts. For parsing you can use ParseBigInt, ParseInt etc.

TUSF:

dozenal would also be better, however most people don't know what it means without searching.

Might be true. I'll probably change the name to dozenal for now though, seeing as dozenal people would rather the base12 bit be base10 instead, if you know what I mean.


Use consistent naming scheme

Gotcha. Actually, your base12.Amer.Int(i) example has me thinking it might be good to have a "Formatter" struct that holds the usable digits and methods. Just have a couple default options. Not sure if it should have a method for each built-in integer type though. Int64 and UInt64 should be enough, no?

egonelbre:

Might be true. I'll probably change the name to dozenal for now though, seeing as dozenal people would rather the base12 bit be base10 instead, if you know what I mean.

I know what you mean. However, one of the questions is about communication. Would people who like dozenal system understand what base12 means or not? Even though they might not like it, I would guess they will still understand it. Your code is still written in decimal notation. So, I would say, meaning of base12 can be more easily inferred than dozenal. (There's prior-art base32, base64, base58).

However, when you reach for a dozenal system you probably have a reason and knowledge about it; so package dozenal might be fine and clear for the target audience. (There's prior-art hex.)


Not sure if it should have a method for each built-in integer type though.

Necessary, probably not. I would write it for int, int64, *big.Int... Or if it's always unsigned, then for the corresponding unsigned types. Then later add things as the need arises.

jerf:

I'll probably change the name to dozenal for now though, seeing as dozenal people would rather the base12 bit be base10 instead, if you know what I mean.

Within a given programming language, you don't really want those sorts of context changes. Many non-English programmers still program in English, because that fits with the rest of the language community and code better, a far more intrusive agreement than numeric base! While you may write a program that exposes a dozenal-based number experience to the world, you really want to stick to a consistent base within the implementation of that program, and the entire rest of the language and libraries are in base-10, most notably including the fact that including a number constant in the code in the form ONE-ZERO will result in, well, ten. So even within a "I like dozenal and think everyone and everything should use it" mindset, base12 remains the correct thing to call a Go library. By the same logic, if you did have a dozenal-based programming language, the correct name for a library implementing conventional Arabic numerals is baseX, not base10 there either.

HowardTheGrum:

I would agree that using base10 would be problematic, but I don't see a problem with using dozenal. 

As a point in support of it as opposed to base12... perhaps it might be interesting for supporters of dozenal math to extend your library to be able to use go generate to process a .doz file with go code written in dozenal, and translate it to a .go file written in decimal? Then you could actually code in dozenal, not just use dozenal in the output of the code. You would obviously need to pass the unicode values for 10 and 11 in to the go generate command, but that shouldn't be a problem, I think? 

jerf:

I don't see a problem with using dozenal. 

My apologies for my lack of clarity. I was merely discussing the second clause of what I quoted about how they'd like dozenal to be base10 rather than base12, but I see how I messed up and confused you. I see no problem with calling it dozenal either.

ChristophBerger:

Just for the fun of it, how about adding "colloquial" output? Like 1, 2, 3, 4, 5, half a dozen, 7, 8, 9, 10, 11, a dozen, a baker's dozen, a dozen and two,..., 17, one and a half dozen, 19,..., 23, two dozen, 25,..., 119, a great hundred/a small gross, 121,..., 143, a gross/a square dozen, 145,..., 1727, a large gross/a cubic dozen, 1729,... 

CountyMcCounterson:

If we are replacing our number system with something worse why not have values for every letter of the alphabet as well as the numbers just to complicate it even more?