munrocket / double.js Goto Github PK

For some reason (2**53+1).toExponential() gives wrong print but correct inside.

console.log(new Double('9007199254740992').sub(new Double('1')).toExponential());
//9.0071992547409932e+15
//Double {hi: 9007199254740992, lo: 1}

By the way working quickly with Int128 and printing it can be a good enhancement.

Uncaught TypeError: D is not a constructor at withDoubleJs (benchmark.js:26) at mandelbrotSplitTest (benchmark.js:186) at drawSplitTest (benchmark.js:205) at window.onload (benchmark.js:228)
This is from Chrome. The same thing happens in Firefox. Both on Ubuntu 20.04.

I am looking for a library that can parse or eval equations, I am using this in Qt Qml Felgo, using Qml JavaScript, do you know if this works in Qml JavaScript Engine also?

Inspired by this, I'm probably going to write a quad double library. It will have 5 operations:

• Initialize from a number (trivial) or a sum or product of two numbers.
• Multiply by another quad or number.
• Add / sub another quad or number.
• Compare quads.
• Convert to string by calling bigfloat (for debugging only, no need for speed).

There won't be anything else, because the only application I need is polygon clipping. Division is handled by using rational numbers.

This paper seems promising.

Numbers are represented as objects:

interface Doubles {
    floats: Float64Array;
    words: Uint32Array;
}

The two fields are aliased like this:

words = new Uint32Array(floats.buffer);

The paper calls for functions like ufp and epart that are best handled by poking IEEE 754 bits directly through integer typed arrays. Function definitions will be like:

function sum44(a, b, result) { ... }

Writing the result to an existing structure avoids memory allocations which involve the 2 aliased typed arrays wrapped in an object.

What do you think? Maybe double.js functions could also take a result array to avoid allocating temporaries in longer calculations.

Something very weird is going on:

$ uname -a
Linux host2 5.4.0-25-generic #29-Ubuntu SMP Fri Apr 17 15:06:57 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
$ node -v
v14.1.0
$ cat package.json 
{
  "dependencies": {
    "double.js": "^0.4.39",
    "esm": "^3.2.25"
  },
}
$ cat double.js 
import { Double } from 'double.js/dist/double.esm.js'
export { Double }
$ cat a.js
require = require("esm")(module)
const D = require('double.js').Double

const inner_radius = new D('1.0')
console.log(inner_radius.toExponential())
const outer_radius = new D('2.0')
console.log(outer_radius.toExponential())
const radius = outer_radius.add(inner_radius)
console.log(radius.toExponential())
console.log(D)
console.log(outer_radius)
console.log(inner_radius)
console.log(radius)
$ node a.js
1.99999999999999899e+0
2.1999999999999980e+0
-1.232595164407811093356479670998e-32
[Function: Double]
Double { hi: 0, lo: 0 }
Double { hi: -1.232595164407831e-32, lo: 0 }
Double { hi: -8.98561874853316e-33, lo: 4.347023556149115e-49 }

Any thoughts were to start from?

Having "type": "module" in package.json prevents usage of
double.js on server node.js with both --experimental-modules and
esm NPM package.

I find your library very interesting and am trying to understand the choice of arithmetic in the library. I am focusing on PI, since it is a commonly known value.

Do you mind explaining how Double.Pi was settled? Double.fromString(PI) almost produces the exact same result.

I can see the fromString method iterates over multiple static Double methods which accumulates to a significant different residual part (lo) compared to the actual decimals of the low part of PI:
2.384626433832795e-16 (the PI.slice(17, 33) seen below).

const PI = '3.141592653589793238462643383279502884'
Double.Pi // { hi: 3.141592653589793, lo: 1.2246467991473532e-16 }

Double.fromString(PI) // { hi: 3.141592653589793, lo: 1.224646799147353e-16 }

const high = Number.parseFloat(PI.slice(0, 17)) // 3.141592653589793
const low = Number.parseFloat(PI.slice(17, 33) + 'e-31') // 2.384626433832795e-16

twoSum(high, low) // { hi: 3.1415926535897936, lo: -2.056265664667831e-16 }

The benchmark seems to show a massive speed difference between decimal.js and big.js.

The bignum libraries generally have a precision limit for division operations, for example 20 digits. However Mandelbrot calculations only involve addition / subtraction / multiplication which result in a finite number of bits, so there's no need to round.

The problem for benchmarking is that without rounding, every iteration potentially doubles the number of bits, making the Mandelbrot iteration run in polynomial instead of linear time.

The bigfloat benchmark code rounds intermediate results at every iteration.

It seems decimal.js rounds multiplication results by default while big.js does not, which would explain the apparent speed difference.

There is an error with this repository's Renovate configuration that needs to be fixed. As a precaution, Renovate will stop PRs until it is resolved.

File: .renovaterc.json
Error type: Invalid JSON (parsing failed)
Message: Syntax error: expecting end of expression or separator near h" "bump

Failing tests are in https://github.com/yanovich/double.js/tree/exp2 e0e618e

Is there any available documentation for these algos?

Hi.

My code:

import Double from 'double.js';

export function roundTo(num: number, roundTo: number) {
	roundTo = new Double(1).div(roundTo).toNumber();
	return new Double(Math.floor(num * roundTo)).div(roundTo).toNumber();
}

Compiles successfully but on execute:

roundTo = new double_js_1.default(1).div(roundTo).toNumber();
              ^
TypeError: double_js_1.default is not a constructor

In double.d.ts:

export default class Double

In double.js:

module.exports = factory()

factory returns class Double.
Where default? As far as I understand it should return {default: Double}.