Multi precision floating point

[Harald van Dijk]

It is a "conforming program".

True, though not a "correct program".

 

[Harald van Dijk]

Hey guys, the standard says:
<quote>
A conforming implementation may have extensions (including additional
library functions), provided they do not alter the behavior of any
strictly conforming
program.3)
<end quote>
So, anything that doesn't break the established rules is ALLOWED.

Yes, that's not the issue. The issue is whether a conforming
implementation may also have non-extensions that cause non-standard code
to be accepted.

 

[Harald van Dijk]

I think that your definition of 'extensions' is broken. If it is in the
C standard, then *by definition* it is *NOT* an extension.

If you bothered to actually read my messages, you'd know I already
understand that, and only gave examples of that *isn't* in the C standard
as what I called extensions.

 

[Harald van Dijk]

Therefore, use of the offsetof() macro requires nothing whatsoever
beyond standard C.
Think about it, and you will see my point.

From my own post upthread:

"#include <stddef.h>
struct S {
int m;
};
enum {
zero = offsetof(struct S, m)
};

does not make use of an extension."

Would you please start reading already, before replying again?

 

[Harald van Dijk]

Do we agree (then) that use of offsetof() does not require a language
extension?
Yes.

If so, then I do not understand what the issue is.

Whether the definition, as opposed to the use, of offsetof requires a
language extension.

In the message that started this subthread, I posted:
"offsetof is required to be defined in the standard headers, not merely
declared, and its definition requires extensions."

