<div dir="ltr"><div>Sasha,</div><div><br></div><div>> Wait.. what?</div><div>></div><div>> Am I really reading an email signed by two people?</div><div><br></div><div>Yes; its a common format in professional writing. Not so common</div><div>is the strong sarcasm and derision that you display in yours.</div><div><br></div><div>> First off, you used subtractive chunking for division. Calling this a</div><div>> naive algorithm is giving it more credit than it is worth. The only</div><div>> time subtractive chunking is used is by school children.</div><div><br></div><div>Our previous email explained that the motivating factor was code</div><div>size. We are free to write faster implementations.</div><div><br></div><div>> I cloned your repository (van Rijn and Howard?)</div><div>></div><div>> <a href="https://github.com/gavinhoward/bc/">https://github.com/gavinhoward/bc/</a></div><div>></div><div>> You (both?) seem to have no idea how to force errors out of a badly</div><div>> scaled irrational function so I supplied an example (though judging</div><div>> from the first example I gave, you (both?) will just lie/boast and say</div><div>> this one works on your system too!):</div><div>></div><div>> echo "sqrt(.0000000000000000000000000000123)" | ./bc -l</div><div>> .0000000000000035071539807692832</div><div>> echo "sqrt(.0000000000000000000000000000123)" | bc -l</div><div>> .0000000000000035071355833500363</div><div>></div><div>> As you can see, the "solution" is not even close.</div><div><br></div><div>This example is appreciated. I cannot, however, find your first</div><div>example where an irrational function produces incorrect results.</div><div><br></div><div>Did you mistakenly send it to the group of "mathematicians and</div><div>systems programmers" who were working also on another `bc' ? [1]</div><div><br></div><div>> It is very hard to produce test results from such a badly made</div><div>> library, as it has actually taken my computer offline twice now (by</div><div>> overusing memory and other strange bugs), but I will give it another</div><div>> go:</div><div>></div><div>> This command takes 25 seconds using your math (if you want to call it</div><div>> that), but only .01 seconds using a correct implementation:</div><div>></div><div>> echo "sqrt(123123^123)" | time ./bc -l</div><div>> 11372609275300462201446509717277573045371910522125088219567947999131\</div><div>> 66658519961107066259363279984633201203915727943358917486581704249214\</div><div>> 07062970046980106751948432347504473036486754487763304174402241913448\</div><div>> 76069500421950114801423888362557755902898498344596580006258740796194\</div><div>> 555554490321132814795761735241438589907716.72501611371543803908</div><div>> 25.30user</div><div>></div><div>> echo "sqrt(123123^123)" | time bc -l</div><div>> 11372609275300462201446509717277573045371910522125088219567947999131\</div><div>> 66658519961107066259363279984633201203915727943358917486581704249214\</div><div>> 07062970046980106751948432347504473036486754487763304174402241913448\</div><div>> 76069500421950114801423888362557755902898498344596580006258740796194\</div><div>> 555554490321132814795761735241438589907716.72501611371543803908</div><div>> 0.01user</div><div>></div><div>> It is easy to scale this to take more time than the lifetime of the</div><div>> universe while other implementations are still instantaneous.</div><div><br></div><div>We are looking into this.</div><div><br></div><div>> I revved your repository back using git checkout and discovered a</div><div>> sordid history. Including an entire fast arbitrary precision</div><div>> implementation written by other authors (appears to be CM Graff and</div><div>> Bao Hexing) which was stripped, renamed and then badly reimplemented.</div><div>></div><div>> Please just fix your fix your "implementation" (if one can really call</div><div>> it that) and stop wasting everyone's time.</div><div><br></div><div>Now, this is enough. As far as commits go, I (Gavin D. Howard)</div><div>and one other person ("rofl0r") are the only two authors:</div><div><br></div><div> $ git log --all --format='%aN <%cE>' | sort -u</div><div> Gavin Howard <<a href="mailto:yzena.tech@gmail.com">yzena.tech@gmail.com</a>></div><div> rofl0r <<a href="mailto:yzena.tech@gmail.com">yzena.tech@gmail.com</a>></div><div><br></div><div>Background for anyone unfamiliar: as I cited [2] in my previous</div><div>email, this `bc' was developed at the same time as this CM Graff</div><div>was working on a separate bignum library. The plan was to use</div><div>that library behind the `bc' language which I was implementing.</div><div><br></div><div>The code you mention, by authors "CM Graff" and "Bao Hexing" was</div><div>not in a shape to be integrated with my `bc' at the time that I</div><div>had finished my own implementation. This is explained on-list.</div><div><br></div><div>You, "Sasha", must have been poring _extremely_ carefully over</div><div>each commit (or have advance knowledge of this) to be able to</div><div>find "an entire fast arbitrary precision implementation" lying</div><div>around, which _only_ existed between Jan. 03 and Jan. 24, 2018,</div><div>and of which was not touched or used in any way except residing</div><div>in the project directory adjacent to my code for a few weeks.</div><div><br></div><div>On January 15, 2018, CM Graff added my name (Gavin D. Howard) to</div><div>the LICENSE file for the mathematics library in question. I am</div><div>an author. Bao Hexing was added on January 16, 2018.</div><div><br></div><div>To accuse me of "stripping", "renaming", and/or "reimplementing"</div><div>that code is simply not true. Those claims are not supported by</div><div>the commit histories of either project.</div><div><br></div><div>One more thing...</div><div><br></div><div>I could not find any mention of you or your "consulting company"</div><div>online (including reviews or even a business registration in any</div><div>of the 50 states in a relevant industry). So if you're charging</div><div>money for your services you may wish to resolve that.</div><div><br></div><div>For such small developer communities, highly-specific projects,</div><div>mention of "mathematicians and systems programmers", `hebimath',</div><div>and the two other individuals, it seems -- suspicious -- that</div><div>you, "Sasha Toltec" (of whom nobody has heard), suddenly come</div><div>into the picture, seemingly so eager to revile the efforts of a</div><div>single, strong first implementation for Toybox?</div><div><br></div><div>What more is there to say?</div><div><br></div><div>Oh yeah: hi, Graff.</div><div><br></div><div>Gavin D. Howard</div><div><br></div><div>[1]: <a href="http://lists.landley.net/pipermail/toybox-landley.net">http://lists.landley.net/pipermail/toybox-landley.net</a></div><div>/2018-August/009628.html</div><div><br></div><div>[2]: <a href="http://lists.landley.net/pipermail/toybox-landley.net">http://lists.landley.net/pipermail/toybox-landley.net</a></div><div>/2018-March/009403.html</div></div><br><div class="gmail_quote"><div dir="ltr">On Tue, Aug 28, 2018 at 11:51 AM Rob Landley <<a href="mailto:rob@landley.net">rob@landley.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 08/28/2018 12:35 AM, Sasha Toltec wrote:<br>
> Wait.. what?<br>
<br>
Commands in pending/ default to "n" in defconfig. Some of them are nearly<br>
finished and just need more review, some are stubs that don't do anything<br>
useful, and some need complete rewrites.<br>
<br>
This is normal for toybox.<br>
<br>
> Am I really reading an email signed by two people?<br>
<br>
People keep emailing me about drama behind the scenes in this command's<br>
development, interchanging handles and names of people I barely know and can't<br>
really track. I'm trying to stay out of it, but don't personally have the domain<br>
expertise to write this command myself, nor the 3-ish months to come up to speed<br>
in this area enough to use existing algorithms explained on wikipedia and similar.<br>
<br>
I'm told the main source of drama is somebody named "Graff" who got banned from<br>
#musl, and Rich is _way_ better at dealing with people than I am. I've been<br>
tempted to reject the bc implementation just because it's not worth the drama<br>
(and already deleted an earlier version from pending rather than wait for an<br>
update as I usually do) but if it's just one troll sock puppeting that's nobody<br>
else's fault.<br>
<br>
> First off, you used subtractive chunking for division. Calling this a<br>
> naive algorithm is giving it more credit than it is worth. The only<br>
> time subtractive chunking is used is by school children.<br>
<br>
And drama. How nice.<br>
<br>
Have you seen my factor implementation? It's naive. The largest 64 bit prime<br>
number is 2^64-59, and ubuntu's factor returns that it's prime basically<br>
instantly (even on my tiny little 5 year old $200-when-it-was-new netbook), but<br>
my version:<br>
<br>
$ time ./factor 18446744073709551557<br>
^C<br>
<br>
I got tired of waiting after about 3 minutes.<br>
<br>
My code, which I authored, sucks. I knew that when I checked it in. Patches<br>
welcome. (That said, the 80/20 rule applies: small and simple and works for the<br>
common case, then wait for people to show up with personal use cases in the<br>
remaining 20%...)<br>
<br>
> I cloned your repository (van Rijn and Howard?)<br>
<br>
van Rijn is the guy who hosts the musl-cross-make toolchain binaries at<br>
<a href="http://b.zv.io/mcm/bin/" rel="noreferrer" target="_blank">http://b.zv.io/mcm/bin/</a> and he's Thalheim on the IRC channel. He's always been<br>
polite and has a history of helping out. I trust his judgement.<br>
<br>
(According to Girl Genius he created the nine muses, but his other projects are<br>
his business.)<br>
<br>
> <a href="https://github.com/gavinhoward/bc/" rel="noreferrer" target="_blank">https://github.com/gavinhoward/bc/</a><br>
> <br>
> You (both?) seem to have no idea how to force errors out of a badly<br>
> scaled irrational function<br>
<br>
I don't either, for the record.<br>
<br>
> so I supplied an example (though judging<br>
> from the first example I gave, you (both?) will just lie/boast and say<br>
> this one works on your system too!):<br>
> <br>
> echo "sqrt(.0000000000000000000000000000123)" | ./bc -l<br>
> .0000000000000035071539807692832<br>
> echo "sqrt(.0000000000000000000000000000123)" | bc -l<br>
> .0000000000000035071355833500363<br>
> <br>
> As you can see, the "solution" is not even close.<br>
<br>
Nineteen digits of precision is not even close?<br>
<br>
What I usually do is add failing test suite entries to remind me of issues I<br>
need to fix. Happy to merge patches against tests/bc.test. Let's see... Huh.<br>
<br>
landley@driftwood:~/toybox/toy3$ TEST_HOST=1 time make test_bc<br>
...<br>
598.95vuser 257.87vsystem 14:14.24velapsed<br>
<br>
The _host_ version takes almost 12 minutes to run this test. Most of which is<br>
spent in "generating", and spits out a couple "(standard_in) 1: syntax error"<br>
lines. That should probably be fixed somehow (running "make tests" to test<br>
_everything_ should be a feasible thing to do on a regularish basis, this one<br>
test can't take this long, maybe it should have a "short" version or<br>
something... Another item for the todo heap.)<br>
<br>
Anyway, adding _this_ test looks like... commit e579e69656b3<br>
<br>
> It is very hard to produce test results from such a badly made<br>
> library, as it has actually taken my computer offline twice now (by<br>
> overusing memory and other strange bugs), but I will give it another<br>
> go:<br>
<br>
Historically, this bc implementation has had one troll, who sock puppets.<br>
<br>
> This command takes 25 seconds using your math (if you want to call it<br>
> that), but only .01 seconds using a correct implementation:<br>
<br>
I'm ok with that. Patches welcome, but that's not a blocker for me.<br>
<br>
> It is easy to scale this to take more time than the lifetime of the<br>
> universe while other implementations are still instantaneous.<br>
<br>
See "factor", above. Which I wrote on a long bus ride while reading<br>
<a href="https://www.muppetlabs.com/~breadbox/txt/rsa.html" rel="noreferrer" target="_blank">https://www.muppetlabs.com/~breadbox/txt/rsa.html</a> which used "factor", and I<br>
went "that looks easy enough"...<br>
<br>
> I revved your repository back using git checkout and discovered a<br>
> sordid history.<br>
<br>
A) One troll, with a history of sock puppetry.<br>
<br>
B) Toybox just checked the results into pending. If toybox's maintainer doesn't<br>
care about the history before that (other than confirming it's under the right<br>
license, and the fun bonus that people who know about it are hanging around to<br>
do more work on it as necessary), why would you?<br>
<br>
> Including an entire fast arbitrary precision<br>
> implementation written by other authors (appears to be CM Graff and<br>
> Bao Hexing) which was stripped, renamed and then badly reimplemented.<br>
<br>
Hello Graff. You can stop now, you've been made.<br>
<br>
> Please just fix your fix your "implementation" (if one can really call<br>
> it that) and stop wasting everyone's time.<br>
><br>
> Sasha Toltec<br>
> Toltec Enterprises<br>
> <a href="mailto:sashatoltec1@gmail.com" target="_blank">sashatoltec1@gmail.com</a><br>
<br>
Who does not exist according to Google.<br>
<br>
Do I need to switch on list moderation for new subscribers?<br>
<br>
Rob<br>
</blockquote></div>