Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

M Ali Notes _ 7/16/2022 #1

Open
fzghoul86 opened this issue Jul 17, 2022 · 0 comments
Open

M Ali Notes _ 7/16/2022 #1

fzghoul86 opened this issue Jul 17, 2022 · 0 comments

Comments

@fzghoul86
Copy link

I am too lazy to use the Android Debugger Toolkit plus the actual gicisky app in Chinese. Your google translate patience dwarfs mine. So, I'm just going to use the files you've loaded until I give up and bust out google translate.

I am also not exactly sure of the file structure (likely because I'm not running any of your stuff). So I am assuming for the file "black.txt" the content of input is a series of black pixels and the output is the seemingly random string provided.

As mentioned before, I love thinking about these problems but I am extremely bad at actually resolving them. I usually get... within striking distance for someone else, for me its like I'm still randomly groping at darkness when I'm only a few connections away from completion.
But my preferred methodology is make bad random guesses then test against them.

I am not sure how I screwed it up but I copy/pasted some stuff incorrectly, so, will need to re-do the below when I have more energy, I note when I found the error below with asterisks

HYPOTHESIS ONE: The output zeros do not matter or represent placeholders for blocks.
TEST METHOD A: I took files the following files and removed all zeros, leaving the other digits as individual blocks. Any string of zeros is treated the same (e.g. "0" and "000" are removed in a similar fashion). "black," "white," "white-black", "black-white", "red"
FINDINGS:
-The number of blocks of continuous non-zero digits varies by input
--black = 1919
--white = 1930
--white-black = 60
--black-white = 60
--red = 54
OBSERVATIONS:
-First non-0 block of digits for these 5 files is "983a"
-For all three single color lines the second block of digits is "75124"
-For both the alternating color lines the second block of digits is "751d4"
-"red" and "black" are identical for the first 54 non-zero blocks; red only has 54 non-zero blocks
-black has non-zero blocks following the same pattern (1, 8, 38, 75124) repeated until the last three blocks which are (7511181, 8, e).
-white has non-zero blocks following the same pattern (1 , 8, ffffffff, 38ffffffff75124) repeated. The 3rd block +1 = 00000000, if you restrict it to one byte. That leaves us with 3 blocks. The last block has another byte that can have +1 to make its repetitive pattern exactly the same as black. At block 973, this occurs and from then on white and black have an identical pattern. The last three blocks, same as black (7511181, 8, e)
-white-black ends in (2, 2, 8, ffffff, 16, 16ffffffffffffffff). black-white ends in (2, 2, 8, ffff, 16ffffff, 16). [It is at this point I noticed that there was something wrong with my transcription] The actual last sequence for these is... (7511181, 8, e)

TEST METHOD B: Taking the above (incorrectly) processed blocks I did a check to see when the values of the 0-less blocks matched.
FINDINGS:
black = white in 161 of the blocks.
black = white-black in 6
black = black-white in 7
black = red in 54... all 54 of reds blocks
white = white-black in 6
white = black-white in 7 (this was flip flopped from my expectation)
white = red in 27 (exactly half of reds total count)
white-black = black-white in 14 blocks; the first 5 blocks are identical while block 6 is white-black (ffffffff), black-white (15ffffff)... (+15, +11) would align them. After that the pattern looks to match but offset
OBSERVATIONS:
-I need to look at the 0s I pulled out between Red and Black to see if there is a pattern in between each of the blocks.
-I would expect black to share the same or offset by one with black-white and white-black... I expected a higher match but where you see (75124) in black you see (751d4) which is the same as the second block of the respective sets. This is +12.

FURTHER THOUGHTS
-Is back-red and white-red's second non-0 block 751d4?
-Does an all black sequence followed by a single white also generate a 751d4 second block?
-Should that second block be read as an encoding to describe the number of colors or encode simple patterns?
-What is the second block in black-white-red repeating?
-white-black 2x2 checkerboard has a second block of (751d4) as well. I assume this test was across two lines and thus equivalent to white-black? Quick check says yes.
-What is 20px.txt? second block is (75144)
-What is the pathological case described?
-Would want to test a sequence that is all possible colors cycling in sequence by single bit increments. Then same count of each color but randomize the order (test a few sets like this).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant