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. Anne On Jun 5, 2013 7:10 PM, "David Cournapeau" <cournape@gmail.com> wrote:
Hi Anne,
Long time no see ;)
On Wed, Jun 5, 2013 at 10:07 AM, Anne Archibald <archibald@astron.nl> wrote:
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 state, so I can manually convert my data to long doubles as I go to and from numpy, but it's a pain. So quad precision support would be nice.
There's a thread discussing quad support:
http://mail.scipy.org/pipermail/numpy-discussion/2012-February/061080.html
Essentially, there isn't any, but since gcc >= 4.6 supports them on Intel hardware (in software), it should be possible. (Then the thread got bogged 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 see where to start. But it seems to me all the basics are available: native C 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
On Wed, Jun 5, 2013 at 5:21 PM, Charles R Harris <charlesr.harris@gmail.com> wrote: library base platform/compiler
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
David _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion