4 ms·

> The paper is interesting and talks about very real problems, but it's still a far cry from something that can be used in production. It’s used in production

by comex 6y ago

> The paper is interesting and talks about very real problems, but it's still a far cry from something that can be used in production. It’s used in production in the default Android calculator app. Does that not count?

qsort 6y ago
It does count, and it's certainly "points" for the ideas there (not that the author needs my validation...) But an API for a language like Java needs more generality than that. The use case was (relatively) simple, (relatively) predictable, and (relatively) self-contained. Crucially, equality in general is still undecidable (it wouldn't play nice with Collections), and it's not obvious that numerical algorithms would in general play nice with it. I'm also not really convinced that having random functions that could either terminate or not in your API is really more intuitive than floating points, but de gustibus non disputandum est. There's also the issue of performance in non-toy examples. With the world going more and more the route of ML, efficiency of numerical algorithms is not a secondary concern.
- ogogmad 6y ago
  > it's not obvious that numerical algorithms would in general play nice with it Perhaps. Some algorithms in numerical analysis are only "backwards stable" as opposed to forwards stable. This includes all possible algorithms for things like Singular Value Decomposition. See: https://mathoverflow.net/questions/369930/why-is-uncomputability-of-the-spectral-decomposition-not-a-problem https://mathoverflow.net/questions/369930/why-is-uncomputabi... > With the world going more and more the route of ML, efficiency of numerical algorithms is not a secondary concern. ML is going in the direction of very low precision floating point numbers, like 16 bit floats. High precision doesn't seem to matter there.

4 ms·

> The paper is interesting and talks about very real problems, but it's still a far cry from something that can be used in production. It’s used in production

by comex 6y ago

qsort 6y ago
It does count, and it's certainly "points" for the ideas there (not that the author needs my validation...) But an API for a language like Java needs more generality than that. The use case was (relatively) simple, (relatively) predictable, and (relatively) self-contained. Crucially, equality in general is still undecidable (it wouldn't play nice with Collections), and it's not obvious that numerical algorithms would in general play nice with it. I'm also not really convinced that having random functions that could either terminate or not in your API is really more intuitive than floating points, but de gustibus non disputandum est. There's also the issue of performance in non-toy examples. With the world going more and more the route of ML, efficiency of numerical algorithms is not a secondary concern.
- ogogmad 6y ago
  > it's not obvious that numerical algorithms would in general play nice with it Perhaps. Some algorithms in numerical analysis are only "backwards stable" as opposed to forwards stable. This includes all possible algorithms for things like Singular Value Decomposition. See: https://mathoverflow.net/questions/369930/why-is-uncomputability-of-the-spectral-decomposition-not-a-problem https://mathoverflow.net/questions/369930/why-is-uncomputabi... > With the world going more and more the route of ML, efficiency of numerical algorithms is not a secondary concern. ML is going in the direction of very low precision floating point numbers, like 16 bit floats. High precision doesn't seem to matter there.