no doubt tho after playing with this is that enumerate value ends up in the
output which is a dictionary. The enumerate has no key which makes it invalid
json if dumped.
Not massive issue but getting the effect of enumerate without polluting output
would be the winner.
>runner_lists = {}
On 04Nov2017 17:43, Sayth Renshaw wrote:
figured it. Needed to use n to iterate when creating.
Yeah, my mistake.
runner_lists = {}
for n, item in enumerate(result):
# if this one is interested / not -filtered:
print(n, item)
runner_lists[n] = result[n]["RacingFormGuid
Sorry
figured it. Needed to use n to iterate when creating.
runner_lists = {}
for n, item in enumerate(result):
# if this one is interested / not -filtered:
print(n, item)
runner_lists[n] = result[n]["RacingFormGuide"]["Event"]["Runners"]
Sayth
--
https://mail.python
> I'd just keep the interesting runners, along with their race numbers, in a
> dict. The enumerate function is handy here. Something like (untested):
>
> runner_lists = {}
> for n, item in enumerate(result):
> if this one is interested/not-filtered:
> runner_lists[n] = result["Raci
On Sunday, 5 November 2017 09:53:37 UTC+11, Cameron Simpson wrote:
> >I want to get a result from a largish json api. One section of the json
> >structure returns lists of data. I am wanting to get each resulting list
> >returned.
> >
> >This is my code.
> >import json
> >from pprint import ppr
On 04Nov2017 14:01, Sayth Renshaw wrote:
I want to get a result from a largish json api. One section of the json
structure returns lists of data. I am wanting to get each resulting list
returned.
This is my code.
import json
from pprint import pprint
with open(r'/home/sayth/Projects/results/
On Wed, 11 Oct 2017 10:57 pm, Stefan Ram wrote:
> FWIW, in is book "Touch of Class" (2009) Bertrand Meyer writes:
>
> |Such instructions are just the old goto in sheep's clothing.
> |Treat them the same way as the original:
> |
> |/Touch of Methodology/:
> | Sticking to one-entry, one-exit build
Chris Angelico writes:
> while True:
> c = sys.stdin.read(1)
> if not c: break
> if c.isprintable(): text += c
> elif c == "\x08": text = text[:-1]
> # etc
> Can you write _that_ as a do-while?
I prefer to write that sort of thing with iterators:
for c in iter(lambda: sys.st
Op 16-04-17 om 19:07 schreef Terry Reedy:
> On 4/16/2017 11:35 AM, Michael Torrie wrote:
>> On 04/16/2017 07:57 AM, bartc wrote:
>>> But people just don't want it.
>>>
>>> /That/ is what surprises me, when people reject things that to me are
>>> no-brainers.
>
> Whereas to me, it is a no-brainer th
Ben Bacarisse wrote:
I fond the proportion on while True: loops surprising. Is there
something about Python that encourages that kind of loop?
Maybe because for-loops take care of most of the ordinary
cases in Python, leaving while-loops to cover the weird
ones, many of which need one or more
Christian Gollwitzer writes:
> Am 18.04.17 um 08:21 schrieb Chris Angelico:
>> On Tue, Apr 18, 2017 at 4:06 PM, Christian Gollwitzer
>> wrote:
>>> Am 18.04.17 um 02:18 schrieb Ben Bacarisse:
>>>
Thanks (and to Grant). IO seems to be the canonical example. Where
some languages would f
Am 18.04.17 um 08:21 schrieb Chris Angelico:
On Tue, Apr 18, 2017 at 4:06 PM, Christian Gollwitzer wrote:
Am 18.04.17 um 02:18 schrieb Ben Bacarisse:
Thanks (and to Grant). IO seems to be the canonical example. Where
some languages would force one to write
c = sys.stdin.read(1)
while c
Christian Gollwitzer :
> Am 18.04.17 um 02:18 schrieb Ben Bacarisse:
>> Python opts for
>>
>> while True:
>> c = sys.stdin.read(1)
>> if c != ' ': break
>
> This loop would be the archetypical do..while or repeat...until to me.
>
> do
> c = sys.stdin.read(1)
> while c== ' '
No,
On Tue, Apr 18, 2017 at 4:06 PM, Christian Gollwitzer wrote:
> Am 18.04.17 um 02:18 schrieb Ben Bacarisse:
>
>> Thanks (and to Grant). IO seems to be the canonical example. Where
>> some languages would force one to write
>>
>> c = sys.stdin.read(1)
>> while c == ' ':
>> c = sys.stdin.
Am 18.04.17 um 02:18 schrieb Ben Bacarisse:
Thanks (and to Grant). IO seems to be the canonical example. Where
some languages would force one to write
c = sys.stdin.read(1)
while c == ' ':
c = sys.stdin.read(1)
Python opts for
while True:
c = sys.stdin.read(1)
if c !=
On Tuesday, April 18, 2017 at 2:09:19 AM UTC+1, Paul Rubin wrote:
> Ben Bacarisse writes:
> > ? I get "AttributeError: 'itertools.dropwhile' object has no attribute
> > 'next'" from your example.
>
> Hmm, .next() worked ok for me in Python 2.7.5. Not sure what happened.
> Maybe something went wr
Ben Bacarisse :
> Python opts for
>
> while True:
> c = sys.stdin.read(1)
> if c != ' ': break
I opt for that in C and bash as well.
In fact, when I start writing a loop, I first type:
while True:
Once it is done, I might notice that the loop begins:
while True:
Gregory Ewing :
> Marko Rauhamaa wrote:
>> What I notice in my numbers is that about one half of my while loops
>> are "while True", and about a third of my loops are while loops.
>
> Out of curiosity, what proportion of your 'while True' loops are
> infinite? (I.e. no break, return or raise in th
On Tue, Apr 18, 2017 at 1:37 AM, MRAB wrote:
> In Python 3 it's:
>
> c = next(itertools.dropwhile(
> lambda c: c==' ',
> iter(lambda: sys.stdin.read(1),None)
> ))
iter's sentinel should be an empty string.
--
https://mail.python.org/mailman/listinfo/python-list
On 2017-04-18 02:09, Paul Rubin wrote:
Ben Bacarisse writes:
? I get "AttributeError: 'itertools.dropwhile' object has no attribute
'next'" from your example.
Hmm, .next() worked ok for me in Python 2.7.5. Not sure what happened.
Maybe something went wrong with my paste. Oh well.
Coming
Ben Bacarisse writes:
> ? I get "AttributeError: 'itertools.dropwhile' object has no attribute
> 'next'" from your example.
Hmm, .next() worked ok for me in Python 2.7.5. Not sure what happened.
Maybe something went wrong with my paste. Oh well.
> Coming from the lazy language Haskell, I find
Paul Rubin writes:
> Ben Bacarisse writes:
>> c = sys.stdin.read(1)
>> while c == ' ':
>> c = sys.stdin.read(1)
(for the record: I was not suggesting this was how you'd do it but how
you'd be forced to do it in some languages)
> c = itertools.dropwhile(
> lambda c: c==' ',
>
On 18/04/2017 01:23, Paul Rubin wrote:
Ben Bacarisse writes:
c = sys.stdin.read(1)
while c == ' ':
c = sys.stdin.read(1)
c = itertools.dropwhile(
lambda c: c==' ',
iter(lambda: sys.stdin.read(1),None)
).next()
I tried this but it doesn't like the .next.
I wanted t
Marko Rauhamaa writes:
> Ben Bacarisse :
>
>> Marko Rauhamaa writes:
>>> What I notice in my numbers is that about one half of my while loops
>>> are "while True", and about a third of my loops are while loops.
>>
>> I fo[u]nd the proportion on while True: loops surprising. Is there
>> something
Ben Bacarisse writes:
> c = sys.stdin.read(1)
> while c == ' ':
> c = sys.stdin.read(1)
c = itertools.dropwhile(
lambda c: c==' ',
iter(lambda: sys.stdin.read(1),None)
).next()
--
https://mail.python.org/mailman/listinfo/python-list
Marko Rauhamaa wrote:
What I notice in my numbers is that about one half of my while loops are
"while True", and about a third of my loops are while loops.
Out of curiosity, what proportion of your 'while True' loops
are infinite? (I.e. no break, return or raise in the loop.)
--
Greg
--
https:
On 2017-04-17, Ben Bacarisse wrote:
> Marko Rauhamaa writes:
>
>> Terry Reedy :
>>
>>> On 4/17/2017 3:11 AM, Marko Rauhamaa wrote:
Here's statistics from a medium-sized project of mine:
while True:34
while : 39
for ... in ...: 158
>>>
>>> As
On 17 April 2017 at 04:00, Steve D'Aprano wrote:
> On Mon, 17 Apr 2017 05:49 am, Dennis Lee Bieber wrote:
>
>> On Mon, 17 Apr 2017 02:48:08 +1000, Steve D'Aprano
>> declaimed the following:
>>
>>>On Sun, 16 Apr 2017 11:57 pm, bartc wrote:
>>>
But people just don't want it.
>>>
>>>Damn straig
Ben Bacarisse :
> Marko Rauhamaa writes:
>> What I notice in my numbers is that about one half of my while loops
>> are "while True", and about a third of my loops are while loops.
>
> I fo[u]nd the proportion on while True: loops surprising. Is there
> something about Python that encourages that
On 17/04/2017 19:02, Ben Bacarisse wrote:
Marko Rauhamaa writes:
Terry Reedy :
On 4/17/2017 3:11 AM, Marko Rauhamaa wrote:
Here's statistics from a medium-sized project of mine:
while True:34
while : 39
for ... in ...: 158
As I posted previously, the ratio
Marko Rauhamaa writes:
> Terry Reedy :
>
>> On 4/17/2017 3:11 AM, Marko Rauhamaa wrote:
>>> Here's statistics from a medium-sized project of mine:
>>>
>>>while True:34
>>>while : 39
>>>for ... in ...: 158
>>
>> As I posted previously, the ratio of for-loops in th
Terry Reedy :
> On 4/17/2017 3:11 AM, Marko Rauhamaa wrote:
>> Here's statistics from a medium-sized project of mine:
>>
>>while True:34
>>while : 39
>>for ... in ...: 158
>
> As I posted previously, the ratio of for-loops in the stdlib is about 7
> to 1.
What I
On 4/17/2017 3:11 AM, Marko Rauhamaa wrote:
Gregory Ewing :
bartc wrote:
Most of my loops start off as endless loops, until I can determine
the actual terminating condition, and where it best goes.
Interesting. My experience is quite different. Most of the loops I
write start off with me thi
Gregory Ewing :
> bartc wrote:
>> Most of my loops start off as endless loops, until I can determine
>> the actual terminating condition, and where it best goes.
>
> Interesting. My experience is quite different. Most of the loops I
> write start off with me thinking "Now I want to do this for eac
On Mon, 17 Apr 2017 05:49 am, Dennis Lee Bieber wrote:
> On Mon, 17 Apr 2017 02:48:08 +1000, Steve D'Aprano
> declaimed the following:
>
>>On Sun, 16 Apr 2017 11:57 pm, bartc wrote:
>>
>>> But people just don't want it.
>>
>>Damn straight. Now you get it. It's not about how easy it is to impleme
bartc wrote:
> - describing the various syntax forms;
> - explaining how they differ;
> - tutorials for beginners showing each form;
And you don't have to explain how an endless loop should be written as
'while True', meanwhile advising against using 'while 1'?
You don't have to mention i
On 16/04/2017 19:42, Chris Angelico wrote:
On Mon, Apr 17, 2017 at 4:21 AM, bartc wrote:
Here is a function from some old CPython source that appears to be something
to do with While statements:
static int
validate_while(node *tree)
{
...
Look, no comments! Are you going to castigate the dev
On Mon, Apr 17, 2017 at 4:21 AM, bartc wrote:
> Here is a function from some old CPython source that appears to be something
> to do with While statements:
>
> static int
> validate_while(node *tree)
> {
> int nch = NCH(tree);
> int res = (validate_ntype(tree, while_stmt)
>
On 16/04/2017 17:30, Steve D'Aprano wrote:
On Sun, 16 Apr 2017 10:06 pm, bartc wrote:
(The 30 Loc figure is with support for loops /in
general/ already in place, and is for /adding/ a new loop statement, in
this case 'while')
What part of *testing* and *documenting* do you not understand?
On Mon, 17 Apr 2017 03:00 am, Rustom Mody wrote:
> BTW I regard Steven's long list of things that youve missed such as
> regression tests, docs etc to be somewhat off the mark
> To see that try this experiment:
> Just add a feature to python that matters to you along with all these
> requirements
On 4/16/2017 11:35 AM, Michael Torrie wrote:
On 04/16/2017 07:57 AM, bartc wrote:
But people just don't want it.
/That/ is what surprises me, when people reject things that to me are
no-brainers.
Whereas to me, it is a no-brainer that we are better off *without*
multiple while/loop construct
On Sunday, April 16, 2017 at 7:27:49 PM UTC+5:30, bartc wrote:
> Technically, adding this one feature to Python /is/ trivial,
^
You are not paying attention bart and I am not likely to pursue this beyond this
post. I tried to say as are others that the substantive reasons to reject a
On Sun, 16 Apr 2017 11:57 pm, bartc wrote:
> Yet countless other, far more elaborate features /are/ added all the time.
Indeed. Because they are needed. Because they add functionality that Python
doesn't already have, or seriously improves the interface to that
functionality.
> Technically, add
On Sun, 16 Apr 2017 10:06 pm, bartc wrote:
> On 16/04/2017 03:51, Steve D'Aprano wrote:
>> On Sat, 15 Apr 2017 10:17 pm, bartc wrote:
>
>>> Yes, I'm constantly surprised at this, as such syntax has a very low
>>> cost (in my last compiler, supporting 'while' for example only added 30
>>> lines to
On 16/04/2017 15:22, Chris Angelico wrote:
On Sun, Apr 16, 2017 at 11:57 PM, bartc wrote:
Technically, adding this one feature to Python /is/ trivial, for example,
allowing while: as a synonym for while True:, but preferably using a new
keyword such as loop. Nothing else needs to be touched. An
On 04/16/2017 07:57 AM, bartc wrote:
> But people just don't want it.
>
> /That/ is what surprises me, when people reject things that to me are
> no-brainers.
I simply don't care about these missing loop constructs. Python works
great for what I use it for, and apparently works well for many pe
On Sun, Apr 16, 2017 at 11:57 PM, bartc wrote:
> Technically, adding this one feature to Python /is/ trivial, for example,
> allowing while: as a synonym for while True:, but preferably using a new
> keyword such as loop. Nothing else needs to be touched. And it could have
> been done right at the
On 16/04/2017 13:22, Rustom Mody wrote:
On Sunday, April 16, 2017 at 5:36:28 PM UTC+5:30, bartc wrote:
On 16/04/2017 03:51, Steve D'Aprano wrote:
On Sat, 15 Apr 2017 10:17 pm, bartc wrote:
Yes, I'm constantly surprised at this, as such syntax has a very low
cost (in my last compiler, support
On Sunday, April 16, 2017 at 5:36:28 PM UTC+5:30, bartc wrote:
> On 16/04/2017 03:51, Steve D'Aprano wrote:
> > On Sat, 15 Apr 2017 10:17 pm, bartc wrote:
>
> >> Yes, I'm constantly surprised at this, as such syntax has a very low
> >> cost (in my last compiler, supporting 'while' for example only
On 16/04/2017 03:51, Steve D'Aprano wrote:
On Sat, 15 Apr 2017 10:17 pm, bartc wrote:
Yes, I'm constantly surprised at this, as such syntax has a very low
cost (in my last compiler, supporting 'while' for example only added 30
lines to the project).
That's the advantage of writing your own p
Steve D'Aprano writes:
> I don't remember the language, but I remember seeing one generalisation of
> the repeat/do loop that puts the test in the middle, rather than at the
> start or end of the loop. If I remember it was something like:
>
> DO
> setup code # executed once only
> REPEAT
>
On 10 March 2016 at 13:02, Peter Otten <__pete...@web.de> wrote:
> Heli wrote:
>
>> I need to loop over a numpy array and then do the following search. The
>> following is taking almost 60(s) for an array (npArray1 and npArray2 in
>> the example below) with around 300K values.
>>
>>
>> for id in np
problem is infact not related to numpy at all. the complexity of your
algorithm is O(len(npArray1) * len(npArray2))
which means the number of computations that you are doing is in the range
of 10**10,
if the absolute difference between the maximum element and minimum element
is less than 10**6, y
> From: sjeik_ap...@hotmail.com
> To: heml...@gmail.com; python-list@python.org
> Subject: RE: looping and searching in numpy array
> Date: Sun, 13 Mar 2016 13:51:23 +
>
> Hi, I suppose you have seen this already (in particular the first link):
> http://nump
> Date: Thu, 10 Mar 2016 08:48:48 -0800
> Subject: Re: looping and searching in numpy array
> From: heml...@gmail.com
> To: python-list@python.org
>
> On Thursday, March 10, 2016 at 2:02:57 PM UTC+1, Peter Otten wrote:
> > Heli wrote:
> >
> > > Dear
On Thursday, March 10, 2016 at 5:49:07 PM UTC+1, Heli wrote:
> On Thursday, March 10, 2016 at 2:02:57 PM UTC+1, Peter Otten wrote:
> > Heli wrote:
> >
> > > Dear all,
> > >
> > > I need to loop over a numpy array and then do the following search. The
> > > following is taking almost 60(s) for an
On Thursday, March 10, 2016 at 2:02:57 PM UTC+1, Peter Otten wrote:
> Heli wrote:
>
> > Dear all,
> >
> > I need to loop over a numpy array and then do the following search. The
> > following is taking almost 60(s) for an array (npArray1 and npArray2 in
> > the example below) with around 300K val
On 10/03/2016 11:43, Heli wrote:
Dear all,
I need to loop over a numpy array and then do the following search. The
following is taking almost 60(s) for an array (npArray1 and npArray2 in the
example below) with around 300K values.
for id in np.nditer(npArray1):
newId=(np.where(npArr
Heli wrote:
> Dear all,
>
> I need to loop over a numpy array and then do the following search. The
> following is taking almost 60(s) for an array (npArray1 and npArray2 in
> the example below) with around 300K values.
>
>
> for id in np.nditer(npArray1):
>
>newId=(n
In article <5109fe6b$0$11104$c3e8...@news.astraweb.com>,
Steven D'Aprano wrote:
> On Thu, 31 Jan 2013 02:49:31 +1100, Chris Angelico wrote:
>
> > it's worth
> > noting that list appending is not going to be O(N*N), because it's going
> > to allow room for expansion.
>
> This is true for list.a
On Thu, 31 Jan 2013 02:49:31 +1100, Chris Angelico wrote:
> it's worth
> noting that list appending is not going to be O(N*N), because it's going
> to allow room for expansion.
This is true for list.append, which is amortized constant time. But it is
not true for list addition, alist + blist, wh
On 30/01/2013 15:49, Chris Angelico wrote:
On Thu, Jan 31, 2013 at 1:58 AM, Robin Becker wrote:
however, when I tried an experiment in python 2.7 using the script below I
find that the looping algorithms perform better. A naive loop using list +=
list would appear to be an O(n**2) operation, bu
On Thu, Jan 31, 2013 at 1:58 AM, Robin Becker wrote:
> however, when I tried an experiment in python 2.7 using the script below I
> find that the looping algorithms perform better. A naive loop using list +=
> list would appear to be an O(n**2) operation, but python seems to be doing
> better than
On 2012-09-21 00:35, giuseppe.amatu...@gmail.com wrote:
Hi Ian and MRAB
thanks to you input i have improve the speed of my code. Definitely reading in
dic() is faster. I have one more question.
In the dic() I calculate the sum of the values, but i want count also the
number of observation, in
Hi Ian and MRAB
thanks to you input i have improve the speed of my code. Definitely reading in
dic() is faster. I have one more question.
In the dic() I calculate the sum of the values, but i want count also the
number of observation, in order to calculate the average in the end.
Should i creat
On Thu, Sep 20, 2012 at 1:28 PM, Ian Kelly wrote:
> Expanding on what MRAB wrote, since you probably have far fewer
> categories than pixels, you may be able to take better advantage of
> numpy's vectorized operations (which are pretty much the whole point
> of using numpy in the first place) by l
On Thu, Sep 20, 2012 at 1:09 PM, MRAB wrote:
> for col in range(cols):
> for row in range(rows):
> cat = valuesCategory[row, col]
> ras = valuesRaster[row, col]
> totals[cat] += ras
Expanding on what MRAB wrote, since you probably have far fewer
categories than pixels,
On 2012-09-20 19:31, giuseppe.amatu...@gmail.com wrote:
Hi,
I have this script in python that i need to apply for very large arrays (arrays
coming from satellite images).
The script works grate but i would like to speed up the process.
The larger computational time is in the for loop process.
Is
On Nov 10, 4:14 pm, James Mills wrote:
> On Thu, Nov 11, 2010 at 8:46 AM, Matty Sarro wrote:
> > Short story - I have a few thousand files in a directory I need to parse
> > through. Is there a simple way to loop through files? I'd like to avoid
> > writing a python script that can parse 1 file,
On 11/11/10 06:23, Chris Rebert wrote:
On Wed, Nov 10, 2010 at 10:11 PM, r0g wrote:
On 11/11/10 00:17, Steve Holden wrote:
On 11/10/2010 5:46 PM, Matty Sarro wrote:
Short story - I have a few thousand files in a directory I need to parse
through. Is there a simple way to loop through files?
On Wed, Nov 10, 2010 at 10:11 PM, r0g wrote:
> On 11/11/10 00:17, Steve Holden wrote:
>> On 11/10/2010 5:46 PM, Matty Sarro wrote:
>>>
>>> Short story - I have a few thousand files in a directory I need to parse
>>> through. Is there a simple way to loop through files? I'd like to avoid
>>> writin
On 11/11/10 00:17, Steve Holden wrote:
On 11/10/2010 5:46 PM, Matty Sarro wrote:
Short story - I have a few thousand files in a directory I need to parse
through. Is there a simple way to loop through files? I'd like to avoid
writing a python script that can parse 1 file, and have to call it a f
On 11/10/10 16:46, Matty Sarro wrote:
Short story - I have a few thousand files in a directory I
need to parse through. Is there a simple way to loop through
files? I'd like to avoid writing a python script that can
parse 1 file, and have to call it a few thousand times from a
bash script. Any in
On 11/10/2010 2:46 PM Matty Sarro said...
Short story - I have a few thousand files in a directory I need to parse
through. Is there a simple way to loop through files? I'd like to avoid
writing a python script that can parse 1 file, and have to call it a few
thousand times from a bash script. An
On Wed, Nov 10, 2010 at 2:46 PM, Matty Sarro wrote:
> Short story - I have a few thousand files in a directory I need to parse
> through. Is there a simple way to loop through files? I'd like to avoid
> writing a python script that can parse 1 file, and have to call it a few
> thousand times from
On 11/10/2010 5:46 PM, Matty Sarro wrote:
> Short story - I have a few thousand files in a directory I need to parse
> through. Is there a simple way to loop through files? I'd like to avoid
> writing a python script that can parse 1 file, and have to call it a few
> thousand times from a bash scri
On Thu, Nov 11, 2010 at 8:46 AM, Matty Sarro wrote:
> Short story - I have a few thousand files in a directory I need to parse
> through. Is there a simple way to loop through files? I'd like to avoid
> writing a python script that can parse 1 file, and have to call it a few
> thousand times from
On Aug 18, 11:50 am, John Posner wrote:
> On 8/18/2010 1:38 PM, cbr...@cbrownsystems.com wrote:
>
> >>> To go the other way, if d = 1, then there exists integers (not
> >>> neccessarily positive) such that
>
> >>> a*x + b*y + c*z = 1
>
> That fact is non-trivial, although the proof isn't *too* har
On 8/18/2010 1:38 PM, cbr...@cbrownsystems.com wrote:
To go the other way, if d = 1, then there exists integers (not
neccessarily positive) such that
a*x + b*y + c*z = 1
That fact is non-trivial, although the proof isn't *too* hard [1]. I
found it interesting to demonstrate the simpler cas
On Aug 18, 10:52 am, Baba wrote:
> Hi Chas
>
> Thanks for that and i agree on your last remark :)
>
> re the number of required consecutive passes required:
>
> The number of required consecutive passes is equal to the smallest
> number because after that you can get any amount of nuggets by just
Hi Chas
Thanks for that and i agree on your last remark :)
re the number of required consecutive passes required:
The number of required consecutive passes is equal to the smallest
number because after that you can get any amount of nuggets by just
adding the smallest nugget pack to some other n
On Aug 17, 2:44 pm, Baba wrote:
> On Aug 16, 6:28 pm, "cbr...@cbrownsystems.com"
>
> wrote:
> > First, suppose d = gcd(x, y, z); then for some x', y', z' we have that
> > x = d*x', y = d*y', z = d*z'; and so for any a, b, c:
>
> could you explain the notation?
>
> what is the difference btw
On 08/17/2010 11:44 PM, Baba wrote:
> On Aug 16, 6:28 pm, "cbr...@cbrownsystems.com"
> wrote:
>
>> First, suppose d = gcd(x, y, z); then for some x', y', z' we have that
>> x = d*x', y = d*y', z = d*z'; and so for any a, b, c:
>>
>
>
>could you explain the notation?
>
>what is the diff
On Aug 16, 6:28 pm, "cbr...@cbrownsystems.com"
wrote:
> First, suppose d = gcd(x, y, z); then for some x', y', z' we have that
> x = d*x', y = d*y', z = d*z'; and so for any a, b, c:
>
could you explain the notation?
what is the difference btw x and x' ?
what is x = d*x', y supposed
Paul Rubin writes:
> Baba writes:
>> exercise: given that packs of McNuggets can only be bought in 6, 9 or
>> 20 packs, write an exhaustive search to find the largest number of
>> McNuggets that cannot be bought in exact quantity.
>
> Is that a homework problem?
yes, and no
it was a homework p
On Aug 16, 11:04 am, Baba wrote:
> Hi Chas, Roald,
>
> These are all complicated formula that i believe are not expected at
> this level. If you look at the source (see my first submission) you
> will see that this exercise is only the second in a series called
> "Introduction to Programming". The
On 8/16/2010 4:18 PM, Baba wrote:
packages=[2,103,105]
min_size=min(packages[0],packages[1],packages[2])
or:
min_size = min(packages)
-John
--
http://mail.python.org/mailman/listinfo/python-list
well i still believe that the key is the smallest sized pack and
there's no need to go into higher mathematics to solve this problem.
I think below code works within the limits of the exercise which
states to look at a maximum range of 200 in order not to search
forever.
packages=[2,103,105]
min_s
Baba writes:
> Hi Mel,
>
> indeed i thought of generalising the theorem as follows:
> If it is possible to buy n, n+1,~, n+(x-1) sets of McNuggets, for some
> x, then it is possible to buy any number of McNuggets >= x, given that
> McNuggets come in x, y and z packs.
>
> so with diophantine_nugge
Baba wrote:
[ ... ]
> Now, i believe that the number of consecutive passes required to make
> this work is equal to the smallest number of pack sizes. So if we have
> packs of (9,12,21) the number of passes needed would be 9 and the
> theorem would read
>
> "If it is possible to buy n,n+1,n+2,...n
Hi Chas, Roald,
These are all complicated formula that i believe are not expected at
this level. If you look at the source (see my first submission) you
will see that this exercise is only the second in a series called
"Introduction to Programming". Therefore i am convinced that there is
a much si
On Mon, Aug 16, 2010 at 12:43 PM, Roald de Vries wrote:
>>> I'm pretty sure that if there's no common divisor for all three (or more)
>>> packages (except one), there is a largest unpurchasable quantity. That
>>> is: ∀
>>> i>1: ¬(i|a) ∨ ¬(i|b) ∨ ¬(i|c), where ¬(x|y) means "x is no divider of y"
>>
On Aug 16, 1:23 am, Roald de Vries wrote:
> On Aug 15, 2010, at 11:51 PM, Ian Kelly wrote:
>
>
>
> > On Sun, Aug 15, 2010 at 4:36 PM, Baba wrote:
> >> Hi Mel,
>
> >> indeed i thought of generalising the theorem as follows:
> >> If it is possible to buy n, n+1,…, n+(x-1) sets of McNuggets, for
>
On Aug 16, 2010, at 5:04 PM, Ian Kelly wrote:
On Mon, Aug 16, 2010 at 4:23 AM, Roald de Vries
wrote:
I suspect that there exists a largest unpurchasable quantity iff at
least two of the pack quantities are relatively prime, but I have
made
no attempt to prove this.
That for sure is not co
On Mon, Aug 16, 2010 at 11:04 AM, Ian Kelly wrote:
> On Mon, Aug 16, 2010 at 4:23 AM, Roald de Vries wrote:
>>> I suspect that there exists a largest unpurchasable quantity iff at
>>> least two of the pack quantities are relatively prime, but I have made
>>> no attempt to prove this.
>>
>> That f
On Mon, Aug 16, 2010 at 4:23 AM, Roald de Vries wrote:
>> I suspect that there exists a largest unpurchasable quantity iff at
>> least two of the pack quantities are relatively prime, but I have made
>> no attempt to prove this.
>
> That for sure is not correct; packs of 2, 4 and 7 do have a large
On Aug 15, 2010, at 11:51 PM, Ian Kelly wrote:
On Sun, Aug 15, 2010 at 4:36 PM, Baba wrote:
Hi Mel,
indeed i thought of generalising the theorem as follows:
If it is possible to buy n, n+1,…, n+(x-1) sets of McNuggets, for
some
x, then it is possible to buy any number of McNuggets >= x, give
On Sun, Aug 15, 2010 at 4:36 PM, Baba wrote:
> Hi Mel,
>
> indeed i thought of generalising the theorem as follows:
> If it is possible to buy n, n+1,…, n+(x-1) sets of McNuggets, for some
> x, then it is possible to buy any number of McNuggets >= x, given that
> McNuggets come in x, y and z packs
Hi Mel,
indeed i thought of generalising the theorem as follows:
If it is possible to buy n, n+1,…, n+(x-1) sets of McNuggets, for some
x, then it is possible to buy any number of McNuggets >= x, given that
McNuggets come in x, y and z packs.
so with diophantine_nuggets(7,10,21) i would need 7 pa
Baba wrote:
> Hi All,
>
> @Emile tnx for spotting the mistake. Should have seen it
myself.
>
> @John & Ian i had a look around but couldn't find a general
version of
> below theorem
> If it is possible to buy x, x+1,…, x+5 sets of McNuggets,
for some x,
> then it is possible to buy any number
1 - 100 of 260 matches
Mail list logo
