Hello

If I have a FLOAT variable how to retrieve its exponent and mantissa in 
the most portable way.

Cheers Raj

On Thu, 31 May 2012 20:59:58 +0000, Raj Pashwar wrote:

> 
> If I have a FLOAT variable how to retrieve its exponent and mantissa in 
> the most portable way.
> 

frexpf

-- 
steve

"Steven G. Kargl" <sgk@REMOVEtroutmask.apl.washington.edu> writes:

> On Thu, 31 May 2012 20:59:58 +0000, Raj Pashwar wrote:
>
>> 
>> If I have a FLOAT variable how to retrieve its exponent and mantissa in 
>> the most portable way.
>> 
>
> frexpf

That's probably what the OP wants, but it's not what they asked for!
frexpf returns a normalised fraction, not the mantissa itself, and the
power returned is always given as a power of 2, even on machines that
use some other radix for the exponent.

-- 
Ben.

On 2012-05-31, Raj Pashwar <raj121190@hotmail.NOSPAM.com> wrote:
> Hello
>
> If I have a FLOAT variable how to retrieve its exponent and mantissa in 
> the most portable way.

You could have a look at the frexp function from <math.h>

On 05/31/2012 04:59 PM, Raj Pashwar wrote:
> Hello
> 
> If I have a FLOAT variable how to retrieve its exponent and mantissa in 
> the most portable way.

C doesn't have FLOAT, it does have float, and it is NOT nit-picking to
point it out because C is case-sensitive.

As has already been pointed out, what you probably want is frexpf(). In
the unlikely event that you're using a implementation where FLT_RADIX !=
2, then the frexpf() won't give you what you asked for (though it may
give you what you want). The following function will give you what you
asked for, whether or not FLT_RADIX == 2.

This code below makes extensive use of parts of the C standard library
that were new in C99; it seems absurd to have to worry about C90 when
C2011 has already come out, but the practical matter of fact is that
there's still a lot of C implementations out there which have not yet
implemented all features of C99, possible including these. ilogbf(x) can
be implemented as directly manipulating the floating point
representation of x; the closest equivalent in C90 is much less efficient.

#include <float.h>
#include <limits.h>
#include <math.h>
#include <stdio.h>

static int decompose_float(
        float x,
        float *mantissa,
        int *exponent
){
    // Returns the sign of x, and sets *exponent to the same values
    // that would be returned by ilogbf(x):
    // FP_ILOGB0 if x is zero. Can be INT_MIN or -INT_MAX
    // FP_ILOGBNAN if x is a NaN. Can be INT_MIN or INT_MAX
    // INT_MAX if x is infinite.
    // The value returned by ilogbf(x) therefore cannot be used to
    // unambiguously distinguish these cases.
    if(isnan(x))
    {
        *exponent = FP_ILOGBNAN;
        *mantissa = x;
        return 0;
    }

    int sign = (x > 0.0F) - (x < 0.0F);
    if(isinf(x))
    {
        *exponent = INT_MAX;
        *mantissa = INFINITY;
    }
    else if(sign)
    {
        *exponent = ilogbf(x);
        *mantissa = x/powf(FLT_RADIX,*exponent)/sign;
    }
    else
    {
        *exponent = FP_ILOGB0;
        *mantissa = 0.0F;
    }

    return sign;
}

int main(void)
{
    float arr[] = {-INFINITY, -HUGE_VALF, -FLT_MAX, -10.0, -1.0, -0.1,
        -FLT_EPSILON, -FLT_MIN, nanf(""), 0.0F, FLT_MIN, FLT_EPSILON,
0.1, 1.0,
        10.0, FLT_MAX, HUGE_VALF, INFINITY};
    for(int val=0; val < sizeof arr/sizeof *arr; val++)
    {
        float mantissa;
        int exponent;
        int sign = decompose_float(arr[val], &mantissa, &exponent);
        printf("%12g = %2d*%8f*pow(%d,%d)\n",
            arr[val], sign, mantissa, FLT_RADIX, exponent);
    }

    return 0;
}

In article <4FC7F751.8080500@verizon.net>,
James Kuyper  <jameskuyper@verizon.net> wrote:
>C doesn't have FLOAT, it does have float, and it is NOT nit-picking to
>point it out because C is case-sensitive.

damn

cut the guy a break

sometimes i think this newsgroup is 'comp.lang.nitprick'

he asked the question in English

just as a guess English not his native language

is kind of rude

=D7=91=D7=AA=D7=90=D7=A8=D7=99=D7=9A =D7=99=D7=95=D7=9D =D7=A9=D7=91=D7=AA,=
 2 =D7=91=D7=99=D7=95=D7=A0=D7=99 2012 00:02:46 UTC+1, =D7=9E=D7=90=D7=AA J=
oe keane:
> In article <4FC7F751.8080500@verizon.net>,
> James Kuyper  <jameskuyper@verizon.net\>>
> >C doesn't have FLOAT, it does have float, and it is NOT nit-picking to
> >point it out because C is case-sensitive.
>=20
> damn
>=20
FLOAT is likely to be a typedef, and the probable reason for using it is to=
 toggle the underlying types without changing the code. So the answer to th=
e question is different.

In article <jqbhmm$j0$1@reader1.panix.com>, Joe keane <jgk@panix.com> wrote:
>In article <4FC7F751.8080500@verizon.net>,
>James Kuyper  <jameskuyper@verizon.net> wrote:
>>C doesn't have FLOAT, it does have float, and it is NOT nit-picking to
>>point it out because C is case-sensitive.
>
>damn
>
>cut the guy a break
>
>sometimes i think this newsgroup is 'comp.lang.nitprick'
>
>he asked the question in English
>
>just as a guess English not his native language
>
>is kind of rude

Welcome to CLC.  We hope you enjoy your stay...

-- 
They say compassion is a virtue, but I don't have the time!

    - David Byrne -

In article <jqbl91$as2$1@news.xmission.com>,
Kenny McCormack <gazelle@shell.xmission.com> wrote:
>Welcome to CLC.  We hope you enjoy your stay...

i listened to Pind Floyd a lot of times

i still don't think

i had a lot of cowerkers 
who has English is not perfect

the other hand
my speaking to them in their native language is somewhere between
impossible or more impossible, probably the latter

On 06/01/2012 07:17 PM, Malcolm McLean wrote:
> בתאריך יום שבת, 2 ביוני 2012 00:02:46 UTC+1, מאת Joe keane:
>> In article <4FC7F751.8080500@verizon.net>,
>> James Kuyper  <jameskuyper@verizon.net\>>
>>> C doesn't have FLOAT, it does have float, and it is NOT nit-picking to
>>> point it out because C is case-sensitive.
>>
>> damn
>>
> FLOAT is likely to be a typedef, and the probable reason for using it is to toggle the underlying types without changing the code. So the answer to the question is different.

I doubt it was a typedef, I think it was just a failure to be adequately
aware of C's case-sensitivity. He may be more familiar with some other
language that is case-insensitive.
However, if it was a typedef, you're right - without knowing what it's a
typedef for, it would be impossible to answer the question.
-- 
James Kuyper

On Sat, 02 Jun 2012 10:27:20 -0400, James Kuyper wrote:

> I doubt it was a typedef, I think it was just a failure to be adequately
> aware of C's case-sensitivity.

Or maybe it's just a case of conventional usage of capitals as a form of
emphasis (you can't use boldface in plain text and using HTML on usenet is
frowned upon). In much the same way that posters often use quotes without
necessarily meaning a C string literal.

Nobody <nobody@nowhere.com> writes:
> On Sat, 02 Jun 2012 10:27:20 -0400, James Kuyper wrote:
>> I doubt it was a typedef, I think it was just a failure to be adequately
>> aware of C's case-sensitivity.
>
> Or maybe it's just a case of conventional usage of capitals as a form of
> emphasis (you can't use boldface in plain text and using HTML on usenet is
> frowned upon). In much the same way that posters often use quotes without
> necessarily meaning a C string literal.

Whatever the OP meant, I hope he understands by now that referring to
the type "float" as "FLOAT" is not a good idea.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
    Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

On Sat, 02 Jun 2012 14:54:09 -0700, Keith Thompson wrote:

> Nobody <nobody@nowhere.com> writes:
>> On Sat, 02 Jun 2012 10:27:20 -0400, James Kuyper wrote:
>>> I doubt it was a typedef, I think it was just a failure to be
>>> adequately aware of C's case-sensitivity.
>>
>> Or maybe it's just a case of conventional usage of capitals as a form
>> of emphasis (you can't use boldface in plain text and using HTML on
>> usenet is frowned upon). In much the same way that posters often use
>> quotes without necessarily meaning a C string literal.
> 
> Whatever the OP meant, I hope he understands by now that referring to
> the type "float" as "FLOAT" is not a good idea.

