long double in gcc implementations

[lcw1964]

This may be in the category of bush-league rudimentary, but I am quite
perplexed on this and diligent Googling has not provided me with a
clear straight answer--perhaps I don't know how to ask the quesion.

I have begun to familiarize myself here with the gcc compiler in a
win32 environment, in the form of MinGW using both Dev C++ and MSYS as
interfaces.

I have recompiled some old math code that uses long double types
throughout and provides the corresponding range and precision (up to 18
digits, with exponents up to about -/+ 4900) when compiled under an
older version of BC++.

In the MinGW incarnation of gcc, I have made a couple of adjustments to
get it to compile--in particular, _atold() doesn't exist, and atof() is
prototyped only in stdlib.h whereas in BC++ it is listed in math.h too.
However, I kept all of my long double declarations and outputs as that,
and used all of the long double versions of the math functions--expl(),
fabsl(), etc. The file complied but the output was gibberish. It took a
little googling to find that I had to recast the long double output as
double so printf() could meaningfully display it.

However, I have come to suspect that MinGW's long double isn't really
long double, and that somewhere in the process the range and precision
of of the floating point math has been restricted to the double range.
For example, in the original code under BC++ (not MSVC++, which is well
known to recast everything as double) I can generate a meaningful
answer of, say 1.34598900000098888e-2345, whereas the MinGW compiled
version will render this tiny value as simply 0.

My question is this--does MinGW offer the "true" long double floating
point 80bit type, and if so how can I get my programs to display
results of the sort I mentioned in the previous paragraph is printf()
needs recasting to double in order to handle it?

I know that the C language in general is not the best environment in
which to do extended precision math work (one would be better off
mastering a high or arbitrary precision library), but I would like to
get the most precision and range out of my calculations under MinGW if
this is available.

many thanks,

Les

[jacob navia]

lcw1964 a écrit :

I know that the C language in general is not the best environment in
which to do extended precision math work (one would be better off
mastering a high or arbitrary precision library), but I would like to
get the most precision and range out of my calculations under MinGW if
this is available.

The lcc-win32 C compiler offers 100 digits floats, 128 bit integers
bignums, whatever.

http://www.cs.virginia.edu/~lcc-win32

What mingw is concerned, please note that mingw uses the
run time library of microsoft, that does NOT support
long doubles, at least the last time I checked. There
are then several problems with that:
1) Maybe the compiler uses long doubles internally, but you can't
print them because printf does not understand long doubles.
You can check this by doing long double calculations and then
casting the result to double.
2) I think that mingw people started rewriting some stuff,
and porting glibc that uses its own internal routines
and definitely supports long doubles.

[Richard Heathfield]

jacob navia said:

lcw1964 a écrit :

>I know that the C language in general is not the best environment in
which to do extended precision math work (one would be better off
mastering a high or arbitrary precision library), but I would like to
get the most precision and range out of my calculations under MinGW if
this is available.

The lcc-win32 C compiler offers 100 digits floats, 128 bit integers
bignums, whatever.

More irrelevant spam from Jacob Navia. Enough is enough. I have removed the
lcc-win32 link from my Web site's list of compilers. It will return when
Jacob gets a clue (i.e. probably never).

<snip>

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[lcw1964]

Whoa whoa whoa!

I have just downloaded lcc-win32 and it looks pretty cool, with a lot
of nifty extended math functions and and not bad GUI for software which
for me, as a non-business user, is free.

Did I just wade into a political rats' nest here?

Les

Richard Heathfield wrote:

jacob navia said:

lcw1964 a écrit :

I know that the C language in general is not the best environment in
which to do extended precision math work (one would be better off
mastering a high or arbitrary precision library), but I would like to
get the most precision and range out of my calculations under MinGW if
this is available.

The lcc-win32 C compiler offers 100 digits floats, 128 bit integers
bignums, whatever.

More irrelevant spam from Jacob Navia. Enough is enough. I have removed the
lcc-win32 link from my Web site's list of compilers. It will return when
Jacob gets a clue (i.e. probably never).

<snip>

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[Eric Sosman]

lcw1964 wrote:

Whoa whoa whoa!

I have just downloaded lcc-win32 and it looks pretty cool, with a lot
of nifty extended math functions and and not bad GUI for software which
for me, as a non-business user, is free.

