Powers, Roots, and more

[Jsoto22]

This update allows for fractional exponents to be used in the pow method. It also adds public methods for square/cube roots, exponentiation of Euler's constant, Euler's constant as a static property, and factorials.

[Jsoto22]

@royNiladri Hope I'm not too late on this but had to work out some precision issues. They're mostly resolved, but I plan to maybe add user defined limits on the public facing method for pow. I'll try to wrap this up by finishing the unit testing tonight, then it should be ready for review.

[Jsoto22]

@royNiladri latest commit implements "UNNECESSARY" rounding mode into roundOff method

Added unit test for roots. Should close #126

Looked into #22 and have a basic plan to implement Locale Aware numbering systems. I'll open a new branch for that after the next release.

[royNiladri]

Hi @Jsoto22 You have some conflicts on this PR. I have added you as a contributor to the repository.. So you can start working on the repository directly. Create a separate branch, and merge all changes from the release branch.

[Jsoto22]

@royNiladri I fixed the conflicts directly. I had left them so you could be aware of what would change in those files. This pr should be good to go now.

[thecaligarmo]

I tried a local version of this, and there's a couple errors. For example: pow(2, 1.7) returns the wrong number.

I think the error is in line 108 of pow.ts where I'm pretty sure you want exponent = abs(subtract(exponent, remainder)).

(Or I did the local version incorrectly, which is highly likely)

[Jsoto22]

@thecaligarmo I'll look into it tonight. Funny enough, I finally had some time this weekend to fix a few other things I caught. Will get back to you on what I find.

[thecaligarmo]

Sounds good =) I think I was having issues with super large numbers too. In this case it was likely me though, but just in case, I was having issues with pow('2.56e237', '1.7') I think in this case it was a precision problem, but I wasn't sure where I messed up copying your code over.

[Jsoto22]

I was working on getting a worker instance for powers, but having trouble with that, so I stashed the changes and tested the first example you gave against Math.pow. The answer was the accurate.

I'll do some more testing with your second example and hopefully I'll push a patch tonight or tomorrow. It may well be a precision issue, but please do note that very large numbers may cause the page threat to stall out. (Working on that)

[thecaligarmo]

I was working on getting a worker instance for powers, but having trouble with that, so I stashed the changes and tested the first example you gave against Math.pow. The answer was the accurate.

I'll do some more testing with your second example and hopefully I'll push a patch tonight or tomorrow. It may well be a precision issue, but please do note that very large numbers may cause the page threat to stall out. (Working on that)

Sounds good =) I probably copied it over wrong then 😅 Thanks for double checking.

[Jsoto22]

No worries and thank you for bringing it up anyways. I'm about to push a temp patch so you can test it out. I wasn't able to stash all the changes, so there's a bit of clutter, but I commented out anything that'll interfere.

I added a script npm run start-min that'll just build and compile. It'll skip the unit testing meant for production. Keep in mind this is a development branch, so definitely not polished, and some of the equations may be off 😂 sometimes it's hard to translate them into code properly.

Known bug: cos function assigns the wrong sign (it's shifted by π/2 radians)

[Jsoto22]

@thecaligarmo you're all set 😁 don't be afraid test out all the extras and lmk if you find any bugs.

[Jsoto22]

After some testing, it was definitely an issue with the precision and an error with a condition in the nthroot approximation. The method used can blow up to infinity after too many iterations, but it's a hard condition to test for when starting with a very large number base.

You can now specify the precision after the decimal place. It's set to 32 by default.

decimal.pow('2.56e234', 1.7, {precision})

[Jsoto22]

@thecaligarmo just pushed an update that should fix the precision and accuracy issue for very large numbers. It needs testing, so I ask that if you get the chance, to try it out.

To that note, next weekend I'll clean things up and add unit testing to ensure everything works consistently.

Again, I want to thank you for bringing this to my attention! I didn't account for devs using such large numbers, and honestly, it's hard to verify the results since there aren't many ways to do so, outside of manually verifying the calculations at each step. I'll reflect this use case in my unit testing.

[Jsoto22]

@royNiladri Profile based on the most recent push. Yesterday, it was clocking in at around 2.57 seconds and I'm not exactly sure where the gains came from, but I'm personally ecstatic at how performant it is. Could have been from my computer restart earlier. The only other improvements I can think of is to store the values as a BigInt and separate value for the decimal index, so that there's fewer temporary resources used and saves time on creating them. Outside of that, I'm looking into a way to simplify how to get the Nth-Root based on the exponent's mantissa so there's no need to iterate and calculate multiple roots per iteration. Everything should be wrapped up and ready for release by the end of the year.

*I assigned the BigDecimal export to decimal in my testing file for quicker editing

[Jsoto22]

@royNiladri latest push gets UT coverage over 80%. If you could find the time, can you add tests to big-decimal.spec? Keep in mind I added quite a few stress tests, so it make take up to a couple of minutes to complete. I'll increase coverage for pow.ts in the next week.

[Jsoto22]

@royNiladri did some profiling on 10,000 divisions against decimal.js. After about 10 rounds, the new division algorithm I put together, with minor changes, is around 18.5% faster. Just about all other functions I've tested are either considerably faster or within a margin of ±5%.

The new version is looking like it'll be very competitive with the other js libraries available.

[Jsoto22]

@royNiladri @janeklb @eldereal Screenshot of initial benchmarking against decimal.js using Benchmark,js

I'll finish the benchmarks by adding all of the core arithmetic and higher order functions. I'll also include other similar libraries to the running. After so, I'll move into cleaning things up, adding comments, finishing the unit tests (they stand to be more thorough), and then updating the readme. In this, I'll ensure that any conflicts with upstream are resolved.

To finish everything up, I'd like to migrate the project from using webpack over to esbuild and tsup. I'll target ES5 but will try to make sure it works with modern frameworks like Vue 2+. Once #138 is resolved, I'll ask for a review and merge to master, then publish to NPM as a major release.

[royNiladri]

@Jsoto22 This looks great! There is another library called "big.js", we can try profiling with that as well. Yes, we need to fix the build system. We are getting some issues with Vue 2.x. Let me check if i can take this up.

[Jsoto22]

@royNiladri these are initial results. I've since made a robust benchmark system to ensure everything tested is one to one. The precision system we use is different and their equivalent functions do not convert to a string after execution like ours. I've accounted for all this though.

As for big.js, it's harder to do a equal comparison because it lack a lot of the features that decimal.js has. I won't be able to compare the 3 side by side but I can do a separate comparison. That being said, lmk what you think about creating a separate library for a light version of BigDecimal.

[Jsoto22]

@royNiladri Dropping in to give an update. I last left off finding that the current implementations, specifically the powers, can lead to an error with BigInt. I found this while working on the benchmarks and testing. It still blows my mind that BigInt has limitations to how large of a number it's willing to calculate.

I've spent this last week thinking through a new approach that splits the BigInt into chunks and started implementing it, and completed addition and subtraction. This would considerably change the library from the ground up, causing a complete rewrite, but will optimize the efficiency of the higher math functions. Internally, it'll store BigInt arrays instead of constantly converting to strings and back. I'm testing the optimal chunk size, but I've used 6 digits for testing and fisrt implementations. This can be changed to larger chunk sizes.

As a side note, I've implemented a NTT-based multiplication algorithm for testing. It's highly efficient for very large values, in the order of 100s of thousands of digits, with a complexity of O(nLog(n)). I've optimized my implementation so it's very fast compared to others found online. The ones I've tried stalls the browser before doing any multiplication, while mine can handle multiplying values with 250 thousand digits within a few seconds. Most of the time spent comes from finding a suitable prime and factorization, then converting the BigInt array into a string at the end. This can be cut back if I use predefined constants, but that limits the max digit length the algorithm can handle. Maybe a limit of 13 trillion digits for the product may be good enough, but that's not arbitrary precision 😅

I'm also looking into an implementation based on Karatsuba using the mentioned chunked value storage, but I'd like to avoid recursion if possible. It's much less complicated than the NTT algorithm, but has a complexity of O(n^1.535). This is great for values in the order of 10s of thousand of digits. I may look into implementing both algorithms, along with a naive multiplication algorithm, and switching between them depending on how large the values are.

As far as division goes, I'm sure I can find an algorithm that works with the chunked method. That'll take some time, but it'll likely follow the same principles as the current algorithm in this PR.

[Jsoto22]

Any further updates will be committed into the development branch given the drastic changes needed to get around the limitations of BigInt.