[swatcoder]

On the hardware level, your processor will have some specific behavior that it exhibits. This is sometimes configurable, in platform-specific way, and people working in low-level, high-performance numerical code already take advantage of that when it is.

If you more mean the language level, and just having two different ways to represent floating point numbers in your code, it gets a little tricky to reason about because one of those may align with what the processor is doing natively and others won't, and so you'd have a software layer converting the behavior of the platform to what your language promises -- with very high overhead sometimes and almost no overhead other times. That kind of inconsistency isn't needed very often. It can become a real headache for testing and in the wild. It's easier for a language to just say "this is the way we do floats" and you adapt as needed.

So the more typical balance is to deal with that kind of thing at the library level. If you want numbers that behave a certain way, and it's not the way your language models them, you use a library that gives you the kind of numbers you want with the tangible awareness that they're likely "soft" and less efficient in some way.