-
Notifications
You must be signed in to change notification settings - Fork 87
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
#ifndef before #define BN_ARRAY_SIZE #21
Conversation
As no feedback has been given and I needed these features I will use my own fork. |
Hi @umnikos and thanks for your interest in this project :) I'm sorry for keeping you waiting :( Like everyone else I also have other obligations, which is why I'm sometimes super slow to react to these issues and PRs. You are of course free to use your own fork if you do not have the patience to wait for me :) I see two main changes in your PR:
1) ifndef before define BN_ARRAY_SIZE I don't think your suggestion works well here, if what you want is parametric integer size. The problem with using an ifndef-guard, is that unless you explicitly #define the array-size everywhere you include the header file / I.e. it makes it possible to have the c-file compiled with one array size (i.e. one integer max-size), and the header-file indicating otherwise. I think it would be better to refactor the code such that the array-sizes are parametric. E.g. converting void bignum_add(struct bn* a, struct bn* b, struct bn* c); /* c = a + b */ to void bignum_add(struct bn* a, struct bn* b, struct bn* c, size_t array_size); ... or something similar. If you only need fixed-size integers all the time, it should be possible to use macros #define bn_add(a, b) bignum_add(a, b, FIXED_ARRAY_SIZE) How do you like this approach instead? 2) Karatsuba multiplication I've dabbled with karatsuba multiplication in the past, but did not get anywhere near theoretical speed-ups in practice. |
1) ifndef before define BN_ARRAY_SIZE 2) Karatsuba multiplication I can open a pull request with only the karatsuba multiplication if you want :) |
Please do. I consider keeping the naiive implementation, and letting a compile-time switch (#define-macro) decide. In some environments recursion is verboten, so it'd be nice to have the choice. While meddling with multiplication, have you seen #11 ? I never got around to taking proper care of that PR either ;( |
I took a quick look at #11 and it's still a regular O(n²) algorithm. I also took a look at your exponentiation algorithm and it's very bad, so expect another pull request from me :) |
😆 exactly what I was hoping 👍 👍 👍 Please keep in mind that this code is (also) aimed at resource-constrained resources. Many optimizations make use of plenty temporary variables, each allocating potentially hundreds of bytes - many small devices have 2-4kb stack at most. If possible, I would prefer to have two functions to choose from at compile time, as mentioned above :) |
The pull request is open if you haven't seen it. Also I did some digging and discovered |
Today I learned about .patch files and how they would be way better suited to do this than my #ifndef and forked repo hack. Oh well... |
I want to use this as a submodule but I need numbers larger than 1024 bits