On Wed, Jun 12, 2013 at 7:55 PM, Anne Archibald wrote:
> On 9 June 2013 13:23, David Cournapeau wrote:
>>
>> So it depends on the CPU, the OS and the compiler. Using long double
>> for anything else than compatibility (e.g. binary files) is often a
>> mistake IMO, and highly unportable.
>
>
> Now
On 9 June 2013 13:23, David Cournapeau wrote:
> So it depends on the CPU, the OS and the compiler. Using long double
> for anything else than compatibility (e.g. binary files) is often a
> mistake IMO, and highly unportable.
>
Now this I have to comment on. Long double is highly questionable for
On Mon, 2013-06-10 at 13:21 +0100, Robert Kern wrote:
> > With my work on https://github.com/hgomersall/pyFFTW, which supports
> > long double as one of the data types, numpy's long double is
> absolutely
> > the right way to do this. Certainly I've managed reasonable success
> > across the three m
On Mon, Jun 10, 2013 at 7:49 AM, Henry Gomersall wrote:
> On Sun, 2013-06-09 at 12:23 +0100, David Cournapeau wrote:
>> So it depends on the CPU, the OS and the compiler. Using long double
>> for anything else than compatibility (e.g. binary files) is often a
>> mistake IMO, and highly unportable
On Sun, 2013-06-09 at 12:23 +0100, David Cournapeau wrote:
> On Sun, Jun 9, 2013 at 8:35 AM, Henry Gomersall
> wrote:
> > On Sat, 2013-06-08 at 14:35 +0200, Anne Archibald wrote:
> >> Looking at the rational module, I think you're right: it really
> >> shouldn't be too hard to get quads working as
On Sun, Jun 9, 2013 at 8:35 AM, Henry Gomersall wrote:
> On Sat, 2013-06-08 at 14:35 +0200, Anne Archibald wrote:
>> 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 hardw
On Sat, 2013-06-08 at 14:35 +0200, Anne Archibald wrote:
> 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 hardw
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
pac
On Wed, Jun 5, 2013 at 5:21 PM, Charles R Harris
wrote:
> Hi Anne,
>
> Long time no see ;)
>
> On Wed, Jun 5, 2013 at 10:07 AM, Anne Archibald wrote:
>>
>> Hi folks,
>>
>> I recently came across an application I needed quad precision for
>> (high-accuracy solution of a differential equation). I f
Hi Anne,
Long time no see ;)
On Wed, Jun 5, 2013 at 10:07 AM, Anne Archibald 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++ library
> (odeint) that worked for the integration itself, b
Hi folks,
I recently came across an application I needed quad precision for
(high-accuracy solution of a differential equation). I found a C++ library
(odeint) that worked for the integration itself, but unfortunately it
appears numpy is not able to work with quad precision arrays. For my
applicat
11 matches
Mail list logo
