-
Notifications
You must be signed in to change notification settings - Fork 5
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
Eliminate Long restrictions for protocol parameters #38
Labels
Comments
Right now, it appears to be very much work for fairly little gain. When using the analyzer of very long signal, it (analyzer) can be taught to handle this restriction. |
The analyzer is really a case or itself and probably can be fixed independently, using BigInteger. |
bengtmartensson
changed the title
Eliminate Long restrictions
Eliminate Long restrictions for protocol parameters
Apr 2, 2018
bengtmartensson
added a commit
that referenced
this issue
Oct 17, 2018
bengtmartensson
added a commit
that referenced
this issue
Nov 16, 2018
bengtmartensson
added a commit
that referenced
this issue
Nov 16, 2018
This was referenced Feb 14, 2023
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Presently, Number-s are restricted to 64 (or 63) bit length, due to the use of Java longs. Lift this restriction. Provide alternative (to the present) implementation of Number (and ??). Should dynamically decide on the usage of long and used long or BigInteger.
Idea: Extend the class Number with some member functions (arithmetic etc) of BigInteger. The functions in Numerical should return Number. The arithmetic presently in long should them be performed with the member functions of Number (not to be confused with java.lang.Number).
The text was updated successfully, but these errors were encountered: