Since I use a package called STANDARD_INTEGERS, it is logical for you to assume I have also written a package called STANDARD_FLOATS with data types Float_7 and Float_15 defining seven- and fifteen-digit real numbers. I haven't and don't intend to, because I don't think it is a good idea. To explain why, I need to tell you a little personal history.
I went to school long ago, in the years B.C. (Before Calculators.) In those days you could easily spot an engineering student by the slide rule dangling from his belt like a sword. The slide rule was his weapon for slaying the dragons he encountered daily. It was a mechanical device with numbers and lines etched on it, which was used for multiplying, dividing, and computing trig functions. It gave three digit accuracy, and you had to keep track of the exponent in your head.
Three digits let you express numbers from 00.0 to 99.9, so the best accuracy you could get from a slide rule was 0.1%. That never bothered civil engineers when they calculated the maximum load a bridge could stand, because they knew better than to design the bridge with only a 0.1% safety factor. The limited accuracy of calculations forced engineers to be conservative, and use a little bit of common sense.
I fear that younger engineers, lacking that heritage, have gone digit crazy. A fourteen-digit calculator has a subtle way of seducing people into unrealistic conclusions.
Ada's predefined type float can be any number of digits selected by the implementer. Generally hardware considerations or software compatibility issues limit the available choices. For example, VAX/VMS has standard floating-point representations which are 6, 9, 15, and 33 digits of precision, so Ada maps all user-defined floating- point types onto one of those representations.
I have not yet found an implementation that uses fewer than 6 digits for the predefined type float. I maintain that 6 digits is plenty of resolution, and I am skeptical of designs that claim to require more.
Suppose we want to represent angles in degrees using floating-point numbers. If we use 6 digits of resolution, we need 3 digits to represent whole degrees up to 360, leaving 3 digits for fractional degrees. Angles can be resolved to 0.001 degree. Will this precision yield good enough accuracy? In real applications it better.
Let's say that you are using these angles in some avionics software that slaves the infrared seeker on a missile to a position determined by the aircraft radar so the missile can lock onto the target. If this system requires 0.001 degree accuracy to work, it means that the radar and missile pylon have to be aligned to the aircraft body to within 0.001 degree. Do you think a sailor on an aircraft-carrier (who has been on combat alert and hasn't had much sleep lately) can do that on a rolling aircraft carrier deck in a few minutes? Even if he can, will it still be aligned after a catapult launch and an arrested landing? Don't kid yourself. If you design a system that can't tolerate 0.001 degree error, it is never going to work in combat.
Can anyone argue that it is ever necessary to compute the sine of an angle to 15 decimal places? Sines are used as scale factors. For example, DISTANCE_NORTH := RADIAL_DISTANCE * Cos(BEARING);. Does the scale factor really need to be accurate to 0.000_000_000_000_1 %? Was RADIAL_DISTANCE measured to that accuracy? Care to figure out how accurately you have to measure the BEARING to maintain that accuracy?
The reason I don't have a STANDARD_FLOATS package is that I don't believe in designing programs that need floating-point numbers with better resolution than 1 part per million. There may be applications in research laboratories that need higher precision, but in my applications the input data is only good to "slide rule accuracy." I use the default type float because the compiler has probably selected the representation that gives the fastest computational speed.