Yes, thanks :-)

In fact John Kupyer was right : on my system FLOAT is a type-def for long 
double.

Cheers Raj

On 6/3/2012 4:11 AM, Raj Pashwar wrote:
> On Sat, 02 Jun 2012 14:54:09 -0700, Keith Thompson wrote:
>
>> Nobody<nobody@nowhere.com>  writes:
>>> On Sat, 02 Jun 2012 10:27:20 -0400, James Kuyper wrote:
>>>> I doubt it was a typedef, I think it was just a failure to be
>>>> adequately aware of C's case-sensitivity.
>>>
>>> Or maybe it's just a case of conventional usage of capitals as a form
>>> of emphasis (you can't use boldface in plain text and using HTML on
>>> usenet is frowned upon). In much the same way that posters often use
>>> quotes without necessarily meaning a C string literal.
>>
>> Whatever the OP meant, I hope he understands by now that referring to
>> the type "float" as "FLOAT" is not a good idea.
>
> Yes, thanks :-)
>
> In fact John Kupyer was right : on my system FLOAT is a type-def for long
> double.

     In that case, don't use frexpf(): Use frexpl() instead, or
#include <tgmath.h> and use frexp().

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

On 06/03/2012 04:11 AM, Raj Pashwar wrote:
> On Sat, 02 Jun 2012 14:54:09 -0700, Keith Thompson wrote:
> 
>> Nobody <nobody@nowhere.com> writes:
>>> On Sat, 02 Jun 2012 10:27:20 -0400, James Kuyper wrote:
>>>> I doubt it was a typedef, I think it was just a failure to be
>>>> adequately aware of C's case-sensitivity.
>>>
>>> Or maybe it's just a case of conventional usage of capitals as a form
>>> of emphasis (you can't use boldface in plain text and using HTML on
>>> usenet is frowned upon). In much the same way that posters often use
>>> quotes without necessarily meaning a C string literal.
>>
>> Whatever the OP meant, I hope he understands by now that referring to
>> the type "float" as "FLOAT" is not a good idea.
> 
> Yes, thanks :-)
> 
> In fact John Kupyer was right : on my system FLOAT is a type-def for long 
> double.

John's my brother, and we both spell it Kuyper, not Kupyer. No offense
taken, but a programmer needs to be a bit more careful about details
like that, or the programs won't work. There will, of course, per
tradition, be at least one spelling error in this message, even though I
didn't put one in deliberately. :-}

The example code I provided was based upon the assumption that FLOAT
meant float; that's a perfectly natural assumption, which is why it's a
bad idea to define a typedef with that name; a more neutral name such as
FP_TYPE would be better; a name that indicated the domain of
applicability of the typedef would be even better. For example, one of
third-party libraries I use chose PGS as it's identifying prefix, and
PGSt_integer is their typedef for the integer type to be used when
interfacing with their library.

Since FLOAT was a typedef for long double, the example code I provided
needs modification as follows:

1. Replace float with FLOAT
2. Remove the F suffixes on floating point constants.
3. Replace FLT prefixes on macros from the standard library with LDBL.
4. Replace INFINITY inside decompose_FLOAT() with x/sign.
5a. Replace f suffixes on standard math library functions with l.
or
5b. #include <tgmath.h> and remove the f suffixes from the standard math
library functions.

Note: if there's any chance that FLOAT might be a typedef for a
different type in the future, or on some other platform where this code
needs to work, 4b is to be preferred to 4a. Item 3 needs to be changed
accordingly; but that is relevant only in the test driver.
-- 
James Kuyper

=D7=91=D7=AA=D7=90=D7=A8=D7=99=D7=9A =D7=99=D7=95=D7=9D =D7=A8=D7=90=D7=A9=
=D7=95=D7=9F, 3 =D7=91=D7=99=D7=95=D7=A0=D7=99 2012 13:51:42 UTC+1, =D7=9E=
=D7=90=D7=AA James Kuyper:
> On 06/03/2012 04:11 AM, Raj Pashwar wrote:
>=20
> The example code I provided was based upon the assumption that FLOAT
> meant float; that's a perfectly natural assumption, which is why it's a
> bad idea to define a typedef with that name; a more neutral name such as
> FP_TYPE would be better;
>

int fft(FLOAT *real, FLOAT *imaginary, int N)

is obvious

IS_TYPE fft_fpt(FP_TYPE *r, FP_TYPE *j, IU_TYPE i)

much less so. You have a certain amount of redundancy. Choose a bad symbol =
for one thing and code is still very readable. It's the accumulation of lit=
tle obscurities which is the killer.=20

=20

On 06/03/2012 10:48 AM, Malcolm McLean wrote:
> בתאריך יום ראשון, 3 ביוני 2012 13:51:42 UTC+1, מאת James Kuyper:
>> On 06/03/2012 04:11 AM, Raj Pashwar wrote:
>>
>> The example code I provided was based upon the assumption that FLOAT
>> meant float; that's a perfectly natural assumption, which is why it's a
>> bad idea to define a typedef with that name; a more neutral name such as
>> FP_TYPE would be better;
>>
> 
> int fft(FLOAT *real, FLOAT *imaginary, int N)
> 
> is obvious

The obvious implication of that typedef is wrong (seriously so, as it
turns out), so it's obviousness is a mark against it.

> IS_TYPE fft_fpt(FP_TYPE *r, FP_TYPE *j, IU_TYPE i)
> 
> much less so. You have a certain amount of redundancy. Choose a bad symbol for one thing and code is still very readable. It's the accumulation of little obscurities which is the killer. 

In suggesting FP_TYPE, I was merely trying to keep as close as possible
to the style of the OP's code as I could, while making my point. I
personally think that IS_TYPE and IU_TYPE are both substantially less
clear than FP_TYPE.

My preferred alternative is fairly well exemplified the the third party
library I was talking about. It would use PGSt_integer, PGSt_double, and
PGSt_uinteger for the places where you used IS_TYPE, FP_TYPE, and
IU_TYPE. Shortening "_TYPE" to "t_" is an improvement; tagging the types
with PGS to indicate which library they were associated with was another
improvement, and using relatively long names for the specific types
helps clarify things too.

I think that using "double" in the type name was a bad choice for the
same reason I originally gave against "FLOAT", but nobody's perfect.
-- 
James Kuyper

Raj Pashwar <raj121190@hotmail.NOSPAM.com> writes:
> On Sat, 02 Jun 2012 14:54:09 -0700, Keith Thompson wrote:
[...]     
>> Whatever the OP meant, I hope he understands by now that referring to
>> the type "float" as "FLOAT" is not a good idea.
>
> Yes, thanks :-)
>
> In fact John Kupyer was right : on my system FLOAT is a type-def for long 
> double.

(James Kuyper)

Out of curiosity, where exactly does this typedef (not "type-def")
appear?  Is it in a header for some particular application or
library, or is it really defined by your (operating) system?

FLOAT is a really bad name for a typedef.  Either it's a typedef
for the built-in type "float", in which case it's fairly useless,
or it's a typedef for something other than "float", in which case
it's actively misleading.

(The only reasonable justification I can think of is that FLOAT
might be used to implement a type in some other language.)

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
    Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

On Sun, 03 Jun 2012 13:43:13 -0700, Keith Thompson wrote:

> Raj Pashwar <raj121190@hotmail.NOSPAM.com> writes:
>> On Sat, 02 Jun 2012 14:54:09 -0700, Keith Thompson wrote:
> [...]
>>> Whatever the OP meant, I hope he understands by now that referring to
>>> the type "float" as "FLOAT" is not a good idea.
>>
>> Yes, thanks :-)
>>
>> In fact John Kupyer was right : on my system FLOAT is a type-def for
>> long double.
> 
> (James Kuyper)
> 
> Out of curiosity, where exactly does this typedef (not "type-def")
> appear?  Is it in a header for some particular application or library,
> or is it really defined by your (operating) system?
> 
> FLOAT is a really bad name for a typedef.  Either it's a typedef for the
> built-in type "float", in which case it's fairly useless, or it's a
> typedef for something other than "float", in which case it's actively
> misleading.
> 
> (The only reasonable justification I can think of is that FLOAT might be
> used to implement a type in some other language.)

Yes, it's in one of the headers.

I think the idea is: it gives flexibility to change between float (=small 
size, low precision) or long double (=high size, high precision) or 
double (=compromise) at a later stage, without needing to change all 
definitions everywhere in code : only the typeDef needs changing.

Cheers Raj

On Sun, 03 Jun 2012 08:33:34 -0400, Eric Sosman wrote:

> On 6/3/2012 4:11 AM, Raj Pashwar wrote:
>> On Sat, 02 Jun 2012 14:54:09 -0700, Keith Thompson wrote:
>>
>>> Nobody<nobody@nowhere.com>  writes:
>>>> On Sat, 02 Jun 2012 10:27:20 -0400, James Kuyper wrote:
>>>>> I doubt it was a typedef, I think it was just a failure to be
>>>>> adequately aware of C's case-sensitivity.
>>>>
>>>> Or maybe it's just a case of conventional usage of capitals as a form
>>>> of emphasis (you can't use boldface in plain text and using HTML on
>>>> usenet is frowned upon). In much the same way that posters often use
>>>> quotes without necessarily meaning a C string literal.
>>>
>>> Whatever the OP meant, I hope he understands by now that referring to
>>> the type "float" as "FLOAT" is not a good idea.
>>
>> Yes, thanks :-)
>>
>> In fact John Kupyer was right : on my system FLOAT is a type-def for
>> long double.
> 
>      In that case, don't use frexpf(): Use frexpl() instead, or
> #include <tgmath.h> and use frexp().

Thanks. I've never used the tgmath library before - can you give me any 
pointers where to download it? What are the advantages over the standard 
math library?

Cheers Raj

On 06/ 4/12 10:06 AM, Raj Pashwar wrote:
> On Sun, 03 Jun 2012 08:33:34 -0400, Eric Sosman wrote:
>
>> On 6/3/2012 4:11 AM, Raj Pashwar wrote:
>>> On Sat, 02 Jun 2012 14:54:09 -0700, Keith Thompson wrote:
>>>
>>>> Nobody<nobody@nowhere.com>   writes:
>>>>> On Sat, 02 Jun 2012 10:27:20 -0400, James Kuyper wrote:
>>>>>> I doubt it was a typedef, I think it was just a failure to be
>>>>>> adequately aware of C's case-sensitivity.
>>>>>
>>>>> Or maybe it's just a case of conventional usage of capitals as a form
>>>>> of emphasis (you can't use boldface in plain text and using HTML on
>>>>> usenet is frowned upon). In much the same way that posters often use
>>>>> quotes without necessarily meaning a C string literal.
>>>>
>>>> Whatever the OP meant, I hope he understands by now that referring to
>>>> the type "float" as "FLOAT" is not a good idea.
>>>
>>> Yes, thanks :-)
>>>
>>> In fact John Kupyer was right : on my system FLOAT is a type-def for
>>> long double.
>>
>>       In that case, don't use frexpf(): Use frexpl() instead, or
>> #include<tgmath.h>  and use frexp().
>
> Thanks. I've never used the tgmath library before - can you give me any
> pointers where to download it? What are the advantages over the standard
> math library?

It's a standard header for generic maths functions.

-- 
Ian Collins

On 06/ 4/12 10:06 AM, Raj Pashwar wrote:
> On Sun, 03 Jun 2012 13:43:13 -0700, Keith Thompson wrote:
>
>> Raj Pashwar<raj121190@hotmail.NOSPAM.com>  writes:
>>> On Sat, 02 Jun 2012 14:54:09 -0700, Keith Thompson wrote:
>> [...]
>>>> Whatever the OP meant, I hope he understands by now that referring to
>>>> the type "float" as "FLOAT" is not a good idea.
>>>
>>> Yes, thanks :-)
>>>
>>> In fact John Kupyer was right : on my system FLOAT is a type-def for
>>> long double.
>>
>> (James Kuyper)
>>
>> Out of curiosity, where exactly does this typedef (not "type-def")
>> appear?  Is it in a header for some particular application or library,
>> or is it really defined by your (operating) system?
>>
>> FLOAT is a really bad name for a typedef.  Either it's a typedef for the
>> built-in type "float", in which case it's fairly useless, or it's a
>> typedef for something other than "float", in which case it's actively
>> misleading.
>>
>> (The only reasonable justification I can think of is that FLOAT might be
>> used to implement a type in some other language.)
>
> Yes, it's in one of the headers.
>
> I think the idea is: it gives flexibility to change between float (=small
> size, low precision) or long double (=high size, high precision) or
> double (=compromise) at a later stage, without needing to change all
> definitions everywhere in code : only the typeDef needs changing.

You miss the point completely.  The technique is common, it is the name 
you have chosen that's bad.

-- 
Ian Collins

On 6/3/2012 6:06 PM, Raj Pashwar wrote:
> On Sun, 03 Jun 2012 08:33:34 -0400, Eric Sosman wrote:
>
>> On 6/3/2012 4:11 AM, Raj Pashwar wrote:
>>>  [...]
>>> In fact John Kupyer was right : on my system FLOAT is a type-def for
>>> long double.
>>
>>       In that case, don't use frexpf(): Use frexpl() instead, or
>> #include<tgmath.h>  and use frexp().
>
> Thanks. I've never used the tgmath library before - can you give me any
> pointers where to download it? What are the advantages over the standard
> math library?

     "Type-generic math" was added to C in the C99 Standard, toward
the end of the Clinton Administration.  If you're using a pre-C99
implementation you might not have it, in which case you should use
frexpl() explicitly.

     The <tgmath.h> standard header provides magical macros that
inspect their argument types and figure out whether to call the
float, double, or long double math function.  Using <tgmath.h>, you
can just write frexp(x) and the compiler will inspect `x' to
decide whether to use frexpf, frexp (the actual function taking
double), or frexpl.

     Your situation is exactly the kind of thing that motivated
<tgmath.h> in the first place.  It's easy enough to write a call
to sqrtf() for a float argument or sqrtl() for a long double,
but when the type is hidden behind a typedef it's not so clear
which function to apply.  In your case the visible name of the
type was FLOAT, so we all directed you to the frexp() function,
which is appropriate for a float argument.  With <tgmath.h>, the
compiler will figure this out for you, even if the visible type
name is REAL or SCALAR: The compiler knows whether these resolve
to float or double or long double, and uses the appropriate
function.

     The underlying functions are in <math.h>, and you can call
them by their full names if you desire (or if you must, lacking
a C99 implementation).

     The latest "C11" Standard introduces machinery to let user-
written functions do similar magic, but I haven't tried it yet.

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

On 06/03/2012 06:06 PM, Raj Pashwar wrote:
> On Sun, 03 Jun 2012 13:43:13 -0700, Keith Thompson wrote:
> 
....
>> Out of curiosity, where exactly does this typedef (not "type-def")
>> appear?  Is it in a header for some particular application or library,
>> or is it really defined by your (operating) system?
....
> Yes, it's in one of the headers.

I think that when he asked  "where exactly", he was looking for an
answer more specific than "yes".
Is it a header for some particular application - if so, which one?
Is it a header for a library - if so, which one?
Is it a header for your operating system - if so, which one?
-- 
James Kuyper

Raj Pashwar <raj121190@hotmail.NOSPAM.com> writes:
> On Sun, 03 Jun 2012 13:43:13 -0700, Keith Thompson wrote:
[...]
>> Out of curiosity, where exactly does this typedef (not "type-def")
>> appear?  Is it in a header for some particular application or library,
>> or is it really defined by your (operating) system?
>> 
>> FLOAT is a really bad name for a typedef.  Either it's a typedef for the
>> built-in type "float", in which case it's fairly useless, or it's a
>> typedef for something other than "float", in which case it's actively
>> misleading.
>> 
>> (The only reasonable justification I can think of is that FLOAT might be
>> used to implement a type in some other language.)
>
> Yes, it's in one of the headers.

Um, I asked "where exactly".

> I think the idea is: it gives flexibility to change between float (=small 
> size, low precision) or long double (=high size, high precision) or 
> double (=compromise) at a later stage, without needing to change all 
> definitions everywhere in code : only the typeDef needs changing.

That's a fine idea -- but FLOAT is a lousy name for it.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
    Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

=D7=91=D7=AA=D7=90=D7=A8=D7=99=D7=9A =D7=99=D7=95=D7=9D =D7=A9=D7=A0=D7=99,=
 4 =D7=91=D7=99=D7=95=D7=A0=D7=99 2012 20:20:43 UTC+1, =D7=9E=D7=90=D7=AA K=
eith Thompson:
>=20
> That's a fine idea -- but FLOAT is a lousy name for it.
>=20
REAL would be better.
However not all programmers know what that means.

On 06/05/2012 06:54 AM, Malcolm McLean wrote:
> בתאריך יום שני, 4 ביוני 2012 20:20:43 UTC+1, מאת Keith Thompson:
>>
>> That's a fine idea -- but FLOAT is a lousy name for it.
>>
> REAL would be better.
> However not all programmers know what that means.

A typedef like that is always intended for use in a specific context; it
should not mean "the floating point type that should be used in all
contexts". It should mean something like "the floating point type to be
used when working with this particular library", and the name should
contain at least a hint of the correct context; neither "FLOAT" nor
"REAL" does so.
-- 
James Kuyper