Comp's number values are not restricted to traditional hardware representations and their shortcomings. Comp numbers have huge, open ended precision with mathematical operations that do not accumulate errors. A single ~num type that represents all possible numbers.
This is somewhat of a game changer for writing code. It feels surprisingly futuristic to do things like convert between Farenheit to Celsius then back and end up with the exact same number you started with. No "approximate" results here.
It should make you wonder why anyone must tolerate (1/3)*3 != 1.0 or rounding 256.49999 to 257 in the year 2026? There is an excellent reason to tolerate these inaccuracies; Computers are astonishingly fast and efficient at storing and computing numbers. But I get the sense mostly it's because of decades of tolerating and being forced to accept.
When those come into play the language will use allocated of arrays of numbers; much like the amazing Numpy which makes storage and computation of numbers more tasteful in Python.
When interacting with legacy languages it is still useful to define numbers in terms they can understand. This is one area where Comp's limits shine brightly. I'll cover limits more in a future post, but the quick definition is that limits can be placed on defined types. A quick shape definition creates a type that can't overflow or allow lossy conversion.
!shape uint8 ~num<integer ge=0 le=255>
We'll get deeper into shape definitions later. The language does provide functions that handle lossy conversions in specific ways, and it's easy to write your own.
Comp numbers are not allowed to be illegal values (inf or nan) by default. But those can be allowed with union types where desirable.
I highly recommend Julia Evan's article that explains the how and whys of problems that will never be a problem for Comp developers.
https://jvns.ca/blog/2023/01/13/examples-of-floating-point-problems/
Top comments (0)