В сортировке подсчётом (единственная, кстати, где название функции соответствует PEP-8) имеет смысл определять не только максимум, но и минимум и на это есть две причины:
Экономия памяти: если сортировать массив, все значения в котором в основном больше миллиона, то миллион ячеек массива-счётчика так и останутся незаполненными.
Поддержка отрицательных чисел: текущая версия алгоритма не способна отсортировать массив с отрицательными числами.
При этом сам код не сильно изменится. Размер массива будет равен разнице максимума и минимума плюс 1, а для получения индекса ячейки-счётчика нужно будет из значения элемента вычитать минимальное значение.
Если ограничиваться только арифметическими выражениями, то да. А если требуется расширить язык условными выражениями (а так же переходами, циклами и т.д.), то в массив обратной польской записи так или иначе придётся вставлять индекс на ячейку для перехода.
Но да, на протяжении всей статьи не покидало ощущение, что автор оригинала изобрёл ОПЗ, слегка его усложнив
Можно попробовать написать парсер из их XML формата. Правда, учитывая, насколько много разных видов диаграмм поддерживает draw.io, это, пожалуй, будет весьма трудоёмко.
Здесь речь идёт о выражениях, где вокруг каждого оператора стоят скобки (так называемое полноскобочное выражение). В таком выражении действительно не нужны приоритеты и ассоциативность операторам.
Для сравнения вот такие выражения: (1+(2*3)) и ((1+2)*3)
Или такие: (3*(2^(2^3))), (3*((2^2)^3)), (((3*2)^2)^3)
Полная расстановка скобок однозначно определяет порядок действий и при парсинге нам не нужно проверять условия с приоритетом и ассоциативностью. А так линейный парсер — это всё та же сортировочная станция по своей сути, просто чуть упрощённая.
Просто никто в здравом уме не захочет вводить выражения, записанное в такой форме, когда оно содержит больше 3 операций.
В самом начале стоит цель искать n-ое число за линейное от N время, при этом в итоге строится полином, который даёт ответ за константное время.
Если цель была искать за O(1), то, пожалуй, могу согласиться с комменатором выше, предложившим готовую формулу, хоть и имеющую недостатки из-за округлений.
Если же хотелось всё-таки быстрее, чем за линейное время, но не за константу, то уж лучше использовать быстрое матричное умножение, дающее ответ за O(log N)
В решении через связанный список отсутствует Model вовсе, что даёт ложное ощущение экономности по памяти.
Список по определению требует памяти больше, чем массив. В том числе за счёт распределённости в памяти, список из большого числа элементов будет проигрывать по скорости банально из-за кеша.
Самое печальное в методах, основанных на градиентах, то, что они объясняют только значения градиентов. Корреляцию между объяснимостью работы сети и значениями градиентов в хэтмапах, несомненно, можно увидеть, но никак нельзя взаимозаменять эти два понятия, к сожалению.
Кажется, что истинное объяснение может дать только математическая функция, которую реализует сеть, но толку от такого объяснения на порядок меньше, чем от градиентов.
Это не противоречит философии, поскольку такие состояния можно было бы сгенерировать один раз при инициализации заданным числом бит, но хотелось получить МТ с как можно меньшим числом как состояний, так и алфавитом. Впрочем, её всё ещё можно сократить в некоторых местах.
Введение дополнительных состояний для переходов на k позиций несомненно ускорило бы работу с памятью и командами переходов. Если опустить переходы, то можно оправдывать принятое решение тем, что операции с памятью медленные в реальных процессорах, но это несерьёзно.
Если делать полноценный аналог x86, в котором только байты, то да, это было бы отличным решением. Если однажды решусь на такое, думаю, использую Вашу идею, спасибо!
В сортировке подсчётом (единственная, кстати, где название функции соответствует PEP-8) имеет смысл определять не только максимум, но и минимум и на это есть две причины:
Экономия памяти: если сортировать массив, все значения в котором в основном больше миллиона, то миллион ячеек массива-счётчика так и останутся незаполненными.
Поддержка отрицательных чисел: текущая версия алгоритма не способна отсортировать массив с отрицательными числами.
При этом сам код не сильно изменится. Размер массива будет равен разнице максимума и минимума плюс 1, а для получения индекса ячейки-счётчика нужно будет из значения элемента вычитать минимальное значение.
Если ограничиваться только арифметическими выражениями, то да. А если требуется расширить язык условными выражениями (а так же переходами, циклами и т.д.), то в массив обратной польской записи так или иначе придётся вставлять индекс на ячейку для перехода.
Но да, на протяжении всей статьи не покидало ощущение, что автор оригинала изобрёл ОПЗ, слегка его усложнив
Можно попробовать написать парсер из их XML формата. Правда, учитывая, насколько много разных видов диаграмм поддерживает draw.io, это, пожалуй, будет весьма трудоёмко.
Здесь речь идёт о выражениях, где вокруг каждого оператора стоят скобки (так называемое полноскобочное выражение). В таком выражении действительно не нужны приоритеты и ассоциативность операторам.
Для сравнения вот такие выражения:
(1+(2*3))и((1+2)*3)Или такие:
(3*(2^(2^3))),(3*((2^2)^3)),(((3*2)^2)^3)Полная расстановка скобок однозначно определяет порядок действий и при парсинге нам не нужно проверять условия с приоритетом и ассоциативностью. А так линейный парсер — это всё та же сортировочная станция по своей сути, просто чуть упрощённая.
Просто никто в здравом уме не захочет вводить выражения, записанное в такой форме, когда оно содержит больше 3 операций.
В самом начале стоит цель искать n-ое число за линейное от N время, при этом в итоге строится полином, который даёт ответ за константное время.
Если цель была искать за O(1), то, пожалуй, могу согласиться с комменатором выше, предложившим готовую формулу, хоть и имеющую недостатки из-за округлений.
Если же хотелось всё-таки быстрее, чем за линейное время, но не за константу, то уж лучше использовать быстрое матричное умножение, дающее ответ за O(log N)
https://programforyou.ru/graph-redactor — онлайн редактор графов с пошаговой визуализацией алгоритмов (с мобильного тоже смотрибельно).
https://dronperminov.ru/machine-learning/dense-network-visualizer — интерактивный визуализатор полносвязной сети с кусочно-линейными функциями активации + особая фоновая методика обучения и анализ уровней доверия.
В решении через связанный список отсутствует Model вовсе, что даёт ложное ощущение экономности по памяти.
Список по определению требует памяти больше, чем массив. В том числе за счёт распределённости в памяти, список из большого числа элементов будет проигрывать по скорости банально из-за кеша.
Значит ли это, что Карацуба не "заметил интересную особенность" для своего алгоритма перемножения, а лишь использовал наработки Гаусса?
Обычно бинарная перекрёстная энтропия
Но если серьёзно, при обучения GAN имеется априорная информация о метке в данных — real или fake
Это чтобы чатботы прочесть текст не могли
Base64 :)
Самое печальное в методах, основанных на градиентах, то, что они объясняют только значения градиентов. Корреляцию между объяснимостью работы сети и значениями градиентов в хэтмапах, несомненно, можно увидеть, но никак нельзя взаимозаменять эти два понятия, к сожалению.
Кажется, что истинное объяснение может дать только математическая функция, которую реализует сеть, но толку от такого объяснения на порядок меньше, чем от градиентов.
Это не противоречит философии, поскольку такие состояния можно было бы сгенерировать один раз при инициализации заданным числом бит, но хотелось получить МТ с как можно меньшим числом как состояний, так и алфавитом. Впрочем, её всё ещё можно сократить в некоторых местах.
Введение дополнительных состояний для переходов на k позиций несомненно ускорило бы работу с памятью и командами переходов. Если опустить переходы, то можно оправдывать принятое решение тем, что операции с памятью медленные в реальных процессорах, но это несерьёзно.
Если делать полноценный аналог x86, в котором только байты, то да, это было бы отличным решением. Если однажды решусь на такое, думаю, использую Вашу идею, спасибо!