The two packages INTEGER_UNITS and FLOAT_UNITS are so similar, it is tempting to ask, "Why not combine both into a single generic package that can be instantiated for either integers or real numbers?" I must admit I was seduced into trying this, but I quickly recognized the error of my ways and escaped from the trap. I'll show you how I started, so you won't get tricked into trying the same thing.
I wrote a generic package called NUMERIC_UNITS for a type described as private. This package could have been instantiated for any numeric type. If I did this, I would have to also supply some arithmetic operators because private types don't come with arithmetic. Part of the package specification is shown in Figure 11.
As it turns out, Figure 11 isn't very practical. Notice that I haven't supplied any default values for MIN and MAX. I can't, because numbers like integer'LAST and 1.0e25 aren't private type values. That means an instantiation would always have to supply the limits. That's a minor inconvenience. The real show-stopper, though, is an ambiguity in the division operators. If I worked long and hard enough, I think I could come up with a way to keep the division operators straight. I'd probably have to replace the "/" operators with distinct functions with names like Float_Result_Division and Integer_Result_Division and instantiate the package very carefully. The only way you can really appreciate the problem is to fool around with it yourself and see what problems you run into.
Suppose you do figure out how to get the universal NUMERIC_UNITS package to work. What have you gained? It won't do anything you couldn't do by instantiating the integer or real versions already discussed.
There is one possible advantage for combining the two package. Whenever there is a good reason to change the INTEGER_UNITS package, the FLOAT_UNITS package should probably be changed for the same reason. It might be easier to maintain the single NUMERIC_UNITS package than to maintain both INTEGER_UNITS and FLOAT_UNITS, so combining the two packages might make maintenance easier.
There are two possible disadvantages. The maintenance considerations discussed in the previous paragraph may really be a disadvantage. It might not be true that changes made to the INTEGER_UNITS package should also be made to the FLOAT_UNITS package, so coupling the two packages might cause bugs or maintenance difficulties. It will certainly be more difficult to instantiate the NUMERIC_UNITS package because of the limit and division operator problems.
The conclusion is that you waste an awful lot of engineering time (that is, money), for a questionable improvement if you combine INTEGER_UNITS and FLOAT_UNITS into a single generic package. The combined package is elegant, but elegance for elegance's sake doesn't make sense in the engineering world. It is better to keep the INTEGER_UNITS and FLOAT_UNITS package separate.