Site Information
About Us
- RonPaulForums.com is an independent grassroots outfit not officially connected to Ron Paul but dedicated to his mission. For more information see our Mission Statement.
I would turn over all those mofos and still not be sure the rule is true. (ETA) in the general case, like if they were part of a larger set. But for just those 4 cards, I could confirm true or false by turning them all over.
Last edited by CPUd; 07-30-2015 at 12:46 PM.
Pretty simple process. Experiment, Develop a theory and then try to disprove it.
I assumed it was a doubling, then disproved it. Next theory was "there is no pattern". Tried a couple sequences and saw decreasing ones were not valid.
Next theory, it had to be increasing. Granted I couldn't test infinite patterns which is what you'd need to do to actually prove it, but I tested a few and decided I has enough evidence to go with it being an increasing pattern.
Last edited by brandon; 07-30-2015 at 06:07 PM.
The answer to that one is "E" and "7."
(The "E" card must have an even number on the other side, and the "7" card must not have a vowel on the other side.)
There was another thread a while back that presented the very same problem (in terms colors and numbers):
http://www.ronpaulforums.com/showthr...cal-People-Are
Last edited by Occam's Banana; 07-30-2015 at 02:28 PM.
How do you know there will not be an 'A' on the other side of the '7' ?
Timosman: 2.
And it is not the two that Occam's Banana mentioned.
On the other puzzle: Those of you who thought you were right, were wrong.
If you were right, then this sequence would follow the rule:
121234323432343434343234324234
121234323432343434343234324235
121234323432343434343234324236
Here's a particularly interesting pair:
1234567890123456.123
1234567890123456.223
1234567890123456.323
and
1234567890123456.123
1234567890123456.223
1234567890123456.423
Last edited by Occam's Banana; 07-30-2015 at 02:48 PM.
The Bastiat Collection · FREE PDF · FREE EPUB · PAPER Frédéric Bastiat (1801-1850)
- "When law and morality are in contradiction to each other, the citizen finds himself in the cruel alternative of either losing his moral sense, or of losing his respect for the law."
-- The Law (p. 54)- "Government is that great fiction, through which everybody endeavors to live at the expense of everybody else."
-- Government (p. 99)- "[W]ar is always begun in the interest of the few, and at the expense of the many."
-- Economic Sophisms - Second Series (p. 312)- "There are two principles that can never be reconciled - Liberty and Constraint."
-- Harmonies of Political Economy - Book One (p. 447)· tu ne cede malis sed contra audentior ito ·
"When you think you know the rule, describe it in words below":
Something related to the number incrementing by a minimum amount vs. the previous number AND also the total set incrementing by a certain minimum amount, that is, from the 1st all the way to the 3rd. The minimum is in terms of a fraction of the total number size whatever that number is, not an absolute value.
The minimum is:
Number 2 / Number 1 must be greater than or equal to: 1.0000000000000001 (16 digits, of course)
No, scratch that, it works for 1234567890123456.1255 / 1234567890123456.123, which is less.
Also notably odd, it does not work for 12345678901234561255 / 12345678901234561230 (same thing but without a decimal point).
Well, I can't even figure out the Number 2-to-Number 1 rule, so forget the Number 3-to-Number 1 rule.
But I'm pretty sure there's a rule. That is, there is a hard and fast rule which can in fact be described, and has been described, to the computers involved. The alternative (or at least one alternative) is that there's a human on the other side manually answering yes or no based on a process that may or may not be perfectly based on an unchanging rule. I base this (being pretty sure there's a rule) simply on an empirical knowledge of the practicalities involved. In theory, there could be a human, or any number of other possibilities that would mean there is actually no rule.
Am I weird that when confronted with a problem or puzzle I entertain as one logical possibility that the entire question and its premise may be a lie?
Didn't look at their code, but to test the numbers, they could be using 8-byte ints. For floats, they may not actually be testing floats, but splitting into 2 ints on each side of the decimal point. They would only need to test the right sides if the left sides were equal. If this is the case, the highest int on either side would be 2^64 (unsigned) before overflow occurs.
That would be 18446744000000000000.
But actually, there appears to be no limit whatsoever to the length of the numbers. I did ones with 101 digits and they came up as "Yes!" if I changed the first digit, "No" if I changed the last. It is something with the proportional change in the numbers, not the size of the numbers themselves.
Well, for whatever reason, I went and found the code for it (see near the bottom):
http://graphics8.nytimes.com/newsgra...31f29/build.js
They use Number, which is 64-bit floats. I don't believe it is possible to overflow those until somewhere over 300 digits.
This part checks to see if the input is numeric:Code:var rightWrong = (inputData[0] < inputData[1]) & (inputData[1] < inputData[2]) ? right : wrong;
Code:function checkNumbers() { $("#g-input input").each(function(i) { var val = $(this).val(); inputData[i] = $.isNumeric(val) ? Number(val) : NaN; }); var tot = inputData[0] + inputData[1] + inputData[2]; var broken = isNaN(tot); $('.g-check').prop('disabled', broken); return broken; }
Last edited by CPUd; 07-30-2015 at 04:12 PM.
Yes, this is an awfully strange way to waste time, eh?
Yes, this does seem to be the code, as you say:
var rightWrong = (inputData[0] < inputData[1]) & (inputData[1] < inputData[2]) ? right : wrong;
var rightWrongClass = (inputData[0] < inputData[1]) & (inputData[1] < inputData[2]) ? "g-yes-num-group" : "g-wrong-num-group";
And that seems pretty straightforward. Which leaves us with the question: why are numbers which do follow that rule, namely Number1<Number2<Number3, coming back as "No"? They are not following the actual, underlying rule. They are well within the overflow limits (assuming you're right about the 300 digits). There must be some other more fundamental bug or problem or limitation in the javascript implementation itself, right?
And a very strange one, wherein ...1 ...2 ...3 does not work, but ...1 ...2 ...4 and ...1 ...3 ...4 both do.
"..." means, in this case, at least 15 or 16 digits.
See my post #41. This set:
1234567890123456.123
1234567890123456.223
1234567890123456.323
returns "No."
The trailing 23s are basically irrelevant.
Guess 1: had a theory, tried it, no.
Guess 2: had a theory, tried it, yes.
Guess 3: stayed with theory, tried it, yes.
Guessed the rule, correct.
I started with a complicated theory, and tried to out think it. Then thought it was one of those things where its so simple it's hard, and figured it out.
Having a scientific training background helps. If you can find one example that blows up the hypothesis/theory, that's all you need.
This is because 1234567890123456.223 and 1234567890123456.323 are both stored as 1234567890123456.2 - http://www.w3schools.com/js/js_numbers.asp
https://en.wikipedia.org/wiki/Double...g-point_format.
This gives 15–17 significant decimal digits precision.
Yeah, I was referring more to the values you can give to Number in the constructor without overflowing, but since it's JS, it protects against that to some extent. Giving it a value with somewhere over 308 digits, it will be "Infinity", which is interesting in this problem because they will pass the isNumeric test, though you could give 3 of these numbers in any order and it will fail the right/wrong test because it sees them as equal.
ETA another interesting item:
var y = new Number(100000000000000000000000000000000000000000) ;
var z = new Number(100000000000000000000000000000000000000001) ;
they will both be represented as "1e+41", and
y < z is false
y == z is false
y <= z is true
Last edited by CPUd; 07-31-2015 at 01:07 AM.
Yes, I believe that you are right. Each pair is, indeed, independently determined to follow the rule or not; the set as a whole doesn't matter, it just seemed like that was a possibility due to some of the trials I ran. Even very small increments like 1000000000000000191 to 1000000000000000192 (difference of only 1 in the 19th digit) would show up as following the rule but only if the other increment was significantly larger, e.g. jumping up to 1000000000000000400. In this example, even going up to 1000000000000000300 is not enough. Such behavior could be caused by a complex rule (or a complex glitch) such as I was envisioning. Something like: N2 must be greater than N1 by x, and N3 than N2 by x, and also N3 than N1 by y.
But in this case, it is simply caused by rounding. 1000000000000000191 and 1000000000000000192 happen to be both just barely on opposite sides of the rounding cutoff. So, 1000000000000000191 is rounded to, well, something, and 1000000000000000192 is rounded to something larger. And then the next rounding cutoff doesn't occur until sometime between 1000000000000000300 and 1000000000000000400. So up until then everything is rounded to the same number to which 1000000000000000192 is being rounded.
It can initially seem a strange problem, ...1 ...2 ...3 not working, but ...1 ...2 ...4 and ...1 ...3 ...4 both working. It certainly did to me! But you hit right on the simple answer: the problem is the 1234567890123456.2 to 1234567890123456.3 interval. No series of numbers containing 1234567890123456.2 followed by 1234567890123456.3 will work. I should have thought to test ...0 ...2 ...3 and ...2 ...3 ...9, and I would have come to the right answer much sooner.
Anyway, in the end decimals didn't fool it, negative numbers didn't fool it, and in and of themselves extremely large or extremely small numbers didn't fool it. Only very small differences in the numbers fooled it, due to rounding.
Even infinity does not fool it, as long as a positive infinity is the third number and a negative infinity is the first.
The checker will only allow you to submit numbers with up to a maximum of 309 digits to the left of the decimal place (or 309 digits if an integer) other than leading zeros, which are ignored. The checker probably allows for unlimited digits to the right of the decimal; I tested up to tens of thousands of digits.
Although an entire bit is used storing the sign, a negative number will not always be greater than a positive value. Negative very-small-number and positive very-small-number will count as equal, presumably because both are rounded to zero which has no sign. While infinity is a thing(in this code/rule), infinitesimal is not.
So, the rule is:
The value of each number as rounded by the javascript computation system must be greater than the value of the preceding number as rounded by the javascript computation system.
The rule could be stated more precisely by someone with a better knowledge of precisely how javascript's floating point arithmetic functions.
No, but understanding that WHEN forum users answer these questions unconditionally, YES, they are definitely NOT covert manipulators infiltrating the forum, IS POLITICAL NEWS.
Do you agree and accept that the framers of the founding documents intended for us to alter or abolish government destructive to our unalienable rights?
Do you agree and accept that the ultimate purpose of free speech is to enable the unity adequate to effectively alter or abolish?
You always want what you need, but do not always need what you want.
People that do not want what they need, have a problem.
Can we stop doing all of the things we are doing that we do not want to do while still doing what we need to do?
Connect With Us