Lies of Billy Gates of Microcrap

**Malcolm McLean** · Jun 28 '08, 06:25 PM

Re: Lies of Billy Gates of Microcrap

"long double" <long-double@long-double.com.inva lidwrote in message news:

>
Can someone please translate this MS lie language into
ordinary logical English language.
I need a "long double" data type that is capable to hold
bigger numbers than the normal "double" type can hold.
Has MS' crappy compiler VC6 implemented this data type or not?
What is your understanding from the citations below from the MS'
documentation', and/or your own practical experience regarding this?
>

Why do you need numbers larger than

1.798e+308 ?

What are you measuring?

--
Free games and programming goodies.

http://www.personal.leeds.ac.uk/~bgy1mm

**CBFalconer** · Jun 28 '08, 06:35 PM

Re: Lies of Billy Gates of Microcrap

long double wrote:

>

.... snip ...

Has MS' crappy compiler VC6 implemented this data type or not?
What is your understanding from the citations below from the MS'
'documentation' , and/or your own practical experience regarding
this?
>
"Type long double
The long double contains 80 bits: 1 for sign, 15 for exponent,
and 64 for mantissa. Its range is +/-1.2E4932 with at least 19
digits of precision.

.... snip ...

>
"Table 3.2 Sizes of Fundamental Types
...
float 4 bytes
double 8 bytes
long double 8 bytes"

Obviously MS VC6 is intended to run on machines with CHAR_BIT ==
80. What's the problem? :-)

Cross-post to c.l.c++ suppressed on follow-ups.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home .att.net>
Try the download section.

**Tim Prince** · Jun 28 '08, 06:45 PM

Re: Lies of Billy Gates of Microcrap

long double wrote:

"double
Type double is a floating type that is larger than or equal to type float,
but shorter than or equal to the size of type long double [-->1]
>
long double [-->1]
Type long double is a floating type that is equal to type double.
>
[1] The representation of long double and double is identical.
However, long double and double are separate types."
>
"Table 3.2 Sizes of Fundamental Types
...
float 4 bytes
double 8 bytes
long double 8 bytes"
>

Microsoft chose the option (permitted by standard) to make double the same
as long double. Other compilers which rely on Microsoft library support
(Intel ICL /Qlongdouble, or mingw gcc) implement the larger range long
double to a limited extent, but don't have library support for long
double. cygwin gcc is in an intermediate position, as newlib has partial
support for long double. So these versions of wider long double fall
short of standard compliance.
You might argue that a reason for the standard permitting long double to
be implemented as double is inadequate hardware support for wider data
types on some platforms. Compilers for Intel and AMD platforms
increasingly make SSE code their primary supported mode, due in large part
to the potential performance advantage.

**Walter Bright** · Jun 28 '08, 06:45 PM

Re: Lies of Billy Gates of Microcrap

Tim Prince wrote:

Microsoft chose the option (permitted by standard) to make double the
same as long double. Other compilers which rely on Microsoft library
support (Intel ICL /Qlongdouble, or mingw gcc) implement the larger
range long double to a limited extent, but don't have library support
for long double. cygwin gcc is in an intermediate position, as newlib
has partial support for long double. So these versions of wider long
double fall short of standard compliance.

Digital Mars C and C++ implements 80 bit long doubles with full library
support.

---
Walter Bright
Digital Mars

Digital Mars C, C++ and D Compilers

http://www.digitalmars.com

Digital Mars C, C++ and D Compilers for Win32, Win16, DOS32 and DOS

C, C++, D programming language compilers

**Walter Bright** · Jun 28 '08, 06:55 PM

Re: Lies of Billy Gates of Microcrap

Malcolm McLean wrote:

Why do you need numbers larger than
1.798e+308 ?
What are you measuring?

More bits of precision is useful to prevent (or at least stave off)
creeping errors from doing things like inverting large matrices or doing
finite element sums.

More exponent range is not for measuring things, but to prevent (or at
least stave off) overflows from intermediate calculations.

---
Walter Bright
Digital Mars

