patashu / break_infinity.js Goto Github PK

While it's technically out of the scope of the repository (making a second one would be ok), a lot of people want to make incremental games that go above 1e308 in C#/Unity, and a mechanical translation of break_infinity.js into C# would be satisfactory for those purposes.

If anyone out there does this, let me know and I can link it from this repository and give it my official blessing.

Same as add(1).log10()

As seen on https://github.com/Yaffle/BigInteger/

Might be faster, might not

Granite had optimized times in AD repo:

/**
 * This version of times avoids an extra conversion to Decimal, if possible. Since the
 * mantissa is -10...10, any number short of MAX/10 can be safely multiplied in
 * @returns {Decimal}
 */
Decimal.prototype.times = function(value) {
  if (typeof value === "number") {
    if (value < 1e307 && value > -1e307) {
      return Decimal.fromMantissaExponent(this.mantissa * value, this.exponent);
    }
    // If the value is larger than 1e307, we can divide that out of mantissa (since it's
    // greater than 1, it won't underflow)
    return Decimal.fromMantissaExponent(this.mantissa * 1e-307 * value, this.exponent + 307);
  }
  if (typeof value === "string") return this.times(new Decimal(value));
  return Decimal.fromMantissaExponent(this.mantissa * value.mantissa, this.exponent + value.exponent);
};

@Patashu Any thoughts about it? Which one (current or this one) is better?

Great library, I've been working with it as a bases for a ES6 module based number lib. (Trying to compress distribution size.)

You can consider shrinking the source code by modifying the powerof10 = [....] array to be auto generated.

Example:

const NUMBER_EXP_MAX = Number(Number.MAX_VALUE.toString().split("e")[1]) - 1;
const NUMBER_EXP_MIN = Number(Number.MIN_VALUE.toString().split("e")[1]) + 1;
let powersof10 = [];
for (let i = NUMBER_EXP_MIN; i <= NUMBER_EXP_MAX; i++) {
    powersof10.push(Number('1e' + i));
}
const indexof0inpowersof10 = -NUMBER_EXP_MIN;

This would negate the need to keep that vary long array in the source. Number("string") also does not suffer from the floating point errors that Math.pow(10,e) does.

Crazy time

break_infinity.min.js should be able to function correctly on all versions of Internet Explorer (including IE6), because many people who go to Kongregate still use Internet Explorer. (break_infinity.js uses the class keyword, which immediately disqualifies it.)

To make break_infinity.min.js, I throw break_infinity.js into http://babeljs.io/repl/ set to es2015, then into https://javascript-minifier.com/ , and the code still works in for example Chrome. But I don't have a way to test easily in IE due to lack of developer tools. So if you can test and confirm it works OK, or can give me a set of steps that DO produce javascript working on IE, let me know.

Hevipelle's Antimatter Dimensions swapped from decimal.js to break_infinity.js. Once the update is out, I will provide the devs of these two incremental games also swap for that sick performance gainz.

AD script time improved by 4.5x after swapping from decimal.js to break_infinity.js. This could be your incremental game:

EDIT: Don't know what Idle Bouncer uses, can check that game too

EDIT 2: Apparently Trimps uses decimal.js?! Does that game even go above 1.78e308? EDIT 3: It uses it just to make it so breeding times don't flip out when you have an extremely small or large amount of Trimps.

If one looks at [email protected]'s files on Unpkg, you can see that there are files that are redundant were included as part of the package:

For e.g.:

• bili.config.ts
• tsconfig.json
• tslint.json
• typedoc.ts
• types directory
• .github directory

Specifying a .npmignore file or simply specifying the directory to be used to publish the artifacts from would fix this issue.

(P.S. Interestingly enough the npm documentation also has additional information on what should be published in a package in the developer guide, specifically the Keeping files out of your package section:

Use a .npmignore file to keep stuff out of your package. If there’s no .npmignore file, but there is a .gitignore file, then npm will ignore the stuff matched by the .gitignore file. If you want to include something that is excluded by your .gitignore file, you can create an empty .npmignore file to override it. Like git, npm looks for .npmignore and .gitignore files in all subdirectories of your package, not only the root directory.

)

