Integers - how ought they work?

This is a very interesting post. Thank you for sharing.

(It is impressive how much new thought and new knowledge the Futhark designers are consistently generating!)

whenever the “mathematically correct” result is not representable in the chosen type, an error is signalled somehow

Overall, Futhark is caught in an awkward tension between performance and correctness, and since it is a language that aspires to both, how is the tension to be resolved?

It is not surprisingly to me that general purpose programming languages tend to be quite successful, even though they predominantly implement only “pseudo-” (“non-algrebraic”?) mathematical functionality. After all, the mathematics they implement are sufficiently “correct” and predictable within the very narrow domain of what most programmes want to do with them: e.g., pointer arithmetic, array indexing mechanics, structure size operations and comparison, &c.

Where these mathematics are insufficient for someone's work, it seems like the response is usually to extend the language to support enough mathematics sufficient for high-performance numerical computation (which usually is focused more on performance than correctness.)

Consider Python, for example, whose builtin int automatically promotes, but whose users routinely trade it (and standard library modules like statistics) for numpy.ndarray (and associated libraries like scipy and statsmodels) that provide mathematics with a mix of wrapping, erroring, and promoting behaviours. It is quite comparatively rare for someone dissatisfied with Python's built-in mathematics to trade them for sympy (or even Decimal)—the dominant desire is performance not correctness.

I don't mean to imply that the original NumPy, numarray, or numeric core developers were disinterested in “correctness” but simply that they were primarily interested in performance constrained by just enough predictable correctness to accomplish numerical analysis tasks.

I would be very interesting to hear the Futhark developers contrast their perspective on correctness against that taken by tools like LFortran and NumPy.

Clearly, many users are satisfied with the compromises that these tools make—but what do users who are dissatisfied look like? (e.g., in my experience, a lot of issues people have with IEEE-754 floating point semantics are sometimes a result of their own missteps, such as a recent issue where an apparently cent-denominated financial metric was stored as a floating point value, summed, did not net to zero, then caused quantitative differences in a report. The problem here is much more pernicious…)