In article <199703192304.PAA01584@taumet.eng.sun.com>,
Stephen.Clamage@Eng.Sun.COM (Steve Clamage) wrote:
>> I have some esoteric floating point questions [about float_t and
>> double_t]
>
> The answer to all the questions below in C++ is "No." Those FP types
> and the header <fp.h> are nowhere mentioned in any draft of the C++
> standard, which is nearing finalization. (And no new features will be
> added.) The NCEG was an ad-hoc group associated with the C commitee,
> and produced a report some of whose recommendations have been adopted
> by the C Committee. (The C++ Committee didn't want to touch anything
> that the C Committee was working on.) I'll let the folks in comp.std.c
> give the C answer to these questions.

This is bad.

  +-----------------------------------------------------------+
  | There needs to be *standard* way to introduce the         |
  | identifiers float_t and double_t into a translation unit. |
  +-----------------------------------------------------------+

When I was working on a math library, I needed to use a fast floating
point type that was at least a double. I was concerned about portability,
speed, and precision. On one platform long double was the fastest, on
another it was double. I didn't want to modify my code for each platform.
I was told that fortunately I would not have to! I was told that this
problem was important enough that the NCEG already solved it. This was
five years ago.

I was told to use the identifier double_t defined in <fp.h>. On machines
where long double was faster, it would be typedefed to long double, and
where double was faster it would be typedefed to double. And so I did
this. Back in 1992, it was my (possibly incorrect) understanding that this
was expected to be standard in both C and C++. So I have interfaces such
as:

 #include <fp.h> // <--- introduce identifier double_t into translation unit

 #ifdef __cplusplus
 extern "C" {
 #endif

 double_t func(double_t x);   // <--- uses NCEG (FPCE) typedef

 #ifdef __cplusplus
 }
 #endif

