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

141–150 of 153 posts

Re: Stage 3 Proposal: Array.prototype.at

#141

Post by 6gvONxR4sf7o »

runarberg wrote: post #79
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

Honest (possibly stupid) question: Do people working on statistical and probability application never need a numeric type optimized for probability values (i.e. values between 0 and 1 that can get really close to either; for example the really almost certain value of p = 1 - 10^-13)? In the same way that financial application needs a decimal type? I’ve only worked on probability applications at a surface level for a…

This would be really nice, but the only solution I know here involves working with numbers that represent a function of p rather than p itself. And what you do depends on what you're computing. In general, you'll find lots of useful math functions that have specialized routines around zero and one, like numpy's log1p function, logaddexp, expm1, and company.

Log odds ratios are also good representations that have this kind of accuracy between zero and one. They're good when you need them. (e.g. 100:1 odds are log(100/1) and 1:100 odds are log(1/100))

Re: Stage 3 Proposal: Array.prototype.at

#142

Post by ironmagma »

cogman10 wrote: post #88
Osiris wrote: post #78

Earlier quoted context omitted.

Why does this make it a mess? Array already has a bunch of properties that aren't elements in the Array that come from the prototype, like join and slice. Your example is just adding a custom property to the array.

Because in most other languages, an array is an enumeration of values. That's it. In Javascript, arrays are actually dictionaries. But not full dictionaries, rather just dictionaries that can have either a string or numeric key. It's messy because an array in javascript isn't just "an array" it's this mismesh of features that are unexpected to a new-to-javascript developer. Unexpected is the enemy of readable code.

It’s only unexpected if you’re bringing in expectations from somewhere else. Coming from JS as basically my first language, it was surprising and a bit annoying that you couldn’t assign properties to hardly anything in other languages, even functions in languages where functions were supposedly first class.

Re: Stage 3 Proposal: Array.prototype.at

#143

Post by runarberg »

6gvONxR4sf7o wrote: post #141
runarberg wrote: post #79

Earlier quoted context omitted.

Honest (possibly stupid) question: Do people working on statistical and probability application never need a numeric type optimized for probability values (i.e. values between 0 and 1 that can get really close to either; for example the really almost certain value of p = 1 - 10^-13)? In the same way that financial application needs a decimal type? I’ve only worked on probability applications at a surface level for a…

This would be really nice, but the only solution I know here involves working with numbers that represent a function of p rather than p itself. And what you do depends on what you're computing. In general, you'll find lots of useful math functions that have specialized routines around zero and one, like numpy's log1p function, logaddexp, expm1, and company. Log odds ratios are also good representations that have this…

I see. So basically you just know a bunch of log rules and then map your distribution into a log-distribution. And I guess this becomes second nature to a seasoned statistician. So a dedicated numeric type for probability value is nothing more than a nice-to-have.

Re: Stage 3 Proposal: Array.prototype.at

#144

Post by 6gvONxR4sf7o »

runarberg wrote: post #143
6gvONxR4sf7o wrote: post #141

Earlier quoted context omitted.

This would be really nice, but the only solution I know here involves working with numbers that represent a function of p rather than p itself. And what you do depends on what you're computing. In general, you'll find lots of useful math functions that have specialized routines around zero and one, like numpy's log1p function, logaddexp, expm1, and company. Log odds ratios are also good representations that have this…

I see. So basically you just know a bunch of log rules and then map your distribution into a log-distribution. And I guess this becomes second nature to a seasoned statistician. So a dedicated numeric type for probability value is nothing more than a nice-to-have.

Kinda, but to make it more explicit: with floating point numbers you don't even need the explicit log distribution because it's kinda baked in already, with the number split between an absolute and an exponential part. So floats capture an exponential scale of precision naturally, allowing you to write 1e-200 and 1 and 1e200 just as easily, with a common relative precision around each. You use the log scale as a mental model and then just keep floating point issues in mind while you work.

The handy functions are more about making sure that cancellations don't happen by providing a few primitive operations that cover lots of the uses. Like the handy log1p which computes log(1+x). If you did this with the log function, you'll compute log(1+1e-200)=log(1)=0. If you use log1p, you get log1p(1e-200)=1e-200. You avoid the loss of info that comes with adding something close to zero to something that isn't close to zero, which is the real trick. And then if you need something close to one, you probable just use the converse: instead of using p=1-eps, you just work with eps itself.

Re: Stage 3 Proposal: Array.prototype.at

#145

Post by 11235813213455 »

11235813213455 wrote: post #91

This will be handy for a multitude of string libs, for example string diffing (fast myers diff, ...)

Oh actually I thought '\u{1f4a9}'.at(0) === '\u{1f4a9}' but np, after reading the docs, it's just like charAt except for negative indices

Quite disappointed so, my parent comment doesn't stand too

Re: Stage 3 Proposal: Array.prototype.at

#146

Post by alerighi »

johnfn wrote: post #102
beaconstudios wrote: post #37

const at = (arr, i) => i >= 0 ? arr[i] : arr[arr.length + i]; Why does the core language need to be extended to incorporate this?

Subtle readability improvements on patterns that see extensive use actually make a difference. I had the exact same thoughts when `.includes()` was proposed to be added to the spec - it's just `.indexOf() !== -1`! - but time has proven me wrong, and I suspect it will prove us wrong about `at` as well. I've written an `.indexOf() !== -1` check hundreds if not thousands of times, and I've gotten the conditional wrong e…

Except you would never get to use this method, because it will take years for all browser vendors to implement it, and even then, you still have a number of users that use for a reason or another Internet Explorer.

You need to use a transpiler (like Typescript), but at this point, there no reason to implement that in the language, a transpiler can implement the feature by simply adding the method to the prototype of the object, like this:

    Array.prototype.at = function (i) { return i

Re: Stage 3 Proposal: Array.prototype.at

#147

Post by spankalee »

xhrpost wrote: post #135
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

Very good point. I'm just now fully understanding why at my last fin-tech job we stored all monetary amounts in pennies. I thought at first it was just ideal to keep everything as integers in the database but I see now that due to our Node backend, something as simple as 0.20 + 0.10 could pose a problem.

That's not due to Node, that's due to IEEE 754 standard floating point operations.

Re: Stage 3 Proposal: Array.prototype.at

#148

Post by borschtplease »

beaconstudios wrote: post #55
zodiakzz wrote: post #51

Earlier quoted context omitted.

Reinventing the wheel is error prone. Noone wants to bloat their code/time with unit tests for all these utility methods. Just look at your at() function, I already spotted a bug, if a numeric string is passed: `([].length + '-1') === '0-1'`

yes that is obvious - my point was that the functionality is minimal. with guards: const at = (arr, i) => { if(!(Array.isArray(arr) && typeof i === 'number')) { throw new Error('invalid arguments'); } // same as before }; you wouldn't just commit a single-line function in your code. But there are 10,000 micro-functions that could be in the core of JS. Why bother to add this, especially if it's so easy to implement? T…

I want you to look at some other languages beside javascript. Take a look at Swift or Ruby. Compared to them it feels like 60% of js code is boilerplate. 200 lines of js can be fit in 60 lines of Swift. All because js stdlib is just sucks. I’m tired of this silly ‘someArray.length ? someArray[someArray.length - 1] : null’, I want just ‘someArray.last()’

Re: Stage 3 Proposal: Array.prototype.at

#149

Post by erikpukinskis »

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

What would the benefits of a language native implementation be, over something like decimal.js?

Is it just a matter of there being a "blessed" implementation for folks to standardize around?

Re: Stage 3 Proposal: Array.prototype.at

#150

Post by ranguna »

erikpukinskis wrote: post #149
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

What would the benefits of a language native implementation be, over something like decimal.js? Is it just a matter of there being a "blessed" implementation for folks to standardize around?

Universal support for third party integrations such as connecting with a database that allows for arbitrary precision decimals, communicating with other services without forcing a use of a random lib (because there are many that do this kind of thing).

Support for this I believe is "low level enough" to ve implemented natively, it's not something like protobuf.

Post reply on HN