… чтобы постить на него все что в голову пришло, невзирая на полезность и адекватность пришеднего.
Хм… зачем же так строго?) Да конечно перед публикацией все же надо хорошо обдумать все, проверить корректность решения и пр. Но ведь все не просчитаешь, порой нужен свежий взгляд со стороны. Уверен что как статья так и комментарии к ней будут полезны как автору так и многим другим.
Я не отрицаю что надежность хранения данных на CD/DVD оставляет желать лучшего, считаю что, в обозримом будущем, их полностью вытеснят накопители на Flash ну и облака :)
Насколько помню мне помогло такое: лоскут ткани, натер его паста ГОИ (+ по моему маслом еще смачивал). Таким методом мне удалось вручную востановить 2 DVD. Ручной метод требует большого запаса терпения. Также следует помнить что движение лоскута должно быть вдоль радиуса, а не вдоль окружности.
Кто нибудь в курсе кого это высказывание (точную формулировку не помню):
«Только гений может создать машину которой сможет пользоваться любой глупец, глупец же создаст машину которой сможет пользоваться только гений.»
Честно говоря, пока что, я тоже не нашел нормального метода, я просто стараюсь перед каждым комитом (в котором есть значительные изменения) править uml. Мне тоже было бы интересно узнать метод получше)
Считаю что хорошему коду, ну а также и правильной архитектуре всей системы способствует применение таких инструментов как UML. При его использовании — мы можем взглянуть на архитектуру/код с высоты птичьего полета и увидеть многие недостатки (если таковы имеются). Это я обнаружил на собственном примере, когда взглянул на код проекта, который я реализовывал 3 года назад без применения UML. Когда пишешь код, постепенно углубляешься все больше и больше в реализацию, теряя при этом свежий взгляд на систему в целом, что может привести ко многим концептуальным ошибкам.
Возникала подобная мысль, только я хотел использовать хеш-таблицу или что-нибудь подобное для кеширования уже найденных проекций сегментов. Но идею отложил в сторону, так как, пока что не нашел метода, как параллельно, без блокировок, строить кеш.
Если конечно Ваше решение как-нибудь возможно распараллелить, то будет отлично, в противном же случае у нас появится последовательный участок, который, несмотря на то что в последовательном режиме может дать большой прирост всему алгоритму, в параллельном думаю может снизить эффективность (закон Амдаля).
Думаю, скобки удобнее. Да конечно во первых это — привычка, если уже привык к ним, то остальное, наверное, будет казаться уже не столь удобным.
Но тут есть еще второй момент — практичность, т.е. если я, например, захочу по чату передать фрагмент программы, то вся логика может пострадать из-за того что какие-то пробелы/табы проглотились. Т.е. я считаю, что логика программы не должна зависеть от форматирования текста этой программы, потаму что это логически разные понятия, а ввод любой дополнительной зависимости — обычно накладывает дополнительные ограничения.
Скажите, Вы разве ушли куда-то от квадратичной сложности?
Нет конечно, не ушел)
Основной целью было разработать и реализовать алгоритм, который хорошо параллелится. Как я и написал в «Заключении» — алгоритм пришел мне на ум почти сразу же после прочтения условия задачи, конечно это были только наброски, без деталей. После этого удалось более детализировать и более выгодным образом его распараллелить.
И да, важный факт тут, использовать число M, потому как некоторые участники тупо на него забивали, а ведь если это число большое, решение, эффективно использующее M, будет работать куда шустрее.
Кстати, заметил что скорость референсного кода, практичеки, не зависит от M, конечно я понимаю что сравнивать референсный код с реализацией этого алгоритма — не корректно, но всеже это удивило)
Могу ли я вас попросить в конце добавить оценку сложности времени выполнения и потребления памяти для вашего решения, так будет видно ещё больше насколько оно хорошее или плохое в отношении к другим решениям. Спасибо :)
Если допустить, что M — константа (хотя от этого параметра сильно зависит скорость), то, если я не ошибаюсь, суммарная сложность будет:
O((N1 — M + 1) * N2) + O step3 = O(N1 * N2) + O step3, где N1, N2 — длина первой и второй строк соответственно; O step3 — сложность шага 3.
Пока что не могу точно сказать какова сложность шага 3, так как тут идет не совсем прямая зависимость от N1, N2.
Хм… зачем же так строго?) Да конечно перед публикацией все же надо хорошо обдумать все, проверить корректность решения и пр. Но ведь все не просчитаешь, порой нужен свежий взгляд со стороны. Уверен что как статья так и комментарии к ней будут полезны как автору так и многим другим.
«Только гений может создать машину которой сможет пользоваться любой глупец, глупец же создаст машину которой сможет пользоваться только гений.»
Но оптимизация в целом — как же без нее? Порой без нее просто невозможно.
Если конечно Ваше решение как-нибудь возможно распараллелить, то будет отлично, в противном же случае у нас появится последовательный участок, который, несмотря на то что в последовательном режиме может дать большой прирост всему алгоритму, в параллельном думаю может снизить эффективность (закон Амдаля).
Но тут есть еще второй момент — практичность, т.е. если я, например, захочу по чату передать фрагмент программы, то вся логика может пострадать из-за того что какие-то пробелы/табы проглотились. Т.е. я считаю, что логика программы не должна зависеть от форматирования текста этой программы, потаму что это логически разные понятия, а ввод любой дополнительной зависимости — обычно накладывает дополнительные ограничения.
Значит можно считать что статья выполнила все поставленные цели.
Надо будет почитать про BLAST.
Нет конечно, не ушел)
Основной целью было разработать и реализовать алгоритм, который хорошо параллелится. Как я и написал в «Заключении» — алгоритм пришел мне на ум почти сразу же после прочтения условия задачи, конечно это были только наброски, без деталей. После этого удалось более детализировать и более выгодным образом его распараллелить.
Также благодарю Lockal, за то что указал на ошибки пунктуации.
Кстати, заметил что скорость референсного кода, практичеки, не зависит от M, конечно я понимаю что сравнивать референсный код с реализацией этого алгоритма — не корректно, но всеже это удивило)
Если допустить, что M — константа (хотя от этого параметра сильно зависит скорость), то, если я не ошибаюсь, суммарная сложность будет:
O((N1 — M + 1) * N2) + O step3 = O(N1 * N2) + O step3, где N1, N2 — длина первой и второй строк соответственно; O step3 — сложность шага 3.
Пока что не могу точно сказать какова сложность шага 3, так как тут идет не совсем прямая зависимость от N1, N2.