[Python-Dev] Re: Decimal type question [Prothon]

[Gareth McCaughan]

On Monday 2004-08-09 20:34, Andrew P. Lentvorski, Jr. wrote:
> 
> On Aug 9, 2004, at 11:31 AM, Paul Moore wrote:
> 
> > I think that having 2 different fractional types distinguished by
> > something as subtle as the presence of an exponent (something no other
> > language does to my knowledge) is an extremely bad idea.
> 
> Doesn't Common Lisp use 1.0e+10 to signify singles and 1.0d+10 to
> signify doubles?
> 
> That doesn't make it a good idea, but there is precedent.

What CL does is a bit hairier than that. CL has, potentially,
*four* different float formats. (An implementation is allowed
to coalesce some or all of them.) s,f,d,l are used as exponent
letters for short, single, double, and long floats, respectively;
e means "use the default". The default default is single-float,
but users can change that if they prefer (say) doubles. (I'm
sure that if CL were being designed now rather than N years ago
double-float would be the default default.)

At least one implementation known to me (CLISP) does have
four different kinds of float. CLISP's long-floats have
user-settable precision, which can be as big as you like,
which makes CLISP a very handy platform for some kinds of
numerical experiments...

Fortran also distinguishes between 1.0e10 and 1.0d10, in much
the same way. In Fortran 90 and later, where there's potentially
an even greater plethora of floating types than in CL, there's
a more general mechanism for specifying the type of a floating-point
constant. It's very nasty. Floating-point types are represented
as integers. You define a parameter (i.e., a variable that isn't
allowed to change) that holds the type you're interested in,
and then you suffix your constants with "_" plus the parameter
name. Thus:

    integer, parameter my_real_type = selected_real_kind(15,100)
    real(my_real_type) x
    x = 1.234_my_real_type

It's not clear to me that any of this is very valuable in a
statically-typed language without type inference: the type
that a constant should be is almost always deducible from
context. (More precisely: there's always a way to deduce
a type that's almost always the one wanted.)

-- 
g