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  6565 
jacob navia <ja***@nospam.comwrites:
user923005 wrote:
>On Nov 30, 1:32 pm, jacob navia <ja...@nospam.comwrote:
>>Keith Thompson wrote:
[...]
>>>>3) Using operator overloading, I integrated this library
like a basic type into the language.
Where the phrase "the language" refers to something other than C.
No. All this extensions are compatible with the C standard as
I have explained thousand times in this newsgroup.
Note that the C standard does NOT forbid extensions
By the same logic, this is C code, since GCC compiles it:
[snip fortran code]
All extensions and proposals that I have argued over and
over produce always this brainless answers...
BRAVO user923005!
Your arguments show the sophistication your mind is capable of!
Yes, they do, but not in the way you mean. (Once again, *please* stop
trying to use sarcasm; you just don't have the knack.)
It's been stated in this thread that a Fortran program is not actually
accepted by gcc in a mode in which it acts as a conforming C compiler.
But consider a hypothetical compiler that (a) acts as a conforming C
compiler (let's say it's a fully conforming hosted C99
implementation), and (b) also acts as a conforming Fortran compiler.
Unless there are programs that are simultaneously legal C and legal
Fortran, but with different semantics, this is entirely possible. In
fact, it could easily be implemented as a wrapper that invokes a C
compiler for C programs, and a Fortran compiler for Fortran programs.
The handling of the full Fortran language in this manner can be viewed
as an *extension* provided by a conforming C implementation. As long
as this extension does not alter the behavior of any strictly
conforming C program, it's permitted by the standard. Thus, a
conforming C implementation *can* compile Fortran, and user923005 made
a valid point.
Similarly, a conforming C implementation *can* compile a C-like
language that incorporates operator overloading.
Incidentally, I don't believe that a C program can use operator
overloading without violating either a constraint or a syntax rule.
My understanding is that the existence of an extension does not
relieve the compiler of its obligation to issue a diagnostic for any
such program; after issuing the diagnostic, it's then free to go on
and handle the extension as it likes. (Of course, this applies only
in conforming mode; a compiler is perfectly free to *silently* accept
operator loading, or do anything else it likes, in a non-conforming
mode.)
So, in conforming mode, a compiler can either (a) reject the use of
operator overloading, or (b) accept it, but only after issuing a
diagnostic. Failure to issue the diagnostic would be a violation of
the standard.
(This is a fairly subtle argument, and it's possible that I'm
mistaken, but it was the result of a discussion in comp.std.c.)
--
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"
On Fri, 30 Nov 2007 18:44:15 -0800, Keith Thompson wrote:
But consider a hypothetical compiler that (a) acts as a conforming C
compiler (let's say it's a fully conforming hosted C99 implementation),
and (b) also acts as a conforming Fortran compiler. Unless there are
programs that are simultaneously legal C and legal Fortran, but with
different semantics, this is entirely possible.
Such programs exist.
/*
*/ #include <stdio.h /*
*/ int main(void) { /*
*/ puts("This is a C program"); /*
*/ } /*
print *, "This is a Fortran program"
end
*/
jacob navia wrote:
>>3) Using operator overloading, I integrated this library
like a basic type into the language.
You mean you've extended the language by adding a new type.
(KT wrote)
>Where the phrase "the language" refers to something other than C.
No. All this extensions are compatible with the C standard as
I have explained thousand times in this newsgroup.
Huh? Things like operator overloading are compatible with ISO C?
Note that the C standard does NOT forbid extensions
Correct.
However once you add extensions, you no longer have ISO C. You have C
with Extensions. Please have the grace to call it that.
Ian Collins wrote:
(replying to someone)
>Well, your compiler does not conform to the C standard *without* the
-ansic flag (for example declaring atof in math.h), so does it support
operator overloading *with* the -ansic flag? If not then it compiles C
when the -ansic flag is specified and something other than C that
supports operator overloading with it.
Just like gcc?
Quite possibly.
Does anyone here claim that gcc is a conforming ISO C implementation?
Does anyone here respond to posts with thinly veiled adverts for gcc?
jacob navia wrote:
>
All extensions and proposals that I have argued over and
over produce always this brainless answers...
BRAVO user923005!
Your arguments show the sophistication your mind is capable of!
Another example of why people take offense at your posts. You seem
incapable of posting any response that does not contain a personal
attack. Even when you make a valid point, you damage your case by
gratuitous ad hominem comments.
jacob navia wrote:
CBFalconer wrote:
>jacob navia wrote:
>>Keith Thompson wrote:
... snip ...
>>>Where the phrase "the language" refers to something other than C.
No. All this extensions are compatible with the C standard as
I have explained thousand times in this newsgroup.
Note that the C standard does NOT forbid extensions
True. However c.l.c does.
You are speaking for yourself... There is no approved c.l.c
consensus about this.
I hesitate to bother commenting on that but you're incorrect.
There is a consensus. You may not like it, but its there nonetheless.
On Sat, 01 Dec 2007 11:14:58 +0000, Mark McIntyre wrote:
jacob navia wrote:
>>>3) Using operator overloading, I integrated this library like a basic
type into the language.
You mean you've extended the language by adding a new type.
I believe you and jacob navia said the same thing here.
(KT wrote)
>>Where the phrase "the language" refers to something other than C.
No. All this extensions are compatible with the C standard as I have
explained thousand times in this newsgroup.
Huh? Things like operator overloading are compatible with ISO C?
Yes. It is possible for a compiler to support operator overloading in a
way that won't miscompile any correct standard C program.
>Note that the C standard does NOT forbid extensions
Correct.
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.
Mark McIntyre wrote:
jacob navia wrote:
>>>3) Using operator overloading, I integrated this library
like a basic type into the language.
You mean you've extended the language by adding a new type.
(KT wrote)
>>Where the phrase "the language" refers to something other than C.
No. All this extensions are compatible with the C standard as
I have explained thousand times in this newsgroup.
Huh? Things like operator overloading are compatible with ISO C?
>Note that the C standard does NOT forbid extensions
Correct.
However once you add extensions, you no longer have ISO C. You have C
with Extensions. Please have the grace to call it that.
It's possible to extend C in a fully conforming mode. All that's
required is that the extension either selects from among the options
when the C standard leaves the behavior unspecified, or is only
supported for programs that contains specific constructs which render
it's behavior undefined.
Jacob: are you claiming that operator overloading is supported in a
fully conforming mode of your compiler? I don't think that's likely, but
I'm willing to consider the possibility that it's true, but only if you
explain how this is the case.
If not, then Keith is correct. When your compiler is operating in
whatever mode it needs to be in to support operator overloading, in that
mode it does in fact compile a language which is not actually C, though
it may be similar.
James Kuyper wrote:
Mark McIntyre wrote:
>jacob navia wrote:
>>>>3) Using operator overloading, I integrated this library
like a basic type into the language.
You mean you've extended the language by adding a new type.
(KT wrote)
>>>Where the phrase "the language" refers to something other than C.
No. All this extensions are compatible with the C standard as
I have explained thousand times in this newsgroup.
Huh? Things like operator overloading are compatible with ISO C?
>>Note that the C standard does NOT forbid extensions
Correct.
However once you add extensions, you no longer have ISO C. You have C
with Extensions. Please have the grace to call it that.
It's possible to extend C in a fully conforming mode. All that's
required is that the extension either selects from among the options
when the C standard leaves the behavior unspecified, or is only
supported for programs that contains specific constructs which render
it's behavior undefined.
Jacob: are you claiming that operator overloading is supported in a
fully conforming mode of your compiler? I don't think that's likely, but
I'm willing to consider the possibility that it's true, but only if you
explain how this is the case.
You can write
int operator = 78;
etc.
"operator" is NOT a keyword. You can use it as a normal identifier.
If you write:
int operator+(someType a,someType b)
{
// ...
}
you are NOT in standard C and I am allowed to treat this non-conforming
code as I wish. For instance, by generating a function that will be
called when you write
someType a,b;
b = b+c;
since this code is AGAIN not conforming (you can't add two user defined
types).
I have respected the standard by
1) No new keywords
2) Only using non-standard constructs for my extension.
It is unfair to treat this extension as a "new language".
When you invoke the compiler with
-ansic however, all extensions are disabled, including
this one. The only exception is _stdcall.
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique http://www.cs.virginia.edu/~lcc-win32
jacob navia said:
<snip>
If you write:
int operator+(someType a,someType b)
{
// ...
}
you are NOT in standard C and I am allowed to treat this non-conforming
code as I wish.
Please discuss such extensions in a newsgroup devoted to that
implementation. If the OP wants to use lcc-win32 extensions, no doubt
he'll ask in a newsgroup devoted to that implementation.
For instance, by generating a function that will be
called when you write
someType a,b;
b = b+c;
since this code is AGAIN not conforming (you can't add two user defined
types).
The Standard requires a diagnostic message to be produced for such code. If
lcc-win32 does not produce such a message in conforming mode, then
lcc-win32 itself is not conforming. (If it does, of course, there is no
problem.)
I have respected the standard by
1) No new keywords
2) Only using non-standard constructs for my extension.
It is unfair to treat this extension as a "new language".
If a program written to use those extensions is a correct C program, then
it will compile and work correctly under other C compilers, not just
lcc-win32. If it does not, then it is not a correct C program, and so
either it is an incorrect program or it is a correct program written in
some other language, in which case it should be discussed in the group
appropriate to that language.
This isn't an academic exercise. People need to be aware that, by using
your extensions, they are locking their code in to your implementation.
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
Keith Thompson wrote, On 01/12/07 02:44:
jacob navia <ja***@nospam.comwrites:
>user923005 wrote:
>>On Nov 30, 1:32 pm, jacob navia <ja...@nospam.comwrote:
Keith Thompson wrote:
<snip>
So, in conforming mode, a compiler can either (a) reject the use of
operator overloading, or (b) accept it, but only after issuing a
diagnostic. Failure to issue the diagnostic would be a violation of
the standard.
(This is a fairly subtle argument, and it's possible that I'm
mistaken, but it was the result of a discussion in comp.std.c.)
This is closely related to my question which Jacob has not addressed.
His compiler (like most) has two modes, one which claims conformance to
the C standard and one which does not. When it does not claim
conformance it can do anything Jacob likes, and that is not relevant
here. However, Jacob has claimed his operator overloading is compatible
with the standard, so does his compiler accept operator overloading when
in the mode that conforms to the standard?
--
Flash Gordon
Harald van Dijk wrote, On 01/12/07 10:24:
On Fri, 30 Nov 2007 18:44:15 -0800, Keith Thompson wrote:
>But consider a hypothetical compiler that (a) acts as a conforming C
compiler (let's say it's a fully conforming hosted C99 implementation),
and (b) also acts as a conforming Fortran compiler. Unless there are
programs that are simultaneously legal C and legal Fortran, but with
different semantics, this is entirely possible.
Such programs exist.
<snip example>
Make it that it only treats a program as Fortran if it is not a valid C
program and Keith's point still stands.
--
Flash Gordon
On Sat, 01 Dec 2007 12:42:19 +0000, Richard Heathfield wrote:
jacob navia said:
<snip>
>If you write:
int operator+(someType a,someType b)
{
// ...
}
you are NOT in standard C and I am allowed to treat this non-conforming
code as I wish.
Please discuss such extensions in a newsgroup devoted to that
implementation. If the OP wants to use lcc-win32 extensions, no doubt
he'll ask in a newsgroup devoted to that implementation.
That advise might have been good earlier in the thread, but now, this is
about whether the extension as implemented is allowable in a conforming
implementation, which I believe is topical here.
On Sat, 01 Dec 2007 12:10:58 +0000, Flash Gordon wrote:
Harald van Dijk wrote, On 01/12/07 10:24:
>On Fri, 30 Nov 2007 18:44:15 -0800, Keith Thompson wrote:
>>But consider a hypothetical compiler that (a) acts as a conforming C
compiler (let's say it's a fully conforming hosted C99
implementation), and (b) also acts as a conforming Fortran compiler.
Unless there are programs that are simultaneously legal C and legal
Fortran, but with different semantics, this is entirely possible.
Such programs exist.
<snip example>
Make it that it only treats a program as Fortran if it is not a valid C
program and Keith's point still stands.
Agreed.
jacob navia wrote, On 01/12/07 11:06:
James Kuyper wrote:
>Mark McIntyre wrote:
>>jacob navia wrote:
>3) Using operator overloading, I integrated this library
>like a basic type into the language.
You mean you've extended the language by adding a new type.
(KT wrote)
Where the phrase "the language" refers to something other than C.
No. All this extensions are compatible with the C standard as
I have explained thousand times in this newsgroup.
Huh? Things like operator overloading are compatible with ISO C?
Note that the C standard does NOT forbid extensions
Correct.
However once you add extensions, you no longer have ISO C. You have C
with Extensions. Please have the grace to call it that.
It's possible to extend C in a fully conforming mode. All that's
required is that the extension either selects from among the options
when the C standard leaves the behavior unspecified, or is only
supported for programs that contains specific constructs which render
it's behavior undefined.
Jacob: are you claiming that operator overloading is supported in a
fully conforming mode of your compiler? I don't think that's likely,
but I'm willing to consider the possibility that it's true, but only
if you explain how this is the case.
<snip>
"operator" is NOT a keyword. You can use it as a normal identifier.
If you write:
int operator+(someType a,someType b)
{
// ...
}
you are NOT in standard C and I am allowed to treat this non-conforming
code as I wish.
In non-conforming mode you can do anything you want. In conforming mode
you have to issue a diagnostic, but once you have done so you can then
do what you want with the program. That diagnostic could be:
INFORMATION: Operator-overloading extension being used
<snip>
I have respected the standard by
1) No new keywords
2) Only using non-standard constructs for my extension.
However, your extensions are not valid in that a conforming compiler is
*required* to issue a diagnostic for the construct.
It is unfair to treat this extension as a "new language".
That is a matter of opinion.
When you invoke the compiler with
-ansic however, all extensions are disabled, including
this one. The only exception is _stdcall.
So your operator overloading and anything that relies on it cannot be
used in any compiler that is behaving as the standard requires. It also
cannot be used in a source file that includes the following snippet in
any mode your compiler supports...
#include <math.h>
static int atof;
If there was an implementation that supported your extension at the same
time as meeting all the requirements of the standard you would be in a
stronger position. As it is, however, I would say that
C+Jocobs-Extensions is a different language. The same can be said about
some of the GNU extensions, and I've certainly seen people stating here
that gnuc is a different language.
--
Flash Gordon
Harald van D?k said:
<snip>
about whether the extension as implemented is allowable in a conforming
implementation, which I believe is topical here.
Well, that's an easy one - the answer is yes, provided that any mandatory
diagnostic message is in fact produced, and provided that it doesn't cause
a strictly conforming program to be mistranslated.
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
Keith Thompson wrote:
Incidentally, I don't believe that a C program can use operator
overloading without violating either a constraint or a syntax rule.
My understanding is that the existence of an extension does not
relieve the compiler of its obligation to issue a diagnostic for any
such program; after issuing the diagnostic, it's then free to go on
and handle the extension as it likes. (Of course, this applies only
in conforming mode; a compiler is perfectly free to *silently* accept
operator loading, or do anything else it likes, in a non-conforming
mode.)
So, in conforming mode, a compiler can either (a) reject the use of
operator overloading, or (b) accept it, but only after issuing a
diagnostic. Failure to issue the diagnostic would be a violation of
the standard.
This is very interesting.
This would mean that I am allowed to use the operator overloading
extension (and stop all internal contorsions) in conforming mode,
what would allow me to implement completely complex types and
extended precision types in the same fashion and take that code
OUT from the compiler...
The only difficult point comes to initialization.
C99 declares that
double _Complex val = 568.67+78.87*I;
is a complex number. There is no accepted way to do
this by using operator overloading either in C or C++...
Somehow the compiler has "to know" those types. The same for
the extended precision floats:
qfloat m = 4544666788766544545455454e9567Q;
(Note the 'Q' at the end)
I would have to design some kind of syntax to call a user function
during compile time to parse this kind of new numbers.
#pragma NumberLexer('Q',qfloat,ReadQfloat,"Qfloat.dll")
mening:
"When you find a number that ends in 'Q', call the function ReadQfloat
in the "Qfloat.dll". That function will fill the qfloat type using the
parsed number.
In a Unix environment it would be:
#pragma NumberLexer('Q',qfloat,ReadQfloat,"libqfloat.so")
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique http://www.cs.virginia.edu/~lcc-win32
On Sat, 01 Dec 2007 14:27:19 +0100, jacob navia wrote:
Keith Thompson wrote:
>[...]
So, in conforming mode, a compiler can either (a) reject the use of
operator overloading, or (b) accept it, but only after issuing a
diagnostic. Failure to issue the diagnostic would be a violation of
the standard.
This is very interesting.
This would mean that I am allowed to use the operator overloading
extension (and stop all internal contorsions) in conforming mode, what
would allow me to implement completely complex types and extended
precision types in the same fashion and take that code OUT from the
compiler...
The only difficult point comes to initialization.
C99 declares that
double _Complex val = 568.67+78.87*I;
is a complex number. There is no accepted way to do this by using
operator overloading either in C
Correct, obviously.
or C++...
Incorrect. The problem can be avoided by allowing non-constant
initialisers, which is exactly what C++ does.
Somehow the compiler has "to know" those types. The same for the
extended precision floats:
qfloat m = 4544666788766544545455454e9567Q;
(Note the 'Q' at the end)
I would have to design some kind of syntax to call a user function
during compile time to parse this kind of new numbers.
#pragma NumberLexer('Q',qfloat,ReadQfloat,"Qfloat.dll")
Please don't allow arbitrary code to be executed merely by compiling a
program even before it's run. This is a security hole just waiting to be
exploited.
I don't have an alternative suggestion, though.
Harald van D?k wrote:
On Sat, 01 Dec 2007 14:27:19 +0100, jacob navia wrote:
>Keith Thompson wrote:
>>[...]
So, in conforming mode, a compiler can either (a) reject the use of
operator overloading, or (b) accept it, but only after issuing a
diagnostic. Failure to issue the diagnostic would be a violation of
the standard.
This is very interesting.
This would mean that I am allowed to use the operator overloading
extension (and stop all internal contorsions) in conforming mode,
what would allow me to implement completely complex types and
extended precision types in the same fashion and take that code OUT
from the compiler...
The only difficult point comes to initialization.
C99 declares that
double _Complex val = 568.67+78.87*I;
is a complex number. There is no accepted way to do this by using
operator overloading either in C
Correct, obviously.
>or C++...
Incorrect. The problem can be avoided by allowing non-constant
initialisers, which is exactly what C++ does.
>Somehow the compiler has "to know" those types. The same for the
extended precision floats:
qfloat m = 4544666788766544545455454e9567Q;
(Note the 'Q' at the end)
I would have to design some kind of syntax to call a user function
during compile time to parse this kind of new numbers.
#pragma NumberLexer('Q',qfloat,ReadQfloat,"Qfloat.dll")
Please don't allow arbitrary code to be executed merely by compiling a
program even before it's run. This is a security hole just waiting to
be exploited.
But many languages have a compile-time language that allows this sort of
thing and more. This shouldn't be a security risk under an operating
system with decent security protections in place.
>
I don't have an alternative suggestion, though.
On Sat, 01 Dec 2007 20:50:25 +0530, santosh wrote:
Harald van D?k wrote:
>On Sat, 01 Dec 2007 14:27:19 +0100, jacob navia wrote:
>>#pragma NumberLexer('Q',qfloat,ReadQfloat,"Qfloat.dll")
Please don't allow arbitrary code to be executed merely by compiling a
program even before it's run. This is a security hole just waiting to
be exploited.
But many languages have a compile-time language that allows this sort of
thing and more.
The languages I know of that do, are designed to compile and run on the
same machine. With C, this is often not so. It should be safe to compile
a program on one machine, and run it on another where potentially
malicious code can do no harm.
This shouldn't be a security risk under an operating
system with decent security protections in place.
If it can wipe my home directory, I do not care much whether my OS's
security protections would prevent it from wiping the whole system. If
there are other security protections you're thinking about, that would
completely prevent any file writing, then it would be okay at least with
me.
Harald van D?k wrote:
On Sat, 01 Dec 2007 20:50:25 +0530, santosh wrote:
>Harald van D?k wrote:
>>On Sat, 01 Dec 2007 14:27:19 +0100, jacob navia wrote:
#pragma NumberLexer('Q',qfloat,ReadQfloat,"Qfloat.dll")
Please don't allow arbitrary code to be executed merely by compiling
a program even before it's run. This is a security hole just waiting
to be exploited.
But many languages have a compile-time language that allows this sort
of thing and more.
The languages I know of that do, are designed to compile and run on
the same machine. With C, this is often not so. It should be safe to
compile a program on one machine, and run it on another where
potentially malicious code can do no harm.
>This shouldn't be a security risk under an operating
system with decent security protections in place.
If it can wipe my home directory, I do not care much whether my OS's
security protections would prevent it from wiping the whole system. If
there are other security protections you're thinking about, that would
completely prevent any file writing, then it would be okay at least
with me.
When you download any source from the Net and compile it, what guarantee
do you get that the configure or make process doesn't wipe your home
directory? Or do you compile everything in a chroot jail?
On Sat, 01 Dec 2007 11:22:01 +0000, Mark McIntyre
<ma**********@spamcop.netwrote:
>jacob navia wrote:
>CBFalconer wrote:
>>jacob navia wrote:
Keith Thompson wrote:
... snip ...
Where the phrase "the language" refers to something other than C.
No. All this extensions are compatible with the C standard as
I have explained thousand times in this newsgroup.
Note that the C standard does NOT forbid extensions
True. However c.l.c does.
You are speaking for yourself... There is no approved c.l.c
consensus about this.
I hesitate to bother commenting on that but you're incorrect.
There is a consensus. You may not like it, but its there nonetheless.
Well, yes and no. In the original meaning of the word, there is
no consensus, the original meaning being a general accord or
common agreement. Over time a second usage has become common,
typically something like majority agreement. Neither of these
usages apply here. Instead there is a minority of the posters
(the regulars) who have a consensus between themselves about what
is on and off topic in c.l.c. This consensus does not extend to
all people who regularly post to comp.lang.c, nor does it stop
"regulars" from being "off topic".
In short there is a consensus among those posters who agree with
you.
Richard Harter, cr*@tiac.net http://home.tiac.net/~cri, http://www.varinoma.com
In the fields of Hell where the grass grows high
Are the graves of dreams allowed to die
On Sat, 01 Dec 2007 21:24:09 +0530, santosh wrote:
When you download any source from the Net and compile it, what guarantee
do you get that the configure or make process doesn't wipe your home
directory? Or do you compile everything in a chroot jail?
The configure and make processes don't need to be run on the same system
as the compiler. Do a search for distcc, if you're interested.
Harald van Dijk wrote:
On Sat, 01 Dec 2007 11:14:58 +0000, Mark McIntyre wrote:
>jacob navia wrote:
>>>>3) Using operator overloading, I integrated this library like a basic
type into the language.
You mean you've extended the language by adding a new type.
I believe you and jacob navia said the same thing here.
No offense, but that may be because you don't speak english as a first
language.
When you extend something, you go beyond its original scope. When you
integrate something into another thing, you make it a part of it. Jacob
cannot make operator overloading part of the C language, since the
language is codified by ISO.
>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,
This may be true, but it doesn't mean that any of these compilers have
integrated (for example) the keyword __declspec or dynamic linking into
the language.
nor will there or can there ever be for the current and previous
standards. Extensions are required to write the standard headers.
Quite possibly. But irrelevant.
On Sat, 01 Dec 2007 17:29:53 +0000, Mark McIntyre wrote:
Harald van Dijk wrote:
>On Sat, 01 Dec 2007 11:14:58 +0000, Mark McIntyre wrote:
>>jacob navia wrote:
>3) Using operator overloading, I integrated this library like a
>basic type into the language.
You mean you've extended the language by adding a new type.
I believe you and jacob navia said the same thing here.
No offense, but that may be because you don't speak english as a first
language.
No offense taken, but I don't think that's it. See below.
When you extend something, you go beyond its original scope. When you
integrate something into another thing, you make it a part of it. Jacob
cannot make operator overloading part of the C language, since the
language is codified by ISO.
He indeed cannot make operator overloading part of ISO C, but he can make
operator overloading part of the language accepted by his conforming
implementation of ISO C. In context, this interpretation of "the
language" makes more sense, I believe. Apparently you didn't read it that
way, but Jacob has (to my knowledge; feel free to correct) never extended
ISO C. He started from a C90-based compiler which already supported a few
extensions, and continued to add parts of C99. He has at no point had a
compiler which accepted exactly ISO C99 as specified by the standard, so
he has never extended that standard C language.
>>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,
This may be true, but it doesn't mean that any of these compilers have
integrated (for example) the keyword __declspec or dynamic linking into
the language.
Correct, but why does that matter?
>nor will there or can there ever be for the current and previous
standards. Extensions are required to write the standard headers.
Quite possibly. But irrelevant.
Why do you now tolerate some extensions of some conforming
implementations, but not others of equally conforming implementations?
You claimed "once you add extensions, you no longer have ISO C." Would
you like to take that back?
Harald van Dijk wrote:
He indeed cannot make operator overloading part of ISO C, but he can make
operator overloading part of the language accepted by his conforming
implementation of ISO C.
Agreed - but this language is not ISO C.
>In context, this interpretation of "the language" makes more sense, I believe.
In the context it was written, the language referred to was surely C.
And since the topic of this group is ISO C, it seems entrely reasonable
to infer that it was this sort of C to which JN referred, not LCC-Win32
or gcc, or msvc or whatever.
>>nor will there or can there ever be for the current and previous
standards. Extensions are required to write the standard headers.
>Quite possibly. But irrelevant.
Why do you now tolerate some extensions of some conforming
implementations, but not others of equally conforming implementations?
You mistake me. I tolerate them all. I however don't refer to them as
ISO C - they're extensions of ISO C.
You claimed "once you add extensions, you no longer have ISO C." Would
you like to take that back?
Please don't be disingenuous. What a compiler implementer does under the
hood, eg inside standard headers, is not constrained by the Standard.
Harald van Dijk wrote:
On Sat, 01 Dec 2007 14:27:19 +0100, jacob navia wrote:
>Keith Thompson wrote:
>>[...]
So, in conforming mode, a compiler can either (a) reject the use of
operator overloading, or (b) accept it, but only after issuing a
diagnostic. Failure to issue the diagnostic would be a violation of
the standard.
This is very interesting.
This would mean that I am allowed to use the operator overloading
extension (and stop all internal contorsions) in conforming mode, what
would allow me to implement completely complex types and extended
precision types in the same fashion and take that code OUT from the
compiler...
The only difficult point comes to initialization.
C99 declares that
double _Complex val = 568.67+78.87*I;
is a complex number. There is no accepted way to do this by using
operator overloading either in C
Correct, obviously.
>or C++...
Incorrect. The problem can be avoided by allowing non-constant
initialisers, which is exactly what C++ does.
No, they will be called at program initialization time, i.e. at the
startof the program.
I want to call those initializers at COMPILE time, i.e.
call that function from the compiler and then just store the binary
result in the data section of the program
Please don't allow arbitrary code to be executed merely by compiling a
program even before it's run. This is a security hole just waiting to be
exploited.
I don't have an alternative suggestion, though.
Well it doesn't have to be a binary. The compiler could compile some
function, then link it then execute it.
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique http://www.cs.virginia.edu/~lcc-win32
jacob navia <ja***@nospam.comwrites:
[...]
When you invoke the compiler with
-ansic however, all extensions are disabled, including
this one. The only exception is _stdcall.
Then perhaps most of this discussion has been a waste of time.
Am I correct in thinking that lcc-win with "-ansic" claims to be a
conforming C compiler, and lcc-win without "-ansic" does not?
If so, then the behavior of lcc-win without "-ansic" is of no
particular relevance here. It doesn't matter whether your
implementation of operator overloading conforms to the C standard, or
whether you issue a diagnostic for any constraint violations or syntax
errors that result from using it, because your implementation, in its
mode that supports operator overloading, is not bound by the C
standard.
Or does lcc-win without "-ansic" claim to be a conforming C compiler
with extensions? If so, then how it handles those extensions is
relevant to the question of whether it's a conforming implementation.
--
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"
Mark McIntyre <ma**********@spamcop.netwrites:
Ian Collins wrote:
(replying to someone)
>>Well, your compiler does not conform to the C standard *without* the
-ansic flag (for example declaring atof in math.h), so does it support
operator overloading *with* the -ansic flag? If not then it compiles C
when the -ansic flag is specified and something other than C that
supports operator overloading with it.
Just like gcc?
Quite possibly.
Does anyone here claim that gcc is a conforming ISO C implementation?
I claim that gcc, with an appropriate set of command-line options, is,
in combination with an appropriate runtime library, a conforming ISO
C90 implementation, apart from bugs. With a different set of
command-line options it approaches being a conforming ISO C99
implementation, but with some significant missing features.
Does anyone here respond to posts with thinly veiled adverts for gcc?
I'll leave that one alone.
--
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"
Flash Gordon <sp**@flash-gordon.me.ukwrites:
Harald van Dijk wrote, On 01/12/07 10:24:
>On Fri, 30 Nov 2007 18:44:15 -0800, Keith Thompson wrote:
>>But consider a hypothetical compiler that (a) acts as a conforming C
compiler (let's say it's a fully conforming hosted C99 implementation),
and (b) also acts as a conforming Fortran compiler. Unless there are
programs that are simultaneously legal C and legal Fortran, but with
different semantics, this is entirely possible.
Such programs exist.
<snip example>
Make it that it only treats a program as Fortran if it is not a valid
C program and Keith's point still stands.
For example, given an existing conforming C implementation and an
existing conforming Fortran implementation, a wrapper script could try
to invoke the C compiler, and if that fails, try the Fortran compiler.
The wrapper script, in combination with the existing C and Fortran
implementations, would consitute a conforming C implementation that
accepts Fortran as an extension.
--
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"
Keith Thompson wrote:
Mark McIntyre <ma**********@spamcop.netwrites:
>Ian Collins wrote:
(replying to someone)
>>>Well, your compiler does not conform to the C standard *without* the
-ansic flag (for example declaring atof in math.h), so does it support
operator overloading *with* the -ansic flag? If not then it compiles C
when the -ansic flag is specified and something other than C that
supports operator overloading with it.
Just like gcc?
Quite possibly.
Does anyone here claim that gcc is a conforming ISO C implementation?
I claim that gcc, with an appropriate set of command-line options, is,
in combination with an appropriate runtime library, a conforming ISO
C90 implementation, apart from bugs. With a different set of
command-line options it approaches being a conforming ISO C99
implementation, but with some significant missing features.
And I'll agree with that. The point being, the conforming mode is
topical here, the other isn't.
Richard Harter wrote:
Mark McIntyre <ma**********@spamcop.netwrote:
>jacob navia wrote:
>>CBFalconer wrote:
jacob navia wrote:
.... snip ...
>>>>>
Note that the C standard does NOT forbid extensions
True. However c.l.c does.
You are speaking for yourself... There is no approved c.l.c
consensus about this.
I hesitate to bother commenting on that but you're incorrect.
There is a consensus. You may not like it, but its there
nonetheless.
Well, yes and no. In the original meaning of the word, there is
no consensus, the original meaning being a general accord or
common agreement. Over time a second usage has become common,
typically something like majority agreement. Neither of these
usages apply here. Instead there is a minority of the posters
(the regulars) who have a consensus between themselves about what
is on and off topic in c.l.c. This consensus does not extend to
all people who regularly post to comp.lang.c, nor does it stop
"regulars" from being "off topic".
In short there is a consensus among those posters who agree with
you.
To the contrary, a short time ago a thread gathered opinions on
this subject. The overwhelming majority agreed with keeping c.l.c
ISO standard based.
--
Chuck F (cbfalconer at maineline dot net)
<http://cbfalconer.home.att.net>
Try the download section.
--
Posted via a free Usenet account from http://www.teranews.com
In article <fi**********@news2.zwoll1.ov.home.nl=?UTF-8?q?Harald_van_D=C4=B3k?= <tr*****@gmail.comwrites:
On Sat, 01 Dec 2007 11:14:58 +0000, Mark McIntyre wrote:
....
Huh? Things like operator overloading are compatible with ISO C?
Yes. It is possible for a compiler to support operator overloading in a
way that won't miscompile any correct standard C program.
Not only correctly compiling standard conforming programs is a requirement.
You need also to issue the required diagnostics for non-standard conforming
programs.
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, +31205924131
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/
"Dik T. Winter" <Di********@cwi.nlwrites:
In article <fi**********@news2.zwoll1.ov.home.nl>
=?UTF-8?q?Harald_van_D=C4=B3k?= <tr*****@gmail.comwrites:
On Sat, 01 Dec 2007 11:14:58 +0000, Mark McIntyre wrote:
...
Huh? Things like operator overloading are compatible with ISO C?
>
Yes. It is possible for a compiler to support operator overloading in a
way that won't miscompile any correct standard C program.
Not only correctly compiling standard conforming programs is a
requirement. You need also to issue the required diagnostics for
non-standard conforming programs.
Yes, specifically for any violation of a constraint or a syntax rule
(and a C-like program that uses operator overloading must violate one
or the other). But once the compiler has issued a single diagnostic,
even if it's something like "Thank you for using this feature", it's
free to go on to generate code for the program.
But that doesn't appear to be much of an issue for the particular
implementation that we've been discussing.
--
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"
CBFalconer wrote:
Richard Harter wrote:
>Mark McIntyre <ma**********@spamcop.netwrote:
>>jacob navia wrote:
CBFalconer wrote:
jacob navia wrote:
>
... snip ...
>>>>>Note that the C standard does NOT forbid extensions
True. However c.l.c does.
You are speaking for yourself... There is no approved c.l.c
consensus about this.
I hesitate to bother commenting on that but you're incorrect.
There is a consensus. You may not like it, but its there
nonetheless.
Well, yes and no. In the original meaning of the word, there is
no consensus, the original meaning being a general accord or
common agreement. Over time a second usage has become common,
typically something like majority agreement. Neither of these
usages apply here. Instead there is a minority of the posters
(the regulars) who have a consensus between themselves about what
is on and off topic in c.l.c. This consensus does not extend to
all people who regularly post to comp.lang.c, nor does it stop
"regulars" from being "off topic".
In short there is a consensus among those posters who agree with
you.
To the contrary, a short time ago a thread gathered opinions on
this subject. The overwhelming majority agreed with keeping c.l.c
ISO standard based.
No. Heathfield wants C90, not ISO C.
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique http://www.cs.virginia.edu/~lcc-win32
jacob navia <ja***@nospam.comwrites:
CBFalconer wrote:
[...]
>To the contrary, a short time ago a thread gathered opinions on
this subject. The overwhelming majority agreed with keeping c.l.c
ISO standard based.
No. Heathfield wants C90, not ISO C.
Even if Richard Heathfield prefers C90 to C99, that has nothing to do
with whether C99 is topical. I don't recall him ever suggesting that
C99 should be considered off-topic. (If he had, I certainly would
have expressed my disagreement.)
--
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"
jacob navia wrote:
CBFalconer wrote:
<snip>
>To the contrary, a short time ago a thread gathered opinions on
this subject. The overwhelming majority agreed with keeping c.l.c
ISO standard based.
No. Heathfield wants C90, not ISO C.
Was it necessary to drop names? This group (as you know) is for C99, C90
(also C95) and C as described in K&R1. Richard has never (as far as I'm
aware) objected to this scope.
BTW are you a member of your national body for C Standardisation? It
would be a much more effective method to propose your ideas than
endless posts to newsgroups.
CBFalconer wrote:
Richard Harter wrote:
>Mark McIntyre <ma**********@spamcop.netwrote:
>>There is a consensus. You may not like it, but its there
nonetheless.
>In short there is a consensus among those posters who agree with
you.
To the contrary, a short time ago a thread gathered opinions on
this subject. The overwhelming majority agreed with keeping c.l.c
ISO standard based.
Indeed, but did you expect a Troll to be accurate? Best just to ignore him.
jacob navia wrote:
CBF wrote
>>The overwhelming majority agreed with keeping c.l.c
ISO standard based.
No. Heathfield wants C90, not ISO C.
Richard is not an overwhelming majority. Overwhelming sometimes maybe,
but not a majority. Unless he's a /lot/ fatter than he's letting on... =:-0
Keith Thompson said:
jacob navia <ja***@nospam.comwrites:
>CBFalconer wrote:
[...]
>>To the contrary, a short time ago a thread gathered opinions on
this subject. The overwhelming majority agreed with keeping c.l.c
ISO standard based.
No. Heathfield wants C90, not ISO C.
Even if Richard Heathfield prefers C90 to C99, that has nothing to do
with whether C99 is topical.
Certainly true. Also, the thread to which Chuck is referring will show that
my topicality preference is actually considerably more liberal than that
of the average responder in that thread. Nevertheless, I abide by the
group's preference, rather than my own.
I don't recall him ever suggesting that C99 should be considered
off-topic. (If he had, I certainly would have expressed my
disagreement.)
I don't recall ever suggesting that either. Of course C99 is topical. It's
the de jure standard for C. The fact that almost no implementations
conform to it does not affect its topicality status here. Nevertheless,
until a program that uses C99 features is at least as portable as one that
uses only C90 features, I will continue to program in the common subset of
C90 and C99.
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
Mark McIntyre said:
jacob navia wrote:
CBF wrote
>>>The overwhelming majority agreed with keeping c.l.c
ISO standard based.
>No. Heathfield wants C90, not ISO C.
Richard is not an overwhelming majority.
In fact, I was part of the *minority* that expressed a desire to open up
the topicality a little.
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
Nick Keighley <ni******************@hotmail.comwrites:
On 28 Nov, 17:34, santosh <santosh....@gmail.comwrote:
>mathieu.dut...@gmail.com wrote:
<snip>
>If you can, think about using tested existing packages instead of
writing yet another implementation. Something like GMP is a good
candidate
note: GMP uses the full GPL (or did last time I looked) this may
limit where you can use it.
http://gmplib.org/ says it is released under the LGPL. Unless I am
mistaken, this is the same as the licence used by the C library used
when build with gcc. I doubt this is what most people mean by "the
full GPL" but YMMV.
--
Ben.
Ben Bacarisse wrote:
Nick Keighley <ni******************@hotmail.comwrites:
>On 28 Nov, 17:34, santosh <santosh....@gmail.comwrote:
>>mathieu.dut...@gmail.com wrote:
<snip>
>>If you can, think about using tested existing packages instead of
writing yet another implementation. Something like GMP is a good
candidate
note: GMP uses the full GPL (or did last time I looked) this may
limit where you can use it.
http://gmplib.org/ says it is released under the LGPL. Unless I am
mistaken, this is the same as the licence used by the C library used
when build with gcc. I doubt this is what most people mean by "the
full GPL" but YMMV.
Other options include:
<http://www.di-mgt.com.au/bigdigits.html>
<http://www.tc.umn.edu/~ringx004/mapm-main.html>
Also the Wikipedia page lists other options:
<http://en.wikipedia.org/wiki/Arbitrary_precision_arithmetic>
On 2 Dec, 18:25, Ben Bacarisse <ben.use...@bsb.me.ukwrote:
Nick Keighley<nick_keighley_nos...@hotmail.comwrites:
On 28 Nov, 17:34, santosh <santosh....@gmail.comwrote:
mathieu.dut...@gmail.com wrote:
<snip>
If you can, think about using tested existing packages instead of
writing yet another implementation. Something like GMP is a good
candidate
note: GMP uses the full GPL (or did last time I looked) this may
limit where you can use it.
http://gmplib.org/says it is released under the LGPL. Unless I am
mistaken, this is the same as the licence used by the C library used
when build with gcc. I doubt this is what most people mean by "the
full GPL" but YMMV.
oops. No I did not mean LGPL to be included in "full GPL"
I was under the impression that GMP didn't use LGPL.
I relied on a vague memory rather than checking. :-(
--
Nick Keighley
Nick Keighley wrote:
santosh <santosh....@gmail.comwrote:
>mathieu.dut...@gmail.com wrote:
<snip>
>If you can, think about using tested existing packages instead of
writing yet another implementation. Something like GMP is a good
candidate
note: GMP uses the full GPL (or did last time I looked) this may
limit where you can use it.
GPL (and LGPL) do not limit your use. However they do, under
certain conditions, limit your distribution of the resultant
program.
--
Chuck F (cbfalconer at maineline dot net)
<http://cbfalconer.home.att.net>
Try the download section.
--
Posted via a free Usenet account from http://www.teranews.com
On Mon, 03 Dec 2007 14:30:43 -0800, user923005 wrote:
On Dec 3, 3:20 pm, Harald van Dijk <true...@gmail.comwrote:
>I agree with the rest of what your message, a conforming implementation
*could* accept user923005's Fortran code. However, he suggested that
the code could equally validly be called C code (as a particular
extension), because it was accepted by a conforming C implementation.
It isn't.
I definitely never said that. At least, not with a straight face.
To clarify, I meant "equally valid" exactly as I posted it: I took your
message to mean jacob's extension was no more C than your Fortran code.
If that's not what you meant, then I'm sorry, I misread your message.
On Dec 3, 3:30 pm, Harald van D©¦k <true...@gmail.comwrote:
On Mon, 03 Dec 2007 14:30:43 -0800, user923005 wrote:
On Dec 3, 3:20 pm, Harald van D©¦k <true...@gmail.comwrote:
I agree with the rest of what your message, a conforming implementation
*could* accept user923005's Fortran code. However, he suggested that
the code could equally validly be called C code (as a particular
extension), because it was accepted by a conforming C implementation.
It isn't.
I definitely never said that. At least, not with a straight face.
To clarify, I meant "equally valid" exactly as I posted it: I took your
message to mean jacob's extension was no more C than your Fortran code.
If that's not what you meant, then I'm sorry, I misread your message.
Actually, that's close enough. Compiler vendors are free to add any
extensions that they like to the language. These extensions do not
extend the language. They only extend the capabilities of the
compiler. Adding classes to C, for instance, is no more an extension
to C than adding Fortran to C. Which is not to say that such
extensions are not useful. Only that they are not C.
Harald van Dijk <tr*****@gmail.comwrites:
[...]
I agree with the rest of what your message, a conforming implementation
*could* accept user923005's Fortran code. However, he suggested that the
code could equally validly be called C code (as a particular extension),
because it was accepted by a conforming C implementation. It isn't.
There are also other reasons why it might not be considered C code, even
if there does exist a C implementation that accepts it, but this alone is
good enough for me for now.
I wouldn't call it "C code" either, but it is a "conforming program"
as defined in C99 4p7. This just demonstrates that the standard's
definition of a "conforming program" is not particularly useful. (I
think it was added for political, rather than technical, reasons; as
long as we can ignore it, I'm ok with that.)
--
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"
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.
- formerly david.thompson1 || achar(64) || worldnet.att.net
On Sat, 1 Dec 2007 10:24:19 +0000 (UTC), Harald van D?k
<tr*****@gmail.comwrote:
On Fri, 30 Nov 2007 18:44:15 -0800, Keith Thompson wrote:
But consider a hypothetical compiler that (a) acts as a conforming C
compiler (let's say it's a fully conforming hosted C99 implementation),
and (b) also acts as a conforming Fortran compiler. Unless there are
programs that are simultaneously legal C and legal Fortran, but with
different semantics, this is entirely possible.
Such programs exist.
/*
*/ #include <stdio.h /*
*/ int main(void) { /*
*/ puts("This is a C program"); /*
*/ } /*
print *, "This is a Fortran program"
end
*/
Not quite. It doesn't work to have the main() routine on the same
effective line as the #include <stdio.h>. You can add a(nother) line
that is blank=comment in the Fortran (fixed) interpretation. Or drop
the #include and either declare puts() yourself -- which is legal as
it doesn't use any header-defined type -- or in C90 you could accept
the implicit declaration, but in C90 you should have a return 0; to
avoid undefined exit status.
- formerly david.thompson1 || achar(64) || worldnet.att.net This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics | |
by: Philipp |
last post by:
Hello (not sure this is the right forum for that question so please redirect
me if necessary)
How can I know how many double values are available between 0 and 1?
On my machine (pentium 3) I get...
|
by: Roger Leigh |
last post by:
Hello,
I'm writing a fixed-precision floating point class, based on the ideas
in the example fixed_pt class in the "Practical C++ Programming" book
by Steve Oualline (O' Reilly). This uses a...
|
by: Brian van den Broek |
last post by:
Hi all,
I guess it is more of a maths question than a programming one, but it
involves use of the decimal module, so here goes:
As a self-directed learning exercise I've been working on a...
|
by: BigMan |
last post by:
How can I check if assignment of a float to a double (or vice versa)
will result in loss of precision?
|
by: michael.mcgarry |
last post by:
Hi,
I have a question about floating point precision in C.
What is the minimum distinguishable difference between 2 floating point
numbers? Does this differ for various computers?
Is this...
| | |
by: Madan |
last post by:
Hi all,
I had problem regarding float/double arithmetic only with + and -
operations, which gives inaccurate precisions. I would like to know how the
arithmetic operations are internally handled...
|
by: Bo Yang |
last post by:
Hi, I am confused by the double type in C++. I don't know whether
below is legal or possible:
double PI = 3.141592675932;
Now, can I get another double variable from PI with lower precision,...
|
by: Matthew |
last post by:
Hi,
I want to change the precision level of floating point variables and
calculations which is done in php.ini.
However the server I rent for my domain does not give me access to
php.ini,...
|
by: Charles Coldwell |
last post by:
James Kanze <james.kanze@gmail.comwrites:
True, with some additional considerations. The commonly used IEEE 754
floating point formats are
single precision: 32 bits including 1 sign bit, 23...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
| | |
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome a new...
|
by: conductexam |
last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and...
|
by: adsilva |
last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
|
by: 6302768590 |
last post by:
Hai team
i want code for transfer the data from one system to another through IP address by using C# our system has to for every 5mins then we have to update the data what the data is updated ...
| | |
by: muto222 |
last post by:
How can i add a mobile payment intergratation into php mysql website.
| |
