Для студентов с семейными парами. Мы с женой живем в такой двухместной комнате, это как маленькая квартира-студия, со своим санузлом и кухней, только без квартплаты и за совершенно смешную цену аренды
Более того: остальные 10% тоже учатся по грантам, просто их гранты не покрывают полную стоимость, остаток они покрывают частью стипендии. Чистых контрактников тут нет :)
Ну поставлять генерик + llvm-байткод в пакетах и при наличии интернета компилировать свежим llvm под целевую платформу не особо сложная задача.
Просто, очевидно, никому это не нужно потому что реального прироста производительности в большинстве приложений просто не будет, а ffmpeg или opencv кому надо сами соберут еще и с кастомными патчами.
Community Edition — это про Visual Studio?
Раз уж сравнение идет c эльбрусами, то хотелось бы увидеть сравнения производительности интела и эльбруса обоих под Linux, с использованием gcc или clang.
Читал не полностью, про Rust половина — придирки, половина от незнания языка и является просто враньем. Зачем писать критическую статью, понахватав по верхам?
Выход — всего лишь ТОЧКА. И она будет находиться там, где Вы захотите.
Это уже не относится к генерации. Хотите — делайте в левом углу, хотите — в точке, где происходит первый возврат по стеку.
Алгоритм поиска ищет путь от заданной начальной точки до заданной конечной.
В данном случае, я ставлю конец в самую дальнюю от выбранного мной входа точку, чтобы с большей степенью вероятности получить наиболее протяженный путь.
Несколькими комментариями выше я ответил на вопрос о контроле длинны пути от точки до точки.
Изначальное количество клеток на нулевом шаге не уменьшается после генерации.
Мы как имели 25 клеток в самом начале, отделенные стенками, так и будем их иметь после генерации. Соответственно, любые из них можно выбрать как начальную\конечную. Алгоритм покрывает все клетки и из любой из них можно пройти в любую. То есть остовное дерево от «входа» до «выхода» можно построить от любой клетки до любой.
Образуется таки.
Алгоритм поиска, в текущем виде, считает все клетки равноправными(шаг равен одному).
То есть стенка при «сносе» заменяется клеткой, которая сразу отмечается посещенной, во избежании повторного прохода по ней.
Можно обойти это, используя шаг равный двум и проверяя есть ли стенка, как в функции removeWall. И соответственно отрисовывать только клетки, а стенки линиями по второй матрице, получаемой разложением по четности, но это уже лютые костыли и велосипеды…
Правильнее, и я так и буду делать в дальнейшем, использовать плотнее графы и работать непосредственно на матрице или списках смежности.
Если там описываются альтернативные варианты представления лабиринта в памяти, с радостью подчерпну что-то новое.
Я нашел матрицу клеток самой оптимальной и удобной в использовании.
Опять же, идеальный он не потому что идеален эстетически, или с точки зрения сложности, просто определение такое.
Вы имеете в виду, можно ли задать длину пути между двумя точками?
Теоретически, да — построить сначала минимальное основное дерево нужной длины, представляющее собой путь между двумя точками, а потом достроить вокруг остальной лабиринт.
Практически — не пробовал, но учту, в следующей статье вместе с поиском в ширину постараюсь осветить этот момент.
Да, лабиринт соответствует определению «идеального лабиринта» — ни циклов, ни изолированных областей, между двумя точками есть путь и притом только один.
UPD: Добавить циклов и вариативности прохождения довольно просто: достаточно выбить некоторое количество рандомных стенок.
Забыл упомянуть об этом, сейчас исправлю, спасибо.
Выходной точкой может быть любая точка, не являющаяся стеной. Хоть в центре, может там переход на другой уровень.
По умолчанию входом всегда считается левая верхняя точка, а выходом — правая нижняя. А так, выбрать можно любые две точки и прикрутить соответствующую визуализацию, на алгоритм это никак не повлияет.
Речь идет о поиске пути между двумя любыми точками, а что это за точки — остается на усмотрение читателя)
Для студентов с семейными парами. Мы с женой живем в такой двухместной комнате, это как маленькая квартира-студия, со своим санузлом и кухней, только без квартплаты и за совершенно смешную цену аренды
Более того: остальные 10% тоже учатся по грантам, просто их гранты не покрывают полную стоимость, остаток они покрывают частью стипендии. Чистых контрактников тут нет :)
Ну поставлять генерик + llvm-байткод в пакетах и при наличии интернета компилировать свежим llvm под целевую платформу не особо сложная задача.
Просто, очевидно, никому это не нужно потому что реального прироста производительности в большинстве приложений просто не будет, а ffmpeg или opencv кому надо сами соберут еще и с кастомными патчами.
У вас ЛОРчанка
Community Edition — это про Visual Studio?
Раз уж сравнение идет c эльбрусами, то хотелось бы увидеть сравнения производительности интела и эльбруса обоих под Linux, с использованием gcc или clang.
lcc полностью наша разработка, что касается кодогенерации и оптимизаций, к нему прикручен покупной gcc-совместимый фронтенд.
Исходники закрыты, проскакивали инсайды, что обсуждается возможность открытия деривативов проектов под *GPL, но конкретных планов не анонсировалось.
З.Ы. спасибо за перевод
Это уже не относится к генерации. Хотите — делайте в левом углу, хотите — в точке, где происходит первый возврат по стеку.
Алгоритм поиска ищет путь от заданной начальной точки до заданной конечной.
В данном случае, я ставлю конец в самую дальнюю от выбранного мной входа точку, чтобы с большей степенью вероятности получить наиболее протяженный путь.
Несколькими комментариями выше я ответил на вопрос о контроле длинны пути от точки до точки.
Мы как имели 25 клеток в самом начале, отделенные стенками, так и будем их иметь после генерации. Соответственно, любые из них можно выбрать как начальную\конечную. Алгоритм покрывает все клетки и из любой из них можно пройти в любую. То есть остовное дерево от «входа» до «выхода» можно построить от любой клетки до любой.
Алгоритм поиска, в текущем виде, считает все клетки равноправными(шаг равен одному).
То есть стенка при «сносе» заменяется клеткой, которая сразу отмечается посещенной, во избежании повторного прохода по ней.
Можно обойти это, используя шаг равный двум и проверяя есть ли стенка, как в функции removeWall. И соответственно отрисовывать только клетки, а стенки линиями по второй матрице, получаемой разложением по четности, но это уже лютые костыли и велосипеды…
Правильнее, и я так и буду делать в дальнейшем, использовать плотнее графы и работать непосредственно на матрице или списках смежности.
Я считал что это вопрос скорее визуализации, правда.
Хм… Тогда реализация сильно приблизится к теоретической базе графов, что и так планировалось. Отлично)
Я нашел матрицу клеток самой оптимальной и удобной в использовании.
Опять же, идеальный он не потому что идеален эстетически, или с точки зрения сложности, просто определение такое.
Теоретически, да — построить сначала минимальное основное дерево нужной длины, представляющее собой путь между двумя точками, а потом достроить вокруг остальной лабиринт.
Практически — не пробовал, но учту, в следующей статье вместе с поиском в ширину постараюсь осветить этот момент.
UPD: Добавить циклов и вариативности прохождения довольно просто: достаточно выбить некоторое количество рандомных стенок.
Выходной точкой может быть любая точка, не являющаяся стеной. Хоть в центре, может там переход на другой уровень.
Речь идет о поиске пути между двумя любыми точками, а что это за точки — остается на усмотрение читателя)