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.

But you cannot do everything alone.

That's the major problem with suckless. Because your ideas are shit, nobody wants to work with you.

>>41
Two developers would probably be enough to implement everything for one architecture. Only exceptionally large projects need more than 2 active developers. However, it is best to focus on the core and only move on to the extra functionallity once the core has been done.

>>42
Spoken like a true dumbass who has no clue what he's doing.

>>42
Pair programming with Sanae!

Unit testing with Suigintou!

>>41,43
Why don't you point out precise things you find libzahl is doing wrong instead of posting vague garbage? We get it that you don't like suckless, but so what? Is that all you wanted to say?

>>32
Say you're writing a library for simulating the effects of nuclear winters, libshtf, and you want to use libzahl internally, but don't want to expose libzahl in libshtf's interface. You also can't make assumptions about what a consuming program, say a nuclear winter visualizer (visnuke) might do. visnuke might use libzahl itself, it might not. Who then is responsible for calling zsetup? What if libshtf needs to call zsetup internally so it can clean itself up properly during an unwind, overriding anything visnuke has done. In order to chain the calls, one would have to pass in the jmp_buf originally used with the call to zsetup to libshtf, but that unnecessarily complicates libshtf's interface.

>>36
I got it working on a Debian 8 machine at my job. Wouldn't build on Void and Gentoo systems at home. It performs well on small code-fragments, but longer ones require a lot more care to how you configure the search space, otherwise it will give up or not make much progress. I haven't been able to get it to reproduce or outperform my hand-tuned assembly kernels yet, but I admittedly haven't spent enough time at it.

>>46
I don't care about what libzahl is doing. I care about the bullshit philosophy and failed ideas that suckless is promoting as somehow "correct". It's as poison to programming as fucking Islam is to modern life.

>>48
So what's the alternative? Lisp? Lisp is also dead.

>>49
You fuckheads are so fucking ignorant you can't even put together a coherent post. Did I say anything about the language at all? No. Read >>48 again, you literal retard.

>>50
Lisp isn't just a language. It's also an idea, with a philosophy behind it. We're talking about alternative philosophies here, are we not?

Seriously, what are you doing with your programming? What direction are you heading in, or looking at.

I'm not criticizing you, I'm just lamenting over the state of our field. I agree, it's all shit, and people like us on the fringe are desperately trying to find something that will bring about a new renaissance, something that will light the way to a Golden Path.

>>48

fucking Islam is to modern life.

What's wrong with Islam?

>>51
The state of the field is shit because people keep stepping back and reinventing wheels, instead of solving new problems.

The state of the field is shit because people don't even recognize problems with the field, but muddle through all the shit required due to inertia. Like the fact that source code is still fucking text files, instead of having semantic editors, or the incompatible application boundaries when you want to process data using functionality found in multiple programs. (and serialization to arbitrary text and/or bytes in the Unix way is a bullshit red herring that makes more problems than it solves)

The state of our field is shit because people focus on bytes & cycles when it's completely unnecessary, or limiting problem scopes to make things less difficult, to stroke their own cock via "programming" instead of getting real work done.

The state of our field is shit because OSes are still fundamentally based on C APIs, meaning that taint of brittleness will always be there.

Everything suckless says, does & stands for is right in the middle of the shittiest shit in the field.

>>53

Like the fact that source code is still fucking text files

What's wrong with that? Most knowledge is codified as written text anyway. Go make a game in Unity or something.

I code in DNA, mofos!

>>54
Why the fuck can't I embed rich data right in a source code file? Real binary data, images in my comments, dataflow graphs that can be executed. No, everything has to be a serial chain of character bytes, locked in order, preventing any other representation.

>>56
It's technically possible, but nobody wants to develop compilers that work with that kind of data. You might want to look into using Lisp to write a domain specific language that's designed to compile that kind of data into a computer program.

>>56,57
Terry A Davis from TempleOS did that.
Not even kidding.
https://www.youtube.com/watch?v=PCfFF9Flhp4&t=52s

>>56
If you consider that UNIX processes are like objects, and UNIX is kind of like an ad hoc programming environment that acts on text messages and operates on the filesystem, isn't processing a bunch of data using command line tools and shell scripts as glue the same thing?

>>56
it's an idea that appeals to me but it has too many problems with it - and you'll notice them when you try working with actual visual and dataflow languages, whether it's something like labview or some custom bullshit designed for an obscure game engine (I did both).

basically, we have plenty of good, varied tools for working with pure text. dozens of text editors (inb4 vi vs emacs), multiple IDEs (general purpose or language-specific), regex (which I hate but it is useful) and - if you're using a decent OS - command-line tools ranging from simple grep to DSLs like awk or sed.

the bigger your project gets the more you start noticing the lack of such tools for visual programming and dataflows. usually, you're either stuck with an annoying proprietary IDE or have to manually alter the internal representation of dataflows or whatever other bullshit your software uses. if you're lucky, you end up basically reverting to normal programming but in an obscure language. if you're unlucky, everything is represented by XML or binary blobs (keep in mind binary blobs are superior to XML because reverse engineering is actually quite fun).

Suigin and Mattias.
You may find C-Reduce useful too, in the same sense as STOKE.
https://embed.cs.utah.edu/creduce/
Should help keeping the source code even smaller and compact - less chances of bugs.

>>60
In other words, inertia of shit means sticking to said shit. Fuck you.

Thinking further, C-Reduce won't help in any way. Disregard my stupidity.

>>62
Oh, let's see your compiler so that we can shit on it too.

>>64
The focus isn't on the compiler, dickhole. Standard semantics can be fed through any given compiler. And yes, I've written tons of compilers for domain-specific projects with the features I want, except having to read multiple files to amalgamate all the formats I need.

It's just that everybody thinks that what we have with shitty text files suffices, so nobody works on anything better in the programming community & industry at large. What we have is what we know, and don't rock the boat.

And fuck you for thinking your little mind can shit on my compilers. I am superior to you in every way.

_{(this space left intentionally blank)}

>>62,64
well yeah, if I want to program something I use programming languages that already exist instead of making a new language, new OS, new computer hardware, new processor architecture, new computer and an entire new universe. if you want to create a whole new paradigm in which you program with dataflows, sound, motion controls or /prog/ shitposting then feel free to do it but don't expect everyone to do the same when they just want to write a piece of software. you don't invent new ways of baking bread, slaughtering pigs, harvesting crops, manufacturing knives and preserving meat every single time you want to eat a sandwich.

suigin's wip is finished!
hebimath is looking good.
https://github.com/suiginsoft/hebimath

I notice that both hebimath and libzahl have bechmarks.
https://github.com/suiginsoft/hebimath/tree/master/bench
http://git.suckless.org/libzahl/tree/bench

Couldn't maandree and suigin work together to unify benchmarking?

maandree's benchmarking strategy can be found on the page 17 of his document "Representing and working with almost none of the integers the suckless way" [0]

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

>>68
My work isn't quite done, but it was time to replace the old master branch. Some things aren't working properly yet.

I've been modifying the hebimath test fixture that comes with libzahl for benchmarking, when the time is right, I'll submit a patch for libzahl.

I can't believe it!
suigin-sama used a bashism.
Oh no!
[[ ... ]] is not defined by POSIX.

He's also using echo "$var". No good.
Read the beginning of this document.
http://www.etalabs.net/sh_tricks.html

What's libzahl exactly?
I am planing to use hebimath for my scheme, I am glad that it has rational support.

>>70
bourne shell a shit

Nevermind, I saw the multiple headers that used the other libraries at http://git.suckless.org/libzahl/tree/bench and thought that it was like a wrapper for multiple other math libraries instead of part of the benchmarking.

>>70
I'll fix it, thanks! It's not merely a bashism, I've been using mksh.

Suigin, are you planing to make manpages for the library? Also, what do the z and p directories stand for?

>>75
I'll be adding manpages and more documentation, but that's probably a month off. The library isn't quite ready for use just yet. If I didn't have a day job, I'd have it done by now. Instead, I'm plugging along at a slow and steady guacman pace.

z: integer functions, the 'z' comes from the symbol ℤ (zahlen) used for the set of integers
p: low-level SIMD packet oriented functions that operate on natural numbers

B-b-but... in the meantime, if you have any criticisms or suggestions, please feel free to air them, so I can take them into consideration and fix any problems.

Do you intend to use STOKE in the same ways as maandree, that is to get rid of assembly, but keep reasonable efficiency?

>>76
You must convince your employers that they need a new bignum library.
Make a report filled with marketing terms to get their attention. Then you can be paid to work on hebimath.

Suigin, you should delete wip branch now that it's merged.
Any advancements with STOKE so you can get rid of asm?

Also, slcon videos are out and there's one from maandree discussing libzahl. Actually, there were many great presentations this year. Did you like one in particular?

>>80
Forgot to delete it.
STOKE will never defeat a hardened zen master.
I haven't watched the slcon videos, my apologies. Time is limited.

Broke my wrist 2 months ago, and had surgery, was out for a few weeks. It's still soar as fug. Carpal tunnel 4 lyfe.

Now I'm just used up junk.

>>81
You're not junk Suigin, we all love you! I hope you get to feeling better about yourself and your injuries heal :3.

I like the suigin and his software.
Get better soon.

STOKE will never defeat a hardened zen master.

Does this mean you will abandon it and keep asm in hebimath forever?
Is the speed gain from it really needed?

>>83
Thanks.

Not abandoned, I'm back to working on it. Why would I want to get rid of the assembly code? STOKE doesn't eliminate assembly source files, it just helps automate writing the assembly files.

C doesn't eliminate assembly files, it just helps automate writing the assembly files.

assembly doesn't eliminate electric signal, it just helps automate manipulating electric signal.

>>86
Circuits are physics, dolt.

☝ 👌

On runtests.sh you use backticks instead of cipher.
You should read this http://stackoverflow.com/a/33301370
In your case it shouldn't matter because it's so simple, but it's a good idea to always use ciphers instead for ``best practice''.

I also get errors from ar and ranlib when compiling.
``plugin needed to handle lto object''

I usually like Suckless stuff and a simple, easily auditable bigint library is sorely needed, but this is hardly an improvement over the current state. libzahl still allocates during operations, for which there is no reason — provide a thin wrapper API if you think providing memory manually is a concern. This is particularly crucial because as soon as you begin to allocate during operations, you must handle allocation failures everywhere: GNU MP does the utterly insane and calls abort while libzahl appears to use a globally saved longjmp instead, sacrificing thread-safety.

>>90

if you think providing memory manually is a concern inconvenient

Always double-check your posts after making quick changes in the middle, kids.

>>89
Thanks for trying it out.

I recall someone mentioning the perils of backticks on the suckless mailing list. They also mentioned a linting tool that checks shell scripts for compliance. Can't find the email now though.

As for the problem with LTO, in GCC 4.9 they introduced a new slim LTO format which broke backward compatibility with the traditional tool chain. I think Clang/LLVM 3.9 just added support for it as well. Anyway, new tool front-ends were introduced for working with slim LTO objects, gcc-ar, gcc-ranlib, gcc-nm which all call ar, ranlib, and nm with the addition LTO plugin arguments.

Fix it locally by modifying the AR and RANLIB variables to use gcc-ar and gcc-ranlib in config.mk or on the command line or remove -flto from the CFLAGS variable.

The reason I haven't changed this to be the default yet is that it breaks things on FreeBSD 10 and one of my other build machines running an old Ubuntu 14.10 LTS install. Not sure of the best way to go forward here. Multiple config.mk files? Dynamically detect if gcc-ar and gcc-ranlib are accessible form PATH in the Makefile using the shell assignment operator?

I don't care about POSIX compliance for the makefiles, just GNU make and bmake cross compatibility.

>>92
Found it. shellcheck.

Why doesn't C have built-in bignum support?

>>94
1.That would increase C size. C runs on everything from toasters to supercomputers.
2.It would mandate a rigid standard where arch/compiler optimization would be important.
3.It would have no benefit, since bignum libraries update faster and have the most features at best speed.

Check em

check em

tried running ``make bench'' on hebimath.

