DM
круто конечно, где-то видел РКА, но не помню где))
Size: a a a
2020 June 25
IP
Насколько мне известно РП ДРН не инетгрирован с ИС АР, поэтому у них только свои МВД-шные коды, КАТО тоже нет у них. ГБД ФЛ в себе содержит только те данные, которые им передает РП ДРН
N
N
BA
Круто спасибо. Это то что нужно. Если есть посвежее буду признателен.
AK
Ivan Priimak
Насколько мне известно РП ДРН не инетгрирован с ИС АР, поэтому у них только свои МВД-шные коды, КАТО тоже нет у них. ГБД ФЛ в себе содержит только те данные, которые им передает РП ДРН
Иван, разве в 2016 не начинали? или так и забросили интеграцию с АР?
N
ага, там много еще что оптимизировать можно:
- избавиться от int[] digits = new int[12];
- избавиться от взятия остатка в выражении t = (i + 3) % 11;
- вместо substring использовать charAt
- избавиться от int[] digits = new int[12];
- избавиться от взятия остатка в выражении t = (i + 3) % 11;
- вместо substring использовать charAt
все-таки оптимизировал
https://github.com/Nyquest/iin_validator
Две версии валидатор ИИНа: старая и оптимизированная.
С 17 миллионами ИИН OldValidator справился за ≈ 50 секунд, FastValidator справился за ≈ 0.7 секунды.
Ускорение в 70 раз.
https://github.com/Nyquest/iin_validator
Две версии валидатор ИИНа: старая и оптимизированная.
С 17 миллионами ИИН OldValidator справился за ≈ 50 секунд, FastValidator справился за ≈ 0.7 секунды.
Ускорение в 70 раз.
AK
все-таки оптимизировал
https://github.com/Nyquest/iin_validator
Две версии валидатор ИИНа: старая и оптимизированная.
С 17 миллионами ИИН OldValidator справился за ≈ 50 секунд, FastValidator справился за ≈ 0.7 секунды.
Ускорение в 70 раз.
https://github.com/Nyquest/iin_validator
Две версии валидатор ИИНа: старая и оптимизированная.
С 17 миллионами ИИН OldValidator справился за ≈ 50 секунд, FastValidator справился за ≈ 0.7 секунды.
Ускорение в 70 раз.
проверки не работают на 100%
AK
Но такой подход к делу мне нравится
IP
Иван, разве в 2016 не начинали? или так и забросили интеграцию с АР?
Сейчас не могу точно сказать. Примерно год назад был на совещании в МВД, тогда они задавались вопросом интеграции с ИС АР, т.е. на тот момент точно не было интеграции и они не знали как начать из-за некоторых своих внутренних проблем с историческими адресами. Они хотели с помощью интеграции все автоматом синхронизировать. Мы по своему опыту им говорили, что 100% автоматом не получится. А как в итоге после у них продвинулись дела в этом направлении, я не вкурсе
2020 June 26
AZ
все-таки оптимизировал
https://github.com/Nyquest/iin_validator
Две версии валидатор ИИНа: старая и оптимизированная.
С 17 миллионами ИИН OldValidator справился за ≈ 50 секунд, FastValidator справился за ≈ 0.7 секунды.
Ускорение в 70 раз.
https://github.com/Nyquest/iin_validator
Две версии валидатор ИИНа: старая и оптимизированная.
С 17 миллионами ИИН OldValidator справился за ≈ 50 секунд, FastValidator справился за ≈ 0.7 секунды.
Ускорение в 70 раз.
1. Попробуйте ещё строку сразу преобразовать в char[] - обращение к элементам массива работает быстрее чем вызов метода charAt, хоть и не на много.
2. После базовой проверки конвертните массив в byte[], чтобы считать было проще.
3. Проверку високосного года сделайте через полноценные числа, а то так сразу и не поймёшь, что там происходит.
2. После базовой проверки конвертните массив в byte[], чтобы считать было проще.
3. Проверку високосного года сделайте через полноценные числа, а то так сразу и не поймёшь, что там происходит.
N
1. Попробуйте ещё строку сразу преобразовать в char[] - обращение к элементам массива работает быстрее чем вызов метода charAt, хоть и не на много.
2. После базовой проверки конвертните массив в byte[], чтобы считать было проще.
3. Проверку високосного года сделайте через полноценные числа, а то так сразу и не поймёшь, что там происходит.
2. После базовой проверки конвертните массив в byte[], чтобы считать было проще.
3. Проверку високосного года сделайте через полноценные числа, а то так сразу и не поймёшь, что там происходит.
по 1-му пункту charAt быстрее, внутри String свой chars
AZ
по 1-му пункту charAt быстрее, внутри String свой chars
Эт смотря сколько раз вызывать. Всё-таки это вызов метода, который приводит к дополнительным операциям со стеком. Т.е. если сравнивать один вызов, то да, charAt будет быстрее, но если у вас charAt вызывается в три раза больше, чем вообще длина строки, то это будет медленнее. Но опять же - разница будет не велика на строке в 12 символов.
N
Эт смотря сколько раз вызывать. Всё-таки это вызов метода, который приводит к дополнительным операциям со стеком. Т.е. если сравнивать один вызов, то да, charAt будет быстрее, но если у вас charAt вызывается в три раза больше, чем вообще длина строки, то это будет медленнее. Но опять же - разница будет не велика на строке в 12 символов.
если String конвертить в char[]
через toCharArray(), то это дополнительное выделение памяти и замедление, что, мне кажется, хуже чем использование charAt. Обычно charAt всегда дает ускорение.
через toCharArray(), то это дополнительное выделение памяти и замедление, что, мне кажется, хуже чем использование charAt. Обычно charAt всегда дает ускорение.
AZ
если String конвертить в char[]
через toCharArray(), то это дополнительное выделение памяти и замедление, что, мне кажется, хуже чем использование charAt. Обычно charAt всегда дает ускорение.
через toCharArray(), то это дополнительное выделение памяти и замедление, что, мне кажется, хуже чем использование charAt. Обычно charAt всегда дает ускорение.
Чтобы не быть голословным, на выходных погоняю бенчмарки двух решений. Аж самому стало интересно. Будет ли профит на таких малых числах в масштабе миллиона иинов.
N
1. Попробуйте ещё строку сразу преобразовать в char[] - обращение к элементам массива работает быстрее чем вызов метода charAt, хоть и не на много.
2. После базовой проверки конвертните массив в byte[], чтобы считать было проще.
3. Проверку високосного года сделайте через полноценные числа, а то так сразу и не поймёшь, что там происходит.
2. После базовой проверки конвертните массив в byte[], чтобы считать было проще.
3. Проверку високосного года сделайте через полноценные числа, а то так сразу и не поймёшь, что там происходит.
по 2-му пункту не очень понял идею, массивов не осталось.
по 3-му пункту главное было ускориться)
по 3-му пункту главное было ускориться)
AZ
по 2-му пункту не очень понял идею, массивов не осталось.
по 3-му пункту главное было ускориться)
по 3-му пункту главное было ускориться)
В общем на выходных сделаю эти решения и погоняю тесты. Там будет видно, есть ли смысл в моих словах или это просто бред.
N
проверки не работают на 100%
проверки работают, просто ИИНы некорректные выдает ФЛ, как ты мне написал (даты рождения некорректные и даже контрольные суммы).
Поэтому в реальных проектах лучше только проверять на 12 цифр и все
Поэтому в реальных проектах лучше только проверять на 12 цифр и все
TN
проверки работают, просто ИИНы некорректные выдает ФЛ, как ты мне написал (даты рождения некорректные и даже контрольные суммы).
Поэтому в реальных проектах лучше только проверять на 12 цифр и все
Поэтому в реальных проектах лучше только проверять на 12 цифр и все
проверки работают, только результат ничего не значит)
ES
проверки работают, просто ИИНы некорректные выдает ФЛ, как ты мне написал (даты рождения некорректные и даже контрольные суммы).
Поэтому в реальных проектах лучше только проверять на 12 цифр и все
Поэтому в реальных проектах лучше только проверять на 12 цифр и все
законом структура оговорена только для БИНов, так что я не знаю на основе какого закондательного акта вы проверяете структуру ИИНа. Вообще ИИН - это сейчас просто рандомно сгенерированный id у которого есть один признак - контрольный 12 разряд. То что в МВД используют алгоритм который они там лет 20 назад придумали и не переписали, не означает что завтра он может не поменяться