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, Sasha Toltec <sashatolt...@gmail.com> wrote: > 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