Alternatively, we might have to restructure the whole project.. See this StackOverflow answer to writing NPM modules in TypeScript.

I'm not sure if this is for a reason but i cannot seem to find .decimalPlaces() and .dp() from decimal.js.

I need this to cut off a long result from dividing two very big decimals.

Math.pow(-0.911317570321271, 4.1);
NaN

Decimal.pow(new Decimal(-0.911317570321271), 4.1);
e {mantissa: 6.8335432712143485, exponent: -1}

https://stackoverflow.com/a/20250486/4254717

In break_infinity.js
> new Decimal('10').pow('1000000000000000').toString()
"1e+1000000000000000"

In break_break_infinity.js:
> new Decimal('10').pow('1000000000000000').toString()
"1.3716055782244467e+1000000000000000"

Using pow() resulting as a number with quadrillion digits, break_break_infinity.js will have 30%-120% margin of error which is no good.

One would expect that the result of Decimal.round would always be an integer (when converted to number), especially if the input was an integer, but apparently not. I'm not sure exactly what causes this or how to fix it.

No clue how you do this.

First problem: After 1e(1e308), exponent can no longer be safely cast to a number. This means that log and anything relying on it (ln, log2, log10, pow) needs to be changed.

Second problem: After exp(1e308), exp needs to be able to handle larger input than Number (such as Decimal), and lines like 'x = new ExpHelper(this.toNumber());' and 'x = x.sub(tmp).toNumber();' need to be looked at.

Third problem: We'll probably want pow to start being able to accept larger than number (such as Decimal) around this point.

I don't think anything else would need to be changed. Notably all of these changes cause performance loss, maybe to the point where a break_break_break_infinity.js would be warranted.

3:24 AM] slabdrill: i improved my hyperbolic trig functions. it turns out they really only have a range of however much your precision can fit. so not necessarily needed i guess.

[6:15 AM] slabdrill: I think you should just make factorial a static instead of being a function of decimal

[6:22 AM] slabdrill:

static factorial(value) {
let n = value+1;
return Decimal.pow((n/Math.E)*Math.sqrt(n*Math.sinh(1/n)+1/(810*Math.pow(n, 6))), n).mul(Math.sqrt(2*Math.PI/n));
}
static fact(value) {return Decimal.factorial(value)}

static permutation(value,other) {
return Decimal.fact(value).div(Decimal.fact(value-other))
}
static combination(value,other) {
return Decimal.permutation(value,other).div(Decimal.fact(other))
}

static doubleFactorial(value) {
value = Math.round(value) //making sure only ints can get in
if (value % 2 == 1) return Decimal.fact(value).div(Decimal.doubleFactorial(value-1))
return Decimal.fact(value/2).mul(Decimal.pow(2,value/2))
//also this doesnt support negatives
}

ilog(base) { //https://en.wikipedia.org/wiki/Iterated_logarithm
if (this.lte(1)) return 0;
let t = this.log(base)
for (var r=1;t>=1;r++) t = Math.log(t)/Math.log(base);
return r;
}

[7:21 AM] slabdrill: is exp() faster the way it is or would this.pow(Math.E) be faster

random suggestion: make the base comparison functions work with tolerance without needing to specify _tolerance. This can be done by checking if args.length is 2 (i think?)

[3:09 AM] slabdrill: random break_infinity suggestion:

root(x) {
if (x%2 !== 1 || this.m >= 0) return this.pow(1/x)
return this.negate().pow(1/x)
}

basically, allows doing negatives for odd roots

I'd like to incorporate this into an Angular project, but there seems to be no type definitions for Typescript. I tried some workarounds to get it to work, but couldn't. Would you be willing to add type declarations for usage with Typescript?