Digital Mars C, C++ and D Compilers

http://www.digitalmars.com

Digital Mars C, C++ and D Compilers for Win32, Win16, DOS32 and DOS

C, C++, D programming language compilers

**Malcolm McLean** · Jun 28 '08, 06:55 PM

Re: Lies of Billy Gates of Microcrap

"Walter Bright" <walter@digital mars-nospamm.comwrot e in message news

Malcolm McLean wrote:

>Why do you need numbers larger than
>1.798e+308 ?
>What are you measuring?

>
More bits of precision is useful to prevent (or at least stave off)
creeping errors from doing things like inverting large matrices or doing
finite element sums.
>

I know. As you say, its only a partial solution. For everyday programming,
the secret is to arrange calculations so that a bit of error can be
tolerated. For instance in games we recalculate all points from the original
mesh values on each frame, we don't iteratively transform them.

--
Free games and programming goodies.

http://www.personal.leeds.ac.uk/~bgy1mm

**Walter Bright** · Jun 28 '08, 07:35 PM

Re: Lies of Billy Gates of Microcrap

Malcolm McLean wrote:

>
"Walter Bright" <walter@digital mars-nospamm.comwrot e in message news

>More bits of precision is useful to prevent (or at least stave off)
>creeping errors from doing things like inverting large matrices or
>doing finite element sums.
>>

I know. As you say, its only a partial solution. For everyday
programming, the secret is to arrange calculations so that a bit of
error can be tolerated. For instance in games we recalculate all points
from the original mesh values on each frame, we don't iteratively
transform them.

Sure, but, for example, algorithms for matrix inversion that correct for
cumulative roundoff error are far more complex and time consuming.

In general, careful fp coding to avoid intermediate overflows and
roundoff error accumulation are not your average coding skills. Take a
look at Cody & Waite's manual, for example.

---
Walter Bright
Digital Mars

Digital Mars C, C++ and D Compilers

http://www.digitalmars.com

Digital Mars C, C++ and D Compilers for Win32, Win16, DOS32 and DOS

C, C++, D programming language compilers

**Tim Prince** · Jun 29 '08, 12:05 AM

Re: Lies of Billy Gates of Microcrap

Walter Bright wrote:

Malcolm McLean wrote:

>>
>"Walter Bright" <walter@digital mars-nospamm.comwrot e in message news

>>More bits of precision is useful to prevent (or at least stave off)
>>creeping errors from doing things like inverting large matrices or
>>doing finite element sums.
>>>

>I know. As you say, its only a partial solution. For everyday
>programming, the secret is to arrange calculations so that a bit of
>error can be tolerated. For instance in games we recalculate all
>points from the original mesh values on each frame, we don't
>iteratively transform them.

>
Sure, but, for example, algorithms for matrix inversion that correct for
cumulative roundoff error are far more complex and time consuming.
>
In general, careful fp coding to avoid intermediate overflows and
roundoff error accumulation are not your average coding skills. Take a
look at Cody & Waite's manual, for example.
>

If you read the help archives for compilers, you see plenty of people
below the skill level needed to deal with extra precision or any use of
long double.

**viza** · Jun 29 '08, 02:25 AM

Re: Lies of Billy Gates of Microcrap

On Sat, 28 Jun 2008 12:34:04 -0700, Walter Bright wrote:

Malcolm McLean wrote:

>>

Sure, but, for example, algorithms for matrix inversion that correct for
cumulative roundoff error are far more complex and time consuming.
>
In general, careful fp coding to avoid intermediate overflows and
roundoff error accumulation are not your average coding skills. Take a
look at Cody & Waite's manual, for example.

or

Amazon.com

http://www.amazon.com

/Accuracy-Stability-Numerical-Algorithms-Nicholas/dp/0898715210

**Rolf Magnus** · Jun 29 '08, 10:25 AM

Re: Lies of Billy Gates of Microcrap

CBFalconer wrote:

long double wrote:

>>

... snip ...