Fine. Use it good health. However, keep in mind that
this compiler (if we are to believe Jacob's description) is
not a C compiler, at least, not a C compiler in its usual
mode of operation. It's some kind of C-plus-extra-goodies
compiler, and if you get hooked on the goodies you may find
that your code won't run on any other systems.

That may or may not be a problem for you; portability is
not the only desirable feature of a piece of code, and is
in some cases worth sacrificing. Just realize that you aren't
getting something for nothing; there's a price to be paid. If
you feel the benefits are worth the price, go ahead and pay --
that's what commerce is all about -- just don't put it on the
ol' credit card and imagine it was free.

Did I just wade into a political rats' nest here?

Jacob has a history of promoting his compiler, especially
to newcomers who may be unwary. He extols its features, he
brags about the latest doodad he's added -- and he claims all
this stuff is "C" simply because his compiler, somewhere back
in its genetic makeup, once had a "C" label attached to it. The
upshot is that nearly every time he posts, other people have to
spend time writing warnings like this one, warnings that would
be unnecessary if he would describe his C-plus-gimmicks accurately.

But, no. In his message on this thread (only his first on
this thread, I fear), he specifically described lcc-win32 as
a "C compiler." It may actually be capable of compiling C, but
he's encouraging you to use "100 digits floats, 128 bit integers
bignums, whatever." The "whatever" alone should raise red flags.

"When in doubt, treat ``feature'' as a pejorative.
(Think of a hundred-bladed Swiss army knife.)"
--Kernighan and Plauger, "Software Tools"

--
Eric Sosman
es*****@acm-dot-org.invalid

[Tom St Denis]

lcw1964 wrote:

This may be in the category of bush-league rudimentary, but I am quite
perplexed on this and diligent Googling has not provided me with a
clear straight answer--perhaps I don't know how to ask the quesion.

I have begun to familiarize myself here with the gcc compiler in a
win32 environment, in the form of MinGW using both Dev C++ and MSYS as
interfaces.

I have recompiled some old math code that uses long double types
throughout and provides the corresponding range and precision (up to 18
digits, with exponents up to about -/+ 4900) when compiled under an
older version of BC++.

Since nobody else brought this up...

Have you thought of trying out Cygwin? It gives you a nice UNIX
emulation layer on-top of the windows runtime (e.g. applications you
write in Cygwin stand half a chance of working on BSD, Linux and UNIX).

I don't know for a fact, but maybe the math libs linked in with Cygwin
can help you out.

Tom

[jacob navia]

lcw1964 a écrit :

Whoa whoa whoa!

I have just downloaded lcc-win32 and it looks pretty cool, with a lot
of nifty extended math functions and and not bad GUI for software which
for me, as a non-business user, is free.

Did I just wade into a political rats' nest here?

Les

Yes. There is a political rat's nest here.

Some people in this group, think that lcc-win32 is a bad compiler
since it has good features in it.

As you know, good features in a copmpiler are bad because
you will use them and like them. The theory goes, you
will get hooked by those evil features, and you will not be
able to use other compilers that do not have them.

You know, it is like ice cream in summer. You like it, and then,
you want more of it.

So, the theory goes, you should not eat ice cream in summer
but hot soup.

But do not worry. Download rates of my compiler system are
anormous, and there are many people using it.

It is widely used in teaching, and many universities have bought
licenses for it.

Just use it. I think you will like it because there are features
like 100 digit precision floats that you will be pressed to find
elsewhere. The math libraries are very extended, as you have noticed.

[Richard Heathfield]

jacob navia said:

lcw1964 a écrit :

>Whoa whoa whoa!

I have just downloaded lcc-win32 and it looks pretty cool, with a lot
of nifty extended math functions and and not bad GUI for software which
for me, as a non-business user, is free.

Did I just wade into a political rats' nest here?

Les

Yes. There is a political rat's nest here.

Some people in this group, think that lcc-win32 is a bad compiler
since it has good features in it.

No, you unutterably stupid man. What we think is bad is your apparent belief
that "C" and "lcc-win32-with-all-its-doodads" are synonymous. They are not.
What we also think is bad is your promotion of non-portable lcc-win32
features in a group where portability is considered very important. If you
want to promote your "good features", the appropriate group in which to do
so is a newsgroup where such features are topical, which is not
comp.lang.c, you unutterably stupid man. And who would want to use a
compiler written by an unutterably stupid man?

As you know, good features in a copmpiler are bad because
you will use them and like them.

No, you unutterably stupid man. Good features in a compiler are fabulous and
wonderful and lovely, as long as you can turn them off when you want to
write portable code. But those features that render the implementation
non-conforming are not topical in the comp.lang.c newsgroup, and that is
why we object to their being discussed here in the comp.lang.c newsgroup,
you unutterably stupid man. And who would want to use a compiler written by
an unutterably stupid man?

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[Tom St Denis]

jacob navia wrote:

Yes. There is a political rat's nest here.

Some people in this group, think that lcc-win32 is a bad compiler
since it has good features in it.

And to think I remember a time when "lcc" referred to an ANSI-C
compiler...

But do not worry. Download rates of my compiler system are
anormous, and there are many people using it.

So what? How many commercial products are made with it? I don't know
of a single shop that uses lcc-win32. They all pretty much use VS and
failing that Cygwin.

I think you really should rename the project if you want to keep up
this crap. Call it JN-Win32 or something. It's clearly not a C
compiler anymore.

I'm half tempted to think this isn't the "real" jacob. Seems like a
clever joe-job.

Tom

[Eric Sosman]

jacob navia wrote:

[...]
You know, it is like ice cream in summer. You like it, and then,
you want more of it.

So, the theory goes, you should not eat ice cream in summer
but hot soup.

I wasn't thinking of ice cream, actually, but of Kool-Aid.
(It wasn't actually Kool-Aid at the Jonestown Massacre, but
the phrase has outrun any casual connection to truth in much
the same way lcc-win32 has outrun any casual connection to C.)

--
Eric Sosman
es*****@acm-dot-org.invalid

[Skarmander]

Richard Heathfield wrote:
[lots of repetitions of the phrase "unutterably stupid man" addressed to
Jacob Navia]

Please try making your points without calling people names. It's childish
and distracting. I don't frequent comp.lang.c for the arguments, but when
there *are* arguments I'd at least expect the participants to remain civil.

Calling mr. Navia "unutterably stupid" as many times as possible is for your
own benefit, as nobody expects such epithets to convince anyone of anything,
except perhaps the immaturity of the speaker. That he was being disingenuous
by deliberately misrepresenting your (and other people's) views doesn't
change that.

In short, if you want to insult someone on a personal level, please use
e-mail. I'm pretty sure your post would have conveyed its non-personal
points equally well without the insults.

S.

[jacob navia]

Eric Sosman a écrit :

I answer to you Eric because there were no insults in
your post. Others, I will just ignore.

You wrote:

lcc-win32 has outrun any casual connection to C.)
In the C standard it is specified in 6.11:

< quote >
6.11 Future language directions
6.11.1 Floating types
1 Future standardization may include additional floating-point types,
including those with greater range, precision, or both than long double.
< end quote >

Lcc-win32 follows this directive. The floating point type "qfloat",
conforms precisely to the usage of other floating point types.

Lcc-win32 specializes in providing the highest support that C can
provide to mathematical users. Together with the qfloat type
an int128 type is provided.

There is nothing in the C standards that specifically
forbids adding extended mathematical types or new kind
of numbers. In general, extensions are NOT forbidden.

In the C standard we read in Paragraph 4: Conformance:

< quote >
A conforming implementation may have extensions (including additional
library functions), provided they do not alter the behavior of any
strictly conforming program.
< end quote >

This is clear. My implementation remains conforming. If you do not
want to use qfloats nobody forces you to.

Concerning the argument that "this group is about standard c"
I have countless times repeated that there is NO LEGAL BASIS
for that since this group has no chart. This is Usenet and
I can express my opinion about this or that as I wish without
anybody having to get upset.

Sincerely

Jacob

[Richard Heathfield]

Tom St Denis said:

<snip>

>
So what? How many commercial products are made with it? I don't know
of a single shop that uses lcc-win32. They all pretty much use VS and
failing that Cygwin.

For Windows, you're pretty much right, although Borland does keep popping up
in odd places. Of course, the visibly commercial world is dominated by
Windows, but there are other commercial avenues. I've worked in a number of
places that use gcc under Linux to write applications that are most
assuredly commercial in nature.

The mainframe C world is, in my experience at least, mostly C/370 and LE370.
Most mainframe programs are for in-house use, obviously, but even mainframe
installations buy in software, and there is a commercial mainframe software
market to meet that need.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[Skarmander]

jacob navia wrote:

This is Usenet and I can express my opinion about this or that as I wish
without anybody having to get upset.

With all due respect, that statement is a contradiction in terms. This *is*
Usenet...

S.

[jacob navia]

Skarmander a écrit :

jacob navia wrote:

>This is Usenet and I can express my opinion about this or that as I wish
without anybody having to get upset.

With all due respect, that statement is a contradiction in terms. This
*is* Usenet...

S.

I do not understand you but anyway, what I wanted to say is that
in the internet groups (that I have been reading and using
since beginning of the 90ties) everybody can express his/her
opinions.

True, I speak about my compiler system in this group, and I think that I
have the right to do so. Specifically, when a user has precision
problems, I think I can point out that after years of effort I have a
compiler system that offers 100 digits in the standard version.

With the growth of the machine power at our disposal, it is increasingly
obvious that we could USE that computing power more, to do calculations
at a level of precision and exactness that wasn't possible in the
times of the PDP 11.

And I think that C, with its emphasis in raw power is the right language
to provide such an extension.

Why should we settle for long double when we can have much more?

A more precise floating type, besides, is mentioned in the C standard.
In the C standard it is specified in 6.11:

< quote >
6.11 Future language directions
6.11.1 Floating types
1 Future standardization may include additional floating-point types,
including those with greater range, precision, or both than long double.
< end quote >

Lcc-win32 follows this directive. The floating point type "qfloat",
conforms precisely to the usage of other floating point types.

This is obviously my personal opinion and I respect anyone who
disagrees with me. As you may have noticed, my posts do not
contain insults or personal attacks to anyone, not even with
people that have a long record of polemic.

[Richard Heathfield]

Skarmander said:

Richard Heathfield wrote:
[lots of repetitions of the phrase "unutterably stupid man" addressed to
Jacob Navia]

Please try making your points without calling people names. It's childish
and distracting. I don't frequent comp.lang.c for the arguments, but when
there *are* arguments I'd at least expect the participants to remain
civil.

It's a reasonable objection, and you do have a point. But...

(a) Lots of worse things have been said here by other people, including Mr
Navia himself, to which you did not object. Why now, and why this?
(b) Either Mr Navia is being stupid or he's using comp.lang.c for commercial
gain. In other words, his constant plugging of lcc-win32's non-portable
features here is either through malice or because of incompetence. I used
Hanlon's Razor.
(c) Some readers of comp.lang.c are clearly not aware of Mr Navia's
continued abuse of this newsgroup, as we have seen in this very thread. I
thought it helpful to draw their attention to one or two examples of the
sloppy thinking Mr Navia constantly displays.
(d) I think many people here would agree that I am one of the more patient
of comp.lang.c's regular contributors (not as patient as Chris Torek, of
course, but then not even Chris Torek is as patient as Chris Torek). That
Mr Navia should provoke such a reaction in a normally patient subscriber
should in itself ring some alarm bells for potential lcc-win32 users.

