paramters determined by GridSearchCV. Where did I make mistake and how to
fix this unexpected results?
Below is the code. The Debug class is used to save the output from 'reduce'
step. This saved output is used in cv_silhouette_scorer() to calculate
silhouette_score. I suspect Debug
On Wed, Nov 16, 2016 at 7:09 PM, Steven D'Aprano
wrote:
> I'm trying to download a file using urllib.request and pipe it straight to an
> external process. On Linux systems, the following is a test file that
> demonstrates the problem:
>
>
> --- cut ---
>
> #!/usr/bin/python3.5
>
> import urllib.r
I'm trying to download a file using urllib.request and pipe it straight to an
external process. On Linux systems, the following is a test file that
demonstrates the problem:
--- cut ---
#!/usr/bin/python3.5
import urllib.request
import subprocess
TEST_URL = 'https://www.irs.gov/pub/irs-prior
On Thu, Aug 1, 2013 at 10:44 AM, Oscar Benjamin
wrote:
> The real dividing line between {int, Fraction} and {float, Decimal,
> complex} is about (in)exactness. The numeric tower ensures the
> property that inexactness is contagious which I think is a good thing.
*nods slowly*
That does make sens
On 1 August 2013 07:32, Chris Angelico wrote:
> On Thu, Aug 1, 2013 at 7:20 AM, Steven D'Aprano
> wrote:
>> I know this, and that's not what surprised me. What surprised me was that
>> Fraction converts the float to a fraction, then compares. It surprises me
>> because in other operations, Fracti
On Thu, Aug 1, 2013 at 7:20 AM, Steven D'Aprano
wrote:
> I know this, and that's not what surprised me. What surprised me was that
> Fraction converts the float to a fraction, then compares. It surprises me
> because in other operations, Fractions down-cast to float.
>
> Adding a float to a Fracti
On Wed, 31 Jul 2013 15:23:21 -0500, Tony the Tiger wrote:
> On Mon, 29 Jul 2013 15:43:24 +, Steven D'Aprano wrote:
>
>> Am I the only one who is surprised by this?
>
> Most likely.
>
> Floats aren't precise enough to be equal to a (true) fraction.
> float(1/3) is cut short somewhere by the
On 29 July 2013 17:09, MRAB wrote:
> On 29/07/2013 16:43, Steven D'Aprano wrote:
>>
>> Comparing floats to Fractions gives unexpected results:
You may not have expected these results but as someone who regularly
uses the fractions module I do expect them.
>> # Python
On 7/29/2013 1:29 PM, Steven D'Aprano wrote:
On Mon, 29 Jul 2013 13:08:20 -0400, Terry Reedy wrote:
In other words, there can be multiple unequal Franctions that have the
same float value: for instance, Fraction(1,3) and
Fraction(6004799503160661, 18014398509481984)
> So from that standpoint
On Jul 29, 2013 1:37 PM, "Serhiy Storchaka" wrote:
>
> 29.07.13 19:09, MRAB написав(ла):
>
>> I'm surprised that Fraction(1/3) != Fraction(1, 3); after all, floats
>> are approximate anyway, and the float value 1/3 is more likely to be
>> Fraction(1, 3) than Fraction(6004799503160661, 180143985094
On Mon, 29 Jul 2013 18:04:19 +0100, MRAB wrote:
> I thought that you're not meant to check for equality when using floats.
Heavens no. You're only meant to *mostly* not check for equality using
floats. As Miracle Max might say:
"It just so happens that floats are only MOSTLY inexact. There's a
On Mon, Jul 29, 2013 at 12:16 PM, Rotwang wrote:
> On 29/07/2013 17:40, Ian Kelly wrote:
>> At the point where the float is exactly equal to the value you get
>> from the floating-point division 1/3.
>
>
> But the interpreter has no way of knowing that the value 1/3 that's been
> passed to the Fra
On Mon, 29 Jul 2013 17:20:27 +0100, Chris Angelico wrote:
Fraction(0.3)
> Fraction(5404319552844595, 18014398509481984)
Fraction(0.33)
> Fraction(5944751508129055, 18014398509481984)
[...]
Fraction(0.3)
> Fraction(6004799503160661, 18014398509481984)
>
> Rounding of
29.07.13 19:09, MRAB написав(ла):
I'm surprised that Fraction(1/3) != Fraction(1, 3); after all, floats
are approximate anyway, and the float value 1/3 is more likely to be
Fraction(1, 3) than Fraction(6004799503160661, 18014398509481984).
>>> def approximate_fraction(f):
prev_numer, numer
On 2013-07-29, MRAB wrote:
> On 29/07/2013 17:40, Ian Kelly wrote:
>> On Mon, Jul 29, 2013 at 10:20 AM, Chris Angelico wrote:
>>> On Mon, Jul 29, 2013 at 5:09 PM, MRAB wrote:
I'm surprised that Fraction(1/3) != Fraction(1, 3); after all, floats
are approximate anyway, and the float val
On 29/07/2013 17:20, Chris Angelico wrote:
On Mon, Jul 29, 2013 at 5:09 PM, MRAB wrote:
I'm surprised that Fraction(1/3) != Fraction(1, 3); after all, floats
are approximate anyway, and the float value 1/3 is more likely to be
Fraction(1, 3) than Fraction(6004799503160661, 18014398509481984).
On 29/07/2013 17:40, Ian Kelly wrote:
On Mon, Jul 29, 2013 at 10:20 AM, Chris Angelico wrote:
On Mon, Jul 29, 2013 at 5:09 PM, MRAB wrote:
I'm surprised that Fraction(1/3) != Fraction(1, 3); after all, floats
are approximate anyway, and the float value 1/3 is more likely to be
Fraction(1, 3)
On Mon, Jul 29, 2013 at 11:04 AM, MRAB wrote:
> On 29/07/2013 17:40, Ian Kelly wrote:
>> At the point where the float is exactly equal to the value you get
>> from the floating-point division 1/3. If it's some other float then
>> the user didn't get there by entering 1/3, so it's not worth trying
On Mon, 29 Jul 2013 13:08:20 -0400, Terry Reedy wrote:
> In other words, there can be multiple unequal Franctions that have the
> same float value: for instance, Fraction(1,3) and
> Fraction(6004799503160661, 18014398509481984)
>
> > So from that standpoint it makes sense to me to cast to Fracti
On Mon, 29 Jul 2013 17:48:21 +0100, MRAB wrote:
> On 29/07/2013 17:20, Chris Angelico wrote:
>> On Mon, Jul 29, 2013 at 5:09 PM, MRAB
>> wrote:
>>> I'm surprised that Fraction(1/3) != Fraction(1, 3); after all, floats
>>> are approximate anyway, and the float value 1/3 is more likely to be
>>> Fr
On Mon, Jul 29, 2013 at 5:40 PM, Ian Kelly wrote:
> On Mon, Jul 29, 2013 at 10:20 AM, Chris Angelico wrote:
>> On Mon, Jul 29, 2013 at 5:09 PM, MRAB wrote:
>>> I'm surprised that Fraction(1/3) != Fraction(1, 3); after all, floats
>>> are approximate anyway, and the float value 1/3 is more likely
On 7/29/2013 11:50 AM, Ian Kelly wrote:
On Mon, Jul 29, 2013 at 9:43 AM, Steven D'Aprano
wrote:
Comparing floats to Fractions gives unexpected results:
# Python 3.3
py> from fractions import Fraction
py> 1/3 == Fraction(1, 3)
False
but:
py> 1/3 == float(Fraction(1, 3))
Tru
On 29/07/2013 17:40, Ian Kelly wrote:
On Mon, Jul 29, 2013 at 10:20 AM, Chris Angelico wrote:
On Mon, Jul 29, 2013 at 5:09 PM, MRAB wrote:
I'm surprised that Fraction(1/3) != Fraction(1, 3); after all, floats
are approximate anyway, and the float value 1/3 is more likely to be
Fraction(1, 3)
On Mon, Jul 29, 2013 at 10:20 AM, Chris Angelico wrote:
> On Mon, Jul 29, 2013 at 5:09 PM, MRAB wrote:
>> I'm surprised that Fraction(1/3) != Fraction(1, 3); after all, floats
>> are approximate anyway, and the float value 1/3 is more likely to be
>> Fraction(1, 3) than Fraction(6004799503160661,
On 29/07/2013 17:20, Chris Angelico wrote:
On Mon, Jul 29, 2013 at 5:09 PM, MRAB wrote:
I'm surprised that Fraction(1/3) != Fraction(1, 3); after all, floats
are approximate anyway, and the float value 1/3 is more likely to be
Fraction(1, 3) than Fraction(6004799503160661, 18014398509481984).
On Mon, Jul 29, 2013 at 5:09 PM, MRAB wrote:
> I'm surprised that Fraction(1/3) != Fraction(1, 3); after all, floats
> are approximate anyway, and the float value 1/3 is more likely to be
> Fraction(1, 3) than Fraction(6004799503160661, 18014398509481984).
At what point should it become Fraction(
On 29/07/2013 16:43, Steven D'Aprano wrote:
Comparing floats to Fractions gives unexpected results:
# Python 3.3
py> from fractions import Fraction
py> 1/3 == Fraction(1, 3)
False
but:
py> 1/3 == float(Fraction(1, 3))
True
I expected that float-to-Fraction comparisons wou
On Mon, Jul 29, 2013 at 9:43 AM, Steven D'Aprano
wrote:
> Comparing floats to Fractions gives unexpected results:
>
> # Python 3.3
> py> from fractions import Fraction
> py> 1/3 == Fraction(1, 3)
> False
>
> but:
>
> py> 1/3 == float(Fraction(1, 3))
&g
Comparing floats to Fractions gives unexpected results:
# Python 3.3
py> from fractions import Fraction
py> 1/3 == Fraction(1, 3)
False
but:
py> 1/3 == float(Fraction(1, 3))
True
I expected that float-to-Fraction comparisons would convert the Fraction
to a float, but apparently th
On 7/24/2013 5:17 PM, Joshua Landau wrote:
import math as m
GAH!
Why on earth would you do such a thing?
for the same reason people do 'import tkinter as tk': to minimize typing
and maximize clarity. In this case,
from math import sin, cos, radians
also works well
--
Terry Jan Reed
On 23 July 2013 13:34, wrote:
> Hello!
> This is my first post, nice to meet you all!
> I`m biology student from Russia, trying to learn python to perform some
>
> simple simulations.
>
> Here`s my first problem.
> I`m trying to perform some simple 2d vector rotations in pygame, in order
>
> to l
On Tue, 23 Jul 2013 15:11:43 +0200, Peter Otten wrote:
> The conversion to int introduces a rounding error that accumulates over
> time.
Most floating point calculations introduce a rounding error. If the
calculations are iterated, the error will accumulate.
In general, you want to avoid accumu
en...@yandex.ru wrote:
> This is my first post, nice to meet you all!
Welcome!
> I`m biology student from Russia, trying to learn python to perform some
>
> simple simulations.
>
> Here`s my first problem.
> I`m trying to perform some simple 2d vector rotations in pygame, in order
>
> to lear
haven't used pygame that much, but it sounds like you drew Z. You have
[0,0],[0,100],[100,0],[100,
100]
0,0 is the top left, if I recall 0, 100 would be the lower left, then you
move to100, 0 which would go diagonal to the top right, and then 100,100 to
the lower right, this is assuming 0,0 is the
Hello!
This is my first post, nice to meet you all!
I`m biology student from Russia, trying to learn python to perform some
simple simulations.
Here`s my first problem.
I`m trying to perform some simple 2d vector rotations in pygame, in order
to learn the basics of linear algebra and 2d trans
Sorry, Everyone. I got an error when posting the first post and did'nt
come in to see if it had actually posted before I tried another post.
--
http://mail.python.org/mailman/listinfo/python-list
I am having a problem when I run a graphics program that I created. I
do not get an error when I run the program, there are just some weird
things going on. I do not know if it is the program causing the
problem or a bug in Python. Here is the code for the program:
from gasp import *
begin_graph
On Friday 24 September 2010, it occurred to Geoff Bache to exclaim:
> > > Unfortunately, it doesn't seem to do that in some cases. Consider the
> >
> > > following code:
> > It does behave as documented: it does not find package names, or
> > investigate sys.modules
>
> Possibly, although for me
> > Unfortunately, it doesn't seem to do that in some cases. Consider the
> > following code:
>
> It does behave as documented: it does not find package names, or investigate
> sys.modules
Possibly, although for me "logging" is exposed as a module, and ought
to behave as one when requesting the m
On Friday 24 September 2010, it occurred to Geoff Bache to exclaim:
> Hi all,
>
> I'm trying to examine some things in my stack. The information I get
> out of inspect.stack() gives file names and I would like to convert
> them to module names. I naturally assumes inspect.getmodulename would
> fix
Hi all,
I'm trying to examine some things in my stack. The information I get
out of inspect.stack() gives file names and I would like to convert
them to module names. I naturally assumes inspect.getmodulename would
fix this for me.
Unfortunately, it doesn't seem to do that in some cases. Consider
Zac Burns gmail.com> writes:
> I'm trying to match any function block,
the two examples were just a part of
my unit tests.
I know. I was just giving an example to indicate why it doesn't work.
find_pattern.py is useful because it gives you a base from which
it's easy to
extrapolate the genera
On Tue, Dec 22, 2009 at 3:21 PM, Benjamin Peterson wrote:
>
> The pattern for that is funcdef< 'def' 'singleLineFunc' parameters< '(' ')'
> >
> ':' simple_stmt< return_stmt< 'return' arith_expr< '1' '+' '2' > > '\n' >
> >. No
> suite.
>
>
I'm trying to match any function block, the two examples we
Zac Burns gmail.com> writes:
>
>
> Greetings,I'm trying to re-purpose the lib2to3 module and along the way came
up with this pattern:"funcdef<'def' name=NAME parameters ['->' test] ':'
suite=suite>"It seems to have 2 problems:
>
> Single-line defs are not matched. Eg: "def singleLineFunc(): re
Greetings,
I'm trying to re-purpose the lib2to3 module and along the way came up with
this pattern:
"funcdef<'def' name=NAME parameters ['->' test] ':' suite=suite>"
It seems to have 2 problems:
1. Single-line defs are not matched. Eg: "def singleLineFunc(): return 1
+ 2" is not matched,
Hi,
Problem solved when strip() is being replaced by strip('\n').
Happy holidays,
Ron.
From: Barak, Ron
Sent: Thursday, December 25, 2008 15:05
To: 'python-list@python.org'
Subject: seek() returns unexpected results
Hi,
When using seek()
Hi,
When using seek() with a certain text file, I get strange results.
I looked at the text file with a binary editor and verified with 'file', and
it's an ASCII English text file.
Running the script on other text files gives the expected output.
Could you suggest the reason ?
In the outputs
47 matches
Mail list logo
