lambda-math - npm Package Compare versions

Comparing version 0.0.13 to 0.1.0

package.json

		{
		"name": "lambda-math",
		"version": "0.0.13",
		"version": "0.1.0",
		"description": "Pseudo lambda expressions for JS arbitrary-precision arithmetic operations.",
		@@ -5,0 +5,0 @@ "main": "src/index.js",

README.md

		@@ -16,16 +16,7 @@ # Lambda math

		Consider adding the floating point number `300 / 293` many times. 72 times in fact. Now, we don't want to simply multiply a number by 72. We want to add it 72 times, so that we can clearly see the problem with floating point rounding which exists in standard JavaScript. So, using `lambda-math` library, we can write:
		Consider adding the floating point number `300 / 293` many times. 72 times in fact. Now, we don't want to simply multiply a number by 72. We want to add it 72 times. This way, we can clearly see the problem with floating point number rounding which exists in standard JavaScript.

		```
		const { div, add, λ, Σ } = require('lambda-math');
		The simple JavaScript way of doing such a sum:

		λ( div, [300, 293] )
		( add, [λ[0], λ[0]], [Σ, λ[0]], 70 );

		console.log(λ[1].number); // 73.72013651877133
		```

		Compare the above to the simple JavaScript way of doing such a sum:

		```
		let result = 0;
		@@ -51,2 +42,21 @@

		You may have noticed that both approaches produce exactly the same output: `73.72013651877126`. If you go and use some cool mathematical environment to actually perform this arithmetic, you will see that the output is something like: `73.7201365187713310580204778156996587...`. Comparing the JS output and mathematical output, we can see that the last 2 digits are wrong in the JS version:

		```
		JS: 73.72...77126
		Math: 73.72...77133
		```

		Can we do any better? Using `lambda-math` library, we can write:

		```
		const { div, add, λ, Σ } = require('lambda-math');

		λ( div, [300, 293] )
		( add, [λ[0], λ[0]], [Σ, λ[0]], 70 );

		console.log(λ[1].number); // 73.72013651877133
		console.log(λ[1].string); // '73.72013651877133105776'
		```

		As you can see, the pseudo lambda approach doesn't have the problem with rounding floating point numbers. Also, some (mathematicians) can argue that the syntax `lambda-math` introduces is more elegant, shorter, and cleaner overall (compared to pure JavaScript way of doing things).
		@@ -77,3 +87,3 @@

		Some examples to better demonstrate these concepts:
		Some examples follow below to better demonstrate these concepts.

		@@ -143,6 +153,6 @@ ### Example 1

		### Example 6

		Besides using `λ` as a function, you can also access the results of each invocation of the function via the array index, starting from 0. So first invocation of `λ` will store the result as `λ[0]`, second invocation as `λ[1]`, and so on. For convenience, `λ[i].number` will contain the JavaScript `number` result value, `λ[i].string` will contain the JavaScript `string` result value, and `λ[i]` will contain the `BigNumber` result value.

		### Example 6

		```
		@@ -162,6 +172,6 @@ λ(add, [1, 2]);

		### Example 7

		You can also chain any number of calls to `λ`, and this will not have any affect on your program:

		### Example 7

		```
		@@ -179,6 +189,6 @@ λ(add, [1, 2])

		### Example 8

		Last, but not least, `λ.reset()` is available to clear all `lambda-math` state, and reset the results stack to zero.

		### Example 8

		```
		@@ -214,4 +224,8 @@ λ(add, [1, 2])

		## Lint the source code

		You can use ESLint to check for potential problems in source code by running `npm run lint`.

		## License

		See [LICENSE](LICENSE) for more details.

package-lock.json

Sorry, the diff of this file is too big to display

lambda-math - npm Package Compare versions

Improved metrics