CC bench/bench.c
AR bench/libbench.a
CC bench/p/padd.c
CC bench/p/paddu.c
CC bench/p/pclz.c
CC bench/p/pctz.c
CC bench/p/pcmp.c
CC bench/p/pcopy.c
CC bench/p/pdivrem.c
/usr/lib/gcc/x86_64-alpine-linux-musl/6.3.0/../../../../x86_64-alpine-linux-musl/bin/ld: libhebimath.a(recipu2x1.o): relocation R_X86_64_32S against hidden symbol `hebi_recipu64_v0lut__' can not be used when making a shared object
/usr/lib/gcc/x86_64-alpine-linux-musl/6.3.0/../../../../x86_64-alpine-linux-musl/bin/ld: libhebimath.a(pmove.o): relocation R_X86_64_32S against `.rodata' can not be used when making a shared object; recompile with -fPIC
/usr/lib/gcc/x86_64-alpine-linux-musl/6.3.0/../../../../x86_64-alpine-linux-musl/bin/ld: final link failed: Nonrepresentable section on output
collect2: error: ld returned 1 exit status
make: *** [Makefile:354: bench/p/pdivrem] Error 1

>>98
Try harder.

>>99
it appears that the error is because my distro makes use of PIE (position-independent executable) by default.

>>100-99
nice dubs

>>100
Sorry, but PIE means Proto-Indo-European. Does your distro use Proto-Indo-European language by default?

>>98,100
Thanks for diagnosing the problem, you just need to add -fpic to your CFLAGS when building and linking against the static library.

Don't think I'll be changing the default config.mk though.

>>103
Adding -fpic didn't work, but -no-pie did. But I lose the benefits of PIE if I use that flag...
Also ran the tests. pdivrem and pshl gave ``Illegal instruction''.
Full report.

running bench tests
=============================================
bench/p/padd
1.11092342 seconds 2807320549 cycles
bench/p/paddu
0.61399935 seconds 1551585089 cycles
bench/p/pclz
0.38591482 seconds 975212322 cycles
bench/p/pctz
0.04113274 seconds 103942455 cycles
bench/p/pcmp
0.25936612 seconds 655420130 cycles
bench/p/pcopy
0.62378001 seconds 1576300554 cycles
bench/p/pdivrem
Illegal instruction
bench/p/pdivremu
4.67800991 seconds 11821408959 cycles
bench/p/pmove
0.82385516 seconds 2081893366 cycles
bench/p/pmul
11.81116410 seconds 29847010724 cycles
bench/p/pmul_karatsuba
4.05948106 seconds 10258375022 cycles
bench/p/pmulu
1.12860501 seconds 2852001229 cycles
bench/p/pnorm
0.27017547 seconds 682734816 cycles
bench/p/pshl
Illegal instruction
bench/p/pshr
0.91286878 seconds 2306832982 cycles
bench/p/psqr
12.04847466 seconds 30446699611 cycles
bench/p/psqr_karatsuba
3.78380911 seconds 9561747711 cycles
bench/p/psub
1.22896880 seconds 3105622042 cycles
bench/p/psubu
0.59403863 seconds 1501143056 cycles
bench/p/pzero
0.34930230 seconds 882689481 cycles
=============================================
all done

>>104
be careful when talking about 'benefits of PIE'. suckless guys are static linking zealots. it's one of the things they're wrong about - especially when they stop talking shit about ASLR - but you can't reason with them

Static linking considered harmful

>>104
Thanks. I must be incorrectly detecting support for something.

Mind running lscpu(1) (should be a part of the util-linux package) and giving me the output? Particularly interested in your CPUID flags.

suigin what do you think about the collapse of the suckless org?

>>107
np, glad to help.

Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 popcnt lahf_lm ida arat dtherm tpr_shadow vnmi flexpriority ept vpid

>>108
Collapse? I heard that Christoph Lohmann left for reasons unknown (or perhaps it's obvious, just look at what's happening to Germany right now). But other than that, I was not aware the community was in a state of collapse.

>>109
Thanks, I'll look into it when I wake up in a few hours, was my first day back to work after the break, need to crash.

☝　　　✌

>>108
suckless didn't collapse. 20h just left to bitreich, but apart from that I don't see much change. I'm still sad that Christoph left, his work was always great.

>>110
Too bad your vacations are already over. Good luck going back to your job. I hope it's not so dull. Have a nice night of sleep. Have a nice 2017.

>>109
Should be fixed in the following commit, let me know.

https://github.com/suiginsoft/hebimath/commit/667591f9716f316d2e7efa5f5dc212e05fe66123

>>112
Thanks, hope everyone has a good year as well.

>>113
It's fixed, good job.

suigin and maandree: why not work on unifying a benchmarking suite?
It could be an independent project that benchmarks hebimath against libzahl against gmp against libtommath.
In the end generates a nice graphic showing which one is better where (R? Gnuplot? Julia?).

gopher://bitreich.org

It's very cool that suigin is adapting hebimath for strict MISRA C and CERT C compliance.
More software should follow this.

suigin: you should look into automatic benchmark reports between commits ( for example https://github.com/JuliaCI/BaseBenchmarkReports/ ).
After every commit, it automatically runs benchmarks between before-commit and after-commit and upload a full report with possible regressions on speed.
For hebimath it'd be good addition, since it's numerical software.

>>116
So... suckless with GPL?
I don't get it.

https://github.com/suiginsoft/hebimath/commit/d1af70846f53d76876711000e24a509327316f1b

Is CERT/MISRA compliance worth losing other advantages?

https://github.com/suiginsoft/hebimath/blob/master/TODO
https://github.com/suiginsoft/hebimath/blob/master/config.mk

TODO says ``planned for version 0.6'' but config.mk says hebimath 0.6 has already been released.

.travis.yml and sonar-project.properties pollute the repo a little, shouldn't put them on .gitignore?

>>115
Maybe later, the benchmarks aren't a high priority, I've been doing manual performance regression testing periodically, I'm in a good state.

>>120
To a degree, yes, it's worth it in this case. That change does make things somewhat simpler from the library maintainer's standpoint, it removes the cognitive overhead of having to think about making sure I'm not fucking something up with the intptr_t -> int casting. Leaving it as is makes it easier for someone to pass in a malformed allocid, and complicates the error checking. As far as losing the type-checking for users, it's not that big of a deal, just use the typedef and you'll be okay.

>>122
Yes, they do, but they're needed for Travis CI (or pretty much any public continuous integration service). I could put them in a different branch, but then I'm not getting as continuous of integrations if I always have to merge from master into another branch or vice versa.

>>121
Version 0.6 only comes out once it's been tagged.

>>122,123
Actually, I can probably roll sonar-project.properties into the .travis.yml file, just pass those properties in as arguments to the sonar-scanner. I'll do that later, thanks for the critique.

I ran hebimath through PVS-Studio.

hebimath/check/p/pcmp.c 33 err V512 A call of the 'memset' function will lead to overflow of the buffer 'y'.
hebimath/check/p/pnorm.c 30 err V512 A call of the 'memset' function will lead to a buffer overflow.
hebimath/check/p/negnot.c 22 warn V756 The 'i' counter is not used inside a nested loop. Consider inspecting usage of 'n' counter.

I ran libzahl through PVS-Studio.

libzahl/src/zrand.c 195 err V654 The condition of loop is always false.
libzahl/src/zrand.c 206 err V654 The condition of loop is always false.
libzahl/src/zsub.c 105 warn V764 Possible incorrect order of arguments passed to 'libzahl_zsub_unsigned' function: 'c' and 'b'.
libzahl/src/allocator.c 24 warn V701 realloc() possible leak: when realloc() fails in allocating memory, original pointer 'a->chars' is lost. Consider assigning realloc() to a temporary pointer.

>>124
tag! you're it!

>>126
Pretty good when it's only my unit tests failing. I think they're false positives in my case.

>>103
It may actually be a bug on hebimath.
I found a similar issue on GHC and it seems to be a bug on GHC.
https://ghc.haskell.org/trac/ghc/ticket/9007

>>130
I'll try installing Alpine on a spare RPI and look into it more deeply over the next couple of days.

>>131
And I'll try Alpine x86-64 in a VM, as it may be specific to that hardware.

🇺🇸🇺🇸🇺🇸🇺🇸🇺🇸🇺🇸🇺🇸🇺🇸🇺🇸🇺🇸🇺🇸🇺🇸🇺🇸🇺🇸🇺🇸🇺🇸🇺🇸🇺🇸🇺🇸🇺🇸🇺🇸🇺🇸🇺🇸🇺🇸🇺🇸🇺🇸🇺🇸🇺🇸🇺🇸🇺🇸🇺🇸🇺🇸🇺🇸🇺🇸🇺🇸🇺🇸🇺🇸🇺🇸🇺🇸
I claim these dubz in the name of the United States of America
🇺🇸🇺🇸🇺🇸🇺🇸🇺🇸🇺🇸🇺🇸🇺🇸🇺🇸🇺🇸🇺🇸🇺🇸🇺🇸🇺🇸🇺🇸🇺🇸🇺🇸🇺🇸🇺🇸🇺🇸🇺🇸🇺🇸🇺🇸🇺🇸🇺🇸🇺🇸🇺🇸🇺🇸🇺🇸🇺🇸🇺🇸🇺🇸🇺🇸🇺🇸🇺🇸🇺🇸🇺🇸🇺🇸🇺🇸

>>131
I did some investigation for you.
If I comment this then it compiles fine.

================================================================================
check/p/pmove.c
hebi_pmove(y+GUARD, x+GUARD, k);
================================================================================
check/z/getset.c
assert(hebi_zgetstr(buf, sizeof(buf), a, 10) < sizeof(buf));
assert(hebi_zgetstr(buf, sizeof(buf), a, 10) < sizeof(buf));
assert(hebi_zgetstr(buf, sizeof(buf), a, 10) < sizeof(buf));
================================================================================
check/z/shift.c
zpermutation(check_iter, check_max_perm, 1, a);
hebi_zshl(r, a, b);
zcheckbc(r, "%Z*(2^%zu)", a, b);
hebi_zshl(q, q, b);
================================================================================
check/z/zcmp.c
bcwrite(cmp_script);
zcheckbinop(zcmp_wrapper, "cmp(%Z, %Z)", 0);
================================================================================
check/z/zcmpmag.c
bcwrite(cmpmag_script);
zcheckbinop(zcmpmag_wrapper, "cmpmag(%Z, %Z)", 0);
================================================================================
check/z/zcmpi.c
bcwrite(cmp_script);
zcheckbinopi64(zcmpi_wrapper, "cmp(%Z, %lld)", 0);
================================================================================
check/z/zcmpu.c
bcwrite(cmp_script);
zcheckbinopu64(zcmpu_wrapper, "cmp(%Z, %llu)", 0);
================================================================================
check/z/zabs.c
bcwrite(abs_script);
zcheckunaryop(hebi_zabs, "abs(%Z)", 0);
================================================================================
check/z/zneg.c
zcheckunaryop(hebi_zneg, "-(%Z)", 0);
================================================================================
check/z/zadd.c
zcheckbinop(hebi_zadd, "%Z + %Z", 0);
================================================================================
check/z/zaddmag.c
bcwrite(abs_script);
zcheckbinop(hebi_zaddmag, "abs(%Z) + abs(%Z)", 0);
================================================================================
check/z/zaddi.c
zcheckbinopi64(hebi_zaddi, "%Z + %lld", 0);
================================================================================
check/z/zaddu.c
zcheckbinopu64(hebi_zaddu, "%Z + %llu", 0);
================================================================================
check/z/zsub.c
zcheckbinop(hebi_zsub, "%Z - %Z", 0);
================================================================================
check/z/zsubmag.c
bcwrite(abs_script);
zcheckbinop(hebi_zsubmag, "abs(%Z) - abs(%Z)", 0);
================================================================================
check/z/zsubi.c
zcheckbinopi64(hebi_zsubi, "%Z - %lld", 0);
================================================================================
check/z/zsubu.c
zcheckbinopu64(hebi_zsubu, "%Z - %llu", 0);
================================================================================
check/z/zmul.c
zcheckbinop(hebi_zmul, "%Z * %Z", 0);
================================================================================
check/z/zmuli.c
zcheckbinopi64(hebi_zmuli, "%Z * %lld", 0);
================================================================================
check/z/zmulu.c
zcheckbinopu64(hebi_zmulu, "%Z * %llu", 0);
================================================================================
check/z/zdiv.c
zcheckbinop(hebi_zdiv, "%Z / %Z", RHS_NONZERO);
================================================================================
check/z/zdivi.c
hebi_zdivi(a, a, 0);
hebi_zdivi(a, a, 0);
zcheckbinopi64(hebi_zdivi, "%Z / %lld", RHS_NONZERO);
================================================================================
check/z/zdivu.c
hebi_zdivu(a, a, 0);
hebi_zdivu(a, a, 0);
zcheckbinopu64(hebi_zdivu, "%Z / %llu", RHS_NONZERO);
================================================================================
check/z/zdivrem.c
hebi_zdivrem(q, r, a, b);
hebi_zdivrem(q, r, a, b);
hebi_zdivrem(q, r, a, b);
zcheckbc(q, "%Z / %Z", a, b);
zcheckbc(r, "%Z %% %Z", a, b);
hebi_zdivrem(q, r, a, b);
zcheckbc(q, "%Z / %Z", a, b);
zcheckbc(r, "%Z %% %Z", a, b);
hebi_zdivrem(q, r, a, b);
zcheckbc(q, "%Z / %Z", a, b);
zcheckbc(r, "%Z %% %Z", a, b);
================================================================================
check/z/zrem.c
zcheckbinop(hebi_zrem, "%Z %% %Z", RHS_NONZERO);
================================================================================
check/z/zremi.c
(void)hebi_zremi(a, 0);
(void)hebi_zremi(a, 0);
zcheckbinopi64(zremi, "%Z %% %lld", RHS_NONZERO);
================================================================================
check/z/zremu.c
(void)hebi_zremu(a, 0);
(void)hebi_zremu(a, 0);
zcheckbinopu64(zremu, "%Z %% %llu", RHS_NONZERO);
================================================================================
check/z/zsqr.c
bcwrite(sqr_script);
zcheckunaryop(hebi_zsqr, "sqr(%Z)", 0);
================================================================================
check/z/znot.c
bcwrite(and_script);
zcheckunaryop(hebi_znot, "not(%Z)", 0);
================================================================================
check/z/zand.c
bcwrite(and_script);
zcheckbinop(hebi_zand, "and(%Z, %Z)", 0);
================================================================================
check/z/zor.c
bcwrite(or_script);
zcheckbinop(hebi_zor, "or(%Z, %Z)", 0);
================================================================================
check/z/zxor.c
bcwrite(xor_script);
zcheckbinop(hebi_zxor, "xor(%Z, %Z)", 0);
================================================================================

Solution.

http://nullprogram.com/blog/2016/10/27/
https://glandium.org/blog/?p=2361
http://infocenter.arm.com/help/topic/com.arm.doc.faqs/ka3554.html
http://www.cs.mcgill.ca/~cs573/fall2002/notes/lec273/lecture11/#115

🐍🐸🐍🐸🐍🐸🐍🐸🐍🐸🐍🐸🐍🐸🐍🐸
🐸🐍🐸🐍🐸🐍🐸🐍🐸🐍🐸🐍🐸🐍🐸🐍
🐍🐸🐍🐸🐍🐸🐍🐸🐍🐸🐍🐸🐍🐸🐍🐸
🐸🐍🐸🐍🐸🐍🐸🐍🐸🐍🐸🐍🐸🐍🐸🐍
🐍🐸🐍🐸🐍🐸🐍🐸🐍🐸🐍🐸🐍🐸🐍🐸
🐸🐍🐸🐍🐸🐍🐸🐍🐸🐍🐸🐍🐸🐍🐸🐍
🐍🐸🐍🐸🐍🐸🐍🐸🐍🐸🐍🐸🐍🐸🐍🐸
🐸🐍🐸🐍🐸🐍🐸🐍🐸🐍🐸🐍🐸🐍🐸🐍
🐍🐸🐍🐸🐍🐸🐍🐸🐍🐸🐍🐸🐍🐸🐍🐸
🐸🐍🐸🐍🐸🐍🐸🐍🐸🐍🐸🐍🐸🐍🐸🐍

arbitrariae preaecisione arithmeticae bybliotheca

I'm not sure that's valid Latin.
You should check it with a proficient speaker.
Revive /lang/, admin bastard!

suigin could be interested in this complex math Open Issue on musl.
http://wiki.musl-libc.org/wiki/Open_Issues#Complex_math

>>81

Broke my wrist 2 months ago

Did you get paid during the off duty?
I'm thinking about breaking my finger.

I miss sugin

e