Skip to content
This repository has been archived by the owner on Jul 27, 2023. It is now read-only.

2^53 + 1 issue #2

Closed
jd327 opened this issue Aug 25, 2014 · 5 comments
Closed

2^53 + 1 issue #2

jd327 opened this issue Aug 25, 2014 · 5 comments
Milestone

Comments

@jd327
Copy link
Contributor

jd327 commented Aug 25, 2014

See #1 (comment) and https://gist.github.com/alco/54beac75f1188bbe280b

Looping in @alco.

@alco
Copy link
Member

alco commented Sep 3, 2014

Here's a basic proof of concept https://github.com/alco/hashids.js/commit/0b268e6873d24095a5c82548cd6d09c9e8ceb95d

The idea is to wrap input numbers in objects that provide the necessary arithmetic functions. By default the wrapper is only used internally and it simply uses native arithmetic. We also limit the range of input numbers (https://github.com/alco/hashids.js/commit/0b268e6873d24095a5c82548cd6d09c9e8ceb95d#diff-ac45510b2aa86482ae1d7551d7e6a36cR137) to ensure compatibility with implementations that use 64-bit integers or big integers.

If the user of the library passes in an object instead of a number, we don't check its range and assume it is an already wrapped number that implements all the required functions. This way, users will be able to extend the library with support for larger numbers without touching its implementation.

The only change to the public interface is in the decrypt function (https://github.com/alco/hashids.js/commit/0b268e6873d24095a5c82548cd6d09c9e8ceb95d#diff-ac45510b2aa86482ae1d7551d7e6a36cR339) were we need to pass a wrapped zero value so that we know which type to use when decoding the string back into numbers.

@jd327
Copy link
Contributor Author

jd327 commented Sep 4, 2014

I like the idea of letting the user extend Hashids with their own library to handle big numbers a lot. I think this a) keeps Hashids small and independent of 3rd party libs for those that don't care about handling big numbers and b) the user is free to pick their own implementation.

For example I know for JavaScript, there's a few:
https://github.com/jtobey/javascript-bignum
https://github.com/alexbardas/bignumber.js
http://jsfromhell.com/classes/bignumber

So, people might be inclined to use one over the other. Or maybe make their own.

@alco, thanks for the proof of concept. One followup question though - is there a reason it would be better to provide objects with math functions included to encode(), rather than provide a math lib to the constructor initially and provide strings of large ints to encode() after that?

@jd327 jd327 added this to the Hashids 1.1 milestone Sep 10, 2014
@alco
Copy link
Member

alco commented Sep 10, 2014

@ivanakimov It makes sense to pass the functions to encode or the Hashids constructor, it just didn't cross my mind at the time. I'll take a look at the libraries you mentioned and will try building another prototype with support for big numbers.

zakame added a commit to zakame/hashids.pm that referenced this issue Sep 15, 2014
@zakame
Copy link
Member

zakame commented Sep 15, 2014

For perl, apparently it only breaks for 2^60.

I can probably use bignum here for >= 2^60.

@4kimov
Copy link
Contributor

4kimov commented Jul 27, 2023

Closing since the project is moving. New algo has maxValue() method to determine upper integer limit, which will differ per implementation.

@4kimov 4kimov closed this as completed Jul 27, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants