royniladri / js-big-decimal Goto Github PK

Describe the bug
Invalid result using divide.

new bigDecimal("29.45").divide(new bigDecimal("646")).multiply(new bigDecimal("646")).getValue() === "29.45"; // 29.45000304
new bigDecimal("29.45").divide(new bigDecimal("646"), 16).multiply(new bigDecimal("646")).getValue() === "29.45"; // 29.4499999999999696
new bigDecimal("29.45").divide(new bigDecimal("646"), 32).multiply(new bigDecimal("646")).getValue() === "29.45"; // 29.44999999999999999999999999999696

To Reproduce

const { default: bigDecimal } = require("js-big-decimal");

console.log(new bigDecimal("29.45").divide(new bigDecimal("646")).multiply(new bigDecimal("646")).getValue()); // 29.45000304
console.log(new bigDecimal("29.45").divide(new bigDecimal("646"), 16).multiply(new bigDecimal("646")).getValue()); // 29.4499999999999696
console.log(new bigDecimal("29.45").divide(new bigDecimal("646"), 32).multiply(new bigDecimal("646")).getValue()); // 29.44999999999999999999999999999696

Expected behavior

new bigDecimal("29.45").divide(new bigDecimal("646")).multiply(new bigDecimal("646")).getValue() === "29.45"; // 29.45

Additional context
Thanks for this great lib 😄

delete

Inconsistency in treating decimal digits in division:

Thus, bigDecimal.divide('2.00', '0.5') = 40.00000000
However, bigDecimal.divide('2.00', '0.50') = 4.00000000

Workaround: bigDecimal.divide( bigDecimal.round('2.00', 2), bigDecimal.round('0.5', 2)) = 4

npm

bigdecimal v.1.2.1

Implement different rounding methods.

Any method to set value to a big decimal object rather than creating a new object every time ?
For example :

const v1 = new bigDecimal(122345);
console.log(v1.getValue());  // 122345
v1.setValue(4566);
console.log(v1.getValue());  //4566

The package.json contains the three dependencies mentioned in the title. Maybe someone ran npm install - g check-updates instead of npm install -g check-updates.

https://github.com/royNiladri/js-big-decimal/blob/master/package.json#L68-L72

bigDecimal.round(0.00000001,8) return "0.000000000100000"
bigDecimal.round("1e-8",8) return "0.000000000100000"
although it should return "0.00000001"

it looks like a bug in the code

error in string:
number = '0.' + (new Array(-exponent + 1)).join('0') + mantisa;
fix:
number = '0.' + (new Array(-exponent - 1)).join('0') + mantisa;

`import bigDecimal from 'js-big-decimal'

export class RunUtils {

public static scaleFloat(value: number, scale: number) {
let strValue = value.toString()
let decimalValue = new bigDecimal(strValue)
return decimalValue.round(scale, bigDecimal.RoundingModes.HALF_UP).getValue()
}
}`

then error: can't find module RoundingModes

trying to do the following math: (94911150 / 94911151) == (94911151 / 94911152)

This should return false, but it appears to be returning true with this library.

var bigDecimal = require('js-big-decimal');
var Decimal = require('decimal.js');

a = new Decimal(94911150);
b = new Decimal(94911151);
c = new Decimal(94911151);
d = new Decimal(94911152);


a1 = new bigDecimal(94911150);
b1 = new bigDecimal(94911151);
c1 = new bigDecimal(94911151);
d1 = new bigDecimal(94911152);


// (94911150 / 94911151) == (94911151 / 94911152)

console.log(a1.divide(b1).compareTo(c1.divide(d1)));

console.log(a.dividedBy(b).equals(c.dividedBy(d)));

0
false

it's my understanding that compareTo returning 0 means they're equal. If you check on wolfram alpha, that isn't the case

Describe the bug
Wrong result when adding any number to -0

To Reproduce

 const n1 = new bigDecimal('-0');
 const n2 = new bigDecimal('10');
 const diff1 = n1.add(n2);
print(diff1.getValue()); // Will print -890

Expected behavior
The result should be 10

Additional context
If the operation is adding -0 to 10 the result will be correct.

Describe the bug
Rounding up a negative number returns a positive value.

To Reproduce
Pick any number in this format: -x.996, -x.997, -x.998, -x.999 and rounding it HALF_UP gives a positive value.
Example:
new bigDecimal('-1.996').round(2, bigDecimal.RoundingModes.HALF_UP).getValue(); -> {value: "2.00"}
new bigDecimal('-2.997').round(2, bigDecimal.RoundingModes.HALF_UP).getValue(); -> {value: "3.00"}
etc..

Expected behavior
Rounding up a negative number returns a negative value.

Additional context

Describe the bug

Incorrect result will When parsing exponential form numbers with following patters:

1. integer mantissa (1e0, 1e1, 1e-1) results in a number with wrong dot position.
2. negative mantissa (-1e1, -0.0134e-2 ) results in illegal number formats.

To Reproduce
Run in a nodejs console:

> bigDecimal = require('js-big-decimal');
> new bigDecimal('1e0')
bigDecimal { value: '0.1' }
> new bigDecimal('1e1')
bigDecimal { value: '1' }
> new bigDecimal('-1e1')
bigDecimal { value: '-.1' }
> new bigDecimal('-0.0134e-2')
bigDecimal { value: '0.-00134' }

Expected behavior
Correct numbers returned.

Additional context
Tested in latest development branch.
A bug fix will submitted later.

Describe the bug

Cannot use bigint values with big decimal

To Reproduce

import bigDecimal from 'js-big-decimal';

new bigDecimal(10n); // type error

Expected behavior

no type error :)

Additional context

This seems to be just a TS / typing issue -- bigint values look like they work just fine if using plain JS.

Discussed in #71

const bigValue = new bigDecimal(0.00001341);
const integer = bigValue.floor();

integer is now -0, instead of 0

Besides the issue, the intent is to obtain the integer part of the number. Is there a better way to achieve that?

After upgrade my project to Angular 10.

WARNING in  my-project depends on 'js-big-decimal'. CommonJS or AMD dependencies can cause optimization bailouts. For more info see: https://angular.io/guide/build#configuring-commonjs-dependencies

How to calculate the remainder? I didn't find the divideandremainder () method

Describe the bug
I'm getting an imprecise result after multiplying.

To Reproduce
import BigDecimal from 'js-big-decimal';
console.log(BigDecimal.multiply('11612,7833519', '10.764'));

Expected behavior
Result should be 125000, getting 124999.9999998516 like I get with plain js.

Discussed in #55

the function's declaration defaults the precision value, should the type definition not be optional then?

thanks for the tool!

Describe the bug
n1.add(n2) where n1 and n2 are bigDecimal return error :

Uncaught Error: Parameter is not a number: aN.NaNNaNNaN
at webpack_modules.423.bigDecimal.validate

Describe the bug
vite projects fail to consume js-big-decimal.

To Reproduce
Repro repo is here: https://github.com/NiloCK/vite-bigdecimal-import-reproduction

See the readme.

Expected behavior
In the repo, yarn dev should serve the sample app page, with the counter integer replaced by a bigDecimal.

Additional context
The vite site seems to be mistakenly importing content from the dist/node folder, instead of dist/web

There is some issue with:

• vite's bundler
• js-big-decimal's packaging / distribution pipeline
• some combination of the two

I'm working with this library in a project and I find it lacking the toFixed functionality, setting out a specific number of decimals is incredibly helpful, I was hoping it would be in the roadmap?

Describe the bug

There is a packaging issue in the library. For SSR apps, it works on client side but not on server side (only after the build - during dev, there is no issue).

Workaround give by Nuxt team is to "transpile" it:
nuxt/nuxt#26375

To Reproduce
https://stackblitz.com/edit/github-qytiun

Expected behavior
Module shall be properly packaged in order to allow usage without transpiling it in Nuxt.

Additional context
N/A - refer to reproduction code

Describe the bug
Division is returning 0 for very small numbers

To Reproduce
The following returns a value of 0, when it shouldn't:

var one = new bigDecimal('200000000000')
var two = new bigDecimal('17453700000.00000000')
var three = new bigDecimal('273484570903.25196072045472431920336519131248')
console.log(one.divide(two).divide(three))

Expected behavior
This should give me a more precise decimal. In particular, it would be nice to have at least 4 (non-zero) values in the form of a.xyz E -1000000 or something like that. Or, allow some way to alter the precision when doing division with very small numbers.

Additional context
No additional context.

Describe the bug
When rounding to 0 from a negative number like "-0.0000005", the result will be something like "-0.00"

To Reproduce
new bigDecimal('-0.05').round(0)
=> '-0'

Expected behavior
any 0 value should not have a negative prefix

new bigDecimal('-0.05').round(0)
=> '0'

Discussed in #56

[email protected] requires got@^9.6.0 via a transitive dependency on [email protected]
No patched version available for got

Hai there,

Could not able to round for the number 0.5 with precision 0 and Rounding Mode HALF_UP

Eg: var num = new bigDecimal("0.5");
var numRound1 = num.round(0, bigDecimal.RoundingModes.HALF_UP);
Expected output:1 but returning 0

Write test cases for accepting input

Raise a number to another number. Both can be non integer and cases resulting in imaginary number [like bigDecimal.pow(-21, 0.5)] should throw an error.

Describe the bug
A clear and concise description of what the bug is.

An error occurs when dividing with a number greater than 1e21.

To Reproduce
Steps to reproduce the behavior, preferably with sample code.

const data = 1e21
multiplier = new bigDecimal(Math.pow(10, 18));
console.log(data / multiplier.value)
let divideAsset = bigDecimal.divide(received.toString(), multiplier.value, 18)
console.log('divideAsset')
console.log(divideAsset)
===>
10.000000000000000000(error)

Expected behavior
A clear and concise description of what you expected to happen.
===>
1000.0000000000000000(Normal case)

Additional context
Add any other context about the problem here.

Describe the bug
Attempting to run bigDecimal.compareTo("-0", "0") returns -1, assuming -0 is lower than 0, when they are mathematically equal. This is always true, on the cases I tested, even when applying exponentials to either of the two operands.

Package version: 2.0.4

To Reproduce
bigDecimal.compareTo("-0", "0") === -1

true

Expected behavior
One would expect that compareTo would return 0 (equal) for the operations bigDecimal.compareTo("-0", "0") and bigDecimal.compareTo("0", "-0").

It is a feature, a bug or an enhancement?
This is an enhancement

Is it duplicated?
Could be related to #11.

Description:
It would be great to support rounding modes just as BigDecimal Java Library or Decimal Python Library do: (ignore ROUND_CEILING and ROUND_FLOOR, since there are already specific methods for that)

• ROUND_DOWN: Rounding mode to round towards zero.
• ROUND_HALF_DOWN: Rounding mode to round towards "nearest neighbor" unless both neighbors are equidistant, in which case round down.
• ROUND_HALF_EVEN: Rounding mode to round towards the "nearest neighbor" unless both neighbors are equidistant, in which case, round towards the even neighbor.
• ROUND_HALF_UP: Rounding mode to round towards "nearest neighbor" unless both neighbors are equidistant, in which case round up.
• ROUND_UNNECESSARY: Rounding mode to assert that the requested operation has an exact result, hence no rounding is necessary.
• ROUND_UP: Rounding mode to round away from zero.

Btw, thanks for this great library 🎉

Describe the bug
I would like to create an extension method

To Reproduce

declare module 'js-big-decimal' {
}

Fails with "is a non-module entity"

Expected behavior
A clear and concise description of what you expected to happen.

Additional context
Add any other context about the problem here.

Opening a new Issue tied to #12 (comment). The comment addresses adding Powers in addition to adding Roots.

Describe the bug
bigDecimal.divide('123456789.123456','.0123456',18)
returns 1000.006391940902021773
but should return 10000063919.40902021773

Decimal position is wrong.

Additional context
Using npm install in node; reports version 1.3.1
Was working on an translation of js-big-decimal to Lua (for Pico8) and my code returned the incorrect answer.
Verified my answer against js-big-decimal and realized I had perfectly implemented it, down to even this bug. 🐛

It should be possible to get prettyValue() based on current user locale. For example, in different countries value 4,294,967,295.00 might be presented as:

• 4 294 967 295,000
• 4,294,967,295.00
• 4.294.967.295,000
• etc (for example, https://docs.oracle.com/cd/E19455-01/806-0169/overview-9/index.html).

method "round" returns only positive results, for example:
bigDecimal.round(-0.1234, 2); returns 0.12, but not -0.12