A member of the C9X committee told me that there was a proposal that was
adopted to merge the <fp.h> back into <math.h>, so to be correct the above
should include <math.h>, not <fp.h>. But this does not work for C++ since
float_t and double_t are defined for C9X headers, not the C89 headers that
the C++ committee adopted. Although many C++ implementations may have
these defined somewhere, currently this is non-standard :-(  [I
previously believed this was standard, and this happened to work for me
for many years.]

One solution is that I, and everyone else, come up with our own typedefs,
that must be changed from platform to platform when using C++. It is
unfortunate this problem has been solved for so long in C (float_t and
double_t), and C programmers have been using these identifiers for at
least the last five years (maybe six or seven?), but they didn't make it
into the C++ standard.

The bottom line is that float_t and double_t don't have a home in C++. Is
it too late to help these poor, homeless, identifiers?  <math.h> and
<cmath> should have float_t and double_t defined. Is it too late to submit
such a proposal?

Since these are only typedefs, ensuring their existence would:

   - *prevent* existing code that use them from breaking
   - not break existing code
   - help new code to be written without modifying it for each
     platform it is ported to
   - would prevent the embarrassment of having the C9X folks say
     that "is something we solved years ago, but needs to be
     hacked in C++".

Possibly more NCEG extensions (see "C9X Floating-Point Proposal WG14/N546
X3J11/96-010") should also be part of C++, but I will leave that to the
numerics folks to argue. And given that it is so late in the game, I don't
want to fight that battle, so I will settle for float_t and double_t. Any
idea if this can happen?

Jay Zipnick, jzipnick@best.com
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

jzipnick@best.com (Jay Zipnick) writes:

>   +-----------------------------------------------------------+
>   | There needs to be *standard* way to introduce the         |
>   | identifiers float_t and double_t into a translation unit. |
>   +-----------------------------------------------------------+
>
> When I was working on a math library, I needed to use a fast floating
> point type that was at least a double. I was concerned about portability,
> speed, and precision. On one platform long double was the fastest, on
> another it was double. I didn't want to modify my code for each platform.
> I was told that fortunately I would not have to! I was told that this
> problem was important enough that the NCEG already solved it. This was
> five years ago.

A little work in a central header file (called fp.h maybe!) and you
can still use float_t and double_t.  You then have to modify this
header file only when you start work on a new platform, at which point
you do a once off check for the fastest type and typedef it.  Sure, it
would be nice if the implementation did it for you, but it's not
really that much work now.


--
______________________________________________________________________
Marcelo Cantos, Research Assistant      __/_   marcelo@mds.rmit.edu.au
Multimedia Database Systems Group, RMIT  /       _  Tel 61-3-9282-2497
723 Swanston St, Carlton VIC 3053    Aus/ralia ><_> Fax 61-3-9282-2490
Acknowledgements: errors - me; wisdom - God; funding - RMIT
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

jzipnick@best.com (Jay Zipnick) writes:

 |>  In article <199703192304.PAA01584@taumet.eng.sun.com>,
 |>  Stephen.Clamage@Eng.Sun.COM (Steve Clamage) wrote:
 |>  >> I have some esoteric floating point questions [about float_t and
 |>  >> double_t]
 |>  >
 |>  > The answer to all the questions below in C++ is "No." Those FP types
 |>  > and the header <fp.h> are nowhere mentioned in any draft of the C++
 |>  > standard, which is nearing finalization. (And no new features will be
 |>  > added.) The NCEG was an ad-hoc group associated with the C commitee,
 |>  > and produced a report some of whose recommendations have been adopted
 |>  > by the C Committee. (The C++ Committee didn't want to touch anything
 |>  > that the C Committee was working on.) I'll let the folks in comp.std.c
 |>  > give the C answer to these questions.
 |>
 |>  This is bad.
 |>
 |>    +-----------------------------------------------------------+
 |>    | There needs to be *standard* way to introduce the         |
 |>    | identifiers float_t and double_t into a translation unit. |
 |>    +-----------------------------------------------------------+

There "needs to be a standard way" to do a lot of things.  I use ASN1
types an BER encoding for communication between platforms; these are ISO
standards, so C++ really should offer me a standard header for them:-).

The standard is a compromise between what is needed and what can be
done.  In my case, for example, I really think that it would be a bad
idea for the standard to fix one single form of interprocess data
representation.  In your case, what you are proposing is probably
reasonable for the C++ standard, but as Steve Clamage pointed out, there
are technico-adminstrative reasons why it will not be.  As it happens,
in the real world, the situation (for you, anyway) is probably better.

 |>  When I was working on a math library, I needed to use a fast floating
 |>  point type that was at least a double. I was concerned about portability,
 |>  speed, and precision. On one platform long double was the fastest, on
 |>  another it was double. I didn't want to modify my code for each platform.
 |>  I was told that fortunately I would not have to! I was told that this
 |>  problem was important enough that the NCEG already solved it. This was
 |>  five years ago.
 |>
 |>  I was told to use the identifier double_t defined in <fp.h>. On machines
 |>  where long double was faster, it would be typedefed to long double, and
 |>  where double was faster it would be typedefed to double. And so I did
 |>  this. Back in 1992, it was my (possibly incorrect) understanding that this
 |>  was expected to be standard in both C and C++. So I have interfaces such
 |>  as:

I don't think it has ever been really standard.  It was a proposal.  It
is not supported by either of the two C compilers available on the
machine I'm on now, for example.

    [...]
 |>  A member of the C9X committee told me that there was a proposal that was
 |>  adopted to merge the <fp.h> back into <math.h>, so to be correct the above
 |>  should include <math.h>, not <fp.h>. But this does not work for C++ since
 |>  float_t and double_t are defined for C9X headers, not the C89 headers that
 |>  the C++ committee adopted.

You can hardly expect the C++ committee to adopt something that doesn't
exist.  At present, the only officially available standard C headers
*are* those of C89.

This is where the situation in real life may be better than what the
standard says.  In practice, most, if not all, C++ compiler vendors also
offer C, either as a command line option from the same compiler, or as a
separate product.  It is hardly conceivable that if this facility is
offered in their C compiler, that it will not be available in the same
form in the C++ compiler.

 |>  Although many C++ implementations may have
 |>  these defined somewhere, currently this is non-standard :-(  [I
 |>  previously believed this was standard, and this happened to work for me
 |>  for many years.]
 |>
 |>  One solution is that I, and everyone else, come up with our own typedefs,
 |>  that must be changed from platform to platform when using C++. It is
 |>  unfortunate this problem has been solved for so long in C (float_t and
 |>  double_t), and C programmers have been using these identifiers for at
 |>  least the last five years (maybe six or seven?), but they didn't make it
 |>  into the C++ standard.
 |>
 |>  The bottom line is that float_t and double_t don't have a home in C++. Is
 |>  it too late to help these poor, homeless, identifiers?  <math.h> and
 |>  <cmath> should have float_t and double_t defined. Is it too late to submit
 |>  such a proposal?

Yes.  On the other hand, I wouldn't worry about it too much.  If they
are blessed by C9X, they will find a home in most real C++ compilers.

 |>  Since these are only typedefs, ensuring their existence would:
 |>
 |>     - *prevent* existing code that use them from breaking
 |>     - not break existing code
 |>     - help new code to be written without modifying it for each
 |>       platform it is ported to
 |>     - would prevent the embarrassment of having the C9X folks say
 |>       that "is something we solved years ago, but needs to be
 |>       hacked in C++".
 |>
 |>  Possibly more NCEG extensions (see "C9X Floating-Point Proposal WG14/N546
 |>  X3J11/96-010") should also be part of C++, but I will leave that to the
 |>  numerics folks to argue. And given that it is so late in the game, I don't
 |>  want to fight that battle, so I will settle for float_t and double_t. Any
 |>  idea if this can happen?

Again: real C++ compilers will probably adopt whatever becomes
officially part of C9X.  I know that it is preferrable to have an
official standard, but given the historical relationship between C and
C++, I think that in this case, you are fairly safe basing yourself on
the C standard.

--
James Kanze      home:     kanze@gabi-soft.fr        +33 (0)1 39 55 85 62
                 office:   kanze@vx.cit.alcatel.fr   +33 (0)1 69 63 14 54
GABI Software, Sarl., 22 rue Jacques-Lemercier, F-78000 Versailles France
     -- Conseils en informatique industrielle --
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

In article <jzipnick-2103972336060001@c420522-a.snvl1.sfba.home.com>,
jzipnick@best.com writes:
> [about float_t and double_t no being standard]
>
> This is bad.
>
> [...]
>
> ... It is
> unfortunate this problem has been solved for so long in C (float_t and
> double_t), and C programmers have been using these identifiers for at
> least the last five years (maybe six or seven?), but they didn't make it
> into the C++ standard.

IRIX 5.2 still doesn't have a float_t or double_t anywhere, nor a <fp.h>
so I doubt this solution is as widespread as you think.  AIX 4.1 doesn't
have it either.

---------------------------------------------------------------------------
Tim Hollebeek         | Disclaimer :=> Everything above is a true statement,
Electron Psychologist |                for sufficiently false values of true.
Princeton University  | email: tim@wfn-shop.princeton.edu
----------------------| http://wfn-shop.princeton.edu/~tim (NEW! IMPROVED!)
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

In article 1803972336360001@c420522-a.snvl1.sfba.home.com, jzipnick@best.com (Jay Zipnick) writes:
>I have some esoteric floating point questions:

The answer to all the questions below in C++ is "No." Those FP types
and the header <fp.h> are nowhere mentioned in any draft of the C++
standard, which is nearing finalization. (And no new features will be
added.) The NCEG was an ad-hoc group associated with the C commitee,
and produced a report some of whose recommendations have been adopted
by the C Committee. (The C++ Committee didn't want to touch anything
that the C Committee was working on.) I'll let the folks in comp.std.c
give the C answer to these questions.

>
>1) Which standard header file should one include from C that declares the
>identifiers float_t and double_t? Where is this documented?
>
>2) Which standard header file should one include from C++ that declares
>the identifiers float_t and double_t? Where is this documented?
>
>I was told years five ago that the proper header is <fp.h>, as defined by
>the NCEG. However I have not been able to find any reference to
>float_t/double_t in the C++ draft standard. (Perhaps an accidental
>ommision?)
>
>3) Does the NCEG (Numerical C Extensions group) still exist? Just curious.
>
>4) I saw one reference in a C9X document that proposed that the <fp.h>
>extensions are to be rolled into <math.h>. Was this proposal passed?
>
>5) If so, is including <fp.h> offically deprecated in C?
>
>6) If so, is including <fp.h> offically deprecated in C++?

---
Steve Clamage, stephen.clamage@eng.sun.com
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

I have some esoteric floating point questions:

1) Which standard header file should one include from C that declares the
identifiers float_t and double_t? Where is this documented?

2) Which standard header file should one include from C++ that declares
the identifiers float_t and double_t? Where is this documented?

I was told years five ago that the proper header is <fp.h>, as defined by
the NCEG. However I have not been able to find any reference to
float_t/double_t in the C++ draft standard. (Perhaps an accidental
ommision?)

3) Does the NCEG (Numerical C Extensions group) still exist? Just curious.

4) I saw one reference in a C9X document that proposed that the <fp.h>
extensions are to be rolled into <math.h>. Was this proposal passed?

5) If so, is including <fp.h> offically deprecated in C?

6) If so, is including <fp.h> offically deprecated in C++?

I certainly hope that the answers to 1 and 2 are the same, as well as the
answers to 5 and 6.

By the way, for those unfamiliar, float_t is supposed to be a typedef for
the fastest floating point type that is at least a float (float, double,
or long double). double_t is supposed to be a typedef for the fastest
floating point type that is at least a double (double, or long double).
Naturally these can vary from platform to platform.

Please also reply to jzipnick@best.com

Thanks,
Jay Zipnick
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]