[Tutor] What's going on?

[Ed Connell]

Thanks to all.

I'll try your suggestions.

Ed Connell

On Mon, May 1, 2023 at 9:41 AM Ed Connell <edwinconnell at gmail.com> wrote:

> Thanks to all.  You have given me some new ideas about things to try.
> Of course
>
> On Sun, Apr 30, 2023 at 9:44 PM ThreeBlindQuarks <
> threesomequarks at proton.me> wrote:
>
>>
>>
>> I looked at your message again Ed and I see you ran the program several
>> ways including just running the .py file on windows.
>>
>> So my suggestion is to use whatever command line program you have,
>> including those that let you redirect output to a file like the bash we
>> bashed a few days ago. I tested the default shell on Windows of CMD like so:
>>
>> C:\Users\xyz>echo "hi"
>> "hi"
>>
>> C:\Users\xyz>echo "hi" >temp.txt
>>
>> C:\Users\xyz>more temp.txt
>> "hi"
>>
>> So it allows redirection and if you run python as in:
>>
>> python file >temp.txt
>>
>> Or something similar, and view it with a pager like I did that shows only
>> a screen at a time, or you can use a text editor. Ideally, all the output
>> will get captured as file I/O may not be as delicate as whatever comes to
>> your screen. I have never had such a problem when I run python with output
>> in RSTUDIO, idle, Jupyter Notebook and so on.
>>
>> If that works, great.
>>
>> And, of course, with a bit of work, you can change the internals of your
>> code to slow down the output, redirect file descriptors for stdout, or just
>> have it pause and ask what to do next.
>>
>> Your program seems to work and is logically sound.
>>
>>
>> Sent with Proton Mail secure email.
>>
>> ------- Original Message -------
>> On Sunday, April 30th, 2023 at 10:32 PM, ThreeBlindQuarks <
>> threesomequarks at proton.me> wrote:
>>
>>
>> > Ed,
>> >
>> > Thank you for supplying code that works and is brief enough to try.
>> >
>> > My only glitch was one of your comments lines that became two lines
>> which resulted in an error easy to fix so it did not try to "trip".
>> >
>> > I got lots of output but as I understand it, you simply wanted to do
>> something N==10 times. You could have encapsulated all the calculations in
>> a function which would cleanly have avoided some issues of your reusing
>> variables.
>> >
>> > So you initialize these each time:
>> >
>> > res = []
>> > nums = []
>> > ct = []
>> >
>> > Your next code segment seems to re-populate some of these variables
>> >
>> >
>> > I get this when I examine variables at the end:
>> >
>> > ct: [0, 0, 0, 0, 0, 0, 0, 0, 0, 0]
>> > nums: [0, 1, 2, 3, 4, 5, 6, 7, 8, 9]
>> >
>> > which makes me wonder if this method is one that could be done
>> differently in perhaps a more Pythonic way. You do this:
>> >
>> > for i in range(10):
>> > ct.append(0)
>> > nums.append(i)
>> >
>> > No error here but consider you are asking for a group of N zeros in a
>> row for the first and a sequence from 0 to N-1 for the second.
>> >
>> > I personally might have combined all the beginning code into these
>> three lines:
>> >
>> > N = 10
>> > res = []
>> > nums = list(range(N))
>> > ct = [0] * N
>> >
>> > Again, nothing wrong with your code so far. Just an alternate viewpoint
>> and note I set a parameter called N to make the code flexible if changed at
>> a single point.
>> >
>> > This removes an explicit loop and replaces it with two hidden implicit
>> loops, albeit perhaps implemented faster internally.
>> >
>> > I am not clear on why you have commented out code about sleeping. It is
>> hinting at something. Is there some concern you did not share? I am not
>> aware any pause is needed unless you want results not to flow off the
>> screen.
>> >
>> > Again, just to show an alternative perspective, you can insert a line
>> of code like this:
>> >
>> > _ = input("Press RETURN to see next results:")
>> >
>> > This stops processing after displaying a prompt and waits for the user
>> to hit any keys and a return (and effectively ignores that) before
>> continuing. Again, not really needed as you can often just scroll up in the
>> output and see quite a bit.
>> >
>> > Now I recall the earlier request was to pick random numbers and never
>> use any one more than four times. I am not sure if your code plans on
>> anything like variations of that. Your next section hard-codes in precisely
>> thirty times in a loop that you shuffle the numbers (initially from 0 to 9)
>> in place and then you pick just the first and append that to res for an
>> eventual result.
>> >
>> > random.shuffle(nums)
>> > res.append(nums[0])
>> > print(res)
>> >
>> > That seems like a bit of extra work to shuffle the whole thing over and
>> over just to get one at random. What is the advantage over just picking a
>> random number from 0 to 9 each time rather than picking lots of them to
>> re-arrange the deck chairs on the Titanic? But, FWIW, it does get you a
>> random number to add to the growing collection.
>> >
>> > The next section explains this odd choice as the list to choose from
>> changes dynamically:
>> >
>> > if ct[nums[0]] == 4:
>> > print( 'Removing', nums[0],nums )
>> > nums = nums[1:]
>> > print('leaving', nums )
>> >
>> > This may have been your problem so I checked. The logic is that once
>> you have used a number four times, remove it and shrink the pool of
>> available to choose from to 9 then later 8 and so on. Is that carried out
>> carefully? You are removing the zeroth item by making a copy of the rest of
>> the list. I would consider an alternate of:
>> >
>> > nums.pop(0)
>> >
>> > Which throws away the first and changes the list in place. Note it can
>> also be used to just remove the nth. So if you just picked a random number
>> from zero to the current length of the list, I am guessing it might be
>> easier to just remove any that reached 4 and never scramble an entire list.
>> >
>> > The rest of the loop is just print statements.
>> >
>> > So logically, what should happen in the inner loop? Thirty numbers
>> should be chosen first from 10 possibilities so res should keep growing and
>> stop at 30 entries. The ct variable always remains at length 10 with
>> entries rising from 0 towards 4 and never exceeding it. The nums list
>> should shrink and above 40 should disappear and perhaps cause problems
>> beyond that as there is nothing to scramble and use. At 30, it should be
>> safe. But ideally, your algorithm should break out of a loop if everything
>> has hit 4, or alternately if the number of items to choose from reaches
>> zero.
>> >
>> > So I ran the code and I am embarrassed to say I did not see anything
>> wrong. It seems to do exactly what it is designed to do. My guess is you
>> are using something that cannot keep up with the I/O and produces glitches
>> on your screen. The fact that it happens after the first run may be a clue
>> that some buffer is being over-run or something.
>> >
>> > So, yes, your sleep attempts make some sense but you may also consider
>> redirecting the output to a file in one of many ways and then viewing the
>> file with something like a text editor and seeing if that looks like you
>> expect.
>> >
>> > If so, there is nothing wrong with your program but something not quite
>> great about some aspect of your environment.
>> >
>> > Anyone else try to run this and get an odd output?
>> >
>> > Q
>> >
>> >
>> >
>> >
>> >
>> >
>> > Sent with Proton Mail secure email.
>> >
>> >
>> > ------- Original Message -------
>> > On Sunday, April 30th, 2023 at 5:31 PM, Ed Connell
>> edwinconnell at gmail.com wrote:
>> >
>> >
>> >
>> > > Greetings,
>> > >
>> > > I got interested in one of your earlier problems, but THAT PROBLEM is
>> not
>> > > what I am asking about. It was to generate a random sequence, each
>> taken
>> > > from a predefined pool. However, nothing is to be used more than four
>> > > times. Moderately interesting.
>> > >
>> > > What I am asking about is this. The first time it runs perfectly.
>> However
>> > > subsequent runs, sooner or later, foul up.
>> > > ###############################
>> > > import random
>> > > import time
>> > >
>> > > for run in range(10): #usually 1 but trying multiple runs through in
>> one
>> > > trip.
>> > >
>> > > # build result, number choices, and choice count lists
>> > > res = []
>> > > nums = []
>> > > ct = []
>> > >
>> > > for i in range(10):
>> > > ct.append(0)
>> > > nums.append(i)
>> > >
>> > > print('\n\n', run, ' start\n')
>> > >
>> > > #time.sleep(0.016) # seems to work for 0.016 or more uncommented
>> > >
>> > > for _ in range( 30 ): # tried 10 - 40
>> > > random.shuffle(nums)
>> > > res.append(nums[0])
>> > > print(res)
>> > > ct[nums[0]] += 1
>> > > if ct[nums[0]] == 4:
>> > > print( 'Removing', nums[0],nums )
>> > > nums = nums[1:]
>> > > print('leaving', nums )
>> > >
>> > > print()
>> > > print('numbers left',sorted(nums))
>> > > print('result',res)
>> > > print('number used of each',ct)
>> > > ####################################
>> > > The problem seems to be a difference between printing and calculation
>> speed
>> > > but maybe not.
>> > >
>> > > I tried mostly using Geany, but also just ran the .py file.
>> > >
>> > > The bad output has incomplete lines as well as missing sections.
>> > >
>> > > I will appreciate your ideas.
>> > >
>> > > Oh, I am running on Windows 11, an hp with AMD 7.
>> > >
>> > > Ed Connll
>> > > --
>> > > I have a right and a left brain, but there is nothing right in the
>> left one
>> > > and there is nothing left in the right one!
>> > > _______________________________________________
>> > > Tutor maillist - Tutor at python.org
>> > > To unsubscribe or change subscription options:
>> > > https://mail.python.org/mailman/listinfo/tutor
>>
>
>
> --
> I have a right and a left brain, but there is nothing right in the left
> one and there is nothing left in the right one!
>
>

-- 
I have a right and a left brain, but there is nothing right in the left one
and there is nothing left in the right one!