[Community Puzzle] Tricky Number Verifier

Puzzles
#1

Coding Games and Programming Challenges to Code Better

Send your feedback or ask for help here!

Created by @slogslog,validated by @FredericLocquet,@jordan_codingame and @Kktus.
If you have any issues, feel free to ping them.

#2

I’m very surprised by this puzzle, in two ways.

(1) No one learnt nothing from the Y2K bug?

About the two-digit year YY,

98 = 1998
99 = 1999
00 = 2000 (fine, because it is defined in puzzle)
01 = 2001 
02 = 2002
03 = 2003
(Why "01" is not 1901? Why disallowing a person to live over 100 years?)
...
20 = 2020 or 1920?
21 = 2021 or 1921?
22 = 2022 or 1922?
23 = 2023 or 1923? 
24 = 2024 or 1924?

In real life people may use current year to judge. In a static puzzle it does not work. “current” is a dynamic concept and is always updating but the puzzle will not update itself constantly.

The faulty number design is not from the author. Fair enough. But using a faulty designed number as a puzzle, the puzzle itself should define clearly how to interpretate the year part.

This definition is largely missing.

(2) check digit is not CRC!

The puzzle suggests when the check digit does not match other parts of the data, we should output a “fixed” sting of number by correcting the check digit.

That’s a BIG mistake :x: in the concept or usage of check digit.

When there is unmatch, the error can be in the first 3 digits, can be in the date, can be in the check digit itself, or can be combination of anything above.

Check digit is not CRC which can help to fix data.

Whenever found a broken check digit, the handling is to invalidate the whole data. No one should attempt to “fix” any part of the data.

I hope no one, particularly fresh learners, would get mis-conception after doing this puzzle.

4 Likes
#3

(1) Mate, no one is disallowed to live over 100 years. But… it simply does not make any difference for computing the check digit except for 1900 and 2000, and this is mentioned in the puzzle as you said.
Process the algorithm for all the years you have above 22 = 2022 or 1922? … it does not make any difference for the check digit.

(2) I guess this is some misunderstanding concerning “error”. The birthdate is defined by the very last 6 digits, you can use both, either 19 or 20 for the year. There cannot be any “error” in this.
And it is just a part of the algorithm that if the check digit returns 10, the first-3-digit number must be increased. This is no BIG mistake just part of the algorithm.:wink:

Seems there is no translation in English. But this algorithm and the tricky thing with increasing the 3-digit number in case of % 11 = 10 is the official practice and the reason why I called the riddle Tricky Number Verifier.

Did this help, mate?

1 Like
#4

Hi,
All tests are corrects but validator #2 is not. Any idea why ?
Thanks

1 Like
#5

Validator #2 contains different invalid characters then test 2. Nothing else is special.

Are you properly checking that the string is 10 characters long AND contains only digits AND the very first digit is no 0?

#6

I think I am :

    ok = 1
    for e in number: # vĂŠrification des nombres
        if not e.isnumeric():
            ok=0
    if len(number)!=10 or ok == 0 or number[0]=="0":
        print("INVALID SYNTAX")
#7

As far as I know, Python’s isnumeric() is too ‘clever’ for this puzzle, it returns True not only for digits.
E.g.Try this out: print('½'.isnumeric())

2 Likes
#8

Of course but ‘½’ is not a 7-bit ASCII. It should be refused in a puzzle. Moreover:

>>> Fraction('½')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.9/fractions.py", line 115, in __new__
    raise ValueError('Invalid literal for Fraction: %r' %
ValueError: Invalid literal for Fraction: '½'
#9

Same issue with python and Validator 2 here. Tried isnumeric(), isidigit() and some other approaches…

#10

Found the reason. You have to check for the incorrect SYNTAX first, and for the DATE part format after that. Otherwise Validator 2 fails.

1 Like
#11

I tried :

    ok = 1
    for e in number: # vĂŠrification des nombres
        if e not in "1234567890":
            ok=0
    if len(number)!=10 or ok == 0 or number[0]=="0":
        print("INVALID SYNTAX")
    elif not date_ok(annee,mois,jour):
        print("INVALID DATE")
    elif c_digit(number)==number:
        print("OK")
    else :
        #print(number)
        print(c_digit(number))

SYNTAX is first, DATE Second and I don’t use isnumeric() anymore.
Any idea ?

1 Like
#12

I used a function instead of an if tree.

1 Like
#13

This solution works for me, for both the tests and validators.
I only took the “invalid syntax” part; I’d say the problem is elsewhere.

#14

Thanks, I’ll check, but it is difficult since tests are ok…

#15

Just a humble code comment from my side.
The boolean datatype is quite useful to differentiate between True and False even for such simple scenarios.
ok = True is somehow nicer than ok = 1

So it is more professional to write:
ok = True
for e in number: # vĂŠrification des nombres
if e not in “1234567890”:
ok=false
** break** # after setting ok to false you can leave the loop to get a better performance
if len(number)!=10 or ok or number[0]==“0”:
print(“INVALID SYNTAX”)

But also your code works without doubt.

#16

Wow! Interesting! Didn’t know that it is true for fractions! Should have integrated this in validator checks. :wink:

#17

What is the rule, and is it stated in the contribution guidelines about the characters that can/cannot be used in puzzles? Is the reason being that they do not work in certain programming languages, or some other reasons?

1 Like
#18

It’s just because it’s not easy to handle 8-bit ASCII characters or utf-8 characters in some languages, for example in C.
At least, every language knows how to manage 7-bit ASCII.

#19

Ah, ok, thanks for your explanation.

#20

Thank you without your help I would have been stuck for very long !
I agree that this system of date is very weird :face_with_spiral_eyes: