6 ms·

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

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 https://github.com/tc39/proposal-decimal

cogman10 5y ago
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).
- diamond_hands 5y ago
  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 :)
  - schwartzworld 5y ago
    Isn't most python just stringing together c and Fortran libraries that expose a python interface?
    - Macha 5y ago
      It amazes me at Python web engineers and Python ML engineers who go along completely unaware of the existence of the other group in any large numbers. (I say this as someone who went to my local pycon 5-6 years ago and was surprised that ML talks were like 30% of the topics)
runarberg 5y ago
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 tiny bit and never really needed it, but I kept wondering whether there were such a numeric types, and if not, what people did if they needed it.
- joppy 5y ago
  Log probabilities are used a bit for this, and most numeric packages (numpy for instance) have special functions for computing log(1+x) which are more accurate when x is tiny.
  - deleted 5y ago
    [deleted]
- 6gvONxR4sf7o 5y ago
  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))
  - runarberg 5y ago
    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.
    - 6gvONxR4sf7o 5y ago
      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.
Aardwolf 5y ago
For financial makes sense, but science should be independent of numerical base?
- ihuman 5y ago
  I think the issue isn't the base, but that Javascript stores all numbers as 64-bit floats.
  - dfabulich 5y ago
    JS has BigInt now. You can kinda fake BigDecimal with it, but none of the built-in operators will work.
    - runarberg 5y ago
      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?
      - lbussell 5y ago
        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.
        wizzwizz4 5y ago
        Yours is more space-efficient for real-world numbers.
        nine_k 5y ago
        This is basically floating-point. IEEE 754, BTW, allows for 10-based floats, but IDK if anybody uses it.
z3t4 5y ago
We also have a unix timestamp issue coming up.
xhrpost 5y ago
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.
- spankalee 5y ago
  That's not due to Node, that's due to IEEE 754 standard floating point operations.
erikpukinskis 5y ago
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?
- ranguna 5y ago
  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.

cogman10 5y ago

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

diamond_hands 5y ago
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 :)
- schwartzworld 5y ago
  Isn't most python just stringing together c and Fortran libraries that expose a python interface?
  - Macha 5y ago
    It amazes me at Python web engineers and Python ML engineers who go along completely unaware of the existence of the other group in any large numbers. (I say this as someone who went to my local pycon 5-6 years ago and was surprised that ML talks were like 30% of the topics)

runarberg 5y ago

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 tiny bit and never really needed it, but I kept wondering whether there were such a numeric types, and if not, what people did if they needed it.

joppy 5y ago
Log probabilities are used a bit for this, and most numeric packages (numpy for instance) have special functions for computing log(1+x) which are more accurate when x is tiny.
- deleted 5y ago
  [deleted]
6gvONxR4sf7o 5y ago
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))
- runarberg 5y ago
  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.
  - 6gvONxR4sf7o 5y ago
    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.

Aardwolf 5y ago

For financial makes sense, but science should be independent of numerical base?

ihuman 5y ago
I think the issue isn't the base, but that Javascript stores all numbers as 64-bit floats.
- dfabulich 5y ago
  JS has BigInt now. You can kinda fake BigDecimal with it, but none of the built-in operators will work.
  - runarberg 5y ago
    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?
    - lbussell 5y ago
      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.
      - wizzwizz4 5y ago
        Yours is more space-efficient for real-world numbers.
      - nine_k 5y ago
        This is basically floating-point. IEEE 754, BTW, allows for 10-based floats, but IDK if anybody uses it.

z3t4 5y ago

We also have a unix timestamp issue coming up.

xhrpost 5y ago

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.

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

erikpukinskis 5y ago

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?

ranguna 5y ago
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.