LibBF – a small library to handle arbitrary precision floating point numbers
1–10 of 63 posts
Re: LibBF – a small library to handle arbitrary precision floating point numbers
#2[deleted]
Re: LibBF – a small library to handle arbitrary precision floating point numbers
#3I don't see any changelog, does anyone know what's new since the last release?
Re: LibBF – a small library to handle arbitrary precision floating point numbers
#4MIT license makes this great for WebAssembly!
Looking forward to benchmarking this in a wasm context.
Re: LibBF – a small library to handle arbitrary precision floating point numbers
#5I don't see any changelog, does anyone know what's new since the last release?
According to the copyright notice, development started in 2017, so it is possibly the first release.
Re: LibBF – a small library to handle arbitrary precision floating point numbers
#6Mostly 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 least provides reasonably tight bounds on them?
I did quite a bit of research at the time but only with limited success. I am reasonably sure that finding the exact lengths is comparable in hardness to factoring p and q in some cases and possibly harder in the general case. But I did not come across much with regard to bounds on the lengths.
Maybe there was somewhere an implicit answer to my question which I did not recognize or fully appreciate due to my limited knowledge of number theory but I never came across an explicit statement that said that printing the decimal representation of a rational number or estimating its length is a hard or unsolved problem.
I ended up just performing the expansion digit by digit until I detected a cycle or reached a specified maximum length, but it would by nice to know in advance how long it will be or at least to learn that this is actually an hard or unsolved problem.
Re: LibBF – a small library to handle arbitrary precision floating point numbers
#7MIT license makes this great for WebAssembly! Looking forward to benchmarking this in a wasm context.
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).
Re: LibBF – a small library to handle arbitrary precision floating point numbers
#8For Mac users trying this at home, I made the following changes to build and run the tinypi tests on Sierra:
1. Comment out the malloc.h include in tinypi.c.
2. Add -Wno-unused-function to CFLAGS.
3. Use shasum, rather than sha1sum, in the test target.
Re: LibBF – a small library to handle arbitrary precision floating point numbers
#9Mostly 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…
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.
Re: LibBF – a small library to handle arbitrary precision floating point numbers
#10MIT license makes this great for WebAssembly! Looking forward to benchmarking this in a wasm context.
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.