Several things need to be figured out about pow(). Copying the code as it stands now:

	pow(value) {
		//UN-SAFETY: We're assuming Decimal^number because number^Decimal or Decimal^Decimal is unheard of in incremental games.
	
		//TODO: Possibly implement slabdrill's generic fast track (with more precise tests)
		/*
		
		var temp = Math.pow(this.mantissa,value)
		if (Math.abs(temp) < 1.8e307) {
			return Decimal.fromMantissaExponent(temp*Math.pow(10,(this.exponent*value)%1), Math.floor(this.exponent*value));
		}

		*/
	
		//Fast track: If (this.exponent*value) is an integer and mantissa^value fits in a Number, we can do a very fast method.
		var temp = this.exponent*value;
		if (Number.isSafeInteger(temp))
		{
			var newMantissa = Math.pow(this.mantissa, value);
			if (Number.isFinite(newMantissa))
			{
				//TODO: This might actually be slower than the 'slow track' if pow is very large, because of the huge amount of normalization we have to do. For example, Decimal.pow(1.43534e-8, 1000) has to be normalized 156 times. Maybe only take fast track if abs(value) <= 10? (Alternatively normalization for very unnormalized numbers can be done)
				return Decimal.fromMantissaExponent(newMantissa, temp);
			}
		}
		
		return Decimal.exp(value*this.ln());
	}

sqrt() also has a potential optimization:

	static sqrt(value) {
		//TODO: If generic fast track pow is not used, implement slabdrill's sqrt and cbrt specific fast track like so:
		///if (this.exponent % 2 = 1) return Decimal.fromMantissaExponent(this.mantissa*3.16227766017, Math.floor(this.exponent/2));
		value = Decimal.fromValue(value);
		
		return value.sqrt();
	}

slabdrill from the Antimatter Dimensions Discord has expressed interest in doing this, if they finish I'll try to get it up on github either in this repository or a related one.

https://www.npmjs.com/package/big-integer

With this change it will be slower, but it will be able to represent numbers as big as 1e(1.78e308), if not bigger! Due to the performance loss, it will be a separate file, so you can choose based on your incremental game needs.

I copied exp() directly from the implementation in SpeedCrunch, without much thought as to performance concerns.

Since it makes and uses a lot of Decimal operations, there's probably a way to do the same calculations but with less overhead. This would also make pow() faster, since pow() uses exp().

log10 is very slightly faster than ln and pow10 is supposedly slightly faster than exp.

pow10 = function(v) {
  if (Number.isInteger(v)) return Decimal.fromMantissaExponent_noNormalize(1,v)
  if (v < 308) return Decimal.fromNumber(Math.pow(10,v)) //idk if this fast track is actually good
  return Decimal.fromMantissaExponent(Math.pow(10,v%1),Math.floor(v))
}

If addition is hyperoperator 1, multiplication is hyperoperator 2 and exponentiation is hyperoperator 3, tetration is hyperoperator 4 and pentation is hyperoperator 5. These operators are notable for being easy to define for integers, but extremely hard to define for real and complex numbers. (Speaking of which, complex numbers when? Vectors/matricies when? Etc...)

• https://en.wikipedia.org/wiki/Tetration
• http://www.tetration.org/
• https://en.wikipedia.org/wiki/Pentation

Like exponentiation, tetration has two inverses - the super-root and the super-logarithm:

• https://en.wikipedia.org/wiki/Tetration#Inverse_operations

With this hierarchy in mind, we could ask what non-natural number hyperoperators look like - what's hyperoperator 0, hyperoperator -1, hyperoperator 0.5, hyperoperator 1.5, etc?

• https://en.wikipedia.org/wiki/Hyperoperation
• http://googology.wikia.com/wiki/Hyper_operator
• http://andydude.github.io/tetration/archives/tetration2/hyper.html
• https://sites.google.com/site/pointlesslargenumberstuff/home/2/weakoperators

To encode very large numbers, some formats and functions exist:

• https://en.wikipedia.org/wiki/Knuth%27s_up-arrow_notation
• https://en.wikipedia.org/wiki/Conway_chained_arrow_notation
• https://en.wikipedia.org/wiki/Ackermann_function

The inverse ackermann function is notable for being one of the slowest growing functions in existence:

• https://en.wikipedia.org/wiki/Ackermann_function#Inverse

And the biggest and most absurdly growing notation of all is Bird's array notation:

• http://googology.wikia.com/wiki/Introduction_to_Bird%27s_array_notation
• http://www.mrob.com/users/chrisb/

And can we go even further?

• http://forums.xkcd.com/viewtopic.php?f=14&t=7469&start=800 'My number is bigger!', especially http://forums.xkcd.com/viewtopic.php?p=2218880&sid=7158c87de2c2c31ee8c7c934d46cdb63#p2218880 and following page, http://forums.xkcd.com/viewtopic.php?p=2596056#p2596056 , http://forums.xkcd.com/viewtopic.php?p=3254229#p3254229 (EliezerYudkowsky's massive computable number) and following page
• http://forums.xkcd.com/viewtopic.php?f=14&t=7469&p=4280817#p4280817 Finally I added my own post for funsies
• http://googology.wikia.com/wiki/Largest_valid_googologism Rayo's Number, BIG FOOT and beyond
• http://googology.wikia.com/wiki/Greedy_clique_sequence and other large combinatronical numbers
• https://itaibn.wordpress.com/2017/11/09/prefix-free-codes-and-ordinals/ a way to represent all numbers?
• https://en.wikipedia.org/wiki/Large_numbers 'Large numbers'
• http://djm.cc/dmoews.html http://djm.cc/bignum-results.txt http://djm.cc/marxen-comments.txt http://djm.cc/ralph-loader.tar December 2001 BIGNUM BAKEOFF contest
• http://googology.wikia.com/wiki/Fast-growing_hierarchy http://googology.wikia.com/wiki/Introduction_to_the_fast-growing_hierarchy
• http://zoologia.biologia.uasnet.mx/ydras/hydra%209.pdf http://fleischer.selfip.com/Paper/hydra_fun07.pdf https://link.springer.com/chapter/10.1007/978-3-540-72914-3_14 Kirby-Paris Hydra and Buchholz hydra and Die Another Day

Finally we reach ordinal and cardinal numbers, transfinite numbers representing sizes and kinds of infinity that can grow to absurd amounts. We've now stepped beyond the realm of numbers that even remotely make sense. Hyperreal/surreal numbers are another alternative - they make infinite and infinitesimal numbers quantities that can be further added/multiplied like any other number.

• https://steamcommunity.com/app/432380/discussions/0/135508292190387402/?tscn=1486172196 (many tutorials and articles curated here)

In break_infinity.js and break_break_infinity.js, we calculate pow generically as

return Decimal.pow10(value*this.log10());

This has a precision problem for very large numbers getting pow'd.

For break_break_infinity.js, here's the progression:

new Decimal("2e100000").pow(1.01).toString()
"2.0139111001331536e+101000"
new Decimal("2e1000000").pow(1.01).toString()
"2.0139111002681136e+1010000"
new Decimal("2e10000000").pow(1.01).toString()
"2.0139111018876377e+10100000"
new Decimal("2e100000000").pow(1.01).toString()
"2.013911110525099e+101000000"
new Decimal("2e100000000").pow(1.01).toString()
"2.013911110525099e+101000000"
new Decimal("2e1000000000").pow(1.01).toString()
"2.0139111796247904e+1010000000"
new Decimal("2e10000000000").pow(1.01).toString()
"2.013905098861038e+10100000000"
new Decimal("2e100000000000").pow(1.01).toString()
"2.013869720236098e+101000000000"
new Decimal("2e1000000000000").pow(1.01).toString()
"2.0140820013086556e+1010000000000"
new Decimal("2e10000000000000").pow(1.01).toString()
"2.0169145547303304e+10100000000000"
new Decimal("2e100000000000000").pow(1.01).toString()
"1.9809567785503388e+101000000000000"
new Decimal("2e1000000000000000").pow(1.01).toString()
"1.7782794100389228e+1010000000000000"
new Decimal("2e10000000000000000").pow(1.01).toString()
"1e+10100000000000000"

