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

[Sasha Toltec]

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, Sasha Toltec <sashatoltec1 at 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
> 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
>>>
>>
>