468,462 Members | 1,809 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 468,462 developers. It's quick & easy.

Multi precision floating point

Dear all,

I want to do multiprecision floating point, i.e. I want
to go beyond single precision, double precision and have
quadruple precision, octuple precision and the like,
and possibly with high speed.

What would be the possible alternatives?
Thanks for any help

Mathieu
Nov 28 '07
137 5991
On Mon, 17 Dec 2007 01:56:36 +0000, David Thompson wrote:
On Sat, 1 Dec 2007 11:47:43 +0000 (UTC), Harald van D?k
<tr*****@gmail.comwrote:
>On Sat, 01 Dec 2007 11:14:58 +0000, Mark McIntyre wrote:
<snip: about Navia/lcc-win32. YA.>
However once you add extensions, you no longer have ISO C. You have C
with Extensions. Please have the grace to call it that.

There is not a single ISO C compiler that doesn't have any extensions,
nor will there or can there ever be for the current and previous
standards. Extensions are required to write the standard headers.

You need some semantics beyond those guaranteed by the standard, but
they don't have to actually be extensions. On a bare system with
memory-mapped I/O and some not too unreasonable restrictions on calling
conventions, I think you only need the implementation definition for
pointer computations and conversions. And in principle you could have an
OS which effectively provides (emulates) the same thing, although I
can't think of any that have.

What you can't do is write all of the library _portably_. But
implementation-specific = unportable does not require extensions.
offsetof is required to be defined in the standard headers, not merely
declared, and its definition requires extensions. All possible
definitions that only rely on what standard C calls undefined behaviour
make use of offsetof in a context requiring a constant expression a
constraint violation. So either the syntax must be extended, or a
constraint must not be enforced by a hard error, or an implementation
must rely on the permission that "An implementation may accept other
forms of constant expressions". In all cases, an extension is required.

C99's <tgmath.hhas similar problems.
Dec 17 '07 #101
=?UTF-8?q?Harald_van_D=C4=B3k?= wrote:
offsetof is required to be defined in the standard headers, not merely
declared, and its definition requires extensions.
How can code which isn't required to be written in C language,
possibley require extensions?

--
pete
Dec 17 '07 #102
On Dec 16, 9:54 pm, Harald van Dijk <true...@gmail.comwrote:
On Mon, 17 Dec 2007 01:56:36 +0000, David Thompson wrote:
On Sat, 1 Dec 2007 11:47:43 +0000 (UTC), Harald van D?k
<true...@gmail.comwrote:
On Sat, 01 Dec 2007 11:14:58 +0000, Mark McIntyre wrote:
<snip: about Navia/lcc-win32. YA.>
However once you add extensions, you no longer have ISO C. You have C
with Extensions. Please have the grace to call it that.
There is not a single ISO C compiler that doesn't have any extensions,
nor will there or can there ever be for the current and previous
standards. Extensions are required to write the standard headers.
You need some semantics beyond those guaranteed by the standard, but
they don't have to actually be extensions. On a bare system with
memory-mapped I/O and some not too unreasonable restrictions on calling
conventions, I think you only need the implementation definition for
pointer computations and conversions. And in principle you could have an
OS which effectively provides (emulates) the same thing, although I
can't think of any that have.
What you can't do is write all of the library _portably_. But
implementation-specific = unportable does not require extensions.

offsetof is required to be defined in the standard headers, not merely
declared, and its definition requires extensions. All possible
definitions that only rely on what standard C calls undefined behaviour
make use of offsetof in a context requiring a constant expression a
constraint violation. So either the syntax must be extended, or a
constraint must not be enforced by a hard error, or an implementation
must rely on the permission that "An implementation may accept other
forms of constant expressions". In all cases, an extension is required.

C99's <tgmath.hhas similar problems.- Hide quoted text -

- Show quoted text -
By the same argument,

i++;

requires an extension in some sense, because it is probably
accomplished using assembly.

The compiler can use any magic it likes to accomplish anything by any
manner. That's not an extension, as long as it is part of the
language. It is highly likely that your compilers memcpy() is
implemented in assembly and not in C, because it may behave more
efficiently given certain conditions like alignments or object sizes.
There's nothing wrong with that and it is not an extension.

An extension is using an unnamed struct. An extension is a type
called qfloat that requires a Q and the end of the data item. An
extension is a string function called strdup(). None of these things
are defined by the language.

There is nothing wrong with any of them. In fact, I like all of
them. But none of them are C language. It should be obvious that
this is true because if you use any of them, then your code is not
guaranteed to compile on a conforming C compiler.

Let's make a simple definition that everyone can agree on:

If it compiles on every ideal, conforming C compiler then it requires
only the C language.
If it fails to compile on any conforming C compiler then it requires
an extension.

Dec 17 '07 #103
user923005 wrote:
An extension is using an unnamed struct. An extension is a type
called qfloat that requires a Q and the end of the data item. An
extension is a string function called strdup(). None of these things
are defined by the language.

There is nothing wrong with any of them. In fact, I like all of
them. But none of them are C language. It should be obvious that
this is true because if you use any of them, then your code is not
guaranteed to compile on a conforming C compiler.

Let's make a simple definition that everyone can agree on:

If it compiles on every ideal, conforming C compiler then it requires
only the C language.
If it fails to compile on any conforming C compiler then it requires
an extension.
If you say that strdup() is an extension, this means that
you get only standard C functions to do anything.

GREAT!

No network
No graphics
No threads
No editors more complex than edlin
No debuggers

Actually your "C" is not able to do anything useful besides
pleasing the regulars in comp.std.c.
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32
Dec 17 '07 #104
On Mon, 17 Dec 2007 11:57:08 -0800, user923005 wrote:
On Dec 16, 9:54 pm, Harald van D캐k <true...@gmail.comwrote:
>On Mon, 17 Dec 2007 01:56:36 +0000, David Thompson wrote:
On Sat, 1 Dec 2007 11:47:43 +0000 (UTC), Harald van D?k
<true...@gmail.comwrote:
>On Sat, 01 Dec 2007 11:14:58 +0000, Mark McIntyre wrote:
<snip: about Navia/lcc-win32. YA.>
However once you add extensions, you no longer have ISO C. You
have C with Extensions. Please have the grace to call it that.
>There is not a single ISO C compiler that doesn't have any
extensions, nor will there or can there ever be for the current and
previous standards. Extensions are required to write the standard
headers.
You need some semantics beyond those guaranteed by the standard, but
they don't have to actually be extensions. On a bare system with
memory-mapped I/O and some not too unreasonable restrictions on
calling conventions, I think you only need the implementation
definition for pointer computations and conversions. And in principle
you could have an OS which effectively provides (emulates) the same
thing, although I can't think of any that have.
What you can't do is write all of the library _portably_. But
implementation-specific = unportable does not require extensions.

offsetof is required to be defined in the standard headers, not merely
declared, and its definition requires extensions. All possible
definitions that only rely on what standard C calls undefined behaviour
make use of offsetof in a context requiring a constant expression a
constraint violation. So either the syntax must be extended, or a
constraint must not be enforced by a hard error, or an implementation
must rely on the permission that "An implementation may accept other
forms of constant expressions". In all cases, an extension is required.

C99's <tgmath.hhas similar problems.- Hide quoted text -

- Show quoted text -

By the same argument,

i++;

requires an extension in some sense, because it is probably accomplished
using assembly.
No, it doesn't require an extension, because it can be interpreted by a
compiler accepting exactly the language as defined by the C standard.
The compiler can use any magic it likes to accomplish anything by any
manner. That's not an extension, as long as it is part of the language.
The definition of offsetof is required to become part of the language
accepted by the implementation, I believe.
It is highly likely that your compilers memcpy() is implemented in
assembly and not in C, because it may behave more efficiently given
certain conditions like alignments or object sizes. There's nothing
wrong with that and it is not an extension.
That depends on how memcpy is defined.

string.h:
// ...
void *memcpy(void *restrict, const void *restrict, size_t);
// ...

string.asm:
_memcpy:
# inefficient assembly implementation
jmp _memmove

In this case, no extension is required, since the assembly version of
memcpy is not read at all by the compiler.

[...]
Let's make a simple definition that everyone can agree on:

If it compiles on every ideal, conforming C compiler then it requires
only the C language.
If it fails to compile on any conforming C compiler then it requires an
extension.
Sure, this means

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

does not make use of an extension. I can agree on that. But how is
offsetof defined? Let's say it is defined in <stddef.has

typedef char __char;
#define offsetof(s, m) ((__char *) &((s *) 0)->m - (__char *) (s *) 0)

Now, after expanding offsetof, it no longer compiles on every ideal,
conforming C compiler. In fact, it violates a constraint which would
cause at least one implementation to reject the program with a hard
error. So by your definition, this _implementation of_ offsetof does make
use of an extension, unless I'm misunderstanding your message.
Dec 17 '07 #105
On Dec 17, 12:09 pm, jacob navia <ja...@nospam.comwrote:
user923005 wrote:
An extension is using an unnamed struct. An extension is a type
called qfloat that requires a Q and the end of the data item. An
extension is a string function called strdup(). None of these things
are defined by the language.
There is nothing wrong with any of them. In fact, I like all of
them. But none of them are C language. It should be obvious that
this is true because if you use any of them, then your code is not
guaranteed to compile on a conforming C compiler.
Let's make a simple definition that everyone can agree on:
If it compiles on every ideal, conforming C compiler then it requires
only the C language.
If it fails to compile on any conforming C compiler then it requires
an extension.

If you say that strdup() is an extension,
It is an extension.
this means that
you get only standard C functions to do anything.

GREAT!
I agree.
No network
No graphics
No threads
No editors more complex than edlin
No debuggers
Right, the C language does not specify any of those things.
Actually your "C" is not able to do anything useful besides
pleasing the regulars in comp.std.c.
No. My C does everything that I need it to do. I guess that any of
the above jobs will be implemented by some vendor specific library or
even by another standard, if possible.
I do not have any problem with a C compiler that provides a TCP/IP
implementation, an OpenGL implementation, threads. The tools provided
like GUI and debugger are totally irrelevant to the point. I can use
a nice GUI to debug a fully compiliant program or a program that uses
extensions. The same for a debugger. An editor that runs in line
mode like Edlin is no more a part of the language than Eclipse is.

If you think that by adding threading to your compiler you have
enlarged the C language then you are simply incompetent. It means
that you do not understand the basic fundamentals of what you are
doing.
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatiquehttp://www.cs.virginia.edu/~lcc-win32- Hide quoted text -

- Show quoted text -
Dec 17 '07 #106
On Dec 17, 12:13 pm, Harald van Dijk <true...@gmail.comwrote:
On Mon, 17 Dec 2007 11:57:08 -0800, user923005 wrote:
On Dec 16, 9:54 pm, Harald van Dijk <true...@gmail.comwrote:
On Mon, 17 Dec 2007 01:56:36 +0000, David Thompson wrote:
On Sat, 1 Dec 2007 11:47:43 +0000 (UTC), Harald van D?k
<true...@gmail.comwrote:
On Sat, 01 Dec 2007 11:14:58 +0000, Mark McIntyre wrote:
<snip: about Navia/lcc-win32. YA.>
However once you add extensions, you no longer have ISO C. You
have C with Extensions. Please have the grace to call it that.
There is not a single ISO C compiler that doesn't have any
extensions, nor will there or can there ever be for the current and
previous standards. Extensions are required to write the standard
headers.
You need some semantics beyond those guaranteed by the standard, but
they don't have to actually be extensions. On a bare system with
memory-mapped I/O and some not too unreasonable restrictions on
calling conventions, I think you only need the implementation
definition for pointer computations and conversions. And in principle
you could have an OS which effectively provides (emulates) the same
thing, although I can't think of any that have.
What you can't do is write all of the library _portably_. But
implementation-specific = unportable does not require extensions.
offsetof is required to be defined in the standard headers, not merely
declared, and its definition requires extensions. All possible
definitions that only rely on what standard C calls undefined behaviour
make use of offsetof in a context requiring a constant expression a
constraint violation. So either the syntax must be extended, or a
constraint must not be enforced by a hard error, or an implementation
must rely on the permission that "An implementation may accept other
forms of constant expressions". In all cases, an extension is required.
C99's <tgmath.hhas similar problems.- Hide quoted text -
- Show quoted text -
By the same argument,
i++;
requires an extension in some sense, because it is probably accomplished
using assembly.

