The New Sudoku Players' Forum

[SpAce]

Code: Select all

......2...87..1.94...39...1.725...6.4...7...2.1...348.9...35...73.4..92...6......

(Another Hodoku-generated puzzle.)

[Cenoman]

Code: Select all

 +------------------------+-------------------------+-------------------------+
 |  1356   4569   13459   |  678     4568   4678    |  2       357     3568   |
 |  2356   8      7       | a26     a256    1       | a356     9       4      |
 |  256    2456   45      |  3       9     b24678   |  5678    57      1      |
 +------------------------+-------------------------+-------------------------+
 |  38     7      2       |  5      e148    48      | f1-3     6       9      |
 |  4      69     38      |  1689    7      689     |  135     135     2      |
 |  56     1      59      |  269     26     3       |  4       8       7      |
 +------------------------+-------------------------+-------------------------+
 |  9      24     148     |  12678   3      5       |  1678    147     68     |
 |  7      3      158     |  4      d168   d68      |  9       2       568    |
 |  1258   245    6       |  12789  d128   c2789    |  13578   13457   358    |
 +------------------------+-------------------------+-------------------------+

(356=2)r2c457 - r3c6 = r9c6 - (268=1)b8p568 - r4c5 = (1)r4c7 =>-3r4c7; ste

[SteveG48]

Code: Select all

 *--------------------------------------------------------------------*
 | 1356   4569   13459  | 678    4568   4678   | 2      357    3568   |
 | 2356   8      7      |e26   cd256    1      |e356    9      4      |
 | 256    2456   45     | 3      9      24678  | 5678   57     1      |
 *----------------------+----------------------+----------------------|
 | 38     7      2      | 5    af148  af48     |f13     6      9      |
 | 4      69     38     | 1689   7      689    | 135    135    2      |
 | 56     1      59     |d269  cd26     3      | 4      8      7      |
 *----------------------+----------------------+----------------------|
 | 9      24     148    | 12678  3      5      | 1678   147    68     |
 | 7      3      158    | 4     b168   b68     | 9      2      568    |
 | 1258   245    6      | 12789 b128    2789   | 13578  13457  358    |
 *--------------------------------------------------------------------*


(8=14)r4c56 - (1=268)b8p568 - 2r26c5 = (56)r26c5&2r6c4 - (2|5=36)r2c47 - (3=148)r4c567 => -8 r4c1,r5c46 ; stte

[eleven]

I tried to find something from the 5 digits in the # marked cells, but ended up in a 4-way Kraken of r9c1:

Code: Select all

 *----------------------------------------------------------------------------*
 |  1356   4569   13459   |  678     4568   4678    |  2       357     3568   |
 |  2356   8      7       |  26      256    1       |  356     9       4      |
 |  256    2456   45      |  3       9      24678   |  5678    57      1      |
 |------------------------+-------------------------+-------------------------|
 | d38     7      2       |  5       48-1   48      | d13      6       9      |
 |  4      69     38      |  1689    7      689     |  135     135     2      |
 |c#56     1      59      |  269   c#26     3       |  4       8       7      |
 |------------------------+-------------------------+-------------------------|
 |  9      24     148     |  12678   3      5       |  1678    147     68     |
 |  7      3     a158     |  4     b#168   b68      |  9       2       568    |
 | #1258   245    6       |  12789 b#128    2789    |  13578   13457   358    |
 *----------------------------------------------------------------------------*

- 1r9c1 - r8c3 = 1r8c5
- 2r9c1 - (2=1)b8p568
- 5r9c1 - (5=2)r6c25 - (2=1)b8p568
- 8r9c1 - (8=1)r4c17
=> -1r4c5, stte

Nice chain by Cenoman. Alternatively you can go this way:
(1=682)b8p568 - r9c6 = r3c6 - r3c12 = (2-3)r2c1 = 31r24c7 => -1r4c5

Steve's chain could be shortened to
(1=268)b8p568 - 2r26c5 = (56)r26c5&2r6c4 - (2|5=36)r2c47 - (3=1)r4c7 => -1r4c5

[SpAce]

Nice chain by Cenoman. Alternatively you can go this way:
(1=682)b8p568 - r9c6 = r3c6 - r3c12 = (2-3)r2c1 = 31r24c7 => -1r4c5

Nice! I'd naturally be tempted to compress it a bit:

(1682)b8p5689 = r3c6 - (23)r2c541 = (31)r24c7 => -1 r4c5

[eleven]

ouch

Don't see the link (1682)b8p5689 = r3c6

(1682)b8p5689 can be

(168)b8p568 & 2b8p9, if not => 2r3c6
or
(168)b8p569 & 2b8p8, if not, what?

[SpAce]

Don't see the link (1682)b8p5689 = r3c6

I'm glad you brought that up! I debated with myself about the same before posting. In my notes I wrote it with the comma (168,2)b8p5689 which at least should work, but then looked for an excuse to remove it. Somehow I convinced myself that it was ok, but I'm going to need more coffee before I can even attempt to defend that position It's quite possible that I screwed up, and I think we can assume that for now.

Added.

(1682)b8p5689 can be

(168)b8p568 & 2b8p9, if not => 2r3c6
or
(168)b8p569 & 2b8p8, if not, what?

2r3c6 still happens because this is true in both cases:

(1682)b8p5689 = (7|9-2)r9c6 = r3c6

So, the link (1682)b8p5689 == (2)r3c6 is valid, but the question is whether it can be expressed as a direct link or not. I think my reasoning for accepting it was that we could see 2r3c6 as an external spoiler to the four-cell ALS (or AHS). If it's not true then we have (1682)b8p5689 and it doesn't matter which way the digits are -- the 1s are locked to point to the elimination anyway. That's why we don't technically need the comma, I think. In any case the compressed chain is probably more readable if we reverse it:

(13)r42c7 = (32)r2c145 - r3c6 = (2681)b8p9658 => -1 r4c5

That's how I originally wrote it -- I just flipped it to match your orientation. From that POV the last link seems quite all right, but it's never a guarantee that it works both ways. That's why I did try to think it through, but logic holes are still possible. What do you think? (Let's skip the debate about stylistic preferences -- I'm only concerned about the correctness. For clarity reasons I wouldn't mind adding the comma anyway, but I find it an interesting question whether it's really needed or not.)

[eleven]

Ah ok, as tired i was, i did not check, that the only possibility to avoid 1268 in the 4 cells is, to have another digit (especially not 2) in r9c6.
This is the information, which your abbreviated link keeps secret. Correct and bitchy.

Again it reminds me on the International Obfuscated C Code Contest.
Yours is a Contest for Obfuscated AIC chains.

Personally i am already saturated with a single example from both contests.
A C Code sample is the program:

Code: Select all

char O,o[];main(l){for(;~l;O||puts(o))O=(O[o]=~(l=getchar())?4<(4^l>>5)?l:46:0)?-~O&printf("%02x ",l)*5:!O;}


It prints a hexdump (hexadecimal ascii codes) plus printable characters of an input file. Clear and brief. A normal implementation probably would use 20 to 30 lines.

E.g. if you feed it with a jpg picture the output might start with

Code: Select all

