Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Stage 3 Proposal: Array.prototype.at

tc39.es

Post reply on HN
Print view View original

111–120 of 153 posts

Re: Stage 3 Proposal: Array.prototype.at

#111

Post by diamond_hands »

cogman10 wrote: post #72
dlojudice wrote: post #33

JS urgently needs support for decimals [1] and thus be able to enter sectors such as scientific and financial. V8 + dynamic language + better math support = perfect environment for many applications out there [1] https://github.com/tc39/proposal-decimal

Couldn't that be done with WASM today? It looks like a few people have managed to build GMP targeting WASM. You might miss out on some SIMD operations, but you'd be able to do 90% of what you'd want with scientific calcs. (admittedly, it'd be nice if this were part of the language).

There's still a ton of overhead for WASM and it's not first class. Using WASM is a lot like using C code in python. It's still nice to have features as first class citizens :)

Re: Stage 3 Proposal: Array.prototype.at

#112

Post by [deleted] »

antris wrote: post #110
inbx0 wrote: post #104

Earlier quoted context omitted.

That will break with > Uncaught TypeError: Cannot convert undefined or null to object because `myObjectArr.at` doesn't bind `this` to `myObjectArr`. When the internals of `map` call the `at` function, `this` is just `undefined` instead of the original array and it'll throw. Luckily Array.prototype.map takes a second argument just for this purpose indices.map(myObjectArr.at, myObjectArr)

Oh wow, I had to try it to make sure. I can't believe how broken the fundamentals of JS are. There should really be a whole new standard library made from ground up without `this`, mutability and all the other legacy stuff.

[deleted]

Re: Stage 3 Proposal: Array.prototype.at

#113

Post by runarberg »

dfabulich wrote: post #101
ihuman wrote: post #95

Earlier quoted context omitted.

I think the issue isn't the base, but that Javascript stores all numbers as 64-bit floats.

JS has BigInt now. You can kinda fake BigDecimal with it, but none of the built-in operators will work.

How do you fake BigDecimal with BigInt? My immediate intuition would have a 3-tuple (a, b, c) which would construct the decimal with a representing the numbers before the decimal separator, b the number of zeroes immediately after the decimal separator, and c the numbers after the zeroes. e.g. 1.000054 would be represented as `[1n, 4n, 54n]` and 3.14159 as `[3n, 0n, 14159n]`.

Is there a better way?

Re: Stage 3 Proposal: Array.prototype.at

#114

Post by lbussell »

runarberg wrote: post #113
dfabulich wrote: post #101

Earlier quoted context omitted.

JS has BigInt now. You can kinda fake BigDecimal with it, but none of the built-in operators will work.

How do you fake BigDecimal with BigInt? My immediate intuition would have a 3-tuple ( a , b , c ) which would construct the decimal with a representing the numbers before the decimal separator, b the number of zeroes immediately after the decimal separator, and c the numbers after the zeroes. e.g. 1.000054 would be represented as `[1n, 4n, 54n]` and 3.14159 as `[3n, 0n, 14159n]`. Is there a better way?

What about a 2-tuple with two numbers, one being the BigInt and one being the exponent. So 1.000054 would be (1000054, -6) = 1000054*10^(-6).

Yours is probably more space efficient though.

Re: Stage 3 Proposal: Array.prototype.at

#115

Post by Pxtl »

ZephyrBlu wrote: post #12
Pxtl wrote: post #8

Earlier quoted context omitted.

Imho that violates the principle of least astonishment - that "at" would have such different behavior from "[]" for negative numbers.

That's the whole point of this though... Currently you can't use negative indexes, but this would make them usable.

Oh, I'd assumed main point was to provide a composable function.

Re: Stage 3 Proposal: Array.prototype.at

#116

Post by schwartzworld »

diamond_hands wrote: post #111
cogman10 wrote: post #72

Earlier quoted context omitted.

Couldn't that be done with WASM today? It looks like a few people have managed to build GMP targeting WASM. You might miss out on some SIMD operations, but you'd be able to do 90% of what you'd want with scientific calcs. (admittedly, it'd be nice if this were part of the language).

There's still a ton of overhead for WASM and it's not first class. Using WASM is a lot like using C code in python. It's still nice to have features as first class citizens :)

Isn't most python just stringing together c and Fortran libraries that expose a python interface?

Re: Stage 3 Proposal: Array.prototype.at

#117

Post by wizzwizz4 »

lbussell wrote: post #114
runarberg wrote: post #113

Earlier quoted context omitted.

How do you fake BigDecimal with BigInt? My immediate intuition would have a 3-tuple ( a , b , c ) which would construct the decimal with a representing the numbers before the decimal separator, b the number of zeroes immediately after the decimal separator, and c the numbers after the zeroes. e.g. 1.000054 would be represented as `[1n, 4n, 54n]` and 3.14159 as `[3n, 0n, 14159n]`. Is there a better way?

What about a 2-tuple with two numbers, one being the BigInt and one being the exponent. So 1.000054 would be (1000054, -6) = 1000054*10^(-6). Yours is probably more space efficient though.

Yours is more space-efficient for real-world numbers.

Re: Stage 3 Proposal: Array.prototype.at

#118

Post by wizzwizz4 »

dmitriid wrote: post #107
Fire-Dragon-DoL wrote: post #47

Earlier quoted context omitted.

Isn't Windows even more epic?

Windows is very epic, but they did break compatibility a few times: the new driver model since Windows 7 (?) for example. The Web probably has a longer history of not breaking things, but also has a smaller feature set to keep track of than Windows. All in all, very hard to compare. But both undoubtedly epic.

The new driver model is Vista-era, I think.

Re: Stage 3 Proposal: Array.prototype.at

#119

Post by xdennis »

Phenix88be wrote: post #9

So instead of fixing the language and allow to use array[-1], they add an other way to access array element. This is why I don't like JavaScript, instead of fixing feature, they add new feature to fix previous feature.

> fixing

I dislike the abuse of this word. Lacking some shorthand notation doesn't make the language "broken".

It reminds me of handling support tickets where clients say "X needs to be urgently fixed" even though X has never been possible. (Should it? Often yes, but it doesn't mean it's broken.)

Re: Stage 3 Proposal: Array.prototype.at

#120

Post by chrismorgan »

zodiakzz wrote: post #67
chrismorgan wrote: post #62

Earlier quoted context omitted.

Quite incidentally, this is fixed with the addition of one character: const at = (arr, i) => i >= 0 ? arr[i] : arr[arr.length + +i];

Nit: it throws if you wanna use a negative bigint as `i` hehehe :( let i = -1n; let test = +i; > Uncaught TypeError: can't convert BigInt to number See this is where standard libraries shine, they consider all the pieces of the puzzle. There's no good reason to disallow bigints here. P.S: Unary plus operator is neat but this TypeError with BigInt is why I am starting to prefer the more verbose `Number(i)`.

Hmm, I had completely forgotten about that distinction. I also can’t find it in the spec https://tc39.es/ecma262/>, which says that Number “performs a type conversion when called as a function rather than as a constructor.” https://tc39.es/ecma262/#sec-number-constructor>. What this means isn’t spelled out, which seems poor. I would have thought it meant ToNumber https://tc39.es/ecma262/#sec-tonumber>, but that would throw an exception on BigInt (like unary plus does, https://tc39.es/ecma262/#sec-unary-plus-operator>). So now I’m guessing it means ToPrimitive https://tc39.es/ecma262/#sec-toprimitive> with preferredType number, which seems to match. This being the case, I believe BigInt is the sole difference between +x and Number(x).
Post reply on HN