rudxain / eso-math.rs

(WIP) Esoteric Mathematic Library for Rust

EsoMath

Warning

I'll RIIR! You can find the JS in this branch

Most math libs are focused on arithmetic and algebra, and practical applications like cryptography. This lib is targeted at Pure Math, Number Theory, and recreational math.

eso-math.rs's Issues

Focus on minimalism

I'm removing a lot of features, to make development easier, and to reduce redundancy (because other libraries already include those features)

Fix `toFraction` and make use of it

The function should return the smallest fraction that when converted to Number yields exactly the same value as the original input, but some inputs cause it to loop too many times and return a bogus fraction. After fixing the bug, I plan on using it in Math.gcd to preserve precision of computations, and Math.factorize to get negative exponents

Make `isPower` use a quasi-linear time algorithm

The paper "Detecting Perfect Powers in Essentially Linear Time" shows that there is a better way to check if n is a perfect power

Add missing step in `divisors`

There's missing multiplication and insertion at the end of the function. This step is required to include all even divisors and powers of 2

Fix `NaN` when using `Math.mod(x, Infinity)`

This is just to make it consistent with the remainder % operator

Add `modInv` and `egcd`

Add Modular Multiplicative Inverse, and Extended Euclidean Algorithm. modInv is useful to avoid wrong return values in Math.modPow

Add rising and falling Factorials

Fix `modpow` memory use

The IntN version has potential for avoidable out of memory errors when e < 2, while the Math version doesn't preserve precision when the exponent isn't an integer (there's no "modular multiplicative inverse" to correct this)

Add test files

Even if the tests will be ran manually, there must be a test file to increase code coverage. This is a serious library, no bugs should be allowed

Replace `IntN.parse` by `BigInt.fromString`

https://github.com/tc39/proposal-number-fromstring

Decide to merge or separate all `mod` variants

I don't know whether modulo fns should have a param to select a variant, or if each variant should have its own independent function. The JS trend seems to be that they should be separated.

Related

Add more JSdoc where needed

Use JSD for param type annotations (and API documentation, obviously)

Fix `isFinite` minor bug

There's wrong output when strings are large. This is a minor bug because the original/built-in also has it, so this has the lowest priority now

Consider renaming radian conversions

See this

TLDR: radToAngle may not be a good name

Use Inverse Gamma Function in `factorial_inv`

This would extend the input and output domain to the Reals instead of just Ints

Use decorators

Decorators are functions that wrap other functions, essentially acting as functions that construct other functions. These are useful to apply common/shared behavior to many fns

add Kaprekar's routine

https://en.wikipedia.org/wiki/Kaprekar%27s_routine

Fix `IntN.parse` radix param precision loss

This has the lowest priority because radix is usually small (and should be), any absurdly large (2^53) BigInt or String value given to it is considered a misuse or an accident by the user or developer and I have no responsibility for that

Localize all vars

Prevents external code from changing the behavior of the library by modifying property values of global objects that some functions depend on. This means using aliases to objects, and copying primitive values

Simplify `root`

That function is madness

Add deterministic primality tester

This is useful for fast generation of random primes. I still need to search for a nice algorithm that runs in polynomial time

Fix "." error in `IntN.from`

When input strings have 1 "." (dot), it throws, even though it should be more flexible

Test Workflow

This is a nice idea for automated testing, and would help to reach 100% code coverage. It's also a win-win situation for everyone using this lib and myself, since I won't need to install it on my system. lol I'm so lazy.

I'll activate the workflow after migrating everything to ESM format

Avoid mismatch-type errors, where possible

Fix thrown exceptions that occur when args are not of the same type. Like in factorial

add prod dig-sum & rev-dig-sum

https://www.geeksforgeeks.org/check-product-digit-sum-reverse-equals-number-not

Smarter min/max

It should return Number type only if it's a safe number, otherwise BigInt type, and only do that if there's multiple valid choices available

What should be the future of this library?

(More info at #2 )
I'm concerned about the future of this library because I want to take it seriously, but I feel like I don't know if the direction I'm going is a good goal.

This library started like my "Useless-Math" repo, just a bunch of functions lying around, and there was no clear direction to take. Then I realized what direction I wanted to take, I wanted this to be a polyfill. But polyfills are usually meant to be used in websites, and this library is definitely not a good idea to use in a website, but I already stated that in the README disclaimer. So now I'm wondering in what should this be focused on?

Name is not unique

The name NTML is already in use by an NPM package and by Microsoft. I should rename (again)

Add Generalized Mean

See

Add Dot Product?

This seems like a basic function to have, but I don't know if it should be added to this library

Move polyfills to a new repo

They don't belong here.

#32

Make `IntN.factorial` even more efficient

This document: http://www.luschny.de/math/factorial/FastFactorialFunctions.htm , and this repo: https://github.com/PeterLuschny/Fast-Factorial-Functions , show that my implementation is kinda slow, lol

`Numeric.root`, `Math.randomSafeInt` and etc, are incapable of returning -0

This isn't an important problem, but causes inconsistency between my library and the IEEE 754 standard

Move To-Dos and bugs to Issues

Add PowerSet?

I don't know if this should be implemented only on Set.prototype, or if I should also add it to Array.prototype, or maybe not add it at all. Is this actually useful in JS?