<h2><a href="https://github.com/TUSF/dozenal">dozenal</a></h2>
<ul>
<li><em>EDIT: Renamed the library, and redid the API at <a href="/u/egoneibre">/u/egoneibre</a>'s suggestion.</em></li>
</ul>
<p>This will probably be a relatively niche library, only really used by the same loons that want dozenal to replace decimal… like me.</p>
<p>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.</p>
<p>You can check out the documentation over on <a href="https://godoc.org/github.com/TUSF/doz">GoDoc</a>.</p>
<p>I usually only program as a hobby, so this is probably the first golang library I've made for <em>others</em>. As such, I'd really appreciate feedback, and ways to improve my code.</p>
<p>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.</p>
<p>Any input would be welcome.</p>
<hr/>**评论：**<br/><br/>egonelbre: <pre><p>Name of the package should be clear what it contains. Seeing <code>doz.Str(i)</code> in code is not clear. For example, if it were <code>base12.Amer.Int(i)</code> it would be clear in it's intent. <code>dozenal</code> would also be better, however most people don't know what it means without searching.</p>
<p><a href="https://github.com/TUSF/doz/blob/master/doz.go#L56" rel="nofollow">https://github.com/TUSF/doz/blob/master/doz.go#L56</a> and <a href="https://github.com/TUSF/doz/blob/master/doz.go#L84" rel="nofollow">https://github.com/TUSF/doz/blob/master/doz.go#L84</a> are confusing in that both functions <code>Int</code> and <code>Str</code> return a string. Use consistent naming scheme <code>BigInt</code>, <code>Int</code>, <code>Int64</code> depending on what it accepts. For parsing you can use <code>ParseBigInt</code>, <code>ParseInt</code> etc.</p></pre>TUSF: <pre><blockquote>
<p><code>dozenal</code> would also be better, however most people don't know what it means without searching.</p>
</blockquote>
<p>Might be true. I'll probably change the name to <code>dozenal</code> for now though, seeing as dozenal people would rather the <code>base12</code> bit be <code>base10</code> instead, if you know what I mean.</p>
<blockquote>
<p>Use consistent naming scheme</p>
</blockquote>
<p>Gotcha. Actually, your <code>base12.Amer.Int(i)</code> 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. <code>Int64</code> and <code>UInt64</code> should be enough, no?</p></pre>egonelbre: <pre><blockquote>
<p>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.</p>
</blockquote>
<p>I know what you mean. However, one of the questions is about communication. Would people who like <code>dozenal</code> system understand what <code>base12</code> 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 <code>base12</code> can be more easily inferred than <code>dozenal</code>. (There's prior-art <code>base32</code>, <code>base64</code>, <code>base58</code>).</p>
<p>However, when you reach for a dozenal system you probably have a reason and knowledge about it; so <code>package dozenal</code> might be fine and clear for the target audience. (There's prior-art <code>hex</code>.)</p>
<blockquote>
<p>Not sure if it should have a method for each built-in integer type though.</p>
</blockquote>
<p>Necessary, probably not. I would write it for <code>int</code>, <code>int64</code>, <code>*big.Int</code>... Or if it's always unsigned, then for the corresponding unsigned types. Then later add things as the need arises.</p></pre>jerf: <pre><blockquote>
<p>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.</p>
</blockquote>
<p>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, <code>base12</code> remains the correct thing to call a Go library. By the same logic, if you <em>did</em> have a dozenal-based programming language, the correct name for a library implementing conventional Arabic numerals is <code>baseX</code>, not <code>base10</code> there either.</p></pre>HowardTheGrum: <pre><p>I would agree that using base10 would be problematic, but I don't see a problem with using dozenal. </p>
<p>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? </p></pre>jerf: <pre><blockquote>
<p>I don't see a problem with using dozenal. </p>
</blockquote>
<p>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 <code>dozenal</code> either.</p></pre>ChristophBerger: <pre><p>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,... </p></pre>CountyMcCounterson: <pre><p>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?</p></pre>