No, it doesn't require an extension, because it can be interpreted by a
compiler accepting exactly the language as defined by the C standard.
The compiler can use any magic it likes to accomplish anything by any
manner. That's not an extension, as long as it is part of the language.

The definition of offsetof is required to become part of the language
accepted by the implementation, I believe.
It is highly likely that your compilers memcpy() is implemented in
assembly and not in C, because it may behave more efficiently given
certain conditions like alignments or object sizes. There's nothing
wrong with that and it is not an extension.

That depends on how memcpy is defined.

string.h:
// ...
void *memcpy(void *restrict, const void *restrict, size_t);
// ...

string.asm:
_memcpy:
# inefficient assembly implementation
jmp _memmove

In this case, no extension is required, since the assembly version of
memcpy is not read at all by the compiler.

[...]
Let's make a simple definition that everyone can agree on:
If it compiles on every ideal, conforming C compiler then it requires
only the C language.
If it fails to compile on any conforming C compiler then it requires an
extension.

Sure, this means

#include <stddef.h>
struct S {
int m;};

enum {
zero = offsetof(struct S, m)

};

does not make use of an extension. I can agree on that. But how is
offsetof defined? Let's say it is defined in <stddef.has

typedef char __char;
#define offsetof(s, m) ((__char *) &((s *) 0)->m - (__char *) (s *) 0)

Now, after expanding offsetof, it no longer compiles on every ideal,
conforming C compiler. In fact, it violates a constraint which would
cause at least one implementation to reject the program with a hard
error. So by your definition, this _implementation of_ offsetof does make
use of an extension, unless I'm misunderstanding your message.- Hide quoted text -

- Show quoted text -
If you expand your macro, so that the code does this, then you have
indeed violated the C language because that is very likely to fail.
#define offsetof(s, m) ((__char *) &((s *) 0)->m - (__char *) (s *) 0)

On the other hand, if you simply use the offsetof() macro and trust
your implementation to implement it as it should then there is no
violation of the standard (indeed, if you do it any other way then you
'have a screw loose').

Similarly,

i++;

may actually be implemented as:

_asm INC EAX;

which is not part of the C language, but why should I care? I am
responsible to write compliant code and the compiler is responsible to
translate it into machine instructions. Besides asking how does
offsetof() work, we may as well ask how malloc() works etc. Chances
are good that a large percentage of the actual internals of a compiler
require assembly language trickery. But any of that is neither here
nor there and is simply covered in the implementation details.
Whether they use assembly or library calls or a giant pile of
interpreted Lisp in the background isn't all that important. They can
accomplish the goal any way that they like, as long as it does what is
promised. I think that your major point is "A C compiler cannot be
accomplished strictly using C, because an extension is going to be
needed somewhere along the way." I don't think that anyone disagrees
with that (or if they do, the disagreement is not important). What is
important is that they accomplish the goals with whatever means are at
their disposal and that if I perform my part of the bargain (writing
correct C code) then they must also accomplish their part of the
bargain (correctly translating the C code as required by the
standard).

