Le 24/02/2012 16:38, Robert Pyle a écrit :
>> I wonder what is the use case of these 80 bits numbers apart from what
>> > is described as "keeping intermediate results" when performing
>> > exponentiation on doubles ?
> In AIFF audio files, the sample rate is stored in the Common Chunk as an
> 80-
On Feb 24, 2012, at 7:43 AM, Pierre Haessig wrote:
> Hi,
> Le 24/02/2012 01:00, Matthew Brett a écrit :
>> Right - no proposal to change float64 because it's not ambiguous - it
>> is both binary64 IEEE floating point format and 64 bit width.
> All right ! Focusing the renaming only on those "exte
Hi,
Le 24/02/2012 01:00, Matthew Brett a écrit :
> Right - no proposal to change float64 because it's not ambiguous - it
> is both binary64 IEEE floating point format and 64 bit width.
All right ! Focusing the renaming only on those "extended precision"
float types makes sense.
> The confusion here
Hi,
On Thu, Feb 23, 2012 at 2:56 PM, Pierre Haessig
wrote:
> Le 23/02/2012 20:08, Mark Wiebe a écrit :
>> +1, I think it's good for its name to correspond to the name in C/C++,
>> so that when people search for information on it they will find the
>> relevant information more easily. With a bunch
Le 23/02/2012 20:08, Mark Wiebe a écrit :
> +1, I think it's good for its name to correspond to the name in C/C++,
> so that when people search for information on it they will find the
> relevant information more easily. With a bunch of NumPy-specific
> aliases, it just creates more hassle for ever
On Thu, Feb 23, 2012 at 10:55 AM, Matthew Brett wrote:
> Hi,
>
> On Thu, Feb 23, 2012 at 10:45 AM, Mark Wiebe wrote:
> > On Thu, Feb 23, 2012 at 10:42 AM, Matthew Brett >
> > wrote:
> >>
> >> Hi,
> >>
> >> On Thu, Feb 23, 2012 at 10:11 AM, Pierre Haessig
> >> wrote:
> >> > Le 23/02/2012 17:28,
Hi,
On Thu, Feb 23, 2012 at 10:45 AM, Mark Wiebe wrote:
> On Thu, Feb 23, 2012 at 10:42 AM, Matthew Brett
> wrote:
>>
>> Hi,
>>
>> On Thu, Feb 23, 2012 at 10:11 AM, Pierre Haessig
>> wrote:
>> > Le 23/02/2012 17:28, Charles R Harris a écrit :
>> >> That's correct. They are both extended precisi
On Thu, Feb 23, 2012 at 10:42 AM, Matthew Brett wrote:
> Hi,
>
> On Thu, Feb 23, 2012 at 10:11 AM, Pierre Haessig
> wrote:
> > Le 23/02/2012 17:28, Charles R Harris a écrit :
> >> That's correct. They are both extended precision (80 bits), but
> >> aligned on 32bit/64bit boundaries respectively.
Hi,
On Thu, Feb 23, 2012 at 10:11 AM, Pierre Haessig
wrote:
> Le 23/02/2012 17:28, Charles R Harris a écrit :
>> That's correct. They are both extended precision (80 bits), but
>> aligned on 32bit/64bit boundaries respectively. Sun provides a true
>> quad precision, also called float128, while on
Le 23/02/2012 17:28, Charles R Harris a écrit :
> That's correct. They are both extended precision (80 bits), but
> aligned on 32bit/64bit boundaries respectively. Sun provides a true
> quad precision, also called float128, while on PPC long double is an
> odd combination of two doubles.
This is in
On Feb 23, 2012, at 10:26 AM, Matthew Brett wrote:
> Hi,
>
> On Thu, Feb 23, 2012 at 4:23 AM, Francesc Alted wrote:
>> On Feb 23, 2012, at 6:06 AM, Francesc Alted wrote:
>>> On Feb 23, 2012, at 5:43 AM, Nathaniel Smith wrote:
>>>
On Thu, Feb 23, 2012 at 11:40 AM, Francesc Alted
wrot
On Thu, Feb 23, 2012 at 5:23 AM, Francesc Alted wrote:
> On Feb 23, 2012, at 6:06 AM, Francesc Alted wrote:
> > On Feb 23, 2012, at 5:43 AM, Nathaniel Smith wrote:
> >
> >> On Thu, Feb 23, 2012 at 11:40 AM, Francesc Alted
> wrote:
> >>> Exactly. I'd update this to read:
> >>>
> >>> float9696
Hi,
On Thu, Feb 23, 2012 at 4:23 AM, Francesc Alted wrote:
> On Feb 23, 2012, at 6:06 AM, Francesc Alted wrote:
>> On Feb 23, 2012, at 5:43 AM, Nathaniel Smith wrote:
>>
>>> On Thu, Feb 23, 2012 at 11:40 AM, Francesc Alted
>>> wrote:
Exactly. I'd update this to read:
float96
On Feb 23, 2012, at 6:06 AM, Francesc Alted wrote:
> On Feb 23, 2012, at 5:43 AM, Nathaniel Smith wrote:
>
>> On Thu, Feb 23, 2012 at 11:40 AM, Francesc Alted
>> wrote:
>>> Exactly. I'd update this to read:
>>>
>>> float9696 bits. Only available on 32-bit (i386) platforms.
>>> float128 1
On Feb 23, 2012, at 5:43 AM, Nathaniel Smith wrote:
> On Thu, Feb 23, 2012 at 11:40 AM, Francesc Alted
> wrote:
>> Exactly. I'd update this to read:
>>
>> float9696 bits. Only available on 32-bit (i386) platforms.
>> float128 128 bits. Only available on 64-bit (AMD64) platforms.
>
> E
Le 23/02/2012 12:40, Francesc Alted a écrit :
>> However, I was surprised that float128 is not mentioned in the array of
>> > available types in the user guide.
>> > http://docs.scipy.org/doc/numpy/user/basics.types.html
>> > Is there a specific reason for this absence, or is just about visiting
>>
On Thu, Feb 23, 2012 at 11:40 AM, Francesc Alted wrote:
> Exactly. I'd update this to read:
>
> float96 96 bits. Only available on 32-bit (i386) platforms.
> float128 128 bits. Only available on 64-bit (AMD64) platforms.
Except float96 is actually 80 bits. (Usually?) Plus some padding...
On Feb 23, 2012, at 3:06 AM, Pierre Haessig wrote:
> Hi,
> Le 23/02/2012 02:24, Matthew Brett a écrit :
>> Luckily I was in fact using longdouble in the live code,
> I had never "exotic" floating point precision, so thanks for your post
> which made me take a look at docstring and documentation.
>
Hi,
Le 23/02/2012 02:24, Matthew Brett a écrit :
> Luckily I was in fact using longdouble in the live code,
I had never "exotic" floating point precision, so thanks for your post
which made me take a look at docstring and documentation.
If I got it right from the docstring, 'np.longdouble', 'np.lo
2012/2/22 Stéfan van der Walt :
> On Wed, Feb 22, 2012 at 2:47 PM, Matthew Brett
> wrote:
>> In [4]: np.array([2.1], dtype=np.longlong)
>> Out[4]: array([2], dtype=int64)
>
> Maybe just a typo:
>
> In [3]: np.array([2.1], dtype=np.longfloat)
> Out[3]: array([ 2.1], dtype=float128)
A thinko maybe
On Wed, Feb 22, 2012 at 2:47 PM, Matthew Brett wrote:
> In [4]: np.array([2.1], dtype=np.longlong)
> Out[4]: array([2], dtype=int64)
Maybe just a typo:
In [3]: np.array([2.1], dtype=np.longfloat)
Out[3]: array([ 2.1], dtype=float128)
Stéfan
___
NumPy-
On 02/22/2012 03:47 PM, Matthew Brett wrote:
> Hi,
>
> I was gaily using np.longlong for casting to the highest available
> float type when I noticed this:
>
> In [4]: np.array([2.1], dtype=np.longlong)
> Out[4]: array([2], dtype=int64)
>
> whereas:
>
> In [5]: np.array([2.1], dtype=np.float128)
>
Hi,
I was gaily using np.longlong for casting to the highest available
float type when I noticed this:
In [4]: np.array([2.1], dtype=np.longlong)
Out[4]: array([2], dtype=int64)
whereas:
In [5]: np.array([2.1], dtype=np.float128)
Out[5]: array([ 2.1], dtype=float128)
This on OSX snow leopard n
23 matches
Mail list logo
