Мы в любом случае смотрим на предыдущее положение, просто к этому добавляется срок валидности.
Не знаю, но я слышал только такую цифру ) Какую Роман Борисович назовет константу, такая и будет, как будто бы это так долго делается?)
это 2ой уже вопрос как долго это делается
Ребят, я просто не смог дочитать до конца, запутался в ваших рассуждениях и показаниях. Прекратите писать гигантские посты. Коротко, взяли и написали баг репорты: имеем, ожидается, получаем расхождение. Если хотите быть понятыми, прекратите флуд.
Проблема такая:
Считаю, что это не верно, потому что OBJECT мог остановиться. Nekrolm считает что это правильно
Я не понимаю, что такое “отставать” и где “там” 5 мин. Выразите мысль в указанном мной формате.
Имеем: Несовпадение моего outputа с correct.(Писалось про конкретный тест)
Nekrolm написал:считая, что для определения езды по встречке, сообщения должны отставать по времени не более чем на 1 минуту. Там же - пять минут.
т.е событие “выехал на встречку” сработает если сообщения пришли в 10:10 и 10:11 например
Ожидается: правильно ли это? Если да, то добавить бы в условие. Если не правильно, то править correctы
Мне все равно кто писал эту фразу. Я ее не понимаю.
Он считает, что событие выезд на встречку должно происходить, если между двумя сообщениями был маленький промежуток времени(В данном случае 1 мин)
Ему возразили тем, что авто могло остановиться и продолжить движение и разница во времени могла быть любой, а выезд имел бы место
Неверно. Два сообщения дают возможность определить направление. А скорость у нас приходит в последнем сообщении и по ней мы определяем по встречке или нет. Если очень хотите, то можем добавить ограничение по времени между сообщениями для определения направления, но не 1 мин.
Как по скорости определить выехали или нет?
Как раз не хотим, и считаем нелогичным
выезд на встречку мы определяем по координатам
А черт! Скорость - это для превышения. Для “встречки” только направление.
Ну, Дима, хотел сказать что объект мог петлю сделать через Караганду и приехать с законного направления. Но я все равно не хочу менять здесь условие.
Еще один вопрос, пока вы здесь:
Имеется: в разных тестах округление времени идет по разному.
Ожидается: Как-то это поправить:smile:
Пример:
Тест 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мым тестом все совпадает.
Почему? 0.006 округляется вниз до 0. PS: плохо пишете багрепорты Саша. Заказчики от вас уже отказались и ушли к другим разрабам.
это из условия
Если так как вы говорите,то надо править другие тесты(например 7)
Тут есть еще такой вариант:
Маршрут
1 1
5 1
5 5
10 5
10 1
8 1
Дороги (односторонние) 1 1 -> 5 1 И 10 1 -> 8 1 (+ еще две вертикальные). Сообщения посылаем в точке 1 1 и в точке 8 1
Какая тут должна быть логика? Только по координатам - был презд по встречке. Координаты + проверка дороги, на которой были - не было проезда.
Саш, ну Димы не было в пятницу, но Вы то были. Конечно, 29. Это моя копипаста. Пошел править.
Когда заказчик вносит правки в техзадание после того как подписан договор и написана большая часть кода, это стоит очень дорого:smile:
Безусловно! Но заказчик идет на поводу у исполнителя, на все соглашается и даже готов заплатить за одну задачу как за две 
А можно конкретно, что там должно быть с выводом по времени в пути: сам REQUEST и что не так?
Институт математики, механики и компьютерных наук ЮФУ, 2005–2021