Не понимаю, почему люди считают что это ChatGPT или вовсе задают вопросы автору, пытаясь объяснить ему что тот не прав?
Успокойтесь и дайте человеку получить зачёт автоматом. Неужели не очевидно по всем формулировкам в тексте, что это работа студента, сделанная для препода по шаблону и с тупыми требованиями
К недостаткам kotlin multiplatform стоит отнести ещё и то, что компилятор работает на наборе бэкендов, которые никак с друг другом не согласованы. Компилятор же при этом использует наивные для платформы реализации по максимуму.
В итоге в какой-то момент можно обнаружить себя в ситуации, в которой на одной платформе все работает, а на другой тоже самое приложение падает из-за того, что базовые структуры данных написаны иначе.
У меня был такой опыт. Я реализовывал алгоритм Эрли, который подразумевает использование множеств, в которые нужно добавлять элементы в процессе итерации по этим самым множествам. И для native это не проблема. Итератор работает так, что новые элементы попадают в конец и все классно. Зато jvm считает иначе и при запуске этой версии код падает, потому что в мире жабы добавление элемента в процессе итерации по коллекции - это ConcurrentModificationException.
Тем не менее имеем "up a piece" и "up a pawn", что подтверждает что в английском также piece в контексте шахмат - это эквивалент русской фигуре и в данном контексте не включает пешки
Вообще, рендер в годот не так уж и плох на данный момент. А утверждения о том, что он не очень идут от того, что скоро гредет вулкан и в сравнении с ним нынешний рендер естественно сильно хуже.
Что же касается оптимизации годот и юнити. Где-то лучше один, а где-то другой. Только недавно видел на ютубе ролик, в котором человек экспериментировал с тем, какое количество коллизий объектов одновременно сможет вывезти годот с его нынешней физикой. И, к сожалению, значение в несколько раз ниже чем у юнити.
Да, это не оптимизация конкретно рендера. Но тем не менее, этот пример показывает, что юнити все таки не так уж и плох. Хотя я все равно продолжу пользоваться годот :)
Я понимаю, что пост не претендует на объективность и все такое. Но блин, на мой взгляд название максимально вводит в заблуждение.
На рынке, особенно в инди секторе, существует достаточно большое количество разных движков, имеющих высокую популярность.
Если обратить внимание на статистику GMTK Game jam о том, на каких движках джемеры писали свои игры, то можно увидеть, что UE и вовсе совсем не популярен в инди секторе, в отличие от Godot, Game Maker и т.д.
Суть статьи сводится к сравнению двух движков в контексте проекта уровня ААА, где на первом месте стоит графика. И естественно, что такая статья имеет место быть и многим будет полезна. Но, чтобы она нашла своего читателя, необходимо отобразить суть статьи в ее названии.
Да уж, у нас тут во Владивостоке все полегче.
Во-первых тестирующая система за долгие годы уже защищена от большинства методов взлома (ага, только когда рядом с тобой компьютер, в котором профессор залогинился под админской учеткой и открыл редактор кода, после чего ушел пить кофе, думаю взломать все крайне просто, но я не поддался искушению).
Во-вторых, как сказал профессор «тестирующую систему ломать не пытаться, вернее пытаться, но не во время олимпиады, потому что иначе дисквалификация».
В-третьих, в соседней аудитории всегда дежурит 1-3 человека, умеющих работать с системой и даже если кто-нибудь загрузит программу, которая на всех 100 тестах даст TL, ее проверку смогут отменить по ходу.
Да я и не говорю ничего против того, что условия равные.
Более того, в одной из комментариев выше я даже писал, что входные данные в этом задании были написаны именно таким образом специально, чтобы показать людям с микроскопами, что стоило прихватить молоток.
А что именно непонятно в том, как был найден виновник? Я же писал в топике, что у меня было сдано эталонное решение со сложностью O(n). Соответственно здесь и возник сразу вопрос, если решение правильное, то в чем проблема? Проверил программу на возможные бесконечные циклы и просто баги. Ошибок не было обнаружено.
Тут и стало ясно, что дело в in-out коде. Тут то и лег глаз именно на Scanner, поскольку больше ожидать таких проблем не от кого. Ну и пошел разбирать его код по кусочкам.
Если знаете, что можно добавить в топик, буду рад помощи.
А что касается задачи, то это не имеет особого значения. Scanner плох не в конкретной задаче, а в любой ситуации, когда в одну строку записано много чисел.
Собственно это был тот самый случай.
Плюс ко всему, не уверен, что выкладывание сюда одного из заданий до того, как оно появилось на официальном сайте ВСОШ, является хорошей идеей.
Это стереотип. Python не такой медленный и линия будет быстрее квадрата С++.
На сложных задачах тоже вполне реально использовать этот язык.
В этом году на регионе была максимум одна задача, которая на нем бы не прошла, если код написан правильно.
Вот в том и дело, что ограничения одни и те же.
Да вот только разные языки за это время делают разное количество операций.
Вообще, не очень понимаю того, что именно вы хотели донести своим комментарием.
В каком-то смысле да, не подготовился.
Но я в принципе отношусь к спортивному программированию довольно пренебрежительно. Так что и не думал настолько углубляться в тонкости при подготовке.
ВСОШ для меня это просто возможность показать себе на что я способен. Именно поэтому я не сталкивался с тем, что ява подъедает на считывании стандартными библиотеками, потому что в моих основных проектах не только мало используется стандартная библиотека, но и ввод из консоли не используется.
Почти, да не во всех.
Факт, что на Python можно и даже в некоторых случаях нужно писать олимпиады из-за того, что код в нем написать банально быстрее, но делать это нужно крайне осторожно, а подчас и вообще иметь другой язык в запасе.
На самом деле ситуация заключается в том, что Java входит в список разрешенных, но не основных языков на Всероссийской Олимпиаде школьников.
В ее использовании организаторы вообще могут отказать.
И тесты соответственно были сделаны без учета данной проблемы.
П.с или возможно с учетом и как раз проверкой того, как мы решим данную проблему. Ибо вероятно не даром в других задачах данные вводились в столбик, а там где 20000 интов подряд, они даются в строчку.
Но это уже конспирология.
Не понимаю, почему люди считают что это ChatGPT или вовсе задают вопросы автору, пытаясь объяснить ему что тот не прав?
Успокойтесь и дайте человеку получить зачёт автоматом. Неужели не очевидно по всем формулировкам в тексте, что это работа студента, сделанная для препода по шаблону и с тупыми требованиями
Не нужно ничего менять и признавать, что новые форматы работают
Сидишь себе в своём консервативном офисе и радуешься тому, как все живо коммуницируют
К недостаткам kotlin multiplatform стоит отнести ещё и то, что компилятор работает на наборе бэкендов, которые никак с друг другом не согласованы. Компилятор же при этом использует наивные для платформы реализации по максимуму.
В итоге в какой-то момент можно обнаружить себя в ситуации, в которой на одной платформе все работает, а на другой тоже самое приложение падает из-за того, что базовые структуры данных написаны иначе.
У меня был такой опыт. Я реализовывал алгоритм Эрли, который подразумевает использование множеств, в которые нужно добавлять элементы в процессе итерации по этим самым множествам. И для native это не проблема. Итератор работает так, что новые элементы попадают в конец и все классно. Зато jvm считает иначе и при запуске этой версии код падает, потому что в мире жабы добавление элемента в процессе итерации по коллекции - это ConcurrentModificationException.
Это будет невероятным достижением, если реализация вообще будет
Тем не менее имеем "up a piece" и "up a pawn", что подтверждает что в английском также piece в контексте шахмат - это эквивалент русской фигуре и в данном контексте не включает пешки
Вообще, рендер в годот не так уж и плох на данный момент. А утверждения о том, что он не очень идут от того, что скоро гредет вулкан и в сравнении с ним нынешний рендер естественно сильно хуже.
Что же касается оптимизации годот и юнити. Где-то лучше один, а где-то другой. Только недавно видел на ютубе ролик, в котором человек экспериментировал с тем, какое количество коллизий объектов одновременно сможет вывезти годот с его нынешней физикой. И, к сожалению, значение в несколько раз ниже чем у юнити.
Да, это не оптимизация конкретно рендера. Но тем не менее, этот пример показывает, что юнити все таки не так уж и плох. Хотя я все равно продолжу пользоваться годот :)
Я понимаю, что пост не претендует на объективность и все такое. Но блин, на мой взгляд название максимально вводит в заблуждение.
На рынке, особенно в инди секторе, существует достаточно большое количество разных движков, имеющих высокую популярность.
Если обратить внимание на статистику GMTK Game jam о том, на каких движках джемеры писали свои игры, то можно увидеть, что UE и вовсе совсем не популярен в инди секторе, в отличие от Godot, Game Maker и т.д.
Суть статьи сводится к сравнению двух движков в контексте проекта уровня ААА, где на первом месте стоит графика. И естественно, что такая статья имеет место быть и многим будет полезна. Но, чтобы она нашла своего читателя, необходимо отобразить суть статьи в ее названии.
Имею ввиду почему вообще jvm long расширяет до float, а не до double? Разве у float хватает длины?
Объясните, пожалуйста, почему в листинге 2 вызов функции с аргументом типа long (1L) вызывает перегрузку для float?
Во-первых тестирующая система за долгие годы уже защищена от большинства методов взлома (ага, только когда рядом с тобой компьютер, в котором профессор залогинился под админской учеткой и открыл редактор кода, после чего ушел пить кофе, думаю взломать все крайне просто, но я не поддался искушению).
Во-вторых, как сказал профессор «тестирующую систему ломать не пытаться, вернее пытаться, но не во время олимпиады, потому что иначе дисквалификация».
В-третьих, в соседней аудитории всегда дежурит 1-3 человека, умеющих работать с системой и даже если кто-нибудь загрузит программу, которая на всех 100 тестах даст TL, ее проверку смогут отменить по ходу.
Более того, в одной из комментариев выше я даже писал, что входные данные в этом задании были написаны именно таким образом специально, чтобы показать людям с микроскопами, что стоило прихватить молоток.
Тут и стало ясно, что дело в in-out коде. Тут то и лег глаз именно на Scanner, поскольку больше ожидать таких проблем не от кого. Ну и пошел разбирать его код по кусочкам.
Если знаете, что можно добавить в топик, буду рад помощи.
А что касается задачи, то это не имеет особого значения. Scanner плох не в конкретной задаче, а в любой ситуации, когда в одну строку записано много чисел.
Собственно это был тот самый случай.
Плюс ко всему, не уверен, что выкладывание сюда одного из заданий до того, как оно появилось на официальном сайте ВСОШ, является хорошей идеей.
Я как-то упустил момент его появления видимо.
Спасибо.
Это стереотип. Python не такой медленный и линия будет быстрее квадрата С++.
На сложных задачах тоже вполне реально использовать этот язык.
В этом году на регионе была максимум одна задача, которая на нем бы не прошла, если код написан правильно.
Вот в том и дело, что ограничения одни и те же.
Да вот только разные языки за это время делают разное количество операций.
Вообще, не очень понимаю того, что именно вы хотели донести своим комментарием.
Но я в принципе отношусь к спортивному программированию довольно пренебрежительно. Так что и не думал настолько углубляться в тонкости при подготовке.
ВСОШ для меня это просто возможность показать себе на что я способен. Именно поэтому я не сталкивался с тем, что ява подъедает на считывании стандартными библиотеками, потому что в моих основных проектах не только мало используется стандартная библиотека, но и ввод из консоли не используется.
Факт, что на Python можно и даже в некоторых случаях нужно писать олимпиады из-за того, что код в нем написать банально быстрее, но делать это нужно крайне осторожно, а подчас и вообще иметь другой язык в запасе.
В ее использовании организаторы вообще могут отказать.
И тесты соответственно были сделаны без учета данной проблемы.
П.с или возможно с учетом и как раз проверкой того, как мы решим данную проблему. Ибо вероятно не даром в других задачах данные вводились в столбик, а там где 20000 интов подряд, они даются в строчку.
Но это уже конспирология.