Re: long double data type
Re: long double data type
- Subject: Re: long double data type
- From: Luigi Castelli <email@hidden>
- Date: Tue, 15 Jun 2010 14:42:47 -0700 (PDT)
> The fact that long double is 80 bits is an implementation
> detail, not a predefined type. On PowerPC, long double
> = double unless you force it to be bigger in which case it
> is emulated in software with 2 doubles (simplistic
> statement!).
Exactly. On my system, the size of a long double is 128 bits (16 bytes), not 80 bits. Why would it not be IEEE compliant?
> They are not IEEE-compliant b/c there is no 80-bit compliance
> definition. Single and double precision floats are compliant, long
> doubles are not.
But if I understand correctly, compliance is dictated by the implementation of the data type. So it is not correct to say in absolute terms that long doubles are not compliant. We have to see how they are implemented. The same would go for floats and doubles, I assume...
Am I making sense?
- Luigi
--- On Tue, 6/15/10, Stephen Davis <email@hidden> wrote:
> From: Stephen Davis <email@hidden>
> Subject: Re: long double data type
> To: "Luigi Castelli" <email@hidden>
> Cc: email@hidden
> Date: Tuesday, June 15, 2010, 2:23 PM
> On Jun 15, 2010, at 2:13 PM, Luigi
> Castelli wrote:
>
> > Thank you for your replies Ian and Stephen.
> > This is exactly what I am after...
> >
> >> "On Intel macs, the type long double corresponds
> to IEEE-754 double
> >> extended precision. A double extended number
> is represented in 80 bits,
> >> and has a precision of 64 significant bits,
> roughly like 19 significant
> >> decimal digits. 15 bits are used to encode
> the exponent, which gives an
> >> exponent range from -16383 to 16384, inclusive."
> >
> > Yes, that's what I learnt too, however I have also
> come across information similar to what Ian mentioned.
> >
> >> There are no 80 bit floating point data types.
> >
> > However from what "man float" says, the long double
> data type defines exactly an 80 bit type.
> >
> > The two pieces of information seem to contradict each
> other.
>
> The fact that long double is 80 bits is an implementation
> detail, not a predefined type. On PowerPC, long double
> = double unless you force it to be bigger in which case it
> is emulated in software with 2 doubles (simplistic
> statement!).
>
> > I am trying to avoid software emulation for bigger
> types, if I can get away with native types.
> >
> > To summarize: if it is true that computations can be
> performed natively with a maximum accuracy of 80 bits (64
> bit effective resolution),
> >
> > AND
> >
> > it is all IEE compliant because computations are
> performed in the SSE unit, I will go for it.
>
> They are not IEEE-compliant b/c there is no 80-bit
> compliance definition. Single and double precision
> floats are compliant, long doubles are not.
>
> stephen
>
> > However I am still not sure that's the case...
> >
> > - Luigi
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > --- On Tue, 6/15/10, Stephen Davis <email@hidden>
> wrote:
> >
> >> From: Stephen Davis <email@hidden>
> >> Subject: Re: long double data type
> >> To: "Luigi Castelli" <email@hidden>
> >> Cc: email@hidden
> >> Date: Tuesday, June 15, 2010, 1:15 PM
> >> On Jun 15, 2010, at 10:44 AM, Luigi
> >> Castelli wrote:
> >>
> >>> Hi there,
> >>>
> >>> this is the second time that I get a similar
> >> response:
> >>>
> >>>> Are you sure that your DSP approach is
> sound?
> >>>>
> >>>> If 64bits are not enough there is
> probably
> >> something wrong
> >>>> with your algorithm.
> >>>
> >>> I really don't want to sound arrogant because
> it is
> >> not what I am about, however I ASSURE you that I
> performed
> >> all the necessary tests, both mathematical and
> auditive to
> >> corroborate my conclusion. My approach is sound, I
> just
> >> don't have enough bits for the audio quality I am
> after. I
> >> understand it might sound weird to hear that 64
> bits are not
> >> enough.
> >>> I might have reached the upper limit of the
> current
> >> technology, but doubting my approach is not
> helping. I would
> >> ask advice on the approach if I wasn't sure it was
> the right
> >> one.
> >>>
> >>> I would love to get back on track with the
> questions I
> >> have asked.
> >>> I apologize in advance if I offended somebody.
> It was
> >> not my intention.
> >>>
> >>> Thank you for your understanding.
> >>>
> >>> - Luigi
> >>
> >> Tahome, personally I found your comment a bit rude
> and a
> >> non-answer to the original question. To
> paraphrase the
> >> old adage, "If you don't have anything useful to
> add, don't
> >> say anything." Let's keep the responses in
> the helpful
> >> category, not in the flame-bait category.
> >>
> >> From "man float":
> >>
> >> "On Intel macs, the type long double corresponds
> to
> >> IEEE-754 double extended precision. A double
> extended
> >> number is represented in 80 bits, and has a
> precision of 64
> >> significant bits, roughly like 19 significant
> decimal
> >> digits. 15 bits are used to encode the
> exponent, which
> >> gives an exponent range from -16383 to 16384,
> inclusive."
> >>
> >> This is a direct mapping to the x86 (technically
> x87) FPU
> >> hardware which has always been 80 bits. Note
> that, on
> >> Mac OS X (intel) systems, single and double
> precision
> >> floating point math is normally executed in the
> SSE unit,
> >> not the x87 FPU.
> >>
> >> hth,
> >> stephen
> >>
> >>>
> >>>
> >>> --- On Tue, 6/15/10, tahome izwah <email@hidden>
> >> wrote:
> >>>
> >>>> From: tahome izwah <email@hidden>
> >>>> Subject: Re: long double data type
> >>>> To: email@hidden
> >>>> Date: Tuesday, June 15, 2010, 8:33 AM
> >>>> I know that I am not really
> >>>> contributing, but...
> >>>>
> >>>>> (Yes, I did my tests and 64 bits of
> precision
> >> just
> >>>> doesn't cut it)
> >>>>
> >>>> Are you sure that your DSP approach is
> sound?
> >>>>
> >>>> If 64bits are not enough there is
> probably
> >> something wrong
> >>>> with your algorithm.
> >>>>
> >>>> Just my 2 centibits
> >>>> --th
> >>>>
> _______________________________________________
> >>>> Do not post admin requests to the list.
> They will
> >> be
> >>>> ignored.
> >>>> Coreaudio-api mailing list
> (email@hidden)
> >>>> Help/Unsubscribe/Update your
> Subscription:
> >>>>
> >>>> This email sent to email@hidden
> >>>>
> >>>
> >>>
> >>>
> >>>
> _______________________________________________
> >>> Do not post admin requests to the list. They
> will be
> >> ignored.
> >>> Coreaudio-api mailing list
> (email@hidden)
> >>> Help/Unsubscribe/Update your Subscription:
> >>>
> >>> This email sent to email@hidden
> >>
> >>
> >
> >
> >
> > _______________________________________________
> > Do not post admin requests to the list. They will be
> ignored.
> > Coreaudio-api mailing list (email@hidden)
> > Help/Unsubscribe/Update your Subscription:
> >
> > This email sent to email@hidden
>
>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden