Alexander Reardon: Let's go big (Big numbers in JavaScript) | JSConf EU 2017
HTML-код
- Опубликовано: 13 июл 2024
- 2017.jsconf.eu/speakers/alexan...
Do you feel limited, boxed in, like you are unable to grow? Try to imagine how numbers in JavaScript feel - they are stuck between +/- 9007199254740991. Unable to breathe, they are stuck.
I will talk about how we can free numbers in JavaScript to represent values much larger than their natural constraints. The talk will navigate through increasingly creative techniques to represent numbers of ever increasing values - freeing numbers from their constraints as well as ourselves. 
Наука
Awesome one . Good Analogy that you used made it far easier to understand :)
I love the color palette! I wish there were a sublime theme like this. Very informative and beautifully presented presentation. By the way, what font is that?
It is quite accessible to make your own sublime theme, so feel free to grand your wish yourself !
I have looked around, the only free font i could find that is similar to the one he used is Open Sans Bold
Holy fck I need this for my drop chance calculator where people might want to check out the next 1000 rolls, which means a bunch of math and a bit of that math is a very scary factorial of 1000 in this example.
I see that it's already a thing in js in 2023, but it doesn't work with decimal points, which I found odd since he described it as a column operation and that seems to make decimal points easy to keep track of.
Interesting solutions for performing arithmetic operations. Regarding storage of large numbers, intuitively one would think an array of 64-bit floats would be a better solution than using a string.
actually arrays of floats won't solve the problem cleanly. They are not 64-bit in precision but store only 53 bits at most, including the zero value (the rest is for the sign bit and 11 bit for scaling, including negatif and positive values, but excluding the special minimum scaling value for zero and denormal number, and the special maximum scaling value for infinite and NaN values).
Floatting point number are also normalized to eliminate the top highest bit which is always one, by shifting digits (s o the leadingbit is the highest one, always 1 for all numbers except zero which has a special scaling value) adjusting the scaling positively.
In practice, it is the number of "safe integer values" that can be stored in the digits (excluding sign and scale) that will limit you in terms of precision, and you only have 53 bits of precision.
This limits indicates that you can safely perform additions or substractions only for numbers that have at most 52 bits of precision, and then can only perform multiplications or divisions with numbers that have at most 26 bits of precision (above this, you'll loose precision and will get impacted by rounding modes)
But your implementation will be also very slow due to the need to check safe ranges to operate on, and 26 bits is not a very practical unit, and you've lost space with the extra 64-26=38 bits left unused.
An array of JS characters will be more compact (16-bit code units). YOu could use strings, but strings have an undesired effect of being unmutable: any modification creates another string but does not alter the original one. So arrays of characters would seem better, but you'll have the overhead of strings which are complex objects with a pointer to their class data linking to their methods, and the overhead of the string length that must be stored as well.
Arrays also have their overhead, but they have the enormous advantage of being mutable : each slot is separately modificable. to reference another element.
So what can you do?
Arrays of integers are much better, but Javascript actually has no integers, it only has IEEE 64-bit floating point "Numbers". There's an ongoing proposal to add a native 64-bit integer "BigInt", distinct from the "Number" type, without any implicit promotion between each other, but with explicit typecasting (which may be lossy) or using constructors. The actual proposal allows specifies that we can also use BigInt constants by suffixing them with an "n" suffix (e.g. "10n") to avoid typecasts and roundings at execution time. The conversion of the source constant will occur at compile time, when parsing the javascript source code.
This is much better! You'll use Arrays of BigInt values. Some operations on BigInt will require being able to perform at least unary negation, binary addition (substruction is an addition where the second parameter has been first negated), but you'll need to be able to handle "carries", so the result of the addition will be two integers. The same will apply to multiplication that also require two numbers to represent the result using BigInts. Divisions will be implemented by first performing the unary inverse operation (which does not need any second number on output) and then using a multiplication. There are more efficient algorithms than that for divisions, but they also apply to computing the inverse itself. Note that the inverse requires being able to store separately a negative scaling which will be reported to the result of the second operation, the multiplication and that can be used to eliminate unnecessary digits.
Note that the presentation in the video does not focus much on the representation of scaling (the second number stored and packed in a IEEE 64-bit floating point value) and on the cost of their normalization (which is negligeable on IEEE 64-bit numbers bit will become significant when working on big numbers). The scaling factor also has its own limited precision and range: this won't be adressed by the ongoing BigInt proposal.
But BigInt will help create maths libraries to represent and store efficiently big numbers without wasting space.