[Toybox] Toybox bc's transcendental and irrational functions produce incorrect results, memory leaks and exhibit brute force algorithmic complexity.

Tue Aug 28 12:28:12 PDT 2018

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
sahsatoltec1 at gmail.com

On 8/28/18, Gavin Howard <gavin.d.howard at 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.tech at gmail.com>
>     rofl0r <yzena.tech at 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 <rob at 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 at 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
>> > sashatoltec1 at gmail.com
>>
>> Who does not exist according to Google.
>>
>> Do I need to switch on list moderation for new subscribers?
>>
>> Rob
>>
>