>Has MS' crappy compiler VC6 implemented this data type or not?
>What is your understanding from the citations below from the MS'
>'documentation ', and/or your own practical experience regarding
>this?
>>
>"Type long double
>The long double contains 80 bits: 1 for sign, 15 for exponent,
>and 64 for mantissa. Its range is +/-1.2E4932 with at least 19
>digits of precision.

... snip ...

>>
>"Table 3.2 Sizes of Fundamental Types
> ...
> float 4 bytes
> double 8 bytes
> long double 8 bytes"

>
Obviously MS VC6 is intended to run on machines with CHAR_BIT ==
80. What's the problem? :-)

I guess you mean CHAR_BIT == 10?

Cross-post to c.l.c++ suppressed on follow-ups.

Why? It's just as relevant to C++ as it is to C.

**pete** · Jun 29 '08, 03:25 PM

Re: Lies of Billy Gates of Microcrap

long double wrote:

[1] The representation of long double and double is identical.
However, long double and double are separate types."

char, unsigned char, signed char,
are three separate types.

char has identical representation
to one of the other two.

Which one of the other two, is implementation defined.

--
pete

**Adem24** · Jun 29 '08, 05:15 PM

Re: Lies of Billy Gates of Microcrap

"Type long double

The long double contains 80 bits: 1 for sign, 15 for exponent,
and 64 for mantissa. Its range is +/-1.2E4932 with at least 19 digits of precision.

//--------------------------------------------------------------
// Demonstrates the use of "long double" (80-bit) on the
// GNU gcc compiler (here using Cygwin for the Windows platform)
//
// See the docs and FAQs of the Windows ports Cygwin or MinGW
// on howto create a static or dynamic library that you can
// link with other compilers.
//
// GCC, the GNU Compiler Collection homepage:
// http://gcc.gnu.org/index.html
//
//--------------------------------------------------------------
#include <stdio.h>
#include <stdlib.h>
#include <float.h>

int long_double_tes t()
{
long double ld = 1.2e4931L;

printf("ld=%Lf\ n", ld);

return 0;
}

int main(int argc, char* argv[])
{
return long_double_tes t();
}

