Пункт (б) последнего задания не решен. Было выписано несколько примеров, среди которых не встретилась искомая пара чисел, однако не было доказано, что она не может встретиться в дальнейшем.
Но что делать в ситуациях, когда в исходной системе присутствуют ограничения вида <= b_i, где b_i > 0? При преобразовании такой системы ограничений к каноническому виду добавляются столбцы, содержащие все нули и одну -1, а для включения в базис столбец должен иметь все нули и одну 1.
Сколько по интернету лазил, ни разу еще не встретил статьи, объясняющей, как этот момент можно обойти. И вообще, как симплекс методом решать каноническую задачу ЛП в общем случае.
Тебе по тестовому заданию дали фидбэк, а ты еще жалуешься) Я на стажировку в Касперского сделал довольно большое задание (как я думаю, близко к идеалу, разве что юнит тестов маловато сделал), мне в итоге отказали, при этом комментариев по решениям не дали - якобы из-за большого числа участников.
В прошлом году каким-то чудом смог заставить свою RX 6600 работать с pytorch на arch linux, через какое-то время снова стал пытаться запускать старый код, а уже не работает... Не помогает ни HSA_OVERRIDE_GFX_VERSION=10.3.0, ни переустановка rocm и торча. На винде HIP SDK, как отмечено в статье, даже не поддерживатеся. Я пробовал ставить zluda с пропатченным ROCm, и оно даже запускается, но поддерживаются только самые простые операции, по типу сложения и умножения тензоров, а уже RNN блоки крашатся на torch._cudnn_rnn_flatten_weight с CUDNN_STATUS_INTERNAL_ERROR.
Короче, жаль, что я 3 года назад выбрал не ту сторону и купил карту от AMD и столько с ней настрадался (причем не только с глубоким обучением, но и с драйверами для видеоигр), веры в их продукцию у меня уже нет.
Вот вводите вы в самом начале статьи определение: "ортогональное — статистически независимое". А потом говорите про различные виды транспорта и какими свойствами разработчик может их наделить, какие-то качественные различия, и в вашем примере нет ни одной случайной величины - то есть статистика (и вообще теория вероятности) к вашему примеру никакого отношения не имеет. Слово "ортогональность" вы, согласно вашему же определению, используете неправильно.
Далее вы приводите картинку с графиком, на котором отмечены скорость и урон противников в doom. Что ж, может быть, как случайные величины вы хотите рассмотреть скорость и урон, потому что игрок не знает, каких монстров создавали разработчики, пока их не увидит? Но по графику очевидно, что эти две переменные зависимы - высокой скорости соответствует низкий урон, то есть ортогональными эти две случайные величины назвать нельзя.
Вашу задумку можно кое-как докрутить до осмысленного вида - сказать, что, если две механики однозначно описываются векторами из какого-то единого линейного пространства и эти векторы ортогональны, то эти механики называются ортогональными. Например, если базис пространства состоит из векторов i (возможность передвигаться по земле), j (возможность передвигаться по воде) и k (по воздуху), то автомобиль в нем будет описываться вектором (1, 0, 0), а лодка - (0, 1, 0) и можно будет сказать, что автомобиль и лодка ортогональны. А вот гидроплан (0, 1, 1) и лодка (0, 1, 0) не ортогональны.
Но у этого определения, конечно, есть недостаток - на практике ортогональных механик почти никогда не будет, т.к. очень уж много у игровых объектов одинаковых переменных. Так, если мы станем рассматривать количество сидений в разных видах транспорта (добавим в базис четвертый вектор - r), и автомобиль теперь станет описываться вектором (1, 0, 0, 4), а лодка - (0, 1, 0, 2), то они уже не будут ортогональны. В этой связи логично перейти к подсчету косинусного расстояния (в моем примере это 1 - (1*0 + 0*1 + 0*0 + 4*2)/sqrt((1^2 + 4^2)(1^2 + 2^2)) ≈ 0.35 и стремиться его максимизировать. Иными словами, стремиться максимизировать разнообразие механик. Только вот зачем вместо того, чтобы просто сказать про разнообразие, пытаться натянуть линейную алгебру на геймдизайн - не ясно.
P.S. Даже не пытайтесь подсчитывать косинусное расстояние на практике, так как выбирать базис можно по-разному - в частности, можно было определить j как возможность передвигаться по воде и по воздуху одновременно, а r - как 1/10 от количества сидений в транспорте.
Разве политически разборки стоят того, чтобы из-за них отказываться от всего остального контента, в том чтсле познавательного? К тому же, на отечественных платформах политика тоже модерируется, просто по противоположному принципу
Пункт (б) последнего задания не решен. Было выписано несколько примеров, среди которых не встретилась искомая пара чисел, однако не было доказано, что она не может встретиться в дальнейшем.
UPD: в книге в книге Данцига про линейное программирование этот момент рассмотрен. Страница 103.
Но что делать в ситуациях, когда в исходной системе присутствуют ограничения вида <= b_i, где b_i > 0? При преобразовании такой системы ограничений к каноническому виду добавляются столбцы, содержащие все нули и одну -1, а для включения в базис столбец должен иметь все нули и одну 1.
Сколько по интернету лазил, ни разу еще не встретил статьи, объясняющей, как этот момент можно обойти. И вообще, как симплекс методом решать каноническую задачу ЛП в общем случае.
Тебе по тестовому заданию дали фидбэк, а ты еще жалуешься) Я на стажировку в Касперского сделал довольно большое задание (как я думаю, близко к идеалу, разве что юнит тестов маловато сделал), мне в итоге отказали, при этом комментариев по решениям не дали - якобы из-за большого числа участников.
В прошлом году каким-то чудом смог заставить свою RX 6600 работать с pytorch на arch linux, через какое-то время снова стал пытаться запускать старый код, а уже не работает... Не помогает ни HSA_OVERRIDE_GFX_VERSION=10.3.0, ни переустановка rocm и торча. На винде HIP SDK, как отмечено в статье, даже не поддерживатеся. Я пробовал ставить zluda с пропатченным ROCm, и оно даже запускается, но поддерживаются только самые простые операции, по типу сложения и умножения тензоров, а уже RNN блоки крашатся на torch._cudnn_rnn_flatten_weight с CUDNN_STATUS_INTERNAL_ERROR.
Короче, жаль, что я 3 года назад выбрал не ту сторону и купил карту от AMD и столько с ней настрадался (причем не только с глубоким обучением, но и с драйверами для видеоигр), веры в их продукцию у меня уже нет.
Не ожидал увидеть на хабре такого словоблудия.
Вот вводите вы в самом начале статьи определение: "ортогональное — статистически независимое". А потом говорите про различные виды транспорта и какими свойствами разработчик может их наделить, какие-то качественные различия, и в вашем примере нет ни одной случайной величины - то есть статистика (и вообще теория вероятности) к вашему примеру никакого отношения не имеет. Слово "ортогональность" вы, согласно вашему же определению, используете неправильно.
Далее вы приводите картинку с графиком, на котором отмечены скорость и урон противников в doom. Что ж, может быть, как случайные величины вы хотите рассмотреть скорость и урон, потому что игрок не знает, каких монстров создавали разработчики, пока их не увидит? Но по графику очевидно, что эти две переменные зависимы - высокой скорости соответствует низкий урон, то есть ортогональными эти две случайные величины назвать нельзя.
Вашу задумку можно кое-как докрутить до осмысленного вида - сказать, что, если две механики однозначно описываются векторами из какого-то единого линейного пространства и эти векторы ортогональны, то эти механики называются ортогональными. Например, если базис пространства состоит из векторов i (возможность передвигаться по земле), j (возможность передвигаться по воде) и k (по воздуху), то автомобиль в нем будет описываться вектором (1, 0, 0), а лодка - (0, 1, 0) и можно будет сказать, что автомобиль и лодка ортогональны. А вот гидроплан (0, 1, 1) и лодка (0, 1, 0) не ортогональны.
Но у этого определения, конечно, есть недостаток - на практике ортогональных механик почти никогда не будет, т.к. очень уж много у игровых объектов одинаковых переменных. Так, если мы станем рассматривать количество сидений в разных видах транспорта (добавим в базис четвертый вектор - r), и автомобиль теперь станет описываться вектором (1, 0, 0, 4), а лодка - (0, 1, 0, 2), то они уже не будут ортогональны. В этой связи логично перейти к подсчету косинусного расстояния (в моем примере это 1 - (1*0 + 0*1 + 0*0 + 4*2)/sqrt((1^2 + 4^2)(1^2 + 2^2)) ≈ 0.35 и стремиться его максимизировать. Иными словами, стремиться максимизировать разнообразие механик. Только вот зачем вместо того, чтобы просто сказать про разнообразие, пытаться натянуть линейную алгебру на геймдизайн - не ясно.
P.S. Даже не пытайтесь подсчитывать косинусное расстояние на практике, так как выбирать базис можно по-разному - в частности, можно было определить j как возможность передвигаться по воде и по воздуху одновременно, а r - как 1/10 от количества сидений в транспорте.
Разве политически разборки стоят того, чтобы из-за них отказываться от всего остального контента, в том чтсле познавательного? К тому же, на отечественных платформах политика тоже модерируется, просто по противоположному принципу