Replace built-in types? #57

Bessonov · 2020-08-02T00:38:52Z

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?

The text was updated successfully, but these errors were encountered:

munrocket · 2021-09-12T11:28:26Z

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 · 2021-09-12T12:38:22Z

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 · 2021-09-12T12:59:48Z

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

Rudxain · 2022-04-25T15:50:13Z

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

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Replace built-in types? #57

Replace built-in types? #57

Replace built-in types? #57

Replace built-in types? #57

Comments