(As Flash Gordon pointed out, it turns out to be possible for a compiler
to accept
#include <stddef.h>
in a way that requires absolutely nothing of what I would consider
extensions, by using compiler magic for the #include statement itself.)

 

[James Kuyper]

I am "incompetent" as Hans J. Boehm:

"Threads cannot be implemented as Libraries"

User923005's point had nothing to do with whether or not threads can be
implemented as libraries. It had to do with whether or not a feature
added to one particular implementation constitutes a change to the C
language itself. The C language itself is defined by the standard. An
implementation can have extensions that go beyond the C language; they
extend the implementation, they don't extend the C language itself.

 

[Philip Potter]

Yes, that's not the issue. The issue is whether a conforming
implementation may also have non-extensions that cause non-standard code
to be accepted.

I would say unequivocally yes. For any construct that introduces UB,
code which uses it is non-standard, but a conforming implementation can
accept it (and does not have to document what happens when it does).

Phil

 

[pete]

Harald van Dijk wrote:

I would say unequivocally yes.

Any extension that won't screw up the translation
and execution of a strictly conforming program, is allowed.

Roughly speaking, any running computer software,
that can translate and execute a strictly conforming C program,
is a conforming C implementation.

 

[Keith Thompson]

Any extension that won't screw up the translation
and execution of a strictly conforming program, is allowed.

Roughly speaking, any running computer software,
that can translate and execute a strictly conforming C program,
is a conforming C implementation.

The requirements on conforming C implementations are *not* limited to
supporting the narrow set of strictly conforming programs. For
example, a hosted implementation that rejects or mishandles this:

#include <stdio.h>
#include <limits.h>
int main(void)
{
printf("INT_MAX = %d\n", INT_MAX);
return 0;
}

is not conforming.

 

[Keith Thompson]

user923005 wrote: [...]

However, I think that a diagnostic should be issued for a
compiler that does something like this:

qfloat foo = 12345678901234567890.9999999Q;

Failure to emit a diagnostic in conformant mode is an indication
that the compiler is broken.

I actually disagree, but at any rate a simple output of "This
compilation accepts non-standard gubris" will suffice. The
standard does not specify quality.

12345678901234567890.9999999Q is a syntax error in standard C. For
that matter, so is qfloat unless it's been declared somewhere
(presumably as a typedef). Diagnostics are required for violations of
syntax rules and of constraints.

So the "123.456Q" syntax is a valid extension (since no strictly
conforming program can use it), but the compiler must still issue a
diagnostic -- which, as you say, can be as simple as "Thank you for
using this wonderful extension".

And of course no diagnostic is required if the compiler is invoked in
a non-conforming mode (but then if the compiler is non-conforming,
then the standard requires absolutely *nothing* of it).

 

[user923005]

user923005 wrote: [...]

However, I think that a diagnostic should be issued for a
compiler that does something like this:
qfloat foo = 12345678901234567890.9999999Q;
Failure to emit a diagnostic in conformant mode is an indication
that the compiler is broken.

I actually disagree, but at any rate a simple output of "This
compilation accepts non-standard gubris" will suffice. The
standard does not specify quality.

12345678901234567890.9999999Q is a syntax error in standard C. For
that matter, so is qfloat unless it's been declared somewhere
(presumably as a typedef). Diagnostics are required for violations of
syntax rules and of constraints.

So the "123.456Q" syntax is a valid extension (since no strictly
conforming program can use it), but the compiler must still issue a
diagnostic -- which, as you say, can be as simple as "Thank you for
using this wonderful extension".

And of course no diagnostic is required if the compiler is invoked in
a non-conforming mode (but then if the compiler is non-conforming,
then the standard requires absolutely *nothing* of it).

I want to make it clear (also) that I actually like Jacob's qfloat
extension.

If I had my 'druthers, I would have C compilers support:
1. 4 byte float (IEEE format).
2. 8 byte double (IEEE format).
3. 16 byte long double (IEEE format).
4a. X byte extended precision (IEEE format).
4b. X byte extended precision (specified format). {Jacob's/Moshier's
qfloat goes here}
5. All of the above in Complex numbers

I would also like to see 0.5 ULP accuracy guarantees (with valid range
for those accuracies) for all math library functions and arithemetic
operations.
While we are at it, it would also be nice to have interval arithmetic
data type and a native exponentiation operator.

But I think those sorts of things are more likely to happen in
Fortran, where the chief concern is 'Formula Translation' -- that is
to say, doing math.
C tends to be more of the "Let's write an operating system" language
with math tossed in as an afterthought.

 

[CBFalconer]

.... snip ...


I want to make it clear (also) that I actually like Jacob's
qfloat extension.

That's fine, as an extension. It should require some sort of
operator selection to enable it, without which it should trigger an
error or warning.

 

[jacob navia]

That's fine, as an extension. It should require some sort of
operator selection to enable it, without which it should trigger an
error or warning.

It will not work if you do not include

#include <qfloat.h>

 

[lawrence.jones]

I would also like to see 0.5 ULP accuracy guarantees (with valid range
for those accuracies) for all math library functions and arithemetic
operations.

While that's certainly reasonable for many operations, experts in the
field (which I am not) have told me that it is extraordinarily difficult
to achieve for some of the library functions. Even 1 ULP is challenging
in some cases.

While we are at it, it would also be nice to have interval arithmetic
data type and a native exponentiation operator.

There's already a native exponentiation operator, although it's spelled
a bit funny: pow().

C tends to be more of the "Let's write an operating system" language
with math tossed in as an afterthought.

Fred Tydeman has been making a valiant effort to correct that with his
floating point test suite:

<http://www.tybor.com/>

-Larry Jones

Kicking dust is the only part of this game we really like. -- Calvin

 

[user923005]

While that's certainly reasonable for many operations, experts in the
field (which I am not) have told me that it is extraordinarily difficult
to achieve for some of the library functions.  Even 1 ULP is challenging
in some cases.

Sure, and some places it is simply impossible (e.g. sin(x) for x a
large number).
I don't want more than what is possible, but I would like to see error
ranges specified for the library something like Cephes has done at
least.

There's already a native exponentiation operator, although it's spelled
a bit funny: pow().

Not nearly as natural as an operator.
Fortran's two asterisks won't work for C, because of C's notation, but
I would like to see a more natural nomenclature. Sure, it's pure
syntactic sugar. But I've got a sweet tooth.

Fred Tydeman has been making a valiant effort to correct that with his
floating point test suite:

        <http://www.tybor.com/>

That stuff looks very interesting.

 

[CBFalconer]

It will not work if you do not include

#include <qfloat.h>

That's a quality problem. The failure will not indicate that it is
due to the use of a non-standard extension.

 

[user923005]

That's a quality problem.  The failure will not indicate that it is
due to the use of a non-standard extension.

How is this different from any other library that relies upon header
files?
If I fail to include the requisite header files, I can expect any sort
of bad thing to happen, especially if macros and/or data structures
are defined in the header.

 

[pete]

While that's certainly reasonable for many operations,
experts in the field (which I am not)
have told me that it is extraordinarily difficult
to achieve for some of the library functions.
Even 1 ULP is challenging in some cases.


There's already a native exponentiation operator,
although it's spelled a bit funny: pow().

That's one of the tough ones to get accuracy.

Here's my P.J. Plauger quote on that topic:
"We used to do successive multiplication, until we discovered that
accuracy degrades quickly with that approach. The only really
safe way to evaluate pow(x, y) accurately is to compute
exp(y * ln(x)) to extra internal precision. (Took us a lot of
rewrites, and a lot of careful testing, to find that out.) "

http://groups.google.com/group/comp.lang.c/msg/e7cff29955d4971b

 

[user923005]

That's one of the tough ones to get accuracy.

Here's my P.J. Plauger quote on that topic:
"We used to do successive multiplication, until we discovered that
 accuracy degrades quickly with that approach. The only really
 safe way to evaluate pow(x, y) accurately is to compute
 exp(y * ln(x)) to extra internal precision. (Took us a lot of
 rewrites, and a lot of careful testing, to find that out.) "

http://groups.google.com/group/comp.lang.c/msg/e7cff29955d4971b

Cephes uses the same technique:
/* pow.c

* Power function
*
*
*
* SYNOPSIS:
*
* double x, y, z, pow();
*
* z = pow( x, y );
*
*
*
* DESCRIPTION:
*
* Computes x raised to the yth power. Analytically,
*
* x**y = exp( y log(x) ).
*
* Following Cody and Waite, this program uses a lookup table
* of 2**-i/16 and pseudo extended precision arithmetic to
* obtain an extra three bits of accuracy in both the logarithm
* and the exponential.
*
*
*
* ACCURACY:
*
* Relative error:
* arithmetic domain # trials peak rms
* IEEE -26,26 30000 4.2e-16 7.7e-17
* DEC -26,26 60000 4.8e-17 9.1e-18
* 1/26 < x < 26, with log(x) uniformly distributed.
* -26 < y < 26, y uniformly distributed.
* IEEE 0,8700 30000 1.5e-14 2.1e-15
* 0.99 < x < 1.01, 0 < y < 8700, uniformly distributed.
*
*
* ERROR MESSAGES:
*
* message condition value returned
* pow overflow x**y > MAXNUM INFINITY
* pow underflow x**y < 1/MAXNUM 0.0
* pow domain x<0 and y noninteger 0.0
*
*/

 

[P.J. Plauger]

While that's certainly reasonable for many operations, experts in the
field (which I am not) have told me that it is extraordinarily difficult
to achieve for some of the library functions. Even 1 ULP is challenging
in some cases.

Sure, and some places it is simply impossible (e.g. sin(x) for x a
large number).

[pjp] It's not impossible -- we compute sin to 1 ulp for *all* finite
values -- but it's also not worth the effort for sufficiently large
values. It's a rare program indeed that makes sensible use of
large angular values represented in floating point.

I don't want more than what is possible, but I would like to see error
ranges specified for the library something like Cephes has done at
least.

There's already a native exponentiation operator, although it's spelled
a bit funny: pow().

Not nearly as natural as an operator.
Fortran's two asterisks won't work for C, because of C's notation,

[pjp] C++ sorta gets away with >> meaning different things in
different contexts, but I basically agree. Nixon's rule applies:
You could do it, but it would be wrong.


but
I would like to see a more natural nomenclature. Sure, it's pure
syntactic sugar. But I've got a sweet tooth.

Fred Tydeman has been making a valiant effort to correct that with his
floating point test suite:

<http://www.tybor.com/>

That stuff looks very interesting.

[pjp] It is *extremely* interesting, at least if you're a floating-point
junkie. We've been using Tydeman's suite for years to help keep
ourselves honest. It's nasty.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com