Re: Why Python don't accept 03 as a number?
On Sat, Dec 8, 2018 at 7:57 PM wrote:
>
> Grant Edwards於 2018年12月9日星期日 UTC+8上午12時52分04秒寫道：
> > Just to be clear: you do _not_ want to use eval on the string.
> >
> > If you're not the one who created the string, it might wipe your hard
> > drive or empty your bank account. If you _are_ the one who created
> > the string, then generate the desired result instead.
> >
> > --
> > Grant
>
> I didn't evaluate the input string directly. It's the translated "digit"
> string been evaluated, so shouldn't have any danger on using eval().
Replacing the first five letters of the alphabet is not sufficient to
sanitize untrusted input for eval. Here's a simple example that avoids
using any of those letters:
py> eval(re.sub(r'[a-e]', '0',
"__import__('su\\x62pro\\x63\\x65ss').run('\\x65\\x63ho rm -rf /',
**{'sh\\x65ll': 1})"))
rm -rf /
CompletedProcess(args='echo rm -rf /', returncode=0)
Now, if you remove *all* the characters that could possibly start
identifiers
(https://docs.python.org/3/reference/lexical_analysis.html#identifiers)
then you might be safe. Possibly just removing all the ones in ASCII
(A-Z + a-z + _) would suffice. I make no guarantees either way.
I wish I could say you should just use ast.literal_eval instead.
Unfortunately it doesn't seem to support ==:
py> ast.literal_eval('10 + 20 == 30')
Traceback (most recent call last):
File "", line 1, in
File "/usr/lib/python3.5/ast.py", line 84, in literal_eval
return _convert(node_or_string)
File "/usr/lib/python3.5/ast.py", line 83, in _convert
raise ValueError('malformed node or string: ' + repr(node))
ValueError: malformed node or string: <_ast.Compare object at 0x78172bee5358>
--
https://mail.python.org/mailman/listinfo/python-list
Re: conda/anaconda and pip3 (pip)
Did you find any solution(s)? -- https://mail.python.org/mailman/listinfo/python-list
Re: Why Python don't accept 03 as a number?
Avi Gross於 2018年12月9日星期日 UTC+8上午1時40分26秒寫道：
> Jach,
>
> Just for fun, I looked at the puzzle you asked about and solved it several
> ways without running into your 03 problem at all. There are more efficient
> solutions than total brute force.
>
> Anyone not interested, stop here, please. After my explanations, I show a
> python program then the output it produces.
>
> The comments in the python program (below) explain the solution classes but
> let me suggest a little algebra simplifies the problem so fewer brute force
> iterations are needed.
>
> The simplistic algorithm can be written as a single list comprehension with
> (in this case) 5 "for" clauses and one "if" clause.
>
> You are solving for: ab + aa + cd == ce
>
> So
> for all digits possible for a
> for all remaining digits possible for b each iteration
> for all remaining digits possible for c each iteration
> for all remaining digits possible for d each iteration
> for all remaining digits possible for e each iteration
> if the condition applies.
>
> Clearly the above is deeply nested with 10!/5! Iterations or 30,240.
>
> But a little algebra simplifies the solution so c drops out of the equation
> as shown below in the comments.
> The test becomes: 21*a + b + d - e == 0
>
> You can apply that as the condition using four loops. You get 32 solutions
> and for each you can let c be any of 10 possibilities for 320 total
> solutions, if I did it right. The number of iterations is now only 5,040 and
> you are evaluating fewer terms with c gone. The full test would have been
> (10*a +b )+ (10*a + a) + (10*c + d) == (10*c + e)
>
> BUT a tad more analysis shows that all solutions require "a" to be zero. If
> a >=1 then 21*a must be >= 21.
> But b and c cannot be more than 9+8 which is 17 and subtracting e makes it
> no larger. So "a" MUST be zero.
>
> So the solution can be done with only three loops for b, d, and e. 720
> iterations.
>
> The commented code is below. It can be done in as little as two lines of
> code if the list comprehension is done in one line but why make it hard to
> read.
>
> If there is a flaw in my reasoning or the program below, please point it
> out. You said there were 192 solutions. I found 320.
> And, there are more efficient solutions possible but overkill for this
> application.
>
> Avi
>
> ### START CODE ##
> # GOAL: find all solutions of a puzzle
> # ab + aa + cd == ce
> # Where each of the letters a through e
> # are UNIQUE values ranging from 0 to 9
>
> # Make the equation simpler
> # expand ab to 10*a + b
> # expand aa to 10*a + a
> # expand cd to 10*c + d
> # add to get 21*a + b + 10*c + d
> # expand ce to 10*c + e
> # simplify 21*a + b + 10*c + d = 10*c + e
> # the 10*c on both sides cancel.
> # RESULT: 21*a + b + d - e = 0
> # the value of c is not relevant and
> # you can solve without e and then add back
> # all ten possibilities later.
>
> # Method:
> # Use a set of digits.
> # Use a list comprehension with four loops.
> # Each loop chooses all available values
> # for a,b,d,e by subtracting the set
> # of digits already in use at the time from all digits.
>
> digits = set(range(10))
>
> matches = [ (a, b, d, e)
> for a in digits
> for b in (digits - {a})
> for d in (digits -{a,b})
> for e in (digits -{a,b,d})
> if ( 21*a + b + d - e == 0)
> ]
>
> print("SOLVING FOR: 21*a + b + d - e == 0")
> print(f"matches found in batches of 10: {len(matches)}")
>
> for (a,b,d,e) in matches:
> solution = {'a' : a,
> 'b' : b,
> 'c' : 'any digit',
> 'd' : d,
> 'e' : e
> }
> print(solution)
>
> # Note the result shows all solutions have 'a' being zero.
> # That was obvious from the equation as there were 21 of them
> # and if a was 1 in 21*a + b + d - e = 0
> # then clearly band d cannot be more than 9+8 so no solution
> # unless a == 0.
> # So you can solve this easier using the above techique by just
> # solving b + d - e = 0
>
> matches = [ (b, d, e)
> for b in digits
> for d in (digits -{b})
> for e in (digits -{b,d})
> if ( b + d == e)
> ]
>
> print("\nSOLVING FOR: b + d == e")
> print(f"matches found in batches of 10: {len(matches)}")
>
> for (b,d,e) in matches:
> solution = {'a' : '0',
> 'b' : b,
> 'c' : 'any digit',
> 'd' : d,
> 'e' : e
> }
> print(solution)
>
> ### END CODE ##
> ### BEGIN OUTPUT ##
> SOLVING FOR: 21*a + b + d - e == 0
> matches found in batches of 10: 32
> {'a': 0, 'b': 1, 'c': 'any digit', 'd': 2, 'e': 3}
> {'a': 0, 'b': 1, 'c': 'any digit', 'd': 3, 'e': 4}
> {'a': 0, 'b': 1, 'c': 'any digit', 'd': 4, 'e': 5}
> {'a': 0, 'b': 1, 'c': 'any digit', 'd': 5,
Re: Why Python don't accept 03 as a number?
Grant Edwards於 2018年12月9日星期日 UTC+8上午12時52分04秒寫道： > On 2018-12-08, Cameron Simpson wrote: > > On 07Dec2018 20:24, Jach Fong wrote: > >>Ian at 2018/12/8 UTC+8 AM11:28:34 wrote: > >>> What is it exactly that you're trying to accomplish with this? Perhaps > >>> there's a better way than using eval. > >> > >>This problem comes from solving a word puzzle, > >>ab + aa + cd == ce > >>Each character will be translate to a digit and evaluate the correctness, > >>03 + 00 + 15 == 18 > > > > Then you should be evaluating the digits and assembling values from > > them. Not trying to shoehorn a string through something that _might_ > > accept this string and do what you want. In Python 2 it will accept your > > string and not do what you want; at least in Python 3 it doesn't accept > > your string. > > Just to be clear: you do _not_ want to use eval on the string. > > If you're not the one who created the string, it might wipe your hard > drive or empty your bank account. If you _are_ the one who created > the string, then generate the desired result instead. > > -- > Grant I didn't evaluate the input string directly. It's the translated "digit" string been evaluated, so shouldn't have any danger on using eval(). --Jach -- https://mail.python.org/mailman/listinfo/python-list
Re: Program to keep track of success percentage
On 2018-12-08 17:54, Avi Gross wrote:
> This may be a bit awkward.
ICWYDT. "awk"ward. :wide-eyed_gaping_grin_with_finger-guns:
You seem to have your knickers in a knot.
> Your solution in AWK assumes lots of things. You assume the data
> is either on stdin or comes from automatically opening file names
> on the command line to generate a stream of lines. You assume a win
> is any line containing one or more lower or upper case instances of
> the letter W. You let AWK count lines and store that in NR and
> assume anything without a W is a loss. You print a running
> commentary and only at the end of input state if they exceeded 31%.
1) yes the problem was underdefined. If all they want is to is tally
wins ("the only user input is win/loss". Note: not blank. Not ties.
Not garbage. Not "victorias/derrotas" nor "νίκες/απώλειες"), the awk
one-liner does exactly that. I'll grant, that the OP didn't specify
whether this was on Windows, Linux, Mac, BSD, DOS, ULTRIX, or
anything at all about the operating system. The concepts for the
solution remain, even if awk is unavailable. If the input isn't from
stdin it's not standard and should be specified in the problem-space
(there's a reason it's called *standard input*).
2) the problem sounded an awful lot like homework. I'm not going to
answer a *Python* homework problem in *Python*. I'm willing to give
the solution in another language (done) so the OP can translate
those ideas into Python. I'm also willing to take what the OP has
already written (nothing provided in the original email) and help the
OP iterate with that. The original request, while posted to the
Python mailing list, didn't even specify that it had to be in
Python. If it's not homework, then the one-liner solves their
problem on any modern platform with a CLI that isn't Windows (and
even on Windows if one installs a version of awk there.)
Yes. It could also have had a sqlite/mysql/postgres database
back-end, and command-line interface for tracking wins/losses, and a
web front-end for displaying statistics and reporting wins/losses,
and a tkinter/wx/whatever GUI for team management, and export PDFs,
and use TensorFlow for AI analysis of the results. But that's not
what the OP asked for.
> Yours would read much better if spaced out, but you might have
> written it this way when you were 😉
While I was not in any chemically-altered state of mind, while I
penned it as one line, it would certainly be more readable as a
script.
#!env awk -f
/[wW]/{
w += 1;
}
{
printf("W: %i L: %i %i%%\n", w, NR-w, w * 100/NR);
}
END {
if (w * 100/NR > 31)
print "More than 31% winning"
}
There. Happy?
> Would you care to do the same thing as a brief program in that
> language.
I can (and for the record, did), but I don't provide other people
with the prefab answers to their homework.
-tkc
--
https://mail.python.org/mailman/listinfo/python-list
Re: Why Python don't accept 03 as a number?
On 12/8/18 6:23 PM, Avi Gross wrote: > [DISCLAIMER: less about python than analysis of a puzzle] > > Richard, > > Thank you for pointing out that c in the puzzle is constrained. That > explains why my 320 answers are too many. It cannot be 0 as "a" is always > zero and it cannot be the three other values that b,d,e are using at the > time. So my earlier solution should say c is any of six available choices. > > So 6 * 32 is 192 solutions. > > Your analysis requires considering a carry from the right column into the > left. I skipped that by converting something like ab to 10*a+b. > > This all began with someone trying to enter 03 which suggests they may have > been starting to look at it your way. As a logic puzzle to do those with > pencil and paper, your analysis is spot on. There is additional info to be > gleaned by looking at adding columns. I chose a perspective on more brute > force methods and whittled it down to less forceful. Given that c was > removed from the equation, though, and that only 6 of 10 options are > available for any given time, I would need another pass at the answers and > for each solution for the others (b,d,e if we agree a is always 0) I would > need to make six entries with c set successively to digits-set(0,b,d,e} or > something like that. > > I note that programming some of the kinds of analysis some of these puzzles > use is not as easy in programming languages as a more brute-force approach > that computers are better at than humans. Actually, part of my point was that we are often tempted to go simple brute force when a bit of analysis can often vastly simplify the problem to be solved. Now, the brute force program, if done right, could also handle other related problems like SEND+MORE=MONEY But now, the input equation isn't controlled by the program, so you need to be very careful about using it for something that gets sent to eval, and by the time you take that care, perhaps it is easier to do the safer way. -- Richard Damon -- https://mail.python.org/mailman/listinfo/python-list
RE: Why Python don't accept 03 as a number?
[DISCLAIMER: less about python than analysis of a puzzle] Richard, Thank you for pointing out that c in the puzzle is constrained. That explains why my 320 answers are too many. It cannot be 0 as "a" is always zero and it cannot be the three other values that b,d,e are using at the time. So my earlier solution should say c is any of six available choices. So 6 * 32 is 192 solutions. Your analysis requires considering a carry from the right column into the left. I skipped that by converting something like ab to 10*a+b. This all began with someone trying to enter 03 which suggests they may have been starting to look at it your way. As a logic puzzle to do those with pencil and paper, your analysis is spot on. There is additional info to be gleaned by looking at adding columns. I chose a perspective on more brute force methods and whittled it down to less forceful. Given that c was removed from the equation, though, and that only 6 of 10 options are available for any given time, I would need another pass at the answers and for each solution for the others (b,d,e if we agree a is always 0) I would need to make six entries with c set successively to digits-set(0,b,d,e} or something like that. I note that programming some of the kinds of analysis some of these puzzles use is not as easy in programming languages as a more brute-force approach that computers are better at than humans. -Original Message- From: Python-list On Behalf Of Richard Damon Sent: Saturday, December 8, 2018 5:30 PM To: python-list@python.org Subject: Re: Why Python don't accept 03 as a number? On 12/8/18 12:40 PM, Avi Gross wrote: > You are solving for: ab + aa + cd == ce Actually, an even quicker analysis for this particular problem is: from the 10s digits, a + a + c + carryin = c Thus a and carryin must both be 0 (carryin can not be negative, nor any of the variables) thus the final solution space is: b + d = e a = 0 c any other digit (6 possible values for every combo of b, d, e) if b is <= 4, there are 8-b possible values of d that will have a legal value of e. b = 1, we get d = 2, 3, 4, ... 7, 8 b = 2, we get d = 1, 3, 4, ... 6, 7 (8 would generate carry) b = 3, we get d = 1, 2, 4, 5, 6 b = 4, we get d = 1, 2, 3, 5 if b >= 5 we get 9-b possible values of d (we no longer have to omit the possible value of b = d) So the number of possible answers are: (7+6+5+4+4+3+2+1)*6 = 192 (your 320 was you gave c 10 possible values, but you need to remove the duplicates). -- https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
RE: Program to keep track of success percentage
Tim,
This may be a bit awkward.
I am not sure a question on the python list expects to get a one-liner, let
alone in an unrelated language like AWK. Unless you install other environments
like Cygwin, AWK does not tend to be available of platforms like Windows. Ditto
for PERL and other languages or tools you want to use this way.
There are times people appreciate something sophisticated or clever or even
innovative.
My personal take on this question is of someone who does not necessarily know
what they need to do, let alone in python. And they did not specify how the
data is supplied or whether it is a one-time thing.
The two numbers needed could be supplied on the command line and gotten using
argv or gotten using two input statements or read from a file or stdin. Or they
could be asking for a cumulative set of wins/losses to be contiuously evaluated
and as soon as the threshold of 31% is attained, print a message. OR, there
could be a previously agreed upon number of games, such as 164, and you get
win/loss criteria some way and you want the percentage of wins divided by the
164 to be 31%.
My GUESS is they are getting a stream of win/win/loss/win/loss/... type of
data, maybe one per line of text, maybe as 0 versus 1, but who knows. If we
knew exactly, it might lead to trivial solutions. For example, if they had a
series of 0/1 you could do a sum() and a count() and divide.
But what if the scenario was to provide a score like 5 - 3 using whatever
notation. Now you need to figure out if your side won and perhaps deal with
ties before counting and dividing.
Too many scenarios are possible but the simple answer is more like someone else
said.
Count the number of wins, or keep track of it.
Count the total you need.
Divide one by the other and compare it to 0.31 or 31 depending on your
calculation method.
Your solution in AWK assumes lots of things. You assume the data is either on
stdin or comes from automatically opening file names on the command line to
generate a stream of lines. You assume a win is any line containing one or more
lower or upper case instances of the letter W. You let AWK count lines and
store that in NR and assume anything without a W is a loss. You print a running
commentary and only at the end of input state if they exceeded 31%.
Now that is quite possibly a way to go. But the data may not be set up that way
or they may want to quit as soon as the threshold is reached or there may be
blank lines or a notation for a tie. Some of those may not be one-liners. Yours
would read much better if spaced out, but you might have written it this way
when you were 😉
But, as mentioned, this is a python board. Would you care to do the same thing
as a brief program in that language.
If we had that pesky := operator, maybe.
Just kidding.
-Original Message-
From: Python-list On
Behalf Of Tim Chase
Sent: Saturday, December 8, 2018 4:00 PM
To: Musatov
Cc: python-list@python.org
Subject: Re: Program to keep track of success percentage
On 2018-12-08 10:02, Musatov wrote:
> I am thinking about a program where the only user input is win/loss.
> The program let's you know if you have won more than 31% of the time
> or not. Any suggestions about how to approach authoring such a
> program? Thanks. --
Can be done with an awk one-liner:
awk '/[wW]/{w+=1}{printf("W: %i L: %i %i%%\n", w, NR-w, w * 100/NR)}END{if (w *
100/NR > 31) print "More than 31% winning"}'
-tkc
--
https://mail.python.org/mailman/listinfo/python-list
--
https://mail.python.org/mailman/listinfo/python-list
Re: Why Python don't accept 03 as a number?
On 12/8/18 12:40 PM, Avi Gross wrote: > You are solving for: ab + aa + cd == ce Actually, an even quicker analysis for this particular problem is: from the 10s digits, a + a + c + carryin = c Thus a and carryin must both be 0 (carryin can not be negative, nor any of the variables) thus the final solution space is: b + d = e a = 0 c any other digit (6 possible values for every combo of b, d, e) if b is <= 4, there are 8-b possible values of d that will have a legal value of e. b = 1, we get d = 2, 3, 4, ... 7, 8 b = 2, we get d = 1, 3, 4, ... 6, 7 (8 would generate carry) b = 3, we get d = 1, 2, 4, 5, 6 b = 4, we get d = 1, 2, 3, 5 if b >= 5 we get 9-b possible values of d (we no longer have to omit the possible value of b = d) So the number of possible answers are: (7+6+5+4+4+3+2+1)*6 = 192 (your 320 was you gave c 10 possible values, but you need to remove the duplicates). -- https://mail.python.org/mailman/listinfo/python-list
Re: Program to keep track of success percentage
On 2018-12-08 10:02, Musatov wrote:
> I am thinking about a program where the only user input is
> win/loss. The program let's you know if you have won more than 31%
> of the time or not. Any suggestions about how to approach authoring
> such a program? Thanks. --
Can be done with an awk one-liner:
awk '/[wW]/{w+=1}{printf("W: %i L: %i %i%%\n", w, NR-w, w *
100/NR)}END{if (w * 100/NR > 31) print "More than 31% winning"}'
-tkc
--
https://mail.python.org/mailman/listinfo/python-list
Re: Program to keep track of success percentage
On Sat, Dec 8, 2018 at 1:22 PM Alister via Python-list wrote: > > On Sat, 08 Dec 2018 10:02:41 -0800, Musatov wrote: > > > I am thinking about a program where the only user input is win/loss. The > > program let's you know if you have won more than 31% of the time or not. > > Any suggestions about how to approach authoring such a program? Thanks. > > To start describe how you would do it if keeping score on paper. > > a simple loop > keep a count of the number for questions > keep a count of the number. > calculate the percentage. > > once you have what is known as pseudo code you will be 90% of the way > there > (python is effectively executable pseudo code anyway) > > this should be more than enough to help you with you homework without > doing it for you If this is not homework on the other hand, then my recommendation is to just use a spreadsheet. -- https://mail.python.org/mailman/listinfo/python-list
Program to keep track of success percentage
I am thinking about a program where the only user input is win/loss. The program let's you know if you have won more than 31% of the time or not. Any suggestions about how to approach authoring such a program? Thanks. -- https://mail.python.org/mailman/listinfo/python-list
Re: Program to keep track of success percentage
On Sat, 08 Dec 2018 10:02:41 -0800, Musatov wrote: > I am thinking about a program where the only user input is win/loss. The > program let's you know if you have won more than 31% of the time or not. > Any suggestions about how to approach authoring such a program? Thanks. To start describe how you would do it if keeping score on paper. a simple loop keep a count of the number for questions keep a count of the number. calculate the percentage. once you have what is known as pseudo code you will be 90% of the way there (python is effectively executable pseudo code anyway) this should be more than enough to help you with you homework without doing it for you -- If reporters don't know that truth is plural, they ought to be lawyers. -- Tom Wicker -- https://mail.python.org/mailman/listinfo/python-list
RE: Why Python don't accept 03 as a number?
Jach,
Just for fun, I looked at the puzzle you asked about and solved it several
ways without running into your 03 problem at all. There are more efficient
solutions than total brute force.
Anyone not interested, stop here, please. After my explanations, I show a
python program then the output it produces.
The comments in the python program (below) explain the solution classes but
let me suggest a little algebra simplifies the problem so fewer brute force
iterations are needed.
The simplistic algorithm can be written as a single list comprehension with
(in this case) 5 "for" clauses and one "if" clause.
You are solving for: ab + aa + cd == ce
So
for all digits possible for a
for all remaining digits possible for b each iteration
for all remaining digits possible for c each iteration
for all remaining digits possible for d each iteration
for all remaining digits possible for e each iteration
if the condition applies.
Clearly the above is deeply nested with 10!/5! Iterations or 30,240.
But a little algebra simplifies the solution so c drops out of the equation
as shown below in the comments.
The test becomes: 21*a + b + d - e == 0
You can apply that as the condition using four loops. You get 32 solutions
and for each you can let c be any of 10 possibilities for 320 total
solutions, if I did it right. The number of iterations is now only 5,040 and
you are evaluating fewer terms with c gone. The full test would have been
(10*a +b )+ (10*a + a) + (10*c + d) == (10*c + e)
BUT a tad more analysis shows that all solutions require "a" to be zero. If
a >=1 then 21*a must be >= 21.
But b and c cannot be more than 9+8 which is 17 and subtracting e makes it
no larger. So "a" MUST be zero.
So the solution can be done with only three loops for b, d, and e. 720
iterations.
The commented code is below. It can be done in as little as two lines of
code if the list comprehension is done in one line but why make it hard to
read.
If there is a flaw in my reasoning or the program below, please point it
out. You said there were 192 solutions. I found 320.
And, there are more efficient solutions possible but overkill for this
application.
Avi
### START CODE ##
# GOAL: find all solutions of a puzzle
# ab + aa + cd == ce
# Where each of the letters a through e
# are UNIQUE values ranging from 0 to 9
# Make the equation simpler
# expand ab to 10*a + b
# expand aa to 10*a + a
# expand cd to 10*c + d
# add to get 21*a + b + 10*c + d
# expand ce to 10*c + e
# simplify 21*a + b + 10*c + d = 10*c + e
# the 10*c on both sides cancel.
# RESULT: 21*a + b + d - e = 0
# the value of c is not relevant and
# you can solve without e and then add back
# all ten possibilities later.
# Method:
# Use a set of digits.
# Use a list comprehension with four loops.
# Each loop chooses all available values
# for a,b,d,e by subtracting the set
# of digits already in use at the time from all digits.
digits = set(range(10))
matches = [ (a, b, d, e)
for a in digits
for b in (digits - {a})
for d in (digits -{a,b})
for e in (digits -{a,b,d})
if ( 21*a + b + d - e == 0)
]
print("SOLVING FOR: 21*a + b + d - e == 0")
print(f"matches found in batches of 10: {len(matches)}")
for (a,b,d,e) in matches:
solution = {'a' : a,
'b' : b,
'c' : 'any digit',
'd' : d,
'e' : e
}
print(solution)
# Note the result shows all solutions have 'a' being zero.
# That was obvious from the equation as there were 21 of them
# and if a was 1 in 21*a + b + d - e = 0
# then clearly band d cannot be more than 9+8 so no solution
# unless a == 0.
# So you can solve this easier using the above techique by just
# solving b + d - e = 0
matches = [ (b, d, e)
for b in digits
for d in (digits -{b})
for e in (digits -{b,d})
if ( b + d == e)
]
print("\nSOLVING FOR: b + d == e")
print(f"matches found in batches of 10: {len(matches)}")
for (b,d,e) in matches:
solution = {'a' : '0',
'b' : b,
'c' : 'any digit',
'd' : d,
'e' : e
}
print(solution)
### END CODE ##
### BEGIN OUTPUT ##
SOLVING FOR: 21*a + b + d - e == 0
matches found in batches of 10: 32
{'a': 0, 'b': 1, 'c': 'any digit', 'd': 2, 'e': 3}
{'a': 0, 'b': 1, 'c': 'any digit', 'd': 3, 'e': 4}
{'a': 0, 'b': 1, 'c': 'any digit', 'd': 4, 'e': 5}
{'a': 0, 'b': 1, 'c': 'any digit', 'd': 5, 'e': 6}
{'a': 0, 'b': 1, 'c': 'any digit', 'd': 6, 'e': 7}
{'a': 0, 'b': 1, 'c': 'any digit', 'd': 7, 'e': 8}
{'a': 0, 'b': 1, 'c': 'any digit', 'd': 8, 'e': 9}
{'a': 0, 'b': 2, 'c': 'any digit', 'd': 1, 'e': 3}
{'a': 0, 'b': 2, 'c': 'any digit', 'd': 3, 'e': 5}
{'a': 0, 'b': 2, 'c': 'any digit', 'd': 4, 'e': 6}
{'a': 0,
Re: Why Python don't accept 03 as a number?
On 2018-12-08, Cameron Simpson wrote: > On 07Dec2018 20:24, Jach Fong wrote: >>Ian at 2018/12/8 UTC+8 AM11:28:34 wrote: >>> What is it exactly that you're trying to accomplish with this? Perhaps >>> there's a better way than using eval. >> >>This problem comes from solving a word puzzle, >>ab + aa + cd == ce >>Each character will be translate to a digit and evaluate the correctness, >>03 + 00 + 15 == 18 > > Then you should be evaluating the digits and assembling values from > them. Not trying to shoehorn a string through something that _might_ > accept this string and do what you want. In Python 2 it will accept your > string and not do what you want; at least in Python 3 it doesn't accept > your string. Just to be clear: you do _not_ want to use eval on the string. If you're not the one who created the string, it might wipe your hard drive or empty your bank account. If you _are_ the one who created the string, then generate the desired result instead. -- Grant -- https://mail.python.org/mailman/listinfo/python-list
Re: Why Python don't accept 03 as a number?
On 12/7/18 11:24 PM, jf...@ms4.hinet.net wrote: > Ian at 2018/12/8 UTC+8 AM11:28:34 wrote: >> What is it exactly that you're trying to accomplish with this? Perhaps >> there's a better way than using eval. > This problem comes from solving a word puzzle, > ab + aa + cd == ce > Each character will be translate to a digit and evaluate the correctness, > 03 + 00 + 15 == 18 > For the classic version of that problem, a = 0 is not allowed, since you never in 'normal' life write number with leading zeros, the alpha-math problems never have leading zeros either. As other have said, the work to compute the value yourself rather than due the text substitution and eval is close to comparable. -- Richard Damon -- https://mail.python.org/mailman/listinfo/python-list
Re: Why Python don't accept 03 as a number?
Avi Gross at 2018/12/8 UTC+8 PM2:09:20 wrote:
> [[READERS DIGEST CONDENSED ANSWER: use int("string") ]]
>
> Since we all agree python will not make notations like "05" work
> indefinitely, and the need expressed is how to solve a symbolic puzzle (see
> message below) then it makes sense to look at alternate representations.
>
> I have a question first. How are you solving your puzzles?
>
> ab + aa + cd == ce
Try all the combinations:-)
The only way I can think of is try-error. It takes no more 10 lines to go from
"ab + aa + cd == ce" to yield one correct answer, such as "03 + 00 + 15 == 18",
using itertools' permutations(), string's translate() and re.
> Why does 05 ever even appear in your solution?
I don't know. There is total 192 answers for this puzzle anyway.
> Are you generating all possible answers by setting each variable to one of 0
> to 9 then the second to any of the remaining nine choices then the third to
> the remaining 8 and so on? For any method like that, you can presumably make
> each component like
>
> ab = 10*a + b
>
> in the loop.
>
> Similarly for aa and cd and ce. If the equality above is true, you found the
> solution and break out. If there can be multiple solutions, note the
> solution and keep going. But note for the 5 variables above, you are testing
> 10*9*8*7*6 combinations.
>
> Another idea is to use strings like "05" as bizarrely, the function int()
> seems to be an ex eption that does NOT care about leading whitespace or
> zeroes:
>
> >>> int("05")
> 5
> >>> int(" 0005")
> 5
>
> And even handles all zeroes:
>
> >>> int("00")
> 0
>
> You can also use lstrip() with an argument to remove zeros:
>
> >>> a = eval("05".lstrip("0"))
>
> >>> a
>
> 5
>
> If you are in a situation where you only want to remove leading zeroes if
> the following character is a digit and not "o" or "b" or "x", use regular
> expressions or other techniques.
As far as the leading zero problem was concerned, the simplest way is using
re.sub()
> I will just toss in the possible use of the SymPy module to do actual
> symbolic computations to solve some of these. Perhaps a tad advanced.
I don't know SymPy and if it can shorten the execution time. But I am very
curious about if there is other algorithm which can apply to this problem:-)
--Jach
--
https://mail.python.org/mailman/listinfo/python-list
Re: Why Python don't accept 03 as a number?
08.12.18 08:53, Henrik Bengtsson пише:
A comment from the sideline: one could imagine extending the Python syntax
with a (optional) 0d prefix that allows for explicit specification of
decimal values. They would "complete" the family:
* 0b: binary number
* 0o: octal number
* 0d: decimal number
* 0x: hexadecimal number
I understand that changing the syntax/parser is a major move. I wouldn't be
surprised if others brought up 0d before.
It is more likely that 'd' will be used for Decimal literals.
1d-2 == Decimal('0.01')
--
https://mail.python.org/mailman/listinfo/python-list
Re: Why Python don't accept 03 as a number?
On Fri, Dec 7, 2018 at 11:56 PM Henrik Bengtsson wrote: > > A comment from the sideline: one could imagine extending the Python syntax > with a (optional) 0d prefix that allows for explicit specification of > decimal values. They would "complete" the family: > > * 0b: binary number > * 0o: octal number > * 0d: decimal number > * 0x: hexadecimal number That's nice and elegant, but what would be the use case? -- https://mail.python.org/mailman/listinfo/python-list
