The typical representation of common numbers (integer, decimals, and floats) seems kind of arbitrary and hardware-centric to me. Thus, I'm kicking around a better way to specify such. Here's some starting brainstorming:

I propose that there be just two basic types: decimal and floating. Here are the specification parameters for each:

'''Decimal'''

* Number of decimal places.
* Min and max range. Ex: -9999.999 to 9999.999

"Integer" would simply be zero decimals. '''The number of bytes needed would calculated'''. 

An alternative approach would be to specify the number of bytes used, and the min/max would be a resulting property of that. However, the disadvantage of this is that we could not get savings via lopsided ranges, such as a positive-only number. Knowing that negative numbers will not be used could save a few bits.

'''Floating'''

Either the number of bytes devoted to the number would be specified (including odd numbers), or the number of mantissa digits in terms of decimal digits or binary digits. For systems that don't allow odd number of bytes, the byte number would be internally rounded up. Thus, here are the sub-options:

* Number of bytes
* Number of mantissa digits in decimal digits (bytes consumed calculated)
* Number of mantissa digits in binary digits (bytes consumed calculated)

If we really want to get generic, then perhaps the concept of "bytes" should be tossed such that we are only dealing with binary digits for sizing. But, that is probably overdoing it. The exponent size may also be a parameter to consider in fancy-land.

--top

I've given this some thought, too.  I believe that 'floating' (as a term) should be dropped for 'measure', which are real numbers given with a certain ''precision'' and ''confidence'' (accuracy), along with ''units'' (like 'meters') and ''property'' (like 'distance').  Much of that information could be stored as meta-data (e.g. in the type field, for efficiency purposes), but one would have the option of storing it as part of the number itself.  Such numbers could still easily take advantage of floating-point operations on the computer, so long as their precision wasn't too high.

Integers should by typed by predicate, with the most common predicate being absolute range.  'Decimal' could be replaced by more generic 'rational', which count things by wholes or fractions, with the 'dec' (base 10) being optional.  As with integers, rationals need to be exact.  Integers are a specialization of rationals, but not of measures.

There is no need for 'reals', since 'measures' can potentially be of any finite but arbitrary precision.

I'm quite sick of numbers being tied to hardware; I'd much rather let the optimizer/language compiler figure out where it can take advantage of my definitions for numbers (e.g. noting that if I said a number is in the range 0..65535, that it CAN be stored into a 16-bit word, should the optimizer want to do so).  And where I need explicit representations, I want the ability to declare representations separately from the ''type'' of the integer (e.g. so I can declare that a particular field is 'bigendian 32-bit ''representation'' of some integer'.).

The only real trick is rings... i.e. if I ''want'' 65535+1 to be 0, I really shouldn't be using something called an "integer", should I?  (or at least I should indicate, explicitly or implicitly, ''intent'' to utilize modulo arithmetic).

-------
See Also: FloatingPointCurrency
------
CategoryMath, CategoryLanguageTyping