A conforming program should compile on any C compiler that claims to
conform. If it does not compile and the vendor claims to have a C
compiler then I have the right to complain and ask that the defect be
fixed. If the defect is not fixed in a timely manner then I have a
right to ask for my money back.
Dec 17 '07 #107
On Mon, 17 Dec 2007 12:36:29 -0800, user923005 wrote:
If you expand your macro, so that the code does this, then you have
indeed violated the C language because that is very likely to fail.
#define offsetof(s, m) ((__char *) &((s *) 0)->m - (__char *) (s *) 0)

On the other hand, if you simply use the offsetof() macro and trust your
implementation to implement it as it should then there is no violation
of the standard (indeed, if you do it any other way then you 'have a
screw loose').
Right, but...
Similarly,

i++;

may actually be implemented as:

_asm INC EAX;

which is not part of the C language, but why should I care? I am
responsible to write compliant code and the compiler is responsible to
translate it into machine instructions. Besides asking how does
offsetof() work, we may as well ask how malloc() works etc.
[...]

....my point was that the definition of offsetof must be in a way that is
accepted by the C compiler, and the definition of i++ or the definition
of malloc don't need to be.
Dec 17 '07 #108
On Dec 17, 12:39 pm, Harald van Dijk <true...@gmail.comwrote:
On Mon, 17 Dec 2007 12:36:29 -0800, user923005 wrote:
If you expand your macro, so that the code does this, then you have
indeed violated the C language because that is very likely to fail.
#define offsetof(s, m) ((__char *) &((s *) 0)->m - (__char *) (s *) 0)
On the other hand, if you simply use the offsetof() macro and trust your
implementation to implement it as it should then there is no violation
of the standard (indeed, if you do it any other way then you 'have a
screw loose').

Right, but...
Similarly,
i++;
may actually be implemented as:
_asm INC EAX;
which is not part of the C language, but why should I care? I am
responsible to write compliant code and the compiler is responsible to
translate it into machine instructions. Besides asking how does
offsetof() work, we may as well ask how malloc() works etc.

[...]

...my point was that the definition of offsetof must be in a way that is
accepted by the C compiler, and the definition of i++ or the definition
of malloc don't need to be.
And my point is that it is irrelevant if part of the C compiler is
accomplished in C or with something else.
Dec 17 '07 #109
user923005 wrote:
>
If you think that by adding threading to your compiler you have
enlarged the C language then you are simply incompetent. It means
that you do not understand the basic fundamentals of what you are
doing.
I am "incompetent" as Hans J. Boehm:

"Threads cannot be implemented as Libraries"

http://www.hpl.hp.com/techreports/2004/HPL-2004-209.pdf

Before insulting other people, read the literature, turn on your brain,
and then, discuss without getting emotional.

OK?

--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32
Dec 17 '07 #110
On Dec 17, 1:50 pm, jacob navia <ja...@nospam.comwrote:
user923005 wrote:
If you think that by adding threading to your compiler you have
enlarged the C language then you are simply incompetent. It means
that you do not understand the basic fundamentals of what you are
doing.

I am "incompetent" as Hans J. Boehm:

"Threads cannot be implemented as Libraries"
Non-sequiter. I have made no claims counter to what "Mr. Garbage
Collector" says.
http://www.hpl.hp.com/techreports/2004/HPL-2004-209.pdf
I have read about garbage collection before. It does not belong in C
or C++, by the way.
Before insulting other people, read the literature, turn on your brain,
and then, discuss without getting emotional.
A great policy.
OK?
I agree that it is good advice, and I think you should follow it.
Dec 17 '07 #111
On Mon, 17 Dec 2007 12:58:02 -0800, user923005 wrote:
On Dec 17, 12:39 pm, Harald van D캐k <true...@gmail.comwrote:
>...my point was that the definition of offsetof must be in a way that
is accepted by the C compiler, and the definition of i++ or the
definition of malloc don't need to be.

And my point is that it is irrelevant if part of the C compiler is
accomplished in C or with something else.
You've demonstrated your point by comparing my example to a too
significantly different example, for reasons I've explained in the
message you replied to. It's possible you're right, but you do need some
argumentation to back it up if you want to convince me or others.
Dec 17 '07 #112
On Mon, 17 Dec 2007 13:22:25 -0800, Keith Thompson wrote:
It's going to be difficult to resolve this question, since the standard
doesn't provide a rigorous definition of the word "extension".
Yes, that's unfortunate, and it's also unfortunate that the rationale
doesn't help explain.
Dec 17 '07 #113
On Dec 17, 1:58 pm, Harald van Dijk <true...@gmail.comwrote:
On Mon, 17 Dec 2007 12:58:02 -0800, user923005 wrote:
On Dec 17, 12:39 pm, Harald van Dijk <true...@gmail.comwrote:
...my point was that the definition of offsetof must be in a way that
is accepted by the C compiler, and the definition of i++ or the
definition of malloc don't need to be.
And my point is that it is irrelevant if part of the C compiler is
accomplished in C or with something else.

You've demonstrated your point by comparing my example to a too
significantly different example, for reasons I've explained in the
message you replied to. It's possible you're right, but you do need some
argumentation to back it up if you want to convince me or others.
I retract my point that you cannot do offsetof() using standard C. I
was wrong about that.

Here is the relevant bit from the standard:
7.17 Common definitions <stddef.h>
1 The following types and macros are defined in the standard header
<stddef.h>. Some are also defined in other headers, as noted in their
respective subclauses.
2 The types are
ptrdiff_t
which is the signed integer type of the result of subtracting two
pointers;
size_t
which is the unsigned integer type of the result of the sizeof
operator; and
wchar_t
which is an integer type whose range of values can represent distinct
codes for all members of the largest extended character set specified
among the supported locales; the null character shall have the code
value zero and each member of the basic character set shall have a
code value equal to its value when used as the lone character in an
integer character constant.
3 The macros are
NULL
which expands to an implementation-defined null pointer constant; and
offsetof(type, member-designator)
which expands to an integer constant expression that has type size_t,
the value of which is the offset in bytes, to the structure member
(designated by member-designator), from the beginning of its structure
(designated by type). The type and member designator shall be such
that given static type t; then the expression &(t.member-designator)
evaluates to an address constant. (If the specified member is a bit-
field, the behavior is undefined.)
Forward references: localization (7.11).

Therefore, use of the offsetof() macro requires nothing whatsoever
beyond standard C.
Think about it, and you will see my point.
Dec 17 '07 #114
user923005 wrote:
On Dec 17, 1:50 pm, jacob navia <ja...@nospam.comwrote:
>user923005 wrote:
>>If you think that by adding threading to your compiler you have
enlarged the C language then you are simply incompetent. It means
that you do not understand the basic fundamentals of what you are
doing.
I am "incompetent" as Hans J. Boehm:

"Threads cannot be implemented as Libraries"

Non-sequiter. I have made no claims counter to what "Mr. Garbage
Collector" says.
Strange, I understood that you were against adding threads to the
language (i.e. within the compiler)

Or what then was your position?

It would be nice if you speak clearly then.
>>If you think that by adding threading to your compiler you have
enlarged the C language then you are simply incompetent. It means
that you do not understand the basic fundamentals of what you are
doing.
I understand that as you being against adding threads to the language
itself.
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32
Dec 17 '07 #115
Harald van D캐k wrote:
On Mon, 17 Dec 2007 13:22:25 -0800, Keith Thompson wrote:
>It's going to be difficult to resolve this question, since the standard
doesn't provide a rigorous definition of the word "extension".

Yes, that's unfortunate, and it's also unfortunate that the rationale
doesn't help explain.
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.
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32
Dec 17 '07 #116
On Mon, 17 Dec 2007 23:13:07 +0100, jacob navia wrote:
Harald van D캐k wrote:
>On Mon, 17 Dec 2007 13:22:25 -0800, Keith Thompson wrote:
>>It's going to be difficult to resolve this question, since the
standard doesn't provide a rigorous definition of the word
"extension".

Yes, that's unfortunate, and it's also unfortunate that the rationale
doesn't help explain.

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.
Dec 17 '07 #117
On Mon, 17 Dec 2007 14:08:41 -0800, user923005 wrote:
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.
Dec 17 '07 #118
On Dec 17, 2:08 pm, jacob navia <ja...@nospam.comwrote:
user923005 wrote:
On Dec 17, 1:50 pm, jacob navia <ja...@nospam.comwrote:
user923005 wrote:
>If you think that by adding threading to your compiler you have
enlarged the C language then you are simply incompetent. It means
that you do not understand the basic fundamentals of what you are
doing.
I am "incompetent" as Hans J. Boehm:
"Threads cannot be implemented as Libraries"
Non-sequiter. I have made no claims counter to what "Mr. Garbage
Collector" says.

Strange, I understood that you were against adding threads to the
language (i.e. within the compiler)
Definintely a comprehension problem on your part. I suggested that
the C language does not define threads. I suggested that threads can
be supplied by an implementation.
Or what then was your position?

It would be nice if you speak clearly then.
My position is very clear to a clear thinker.
>>If you think that by adding threading to your compiler you have
>>enlarged the C language then you are simply incompetent. It means
>>that you do not understand the basic fundamentals of what you are
>>doing.

I understand that as you being against adding threads to the language
itself.
I do not know if it is a good idea to add threads to the language or
not. I will say that if threads are added to the language, then they
must be added by the standards committee. If an implementor adds
threads to the language then this does not extend the C language but
(rather) creates an extension to the C language.

Do you understand the difference between:
The language C with threads added to it.
(A vendor cannot do this, only the standards committee can.)

And
The C language extended by threads.
(A vendor can do this.)

?

By the way, I think that adding garbage collection to C would be a
terrible mistake. If that happens, then it will no longer be possible
to create reliable real time versions of the C language.
Dec 17 '07 #119
On Mon, 17 Dec 2007 14:06:34 -0800, user923005 wrote:
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?
Dec 17 '07 #120
On Dec 17, 2:13 pm, jacob navia <ja...@nospam.comwrote:
Harald van Dijk wrote:
On Mon, 17 Dec 2007 13:22:25 -0800, Keith Thompson wrote:
It's going to be difficult to resolve this question, since the standard
doesn't provide a rigorous definition of the word "extension".
Yes, that's unfortunate, and it's also unfortunate that the rationale
doesn't help explain.

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.
I do not believe than anyone has ever argued this point.
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.
Dec 17 '07 #121
On Dec 17, 3:38 pm, Harald van Dijk <true...@gmail.comwrote:
On Mon, 17 Dec 2007 14:06:34 -0800, user923005 wrote:
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?
Do we agree (then) that use of offsetof() does not require a language
extension?
If so, then I do not understand what the issue is.
Dec 17 '07 #122
On Mon, 17 Dec 2007 14:27:18 -0800, user923005 wrote:
On Dec 17, 3:38 pm, Harald van D캐k <true...@gmail.comwrote:
>On Mon, 17 Dec 2007 14:06:34 -0800, user923005 wrote:
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?

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.)
Dec 17 '07 #123
On Mon, 17 Dec 2007 18:28:23 -0500, pete wrote:
=?UTF-8?q?Harald_van_D=C4=B3k?= wrote:
>On Mon, 17 Dec 2007 17:53:48 -0500, pete wrote:
/* BEGIN putc.c */

#include <stdio.h>

#define str(s) # s
#define xstr(s) str(s)

int main(void)
{
puts(xstr(putc('H', stdio)));
putchar('\n');
return 0;
}

/* END putc.c */

This is not a valid C program.

It is a "conforming program".
True, though not a "correct program".
Dec 17 '07 #124
Philip Potter wrote:
>
Harald van D캐k wrote:
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.
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.

--
pete
Dec 18 '07 #125
pete <pf*****@mindspring.comwrites:
Philip Potter wrote:
>Harald van D횆쨀k wrote:
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.

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 (The_Other_Keith) <ks***@mib.org>
Looking for software development work in the San Diego area.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Dec 18 '07 #126
user923005 wrote:
jacob navia <ja...@nospam.comwrote:
.... snip ...
>
>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.

I do not believe than anyone has ever argued this point.
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.

--
Merry Christmas, Happy Hanukah, Happy New Year
Joyeux Noel, Bonne Annee.
Chuck F (cbfalconer at maineline dot net)
<http://cbfalconer.home.att.net>

--
Posted via a free Usenet account from http://www.teranews.com

Dec 20 '07 #127
CBFalconer <cb********@yahoo.comwrites:
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).

