Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Replace built-in types? #57

Open
Bessonov opened this issue Aug 2, 2020 · 4 comments
Open

Replace built-in types? #57

Bessonov opened this issue Aug 2, 2020 · 4 comments

Comments

@Bessonov
Copy link

Bessonov commented Aug 2, 2020

Be aware: it's not a concept, but just a raw idea. Because IEEE 754 isn't precise for relevant extent anyway, may be it's better to replace the built-in type(s) under the hood with sensitive defaults. The current way to deal with integers, floats, BigInt doesn't feel right from mathematical (try to explain 0.1 + 0.2 to non-technician) or syntax (n? d? Or p?) views. I'm not sure why developers should even care about it, except of some edge cases. It should "just work".

For example,

  • lets define default precision after point to 17 (taken from 0.1 + 0.2 = 0.30000000000000004, I guess 17 decimal digits for binary64), which would be used for division.
  • lets define that no explicit suffixes like n or classes like BigDecimal/BigInt are needed. Just use +, - and other already known operations.
  • lets define that default .toString() returns only significant numbers (strip all tail zeros). For example: console.log(0.1 + 0.2) prints 0.3 and console.log(0.1010) prints 0.101.

Now tricky part.

Custom printing: console.log(0.1234000.toString({rounding: Number.Rounding.Scientific})).

Rounding: 0.1234.round(3, Number.Rounding.HalfUp).

Converting: 0.1234.toBase(2), 0.1234.toHex().

Division with custom precision. This is a hard one. May be like 1.div(3, 17) or 1 /17 3. The last one can leads to errors. But we have already something like with regexp: /^\d+$/.test('123'). And in most cases there is no need to change the default anyway.

Above examples are not consistent and are, well, just examples. I like to pass Objects as args, because it's more readable, but often people like indexed arguments.

I'm also aware that it would be a very large breaking change in sense of semantic. But in my opinion it's very important that math operations work in a (more) predictable way.

What do you think about it?

@munrocket
Copy link

Computers don’t work in base10 arithmetic and programmers don’t care about non technicians. If you will do any computation in base10, libraries like three.js will be slow.

@Bessonov
Copy link
Author

Computers don’t work in base10 arithmetic

That's fine.

programmers don’t care about non technicians

That's not true. In fact, programmers care much about non technicians and often about other programmers. Did you use any software where you was forced to enter data in base2? Beside some cases, as a programmer, you use const x = 10 and not like const x = 1010b. A notable exception is color with 3x base16.

But this isn't topic to discuss in this proposal. Bitwise operations and conversions are fine. But naïve reliance on floating point arithmetic is bad, very bad. BigInt makes this situation even worse, because it introduces/reserves new syntax and takes only integers into account. It's hard to find use cases in real world applications. But there endless cases for decimals.

This proposal is about fixing the number type in the - from my(!) point of view - right way.

@munrocket
Copy link

This is a breaking change. Web usually doesn’t break things. Also https://0.30000000000000004.com/

@Rudxain
Copy link
Contributor

Rudxain commented Apr 25, 2022

Another "problem" is that Number static constants should be updated, which is probably the purpose of those constants being defined as static properties, which allows code to future-proof itself. But most minified pages and even non-minifed source files rely on these constants to be permanent, which means this is still a breaking change. A solution would be to make it more subtle, in the same way engines optimize Numbers by transparently storing them internally as Int32 and Uint32 when possible, so this "precision upgrade" isn't something that should be implemented by this proposal in the lang directly, but rather should be implemented by JS engines since the ES spec explicitly allows implementation-defined accuracy

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants