Вы не справедливы. Я привожу вам код и подробные объяснения, а в ответ слышу только короткие замечания. Опыта в этом не заметно, не то что его нет, может он и есть. Но вы не читаете, не слушаете и не смотрите код, а свой не показываете. Поэтому странно сравнивать убеждения. И да, все программисты по разному готовят, собственно это то самое место, где мы обсуждаем как мы это делаем.
Давайте вернемся к началу > Хотя по идее достаточно было заиспользовать AStar Project и разобраться в основах того, что такое поиск пути и оценках сложности этого алгоритма.
Итог разговора. Это не просто достаточно - это с переизбытком и не нужно. Это как раз иллюстрирует слова из статьи: "Не каждое функциональное решение разработчик хочет тянуть «к себе в проект». И этому есть куча причин."
В идеале, я вообще не должен знать что-такое AStar не говоря о каких то там оценках сложности. Это не тот уровень абстракции. В статье поэтому и говорится о "Юнити предоставляет достаточно низко уровневые понятия и логику построения игрового пространства. Нет ни каких высокоуровневых концепций "
Можете это подробнее описать. Это типа любовь к ECS и вера, что нарушая ООП появляется производительность. Или что-то другое?
P.S. Про остальное я могу ответить, но это длинный разговор, а по ссылкам вы не хотите проходить ... впрочем одну дам, чтобы снять начальные вопросы про ECS, при желании там есть еще объяснения, что уродство кода ECS - подходом не дает ни производительности, ни какого либо удобства.
Что касается, A* Pathfinding - юнити тоже реализует этот же алгоритм. Делать аналогичное решение, как сделали разрабтчики A* Pathfinding Project - это классическое движкописательство, на сколько я понял из описания их библиотеки, они перереализовали практически тот же подход через NavMesh, детально нужно разбираться, но в этом нет смысла, когда это не поддерживает Юнити. Как и написал в статье, это устареет. Поэтому даже если их решение в чем то интересное, его возьмут и засунут в коробку, а само по себе она не нужно.
Попробуйте найти среди тоны кода решения от A* Pathfinding Project вот такой кусочек
а потом сравните, что в том же месте в моем наивном, но нативном решении. И затем просто подумайте, откуда тут появится лучшая производительность? И зачем в свой проект тянуть несколько сотен классов, логику которых вам совсем не хочется знать, вместо того, как сделано в моей библиотеке решение на базе Юнити, стоящее двух методов с прозрачным решением. Я бы о нем написал и подробнее, но у меня ограничение на количество статей на хабре.
Возможно, но совсем не факт. Но вначале, хотелось бы выслушать ваши аргументы, почему начнет тормозить? Только тогда можно будет понять, что мы обсуждаем. Но в любом случае, это не повод использовать платный ассет с кривым решением.
Проблема с поиском пути это лишь пример "проблем" и задач возникающих в юнити, в которых полезна библиотека более высокоуровневых игровых понятий. Использование специализированных аж целых библиотек аля AStar Project (хотя вы так и не дали ссылки и понять что это такое не возможно) с большой вероятностью, есть вторая обозначенная крайность - использование непропорционально больших ассетов для решения простой задачи. А не поняли чем поможет, потому что в статье это и не описано, а код в репозитории вам посмотреть лень. Было бы нормально, если хоте ли бы разобраться попросить объяснить, но вы решили зайти с претензий ..
Вы вообще зря перевели на ECS, все тоже самое можно сделать на ООП. Если предоставите исходники я бы с этим повозился бы (желательно версии до и после перехода).
Поправь меня, если я не прав - Машина Цетлина это тот же перцептрон Розенблатта, на пороговых элементах, но только со стахостическим обучением, если не путаю, Розенблатт это называл S-управляемой системой, что потом использовал Хопфилд .. т.е. по сути ничего нового
Во-первых, 30к это вырвано из контекста, там же видно, что 10к - 20к -30к - разница не большая. Во-вторых, нейрон перцептрона и нейрон бэкпропа это две большие разницы. Их смело можно рассматривать как 1 к 1000 (по вычислительной нагрузке).
во всех остальных случаях, вы или использовали предобработку или вам попался хороший seed рандома, ну или поздравляю совравши
Но главного вы так и не поняли, это новый алгоритм, без вычисления градиента, поэтому даже если он пока чуть хуже (хотя это и не так сейчас, разве что CNN и WRN - вот где оверхед нейронов - чуток лучше) - он не требует вычисления производных ...
чтобы понимали в каких пределах у нас расхождения, у меня есть реализация бэкпропа на питоне (дал, кто-то из форумчан, который тоже вдохновился спорить:) ) , на вашей архитектуре 784-48-128-10 он дает порядка 96% точности после 370 итераций. Но это не аргмакс, а то, что выше в статье E_hard
исходники выложи, тогда посмотрим (люблю я эти преувеличения, и когда сравнивают хрен с редькой), выложишь перепроверю. И даже если так, это хороший результат. Адекватно, думать надо. Хотя уверен, что что-то недоговариваете. Просто было тут много фейкометов, которые на проверку оказались несостоятельными.
Я вот все думаю, откуда на форумах часто переходы на личности, всякое там ad hominem - так это вот от таких учителей, от их петушачих представлениях, а о гавнокоде не слова.
Видешли, некоторые люди читают не только "веселые картинки", и не разбираясь в теме, позволяют себе смешно пописывать про стратегическое развитие и прочие разводы ...
Вы не справедливы. Я привожу вам код и подробные объяснения, а в ответ слышу только короткие замечания. Опыта в этом не заметно, не то что его нет, может он и есть. Но вы не читаете, не слушаете и не смотрите код, а свой не показываете. Поэтому странно сравнивать убеждения. И да, все программисты по разному готовят, собственно это то самое место, где мы обсуждаем как мы это делаем.
Давайте вернемся к началу
> Хотя по идее достаточно было заиспользовать AStar Project и разобраться в основах того, что такое поиск пути и оценках сложности этого алгоритма.
Итог разговора. Это не просто достаточно - это с переизбытком и не нужно. Это как раз иллюстрирует слова из статьи: "Не каждое функциональное решение разработчик хочет тянуть «к себе в проект». И этому есть куча причин."
В идеале, я вообще не должен знать что-такое AStar не говоря о каких то там оценках сложности. Это не тот уровень абстракции. В статье поэтому и говорится о "Юнити предоставляет достаточно низко уровневые понятия и логику построения игрового пространства. Нет ни каких высокоуровневых концепций "
Позвольте себе думать более высокими категориями.
Можете это подробнее описать. Это типа любовь к ECS и вера, что нарушая ООП появляется производительность. Или что-то другое?
P.S. Про остальное я могу ответить, но это длинный разговор, а по ссылкам вы не хотите проходить ... впрочем одну дам, чтобы снять начальные вопросы про ECS, при желании там есть еще объяснения, что уродство кода ECS - подходом не дает ни производительности, ни какого либо удобства.
Что касается, A* Pathfinding - юнити тоже реализует этот же алгоритм. Делать аналогичное решение, как сделали разрабтчики A* Pathfinding Project - это классическое движкописательство, на сколько я понял из описания их библиотеки, они перереализовали практически тот же подход через NavMesh, детально нужно разбираться, но в этом нет смысла, когда это не поддерживает Юнити. Как и написал в статье, это устареет. Поэтому даже если их решение в чем то интересное, его возьмут и засунут в коробку, а само по себе она не нужно.
Попробуйте найти среди тоны кода решения от A* Pathfinding Project вот такой кусочек
а потом сравните, что в том же месте в моем наивном, но нативном решении. И затем просто подумайте, откуда тут появится лучшая производительность? И зачем в свой проект тянуть несколько сотен классов, логику которых вам совсем не хочется знать, вместо того, как сделано в моей библиотеке решение на базе Юнити, стоящее двух методов с прозрачным решением. Я бы о нем написал и подробнее, но у меня ограничение на количество статей на хабре.
Возможно, но совсем не факт. Но вначале, хотелось бы выслушать ваши аргументы, почему начнет тормозить? Только тогда можно будет понять, что мы обсуждаем. Но в любом случае, это не повод использовать платный ассет с кривым решением.
Проблема с поиском пути это лишь пример "проблем" и задач возникающих в юнити, в которых полезна библиотека более высокоуровневых игровых понятий. Использование специализированных аж целых библиотек аля AStar Project (хотя вы так и не дали ссылки и понять что это такое не возможно) с большой вероятностью, есть вторая обозначенная крайность - использование непропорционально больших ассетов для решения простой задачи.
А не поняли чем поможет, потому что в статье это и не описано, а код в репозитории вам посмотреть лень. Было бы нормально, если хоте ли бы разобраться попросить объяснить, но вы решили зайти с претензий ..
Это как раз то, что я назвал движкописательство. Юнити предлагает так называемый NavMesh, поэтому нет ни какой необходимости изобретать велосипед.
Вы вообще зря перевели на ECS, все тоже самое можно сделать на ООП. Если предоставите исходники я бы с этим повозился бы (желательно версии до и после перехода).
Мы просто обсуждаем в другом месте, а тут удобно делать выгружать графики. Все кому интересно могу пригласить сюда https://dxdy.ru/topic161852.html
Поправь меня, если я не прав - Машина Цетлина это тот же перцептрон Розенблатта, на пороговых элементах, но только со стахостическим обучением, если не путаю, Розенблатт это называл S-управляемой системой, что потом использовал Хопфилд .. т.е. по сути ничего нового
что же Вы тогда не реализовали перцептрон?
Во-первых, 30к это вырвано из контекста, там же видно, что 10к - 20к -30к - разница не большая. Во-вторых, нейрон перцептрона и нейрон бэкпропа это две большие разницы. Их смело можно рассматривать как 1 к 1000 (по вычислительной нагрузке).
во всех остальных случаях, вы или использовали предобработку или вам попался хороший seed рандома, ну или поздравляю совравши
Но главного вы так и не поняли, это новый алгоритм, без вычисления градиента, поэтому даже если он пока чуть хуже (хотя это и не так сейчас, разве что CNN и WRN - вот где оверхед нейронов - чуток лучше) - он не требует вычисления производных ...
чтобы понимали в каких пределах у нас расхождения, у меня есть реализация бэкпропа на питоне (дал, кто-то из форумчан, который тоже вдохновился спорить:) ) , на вашей архитектуре 784-48-128-10 он дает порядка 96% точности после 370 итераций. Но это не аргмакс, а то, что выше в статье E_hard
ну не, на это у меня нет времени ... Си, С#, Питон на крайняк ... ну или к новому году доберусь ))
исходники выложи, тогда посмотрим (люблю я эти преувеличения, и когда сравнивают хрен с редькой), выложишь перепроверю. И даже если так, это хороший результат. Адекватно, думать надо. Хотя уверен, что что-то недоговариваете. Просто было тут много фейкометов, которые на проверку оказались несостоятельными.
тут очевидно неверная реализация, искать ошибки мне лень.
Очевидно потому, что получится глупость, такая как у вас.
Да, очень хороший результат, аналогичный MLP + backprop
Я вот все думаю, откуда на форумах часто переходы на личности, всякое там ad hominem - так это вот от таких учителей, от их петушачих представлениях, а о гавнокоде не слова.
Видешли, некоторые люди читают не только "веселые картинки", и не разбираясь в теме, позволяют себе смешно пописывать про стратегическое развитие и прочие разводы ...