/*
Output:
(a very very long number (here manually wrapped into several lines):

ld=119999999999 999999999109887 086629743819001 000000000000000 000000000000000 0000000000
000000000000000 000000000000000 000000000000000 000000000000000 000000000000000 0000000000
000000000000000 000000000000000 000000000000000 000000000000000 000000000000000 0000000000
000000000000000 000000000000000 000000000000000 000000000000000 000000000000000 0000000000
000000000000000 000000000000000 000000000000000 000000000000000 000000000000000 0000000000
000000000000000 000000000000000 000000000000000 000000000000000 000000000000000 0000000000
000000000000000 000000000000000 000000000000000 000000000000000 000000000000000 0000000000
000000000000000 000000000000000 000000000000000 000000000000000 000000000000000 0000000000
000000000000000 000000000000000 000000000000000 000000000000000 000000000000000 0000000000
000000000000000 000000000000000 000000000000000 000000000000000 000000000000000 0000000000
000000000000000 000000000000000 000000000000000 000000000000000 000000000000000 0000000000
000000000000000 000000000000000 000000000000000 000000000000000 000000000000000 0000000000
000000000000000 000000000000000 000000000000000 000000000000000 000000000000000 0000000000
000000000000000 000000000000000 000000000000000 000000000000000 000000000000000 0000000000
000000000000000 000000000000000 000000000000000 000000000000000 000000000000000 0000000000
000000000000000 000000000000000 000000000000000 000000000000000 000000000000000 0000000000
000000000000000 000000000000000 000000000000000 000000000000000 000000000000000 0000000000
000000000000000 000000000000000 000000000000000 000000000000000 000000000000000 0000000000
000000000000000 000000000000000 000000000000000 000000000000000 000000000000000 0000000000
000000000000000 000000000000000 000000000000000 000000000000000 000000000000000 0000000000
000000000000000 000000000000000 000000000000000 000000000000000 000000000000000 0000000000
000000000000000 000000000000000 000000000000000 000000000000000 000000000000000 0000000000
000000000000000 000000000000000 000000000000000 000000000000000 000000000000000 0000000000
000000000000000 000000000000000 000000000000000 000000000000000 000000000000000 0000000000
000000000000000 000000000000000 000000000000000 000000000000000 000000000000000 0000000000
000000000000000 000000000000000 000000000000000 000000000000000 000000000000000 0000000000
000000000000000 000000000000000 000000000000000 000000000000000 000000000000000 0000000000
000000000000000 000000000000000 000000000000000 000000000000000 000000000000000 0000000000
000000000000000 000000000000000 000000000000000 000000000000000 000000000000000 0000000000
000000000000000 000000000000000 000000000000000 000000000000000 000000000000000 0000000000
000000000000000 000000000000000 000000000000000 000000000000000 000000000000000 0000000000
000000000000000 000000000000000 000000000000000 000000000000000 000000000000000 0000000000
000000000000000 000000000000000 000000000000000 000000000000000 000000000000000 0000000000
000000000000000 000000000000000 000000000000000 000000000000000 000000000000000 0000000000
000000000000000 000000000000000 000000000000000 000000000000000 000000000000000 0000000000
000000000000000 000000000000000 000000000000000 000000000000000 000000000000000 0000000000
000000000000000 000000000000000 000000000000000 000000000000000 000000000000000 0000000000
000000000000000 000000000000000 000000000000000 000000000000000 000000000000000 0000000000
000000000000000 000000000000000 000000000000000 000000000000000 000000000000000 0000000000
000000000000000 000000000000000 000000000000000 000000000000000 000000000000000 0000000000
000000000000000 000000000000000 000000000000000 000000000000000 000000000000000 0000000000
000000000000000 000000000000000 000000000000000 000000000000000 000000000000000 0000000000
000000000000000 000000000000000 000000000000000 000000000000000 000000000000000 0000000000
000000000000000 000000000000000 000000000000000 000000000000000 000000000000000 0000000000
000000000000000 000000000000000 000000000000000 000000000000000 000000000000000 0000000000
000000000000000 000000000000000 000000000000000 000000000000000 000000000000000 0000000000
000000000000000 000000000000000 000000000000000 000000000000000 000000000000000 0000000000
000000000000000 000000000000000 000000000000000 000000000000000 000000000000000 0000000000
000000000000000 000000000000000 000000000000000 000000000000000 000000000000000 0000000000
000000000000000 000000000000000 000000000000000 000000000000000 000000000000000 0000000000
000000000000000 000000000000000 000000000000000 000000000000000 000000000000000 0000000000
000000000000000 000000000000000 000000000000000 000000000000000 000000000000000 0000000000
000000000000000 000000000000000 000000000000000 000000000000000 000000000000000 0000000000
000000000000000 000000000000000 000000000000000 000000000000000 000000000000000 0000000000
000000000000000 000000000000000 000000000000000 000000000000000 000000000000000 0000000000
000000000000000 000000000000000 000000000000000 000000000000000 000000000000000 0000000000
000000000000000 000000000000000 000000000000000 000000000000000 000000000000000 0000000000
000000000000000 000000000000000 000000000000000 000000000000000 000000000000000 000000000000000 .000000

*/

**Gernot Frisch** · Jun 30 '08, 07:45 AM

Re: Lies of Billy Gates of Microcrap

More bits of precision is useful to prevent (or at least stave off)
creeping errors from doing things like inverting large matrices or doing
finite element sums.
>
More exponent range is not for measuring things, but to prevent (or at
least stave off) overflows from intermediate calculations.

It's neccessary sometimes, I agree. But you should try to keep your code
able to cross compile with 64bit double, too.
It's mostly a problem of bad design/coding and bigger accuracy won't make
things "good", just "better".

--
------------------------------------
Gernot Frisch

GLBasic - multiplatform development in BASIC

http://www.glbasic.com

GLBasic is a programming language that supports multiple platforms like e.g. iPhone

Lies of Billy Gates of Microcrap

Lies of Billy Gates of Microcrap

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment