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