ff d8 ff e0 00 10 4a 46 49 46 00 01 01 01 00 48 ......JFIF.....H
00 48 00 00 ff e1 15 ca 45 78 69 66 00 00 4d 4d .H......Exif..MM
00 2a 00 00 00 08 00 0b 01 0f 00 02 00 00 00 08 .*..............
00 00 00 92 01 10 00 02 00 00 00 09 00 00 00 9a ................
01 12 00 03 00 00 00 01 00 01 00 00 01 1a 00 05 ................
00 00 00 01 00 00 00 a4 01 1b 00 05 00 00 00 01 ................
00 00 00 ac 01 28 00 03 00 00 00 01 00 02 00 00 .....(..........
01 31 00 02 00 00 00 0e 00 00 00 b4 01 32 00 02 .1...........2..
00 00 00 14 00 00 00 c2 02 13 00 03 00 00 00 01 ................
00 01 00 00 87 69 00 04 00 00 00 01 00 00 00 d6 .....i..........
88 25 00 04 00 00 00 01 00 00 03 82 00 00 04 52 .%.............R
73 61 6d 73 75 6e 67 00 53 4d 2d 47 39 35 30 46 samsung.SM-G950F
00 00 00 00 00 48 00 00 00 01 00 00 00 48 00 00 .....H.......H..
00 01 47 39 35 30 46 58 58 55 31 43 52 42 37 00 ..G950FXXU1CRB7.
32 30 31 38 3a 31 30 3a 31 35 20 30 39 3a 31 31 2018:10:15 09:11
3a 31 31 00 00 20 82 9a 00 05 00 00 00 01 00 00 :11.. ..........


[SpAce]

Correct and bitchy.

Ok, thanks!

Again it reminds me on the International Obfuscated C Code Contest.
Yours is a Contest for Obfuscated AIC chains.

Not even close. Inaccurate analogies aren't really helpful. There's a big difference in using advanced language features and idioms to achieve tangible benefits (such as brevity, efficiency, elegance, and most importantly learning) and intentionally obfuscating code for the sake of itself.

There's also a big difference in the languages themselves. C has few safeguards and many questionable features to make obfuscation (and mistakes) too easy, which is why writing readable C code takes both skill and discipline. (Of course writing single-line programs like your example takes even more skill.) Eureka, on the other hand, is such a simple and inflexible language that it's very hard to obfuscate even on purpose. Or can you prove me wrong? Can you show me an example of a valid AIC that is actually hard to understand?

Added:

A C Code sample is the program:

Code: Select all

char O,o[];main(l){for(;~l;O||puts(o))O=(O[o]=~(l=getchar())?4<(4^l>>5)?l:46:0)?-~O&printf("%02x ",l)*5:!O;}

It prints a hexdump (hexadecimal ascii codes) plus printable characters of an input file. Clear and brief. A normal implementation probably would use 20 to 30 lines.

I tried to make some sense of that with my practically non-existent C experience. It wasn't easy, even though that's probably quite a simple example. There are still many things I don't understand, mainly because being used to type-safe languages (especially Java) I don't really get C's happy mix-up of ints, chars, strings, arrays, pointers, etc (and worst of all booleans). Anyway, at least I think I got the wonderfully nested ternary operators translated into ifs, and got rid of any compiler warnings:

Initial deciphering: Show

Code: Select all

// Original:
// char O,o[];main(l){for(;~l;O||puts(o))O=(O[o]=~(l=getchar())?4<(4^l>>5)?l:46:0)?-~O&printf("%02x ",l)*5:!O;}

#include <stdio.h>

char c = 0; // originally: O
char a[1];  // originally: o

int main(int argc, char *argv[]) {

   a[0] = 0;

   for (int l = 0; l != EOF;) {
      l = getchar();
      if (l != EOF) {
         if (((l >> 5) ^ 4) > 4) {
            c[a] = l;
         } else {
            c[a] = '.'; // originally: 46
         }
         c = -~c & (printf("%02x ", l) * 5);
      } else {
         c[a] = 0;
         c = !c;
      }
      if (c == 0) {
         puts(a);
      }
   }

   return 0;
}

Now there might be some hope to see what it's actually doing.

Added 2. I think I mostly figured it out. Well, I don't really understand at all how it's using the array all backwards (*), but it seems to work anyhow (because it's C). Here's a bit cleaner translation, I think (and hopefully bug-free this time):

Code: Select all

#include <stdio.h>
#include <ctype.h>
#define BUFFER_SIZE 16

char buf[BUFFER_SIZE];

int main() {

   for (int c=getchar(), n=0; c!=EOF; c=getchar(), n=(n+1)%BUFFER_SIZE) {
      printf("%02x ", c);
      buf[n] = isprint(c) ? (char)c : '.';
      n < (BUFFER_SIZE-1) ? buf[n+1]='\0' : puts(buf);
   }
   puts(buf);   

   return 0;
}

Thanks for this example! As a result my C programming skills just multiplied Obfuscation can be a useful learning tool, too.

(*) Well, it wasn't a total surprise, as I figured it had something to do with C's weird pointer arithmetic, but still very unintuitive. As mentioned here, "it is invaluable if you want to compete in the obfuscated C contest".