Стандартная библиотека C++ (2015)


#146

Оно дает возможность валидатору отсекать группу неправильных тестов :smile:

Кстати:

0≤id<all

#147

Информацию о правильности id. В целом, Дима верно ответил.


#148

По странному стечению обстоятельств, я Вас пропустил. Приношу свои извинения. Инпут принят, а с аутпутом еще разбираемся.


#149

Отправлять решение уже можно?

Если да, тогда какой формат решения, solution.tar с кодом, или как-то по другому называть надо?

Есть еще один вопрос правда… в Request 3 мы должны вычилсить среднюю скорость дороги(тут уже можно использовать trunc(middleSpeed+0.001), то что мы обговорили в классе), а после этого мы получаем время делением=> double. Причем время это может получится весьма небольшим, например в тесте, который кидали сюда 0.16 минуты. По идее опять могут быть ошибки. Как округлять для времени?


#150

direction - количество направлений.


#151

В условие внес коррективы в виде “Пояснений”. Добавил ссылки на них по тексту и выделил подчеркиванием, чтобы было проще найти.

Кстати, округлять скорость не надо, т.к. мы ее нигде не выводим!

Перепроверил тесты. Итого 10 тестов. Правила отправки те же. Пробуйте.


#152

Мы в четверг решили как, и я это внес в пояснения. До целого вниз с точностью до 0.001.


#153

Нас за тесты поругали, а сами… :smile:

Тест 1:

10:04 REQUEST 3 1 1 1 10

Описание запросов 3-го типа после указания времени, категории и типа содержит описание маршрута в следующем формате: «k x1 y1 x2 y2 … xk yk»

Вроде как корректно: 10:04 REQUEST 3 2 1 1 1 10

OUTPUT к тесту 1 тоже не правильный вроде, ну до второго запроса конечно

выдает 3 4 0 1 2

но они все ехали со скоростью 20(а первый REQUEST выдал NOTHING, т.е ничего не нарушалось) по дорогам (0,1,3,4)=> 0 1 3 4 2 вот это корректно, т.к : “На список самых загруженных дорог накладывается дополнительное требование о том, что дороги с одинаковой скоростью должны быть упорядочены по номеру”

Дальше там… Correct очень мало верных

То что бросается в глаза с первого взгляда:

Тест №9 1 5 0 CAR 1 40- Дорога по которой едем 10:01 OBJECT 2 1 0 10 10:06 OBJECT 2 1 2 100 нарушил не скорость, а выехал на встречную полосу прежде всего =>вот эта строка неверна

10:06 0 1 100

Тест 10:

По Requestу 2 выдает 0 3 1 4 2 но дороги то всего 4 по которым могут машины кататься. У второй дороги вообще скорости нет.

Ну и.т.д

Кстати, строка с комментариями отображается в output и валит тесты:

— Output: size 0 —

— Correct: size 190 —

# Тест на первый запрос. Состоит из большого количества автомобилей, едущих по встречке на первой дороге


#154

Отображение - так и задумано.

Не должна валить.

update: в чекере просто синтаксическая ошибка. Все будет хорошо )

update2: там просто висит не тот чекер. Запланированный будет игнорировать #коммент.


#155

Теперь все хорошо должно быть.

Этот тест залез в таком виде по ошибке) Валидатор его не пропустил, но почему-то он там оказался. Поправил.

Превышение скорости все равно есть. Outputы пока формируются, считая, что для определения езды по встречке, сообщения должны отставать по времени не более чем на 1 минуту. Там же - пять минут. Даже если будем считать, что есть выход на встречку: см. появнения - превышение скорости тут тоже нужно учесть.


#156

9.Время в пути для запроса 3 считается как произведение длин отрезков (с учетом масштаба) умноженное на среднюю скорость дороги

У меня разрыв шаблона :slight_smile: Это так и задумано?

Я всегда думал, что время - это расстояние, деленное на скорость. И тогда все время должно быть суммой расстояний, деленных на скорости.


#157

Такого я в условии не видел…

Как все таки округлять время?

Тест 10:

5 1 8 CAR 1 40 Вот дорога

10:00 REQUEST 3 2 1 5 5 5 Приходит тут же request

И вот я считаю 40(м)/40000(м/ч)*60=0.006 минуты.

судя по Пояснению 4 :"Время при выводе округляются вниз с точностью до 0.001, т.е. 29.999 округляется до 30, 29.006 до 30, 29.87 тоже до 30"© , я должен поставить 1, т.е сделать trunc(time+0.998); и получу то что надо, но в корректном тесте стоит 0. Та же ситуация и с 1м тестом, но с 7мым тестом все совпадает.

Также считаю, Что надо убрать пояснение 8:"Маршрут в запросе 3 состоит как минимум из двух отрезков. Каждый отрезок маршрута целиком принадлежит некоторой дороге. Никакие два подряд идущих отрезка не могут принадлежать одной дороге."©

Иначе мы не можем почитать время на прямой дороге(кст из-за этого пояснения первый тест опять не должен пройти отбор :smile: )


#158

Это с самой первой практики к этой задаче. Считать относительно предпоследнего сообщения неправильно: вдруг оно было 2 часа назад?

Пояснение 4, про округление, дико мутное. Что значит, округление вниз с точностью? Всегда округлять вниз, если только до ближайшего целого не меньше 0.001? По-моему, самое логичное - всегда округлять вверх. Так мы говорим, что время в пути - не более N минут.

Но у меня есть вариант, по-моему, самый лучший для этой мутности: чекер будет проверять, что предложенный ответ отличается не более чем на единицу от авторского. И все вопросы округления сразу же отпадут

Наверное, имелось в виду - точек.


#159

а где это в условии было написано, и даже если 2 часа назад последнее сообщение на что это влияет? я могу, допустим, из двора выехать против одностороннего движения, остановится(1ое появление в системе) сходить домой обратно по своим делам и поехать дальше против движения(2е появление) и судя по тому что ты сказал это не нужно учитывать как нарушение. Тогда спрашивается, почему мы должны привязку к времени предыдущего появления делать?


#160

Согласен с Андреем


#161

Если мы проектируем реальную систему, то мы вообще не имеем право ориентироваться только на одно из двух. + Нужно еще кучу разлиных факторов привлечь.

Здесь у нас сферическая система в вакууме, на реальную смахивающая крайне мало. Я не настаиваю, что так должно быть: просто это один раз оговаривалось и так оно висит в неокончательном решении.

В этой задаче вообще самой большой проблемой является проверка корректности входных данных. Это очень сложная штука - проверять, что автомобилист или пешеход могли добраться от одной точки до другой за период между их двумя сообщениями. Или, что они могли так разогнаться.


#162

Было бы неплохо

Наверное, но мало ли что имелось ввиду:smile:

Не помню такого совсем… У меня даже мысли такой до этого момента не было(По соображениям которые привел Андрей)


#163

Это была моя самая первая мысль, когда только задачу прочитал на практике и раз пять об этом спрашивал Романа Борисовича :smile:

Ориентир на последнее сообщение - дурной. Я подключился к интернету в 10:10, отключился, проехал по встречке до перекрестка, повернул, проехал 100 метров по правилам, опять подключился. Фиксировать ли нарушение?

Ориентир на два близких по времени события - уже лучше, но опять таки: в 10:10:00 отправил сообщение, отключился, поехал по встречке, в 10:10:32 свернул и поехал по правилам, повключился и отправил в 10:11:02. Было ли нарушение?

Всякие Яндекс.Карты, как у них написано на официальной пояснялке, строят вероятные треки движения - и это будет покруче того, что у нас.

В пояснении про расчет пути написано умножение, но все же поняли, что имелось в виду деление?:slight_smile:


#164

Тогда может быть другая ситуация: пришло сообщение объехал квартал по кругу меньше чем за минуту, будто проехал по встречке

Тут много можно спорить о том как правильнее, но в условии этого пока нет,а в тестах уже есть

Резонный вопрос: почему тогда 1 мин, а не 2 или 1.5?


#165

ну вот ты сам только что и сказал что твой вариант смотря как то на время тоже не идеальный, но смотреть на предыдущее положение, как мне кажется, и с точки зрения реализации, и с точки зрения логики как раз вписывается в нашу задачу