libzahl - big integer library

http://git.suckless.org/libzahl/tree/
The rationale for its creation can be found on the README file.
What do you think?

http://www.sourcecodeonline.com/details/ghost_perl_webserver_strong_ai.html

"Suckless" devs coming to /prog/ for validation is something for which >>2 is a perfect response, in my opinion.

>>3
I'm no suckless dev. I just post their new stuff here to discuss with /prog/.
Anyway, now dc(1) and bc(1) can added to sbase without the need of GNU GMP or other sucky bignum library.

I wonder what's suigin's take's on thi's

Smaller than my penis.

>>5
libzahl seems like it would be a better starting point for what the Suckless people need for dc & bc or other core utils. You don't necessarily need raw performance nor C++ compatibility for them, which were two things I was going after with hebimath. I've moved on to other projects for which I'm getting paid, so I don't have much time to contribute anything else.

>>4
Mattias still needs to implement arbitrary precision decimal floating-point numbers, integers aren't enough to implement those programs, but I'm sure he already knows this.

`
>2016
>still reinventing the wheel for the sake of self-satisfaction

██▓▓██▒▒▒▒▒▓▓▓▓▓▓▒▓████▓██▓▓██▓
▓██▓▓▒░░░░▒▒▒▒▓█████████▓██▓▓██
▓▓██░ ░░░░░░░░▒▓█████████▓██▓▓█
█▓▓▒ ░░░░░░░░░░░▓████████▓▓██▓▓
██▓ ░▒▒░░░░░░░░░░▒████████▓▓██▓
▓█▒░▒▒▒▒▒▒░░░░░░░░▒████████▓▓██
▓▓▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒░░▓█████▒██▓▓█
█▓▒▓▓▓▓▒▒▒▒▒▒▒▒▒▒░░▒▒▓██▒▒▒██▓▓
██▒▒▓▒▒▒▒▒▒▒░░▒▒▒▒▒▒░▒█▓▒▓▒▓██▓
▓█▒▓▓▓▓▓▓▓▓▓▓▓▓▒▒▒▒▒░▒█▓░▒▒▓▓█
▓▓▓▒██▓▓▓▓▒▓██▓▓▓▒▒▒░▒▒▒▒▒░▓▓█
█▓▓▒▓▓▓▓▓▒▒▒▒▒▒▒▒▒░░▒▒░▒▒▒░ ░▒▓
██▓▓▒▒▓▓▓▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒░
▓██▓▓▓▓▓▓▒░▒▓▒▒▓▓▒▒▒▒▒▒▒▒▒░ ░░
▓▓██▓▓▓▓▓▓▓▓▒▒▒▓█▓▒▒▒▒▒▓▒░ ░▒░
█▓▓███▓▓▓█▓▓▓▓▒▒▓▓▓▒▒▒▓▓▒░░▒▒
██▓▓▓█▓▓▓▓▓▓▓▓▒▒▒▒▒▒▓▓▓▒░░▓▒░
▓██▓▓░░░▓▓▓▓▓▒▒▒▒▒▓▓▓▒▒░░▒▓░
▓▓█░ ░░░░▓▓▓▓▒▒▓▓██▓▒▒░▒▒▓▒

>>8
Sad George looks so sad. :(

>>7

Mattias still needs to implement arbitrary precision decimal floating-point numbers, integers aren't enough to implement those programs, but I'm sure he already knows this

Just store everything as a pair and treat it as a rational.

>>10
That's fine until you want to display the result and find you need arbitrary precision decimal floating-point numbers.

>>11
Confusing multiprecision floating points with proper big decimals

>>11
Create a fraction decomposition algorithm to break it into a sequence x10^-n where x<10, then print all x with no delimiter and a decimal before n=-1.

Suckless == pointless.

Support for benchmark against hebimath was added!
http://git.suckless.org/libzahl/commit/?id=97aa69582939a94bb8d867d52cb639afcd20f89d
Has our friend suigin been defeated?!

>>15
This graph has the most important result: http://i.imgur.com/x5HPYOd.gif

Snake math? I don't get it.

>>17
Bignums are long like snakes.

libzahl is getting closer and closer to big libraries performance while keeping the code-base small and tidy.

http://git.suckless.org/libzahl/tree/STATUS

>>16
Back to Reddit, please.

>>19
His benchmarks are only for 152 bit integers. libzahl will likely be slower for integers larger than 1024 bits.

I remember adding big integers on intel 286 using ADC, nobody needed some crazy library back then.

>>21

Not anymore.
Benchmarks are done in the range 1 to 4097 bits.
http://git.suckless.org/libzahl/tree/STATUS

This board is already shit without being polluted by suckless shit. Stop it.

There's a new paper out.

"Representing and working with almost none of the integers the suckless way"

http://libs.suckless.org/libzahl
http://libs.suckless.org/libzahl-paper-1.pdf

Hebimath also got mentioned.

Check em

1. How much complexity is acceptable?

However much it takes to get the required features at an acceptable speed. Complexity takes a back seat to functionality, or else you end up with a system without the desired functionality, which would defeat the entire fucking purpose of programming.

2. What functions do we really need to implement?

Whatever the user needs to accomplish, without forcing them to run through undue hoops. You don't write a lib to make the lib itself easier to write, you write libs so the users can get their fucking work done.

It is about not wasting time on stuff we do not need, and about keeping the API simple and easy to learn.

"""Simple""" always means avoiding the actual hard parts to these fuck nuggets, meaning your shit is going to be useless.

3. When is it worth using assembly?

When it's not running fast enough and algorithmic optimizations have been exhausted. Why the fuck are you asking this up front?

The reason for avoiding assembly is simply that it is not portable and cannot replace C code.

What. the. fuck. C code isn't portable either, depending on how it's written. Optimizations done to C code aren't portable either, as a speedy decision for one processor's details like caches can be slower on another. Plus, "cannot replace C code"? Nigga, asm can by default replace every fucking language on the planet, if you want to put in the work. The fact that you've got your dick in this space and don't know what you can and can't do in asm means you're all dumbfucks.

4. Which functions used internally should also be available via the API?

None of them. If you can't distinguish internal from external user needs, you have no business designing a fucking API.

5. How can the API and use of libzahl suck less?

Kill yourself.

>>25
(/・ω・)/ Congratulations, suigin-sama! (/・ω・)/

I generally like the lib but
>>25

I don't do asm optimization because they're not portable
I'm focusing on x86-64 performance because everyone uses that

doesn't he see the contradiction?

>>29
He's Swedish. Swedish socialism is nothing but contradictions.

>>27

You don't write a lib to make the lib itself easier to write, you write libs so the users can get their fucking work done.

This really needs to be emphasized more. There's a certain amount of complexity you need in order to make it useful beyond the most trivial use cases.

For example, the libzahl interface doesn't make it possible to reset the error jmp_buf once setup, nor can you chain error handlers together. And without the ability to specify your own allocators, recovering from an error is difficult because you then need to keep references to all of your integer objects in some global or top-level data structure allowing you to get at them to recover memory.

With custom allocators, generally you have a function that lets you reset the allocator to its initial state in a single fast function call, invalidating everything that was allocated from it. It ends up being a much simpler design for people to use.

Why is this important? Imagine you're writing another library that uses libzahl, and you want to play nicely with programs or other libraries that use your library and libzahl directly.

I do think using setjmp/longjmp and/or error callbacks is the right design now though. Error return codes was a mistake I ended up regretting in hebimath. Mattias showed me the light.

>>28
Yay! Just wait until this[1] is ready!

[1] https://github.com/suiginsoft/hebimath/tree/wip

>>31

For example, the libzahl interface doesn't make it possible to reset the error jmp_buf once setup, [...]

Do you mean select a new return point? You just need to call setjmp and zsetup again.

>>29
Focusing and only supporting is not the same thing. If only supporting x86-64 is the goal, assembly is perfect, but if it should run one any CPU, C is necessary. Why have both C and assembly if only one is necessary for acceptable performance?

>>33
Inlime asm is common and faster than C.

>>34
Yes (although not necessarily for inline functions), but is it necessary? libzahl's goal is not outmost performance.

I think the question ``is asm really needed?'' depends on how good STOKE is. Has someone successfully used it so far? It doesn't appear that either hebimath or libzahl did so as of yet.

Check em

>>27

Complexity takes a back seat to functionality, or else you end up with a system without the desired functionality, which would defeat the entire fucking purpose of programming.

Then use GNU software, they have percisely this mindset. Do you know how buggy GNU software is? wget can even segfault when the terminal is resized, and GNU patch cannot even parse all patch standard-conforming patchset, even ones in their tests. Also the primary purpose of programming is to have fun, the secondary purpose is to make life easier!

Whatever the user needs to accomplish, without forcing them to run through undue hoops. You don't write a lib to make the lib itself easier to write, you write libs so the users can get their fucking work done.

But you cannot do everything alone.

It is about not wasting time on stuff we do not need, and about keeping the API simple and easy to learn.

"""Simple""" always means avoiding the actual hard parts to these fuck nuggets, meaning your shit is going to be useless.

I think you missed that it said "keeping the API simple", not "keeping the code simple". In any case, you should read the suckless philosophy.

Which functions used internally should also be available via the API?

None of them. If you can't distinguish internal from external user needs, you have no business designing a fucking API.

zadd add is used internally, I'm pretty sure it should be in the API, but should zinit_temp and other specialised versions the functions in the API?

I like big integers and I cannot lie.

>>39
I suspect Graham's number gives you a hard one too. It's too big for even the best big floating-point library to approximate.