Calling mr. Navia "unutterably stupid" as many times as possible is for
your own benefit,

Not as many times as possible, by any means. And certainly not for my own
benefit. If I want to call people names for my own benefit, I can do that
offline.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[Skarmander]

jacob navia wrote:

Skarmander a écrit :

>jacob navia wrote:

>>This is Usenet and I can express my opinion about this or that as I wish
without anybody having to get upset.

With all due respect, that statement is a contradiction in terms. This
*is* Usenet...

I do not understand you but anyway, what I wanted to say is that
in the internet groups (that I have been reading and using
since beginning of the 90ties) everybody can express his/her
opinions.

I'll be more explicit: your remark that you can "express [your] opinion
about this or that as I wish without anybody having to get upset" is so
obviously flawed! This is Usenet, of course people will get upset at
opinions, about anything from euthanasia to knitting patterns. I *think*
flame wars were invented on Usenet, too, but they might be older.

Do they *have* to get upset? Well, probably. It's human nature.

True, I speak about my compiler system in this group, and I think that I
have the right to do so. Specifically, when a user has precision
problems, I think I can point out that after years of effort I have a
compiler system that offers 100 digits in the standard version.

And so you did. What one is entitled to (or believes oneself to be entitled
to) is of no concern on Usenet.

With the growth of the machine power at our disposal, it is increasingly
obvious that we could USE that computing power more, to do calculations
at a level of precision and exactness that wasn't possible in the
times of the PDP 11.

And I think that C, with its emphasis in raw power is the right language
to provide such an extension.

Why should we settle for long double when we can have much more?

You're asking the wrong question, and ignoring the points made.

Nobody should fault you for mentioning compiler-specific extensions, as long
as you clearly mention, in ten feet high burning letters, that they *are*
compiler-specific extensions. To simply mention that "my compiler supports
this awesome feature that might be of use to you", without also clearly
mentioning that you're going outside the realm of standard C, is
disingenuous. There are solid reasons the group generally prefers sticking
to standard C, and acknowledging this preference is just a matter of good
manners, especially when making remarks that are self-serving.

A more precise floating type, besides, is mentioned in the C standard.
In the C standard it is specified in 6.11:

< quote >
6.11 Future language directions
6.11.1 Floating types
1 Future standardization may include additional floating-point types,
including those with greater range, precision, or both than long double.
< end quote >

Lcc-win32 follows this directive. The floating point type "qfloat",
conforms precisely to the usage of other floating point types.

Whoa there. This is *not* a directive, and not directed at you in any case.
You are indeed free to implement nonstandard floating point types, but that
is not a result of the section you quoted. That merely says that the
standards committee may add more types in the future. That implementations
may provide extensions so long as this doesn't affect conforming programs is
mentioned elsewhere.

This is obviously my personal opinion and I respect anyone who
disagrees with me. As you may have noticed, my posts do not
contain insults or personal attacks to anyone, not even with
people that have a long record of polemic.

Duly noted, but this does not give you any sort of moral high ground.

S.

[lcw1964]

Thanks, and I know I should try it out, but I must admit that I am
Unix/Linux impaired (I am writing here as an amateur and hobbyist, so
if I should take my query to a more appropriate NG please advise) and I
have not found Cygwin as easy to install as MinGW, which provides all I
need in a couple of self-contained EXEs. The bottom line is that there
a many file choices offered in any cygwin download, and I have no clue
what I need, so I will do a little research first.

I am an evil windows user and am writing only for myself, so I don't
care about cross-platform compatibility, but I do want a long double
type that "means" long double. I understand that MinGW may have a
dependency on msvcrt.dll that casts long double to double.

Les
Tom St Denis wrote:

>
Have you thought of trying out Cygwin? It gives you a nice UNIX
emulation layer on-top of the windows runtime (e.g. applications you
write in Cygwin stand half a chance of working on BSD, Linux and UNIX).

I don't know for a fact, but maybe the math libs linked in with Cygwin
can help you out.

Tom

[Skarmander]

Richard Heathfield wrote:

Skarmander said:

>Richard Heathfield wrote:
[lots of repetitions of the phrase "unutterably stupid man" addressed to
Jacob Navia]

Please try making your points without calling people names. It's childish
and distracting. I don't frequent comp.lang.c for the arguments, but when
there *are* arguments I'd at least expect the participants to remain
civil.

It's a reasonable objection, and you do have a point. But...

(a) Lots of worse things have been said here by other people, including Mr
Navia himself, to which you did not object. Why now, and why this?

Phase of the moon. I'm not singling you out, if that's what you think. This
post just leapt at me. I'm not usually a net.nanny, but I personally dislike
reading childish bickering, and I may make the occasional remark.

(b) Either Mr Navia is being stupid or he's using comp.lang.c for commercial
gain. In other words, his constant plugging of lcc-win32's non-portable
features here is either through malice or because of incompetence. I used
Hanlon's Razor.
(c) Some readers of comp.lang.c are clearly not aware of Mr Navia's
continued abuse of this newsgroup, as we have seen in this very thread. I
thought it helpful to draw their attention to one or two examples of the
sloppy thinking Mr Navia constantly displays.
(d) I think many people here would agree that I am one of the more patient
of comp.lang.c's regular contributors (not as patient as Chris Torek, of
course, but then not even Chris Torek is as patient as Chris Torek). That
Mr Navia should provoke such a reaction in a normally patient subscriber
should in itself ring some alarm bells for potential lcc-win32 users.

I don't fault you for expressing your opinion (and I do see your point); I
was just slightly put off by the style.

>Calling mr. Navia "unutterably stupid" as many times as possible is for
your own benefit,

Not as many times as possible, by any means. And certainly not for my own
benefit. If I want to call people names for my own benefit, I can do that
offline.

Alright, so you really *were* trying to convince people he's unutterably
stupid. My mistake...

S.

[Richard Heathfield]

jacob navia said:

<snip>

>
This is obviously my personal opinion and I respect anyone who
disagrees with me. As you may have noticed, my posts do not
contain insults or personal attacks to anyone, not even with
people that have a long record of polemic.

"Genius programmers like you should not use lcc-win32." - Jacob Navia.
"Excuse me sir. Should I speak to you as "your holiness" maybe ?" - Jacob
Navia.
"Your language (hopes to cover his silly ass, etc) just shows your anal
fixation... Go to a doctor man." - Jacob Navia.
"Please turn on your brain before complaining..." - Jacob Navia.

etc etc ad nauseam.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[jacob navia]

Skarmander a écrit :

[snip]
[Jacob navia wrote]

>A more precise floating type, besides, is mentioned in the C standard.
In the C standard it is specified in 6.11:

< quote >
6.11 Future language directions
6.11.1 Floating types
1 Future standardization may include additional floating-point types,
including those with greater range, precision, or both than long double.
< end quote >

Lcc-win32 follows this directive. The floating point type "qfloat",
conforms precisely to the usage of other floating point types.

[Skarmander wrote]

Whoa there. This is *not* a directive, and not directed at you in any
case. You are indeed free to implement nonstandard floating point types,
but that is not a result of the section you quoted. That merely says
that the standards committee may add more types in the future. That
implementations may provide extensions so long as this doesn't affect
conforming programs is mentioned elsewhere.

Excuse me but "Future directions" means what it says: the directions
the comitee wants to follow in future issues of the standard.

Besides, in the paragraph J: "Common extensions" we have:

< quote >
J.5.6 Other arithmetic types
1 Additional arithmetic types, such as _ _int128 or double double, and
their appropriate conversions are defined (6.2.5, 6.3.1). Additional
floating types may have more range or precision than long double, may be
used for evaluating expressions of other floating types, and may be used
to define float_t or double_t.

< end quote >

This means that qfloat is included in the "common extensions" feature of
the standard, that explicitely mentions things that are not standard
but sufficiently common to be OKed, even if this is not normative.

All this extensions can be disabled when invoking the compiler with
-ansic
flag.

[Skarmander]

jacob navia wrote:

Skarmander a écrit :

[snip]
[Jacob navia wrote]

>>A more precise floating type, besides, is mentioned in the C standard.
In the C standard it is specified in 6.11:

< quote >
6.11 Future language directions
6.11.1 Floating types
1 Future standardization may include additional floating-point types,
including those with greater range, precision, or both than long double.
< end quote >

Lcc-win32 follows this directive. The floating point type "qfloat",
conforms precisely to the usage of other floating point types.

[Skarmander wrote]

>Whoa there. This is *not* a directive, and not directed at you in any
case. You are indeed free to implement nonstandard floating point
types, but that is not a result of the section you quoted. That merely
says that the standards committee may add more types in the future.
That implementations may provide extensions so long as this doesn't
affect conforming programs is mentioned elsewhere.

Excuse me but "Future directions" means what it says: the directions
the comitee wants to follow in future issues of the standard.

Exactly, and you are not the committee. Section 6.11 is not any sort of hint
or instruction to implementers to extend the language. Your remark about
"following" this directive made no sense.

Besides, in the paragraph J: "Common extensions" we have:

< quote >
J.5.6 Other arithmetic types
1 Additional arithmetic types, such as _ _int128 or double double, and
their appropriate conversions are defined (6.2.5, 6.3.1). Additional
floating types may have more range or precision than long double, may be
used for evaluating expressions of other floating types, and may be used
to define float_t or double_t.

< end quote >

This means that qfloat is included in the "common extensions" feature of
the standard, that explicitely mentions things that are not standard
but sufficiently common to be OKed, even if this is not normative.

I explicitly said implementations are allowed to provide such extensions, as
does the standard. This is not contested. I merely pointed out that the
section you quoted earlier is irrelevant to the specific point you were
making - and that is all.

All this extensions can be disabled when invoking the compiler with
-ansic
flag.

A step up from many other compilers, for sure.

S.

[Gordon Burditt]

lcc-win32 has outrun any casual connection to C.)

>

In the C standard it is specified in 6.11:

< quote >
6.11 Future language directions
6.11.1 Floating types
1 Future standardization may include additional floating-point types,
including those with greater range, precision, or both than long double.
< end quote >

Lcc-win32 follows this directive. The floating point type "qfloat",
conforms precisely to the usage of other floating point types.

Lcc-win32 specializes in providing the highest support that C can
provide to mathematical users. Together with the qfloat type
an int128 type is provided.

There is nothing in the C standards that specifically
forbids adding extended mathematical types or new kind
of numbers. In general, extensions are NOT forbidden.

Does the following compile?

int foo(void)
{
float qfloat, class, new, delete;

/* ... bunch of stuff that uses these variables */
return 0;
}

If 'qfloat' is a built-in typedef or something similar, you've
got problems. If, on the other hand, you have to include <qfloat.h>
in order to use the qfloat type, you're OK.

>In the C standard we read in Paragraph 4: Conformance:

< quote >
A conforming implementation may have extensions (including additional
library functions), provided they do not alter the behavior of any
strictly conforming program.
< end quote >

That includes namespace issues over the name 'qfloat'.

>This is clear. My implementation remains conforming. If you do not
want to use qfloats nobody forces you to.

Gordon L. Burditt

[Tom St Denis]

jacob navia wrote:

Lcc-win32 follows this directive. The floating point type "qfloat",
conforms precisely to the usage of other floating point types.

Lcc-win32 specializes in providing the highest support that C can
provide to mathematical users. Together with the qfloat type
an int128 type is provided.

The problem I have with this is that C++ addresses this fairly well.
If you really want to give people large floats write a C++ library
using operation overloading. That way people are not tied to your
compiler platform and can best use the technology.

Tom

[lcw1964]

jacob navia wrote:

>
Just use it. I think you will like it because there are features
like 100 digit precision floats that you will be pressed to find
elsewhere. The math libraries are very extended, as you have noticed.

I am just interested in writing some math code for myself and higher
precision, if it gives consistently valid results and I can learn to
use the provided libraries to advantage. This will take some learning
and experimenting. I am not interested in portability, though I do
respect for the serious developer that that is desireable.

Monsieur Navia, I thank you for directing me to your product and I will
experiment with it at my leisure. Since I am not programming space
shuttle navigation systems I don't need mission critical perfection,
and just want to learn something new. As I am not programming for
commercial purposes I will not purchase a license and will take your
referral to your product as free advice, and will give you the benefit
of the doubt as to your intentions.

However, sir, if there is a legitimate complaint here in the group that
you are not totally transparent in disclosing the features and
limitations of your product, I would encourage you to look at that
honestly. But I know it is hard to take a humble and self-reflective
stance when one's critics imbue feedback with ad hominem personal
attacks. I stopped reading the ranting of one of your critics in this
thread when he demeaned himself to calling you a "stupid man". I think
it is possible that you may have very different ideas than many
professional programmers about what is or is not desireable in a
software development product, and you are entitled to your view and
your own market niche. But getting personal seems a little excessive.
However, like I said, if this acrimony emanates from legitimate
misgivings about what your product offers vis-a-vis the other
alternatives out there, it may be wise to accept that feedback and try
to disentangle the personal attacks from the worthwhile advice.

This all said, I must admit to a tinge of resentment myself by the
implication in some posts in this thread that I could be a naive "mark"
about to be sold Florida swamp land from the consummate confidence man.
Words like "bush-league", "hobbyist", "inexperience", etc., connote
only my amateur status, not stupidity. Heck, I write simple C programs
for fun, so I obviously must have an IQ about 80 at least, so I deserve
some credit. Thanks, but no thanks, for the warning, I am a big boy,
and can take care of myself.

Mr. Navia, if I have any questions about your product I will write you.
As for the rest of you, can you move the flame war to another thread
and get back to helping me out by trying to answer my original
question?

Les

[jacob navia]

Richard Heathfield a écrit :

jacob navia said:

<snip>

>>This is obviously my personal opinion and I respect anyone who
disagrees with me. As you may have noticed, my posts do not
contain insults or personal attacks to anyone, not even with
people that have a long record of polemic.

"Genius programmers like you should not use lcc-win32." - Jacob Navia.

Where do I insult someone with that remark?
I advise you not to use a compiler system that
you tell again and again that is bad.

"Excuse me sir. Should I speak to you as "your holiness" maybe ?" - Jacob
Navia.

Yes, I was treating you of "Richard" and you
protested (I think you thought that "Richard" is an insult:-)

Bewildered I asked you back how should I treat you. Well
I have settled for "Heathfield". I hope you do not
think that is an insult, Heathfield.

"Your language (hopes to cover his silly ass, etc) just shows your anal
fixation... Go to a doctor man." - Jacob Navia.

I was complaining about bad manners. I definitely do not
like people that swear and put "ass" in every sentence.
Note that there are no insults in my post.

"Please turn on your brain before complaining..." - Jacob Navia.

That is an advise Heathfield. Nowhere there is an insult.

An advise that with good manners discussions are less emotional
and more to the point. Flame fests are so boring.

You do not like lcc-win32?

You are not the only one. Please keep cool and expose your views.

Explain why providing features like 100 digits precision is
bad for the user.

Go ahead.

jacob

[Skarmander]

jacob navia wrote:
<snip>

An advise that with good manners discussions are less emotional
and more to the point. Flame fests are so boring.

Then don't fan the flames.

You do not like lcc-win32?

You are not the only one. Please keep cool and expose your views.

Explain why providing features like 100 digits precision is
bad for the user.

Go ahead.

Plus ça change, plus c'est la même chose.

You *know* this is not what he was saying or even implying, so why do you
insist on attributing it to him? I can only imagine that you *like*
pointless discussions.

Knock yourself out.

S.

[Richard Heathfield]

jacob navia said:

Richard Heathfield a écrit :

>jacob navia said:

<snip>

>>>This is obviously my personal opinion and I respect anyone who
disagrees with me. As you may have noticed, my posts do not
contain insults or personal attacks to anyone, not even with
people that have a long record of polemic.

"Genius programmers like you should not use lcc-win32." - Jacob Navia.

Where do I insult someone with that remark?

Either it's sarcastic or it's not. If it's sarcastic, it's a personal
attack. If it's not sarcastic, you are advising intelligent programmers not
to use your product. Which is it?

>"Excuse me sir. Should I speak to you as "your holiness" maybe ?" -
Jacob Navia.

Yes, I was treating you of "Richard" and you
protested (I think you thought that "Richard" is an insult:-)

You are confused. The comment I quoted was not addressed to me. I am not
your only target by any means.

>"Your language (hopes to cover his silly ass, etc) just shows your anal
fixation... Go to a doctor man." - Jacob Navia.

I was complaining about bad manners.

It is bad manners to use comp.lang.c for constant plugging of your
commercial product. So please stop doing it.

<snip>

>
You do not like lcc-win32?

I have no idea. I've never, ever tried it. And because of your appalling
behaviour here in comp.lang.c, it is unlikely that I ever will.

Explain why providing features like 100 digits precision is
bad for the user.

I never claimed it was. Learn to read before responding.
--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[Flash Gordon]

Gordon Burditt wrote:

Javob wrote the material quoted by Gordon.

Gordon, please start providing attributions. Consider this yet another
complaint on the long list of complaints about you not providing
attributions.

> lcc-win32 has outrun any casual connection to C.)
In the C standard it is specified in 6.11:

< quote >
6.11 Future language directions
6.11.1 Floating types
1 Future standardization may include additional floating-point types,
including those with greater range, precision, or both than long double.
< end quote >

Lcc-win32 follows this directive. The floating point type "qfloat",
conforms precisely to the usage of other floating point types.

Lcc-win32 specializes in providing the highest support that C can
provide to mathematical users. Together with the qfloat type
an int128 type is provided.

There is nothing in the C standards that specifically
forbids adding extended mathematical types or new kind
of numbers. In general, extensions are NOT forbidden.

Does the following compile?

#include <math.h>
#include <float.h>
#include <stdlib.h>
#include <stdio.h>
/* Add other standard headers to taste. After all, the standard headers
are not allowed to invade user namespace either */

int foo(void)
{
float qfloat, class, new, delete;

/* ... bunch of stuff that uses these variables */
return 0;
}

If 'qfloat' is a built-in typedef or something similar, you've
got problems. If, on the other hand, you have to include <qfloat.h>
in order to use the qfloat type, you're OK.

Agreed. However, qfloat would still not be topical here. Although I
would have said implementing it as __qfloat would have been better.

>In the C standard we read in Paragraph 4: Conformance:

< quote >
A conforming implementation may have extensions (including additional
library functions), provided they do not alter the behavior of any
strictly conforming program.
< end quote >

That includes namespace issues over the name 'qfloat'.

>This is clear. My implementation remains conforming. If you do not
want to use qfloats nobody forces you to.

Only if it does not invade user namespace.
--
Flash Gordon
Still sigless on this computer

[Eric Sosman]

jacob navia wrote:

Eric Sosman a écrit :

I answer to you Eric because there were no insults in
your post. Others, I will just ignore.

If only you'd be as good as your word -- but you broke
it less than twenty minutes later, going by the time stamps
on my news server.

Concerning the argument that "this group is about standard c"

... an argument I did not make ...

I have countless times repeated that there is NO LEGAL BASIS
for that since this group has no chart.

"Charter." No, comp.lang.c traces its origins to the days
before newsgroup charters existed, as you quite well know. The
lack of charter is not an indication that the group is a free-
for-all in which all things are topical; *all* newsgroups from
those early days were created without charters. That doesn't
mean they were created without purpose.

This is Usenet and
I can express my opinion about this or that as I wish without
anybody having to get upset.

This is Usenet, and others are free to express their opinions
about lcc-win32, Jacob Navia, the relative merits of Steinway and
Yamaha pianos, and equally relevant topics.

As you may have noticed, my posts do not
contain insults or personal attacks to anyone, not even with
people that have a long record of polemic.

Your non-polemical, non-attacking posts have in the past
employed a rather vigorous vocabulary ...

--
Eric Sosman
es*****@acm-dot-org.invalid

[Michael Mair]

Tom St Denis schrieb:

jacob navia wrote:

>>Yes. There is a political rat's nest here.

Some people in this group, think that lcc-win32 is a bad compiler
since it has good features in it.

And to think I remember a time when "lcc" referred to an ANSI-C
compiler...

It still is (*) -- appending the pejorative "win32" to a certain branch
somehow rotted said branch's "C-ness". Go figure.

Not really serious
Michael

(*) lcc indeed is still a C compiler; for example, Matlab comes with
lcc as mex compiler (if you do not have something better).
--
E-Mail: Mine is an /at/ gmx /dot/ de address.

[Keith Thompson]

Eric Sosman <es*****@acm-dot-org.invalidwrites:

lcw1964 wrote:

>Whoa whoa whoa!
I have just downloaded lcc-win32 and it looks pretty cool, with a lot
of nifty extended math functions and and not bad GUI for software which
for me, as a non-business user, is free.

Fine. Use it good health. However, keep in mind that
this compiler (if we are to believe Jacob's description) is
not a C compiler, at least, not a C compiler in its usual
mode of operation. It's some kind of C-plus-extra-goodies
compiler, and if you get hooked on the goodies you may find
that your code won't run on any other systems.

[...]

To be fair, many, perhaps most, C compilers are non-conforming in
their default mode, and many, perhaps most, C compilers offer
extensions. Consider gcc, for example. The C standard specifically
allows extensions as long as they don't break any strictly conforming
code; extensions that do break strictly conforming code are allowed as
long as there's a mode in which those extensions are disabled.

My understanding is that lcc-win32 provides command-line options that
disable its extensions and cause it to operate as a conforming C
compiler, either for C90 or for C99. I don't know how good its C99
conformance is.

In effect, a compiler in conforming mode and the same compiler in
another mode that provides non-standard extensions are two different
implementations, one conforming and one not. The C standard logically
has nothing to say about non-conforming implementations, other than
that they're non-conforming.

Since this newsgroup discusses standard C, we tend to place more
emphasis on standard conformance and portability than might be
necessary in other contexts. There's definitely a price to be paid
for whatever benefits you get from using non-portable extensions.
Only you can decide whether it's worth the price.

In my opinion, it's very important, at the very least, to be aware of
which features are defined by the standard and which are
compiler-specific extensions. If you find some lcc-win32 extension
useful, go ahead and use it -- but be aware that other compilers are
unlikely to support it, and you won't be able to compile your code on
any platform that lcc-win32 doesn't support. jacob tends to gloss
over this fact.

There are a number of C-based languages. One of them is C++; it has
several newsgroups devoted to it, including comp.lang.c++. Another is
Objective C; it has its own newsgroup, comp.lang.objective-c. And
another is the extended C-like language supported by lcc-win32 in its
non-conforming mode; feel free to discuss that in comp.compilers.lcc.
(Note that lcc and lcc-win32 are two different things, one derived
from the other; see the relevant web pages for details.)

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[jacob navia]

Gordon Burditt a écrit :

Does the following compile?

int foo(void)
{
float qfloat, class, new, delete;

/* ... bunch of stuff that uses these variables */
return 0;
}

If 'qfloat' is a built-in typedef or something similar, you've
got problems. If, on the other hand, you have to include <qfloat.h>
in order to use the qfloat type, you're OK.

THANKS!

I have just discovered a bug (<grin>)

I was initializing types before I parsed the command line options,
so qfloat would always be defined even if you specified -ansic.

I have fixed this, and now your example compiles without any
problems with lcc -ansic

jacob

[Keith Thompson]

jacob navia <ja***@jacob.remcomp.frwrites:

lcw1964 a écrit :

>Whoa whoa whoa!
I have just downloaded lcc-win32 and it looks pretty cool, with a lot
of nifty extended math functions and and not bad GUI for software which
for me, as a non-business user, is free.
Did I just wade into a political rats' nest here?

Yes. There is a political rat's nest here.

Some people in this group, think that lcc-win32 is a bad compiler
since it has good features in it.

Nonsense. Nobody has said that, or anything resembling it. A number
of us have explained in detail our objections to the way you promote
lcc-win32's extensions in this newsgroup. You have repeatedly
responded to these objections as if people were attacking the compiler
itself, or you personally. (And yes, sometimes we get frustrated.)

Try to understand our arguments without filtering them through your
own preconceptions.

lcc-win32 implements some possibly useful extensions. There's nothing
wrong with that, and I don't recall anybody attacking you for it.

Any code that depends on those extensions will not be portable to
compilers other than lcc-win32, or to platforms that lcc-win32 doesn't
support. (The name implies that it supports only 32-bit Windows; is
that correct?) It's very important for potential users to be aware of
that fact. You often suggest specific features supported only by
lcc-win32 without mentioning the portability issue.

Languages based on C are not C, and are not topical in comp.lang.c.
For example, C++, Objective C, and the extended C-like language
supported by lcc-win32 are not C, and are off-topic here. Each of
these has one or more newsgroups in which it is perfectly topical. I
don't think a brief suggestion that another language might be useful,
with a pointer to an apropriate newsgroup, would be objectionable.
Detailed discussions of these non-C languages are objectionable.

Of all the things you've posted here that people have complained
about, I can't think of any that I'd consider inappropriate if you had
posted them to comp.compilers.lcc. Think about that.

[snip]

Just use it. I think you will like it because there are features
like 100 digit precision floats that you will be pressed to find
elsewhere. The math libraries are very extended, as you have noticed.

Sure, go ahead and use it *if* you don't mind paying the price in loss
of portability. And if you have any questions about the extensions,
please ask them in comp.compilers.lcc, not here.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[P.J. Plauger]

"lcw1964" <le***********@alumni.uwo.cawrote in message
news:11********************@p79g2000cwp.googlegrou ps.com...

My question is this--does MinGW offer the "true" long double floating
point 80bit type, and if so how can I get my programs to display
results of the sort I mentioned in the previous paragraph is printf()
needs recasting to double in order to handle it?

Gosh, after all this noise, I'm not sure you still care about an
answer to your original question, but here it is. Mingw fails to
set the FPP in a proper state at program startup to do long double
arithmetic well. Our library executes:

fesetenv(FE_DFL_ENV); // correct FPP mode

whenever we use the native Mingw library and it works much better.
(It's still nowhere near as good as our library, but what with all
the flak about promoting third-party libraries, I hesitate to
mention that. You will notice, however, that *we* found the bug --
years ago. That tells you something about who tests what.)

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

[Keith Thompson]

jacob navia <ja***@jacob.remcomp.frwrites:
[...]

Excuse me but "Future directions" means what it says: the directions
the comitee wants to follow in future issues of the standard.

Besides, in the paragraph J: "Common extensions" we have:

< quote >
J.5.6 Other arithmetic types
1 Additional arithmetic types, such as _ _int128 or double double, and
their appropriate conversions are defined (6.2.5, 6.3.1). Additional
floating types may have more range or precision than long double, may
be
used for evaluating expressions of other floating types, and may be used
to define float_t or double_t.

< end quote >

Providing __int128 or double double would not break any strictly
conforming code. The identifier __int128 is in the implementation's
namespace, and "double double" is a syntax error; no strictly
conforming program can use either.

This means that qfloat is included in the "common extensions" feature of
the standard, that explicitely mentions things that are not standard
but sufficiently common to be OKed, even if this is not normative.

There's no mention of "qfloat" in the standard.

If I can't use "qfloat" as an identifier in my own code, then the
implementation is non-conforming. If I can't use "qfloat" as an
identifier *and* use your extension, then you've implemented your
extension in a non-conforming manner.

You're allowed to do so, but I object to your insistence on discussing
it here.

All this extensions can be disabled when invoking the compiler with
-ansic flag.

That's good, seriously.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Richard Heathfield]

Keith Thompson said:

jacob navia <ja***@jacob.remcomp.frwrites:
[...]

<snip>

>

>All this extensions can be disabled when invoking the compiler with
-ansic flag.

That's good, seriously.

But it's not true (at least for the qfloat thing), for any users that
obtained their copy of lcc-win32 prior to this discussion (see elsethread,
where Mr Navia admits that he's had to fix the compiler as a result of this
discussion).

Up until now, many of us have taken Mr Navia's claims about
conformance-on-request at face value. But now one cannot help but wonder
how many other similar conformance issues exist within lcc-win32, as yet
undetected by Mr Navia.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[Keith Thompson]

"lcw1964" <le***********@alumni.uwo.cawrites:
[...]

I have recompiled some old math code that uses long double types
throughout and provides the corresponding range and precision (up to 18
digits, with exponents up to about -/+ 4900) when compiled under an
older version of BC++.

You're making an assumption about the correct range and precision of
long double.

In the MinGW incarnation of gcc, I have made a couple of adjustments to
get it to compile--in particular, _atold() doesn't exist, and atof() is
prototyped only in stdlib.h whereas in BC++ it is listed in math.h too.

MinGW is correct about atof(); according to the standard, it's
declared in <stdlib.h>, not in <math.h>. _atold() is non-standard, so
you can't use it in portable code.

However, I kept all of my long double declarations and outputs as that,
and used all of the long double versions of the math functions--expl(),
fabsl(), etc. The file complied but the output was gibberish. It took a
little googling to find that I had to recast the long double output as
double so printf() could meaningfully display it.

No, you just have to use the correct format. Use "%e", "%g", or "%f"
for float or double (float is promoted to double in a call to
printf()); use "%Le", "Lg", or "%Lf" for long double.

However, I have come to suspect that MinGW's long double isn't really
long double, and that somewhere in the process the range and precision
of of the floating point math has been restricted to the double range.
For example, in the original code under BC++ (not MSVC++, which is well
known to recast everything as double) I can generate a meaningful
answer of, say 1.34598900000098888e-2345, whereas the MinGW compiled
version will render this tiny value as simply 0.

C defines three floating-point types: float, double, and long double.
The standard requires float to have a precision of at least 6 decimal
digits; double and long double require at least 10. The maximum
representable value for all three types is required to be at least
1E+37.

There's no requirement for long double to be bigger than double; they
could have exactly the same representation (just as short and int or
int and long often have the same representation). The type "long
double" exists to *allow* an implementation to provide a large type,
not to require it.

My question is this--does MinGW offer the "true" long double floating
point 80bit type, and if so how can I get my programs to display
results of the sort I mentioned in the previous paragraph is printf()
needs recasting to double in order to handle it?

I don't know whether MinGW offers a long double type bigger than
double, though the fact that you had trouble printing long double
values makes me suspect that it does.

Try compiling and executing this program:

#include <float.h>
#include <limits.h>
#include <stdio.h>
int main(void)
{
printf("float is %d bits\n", CHAR_BIT * (int)sizeof(float));
printf("double is %d bits\n", CHAR_BIT * (int)sizeof(double));
printf("long double is %d bits\n", CHAR_BIT * (int)sizeof(long double));
printf("\n");

printf("FLT_DIG = %d\n", FLT_DIG);
printf("DBL_DIG = %d\n", DBL_DIG);
printf("LDBL_DIG = %d\n", LDBL_DIG);
printf("\n");

printf("FLT_MIN = %g\n", FLT_MIN);
printf("DBL_MIN = %g\n", DBL_MIN);
printf("LDBL_MIN = %Lg\n", LDBL_MIN);
printf("\n");

printf("FLT_MAX = %g\n", FLT_MAX);
printf("DBL_MAX = %g\n", DBL_MAX);
printf("LDBL_MAX = %Lg\n", LDBL_MAX);

return 0;
}

Note that the number of bits doesn't necessarily mean that all those
bits are used; you might have a 96-bit long double of which only 80
bits are actually used.

There's another potential problem. An implementation consists of two
parts, the compiler and the runtime library (plus the linker and
perhaps a few other things). Very often the runtime library is
provided as part of the operating system, and the compiler is provided
by a third party, so they might not be in sync. If your compiler
assumes that long double has one representation, and your runtime
library's implementation of printf() assumes a different
representation, you're going to have problems. In that case, you have
a non-conforming (broken) implementation -- and there might not be
much you can do about it.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[jacob navia]

P.J. Plauger a écrit :

"lcw1964" <le***********@alumni.uwo.cawrote in message
news:11********************@p79g2000cwp.googlegrou ps.com...

>>My question is this--does MinGW offer the "true" long double floating
point 80bit type, and if so how can I get my programs to display
results of the sort I mentioned in the previous paragraph is printf()
needs recasting to double in order to handle it?

Gosh, after all this noise, I'm not sure you still care about an
answer to your original question, but here it is. Mingw fails to
set the FPP in a proper state at program startup to do long double
arithmetic well. Our library executes:

fesetenv(FE_DFL_ENV); // correct FPP mode

whenever we use the native Mingw library and it works much better.
(It's still nowhere near as good as our library, but what with all
the flak about promoting third-party libraries, I hesitate to
mention that. You will notice, however, that *we* found the bug --
years ago. That tells you something about who tests what.)

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

This is unclear.

FE_DFL_ENV is a macro that "designates the default environment"
as the standard says (7.6.1)

Specifically in this case however, do you set the FPU at full precision
(80 bits) or you stay in 64 bit mode?

lcc-win32 sets full precision at 80 bits.

The other problem with mingw is the run time library. Last time
I checked they do not provide a C99 compliant printf, so it is very
difficult to print long double data.

[jacob navia]

The mingw documentation says:
http://www.mingw.org/MinGWiki/index.php/long%20double

< quote >
Minimalist GNU for Windows
Printing and formatting long double values

mingw uses the Microsoft C run-time libraries and their implementation
of printf does not support the 'long double' type. As a work-around, you
could cast to 'double' and pass that to printf instead. For example:

printf("value = %g\n", (double) my_long_double_value);

Note that a similar problem exists for 'long long' type. Use the 'I64'
(eye sixty-four) length modifier instead of gcc's 'll' (ell ell). For
example:

printf("value = %I64d\n", my_long_long_value);

See also long long

< end quote >

[Chris Torek]

>"lcw1964" <le***********@alumni.uwo.cawrites:

>[...]

>I have recompiled some old math code that uses long double types
throughout and provides the corresponding range and precision (up to 18
digits, with exponents up to about -/+ 4900) when compiled under an
older version of BC++.

In article <ln************@nuthaus.mib.org>
Keith Thompson <ks***@mib.orgwrote:

>You're making an assumption about the correct range and precision of
long double.

This range is not required by C, but is provided by the target
architecture. (That makes this *particular* detail off-topic in
comp.lang.c, of course.) The on-topic part is whether implementations
are required to distinguish between "double" and "long double",
both in terms of compile-time type (where the answer is "yes") and
in terms of sizeof(), precision, and so on (where the answer is
"no").

A related question: if you compile and run:

#include <stdio.h>

int main(void) {

printf("sizeof(double): %lu\n",
(unsigned long)sizeof(double));
printf("sizeof(long double): %lu\n",
(unsigned long)sizeof(long double));
return 0;
}

and get two different numbers, does this mean that the values for
DBL_* and LDBL_* in <float.hmust be different? (I would say
"no": for instance, you can have a compiler in which sizeof(long
double) is bigger but the extra bytes are simply wasted. Not very
useful, but then, the Standard rarely imposes any requirement that
a compiler be any good. :-) )

>In the MinGW incarnation of gcc, I have made a couple of adjustments to
get it to compile--in particular, _atold() doesn't exist, and atof() is
prototyped only in stdlib.h whereas in BC++ it is listed in math.h too.

>MinGW is correct about atof(); according to the standard, it's
declared in <stdlib.h>, not in <math.h>. _atold() is non-standard, so
you can't use it in portable code.

And the (C99) standard routine for extracting a long double is
strtold(), also in <stdlib.h>. (Or of course you can use scanf
with "%Lf" and the like.)

>There's another potential problem. An implementation consists of two
parts ...

More precisely, most *real* implementations consist of multiple
parts (at least two, usually quite a few more). A few (usually
toy) implementations actually package everything up into one seamless
-- and hence inflexible and unextendable -- whole. (I prefer
systems with "beautiful seams", as Mark Weiser once called them.)

>the compiler and the runtime library (plus the linker and
perhaps a few other things).

(those being some of the "more")

>Very often the runtime library is provided as part of the operating
system, and the compiler is provided by a third party, so they
might not be in sync. If your compiler assumes that long double
has one representation, and your runtime library's implementation
of printf() assumes a different representation, you're going to
have problems. In that case, you have a non-conforming (broken)
implementation -- and there might not be much you can do about it.

I believe this is in fact the problem here. The easiest thing to
do about it is usually to find a different, less- or non-broken
implementation.

Also (though neither you nor the OP appear to need this), I have some
related comments in <http://web.torek.net/c/numbers.html>.
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) [phone]
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.

[Keith Thompson]

jacob navia <ja***@jacob.remcomp.frwrites:
[...]

The other problem with mingw is the run time library. Last time
I checked they do not provide a C99 compliant printf, so it is very
difficult to print long double data.

As far as I know, C99 didn't add anything new to printf related to
long double (except "%La" and "%LA" for hexadecimal output, but I
don't think that's what we're talking about).

This:

#include <stdio.h>
int main(void)
{
long double x = 42.0;
printf("x = %Lg\n", x);
return 0;
}

is valid in both C90 and C99.

(I think some versions of gcc have printed misleading warnings about
something like this; I don't remember the exact details.)

So if mingw's runtime library doesn't support printing long doubles,
it's not a C99-specific problem. (It may be a mismatch between the
compiler and the library.)

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Keith Thompson]

Richard Heathfield <in*****@invalid.invalidwrites:

Keith Thompson said:

>jacob navia <ja***@jacob.remcomp.frwrites:
[...]

<snip>

>>

>>All this extensions can be disabled when invoking the compiler with
-ansic flag.

That's good, seriously.

But it's not true (at least for the qfloat thing), for any users that
obtained their copy of lcc-win32 prior to this discussion (see elsethread,
where Mr Navia admits that he's had to fix the compiler as a result of this
discussion).

In fairness, that particular case strikes me as a relatively minor
bug, something common to almost all software -- and he did fix it
quickly.

Since I've never really used lcc-win32, I have no real basis for
judging how buggy it is in general. (I decline, at least for now, to
judge jacob's programming skills on the basis of his debating skills.)

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Keith Thompson]

jacob navia <ja***@jacob.remcomp.frwrites:

The mingw documentation says:
http://www.mingw.org/MinGWiki/index.php/long%20double

< quote >
Minimalist GNU for Windows
Printing and formatting long double values

mingw uses the Microsoft C run-time libraries and their implementation
of printf does not support the 'long double' type. As a work-around,
you could cast to 'double' and pass that to printf instead. For
example:

printf("value = %g\n", (double) my_long_double_value);

Note that a similar problem exists for 'long long' type. Use the 'I64'
(eye sixty-four) length modifier instead of gcc's 'll' (ell ell). For
example:

printf("value = %I64d\n", my_long_long_value);

See also long long

< end quote >

I suspect that this may be, if not incorrect, at least just a little
bit misleading. It seems likely that the Microsoft C run-time library
does support "long double" -- just not the same representation of
"long double" used by MinGW's compiler. But in any case, casting to
double is a decent workaround, unless you really need to display more
precision than double provides.

It would also be nice if it mentioned that "%lld" is the form
specified by the standard, not just a gcc vs. Microsoft thing. (And
it's not gcc that implements printf anyway, it's the runtime library,
which is *not* part of gcc -- though gcc does recognize printf formats
for the purpose of issuing warnings.)

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Keith Thompson]

Chris Torek <no****@torek.netwrites:
[...]

Also (though neither you nor the OP appear to need this), I have some
related comments in <http://web.torek.net/c/numbers.html>.

The correct URL appears to be <http://www.torek.net/torek/c/numbers.html>.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[P.J. Plauger]

"jacob navia" <ja***@jacob.remcomp.frwrote in message
news:44*********************@news.orange.fr...

This is unclear.

FE_DFL_ENV is a macro that "designates the default environment"
as the standard says (7.6.1)

Specifically in this case however, do you set the FPU at full precision
(80 bits) or you stay in 64 bit mode?

lcc-win32 sets full precision at 80 bits.

IIRC, the mode is described in terms of the number of precision bits,
not the number of bits in the full floating-point representation.
Thus the choice is between 53-bit mode, good for 64-bit IEEE "double"
representation, or 64-bit, good for extended IEEE 80-bit "long double"
representation. Our FE_DFL_ENV ensures that the 80-bit representation
gives sensible results with Mingw. The startup code that Mingw
normally relies on does not.

The other problem with mingw is the run time library. Last time
I checked they do not provide a C99 compliant printf, so it is very
difficult to print long double data.

That may be true, but the problem goes deeper than that. Mingw, left
to its own devices, doesn't even *compute* good long double results
internally.

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

[lcw1964]

Wow! My original query stimulated a lot of discussion, even when one
disregards the heated segue in the lcc-win32 business.

I thank everyone for their time and thoughtful comments. This is
obviously a more complex issue than I at first naively imagined, and I
have been directed to several helpful resources and have learned a
great deal. The question was obviously worth posting--if not, there
would not have been such involved helpful discussion.

Many thanks again,

Les

[lcw1964]

jacob navia wrote:

>
The lcc-win32 C compiler offers 100 digits floats, 128 bit integers
bignums, whatever.

After spending a few hours trying to painstakingly port some simple
code to compile under lcc-win32, converting long double to qfloat and
changing a few math functions to the idiosyncratic qfloat versions, I
get plenty of digits in my output, but everything is wrong after about
the 16th digit. Similar code using the Pascal extended type compiles
under the ancient Delphi 2.0 and offers 18 digits, within 1ULP, without
resorting to any floating type extensions that are idiosyncratic to the
compiler.

What is the point of offering a 100 digit floating point type if the 85
of those digits are meaningless?

Someone told me in this thread you get what you pay for. I would add to
that bit of wisdom that if something seems too good to be true, it
probably is.

Les

[Tom St Denis]

lcw1964 wrote:

What is the point of offering a 100 digit floating point type if the 85
of those digits are meaningless?

Someone told me in this thread you get what you pay for. I would add to
that bit of wisdom that if something seems too good to be true, it
probably is.

Well don't discount the possibility your code is incorrect and just
happened to work with an older non-standard conforming compiler.

In general though if you need huge precision [e.g. 80 bits] you
should just look into using a bignum library and wrap your own floating
point logic around it. For instance, my LibTomFloat is a very quick
[and hardly tested] attempt at this around my free LibTomMath. Both
libs are public domain and written in portable C. Obviously if you
have some commercial need for this you may want to invest some time in
thoroughly testing/improving the implementation.

If you know the range of your values you could more easily just use a
fixed point representation. e.g. if you know your values are in the
range -7 ... 7 you only need 3 bits for the integer. So if you used a
128-bit bignum you'd have 125 bits of fraction. etc...

Tom

[lcw1964]

Tom St Denis wrote:

>
Well don't discount the possibility your code is incorrect and just
happened to work with an older non-standard conforming compiler.

I am duly humbled and I may have spoken prematurely. I have tested out
some of Mr. Navia's built-in math functions, compared the results to
Maple, and they do seem to render very impressive results. (As a matter
of fact, I am so impressed I would love to see the source code to try
to learn where I have gone astray.)

I will go back to the drawing board and keep an open mind to see if if
any of the constants are functions I am using are not producing interim
results to the qfloat level. Garbage in garbage out, eh?

I must admit that it is hard to get used to nonstandard libraries and
functions and I can appreciate the criticisms here around portability.

many thanks,

Les