The problem is due to the use of log10. all of the precision slowly vanishes until nothing is left:

10000000000000000+0.30102999566398119521
10000000000000000

obviously, making a log10_decimal or log10_biginteger would not fix this problem.

The line will have to be something different that allows the precision to continue to exist. It's clear that the 'high part' and the 'low part' of log10 mean something different - one mostly influences the exponent, one mostly influences the mantissa. Maybe this will lead to a solution (and possibly even a speedup)?

I haven't checked other operations, but in some cases add can return the same instance that was passed as left-hand side Decimal.
https://github.com/Patashu/break_infinity.js/blob/master/src/break_infinity.ts#L869

We need to decide if we want Decimal to be

• Faster, with less allocations
• Slower, but without pitfalls

I believe that returning the same instance can lead to some quirky bugs caused by innate mutability of Decimal, but it's your call.
Keep in mind that "faster" and "slower" doesn't really mean object allocation itself (which a really lightweight operation), but instead the fact that it will add to garbage and GC will be invoked sooner.

add/sub has some vestigal weirdness that has the correct functionality, but probably isn't optimal or as simple as possible.

https://bitbucket.org/heldercorreia/speedcrunch/src/9cffa7b674890affcb877bfebc81d39c26b20dcc/src/math/floatnum.c?at=master&fileviewer=file-view-default

• float_add
• float_sub
• _addsub_ordered

I don't remember if I did this or not...

I don't know if this is due to Antimatter Dimensions code or break_infinity.js code. (I'll close it if it's confirmed to be due to the former.)

Some people on mobile browsers are reporting their saves do not work after the Antimatter Dimensions Eternity Update. However, their saves work fine on Windows Chrome. So it must be something to do with the specific browser used to play the game.

https://www.reddit.com/r/AntimatterDimensions/comments/7gvkf0/save_broken_after_eternity_update_d/

https://www.reddit.com/r/AntimatterDimensions/comments/7gtzl3/my_save_is_broken_after_the_eternity_update/

(just copying and pasting my notes)

hypothetical number system that reaches 10^^1.8e308: store two numbers. the first is layer (starts at 0). the second is payload.
layer == 0: payload is the number.
layer == 1: payload is the exponent of the number (e.g. 1epayload is how large the number is)
layer == 2: payload is the exponent of the exponent of the number (e.g. 1e1epayload is how large the number is)
and so on all the way up to layer == 1.8e308, payload == 1.8e308 where the number system breaks.
until you recursively split 'layer' into 'layer layer' and 'layer payload'... infinite layers until you run out of memory??

There are a lot of things you'd need to figure out, first is when do you decide to increase or decrease the layer after doing a calculation (e.g. what does normalizing involve and how aggressive does it need to be) second is that functions that have been simplified to not worry about very big/very small cases like log and pow would need to handle these ridiculous numbers,third is that as we reach extremely high levels of tetration, a question arises, what kinds of operators do we need to keep going bigger and bigger anyway? and of course fourth is optimization, if we have to compare layers every time we do operations it might get slow.

I think the proper way to do normalization is to increment layer whenever payload >= 9e15, and to decrement payload whenever payload < log10(9e15). That way you never skip integers at layer 0, you never skip integer exponents at layer 1, you never skip integer ees at layer 2, etc. And if you normalize strictly then you can take shortcuts in other operations, like in cmp if layera > layerb then a > b. And I think you at most have to change by 1 layer whenever normalizing.

