On Thu, Apr 10, 2008 at 8:01 PM, Robert Kern <[EMAIL PROTECTED]> wrote:
> On Thu, Apr 10, 2008 at 8:58 PM, Charles R Harris
> <[EMAIL PROTECTED]> wrote:
> > I'm open to suggestions.
>
> I have nothing better to offer than what you've done. Thank you!
>
OK, but it looks like I need to implement ou
On Thu, Apr 10, 2008 at 8:58 PM, Charles R Harris
<[EMAIL PROTECTED]> wrote:
> I'm open to suggestions.
I have nothing better to offer than what you've done. Thank you!
--
Robert Kern
"I have come to believe that the whole world is an enigma, a harmless
enigma that is made terrible by our own m
On Thu, Apr 10, 2008 at 7:06 PM, Robert Kern <[EMAIL PROTECTED]> wrote:
> On Thu, Apr 10, 2008 at 7:57 PM, Charles R Harris
> <[EMAIL PROTECTED]> wrote:
> >
> > On Thu, Apr 10, 2008 at 6:38 PM, Robert Kern <[EMAIL PROTECTED]>
> wrote:
> > >
> > > On Thu, Apr 10, 2008 at 7:31 PM, Charles R Harris
>
On Thu, Apr 10, 2008 at 7:06 PM, Robert Kern <[EMAIL PROTECTED]> wrote:
> On Thu, Apr 10, 2008 at 7:57 PM, Charles R Harris
> <[EMAIL PROTECTED]> wrote:
> >
> > On Thu, Apr 10, 2008 at 6:38 PM, Robert Kern <[EMAIL PROTECTED]>
> wrote:
> > >
> > > On Thu, Apr 10, 2008 at 7:31 PM, Charles R Harris
>
On Thu, Apr 10, 2008 at 7:57 PM, Charles R Harris
<[EMAIL PROTECTED]> wrote:
>
> On Thu, Apr 10, 2008 at 6:38 PM, Robert Kern <[EMAIL PROTECTED]> wrote:
> >
> > On Thu, Apr 10, 2008 at 7:31 PM, Charles R Harris
> > <[EMAIL PROTECTED]> wrote:
> > > > That said, str(float_numpy_scalar) really should
On Thu, Apr 10, 2008 at 6:38 PM, Robert Kern <[EMAIL PROTECTED]> wrote:
> On Thu, Apr 10, 2008 at 7:31 PM, Charles R Harris
> <[EMAIL PROTECTED]> wrote:
> > > That said, str(float_numpy_scalar) really should have the same rules
> > > as str(some_python_float).
> >
> > For all different precisions?
On Thu, Apr 10, 2008 at 7:31 PM, Charles R Harris
<[EMAIL PROTECTED]> wrote:
> > That said, str(float_numpy_scalar) really should have the same rules
> > as str(some_python_float).
>
> For all different precisions?
No. I should have said str(float64_numpy_scalar). I am content to
leave the other t
On Fri, Apr 4, 2008 at 1:47 PM, Robert Kern <[EMAIL PROTECTED]> wrote:
> On Fri, Apr 4, 2008 at 9:56 AM, Will Lee <[EMAIL PROTECTED]> wrote:
> > I understand the implication for the floating point comparison and the
> need
> > for allclose. However, I think in a doctest context, this behavior
> m
Thanks for all the comments about this issue. Do you know if there's a
ticket that's open for this? Is this an easy fix before the 1.0.5 release?
Thanks,
Will
On Fri, Apr 4, 2008 at 3:40 PM, Timothy Hochberg <[EMAIL PROTECTED]>
wrote:
>
>
> On Fri, Apr 4, 2008 at 12:47 PM, Robert Kern <[EMAIL
On Fri, Apr 4, 2008 at 12:47 PM, Robert Kern <[EMAIL PROTECTED]> wrote:
> On Fri, Apr 4, 2008 at 9:56 AM, Will Lee <[EMAIL PROTECTED]> wrote:
> > I understand the implication for the floating point comparison and the
> need
> > for allclose. However, I think in a doctest context, this behavior
>
Robert Kern wrote:
> On Fri, Apr 4, 2008 at 9:56 AM, Will Lee <[EMAIL PROTECTED]> wrote:
>
>> I understand the implication for the floating point comparison and the need
>> for allclose. However, I think in a doctest context, this behavior makes
>> the doc much harder to read.
>>
>
> Tabli
On Fri, Apr 4, 2008 at 9:56 AM, Will Lee <[EMAIL PROTECTED]> wrote:
> I understand the implication for the floating point comparison and the need
> for allclose. However, I think in a doctest context, this behavior makes
> the doc much harder to read.
Tabling the issue of the fact that we changed
I understand the implication for the floating point comparison and the need
for allclose. However, I think in a doctest context, this behavior makes
the doc much harder to read. For example, if you have this in your doctest:
def doSomething(a):
'''
>>> print doSomething(0.0011)[0]
>>
Hi,
Note that at least under Python 2.5.1:
>>> a=0.0012
>>> a
0.0011999
>>> str(a)
'0.0012'
>>> repr(a)
'0.0011999'
From Python docs, repr(): 'Return a string containing a printable
representation of an object' and str(): 'Return a nice string
representation of the o
Bruce Southey wrote:
> Hi,
> This topic has come up many times and the only problem is the lack of
> understanding how computers store numbers and computer numerical precision.
>
> The NumPy output is consistent with Python on my x86_64 linux system
> with Python 2.5.1:
> >>> a=0.0012
> >>> a
>
Hi,
This topic has come up many times and the only problem is the lack of
understanding how computers store numbers and computer numerical precision.
The NumPy output is consistent with Python on my x86_64 linux system
with Python 2.5.1:
>>> a=0.0012
>>> a
0.0011999
Simply put, in
Hi Will
On 03/04/2008, Will Lee <[EMAIL PROTECTED]> wrote:
> I seem to have problem with floating point printing with the latest numpy,
> python 2.5.2, gcc 4.1.4, and 64-bit linux:
>
> In [24]: print str(0.0012)
> 0.0012
>
> In [25]: a = numpy.array([0.0012])
>
> In [26]: print str(a[0])
> 0.0011
Hi,
I seem to have problem with floating point printing with the latest numpy,
python 2.5.2, gcc 4.1.4, and 64-bit linux:
In [24]: print str(0.0012)
0.0012
In [25]: a = numpy.array([0.0012])
In [26]: print str(a[0])
0.0011999
In [27]: print numpy.__version__
1.0.5.dev4950
It seems
18 matches
Mail list logo
