В озыве на картинке на самом деле написано следующее:
Сотрудники и владельцы ресторана разговаривают с тобой, как будто они дружелюбны и всё такое. Я не выношу дружелюбный людей, и если приходится общаться, я лучше буду делать это со своим телефоном. Возвращаясь к пицце. Зачем столько гурманских приправ в меню? Всё, что нужно, это пицца с сыром и пицца с карри и сыром. Не рекомендую идти в этот ресторан никому, кто любит пиццу с карри.
Система имеет встроенную защиту от вирусов/зловредного ПО, так что, по утверждению разработчиков, нет необходимости устанавливать антивирусное ПО на домашние/рабочие системы по отдельности.
Изменив в вашем Glonass.java
for (int offset = 0;; offset += 10)
на
for (int offset = 120000;; offset += 10)
Я получил на 0.2 балла больше (в сумме на 6и тестах)
Не знаю стоит ли это 5и символов :)
У habrunit действительно круто — предпосчёт 256 маркеров. Судя по коду он читает до 16и килобайт. При оптимальном распределении маркеров:
665000 возможных расстояний делить на 256 это примерно 2600 байт.
Я искал пересечения краёв колец и мог оценить разброс точек. Считывание маленького участка используется только при маленьком разбросе.
Во время чтения можно сделать следующие оптимизации:
* Вместо того, чтобы считывать 660к данных, для первух спутников можно посчитать более точный минимум и максимум расстояния (Если спутник в 20000км от центра, то он как минимум 20000-6378 км от приёмника)
* Начиная со 2го/3го спутника, когда местоположение приёмника примерно известно, можно считать маленький кусок — меньше килобайта.
* Pattern.find работает быстрее indexOf, так как использует Boyer–Moore
Удивило что многие рискнули проигнорировать «Переводы строк — не документированы, лучше на это не закладываться. » и (удачно) предположили \r\n как в опубликованных тестах.
А ещё проигнорирован результат функции skip(), хотя в документации сказано, что может быть пропущено меньше заказанного.
В отличие от решений других лидеров — моё может давать существенно разные результаты в разные запуски.
BarsMonster, на моей машине моё решение обгоняет habrunit примерно на 0.2 балла при прогоне каждого теста 20 раз подряд (для усреднения результатов и разогрева cache).
Можете сделать у себя такую пороверку для лидеров?
for i in range(6):
for r in range(20):
name = 'tests/' + str(i+1)
check(name)
Моё решение использует 4 потока:
1) Чтение файлов + расчёт x,y,r для каждого спутника.
2) Подсчёт начальной точки (после 2х или 3х спутников) и печать результата когда все спутники обработаны
3) Итеративный поиск оптимальной точки на основе уже считанных спутников.
4) Оценка результата и остановка если время кончается или ожидается ухудшение результата.
Например для 12и монет можно найти фальшивую за 3 взвешивания а не за 4.
Сотрудники и владельцы ресторана разговаривают с тобой, как будто они дружелюбны и всё такое. Я не выношу дружелюбный людей, и если приходится общаться, я лучше буду делать это со своим телефоном. Возвращаясь к пицце. Зачем столько гурманских приправ в меню? Всё, что нужно, это пицца с сыром и пицца с карри и сыром. Не рекомендую идти в этот ресторан никому, кто любит пиццу с карри.
Когда вы играете музыку на синтезаторе пальцами, вы же считаете её своей, хотя издает её синтезатор спроектированный кем то другим.
После такой фразы тяжело верить остальному.
theoatmeal.com/comics/game_of_thrones
У вашего решения есть несколько проблем:
При запуске «str_cpy(&s, s+5);» ваш memmove читает из памяти которая вам уже не принадлежит.
Аналогично при запуске str_cat(&s, s+5);
for (int offset = 0;; offset += 10)
на
for (int offset = 120000;; offset += 10)
Я получил на 0.2 балла больше (в сумме на 6и тестах)
Не знаю стоит ли это 5и символов :)
У habrunit действительно круто — предпосчёт 256 маркеров. Судя по коду он читает до 16и килобайт. При оптимальном распределении маркеров:
665000 возможных расстояний делить на 256 это примерно 2600 байт.
Я искал пересечения краёв колец и мог оценить разброс точек. Считывание маленького участка используется только при маленьком разбросе.
* Вместо того, чтобы считывать 660к данных, для первух спутников можно посчитать более точный минимум и максимум расстояния (Если спутник в 20000км от центра, то он как минимум 20000-6378 км от приёмника)
* Начиная со 2го/3го спутника, когда местоположение приёмника примерно известно, можно считать маленький кусок — меньше килобайта.
* Pattern.find работает быстрее indexOf, так как использует Boyer–Moore
Удивило что многие рискнули проигнорировать «Переводы строк — не документированы, лучше на это не закладываться. » и (удачно) предположили \r\n как в опубликованных тестах.
А ещё проигнорирован результат функции skip(), хотя в документации сказано, что может быть пропущено меньше заказанного.
BarsMonster, на моей машине моё решение обгоняет habrunit примерно на 0.2 балла при прогоне каждого теста 20 раз подряд (для усреднения результатов и разогрева cache).
Можете сделать у себя такую пороверку для лидеров?
1) Чтение файлов + расчёт x,y,r для каждого спутника.
2) Подсчёт начальной точки (после 2х или 3х спутников) и печать результата когда все спутники обработаны
3) Итеративный поиск оптимальной точки на основе уже считанных спутников.
4) Оценка результата и остановка если время кончается или ожидается ухудшение результата.
К сожалению моя Java оказалась не достаточно сильна — замена моего Reader-a на Reader AKashta вроде выводила бы меня на 2е место с шансами на 1е.
Тесты немного огорчили, по количеству и отсутствию тестов с 2я спутниками.