dn writes:
[...]
> Further, if you look at the OP's original solution, it only publishes
> the last pair, ie the match, without mention of the list of non-matches.
> Was it perhaps only a means of testing the solution?
It was a means of showing the student that indeed they obtained a match.
If
On 11/09/2021 10:09, dn via Python-list wrote:
The stated requirement is: "I'd like to get the number of times I
tried". Given such: why bother with returning any of the pairs of values?
Indeed, if that's the requirement, then you can do even better, noting
that the probability of getting
On 2021-09-08 13:07:47 +1200, Greg Ewing wrote:
> On 8/09/21 2:53 am, Grant Edwards wrote:
> >#define IF if (
> >#define THEN ) {
> >#define ELSE } else {
> >#define ENDIF }
>
> I gather that early versions of some of the Unix utilities were
> written by someone who liked using
On 11/09/2021 18.03, Chris Angelico wrote:
> On Sat, Sep 11, 2021 at 3:26 PM dn via Python-list
> wrote:
>>
>> On 31/08/2021 01.50, Chris Angelico wrote:
>>> On Mon, Aug 30, 2021 at 11:13 PM David Raymond
>>> wrote:
> def how_many_times():
> x, y = 0, 1
> c = 0
>
On Sat, Sep 11, 2021 at 3:26 PM dn via Python-list
wrote:
>
> On 31/08/2021 01.50, Chris Angelico wrote:
> > On Mon, Aug 30, 2021 at 11:13 PM David Raymond
> > wrote:
> >>
> >>> def how_many_times():
> >>> x, y = 0, 1
> >>> c = 0
> >>> while x != y:
> >>> c = c + 1
> >>> x, y =
On 31/08/2021 01.50, Chris Angelico wrote:
> On Mon, Aug 30, 2021 at 11:13 PM David Raymond
> wrote:
>>
>>> def how_many_times():
>>> x, y = 0, 1
>>> c = 0
>>> while x != y:
>>> c = c + 1
>>> x, y = roll()
>>> return c, (x, y)
>>
>> Since I haven't seen it used in answers yet,
On Wed, 8 Sep 2021 16:32:45 - (UTC), Grant Edwards
declaimed the following:
>On 2021-09-08, Dennis Lee Bieber wrote:
>
>> I spent close to 20 years (80s-90s) maintaining the /output/ of such
>> a preprocessor.
>
>Ouch. I hope it paid well. ;)
Only if one ignores the bloody cost of
On Wed, 8 Sep 2021 14:46:28 - (UTC), Grant Edwards
declaimed the following:
>On 2021-09-08, charles hottel wrote:
>
>> So what do yoy think or feel about a language like RATFOR (Rational
>> FORTRAN) which was implemented as macros? Should they instead have
>> simply adapted themselves to
On 2021-09-08, Dennis Lee Bieber wrote:
> I spent close to 20 years (80s-90s) maintaining the /output/ of such
> a preprocessor.
Ouch. I hope it paid well. ;)
Back when I did a lot of TeX/LaTeX stuff on VMS, I used to make
occasional fixes and add (very minor) features to one of the dvi
Charles,
This forum is for python discussions so I will clarify that there is nothing
wrong with making up a new language, including by bootstrapping an old
language. But why not call it new and do not try to confuse people using the
old.
Python has grown and added much over the years and even
On Wed, 8 Sep 2021 00:24:44 +0100, Alan Gauld via Python-list
declaimed the following:
>
>That was quite common in C before it became popular(early/mid 80s).
>I've seen Pascal, Algol and Coral macro sets in use.
>You could even download pre-written ones from various
>bulletin boards (remember
On 2021-09-08, charles hottel wrote:
> So what do yoy think or feel about a language like RATFOR (Rational
> FORTRAN) which was implemented as macros?
The RATFOR implementations I've seen weren't done using macros. It was
a preprocessor, yes. But it generates code for the various structured
On 2021-09-08, charles hottel wrote:
> So what do yoy think or feel about a language like RATFOR (Rational
> FORTRAN) which was implemented as macros? Should they instead have
> simply adapted themselves to FORTRAN?
That's an interesting question. If the langauge is complete,
well-defined,
On 9/7/2021 9:20 PM, Avi Gross wrote:
Greg,
Yes, a smart person may come up with such tricks but a really smart person,
in my view, adjusts. With some exceptions, such as when trying to port
existing code to a new language quickly, someone who is not too obsessive
will try to pick up the goals
I think I already agreed with much of your point. That is indeed the
problem. You are allowed to do some possibly non-standard things. A static
evaluation/replacement may show the wrong function being called and a
dynamic one may still mess up as there are many ways to do indirection.
I mention
On 9/7/21 3:51 PM, Avi Gross via Python-list wrote:
> and similarly changes any function imported directly
> to also be fully qualified.
One danger with this is that it can actual change the behavior of the
program. Maybe more likely with global objects than functions, but still
an issue.
Greg,
Yes, a smart person may come up with such tricks but a really smart person,
in my view, adjusts. With some exceptions, such as when trying to port
existing code to a new language quickly, someone who is not too obsessive
will try to pick up the goals and spirit of a new language and use
On 8/09/21 2:53 am, Grant Edwards wrote:
#define IF if (
#define THEN ) {
#define ELSE } else {
#define ENDIF }
...
I gather that early versions of some of the Unix utilities were
written by someone who liked using macros to make C resemble Algol.
I guess you can get away with
On 07/09/2021 15:53, Grant Edwards wrote:
> I remember engineering manager I worked with about 35 years ago who
> used a set of C macros to try to make his code look as much like BASIC
> as possible:
>
> #define IF if (
> #define THEN ) {
> #define ELSE } else {
> #define ENDIF }
> ...
Although I sort of agree with Alister, I also note that many languages
deliberately provide you with the means to customize in ways that make your
personal life more amenable while making it perhaps harder for others.
Consider the humble import statement frequently used as:
import numpy as np
On Tue, 7 Sep 2021 16:08:04 +1200, Greg Ewing
declaimed the following:
>On 7/09/21 11:38 am, Avi Gross wrote:
>
>> #define INDEFINITELY_LOOP while (true)
>>
>> So, how to do something like that in python, is a challenge left to the user
>> ?
>
>def hell_frozen_over():
> return False
>
Grant Edwards writes:
> On 2021-09-06, Stefan Ram wrote:
>> "Avi Gross" writes:
>>> In languages like C/C++ there are people who make up macros like:
>>>#define INDEFINITELY_LOOP while (true)
>>>Or something like that and then allow the preprocessor to replace
>>>INDEFINITELY_LOOP with valid
On Tue, 07 Sep 2021 14:53:29 +, Grant Edwards wrote:
> On 2021-09-06, Stefan Ram wrote:
>> "Avi Gross" writes:
>>> In languages like C/C++ there are people who make up macros like:
>>>#define INDEFINITELY_LOOP while (true)
>>>Or something like that and then allow the preprocessor to replace
On 2021-09-06, Stefan Ram wrote:
> "Avi Gross" writes:
>> In languages like C/C++ there are people who make up macros like:
>>#define INDEFINITELY_LOOP while (true)
>>Or something like that and then allow the preprocessor to replace
>>INDEFINITELY_LOOP with valid C code.
>
> Those usually are
On 7/09/21 11:38 am, Avi Gross wrote:
#define INDEFINITELY_LOOP while (true)
So, how to do something like that in python, is a challenge left to the user
def hell_frozen_over():
return False
while not hell_frozen_over():
--
Greg
--
It has been nearly three decades since I have had to write in C, Stefan, but
what I suggested jokingly is quite mild compared to what the winners of the
obfuscated C Contest do:
https://www.ioccc.org/
Time for me to drop out of this thread. Personally I fully agree uses of
"while' as described
I hate to quibble but as almost anything in Python can evaluate to being
truthy, a command like
while "never"
evaluates to true as the string is not empty.
I meant a generator like
>>> def boring():
while True: yield()
>>> for _ in boring():
print("repeating ...")
On 2021-09-06 at 20:11:41 -0400,
Avi Gross via Python-list wrote:
> And in the python version, has anyone made a generator that returned
> NULL or the like so you can say uselessly:
>
> for ( _ in forever() ) ...
while "forever":
...
--
Let me add something, Stefan. Some people just want to get a job done. For
this person, he had a very specific need for a one-time project where the
rest of it was understood but one small step was confusing. Frankly, he
could have done it faster by opening a text editor on something like a CSV
I actually like it if a language lets you spell out your intention, although
adding many keywords is not a plus.
So, yes something like:
loop
...
end loop;
Is appealing as it makes clear the decision on when to exit the loop must be
within the loop (or till
On Sat, 4 Sep 2021 12:27:55 -0500, "Michael F. Stemper"
declaimed the following:
>
>Kernighan and Ritchie agree(d) with you. Per _The C Programming
>Language__:
> Experience shows that do-while is much less used that while
> and for.
>
And just for confusion, consider languages with
For some people the "while true" method seems reasonable but it has a
problem if the internal body does not have some guarantee of an exit. And
that exit can be subtle. Many have mentioned ways an end condition can fail
due to rounding errors not being exactly equal to what you are looking for,
or
"Michael F. Stemper" writes:
> On 04/09/2021 08.53, Hope Rouselle wrote:
>> Chris Angelico writes:
>
>>> And at this point, it's looking pretty much identical to the for loop
>>> version. Ultimately, they're all the same and you can pick and choose
>>> elements from each of them.
>> I see.
"Peter J. Holzer" writes:
> On 2021-09-02 11:28:21 -0300, Hope Rouselle wrote:
>> dn writes:
>> > On 29/08/2021 08.46, Hope Rouselle wrote:
>> >> Here's my solution:
>> >>
>> >> --8<---cut here---start->8---
>> >> def how_many_times():
>> >> x, y = 0, 1
>>
Chris Angelico writes:
> On Fri, Sep 3, 2021 at 4:33 AM Hope Rouselle wrote:
>> Yeah. Here's a little context. I came across this by processing a list
>> of exercises. (I'm teaching a course --- you know that by now, I
>> guess.) So the first thing I observed was the equal volume of work
>>
On 04/09/2021 08.53, Hope Rouselle wrote:
Chris Angelico writes:
And at this point, it's looking pretty much identical to the for loop
version. Ultimately, they're all the same and you can pick and choose
elements from each of them.
I see. That's why C must have added the do-while, but
On 2021-09-02 11:28:21 -0300, Hope Rouselle wrote:
> dn writes:
> > On 29/08/2021 08.46, Hope Rouselle wrote:
> >> Here's my solution:
> >>
> >> --8<---cut here---start->8---
> >> def how_many_times():
> >> x, y = 0, 1
> >> c = 0
> >> while x != y:
> >>
def how_many_times():
x, y = 0, 1
c = 0
while x != y:
c = c + 1
x, y = roll()
return c, (x, y)
Since I haven't seen it used in answers yet, here's another option using our
new walrus operator
def how_many_times():
roll_count = 1
while (rolls := roll())[0] !=
On Fri, Sep 3, 2021 at 4:51 AM Hope Rouselle wrote:
>
> Chris Angelico writes:
>
> > On Mon, Aug 30, 2021 at 11:13 PM David Raymond
> > wrote:
> >>
> >> > def how_many_times():
> >> > x, y = 0, 1
> >> > c = 0
> >> > while x != y:
> >> > c = c + 1
> >> > x, y = roll()
> >> >
On Fri, Sep 3, 2021 at 4:33 AM Hope Rouselle wrote:
> Yeah. Here's a little context. I came across this by processing a list
> of exercises. (I'm teaching a course --- you know that by now, I
> guess.) So the first thing I observed was the equal volume of work
> dedicated to while loops and
Chris Angelico writes:
> On Mon, Aug 30, 2021 at 11:13 PM David Raymond
> wrote:
>>
>> > def how_many_times():
>> > x, y = 0, 1
>> > c = 0
>> > while x != y:
>> > c = c + 1
>> > x, y = roll()
>> > return c, (x, y)
>>
>> Since I haven't seen it used in answers yet, here's
David Raymond writes:
>> def how_many_times():
>> x, y = 0, 1
>> c = 0
>> while x != y:
>> c = c + 1
>> x, y = roll()
>> return c, (x, y)
>
> Since I haven't seen it used in answers yet, here's another option using our
> new walrus operator
>
> def how_many_times():
>
dn writes:
> On 29/08/2021 08.46, Hope Rouselle wrote:
>> Here's my solution:
>>
>> --8<---cut here---start->8---
>> def how_many_times():
>> x, y = 0, 1
>> c = 0
>> while x != y:
>> c = c + 1
>> x, y = roll()
>> return c, (x, y)
>
>>
>> Why
On 30/08/2021 06:17, dn via Python-list wrote:
OTOH the simulation of rolling n-number of dice, as would happen in the
real-world, would be broken by making the computer's algorithm more
efficient (rolling until the first non-equal value is 'found'). Does
that mean the realism of the model
On Tue, Aug 31, 2021 at 12:28 AM Peter Otten <__pete...@web.de> wrote:
>
> On 30/08/2021 15:50, Chris Angelico wrote:
>
> > def how_many_times():
> > return next((count, rolls) for count, rolls in
> > enumerate(iter(roll, None)) if len(Counter(rolls)) == 1)
>
>
> That's certainly the most
On 30/08/2021 15:50, Chris Angelico wrote:
def how_many_times():
return next((count, rolls) for count, rolls in
enumerate(iter(roll, None)) if len(Counter(rolls)) == 1)
That's certainly the most Counter-intuitive version so far;)
Do I get bonus points for it being a one-liner that
On Mon, Aug 30, 2021 at 11:13 PM David Raymond wrote:
>
> > def how_many_times():
> > x, y = 0, 1
> > c = 0
> > while x != y:
> > c = c + 1
> > x, y = roll()
> > return c, (x, y)
>
> Since I haven't seen it used in answers yet, here's another option using our
> new walrus
> def how_many_times():
> x, y = 0, 1
> c = 0
> while x != y:
> c = c + 1
> x, y = roll()
> return c, (x, y)
Since I haven't seen it used in answers yet, here's another option using our
new walrus operator
def how_many_times():
roll_count = 1
while (rolls := roll())[0]
On 30/08/2021 00.47, Peter Otten wrote:
> On 29/08/2021 12:13, dn via Python-list wrote:
>> On 29/08/2021 20.06, Peter Otten wrote:
>> ...
>>> OK, maybe a bit complicated... but does it pay off if you want to
>>> generalize?
>>>
>> def roll_die(faces):
>>> while True: yield
On Mon, Aug 30, 2021 at 9:53 AM dn via Python-list
wrote:
>
> On 29/08/2021 22.24, Chris Angelico wrote:
> > On Sun, Aug 29, 2021 at 8:14 PM dn via Python-list
> > wrote:
> >> Efficiency:
> >> - wonder how max( d ) == min( d ) compares for speed with the set() type
> >> constructor?
> >
> > That
On 29/08/2021 22.24, Chris Angelico wrote:
> On Sun, Aug 29, 2021 at 8:14 PM dn via Python-list
> wrote:
>> Efficiency:
>> - wonder how max( d ) == min( d ) compares for speed with the set() type
>> constructor?
>
> That may or may not be an improvement.
>
>> - alternately len( d ) < 2?
>> - or
On 29/08/2021 12:13, dn via Python-list wrote:
On 29/08/2021 20.06, Peter Otten wrote:
...
OK, maybe a bit complicated... but does it pay off if you want to
generalize?
def roll_die(faces):
while True: yield random.randrange(1, 1 + faces)
def hmt(faces, dies):
for c, d in
On Sun, Aug 29, 2021 at 8:14 PM dn via Python-list
wrote:
> Efficiency:
> - wonder how max( d ) == min( d ) compares for speed with the set() type
> constructor?
That may or may not be an improvement.
> - alternately len( d ) < 2?
> - or len( d ) - 1 coerced to a boolean by the if?
Neither of
On 29/08/2021 20.06, Peter Otten wrote:
...
> OK, maybe a bit complicated... but does it pay off if you want to
> generalize?
>
def roll_die(faces):
> while True: yield random.randrange(1, 1 + faces)
>
def hmt(faces, dies):
> for c, d in enumerate(zip(*[roll_die(faces)]*dies),
On 28/08/2021 14:00, Hope Rouselle wrote:
def how_many_times():
x, y = 0, 1
c = 0
while x != y:
c = c + 1
x, y = roll()
return c, (x, y)
--8<---cut here---end--->8---
Why am I unhappy? I'm wish I could confine x, y to the while loop.
And there is the ever popular recursive version you call with no while loop
in sight. And, oddly, no variable declared in your main body:
# CODE START ---
import random
def roll2():
return random.randint(1,6), random.randint(1,6)
def roll_equal(counter):
first, second = roll2()
On 28/08/2021 21:50, Hope Rouselle wrote:
>>> roll_count = 0
>>> while True:
>>> outcome = roll_two_dice()
>>> roll_count += 1
>>> if outcome[ 0 ]== outcome[ 1 ]: break
>>> return roll_count, outcome[ 0 ]
>>
>
> Wait, I'm surprised ``outcome'' is still a valid name at the
>
On 8/28/2021 8:00 AM, Hope Rouselle wrote:
How should I write this? I'd like to roll two six-sided dice until I
get the same number on both. I'd like to get the number of times I
tried. Here's a primitive I'm using:
--8<---cut here---start->8---
x, y =
On 29/08/2021 08.46, Hope Rouselle wrote:
> Here's my solution:
>
> --8<---cut here---start->8---
> def how_many_times():
> x, y = 0, 1
> c = 0
> while x != y:
> c = c + 1
> x, y = roll()
> return c, (x, y)
>
> Why am I unhappy? I'm wish I
Hope Rouselle writes:
> r...@zedat.fu-berlin.de (Stefan Ram) writes:
>
>> Hope Rouselle writes:
>>>How would you write this?
>>
>> """Rolls two dice until both yield the same value.
>> Returns the number of times the two dice were rolled
>> and the final value yielded."""
>> roll_count = 0
>>
r...@zedat.fu-berlin.de (Stefan Ram) writes:
> Hope Rouselle writes:
>>How would you write this?
>
> """Rolls two dice until both yield the same value.
> Returns the number of times the two dice were rolled
> and the final value yielded."""
> roll_count = 0
> while True:
> outcome =
On Sun, Aug 29, 2021 at 7:37 AM Hope Rouselle wrote:
>
> How should I write this? I'd like to roll two six-sided dice until I
> get the same number on both. I'd like to get the number of times I
> tried. Here's a primitive I'm using:
>
> --8<---cut
r...@zedat.fu-berlin.de (Stefan Ram) writes:
> Hope Rouselle writes:
>>Wait, I'm surprised ``outcome'' is still a valid name at the
>>return-statement. Wasn't it defined inside the while? Shouldn't its
>>scope be restricted to the while block? I had no idea. I should learn
>>some Python.
>
>
63 matches
Mail list logo