--
Keith Thompson (The_Other_Keith) <ks***@mib.org>
Looking for software development work in the San Diego area.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Dec 20 '07 #128
On Dec 20, 11:52 am, Keith Thompson <ks...@mib.orgwrote:
CBFalconer <cbfalco...@yahoo.comwrites:
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.
Dec 20 '07 #129
user923005 wrote:
Keith Thompson <ks...@mib.orgwrote:
.... snip ...
>
>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.
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.

--
Merry Christmas, Happy Hanukah, Happy New Year
Joyeux Noel, Bonne Annee.
Chuck F (cbfalconer at maineline dot net)
<http://cbfalconer.home.att.net>

--
Posted via a free Usenet account from http://www.teranews.com

Dec 21 '07 #130
CBFalconer wrote:
user923005 wrote:
>Keith Thompson <ks...@mib.orgwrote:
... snip ...
>>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.

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>

--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32
Dec 21 '07 #131
user923005 <dc*****@connx.comwrote:
>
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
Dec 21 '07 #132
On Dec 21, 11:09*am, lawrence.jo...@siemens.com wrote:
user923005 <dcor...@connx.comwrote:
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.
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.
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().
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.
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/>
That stuff looks very interesting.
Dec 21 '07 #133
jacob navia wrote:
CBFalconer wrote:
>user923005 wrote:
>>Keith Thompson <ks...@mib.orgwrote:
... snip ...
>>>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.

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>
That's a quality problem. The failure will not indicate that it is
due to the use of a non-standard extension.

--
Merry Christmas, Happy Hanukah, Happy New Year
Joyeux Noel, Bonne Annee.
Chuck F (cbfalconer at maineline dot net)
<http://cbfalconer.home.att.net>

--
Posted via a free Usenet account from http://www.teranews.com

Dec 21 '07 #134
On Dec 21, 2:41*pm, CBFalconer <cbfalco...@yahoo.comwrote:
jacob navia wrote:
CBFalconer wrote:
user923005 wrote:
Keith Thompson <ks...@mib.orgwrote:
... snip ...
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.
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>

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.
Dec 21 '07 #135
la************@siemens.com wrote:
>
user923005 <dc*****@connx.comwrote:

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().
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....cff29955d4971b

--
pete
Dec 22 '07 #136
On Dec 21, 4:00*pm, pete <pfil...@mindspring.comwrote:
lawrence.jo...@siemens.com wrote:
user923005 <dcor...@connx.comwrote:
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().

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....cff29955d4971b
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
*
*/
Dec 22 '07 #137
"user923005" <dc*****@connx.comwrote in message
news:ec**********************************@e23g2000 prf.googlegroups.com...
On Dec 21, 11:09 am, lawrence.jo...@siemens.com wrote:
user923005 <dcor...@connx.comwrote:
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.
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.
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().
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.
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/>
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

Dec 22 '07 #138

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

24 posts views Thread by Philipp | last post: by
4 posts views Thread by Roger Leigh | last post: by
2 posts views Thread by Brian van den Broek | last post: by
15 posts views Thread by michael.mcgarry | last post: by
3 posts views Thread by Madan | last post: by
10 posts views Thread by Bo Yang | last post: by
reply views Thread by Charles Coldwell | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.