Блин тогда я жёстко затупил в ответе, я почему-то решил, что первое число не длина маршрута, а их количество. Сбило ваше указание "(маршруты, если их несколько)". Зачем тогда это? Или условие было на вашем сайте изначально другое?
Мда, вот косяк…
В любом случае длина маршрута однозначно вычисляется количеством последующих 12-байтных узлов, но при вашей «автоматизированной» обработке оно не проканает, да, потому что у меня первые 4 байта другие.
Хотя оно в любом случае не проканало бы, потому что сейчас проверил, Java через DataOutputStream.writeInt пишет целое число с обратным порядком байт: «00 00 00 01», о чём я вам и говорил выше, собственно. Надо чётко определять подобные тонкости :\
На самом деле оказалось, что вышеобсуждаемых проблем нет в принципе :) И если бы вы сразу сказали сколько точно должно быть маршрутов (а их достоверно точно можно посчитать), то ничего из того, что писалось выше никому не пришло бы в голову писать. Верно ведь?
Честно пытался начать делать задачу. Даже файл распарсил и составил мэпы по входам/выходам. Замутить поиск по дереву с сохранением длины маршрутов пар вершин теперь дело техники (лаба 1-2 курса универа).
На самом деле это средней сложности задача на графы. Но с заковыками и непонятками. За интерес в такое играть неохота. Соревноваться конечно круто, но смысл в чём? Таких задач можно сотни придумать. К тому же задание слишком некорректно, особенно с учётом того, что «обработка будет автоматически». Что значит «4 байта длина маршрута», как оно кодируется? В каком порядке байтов? От старшего к младшему? Или наоборот? Допустим, я пишу на Java и читаю четырёхбайтовый int через DataInputStream, есть сомнение, что мой бинарный вывод будет такой же как у вас в вашей платформе.
Про нечёткость определения маршрутов выше сказано. При недостаточно разреженном графе маршрутов будет и правда если не бесконечное количество, то достаточно неопределённое. При наличии зацикленных тоже непонятно, каждый цикл добавляет кучу маршрутов. А если зацикленный маршрут самый длинный, то сколько их? Столько, сколько вершин в этом цикле? Как-то нелогично это всё, имхо.
А тематика и содержание статей нравится вполне, я бы читал даже, но почему-то rss не нашёл на сайте, а pdf не очень удобно лично мне отслеживать и читать…
Скачал, почитал журналы. Разрешите уж критику. Я понимаю, конечно, что проект некоммерческий и т. п., но раз уж взялись делать какой-никакой журнал — возьмите в честь юбилея в работу какого-нибудь опытного корректора/редактора или просто внимательнее вычитывайте тексты. Я совсем не граммар-наци, но невозможно же читать — орфографические, пунктуационные и тем более стилистические ошибки в каждом абзаце :(
Так что делать то надо, расскажите? И зачем. И что будет если не сделать. И кого это вообще касается. Честно говоря, не очень понятно, а разбираться и читать их сайты не очень сейчас хочется. Написал в техподдержку, молчат пока.
Срок, в течение которого Вам необходимо оформить трехстороннее соглашение, продлен до 28 марта 2011 года. По истечению этого срока АНО <РСИЦ> перестанет оказывать услуги клиентам.
Я не очень понял, поясните пожалуйста. Чем это всё грозит мне, как владельцу нескольких доменов у RU-CENTER. Домены не потеряются? Или что вообще происходит (помимо того, что писано уже тут про руцентр)? Имею с ними договор бумажный, заключал лет 7 назад. Писем таких не приходило.
Фидо, эхи и прочее — это всё понятно. Проходили, знаем. Но как-то это совсем не то же самое, что общедоступный блог, не? И даже вообще фактически и не блог даже. В силу как раз «децентрализованности» блогоэх в них имеется ряд недостатков. По крайней мере большинства достоинств из приведённого в посте списка точно нет. И как только у людей появилась возможность централизоваться фидо и эхи стали загибаться. Может, местами и жаль, но всему своё место и время. Мне так кажется.
Та часть, которая описывает WinnerChecker'ы написана в лучших традициях Java, вместо описания малюсенького кусочка кода на несколько строчек — создание интерфейса и подклассов
Да, Java она такая негодяйка — как-то незаметно заставляет нормально декомпозировать задачу вместо портянки вложенных друг в друга циклов на вполовину меньше строчек.
В 99.9% случаев из тех, где может понадобиться подобный код никогда не возникнет на входе Xuccessful. Скорее всего тут разбирается конкретный вывод чего-либо. А если и возникнет, то… а если Xuccessful тоже устраивает? Без контекста использования почти никогда нельзя сказать достоверно гавнокод или не гавнокод. В том же code_wtf в половине случаев после разбора оказывается, что никакой это и не гавнокод, а просто кто-то не разобрался поглубже :) Но даже и без контекста видно, что разбираются какие-то итоговые строки на GOOD-ответ и BAD-ответ по признакам наличия в содержимом частей строк, которые однозначно указывают на результат. Повторяю, это более чем распространённое решение в таких случаях, а зачастую и самое приемлемое.
А если взять и допустить, что происходит что-то вроде разбора логов или анализа возврата какого-либо протокола (а название метода и само содержимое строк как раз подходящие), то есть какого-либо многочисленного набора фиксированных/однотипных значений строк, то оказывается, что это вовсе и не гавнокод, а если не изящное, то самое логичное (и привычное для многих, кто с этим сталкивался) решение.
Имхо, профессионализм и опыт как раз и определяется выбором вот такого вот решения и понимание отличия от гавнокода, которым бы являлось похожее решение в некоторых других случаях.
Как раз непрофессионал использовал бы что-то типа .equalsIgnoreCase, особенно если предполагается оптимизация по перфомансу, размеру байткода или памяти.
Пытался запустить поглядеть в виртуалбоксе. На разных этапах загрузки/установки зависало напрочь, пару раз виртуалбокс писал обнаружена критическая ошибка и закрывал. Менял параметры памяти, чипсета, видеопамяти, отключал всё что можно было — звук, usb, сеть. Все попытки поглядеть на рабочий стол оказались тщетны. Вечером попробую записать на cd и загрузиться. Добью из принципа :)
Мда, вот косяк…
В любом случае длина маршрута однозначно вычисляется количеством последующих 12-байтных узлов, но при вашей «автоматизированной» обработке оно не проканает, да, потому что у меня первые 4 байта другие.
Хотя оно в любом случае не проканало бы, потому что сейчас проверил, Java через DataOutputStream.writeInt пишет целое число с обратным порядком байт: «00 00 00 01», о чём я вам и говорил выше, собственно. Надо чётко определять подобные тонкости :\
На самом деле это средней сложности задача на графы. Но с заковыками и непонятками. За интерес в такое играть неохота. Соревноваться конечно круто, но смысл в чём? Таких задач можно сотни придумать. К тому же задание слишком некорректно, особенно с учётом того, что «обработка будет автоматически». Что значит «4 байта длина маршрута», как оно кодируется? В каком порядке байтов? От старшего к младшему? Или наоборот? Допустим, я пишу на Java и читаю четырёхбайтовый int через DataInputStream, есть сомнение, что мой бинарный вывод будет такой же как у вас в вашей платформе.
Про нечёткость определения маршрутов выше сказано. При недостаточно разреженном графе маршрутов будет и правда если не бесконечное количество, то достаточно неопределённое. При наличии зацикленных тоже непонятно, каждый цикл добавляет кучу маршрутов. А если зацикленный маршрут самый длинный, то сколько их? Столько, сколько вершин в этом цикле? Как-то нелогично это всё, имхо.
25 Вт*ч = 25 В*А*ч, если вольтаж 3,75В, то получается 6,(6) А*ч = 6666 мА*ч
Имхо, профессионализм и опыт как раз и определяется выбором вот такого вот решения и понимание отличия от гавнокода, которым бы являлось похожее решение в некоторых других случаях.
Как раз непрофессионал использовал бы что-то типа .equalsIgnoreCase, особенно если предполагается оптимизация по перфомансу, размеру байткода или памяти.
Правда, установить не получилось, но на логотип поглядеть со второго раза удалось)