Support for extended/quad precision floating point types?

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Support for extended/quad precision floating point types?

Francesc Altet
Hi,

Some of our users have asked us about the possibility to add support in
PyTables for extended/quad precision float types, i.e. a 96-bit and
128-bit floats respectively.

I've checked that HDF5 does seem to support 96-bit floats (through
H5T_NATIVE_LDOUBLE symbol), but not 128-bit ones (or at least, I
haven't seem the way). Are there any plans to implement quad precision
support in HDF5 anytime soon?

Thanks,

--
>0,0<   Francesc Altet ? ? http://www.carabos.com/
V   V   C?rabos Coop. V. ??Enjoy Data
 "-"

----------------------------------------------------------------------
This mailing list is for HDF software users discussion.
To subscribe to this list, send a message to hdf-forum-subscribe at hdfgroup.org.
To unsubscribe, send a message to hdf-forum-unsubscribe at hdfgroup.org.




Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Support for extended/quad precision floating point types?

Francesc Altet
A Wednesday 19 December 2007, Francesc Altet escrigu?:

> Hi,
>
> Some of our users have asked us about the possibility to add support
> in PyTables for extended/quad precision float types, i.e. a 96-bit
> and 128-bit floats respectively.
>
> I've checked that HDF5 does seem to support 96-bit floats (through
> H5T_NATIVE_LDOUBLE symbol), but not 128-bit ones (or at least, I
> haven't seem the way). Are there any plans to implement quad
> precision support in HDF5 anytime soon?

Ops, some investigation says that H5T_NATIVE_LDOUBLE gives extents of
96-bit in 32-bit platforms and 128-bit in 64-bit ones (at least, in
those that I've tested, an Intel Pentium4 and AMD Opteron).  So, I
guess that, in order to map H5T_NATIVE_LDOUBLE to either a 96-bit o
128-bit floats, I should first query the length of it in the platform.  
Of course, this kind of floats will not be portable between
platforms :-/

Cheers,

--
>0,0<   Francesc Altet ? ? http://www.carabos.com/
V   V   C?rabos Coop. V. ??Enjoy Data
 "-"

----------------------------------------------------------------------
This mailing list is for HDF software users discussion.
To subscribe to this list, send a message to hdf-forum-subscribe at hdfgroup.org.
To unsubscribe, send a message to hdf-forum-unsubscribe at hdfgroup.org.




Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Support for extended/quad precision floating point types?

Quincey Koziol
Hi Francesc,

On Dec 19, 2007, at 9:08 AM, Francesc Altet wrote:

> A Wednesday 19 December 2007, Francesc Altet escrigu?:
>> Hi,
>>
>> Some of our users have asked us about the possibility to add support
>> in PyTables for extended/quad precision float types, i.e. a 96-bit
>> and 128-bit floats respectively.
>>
>> I've checked that HDF5 does seem to support 96-bit floats (through
>> H5T_NATIVE_LDOUBLE symbol), but not 128-bit ones (or at least, I
>> haven't seem the way). Are there any plans to implement quad
>> precision support in HDF5 anytime soon?
>
> Ops, some investigation says that H5T_NATIVE_LDOUBLE gives extents of
> 96-bit in 32-bit platforms and 128-bit in 64-bit ones (at least, in
> those that I've tested, an Intel Pentium4 and AMD Opteron).  So, I
> guess that, in order to map H5T_NATIVE_LDOUBLE to either a 96-bit o
> 128-bit floats, I should first query the length of it in the platform.
> Of course, this kind of floats will not be portable between
> platforms :-/

        You can also define your own floating-point number format with the  
H5Tset_fields() API routine.  Datatype conversions are slower when  
this is done, but they will operate correctly.

        Quincey

> Cheers,
>
> --
>> 0,0<   Francesc Altet     http://www.carabos.com/
> V   V   C?rabos Coop. V.   Enjoy Data
>  "-"
>
> ----------------------------------------------------------------------
> This mailing list is for HDF software users discussion.
> To subscribe to this list, send a message to hdf-forum-
> subscribe at hdfgroup.org.
> To unsubscribe, send a message to hdf-forum-unsubscribe at hdfgroup.org.
>
>


----------------------------------------------------------------------
This mailing list is for HDF software users discussion.
To subscribe to this list, send a message to hdf-forum-subscribe at hdfgroup.org.
To unsubscribe, send a message to hdf-forum-unsubscribe at hdfgroup.org.




Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Support for extended/quad precision floating point types?

Francesc Altet
A Thursday 20 December 2007, Quincey Koziol escrigu?:

> Hi Francesc,
>
> On Dec 19, 2007, at 9:08 AM, Francesc Altet wrote:
> > A Wednesday 19 December 2007, Francesc Altet escrigu?:
> >> Hi,
> >>
> >> Some of our users have asked us about the possibility to add
> >> support in PyTables for extended/quad precision float types, i.e.
> >> a 96-bit and 128-bit floats respectively.
> >>
> >> I've checked that HDF5 does seem to support 96-bit floats (through
> >> H5T_NATIVE_LDOUBLE symbol), but not 128-bit ones (or at least, I
> >> haven't seem the way). Are there any plans to implement quad
> >> precision support in HDF5 anytime soon?
> >
> > Ops, some investigation says that H5T_NATIVE_LDOUBLE gives extents
> > of 96-bit in 32-bit platforms and 128-bit in 64-bit ones (at least,
> > in those that I've tested, an Intel Pentium4 and AMD Opteron).  So,
> > I guess that, in order to map H5T_NATIVE_LDOUBLE to either a 96-bit
> > o 128-bit floats, I should first query the length of it in the
> > platform. Of course, this kind of floats will not be portable
> > between platforms :-/
>
> You can also define your own floating-point number format with the
> H5Tset_fields() API routine.  Datatype conversions are slower when
> this is done, but they will operate correctly.

Very interesting.  I wasn't aware that HDF5 had this level of
flexibility to declare user-defined floats.  However, it's still open
the issue of which C-type container would be able to keep 128-bit
floats in 32-bit machines, which only have 96-bit floats, but one can
always trim the precision and warn the user about that.

Does HDF5 support the automatic conversion from/to user-defined floats
to/from native floating point for the machine, or one should implement
this support by hand?

Thanks!

--
>0,0<   Francesc Altet ? ? http://www.carabos.com/
V   V   C?rabos Coop. V. ??Enjoy Data
 "-"

----------------------------------------------------------------------
This mailing list is for HDF software users discussion.
To subscribe to this list, send a message to hdf-forum-subscribe at hdfgroup.org.
To unsubscribe, send a message to hdf-forum-unsubscribe at hdfgroup.org.




Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Support for extended/quad precision floating point types?

Quincey Koziol
Hi Francesc,

On Dec 20, 2007, at 10:03 AM, Francesc Altet wrote:

> A Thursday 20 December 2007, Quincey Koziol escrigu?:
>> Hi Francesc,
>>
>> On Dec 19, 2007, at 9:08 AM, Francesc Altet wrote:
>>> A Wednesday 19 December 2007, Francesc Altet escrigu?:
>>>> Hi,
>>>>
>>>> Some of our users have asked us about the possibility to add
>>>> support in PyTables for extended/quad precision float types, i.e.
>>>> a 96-bit and 128-bit floats respectively.
>>>>
>>>> I've checked that HDF5 does seem to support 96-bit floats (through
>>>> H5T_NATIVE_LDOUBLE symbol), but not 128-bit ones (or at least, I
>>>> haven't seem the way). Are there any plans to implement quad
>>>> precision support in HDF5 anytime soon?
>>>
>>> Ops, some investigation says that H5T_NATIVE_LDOUBLE gives extents
>>> of 96-bit in 32-bit platforms and 128-bit in 64-bit ones (at least,
>>> in those that I've tested, an Intel Pentium4 and AMD Opteron).  So,
>>> I guess that, in order to map H5T_NATIVE_LDOUBLE to either a 96-bit
>>> o 128-bit floats, I should first query the length of it in the
>>> platform. Of course, this kind of floats will not be portable
>>> between platforms :-/
>>
>> You can also define your own floating-point number format with the
>> H5Tset_fields() API routine.  Datatype conversions are slower when
>> this is done, but they will operate correctly.
>
> Very interesting.  I wasn't aware that HDF5 had this level of
> flexibility to declare user-defined floats.  However, it's still open
> the issue of which C-type container would be able to keep 128-bit
> floats in 32-bit machines, which only have 96-bit floats, but one can
> always trim the precision and warn the user about that.
>
> Does HDF5 support the automatic conversion from/to user-defined floats
> to/from native floating point for the machine, or one should implement
> this support by hand?

        HDF5's datatype conversions will automatically convert between any  
two floating-point formats.  It's a _lot_ more efficient for the  
predefined ones though... :-)

        Quincey


> Thanks!
>
> --
>> 0,0<   Francesc Altet     http://www.carabos.com/
> V   V   C?rabos Coop. V.   Enjoy Data
>  "-"
>
> ----------------------------------------------------------------------
> This mailing list is for HDF software users discussion.
> To subscribe to this list, send a message to hdf-forum-
> subscribe at hdfgroup.org.
> To unsubscribe, send a message to hdf-forum-unsubscribe at hdfgroup.org.
>
>


----------------------------------------------------------------------
This mailing list is for HDF software users discussion.
To subscribe to this list, send a message to hdf-forum-subscribe at hdfgroup.org.
To unsubscribe, send a message to hdf-forum-unsubscribe at hdfgroup.org.




Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Support for extended/quad precision floating point types?

Francesc Altet
Hi Quincey,

A Thursday 20 December 2007, escrigu?reu:

> Hi Francesc,
>
> On Dec 20, 2007, at 10:03 AM, Francesc Altet wrote:
> > A Thursday 20 December 2007, Quincey Koziol escrigu?:
> >> Hi Francesc,
> >>
> >> On Dec 19, 2007, at 9:08 AM, Francesc Altet wrote:
> >>> A Wednesday 19 December 2007, Francesc Altet escrigu?:
> >>>> Hi,
> >>>>
> >>>> Some of our users have asked us about the possibility to add
> >>>> support in PyTables for extended/quad precision float types,
> >>>> i.e. a 96-bit and 128-bit floats respectively.
> >>>>
> >>>> I've checked that HDF5 does seem to support 96-bit floats
> >>>> (through H5T_NATIVE_LDOUBLE symbol), but not 128-bit ones (or at
> >>>> least, I haven't seem the way). Are there any plans to implement
> >>>> quad precision support in HDF5 anytime soon?
> >>>
> >>> Ops, some investigation says that H5T_NATIVE_LDOUBLE gives
> >>> extents of 96-bit in 32-bit platforms and 128-bit in 64-bit ones
> >>> (at least, in those that I've tested, an Intel Pentium4 and AMD
> >>> Opteron).  So, I guess that, in order to map H5T_NATIVE_LDOUBLE
> >>> to either a 96-bit o 128-bit floats, I should first query the
> >>> length of it in the platform. Of course, this kind of floats will
> >>> not be portable between platforms :-/
> >>
> >> You can also define your own floating-point number format with
> >> the H5Tset_fields() API routine.  Datatype conversions are slower
> >> when this is done, but they will operate correctly.
> >
> > Very interesting.  I wasn't aware that HDF5 had this level of
> > flexibility to declare user-defined floats.  However, it's still
> > open the issue of which C-type container would be able to keep
> > 128-bit floats in 32-bit machines, which only have 96-bit floats,
> > but one can always trim the precision and warn the user about that.
> >
> > Does HDF5 support the automatic conversion from/to user-defined
> > floats to/from native floating point for the machine, or one should
> > implement this support by hand?
>
> HDF5's datatype conversions will automatically convert between any
> two floating-point formats.  It's a _lot_ more efficient for the
> predefined ones though... :-)

Oh, despite of the slowness, that's excellent news!

--
>0,0<   Francesc Altet ? ? http://www.carabos.com/
V   V   C?rabos Coop. V. ??Enjoy Data
 "-"

----------------------------------------------------------------------
This mailing list is for HDF software users discussion.
To subscribe to this list, send a message to hdf-forum-subscribe at hdfgroup.org.
To unsubscribe, send a message to hdf-forum-unsubscribe at hdfgroup.org.




Loading...