log10 would be pretty funny, it'd literally just decrement layer by 1 and be super fast. Which kind of implies pow10 would be really fast too (increment layer by 1) which is funny as well. Of course, any non-10 log/pow would have to use actual math. Of course, if we want to have a 'game' that goes above 9e15 layers (no game comes ANYWHERE close to this right now, it goes without saying), we'll need to create operators that go up and down more than a single layer at a time. Factorial/xe^x and inverse factorial/lambert w probably won't cut it... Maybe tetration and its inverses are strong enough?

as for layer layers, I have no idea how it would work and it sounds dumb, but it does sound funny. there's probably a smarter way to do it? but that can wait until laaater.

games calculators that go this high that we can scavenge for working code:

Apparently Incremental Unlimited does something similar, and reaches at least 10^^4 already: https://play.google.com/store/apps/details?id=com.antoine.mathematician.oddlittlegame&hl=en

https://mrob.com/pub/comp/hypercalc/hypercalc-javascript.html hypercalc goes up to 10↑↑(10^10), which is pretty heckin' sweet! The source code's in perl, though. Who wants to read perl? http://mrob.com/pub/comp/hypercalc/hypercalc.txt

As per AD Discord, we are approaching a point where we would benefit from BI optimizations. I'll try to squeeze some more performance from low-level optimizations, like less allocations and type consistency, and I think working on it would be more safe/efficient with TypeScript
Plus, we will always have fresh TS definitions out of the box!

Consider adding support for integer roots, as it can be done somewhat faster than pow in general (and may be more accurate). This quick implementation is about 25% faster:

      Decimal.prototype.nthRoot = function (value) {
        if (this.mantissa === 0) return ME_NN(0, 0);
        if (value > 307) return this.pow(1 / value);
        if (value === 0) return ME_NN(1, 0);
        const newExp = Math.floor(this.exponent / value);
        const excessExp = this.exponent - value * newExp;
        return ME(Math.pow(powerOf10(excessExp) * this.mantissa, 1 / value), newExp);
      };

(It doesn't take the sign of the base into account, though)

it links to https://github.com/Patashu/break_infinity.js/blob/master/break_infinity.d.ts which no longer exists - I think maybe it should link to https://github.com/Patashu/break_infinity.js/blob/master/dist/index.d.ts now?

Turns out being able to check if your update changes behaviour unexpectedly is a pretty good thing to have.

It is unclear how to begin using this library if you are unfamiliar with decimal.js, would be nice to get some documentation on installing and adding to a new project, as well as converting an old project

> var Decimal = require('decimal.js')
undefined
> var BDecimal = require('break_infinity.js/break_infinity.js')
undefined
> new Decimal('1e9999').toExponential(5)
'1.00000e+9999'
> new BDecimal('1e9999').toExponential(5)
'1.000000e+9999'

swarmsim and swarm-numberformat depend on these for number formatting; expected them to match.

I noticed while testing break_break_infinity.js that this line:

exp = Math.trunc(x/Math.LN10);

starts to not work properly if x is above 1e17, because trunc finds no decimal places to trunc.

See if this causes any numerical inaccuracies in regular break_infinity.js.

swarmsim and swarm-numberformat need it, and it exists for native numbers, decimal.js, and decimal.js-light.

This is enough for my unit tests to pass, but I'm not sure that it's correct everywhere, so no pull request:

	toPrecision(sigfigs) {
		return this.toFixed(sigfigs-1)
	}

I think most of the trigonometric operators like cos and sin and stuff are pointless, but gamma (the continuous factorial function) and its inverse deal with the domain of very large numbers, grow FASTER than exponential and, if given easy access to, might be explored by incremental games in more detail.

Notably, decimal.js does NOT have gamma/invgamma.

SpeedCrunch has implementations of gamma and lngamma:

• https://bitbucket.org/heldercorreia/speedcrunch/src/9cffa7b674890affcb877bfebc81d39c26b20dcc/src/math/floatgamma.c?at=master&fileviewer=file-view-default
• https://bitbucket.org/heldercorreia/speedcrunch/src/9cffa7b674890affcb877bfebc81d39c26b20dcc/src/math/floatincgamma.c?at=master&fileviewer=file-view-default

But no invgamma.

invgamma seems to be a lot harder, discussions/papers here:

• https://mathoverflow.net/questions/12828/inverse-gamma-function
• http://www.ams.org/journals/proc/2012-140-04/S0002-9939-2011-11023-2/S0002-9939-2011-11023-2.pdf
• http://community.wolfram.com/groups/-/m/t/882519
• http://mis.math.leidenuniv.nl/websites/websites/positivity2013/presentations/uchiyama.pdf
• https://math.stackexchange.com/questions/18362/is-there-an-inverse-gamma-gamma-1-z-function
• http://echochamber.me/viewtopic.php?t=105393
• https://arxiv.org/pdf/1309.2167.pdf
• https://cran.r-project.org/web/packages/invgamma/invgamma.pdf

EDIT: I looked at the SpeedCrunch code for gamma and it's a ton of functions to convert, that and the fact that gamma() and x^x scale at more or less the same rate makes me less motivated to do this. But there is no technical problem stopping gamma and lngamma from being implemented in break_infinity.js besides the motivation to do it.

Also, related to invgamma, how about the Lambert-W function (inverse of x*e^x)?

• https://en.wikipedia.org/wiki/Lambert_W_function
• https://www.maplesoft.com/support/help/Maple/view.aspx?path=LambertW
• http://au.mathworks.com/help/symbolic/lambertw.html?requestedDomain=au.mathworks.com
• https://docs.scipy.org/doc/scipy-0.16.0/reference/generated/scipy.special.lambertw.html

From Zelo101#0138 on the Antimatter Dimensions Discord server in the game-dev channel:

I've got this error with AD-notations, does anyone know how to solve this?

...
here is how i import it

(Note: This will be the tracking issue to fix the package entry-points)

Add support of parsing numbers like e100 in addition to 1e100
For ex.
Decimal.fromString("e100")

> var Decimal = require('decimal.js')
undefined
> var BDecimal = require('break_infinity.js/break_infinity.js')
undefined
> new Decimal('fail')
Error: [DecimalError] Invalid argument: fail
    at parseOther (/home/evan/code/swarm-numberformat/node_modules/decimal.js/decimal.js:3596:13)
    at new Decimal (/home/evan/code/swarm-numberformat/node_modules/decimal.js/decimal.js:4298:55)
    at repl:1:1
    at ContextifyScript.Script.runInThisContext (vm.js:50:33)
    at REPLServer.defaultEval (repl.js:240:29)
    at bound (domain.js:301:14)
    at REPLServer.runBound [as eval] (domain.js:314:12)
    at REPLServer.onLine (repl.js:441:10)
    at emitOne (events.js:121:20)
    at REPLServer.emit (events.js:211:7)
> new BDecimal('fail')
Decimal { mantissa: NaN, exponent: NaN }

I expected them to behave the same, but decimal.js throws an error while break_infinity returns NaN.

just reminding myself that I've been lazy and not ported over everything!! close when it's caught up

Modern Javascript development is usually done using a module bundler, which has some very clear advantages.

• Allows splitting the project into modules (files) instead of having it in a single file, which makes the code more maintainable and readable. This will welcome more people (including me) to contribute to the project.
• Easy integration with Babel to allow writing ES6 code while still maintaining cross-browser support. (See #1)
• Tree shaking and code uglifying as a normal part of the build process

Rollup is considered the best for libraries as it produces the lightest bundle.

Code like this

const decimal = new Decimal("1e420");
...
Decimal.pow(decimal, 10);

Will implicitly call valueOf in this line

on value, which calls toString which will be converted back to number just to compare with 10

import Decimal from 'break_infinity.js'
Could not find a declaration file for module 'break_infinity.js'.

faster than remaking every place you'd want it!