The New Sudoku Players' Forum

[tarek]

Code: Select all

+-------+-------+-------+
| . 5 . | 2 . 9 | . 4 1 |
| 9 . . | . . . | 8 . . |
| . . . | . 5 . | . 6 . |
+-------+-------+-------+
| 1 . . | . . 2 | . . 4 |
| . . 7 | . . . | 1 . . |
| 8 . . | 3 . . | . . . |
+-------+-------+-------+
| . 7 . | . 4 . | . . 9 |
| 3 . 9 | . . . | . . 7 |
| 2 . . | 7 . . | 5 1 . |
+-------+-------+-------+
.5.2.9.419.....8......5..6.1....2..4..7...1..8..3......7..4...93.9.....72..7..51.


Play this puzzle online

Download Sukaku Explainer

[SpAce]

Code: Select all

.--------------------.----------------.----------------.
| a6-7  5      368   | 2    378  9    | f37   4    1   |
|  9    1234   1234  | 146  137  167  |  8    57  e235 |
|  47   12348  12348 | 148  5    178  |  9    6   e23  |
:--------------------+----------------+----------------:
|  1    369    356   | 58   78   2    |  367  579  4   |
|  45   23     7     | 9    6    45   |  1    23   8   |
|  8    2469   2456  | 3    17   1457 |  267  579  56  |
:--------------------+----------------+----------------:
| b56   7      1568  | 168  4    1368 | c236  23   9   |
|  3    16     9     | 156  2    156  |  4    8    7   |
|  2    468    468   | 7    9    368  |  5    1   d36  |
'--------------------'----------------'----------------'

(6)r1c1 = r7c1 - r7c7 = (6-3)r9c9 = r23c9 - (3=7)r1c7 => -7 r1c1; stte

[Cenoman]

Code: Select all

 +-----------------------+---------------------+--------------------+
 |  67   5       368     |  2     378   9      | c37    4     1     |
 |  9    1234    1234    |  146  a137  a167    |  8    b57    235   |
 | f47   12348   12348   |  148   5     18-7   |  9     6     23    |
 +-----------------------+---------------------+--------------------+
 |  1    369     356     |  58    78    2      | d367   579   4     |
 | f45   23      7       |  9     6     45     |  1    d23    8     |
 |  8    2469    2456    |  3     17    1457   | d267   579   56    |
 +-----------------------+---------------------+--------------------+
 | f56   7       1568    |  168   4     1368   | e236   23    9     |
 |  3    16      9       |  156   2     156    |  4     8     7     |
 |  2    468     468     |  7     9     368    |  5     1     36    |
 +-----------------------+---------------------+--------------------+

(7)r2c56 = r2c8 - r1c7 = (7-236)b6p157 = r7c7 - (6=457)r357c1 => -7 r3c6; ste

[SteveG48]

Code: Select all

 *----------------------------------------------------------------------*
 | 67     5      368    | 2     e378    9      |ace37     4      1      |
 | 9      1234   1234   | 146    137    167    |   8      57   bc235    |
 | 47     12348  12348  | 148    5      178    |   9      6    bc23     |
 *----------------------+----------------------+------------------------|
 | 1      369    356    | 58    d78     2      |  d367    579    4      |
 | 45     23     7      | 9      6      45     |   1      23     8      |
 | 8      2469   2456   | 3      17     1457   |   267    579   c56     |
 *----------------------+----------------------+------------------------|
 | 56     7      1568   | 168    4      1368   |   236    23     9      |
 | 3      16     9      | 156    2      156    |   4      8      7      |
 | 2      468    468    | 7      9      368    |   5      1      36     |
 *----------------------------------------------------------------------*


(7=3)r1c7 - r23c9 = (256)r236c9&3r1c7 - (3|6=78)r4c57 - (8=37)r1c57 => -7 r1c1 ; stte

[SpAce]

Hi Steve,

(256)r236c9&3r1c7

That's a prime example of the readability problem with the '&' I've been talking about, most recently in my reply to your comment. That dual node looks like one big blob to me, because there are no clearly visible boundaries between the ANDed parts. As the simplest fix, I would suggest adding parentheses to the second part too to make it more readable: (256)r236c9&(3)r1c7. Not perfect, but much better, I think. (It's also the most in line with actual Eureka standards.)

Brackets don't fix all problems with the '&', though, which is why I'm investigating other possibilities to replace that problematic symbol. Not in Eureka, though. I think that language should be frozen with the current syntax rules instead of introducing any big changes. That's why I'm working on a completely new language, so that I don't have to worry about the legacy baggages of Eureka.

Thus, when you see me test non-standard language features, such as the dot and the new semantics of the comma, they're not Eureka nor am I suggesting them for it either. I'm just testing different possibilities to find a set of symbols and semantics I would actually like.

Of course, nothing is perfect from all points of view. Some compromises must be made between readability, backwards compatibility, intuitiveness, compactness, etc. The one that I won't easily give up is readability, and it pretty much guarantees that the '&' must go. How exactly it will be replaced in all situations is still a bit open. For that I'm welcoming feedback.

[SteveG48]

How about ((256)r236c9)&(3r1c7) ?

I'm not sure why you're so hard over against & . The one thing that I will never give up is unambiguity. Even readability must give way to that.

[SpAce]

How about ((256)r236c9)&(3r1c7) ?

It's definitely more readable than even my quick-fix suggestion. The price is four more characters (while mine had only two extras). For that same price you could use white space too, which easily trumps both:

Code: Select all

((256)r236c9 & 3r1c7)

((256)r236c9)&(3r1c7)

(256)r236c9&(3)r1c7..
---------------------

(256)r236c9&3r1c7....

I don't really see why you'd rather use the cluttered option for the same price. Of course, the most readable options add no extra characters at all:

Code: Select all

(256)r236c9.3r1c7.... (non-standard)

(256)r236c9,3r1c7....


I'm not sure why you're so hard over against & .

Because it forces one to choose between readability and consistency+compactness. None of the other commonly used symbols require any tricks that sacrifice compactness to maintain readability. Compare these:

Code: Select all

(256)r236c9&3r1c7
(256)r236c9|3r1c7
(256)r236c9,3r1c7
(256)r236c9.3r1c7
(256)r236c9_3r1c7
(256)r236c9'3r1c7
(256)r236c9:3r1c7
(256)r236c9;3r1c7
(256)r236c9+3r1c7
(256)r236c9°3r1c7
(256)r236c9*3r1c7


Any of those other symbols is a much more readable separator than the '&'. On the other hand, the ones in the same league with it are:

Code: Select all

(256)r236c9&3r1c7
(256)r236c9@3r1c7
(256)r236c9#3r1c7
(256)r236c9%3r1c7
(256)r236c9?3r1c7
(256)r236c9§3r1c7

In other words, any symbol that fills the whole space is a poor separator.

(Regardless of the separator, I'm not the biggest fan of the asymmetric use of brackets around digits. I'd rather have either 256r236c9.3r1c7 or (256)r236c9.(3)r1c7. I think both are more readable than (256)r36c9.3r1c7. I used to hate all use of unbracketed digits, but I've somewhat changed my mind about that, and even started using them at times. In fact, 'no brackets' is the standard convention in my new language.)

The one thing that I will never give up is unambiguity. Even readability must give way to that.

You should know me well enough to not doubt that we're in full agreement there. There's no ambiguity here. The semantics I'm currently testing are unambiguously incompatible with Eureka. I repeat myself but I'm not suggesting any such changes to Eureka. That wouldn't make any sense at this point.

I can, however, create any kinds of syntax rules for my own language, and they will certainly be unambiguous in that context. What I'm requesting is help with choosing the best available symbols and semantics without any regard for current Eureka standards. What's best is of course subjective and dependent on one's goals. One of mine is readability, so it's a high-priority target.