On Mon, Nov 27, 2017 at 3:04 PM, Rustom Mody wrote:
>> Aviators have pinned down the best solution to this, I think. A pilot
>> is not expected to be perfect; he is expected to follow checklists. A
>> preflight checklist. A departure checklist. A landing checklist.
>>
On 27/11/2017 17:41, Chris Angelico wrote:
> On Tue, Nov 28, 2017 at 2:14 AM, bartc wrote:
>> JPEG uses lossy compression. The resulting recovered data is an
>> approximation of the original.
>
> Ah but it is a perfect representation of the JPEG stream. Any given
> compressed
On 11/27/17 1:57 PM, bartc wrote:
> On 27/11/2017 17:41, Chris Angelico wrote:
>> On Tue, Nov 28, 2017 at 2:14 AM, bartc wrote:
>>> JPEG uses lossy compression. The resulting recovered data is an
>>> approximation of the original.
>>
>> Ah but it is a perfect representation of
bartc wrote:
> Testing everything comprehensively just wouldn't be useful for me who
> works on whole applications, whole concepts, not just a handful of
> functions with well-defined inputs and outputs.
I had this experience with Pyrex (the precursor to Cython). The various parts
are so
On Nov 27, 2017 7:08 AM, "Chris Angelico" wrote:
In every compiler, interpreter, and CPU that I've ever used, the remainder has
been well-defined. In what situation was it ill-defined, such that different
compilers could do different things?
In C89 the result of integer
On Tue, Nov 28, 2017 at 2:14 AM, bartc wrote:
> JPEG uses lossy compression. The resulting recovered data is an
> approximation of the original.
Ah but it is a perfect representation of the JPEG stream. Any given compressed
stream must always decode to the same output. The
On Monday, November 27, 2017 at 2:10:56 AM UTC-8, Chris Angelico wrote:
> Or you could use the floating-point values for positive and negative
> infinity
perfecto! thank you!
peace
stm
--
https://mail.python.org/mailman/listinfo/python-list
On Mon, Nov 27, 2017 at 10:38 PM, bartc wrote:
> On 27/11/2017 03:04, Michael Torrie wrote:
>>
>> On 11/26/2017 08:39 AM, bartc wrote:
>>>
>>> The problem was traced to two lines that were in the wrong order (in the
>>> original program). I can't see how unit tests can have
bartc wrote:
> (Maybe it's viable if working from an exacting
> specification that someone else has already worked out.)
In my experience, for anything non-trivial that hasn't been done before, these
"exacting specifications" never exist. Even if someone handles wnat they
*think* are exact and
On 27/11/2017 13:57, Chris Angelico wrote:
> On Mon, Nov 27, 2017 at 10:38 PM, bartc wrote:
> Your decoder was straight-up buggy, and tests would have proven this.
I created my Python version after the abysmal results from other Python
decoders I tried which didn't work at
On Monday, November 27, 2017 at 12:12:24 PM UTC+5:30, Chris Angelico wrote:
> On Mon, Nov 27, 2017 at 3:04 PM, Rustom Mody wrote:
> >> Aviators have pinned down the best solution to this, I think. A pilot
> >> is not expected to be perfect; he is expected to follow checklists. A
> >> preflight
On 27/11/2017 03:04, Michael Torrie wrote:
> On 11/26/2017 08:39 AM, bartc wrote:
>> The problem was traced to two lines that were in the wrong order (in the
>> original program). I can't see how unit tests can have helped in any way
>> at all, and it would probably have taken much longer.
>
>
On Sunday, November 26, 2017 at 7:09:25 PM UTC-8, Michael Torrie wrote:
> So you are using this Infinity class as a sentinel value of some kind?
> Representing game state? There may be an easier way than a full on
> custom type. Sometimes just a sentinel object is sufficient. Or an
>
On Mon, Nov 27, 2017 at 9:01 PM, wrote:
> On Sunday, November 26, 2017 at 7:09:25 PM UTC-8, Michael Torrie wrote:
>
>> So you are using this Infinity class as a sentinel value of some kind?
>> Representing game state? There may be an easier way than a full on
>>
On Mon, Nov 27, 2017 at 10:08 AM, Gregory Ewing
wrote:
> Chris Angelico wrote:
>
>> On Mon, Nov 27, 2017 at 1:11 AM, bartc wrote:
>
>>
>>>
>>> If I had to bother with such systematic tests as you suggest, and finish
>>> and
>>> sign off everything
On Monday, November 27, 2017 at 9:08:42 AM UTC+5:30, Chris Angelico wrote:
> On Mon, Nov 27, 2017 at 1:55 PM, Michael Torrie wrote:
> > On 11/26/2017 07:11 AM, bartc wrote:
> >>> You may argue that testing doesn't matter for his small game, written
> >>> for his own education and amusement. The
Chris Angelico wrote:
> On Mon, Nov 27, 2017 at 1:11 AM, bartc wrote:
>
>>If I had to bother with such systematic tests as you suggest, and finish and
>>sign off everything before proceeding further, then nothing would ever get
>>done. (Maybe it's viable if working from an
On Mon, Nov 27, 2017 at 1:55 PM, Michael Torrie wrote:
> On 11/26/2017 07:11 AM, bartc wrote:
>>> You may argue that testing doesn't matter for his small game, written
>>> for his own education and amusement. The fact is that software in
>>> general is of abysmal quality
On 11/26/2017 08:39 AM, bartc wrote:
> The problem was traced to two lines that were in the wrong order (in the
> original program). I can't see how unit tests can have helped in any way
> at all, and it would probably have taken much longer.
What makes you think that? Surely other decoders were
On 11/26/2017 07:11 AM, bartc wrote:
>> You may argue that testing doesn't matter for his small game, written
>> for his own education and amusement. The fact is that software in
>> general is of abysmal quality across the boards, and promoting a habit
>> of unit testing is good, even for
On 11/25/2017 12:58 PM, namenobodywa...@gmail.com wrote:
> the idea is that there should be exactly one object posinf (positive
infinity) that compares as strictly greater than any number ever considered,
and exactly one object neginf that compares as strictly less; as the code
stands now there is
On 25/11/2017 23:49, Terry Reedy wrote:
> On 11/25/2017 4:57 PM, namenobodywa...@gmail.com wrote:
>> On Saturday, November 25, 2017 at 12:48:38 AM UTC-8, Terry Reedy wrote:
>>
>>> I did, and it looks buggy to me.â The top and left frame lines are
>>> missing.â If I click a square, the bottom
On 25/11/2017 16:07, Michael Torrie wrote:
> On 11/25/2017 06:00 AM, bartc wrote:
>> And there's a quite lot left of the rest of the program to worry about too!
>>
>> If you add 'window()' at the end of the program, then it seems to run on
>> Python 3. I'd play around with it first before thinking
On Sat, 25 Nov 2017 12:26:52 -0800, namenobodywants wrote:
> On Friday, November 24, 2017 at 8:07:07 AM UTC-8, Chris Angelico wrote:
>
>> This is the kind of function that needs a docstring and some comments.
>> What exactly is this doing? What are the "lines" of the board? What's
>> the
On 11/27/17 1:57 PM, bartc wrote:
On 27/11/2017 17:41, Chris Angelico wrote:
On Tue, Nov 28, 2017 at 2:14 AM, bartc wrote:
JPEG uses lossy compression. The resulting recovered data is an
approximation of the original.
Ah but it is a perfect representation of the JPEG
On 27/11/2017 17:41, Chris Angelico wrote:
On Tue, Nov 28, 2017 at 2:14 AM, bartc wrote:
JPEG uses lossy compression. The resulting recovered data is an
approximation of the original.
Ah but it is a perfect representation of the JPEG stream. Any given
compressed stream must
On Tue, Nov 28, 2017 at 2:14 AM, bartc wrote:
> JPEG uses lossy compression. The resulting recovered data is an
> approximation of the original.
Ah but it is a perfect representation of the JPEG stream. Any given
compressed stream must always decode to the same output. The
On 27/11/2017 13:57, Chris Angelico wrote:
On Mon, Nov 27, 2017 at 10:38 PM, bartc wrote:
Your decoder was straight-up buggy, and tests would have proven this.
I created my Python version after the abysmal results from other Python
decoders I tried which didn't work at
On Nov 27, 2017 7:08 AM, "Chris Angelico" wrote:
In every compiler, interpreter, and CPU that I've ever used, the
remainder has been well-defined. In what situation was it ill-defined,
such that different compilers could do different things?
In C89 the result of integer
On Mon, Nov 27, 2017 at 10:38 PM, bartc wrote:
> On 27/11/2017 03:04, Michael Torrie wrote:
>>
>> On 11/26/2017 08:39 AM, bartc wrote:
>>>
>>> The problem was traced to two lines that were in the wrong order (in the
>>> original program). I can't see how unit tests can have
On Monday, November 27, 2017 at 12:12:24 PM UTC+5:30, Chris Angelico wrote:
> On Mon, Nov 27, 2017 at 3:04 PM, Rustom Mody wrote:
> >> Aviators have pinned down the best solution to this, I think. A pilot
> >> is not expected to be perfect; he is expected to follow checklists. A
> >> preflight
On Monday, November 27, 2017 at 2:10:56 AM UTC-8, Chris Angelico wrote:
> Or you could use the floating-point values for positive and negative
> infinity
perfecto! thank you!
peace
stm
--
https://mail.python.org/mailman/listinfo/python-list
On 27/11/2017 03:04, Michael Torrie wrote:
On 11/26/2017 08:39 AM, bartc wrote:
The problem was traced to two lines that were in the wrong order (in the
original program). I can't see how unit tests can have helped in any way
at all, and it would probably have taken much longer.
What makes
On Mon, Nov 27, 2017 at 9:01 PM, wrote:
> On Sunday, November 26, 2017 at 7:09:25 PM UTC-8, Michael Torrie wrote:
>
>> So you are using this Infinity class as a sentinel value of some kind?
>> Representing game state? There may be an easier way than a full on
>>
On Sunday, November 26, 2017 at 7:09:25 PM UTC-8, Michael Torrie wrote:
> So you are using this Infinity class as a sentinel value of some kind?
> Representing game state? There may be an easier way than a full on
> custom type. Sometimes just a sentinel object is sufficient. Or an
>
On Mon, Nov 27, 2017 at 3:04 PM, Rustom Mody wrote:
>> Aviators have pinned down the best solution to this, I think. A pilot
>> is not expected to be perfect; he is expected to follow checklists. A
>> preflight checklist. A departure checklist. A landing checklist.
>>
On Monday, November 27, 2017 at 9:08:42 AM UTC+5:30, Chris Angelico wrote:
> On Mon, Nov 27, 2017 at 1:55 PM, Michael Torrie wrote:
> > On 11/26/2017 07:11 AM, bartc wrote:
> >>> You may argue that testing doesn't matter for his small game, written
> >>> for his own education and amusement. The
On Mon, Nov 27, 2017 at 1:55 PM, Michael Torrie wrote:
> On 11/26/2017 07:11 AM, bartc wrote:
>>> You may argue that testing doesn't matter for his small game, written
>>> for his own education and amusement. The fact is that software in
>>> general is of abysmal quality
On 11/25/2017 12:58 PM, namenobodywa...@gmail.com wrote:
> the idea is that there should be exactly one object posinf (positive
> infinity) that compares as strictly greater than any number ever considered,
> and exactly one object neginf that compares as strictly less; as the code
> stands now
On 11/26/2017 08:39 AM, bartc wrote:
> The problem was traced to two lines that were in the wrong order (in the
> original program). I can't see how unit tests can have helped in any way
> at all, and it would probably have taken much longer.
What makes you think that? Surely other decoders
On 11/26/2017 07:11 AM, bartc wrote:
>> You may argue that testing doesn't matter for his small game, written
>> for his own education and amusement. The fact is that software in
>> general is of abysmal quality across the boards, and promoting a habit
>> of unit testing is good, even for
bartc wrote:
Testing everything comprehensively just wouldn't be useful for me who
works on whole applications, whole concepts, not just a handful of
functions with well-defined inputs and outputs.
I had this experience with Pyrex (the precursor to Cython).
The various parts are so
On Mon, Nov 27, 2017 at 10:08 AM, Gregory Ewing
wrote:
> Chris Angelico wrote:
>
>> On Mon, Nov 27, 2017 at 1:11 AM, bartc wrote:
>
>>
>>>
>>> If I had to bother with such systematic tests as you suggest, and finish
>>> and
>>> sign off everything
Chris Angelico wrote:
On Mon, Nov 27, 2017 at 1:11 AM, bartc wrote:
>
If I had to bother with such systematic tests as you suggest, and finish and
sign off everything before proceeding further, then nothing would ever get
done. (Maybe it's viable if working from an exacting
bartc wrote:
(Maybe it's viable if working from an exacting
specification that someone else has already worked out.)
In my experience, for anything non-trivial that hasn't been
done before, these "exacting specifications" never exist.
Even if someone handles wnat they *think* are exact and
On 26/11/2017 14:23, Chris Angelico wrote:
> On Mon, Nov 27, 2017 at 1:11 AM, bartc wrote:
>> The way I write code isn't incrementally top down or bottom up. It's
>> backwards and forwards. Feedback from different parts means the thing
>> develops as a whole. Sometimes parts are
On 25/11/2017 23:49, Terry Reedy wrote:
> On 11/25/2017 4:57 PM, namenobodywa...@gmail.com wrote:
>> On Saturday, November 25, 2017 at 12:48:38 AM UTC-8, Terry Reedy wrote:
>>
>>> I did, and it looks buggy to me.â The top and left frame lines are
>>> missing.â If I click a square, the bottom
On 25/11/2017 16:07, Michael Torrie wrote:
> On 11/25/2017 06:00 AM, bartc wrote:
>> And there's a quite lot left of the rest of the program to worry about too!
>>
>> If you add 'window()' at the end of the program, then it seems to run on
>> Python 3. I'd play around with it first before thinking
On Sat, 25 Nov 2017 12:26:52 -0800, namenobodywants wrote:
> On Friday, November 24, 2017 at 8:07:07 AM UTC-8, Chris Angelico wrote:
>
>> This is the kind of function that needs a docstring and some comments.
>> What exactly is this doing? What are the "lines" of the board? What's
>> the
On 11/25/2017 4:57 PM, namenobodywa...@gmail.com wrote:
> On Saturday, November 25, 2017 at 12:48:38 AM UTC-8, Terry Reedy wrote:
>
>> I did, and it looks buggy to me. The top and left frame lines are
>> missing. If I click a square, the bottom square in the column lights
>> up. But then I have
On Saturday, November 25, 2017 at 12:48:38 AM UTC-8, Terry Reedy wrote:
> I did, and it looks buggy to me. The top and left frame lines are
> missing. If I click a square, the bottom square in the column lights
> up. But then I have no idea whether those are your intentions or not.
i hadn't
On Friday, November 24, 2017 at 8:07:07 AM UTC-8, Chris Angelico wrote:
> This is the kind of function that needs a docstring and some comments.
> What exactly is this doing? What are the "lines" of the board? What's
> the difference between "linear" and "lines"? What exactly is it
> returning?
On Saturday, November 25, 2017 at 5:00:12 AM UTC-8, bartc wrote:
> Actually I've no idea what these tests are supposed to prove.
me neither; i think you guys may be getting me out of my depth now
> They are to do with one class called 'infinity', which is never used in the
rest
> of the
On 11/25/2017 06:00 AM, bartc wrote:
> And there's a quite lot left of the rest of the program to worry about too!
>
> If you add 'window()' at the end of the program, then it seems to run on
> Python 3. I'd play around with it first before thinking up strategies
> for testing it.
Actually, no.
On Mon, Nov 27, 2017 at 1:11 AM, bartc wrote:
> The way I write code isn't incrementally top down or bottom up. It's
> backwards and forwards. Feedback from different parts means the thing
> develops as a whole. Sometimes parts are split into distinct sections,
> sometimes
On 25/11/2017 23:49, Terry Reedy wrote:
> On 11/25/2017 4:57 PM, namenobodywa...@gmail.com wrote:
>> On Saturday, November 25, 2017 at 12:48:38 AM UTC-8, Terry Reedy wrote:
>>
>>> I did, and it looks buggy to me.â The top and left frame lines are
>>> missing.â If I click a square, the bottom
On Sat, 25 Nov 2017 12:26:52 -0800, namenobodywants wrote:
> On Friday, November 24, 2017 at 8:07:07 AM UTC-8, Chris Angelico wrote:
>
>> This is the kind of function that needs a docstring and some comments.
>> What exactly is this doing? What are the "lines" of the board? What's
>> the
On 26/11/2017 14:23, Chris Angelico wrote:
> On Mon, Nov 27, 2017 at 1:11 AM, bartc wrote:
>> The way I write code isn't incrementally top down or bottom up. It's
>> backwards and forwards. Feedback from different parts means the thing
>> develops as a whole. Sometimes parts are
On 25/11/2017 16:07, Michael Torrie wrote:
> On 11/25/2017 06:00 AM, bartc wrote:
>> And there's a quite lot left of the rest of the program to worry about too!
>>
>> If you add 'window()' at the end of the program, then it seems to run on
>> Python 3. I'd play around with it first before thinking
On 11/25/2017 4:57 PM, namenobodywa...@gmail.com wrote:
> On Saturday, November 25, 2017 at 12:48:38 AM UTC-8, Terry Reedy wrote:
>
>> I did, and it looks buggy to me. The top and left frame lines are
>> missing. If I click a square, the bottom square in the column lights
>> up. But then I have
On Saturday, November 25, 2017 at 12:48:38 AM UTC-8, Terry Reedy wrote:
> I did, and it looks buggy to me. The top and left frame lines are
> missing. If I click a square, the bottom square in the column lights
> up. But then I have no idea whether those are your intentions or not.
i hadn't
On Saturday, November 25, 2017 at 5:00:12 AM UTC-8, bartc wrote:
> Actually I've no idea what these tests are supposed to prove.
me neither; i think you guys may be getting me out of my depth now
> They are to do with one class called 'infinity', which is never used in the
rest
> of the
On 11/25/2017 06:00 AM, bartc wrote:
> And there's a quite lot left of the rest of the program to worry about too!
>
> If you add 'window()' at the end of the program, then it seems to run on
> Python 3. I'd play around with it first before thinking up strategies
> for testing it.
Actually, no.
On Friday, November 24, 2017 at 8:07:07 AM UTC-8, Chris Angelico wrote:
> This is the kind of function that needs a docstring and some comments.
> What exactly is this doing? What are the "lines" of the board? What's
> the difference between "linear" and "lines"? What exactly is it
> returning?
On 26/11/2017 14:23, Chris Angelico wrote:
On Mon, Nov 27, 2017 at 1:11 AM, bartc wrote:
The way I write code isn't incrementally top down or bottom up. It's
backwards and forwards. Feedback from different parts means the thing
develops as a whole. Sometimes parts are split
On Mon, Nov 27, 2017 at 1:11 AM, bartc wrote:
> The way I write code isn't incrementally top down or bottom up. It's
> backwards and forwards. Feedback from different parts means the thing
> develops as a whole. Sometimes parts are split into distinct sections,
> sometimes
On 25/11/2017 23:49, Terry Reedy wrote:
On 11/25/2017 4:57 PM, namenobodywa...@gmail.com wrote:
On Saturday, November 25, 2017 at 12:48:38 AM UTC-8, Terry Reedy wrote:
I did, and it looks buggy to me. The top and left frame lines are
missing. If I click a square, the bottom square in the
On 25/11/2017 16:07, Michael Torrie wrote:
On 11/25/2017 06:00 AM, bartc wrote:
And there's a quite lot left of the rest of the program to worry about too!
If you add 'window()' at the end of the program, then it seems to run on
Python 3. I'd play around with it first before thinking up
On Sat, 25 Nov 2017 12:26:52 -0800, namenobodywants wrote:
> On Friday, November 24, 2017 at 8:07:07 AM UTC-8, Chris Angelico wrote:
>
>> This is the kind of function that needs a docstring and some comments.
>> What exactly is this doing? What are the "lines" of the board? What's
>> the
On 11/25/2017 4:57 PM, namenobodywa...@gmail.com wrote:
On Saturday, November 25, 2017 at 12:48:38 AM UTC-8, Terry Reedy wrote:
I did, and it looks buggy to me. The top and left frame lines are
missing. If I click a square, the bottom square in the column lights
up. But then I have no idea
On Saturday, November 25, 2017 at 12:48:38 AM UTC-8, Terry Reedy wrote:
> I did, and it looks buggy to me. The top and left frame lines are
> missing. If I click a square, the bottom square in the column lights
> up. But then I have no idea whether those are your intentions or not.
i hadn't
On Friday, November 24, 2017 at 8:07:07 AM UTC-8, Chris Angelico wrote:
> This is the kind of function that needs a docstring and some comments.
> What exactly is this doing? What are the "lines" of the board? What's
> the difference between "linear" and "lines"? What exactly is it
> returning?
On Saturday, November 25, 2017 at 5:00:12 AM UTC-8, bartc wrote:
> Actually I've no idea what these tests are supposed to prove.
me neither; i think you guys may be getting me out of my depth now
> They are to do with one class called 'infinity', which is never used in the
> rest
> of the
On 11/25/2017 06:00 AM, bartc wrote:
> And there's a quite lot left of the rest of the program to worry about too!
>
> If you add 'window()' at the end of the program, then it seems to run on
> Python 3. I'd play around with it first before thinking up strategies
> for testing it.
Actually,
On Nov 25, 2017, at 9:16 AM, Ian Kelly wrote:
>
>> On Sat, Nov 25, 2017 at 10:02 AM, Chris Angelico wrote:
>>> On Sun, Nov 26, 2017 at 3:36 AM, Ian Kelly wrote:
On Sat, Nov 25, 2017 at 6:00 AM, bartc wrote:
On Sat, Nov 25, 2017 at 10:02 AM, Chris Angelico wrote:
> On Sun, Nov 26, 2017 at 3:36 AM, Ian Kelly wrote:
>> On Sat, Nov 25, 2017 at 6:00 AM, bartc wrote:
>>> Where are your unittests for these unittests?
>>
>> No, the point of having
On Sun, Nov 26, 2017 at 3:36 AM, Ian Kelly wrote:
> On Sat, Nov 25, 2017 at 6:00 AM, bartc wrote:
>> Where are your unittests for these unittests?
>
> No, the point of having unit tests is to build confidence that the
> code in question works correctly.
On Sat, Nov 25, 2017 at 6:00 AM, bartc wrote:
> Where are your unittests for these unittests?
Taking this question more seriously than it deserves: the tests for
the unittest module itself are at
https://hg.python.org/cpython/file/tip/Lib/unittest/test. Yes,
unittest has tests
On 25/11/2017 04:43, Ian Kelly wrote:
On Fri, Nov 24, 2017 at 7:05 PM, wrote:
On Friday, November 24, 2017 at 12:13:18 PM UTC-8, Terry Reedy wrote:
Since you did not start with tests or write tests as you wrote code, ...
why on earth would you assume that?
On 11/24/2017 9:05 PM, namenobodywa...@gmail.com wrote:
On Friday, November 24, 2017 at 12:13:18 PM UTC-8, Terry Reedy wrote:
Since you did not start with tests or write tests as you wrote code, ...
that I could tell ...
I agree that I should have stuck in a qualifier, such as 'apparently'.
On Fri, Nov 24, 2017 at 7:05 PM, wrote:
> On Friday, November 24, 2017 at 12:13:18 PM UTC-8, Terry Reedy wrote:
>
>> Since you did not start with tests or write tests as you wrote code, ...
>
> why on earth would you assume that? instantiate "window" and you'll see it
On Sat, Nov 25, 2017 at 1:05 PM, wrote:
> On Friday, November 24, 2017 at 12:13:18 PM UTC-8, Terry Reedy wrote:
>
>> Since you did not start with tests or write tests as you wrote code, ...
>
> why on earth would you assume that? instantiate "window" and you'll see it
On Friday, November 24, 2017 at 12:13:18 PM UTC-8, Terry Reedy wrote:
> Since you did not start with tests or write tests as you wrote code, ...
why on earth would you assume that? instantiate "window" and you'll see it
works exactly as i intended; nobody's asking you to debug code for free;
On 11/24/2017 10:33 AM, namenobodywa...@gmail.com wrote:
hi all
i've just finished my first excursion into artificial intelligence with a game
less trivial than tictactoe, and here it is in case anybody can offer
criticism/suggestions/etc
Since you did not start with tests or write tests as
On Sat, Nov 25, 2017 at 2:33 AM, wrote:
> hi all
>
> i've just finished my first excursion into artificial intelligence with a
> game less trivial than tictactoe, and here it is in case anybody can offer
> criticism/suggestions/etc
>
Hi!
You don't have a lot of
85 matches
Mail list logo