Could you share a short, VERY Readable Pythonic (or Lisp, Scheme) code
that solves this?
This is my answer after spending this afternoon learning Guile. Much
more wordy than the Python version I previously posted. Anybody know
how to do it better?
Lawrence D'Oliveiro <ldo@nz.invalid> writes:
This is my answer after spending this afternoon learning Guile. Much
more wordy than the Python version I previously posted. Anybody know
how to do it better?
The following works for me as a fairly simple port of the concise Python version to Guile.
This is my answer after spending this afternoon learning Guile. Much
more wordy than the Python version I previously posted. Anybody know
how to do it better?
(define (range n) ...
1) Your "range" function already exists, called "iota" (after the iota operation in APL).
2) Similarly the "score" function looks translated from C to Scheme or something like that.
sum(a == b for a, b in zip(candidate, answer))
sum
(
i != j and a == b
for i, a in enumerate(candidate)
for j, b in enumerate(answer)
)
)
Lawrence D'Oliveiro <ldo@nz.invalid> writes:
sum
(
i != j and a == b for i, a in enumerate(candidate)
for j, b in enumerate(answer)
)
In Python you might avoid the nested loops by writing that in terms of
set or multiset (collections.Counter) intersections.
In Python you might avoid the nested loops by writing that in terms ofWhy would that be better?
set or multiset (collections.Counter) intersections.
On Tue, 27 Feb 2024 17:46:48 -0800, Paul Rubin wrote:
Lawrence D'Oliveiro <ldo@nz.invalid> writes:
sum
(
i != j and a == b for i, a in enumerate(candidate)
for j, b in enumerate(answer)
)
In Python you might avoid the nested loops by writing that in terms of
set or multiset (collections.Counter) intersections.
Why would that be better?
Lawrence D'Oliveiro <ldo@nz.invalid> writes:
Why would that be better?
You are trying to handle N digits and your algorithm does O(N**2) comparisons. Ok, I guess the whole search strategy is impractical if N
is larger than just a few, and in traditional Mastermind N=4, so maybe
that isn't an issue.
“Premature optimization is the root of all evil.”
Same idea as writing a matrix product as A*B instead of as some messy
thing with subscripts.
On Wed, 28 Feb 2024 15:54:48 -0800, Paul Rubin wrote:
Lawrence D'Oliveiro <ldo@nz.invalid> writes:
Why would that be better?
You are trying to handle N digits and your algorithm does O(N**2)
comparisons. Ok, I guess the whole search strategy is impractical if N
is larger than just a few, and in traditional Mastermind N=4, so maybe
that isn't an issue.
“Premature optimization is the root of all evil.”
-- variously attributed to Tony Hoare or Donald Knuth
Somebody still has to write the underlying code with the subscripts.
I only push things into separate/library functions if I’m going to reuse them. Splitting things off just for the sake of doing so is what we could call a “fragmentation smell” or a “gratuitous hierarchy antipattern”.
Lawrence D'Oliveiro <ldo@nz.invalid> writes:
Somebody still has to write the underlying code with the subscripts.
Sure, that's pushed down into a library or helper function though. Doing
it at the higher level is related to the "primitive obsession"
antipattern.
The "parenthesis pileup" aside, the following things jump out at me:
1) Your "range" function already exists, called "iota" (after the iota operation in APL).
2) Even if it didn't exist, your recursive definition is messy.
This is more idiomatic:
(define (range n)
(define (go n a)
(if (< n 0)
a
(go (1- n) (cons n a))))
(go n 0))
On 2024-02-29, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
On Wed, 28 Feb 2024 15:54:48 -0800, Paul Rubin wrote:
Lawrence D'Oliveiro <ldo@nz.invalid> writes:
Why would that be better?
You are trying to handle N digits and your algorithm does O(N**2)
comparisons. Ok, I guess the whole search strategy is impractical if N
is larger than just a few, and in traditional Mastermind N=4, so maybe
that isn't an issue.
“Premature optimization is the root of all evil.”
-- variously attributed to Tony Hoare or Donald Knuth
Pinning it down more precisely at this stage would be premature
attribution.
yes, there are places where it doesn't bring much benefit to optimize,
but there are also the parts where it *does*.
On 2024-03-01, Kaz Kylheku wrote:
On 2024-02-29, Lawrence D'Oliveiro <ldo@nz.invalid> wrote: .....
“Premature optimization is the root of all evil.”
----- variously attributed to Tony Hoare or Donald Knuth
Pinning it down more precisely at this stage would be premature attribution.
I sometimes feel that this specific sentence from Knuth's quote might be being used as a way to discourage even thinking about optimization, when
the intent of the whole quote might be actually the opposite: yes, there
are places where it doesn't bring much benefit to optimize, but there
are also the parts where it *does*.
it's written in a [functional] or [mathematical] or
"comprehensive" style.
and not Perlis?
On Sun, 3 Mar 2024 22:56:25 +0000, HenHanna wrote:
it's written in a [functional] or [mathematical] or "comprehensive" style.
Yup, I like writing functional constructs in primarily-procedural
languages. It’s better than trying to work in supposedly pure-functional languages.
Python also uses the term “comprehension” for certain uses of that kind of construct.
and not Perlis?
I like another quote of his: “There are two ways to write error-free programs; only the third one works.”
41. Some programming languages manage to absorb change, but withstand progress. -------- For example?????
42. You can measure a programmer's perspective by noting his attitude on
the continuing vitality of FORTRAN.
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 388 |
Nodes: | 16 (2 / 14) |
Uptime: | 10:20:04 |
Calls: | 8,221 |
Files: | 13,122 |
Messages: | 5,872,709 |