> That's an ideal case, but it doesn't work, because more or less senior
> committers are already too busy. If they do not even have time to
> review issues, followup on patches - how can they monitor who reached
> the appropriate karma level?
The practice proves to be different. In the recent ad
On Sun, Mar 28, 2010 at 9:28 AM, Robert Kern wrote:
> On 2010-03-27 00:32 , David Cournapeau wrote:
>>
>> On Sat, Mar 27, 2010 at 8:16 AM, Raymond Hettinger
>> wrote:
>>>
>>> On Mar 26, 2010, at 2:16 PM, Xavier Morel wrote:
>>>
>>> How about raising an exception instead of creating nans in the f
On Wed, Mar 24, 2010 at 12:34 AM, "Martin v. Löwis" wrote:
>
> Procedurally, I wonder where people got the notion from that you can or
> need to apply for commit access. IIUC, it used to be the case that you
> would be recommended for commit access, by some (more or less senior)
> fellow committer
On Sun, Mar 28, 2010 at 17:55, Greg Ewing wrote:
> Steven D'Aprano wrote:
>
>> I disagree -- if I ask:
>>
>> 3.0 in [1.0, 2.0, float('nan'), 3.0]
>>
>> I should get True, not an exception.
>
> Yes, I don't think anyone would disagree that NaN should compare
> unequal to anything that isn't a NaN.
On Sun, Mar 28, 2010 at 3:25 PM, Larry Hastings wrote:
> M.-A. Lemburg wrote:
>
> Just as reminder of the process we have in place for such changes:
> Please discuss any major breakage on python-dev before checking in
> the patch.
>
>
> I'm aware this is a good idea. I simply didn't consider this
Steven D'Aprano wrote:
I disagree -- if I ask:
3.0 in [1.0, 2.0, float('nan'), 3.0]
I should get True, not an exception.
Yes, I don't think anyone would disagree that NaN should compare
unequal to anything that isn't a NaN. Problems only arise when
comparing two NaNs.
--
Greg
_
On Sun, 28 Mar 2010 05:32:46 pm Adam Olsen wrote:
> On Sat, Mar 27, 2010 at 18:27, Robert Kern
wrote:
> > On 2010-03-27 13:36 , Adam Olsen wrote:
> >> What's the flaw in using isnan()?
> >
> > There are implicit comparisons being done inside
> > list.__contains__() and other such methods. They do
Well, it's been a couple of days, and nobody has stepped forward to
speak in favor of my aggressive PyCapsule schedule. So I will bow to
the wishes of those who have spoken up, and scale it back.
Specifically, I propose writing a patch that will:
* allow the CObject API to (unsafely) d
On Fri, Mar 26, 2010 at 8:59 PM, Michael Foord
wrote:
> Hello all,
>
> A user has suggested an optional argument to
> unittest.TestCase.assertAlmostEqual for specifying a maximum difference
> between the expected and actual values, instead of using rounding.
>
> This sounds great to me as the defa
A good summary on floating point comparison algorithms can be found at
http://www.boost.org/doc/libs/1_34_0/libs/test/doc/components/test_tools/floating_point_comparison.html
I, too, redefine almostEquals so that the comparison is more robust
+1
On Sun, Mar 28, 2010 at 2:06 AM, Steven D'Aprano
On Sun, 28 Mar 2010 02:54:19 pm Charles McCreary wrote:
> Perhaps not just absolute but relative tolerance, e.g.:
>
> def isclose(x, y, rtol=1.e-5, atol=1.e-8):
> return abs(x-y) <= atol + rtol * abs(y)
I'm not sure why you add the tolerances like that. Surely a more
appropriate approach is t
11 matches
Mail list logo
