Live data from Hacker News

LibBF – a small library to handle arbitrary precision floating point numbers

bellard.org

41–50 of 63 posts

Re: LibBF – a small library to handle arbitrary precision floating point numbers

#41
post #6

Mostly off topic but maybe this post attracts people who know the answer to a question that I ran into when I implemented a big integer based rational number library some time ago. The decimal representation of a rational number p / q has the general form ± . ( ), for example 41,111,111 / 333,000 equals 123.456(789). Is there an efficient algorithm to determine the lengths of the fractional parts or one that does at…

As you said, this is equivalent to factorisation in terms of complexity. The Wikipedia article[0] on the subject does a good job of summarising the details of this in the section "Other properties of repeatend lengths". For a simple answer, the lengths are bounded above by Euler's totient function [1] (the sum of factors) of the denominator. Any tighter bounds depend on the specific primes in the factorisation. Note…

> As you said, this is equivalent to factorisation in terms of complexity.

This can't be right. Factorisation is, legendarily, a hard problem, unsolved (in realistic time frames) for large input. But more than that, it's harder than division is.

Finding the length of the nonrepeating and repeating parts of a rational number's decimal expansion can be done just by doing the division. That would appear to be evidence that it is not harder than division?

Edit: from the wikipedia section you link:

> If k = 2^a·5^b·n where n > 1 and n is not divisible by 2 or 5, then the length of the transient of 1/k is max(a,b) and the period [of the repetend, presumably] is r, where r is the smallest integer such that 10^r ≡ 1 (mod n)

All integers (except those whose only prime factors are 2 and 5) satisfy this condition, so this would appear to be exactly the method desired? Repeatedly dividing by 5 is much, much easier than factoring is. Taking the discrete log of 1... could be equivalent to factoring.

Re: LibBF – a small library to handle arbitrary precision floating point numbers

#42
post #39
post #27

Earlier quoted context omitted.

God damn, as if the others were not enough... Can someone confirm that this dude is a human?

He also built a home brew 3G and then LTE base station, iirc.

Yes, his company Amarisoft sells a SDR LTE based station with EPC (the core network part) support too: https://www.amarisoft.com/

Re: LibBF – a small library to handle arbitrary precision floating point numbers

#43
post #7

Earlier quoted context omitted.

Looking at the code this should be quite simple since libc is the only dep. You can Emscripten at first to be easy, but to wrap it up as a JS lib, you can probably implement the libc calls yourself easily and remove the Emscripten dep. The author even broke off bf_realloc to put your own alloc impl (which can be written in WASM, but I suggest writing it in C before the compilation).

cheers, sadly I won't be exploring JS lib wrapper approach. we're already deep down the EMSCRIPTEN_BINDINGS() rabbit-hole :) originally, the fixed size heap (/w optimisations) meant unbound use from a JS lib was too hard to reason about; hence avoided entirely in favour of a emscripten blackbox.

Do you have a link for this ?

Re: LibBF – a small library to handle arbitrary precision floating point numbers

#44
post #17
post #9

Earlier quoted context omitted.

While I’m sure you know this, when computing the fractional part you will have at most q-1 digits in your repeating cycle. When you divide by q, you have at most q unique remainders (0 to q-1). Also when computing the fractional part, if you end up with the same remainder as you’ve previously seen then you’ve hit the cycle.

That is exactly what I did, I implemented some cycle finding algorithm, a tortoise and hare variant maybe but I can not tell from the top of my head, on the reminder sequence giving up after a user-specified number of steps. But it irks me that this may abort just a hand full of steps before finally finding the cycle. And unfortunately q is just way to loose as a bound if it even deserves the name bound in this case.…

> I implemented some cycle finding algorithm, a tortoise and hare variant maybe but I can not tell from the top of my head, on the reminder sequence giving up after a user-specified number of steps.

What's the cycle finding for? Isn't it enough to record the remainder sequence with indices? As soon as any remainder reoccurs, that's the cycle.

Re: LibBF – a small library to handle arbitrary precision floating point numbers

#45
post #42
post #39

Earlier quoted context omitted.

He also built a home brew 3G and then LTE base station, iirc.

Yes, his company Amarisoft sells a SDR LTE based station with EPC (the core network part) support too: https://www.amarisoft.com/

And he generated MPEG2 DVB streams (actual RF signal) from clever GPU coding.

Re: LibBF – a small library to handle arbitrary precision floating point numbers

#46
This needs some major work to be packagable into a library, esp. for non amd64 hosts. There's also no src repo, as with all his previous hacks.

Who will do the autotooling and repo hosting? I've added some sugar in my fork on github https://github.com/rurban/libbf/tree/my but I'm not sure yet if I will use it.

But the low constant overhead for small numbers, the small size, no assembler tricks and the MIT license makes it very attractive.

Re: LibBF – a small library to handle arbitrary precision floating point numbers

#48
post #21

For those that don't know, Fabrice Bellard is the author of ffmpeg [1], the tiny c compiler (tcc) [2], linux in the browser [3] among many others [4]. Does anyone know how LibBF stacks up against GMP? [5] [1] http://ffmpeg.org/ [2] https://bellard.org/tcc/ [3] https://bellard.org/jslinux/ [4] https://bellard.org/ [5] https://en.wikipedia.org/wiki/GNU_Multiple_Precision_Arithme...

I've just noticed that one of the jslinux configurations now boots to X Windows(!) for either RISC-V(!) 32 or 64 bit.

GET OUT OF TOWN.

Re: LibBF – a small library to handle arbitrary precision floating point numbers

#49
Perhaps a side digression to this conversation, but... in spite of all the cool languages we talk about that have many on-paper advantages of either safety, convenience, or support of paradigms, is there really any option besides C for this kind of thing?

It still seems that, if you want to write Core Infrastructual Code that can be run anywhere, on anything, that links with any other software without any caveats, disclaimers, or compromise, C is still king.

Could this have practically been written in rust? haskell? ...and still have the same degree of embeddability and reach?

Re: LibBF – a small library to handle arbitrary precision floating point numbers

#50

Perhaps a side digression to this conversation, but... in spite of all the cool languages we talk about that have many on-paper advantages of either safety, convenience, or support of paradigms, is there really any option besides C for this kind of thing? It still seems that, if you want to write Core Infrastructual Code that can be run anywhere, on anything, that links with any other software without any caveats, di…

In my limited experience, no. All of the languages you mention put developer experience above portability, so usually require a basic runtime. C on the other hand is not interested in saving you from the machine, which allows for extremely minimal programs. Even C++ isn't great here compared to C. Then again, debugging segfaults isn't for everyone, so most are fine giving up C.
Post reply on HN