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-bit
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 is
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 extended
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',
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.
If I
On Thu, Feb 23, 2012 at 11:40 AM, Francesc Alted franc...@continuum.io 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
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
the
On Feb 23, 2012, at 5:43 AM, Nathaniel Smith wrote:
On Thu, Feb 23, 2012 at 11:40 AM, Francesc Alted franc...@continuum.io
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)
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 franc...@continuum.io
wrote:
Exactly. I'd update this to read:
float9696 bits. Only available on 32-bit (i386) platforms.
Hi,
On Thu, Feb 23, 2012 at 4:23 AM, Francesc Alted franc...@continuum.io 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 franc...@continuum.io
wrote:
Exactly. I'd update this to
On Thu, Feb 23, 2012 at 5:23 AM, Francesc Alted franc...@continuum.iowrote:
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 franc...@continuum.io
wrote:
Exactly. I'd update this to
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
Hi,
On Thu, Feb 23, 2012 at 10:11 AM, Pierre Haessig
pierre.haes...@crans.org 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
On Thu, Feb 23, 2012 at 10:42 AM, Matthew Brett matthew.br...@gmail.comwrote:
Hi,
On Thu, Feb 23, 2012 at 10:11 AM, Pierre Haessig
pierre.haes...@crans.org 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
Hi,
On Thu, Feb 23, 2012 at 10:45 AM, Mark Wiebe mwwi...@gmail.com wrote:
On Thu, Feb 23, 2012 at 10:42 AM, Matthew Brett matthew.br...@gmail.com
wrote:
Hi,
On Thu, Feb 23, 2012 at 10:11 AM, Pierre Haessig
pierre.haes...@crans.org wrote:
Le 23/02/2012 17:28, Charles R Harris a écrit :
On Thu, Feb 23, 2012 at 10:55 AM, Matthew Brett matthew.br...@gmail.comwrote:
Hi,
On Thu, Feb 23, 2012 at 10:45 AM, Mark Wiebe mwwi...@gmail.com wrote:
On Thu, Feb 23, 2012 at 10:42 AM, Matthew Brett matthew.br...@gmail.com
wrote:
Hi,
On Thu, Feb 23, 2012 at 10:11 AM, Pierre
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
Hi,
On Thu, Feb 23, 2012 at 2:56 PM, Pierre Haessig
pierre.haes...@crans.org 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
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
On Wed, Feb 22, 2012 at 2:47 PM, Matthew Brett matthew.br...@gmail.com 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
2012/2/22 Stéfan van der Walt ste...@sun.ac.za:
On Wed, Feb 22, 2012 at 2:47 PM, Matthew Brett matthew.br...@gmail.com
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],
21 matches
Mail list logo
