подобное поведение было одной из нескольких особенностей, о наличии которых сообщали владельцы кошкам, наряду с "интересным поведением" и "пониманием всего"
Так кто кому сообщил, простите? Владельцы своим кошкам? =)
Пункт 2 у Вас очень спорный. Вот прислали Вам электронный документ о том, что Вы взяли 2 года назад кредит в банке "Рога и копыта", подписанный ЭЦП, по которому известно что уже полгода есть известный способ взлома. Дата документа - 2 года назад, отправитель говорит "точно-точно, давно не трогал этот документ".
Боюсь я не смог донести мысль. Если я как игрок первый раз выбрал дверь №2. После этого ведущий (не зная моего выбора) открыл эту же дверь №2, за которой ничего не было. После этого шансы будут 50/50, выбрать дверь №1 или дверь №3.
Затем я, как ведущий, попрошу вас выбрать одну из них. К сожалению я не могу узнать ваш выбор, но давайте представим что вы выбрали левую дверь.
Фраза может ввести в заблуждение. Ведущий как раз должен знать первоначальный выбор игрока, так как на следующем шаге он будет открывать ту из "пустых" дверей, которую игрок не выбрал (иначе, если игрок в первый раз выбрал "пустую" дверь, и выбор ведущего совпадёт с выбором игрока, на второй попытке у игрока действительно будут шансы 50/50).
Окей, с чисто теоретической точки зрения, я погорячился, и при константном количестве букв этот множитель сводится к константе. На практике же, константа тоже может существенно повлиять на реальные требования по памяти и CPU.
Иногда оптимизация алгоритма может быть сопряжена с усложнением кода, и приходится выбирать между читабельным и поддерживаемым кодом, с одной стороны, и эффективностью с другой.
Но в данном случае, необходимость для каждой буквы ввода множество сравнений с каждой буквой алфавита - точно будет менее оправдана чем простой поиск по словарю, который будет эффективнее, и при этом описан более простым кодом.
Честно говоря, я бы предпочел в такой ситуации всё равно использовать словарь, пусть даже это повлечёт некоторый оверхед по памяти - так код будет намного проще, а значит меньше шансов накосячить.
Я бы предложил автору скрыть статью в черновики, если есть желание не утонуть в минусах, и переделать код, а заодно занять форматированием и исправлением орфографических ошибок. Заодно можно было бы добавить небольшую историческую справку про сам шифр: как возник, где применялся реально, чтобы статья была интереснее. @HotMilkTicTac
В алгоритме шифрования у вас на каждый символ два вложенных цикла поиска символа в массиве, что делает его чрезвычайно медленным (асимптотика O(n^3), подробнее тут). Я бы рекомендовал обратить внимание на использование словаря, под капотом у которого - хэш-таблица.
Алгоритм дешифрования чересчур громоздкий - что если у вас таблица будет 10х10? А если 128х128? Если вы точно знаете, что на входе - число, тогда его можно разделить на две компоненты, и с помощью int.Parse/int.TryParse получить нужные индексы для нахождения буквы.
Ну и перед публикацией статьи желательно хотя бы выровнять код, который Вы публикуете.
В целом, Вы молодец что изучаете программирование, но технический уровень этой статьи точно не соответствует уровню хабра. Рекомендую найти кого-то, кто бы помог Вам с вычитыванием статьи перед публикацией, ну и в целом в изучении языка C#. Можете писать мне, почта navferty@ymail.com
В случае если речь идет о работе с кодом - да. У меня VSCode чаще используется для просмотра логов, правки конфигов, редактирования json'ов и тому подобных эпизодических задач, а для кода есть полноценная Visual Studio
Вот тоже об этом подумал: "если у Вас настроены бэкапы, но нет регулярной проверки разворачивания БД из бэкапов - то у Вас нет бэкапов"
Шикарная штука. Возможно, сподвигнет меня таки попробовать поиграть в майнкрафт)
А если своей, как будет закон трактовать? Или еще более спорно - сгенерированное нейросеткой изображение?
Так кто кому сообщил, простите? Владельцы своим кошкам? =)
В русском языке есть устоявшееся понятие "форк", слово "вилка" в данном контексте может вызвать лишь недоумение.
Тогда уж не "фильм", а "картину" (впрочем, это слово тоже заимствованное).
Пункт 2 у Вас очень спорный. Вот прислали Вам электронный документ о том, что Вы взяли 2 года назад кредит в банке "Рога и копыта", подписанный ЭЦП, по которому известно что уже полгода есть известный способ взлома. Дата документа - 2 года назад, отправитель говорит "точно-точно, давно не трогал этот документ".
Возможно, имеет смысл уточнить фразу, чтобы она не вводила в заблуждение тех кто читает об этом "парадоксе" впервые
Боюсь я не смог донести мысль. Если я как игрок первый раз выбрал дверь №2. После этого ведущий (не зная моего выбора) открыл эту же дверь №2, за которой ничего не было. После этого шансы будут 50/50, выбрать дверь №1 или дверь №3.
Фраза может ввести в заблуждение. Ведущий как раз должен знать первоначальный выбор игрока, так как на следующем шаге он будет открывать ту из "пустых" дверей, которую игрок не выбрал (иначе, если игрок в первый раз выбрал "пустую" дверь, и выбор ведущего совпадёт с выбором игрока, на второй попытке у игрока действительно будут шансы 50/50).
Выпрос: "А почему люди остались на земле, а не слетели с неё?"
Ответ: "Потому что они прикреплены к поликлинникам"
Окей, с чисто теоретической точки зрения, я погорячился, и при константном количестве букв этот множитель сводится к константе. На практике же, константа тоже может существенно повлиять на реальные требования по памяти и CPU.
Иногда оптимизация алгоритма может быть сопряжена с усложнением кода, и приходится выбирать между читабельным и поддерживаемым кодом, с одной стороны, и эффективностью с другой.
Но в данном случае, необходимость для каждой буквы ввода множество сравнений с каждой буквой алфавита - точно будет менее оправдана чем простой поиск по словарю, который будет эффективнее, и при этом описан более простым кодом.
В дотнете мапа - это и есть словарь. Разница будет в вызове GetHashCode, который делает немного арифметики, а именно
и нахождения в массиве (внутри словаря) значение по полученному индексу, или прямого обращения к массиву в варианте @astec
Честно говоря, я бы предпочел в такой ситуации всё равно использовать словарь, пусть даже это повлечёт некоторый оверхед по памяти - так код будет намного проще, а значит меньше шансов накосячить.
Я бы предложил автору скрыть статью в черновики, если есть желание не утонуть в минусах, и переделать код, а заодно занять форматированием и исправлением орфографических ошибок. Заодно можно было бы добавить небольшую историческую справку про сам шифр: как возник, где применялся реально, чтобы статья была интереснее. @HotMilkTicTac
Ну шифр на то и шифр, что порядок не обязан быть последовательным, как таблице Unicode =)
То что вы перечислили - это не библиотеки, а пространства имён, все они входят в BCL (base class library).
В алгоритме шифрования у вас на каждый символ два вложенных цикла поиска символа в массиве, что делает его чрезвычайно медленным (асимптотика O(n^3), подробнее тут). Я бы рекомендовал обратить внимание на использование словаря, под капотом у которого - хэш-таблица.
Алгоритм дешифрования чересчур громоздкий - что если у вас таблица будет 10х10? А если 128х128? Если вы точно знаете, что на входе - число, тогда его можно разделить на две компоненты, и с помощью int.Parse/int.TryParse получить нужные индексы для нахождения буквы.
Ну и перед публикацией статьи желательно хотя бы выровнять код, который Вы публикуете.
В целом, Вы молодец что изучаете программирование, но технический уровень этой статьи точно не соответствует уровню хабра. Рекомендую найти кого-то, кто бы помог Вам с вычитыванием статьи перед публикацией, ну и в целом в изучении языка C#. Можете писать мне, почта navferty@ymail.com
Зато можно пользоваться Ctrl-W для закрытия вкладки блокнота, аналогично как в браузерах, удобно. В этом случае, кстати, спрашивает.
А что с ним случилось?
Расшифровка
"ползала" не как глагол, а как "половина зала"
В случае если речь идет о работе с кодом - да. У меня VSCode чаще используется для просмотра логов, правки конфигов, редактирования json'ов и тому подобных эпизодических задач, а для кода есть полноценная Visual Studio