Why did this paper need four revisions? Edit: the revisions have different ranges of numbers, but they go up and down. Odd.
Actually, four is even.
Numbers 0 to 11111 in terms of Increasing and Decreasing Orders of 1 to 9 (2014)
31–40 of 61 posts
Re: Numbers 0 to 11111 in terms of Increasing and Decreasing Orders of 1 to 9 (2014)
#32Earlier quoted context omitted.
There is no script, he did it mostly by hand.
I would have thought that to be the fun bit! I think there was at least one script for some of the numbers, this I would have thought the most interesting, optimisation of the script and for all numbers and proving some numbers have no solutions([edit] possibly very hard) - "The author is thankful to xxxx in finding some difficult representations using computerized script."
"some". In previous versions of the paper, he claims to have done everything manually: "To bring these numbers, thousands of combinations are considered without use of any programming language."
Re: Numbers 0 to 11111 in terms of Increasing and Decreasing Orders of 1 to 9 (2014)
#33I just wrote a script to do this in, like, 5 minutes :) And the whole thing runs in 7 seconds on my machine. https://github.com/adtac/123456789/blob/master/output Admittedly, it doesn't have every number. I suspect it's because I haven't included bracketed expressions.
What happens if you allow for 0?
For ascending solution taking a lazy approach, it appears to be a trivial inclusion, considering for any n with a solution using 1-9, a solution which includes 0 will simply take the form:
n = 0 +
n = + 0
1 = ^ 0Re: Numbers 0 to 11111 in terms of Increasing and Decreasing Orders of 1 to 9 (2014)
#34I just wrote a script to do this in, like, 5 minutes :) And the whole thing runs in 7 seconds on my machine. https://github.com/adtac/123456789/blob/master/output Admittedly, it doesn't have every number. I suspect it's because I haven't included bracketed expressions.
3 = 123+4+5-6*7^89 First verifiable instance of error? Did a little fishing for overflow candidates with the following regex: [1-9]{3,}\^[1-9]{3,} ...caught 58 results between 266 and 10940: 266 = 123^456-78-9 ... 10940 = 12345^6789 My kung fu isn't Python so I don't know how types are handled. That eval() function sure smells suicidal for anything remotely serious though.
No, Python doesn't have integer overflow.
"^" is the XOR operator. GP's code has that bug.
> That eval() function sure smells suicidal for anything remotely serious though.
Yes, ast.literal_eval() should be used.
Re: Numbers 0 to 11111 in terms of Increasing and Decreasing Orders of 1 to 9 (2014)
#35Earlier quoted context omitted.
Is that actually why base 10 became the norm? I've never really learned why exactly decimal was chosen, and I'd be interested in learning about what historical evidence there is for its origin.
It's often claimed, but I'm not aware of any strong evidence for it. In particular, since our hands can show "10" the natural base this would imply is base _11_ and not 10. Another argument I've heard presented is that since 10 is divisible by 2 and 5 this simplifies many common calculations. There were groups in the past advocating use of other bases (in particular 12 but also 16). The mayan's number system is base…
>In particular, since our hands can show "10" the natural base this would imply is base _11_ and not 10.
I'd disagree. Having base 10 allows us to easily imagine 60 as 6 people worth of fingers.
Re: Numbers 0 to 11111 in terms of Increasing and Decreasing Orders of 1 to 9 (2014)
#36Earlier quoted context omitted.
There are 10 one-digit numbers in decimal. 0 is excluded because of obvious reasons, leaving numbers 1 through 9.
In other words, yes, we use decimal because we have ten fingers.
Many civilizations used base 12, most probably because you can count 12 phalanges using your thumb.
https://en.wikipedia.org/wiki/Duodecimal
Re: Numbers 0 to 11111 in terms of Increasing and Decreasing Orders of 1 to 9 (2014)
#37Earlier quoted context omitted.
3 = 123+4+5-6*7^89 First verifiable instance of error? Did a little fishing for overflow candidates with the following regex: [1-9]{3,}\^[1-9]{3,} ...caught 58 results between 266 and 10940: 266 = 123^456-78-9 ... 10940 = 12345^6789 My kung fu isn't Python so I don't know how types are handled. That eval() function sure smells suicidal for anything remotely serious though.
No, Python doesn't have integer overflow. "^" is the XOR operator. GP's code has that bug. > That eval() function sure smells suicidal for anything remotely serious though. Yes, ast.literal_eval() should be used.
Ugh, fixed it.
Using * * is not really an option now because it takes insane amounts of time to compute something like `123456789`.
And this is just a tiny script - `eval` shouldn't really be an issue. And yes, I know it's evil, generally. But if you think about it, Python itself is just one big eval loop :P
Re: Numbers 0 to 11111 in terms of Increasing and Decreasing Orders of 1 to 9 (2014)
#38Re: Numbers 0 to 11111 in terms of Increasing and Decreasing Orders of 1 to 9 (2014)
#39I just wrote a script to do this in, like, 5 minutes :) And the whole thing runs in 7 seconds on my machine. https://github.com/adtac/123456789/blob/master/output Admittedly, it doesn't have every number. I suspect it's because I haven't included bracketed expressions.
I think a good idea might be to do it for postfix/prefix notation, rather than infix. This will also get rid of the need for parentheses.
Re: Numbers 0 to 11111 in terms of Increasing and Decreasing Orders of 1 to 9 (2014)
#40It wasn't clear why this was interesting from the title. But here's an example: 0 = 12 + 34 − 56 − 7 + 8 + 9. 1 = 1^23456789. 2 = 123+4−56−78+9. 3 = 123 − 45 − 6 − 78 + 9. And then in decreasing order 0 = 98−7−6−54−32+1. 1 = 98−76−54+32+1. 2 = 9+87−65+4−32−1. 3 = 98−76−5+4+3−21. That this is possible at all is counter-intuitive to me, and hence fascinating. Even more fascinating is that he does not have a solution fo…
There's not a lot interesting about "facts about numbers" when you place such a low upper bound on your achievements. If he'd only done this up to 100, he'd never have had trouble finding a solution for 10958. But why 11111? Why not 111111111111? To me this is just as interesting as any other arbitrary list of permutations of symbols.
I assume 111112 is unrepresentable as well?