rudxain / esomath.js

Esoteric Mathematic Library for Javascript (past names: more-math-for-JS, mostly_math, NTML.js)

Me

Stats

Get cards like this one!

Personal

• Have an "obsession" with code refactoring. It's obvious from my GH activity 😂
• Considering moving to GitLab, for many reasons. The fact that GL nukes dead accounts is a deal-breaker for me. I've just learned about Code-Berg, it seems interesting.

Repos

• When my PRs are merged, I'll delete my corresponding fork. Therefore, links to any of my forks may be broken (not dead, because it's not permanent) in the future. The exception is .files
• I could delete any of my Gists without warning
• All my repos use semver, except the ones that don't use versioning at all
• If I contribute to any of your repos, I hope you do the same for me and/or other people :)

Langs

❤Favorites, in practice:

This takes into account all the stuff related to the langs (portability, std+community tools & libraries, ecosystem, documentation, etc...)

0. Python
1. JavaScript
2. 🦀Rust
3. POSIX Shell

One of the things I love about Rust is its honesty: Rust has abstractions (like any other lang), but they are leaky by design.

Rust [is] both as low-level as C, and as high-level as Lisp, whereas most other popular languages are stuck somewhere in the middle.

❤Favorites, in theory:

This only takes into account the langs in isolation (syntax, grammar, stdlib, etc...)

0. 🦀Rust. For everything.
1. Python. For expressing algorithms, because "haha, pseudo-code".
2. Any lang that uses symbols rather than words (such as BrainFuck dialects), specially if the symbols have shapes that intuitively correspond to their operation.

My favorite argument against Python's colons is this:

The colons are an extra visual clue to scanning the blocks. As such, they improve readability, one of Python's main strengths.

Then Opening and closing braces should be called an "extra visual clue to scanning the block" in C++ and Java? Because they improved readability. Braces ({) then is C++, Java's main Strength.

As a logician, I love the way they point out the fallacy!

🧠Expertise:

Warning

this is subject to the Dunning-Kruger effect 😂 I'll try my best to list in an accurate order

This takes into account my knowledge of the lang (and everything related), and the experience making useful, efficient, and safe programs in it.

0. Java Regular Expressions (I'm expert at optimizing them), CSV (any "dialect"), JSON
1. 🦙Llamalab Automate. I know more about expressions than blocks
2. Scratch
3. JavaScript
4. TypeScript
5. POSIX shell
6. MirBSD Korn Shell, ksh93, Dash
7. Bash
8. Python
9. SVG ("subset" of XML)
10. HTML
11. CSS
12. 🦀Rust
13. C
14. C++
15. Go
16. BrainFuck

👀Interested:

0. 💾Assembly
1. V
2. APL
3. (Common Lisp)
4. 🕊Ada

Editors

Helix ❤

I have experience with VScode and GNU Nano

OS

❤Favorites:

0. Debian
1. Android
2. Microsoft Windows

🧠Expertise:

0. Android 4 to 8.1, and 12. (0 experience with A[9, 11]). Most of my experience was from using TouchWiz, Samsung Experience, and OneUI. I do have some experience with AOSP (0 Gapps)
1. Debian-based Linux distros
2. ChromeOS. I have minimal knowledge about its internals. I know that most apps aren't native, but are powered by HTML+CSS+JS.
3. Microsoft Windows XP, [7, 11] (I haven't touched Vista 💀). Despite using it my entire life, this beast is so bloated/complex that I know less than ~20% about it.

👀Interested:

0. Redox
1. Nix
2. G Fuchsia

Browsers

• Favorite (in practice): Mozilla Firefox
• Fav (theory): LibreWolf

I also have expertise with Chromium-based browsers.

Terminals

• Linux: GNOME Terminal (not Console)
• Android: Termux

esomath.js's Issues

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

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

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?

Move To-Dos and bugs to Issues

Use Inverse Gamma Function in `factorial_inv`

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

Fix "." error in `IntN.from`

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

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?

`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

Simplify `root`

That function is madness

Add Dot Product?

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

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

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

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

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

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

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

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

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

Move polyfills to a new repo

They don't belong here.

#32

Avoid mismatch-type errors, where possible

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

Name is not unique

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

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)

Add more JSdoc where needed

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

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

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 `modInv` and `egcd`

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

Consider renaming radian conversions

See this

TLDR: radToAngle may not be a good name

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

Add rising and falling Factorials

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

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

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 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

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

Add Generalized Mean

See