Why do programming languages usually not implement number types with units?

  • Thread starter Thread starter elcaro
  • Start date Start date
  • Tags Tags
    Programming Units
Click For Summary
SUMMARY

The discussion centers on the lack of built-in number types with units in most programming languages, with Frink being a notable exception. Participants argue that while some languages like C++ allow for user-defined implementations, such as classes for unit handling, the complexity and computational expense of integrating units directly into the language often outweigh the benefits. The consensus is that unit management is better suited for libraries or domain-specific languages, which can cater to specific application needs without complicating general-purpose programming.

PREREQUISITES
  • Understanding of programming languages and their type systems
  • Familiarity with unit conversion concepts in programming
  • Knowledge of domain-specific languages (DSLs) and their applications
  • Experience with class design and implementation in languages like C++ or Groovy
NEXT STEPS
  • Research Frink programming language and its unit handling capabilities
  • Explore the implementation of unit conversion classes in C++
  • Learn about Groovy's domain-specific languages for practical applications
  • Investigate libraries for dimensional analysis in scientific computing
USEFUL FOR

Software developers, particularly those working in scientific computing, educators in programming languages, and anyone interested in the design of type systems and unit management in programming.

  • #61
Vanadium 50 said:
Why?

Why is arithmetic used in error propagation different from any other use of arithmetic?
As an example, some compilers/platforms have compiler flags to do reduced precision floating point operations or approximations.
 
Technology news on Phys.org
  • #62
You're talking about significant figures, which is a quick-and-dirty reflection of real error propagation. If you build that into your intrinsics, won't it make it that much harder to program in the more correct procedure?

I confess that I find the logic of this thread puzzling. What is proposed can be done in various flexible languages. But no, that's not good enough. It has to be by changing how the language deals with intrinsic types, often in incompatible ways.
 
Last edited:
  • Like
Likes   Reactions: pbuk
  • #63
Jarvis323 said:
I agree it is not trivial. Usually it is the work of mathematicians to apply theory based on the numerical algorithms, to get error bounds on things like matrix operations.
Yes. Things - again! - burns down to the 'engineering' part of the software development.

Jarvis323 said:
But then you also have the issue that high level code may not compile to what you expect.
Quite a bullseye. All these fancy additions/modifications would be a nightmare to validate.
 
  • #64
Vanadium 50 said:
won't it make it that much harder to program in the more correct procedure?
I guess I'm talking more about what a floating-point represents versus an integer.

Math with integers is easy: 1 is exactly 1, 3 is exactly 3, thus ##\frac{1}{3} = 0.\bar{3}##. It works very well in theoretical work.

But with more practical problems, you rarely work with such certainty. You deal with some level of precision and you have 2 limits: the significand length that the program can handle and the precision of the inputs. You cannot escape the former but, somehow, nobody cares about the latter. To me, ##\frac{1.0}{3.0} \neq \frac{1.00}{3.00}## and neither of them is equal to ##0.\bar{3}##. I would at least expect an answer that doesn't have more than 2 or 3 significant figures. But to be able to perform other calculations, having the error following the number is crucial.

It would be nice if a computer program could keep track of this throughout its calculations. So a floating-point would store a significand, an exponent, and an error.
 
  • #65
So in summary, we have the following requirements for floating point numerics:
  1. they should have unit information attached so we can't add feet to metres
  2. they should have dimensional information attached so we know that a velocity times a time is a distance
  3. they should have physical information attached so we can't add a torque to an energy
  4. they should have measurement error attached (according to what standard?) so we can present results appropriately
  5. they should have round-off error attached so we can track its propagation
  6. they should have truncation error attached so we can track this without having to understand the underlying algorithm (nobody mentioned this but I thought I'd add it for good measure)
I think it should now be obvious why these requirements are not implemented in general purpose languages, however subsets of these requirements are implemented in certain special purpose languages and also in modules for certain general purpose languages. Also, where a system is highly specialised and safety-critical, the general features of many special purpose languages can be used to implement numeric classes implementing whatever subset of these features is appropriate.

Mods, are we done?
 
  • Like
  • Sad
  • Skeptical
Likes   Reactions: Jarvis323, BvU, jack action and 1 other person
  • #66
pbuk said:
Mods, are we done?
Seems like it to me ...
Thread closed
 
  • Like
Likes   Reactions: BvU

Similar threads

Replies
86
Views
2K
  • · Replies 25 ·
Replies
25
Views
871
Replies
4
Views
2K
  • · Replies 2 ·
Replies
2
Views
2K
  • · Replies 6 ·
Replies
6
Views
2K
Replies
65
Views
5K
Replies
81
Views
7K
Replies
3
Views
2K
  • · Replies 15 ·
Replies
15
Views
4K
  • · Replies 8 ·
Replies
8
Views
3K