[Numpy-discussion] supporting quad precision
Sat Jun 8 07:35:27 CDT 2013
Looking at the rational module, I think you're right: it really shouldn't
be too hard to get quads working as a user type using gcc's __float128
type, which will provide hardware arithmetic in the unlikely case that the
user has hardware quads. Alternatively, probably more work, one could use a
package like qd to provide portable quad precision (and quad-double).
I'll take a look.
On Jun 5, 2013 7:10 PM, "David Cournapeau" <firstname.lastname@example.org> wrote:
> On Wed, Jun 5, 2013 at 5:21 PM, Charles R Harris
> <email@example.com> wrote:
> > Hi Anne,
> > Long time no see ;)
> > On Wed, Jun 5, 2013 at 10:07 AM, Anne Archibald <firstname.lastname@example.org>
> >> Hi folks,
> >> I recently came across an application I needed quad precision for
> >> (high-accuracy solution of a differential equation). I found a C++
> >> (odeint) that worked for the integration itself, but unfortunately it
> >> appears numpy is not able to work with quad precision arrays. For my
> >> application the quad precision is only really needed for integrator
> >> so I can manually convert my data to long doubles as I go to and from
> >> but it's a pain. So quad precision support would be nice.
> >> There's a thread discussing quad support:
> >> Essentially, there isn't any, but since gcc >= 4.6 supports them on
> >> hardware (in software), it should be possible. (Then the thread got
> >> down in bike-shedding about what to call them.)
> >> What would it take to support quads in numpy? I looked into the numpy
> >> dtype definitions, and it's a complex arrangement involving detection of
> >> platform support and templatized C code; in the end I couldn't really
> >> where to start. But it seems to me all the basics are available: native
> >> syntax for basic arithmetic, "qabs"-style versions of all the basic
> >> functions, NaNs and Infs. So how would one go about adding quad support?
> > There are some improvements for user types committed in 1.8-dev. Perhaps
> > quad support could be added as a user type as it is still
> > dependent. The rational type added to numpy could supply a template for
> > adding the new type.
> I would be in support of that direction as well: let it live
> separately until CPU/compiler support is coming up.
> Anne, will you be at scipy conference ? Improving user data type
> internal API is something I'd like to work on as well
> NumPy-Discussion mailing list
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the NumPy-Discussion