"Генетические алгоритмы - это просто!" - продолжение следует? - страница 3
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Дело в области значений совокупного показателя критериев. Оптимизатор заведомо ищет не там (не потому что он плох, а потому что таков совокупный критерий - из за перекоса), где хотел бы искать пользователь. Отсюда, варианты оптимизации, любо-дороги пользователю, даже и не появятся вообще. Пользователю остается лишь выбирать среди тех вариантов, которые ‘‘получились‘‘, причем это единичные случаи среди остальных вариантов результатов, так как остальная масса результатов сосредоточена именно на тех, где баланс максимален. А для робастости, как говорят, необходим пологий участок нужных результатов (а он получится "дырявым").
По моему, тень на плетень наводите или не в курсе кастомного параметра оптимизации.
Критерий полностью под управлением - какой хотите, такой и делайте.
Зачем делать вид, что кастомного критерия нет и тут же рассказывать, что как хорошо иметь кастомный критерий оптимизации?
Зачем делать вид, что кастомного критерия нет и тут же рассказывать, что как хорошо иметь кастомный критерий оптимизации?
Я кстати, так и не понял, почему они игнорируют кастомный критерий, ведь его можно настроить как хочется и сам он может включать десятки коэффициентов с разными весами.
Потому что кастом не нормирует каждый критерий относительно своего диапазона.
Пример: имеем 3 критерия, и две особи. 8600 -0.1 -0.5 и 7600 0.01 0.02
беглый взгляд даст понять что вторая особь лучше, но кастом выдаст лучшей первую.
ЗЫ при чём как бы вы не изголялись без нормирования относительно диапазона критерия не обойтись. Особи же ничего не знают о значениях соседей, поэтому кастомом правильное нормирование не реализовать.
Если вы будете перемножать это даст ошибку на отрицательных значениях, если будете суммировать то получите занижение значимости критериев.
По моему, тень на плетень наводите или не в курсе кастомного параметра оптимизации.
Критерий полностью под управлением - какой хотите, такой и делайте.
Зачем делать вид, что кастомного критерия нет и тут же рассказывать, что как хорошо иметь кастомный критерий оптимизации?
C-4:
Я кстати, так и не понял, почему они игнорируют кастомный критерий, ведь его можно настроить как хочется и сам он может включать десятки коэффициентов с разными весами.
Кастомный критерий оптимизации так же будет иметь перекос в сторону под-критерия, имеющего бо'льшую размерность. А нормировать критерии невозможно, без знания того, какие значения под-критериев получились на остальных проходах. И никакие коэффициенты не помогут.
Да, конечно. Можно сначала провести оптимизацию, для того, что бы посмотреть минимальные и максимальные значения под-критериев, а затем лезть в код, что бы отредактировать формулу кастомного совокупного критерия. А потом снова начать оптимизацию, что бы получить уже нормальную картину. Геморой.... Любые правки под-критериев требуют 2-х кратного запуска оптимизации, а это в 2 раза больше времени и и затраченных денег.
Кастомный критерий оптимизации так же будет иметь перекос в сторону под-критерия, имеющего бо'льшую размерность. А нормировать критерии невозможно, без знания того, какие значения под-критериев получились на остальных проходах. И никакие коэффициенты не помогут.
Да, конечно. Можно сначала провести оптимизацию, для того, что бы посмотреть минимальные и максимальные значения под-критериев, а затем лезть в код, что бы отредактировать формулу кастомного совокупного критерия. А потом снова начать оптимизацию, что бы получить уже нормальную картину. Геморой.... Любые правки под-критериев требуют 2-х кратного запуска оптимизации, а это в 2 раза больше времени и и затраченных денег.
Теперь мысль понятна.
Какое решение для нормирования предлагаете?
А нормировать критерии невозможно, без знания того, какие значения под-критериев получились на остальных проходах. И никакие коэффициенты не помогут.
Почему? Не используешь абсолютные критерии, и проблема исчезает сама собой.
Например использовать в оптимизации баланс вообще не имеет смысла.
Теперь мысль понятна.
Какое решение для нормирования предлагаете?
Есть значения расчёта критериев, и есть значения передаваемые оптимизатору (в данной реализации это одни и те же значения), вот в этом месте (на этом стыке) нужно проводить нормирование относительно того что есть.
Таким образом нормирование будет динамичным и учитывать новые данные, и истинные значения не будут сбрасываться.
ЗЫ те добавить в особь кроме переменой "значение критерия" ещё и "значение нормированного критерия", это приватная переменная которую заполняет сам алгоритм по надобности. Ведь нам же нужно расставить особи по ранжиру чтоб делать следующее скрещивание, поэтому нормировать нужно только относительно текущей популяции.
ЗЗЫ ну и конечно разделить критерии. Критериев должно быть много, раз мы говорим о многокритериальном поиске.
ЗЗЗЫ этот механизм желательно внедрить и в стандартные критерии, ну и конечно в кастомный в виде заполняемого параметрического буффера.
ЗЗЗЗЫ ну если уже просить, то по максимуму :) , хорошо бы ещё и коэфициенты значимости каждого критерия внешние задавать. Это приказы нормирующему инструменту домножить после процедуры нормирования на значимость.
Для принятия решения все критерии так или иначе сводятся к одному показателю. Поэтому игры в "многокритериальные параметры наружу" не имеют смысла. Внутри OnTester можно иметь сколько угодно критериев, но в финале они превращаются в одиночный double.
Вопрос: какое решение для возможности отнормировать внутренние критерии для выдачи одно ответа в OnTester?