magic number что это

Что такое Magic Number в настройках советника

У рядовых пользователей очень часто возникает множество вопросов по поводу этого параметра. Объединив эти вопросы в одну небольшую статью, я решил помочь вам прояснить некоторые каверзные моменты.

Ниже вы сможете найти самые популярные вопросы, которые могут возникнуть, как у новичков, так и у бывалых трейдеров.

Что такое Magic Number?

Magic Number – это числовой идентификатор, который используется советником для того, чтобы он не путал свои и чужие ордера. Он нужен для того, чтобы советник не трогал ордера других экспертов, а также позиции, открытые вручную.

Советник присваивает своим ордерам определённый код. Это позволяет ему различать все позиции, которые находятся на данный момент в терминале, и работать только с теми ордерами, которые он открыл сам.

С помощью Magic Number советник понимает, какие ордера его, а какие ордера чужие.

Число может быть абсолютно любым, кроме нуля.

Нужно ли менять Magic Number при установке одного и того же советника на разные пары?

Допустим, что у вас есть советник, который вы хотели бы установить на валютные пары EURUSD и GBPUSD. Для этого вы открываете два разных окна графиков и присоединяете к каждому из них советник. Тогда возникает логичный вопрос:

Нужно ли изменить параметр, для того чтобы данные эксперты не запутались?

Менять Magic Number, если валютные пары разные – не нужно!

Если ставим один и тот же советник на разные пары, то данный параметр изменять не требуется.

А если я хочу установить один и тот же советник на 2 графика одной валютной пары, но с разными таймфреймами?

Представим, что вы поставили советник на таймфрейм М15. И точно такой же советник, но на таймфрейм Н4.

В данном случае Magic Number должен быть разным в настройках этого советника.

Иначе он начнёт путать ордера и таким образом открывать и закрывать их на разных таймфреймах.

Поэтому, если вы по какой-то причине хотите установить один и тот же советник на два графика одной валютной пары, но с разными таймфреймами, то в этом случае вам потребуется изменить настройки советника. Так, чтобы числовые значения параметра не совпадали.

Что будет если у 2 разных советников будут одинаковые Magic Number?

Если вдруг у двух советников будет выставлено одинаковое значение, то тогда они начнут путать ордера друг друга.

Допустим, что у нас есть советники «Х» и «У» с одинаковыми числовыми параметрами magic number. Советник «Х» открывает какой-то ордер, а советник «У» думает, что это его ордер и начинает управлять им по своей стратегии. И если стратегия советника «У» говорит, что нужно закрыть ордер, то он закроет ордер советника «Х».

А всё потому что у них совпадает параметры Magic Number.

Поэтому для того, чтобы один советник не путал свои ордера с позициями другого, нужно чтобы у них не совпадал данный параметр. Они должны быть разными.

В настройках робота нет Magic Number, он не будет путать ордера?

Иногда бывает так, что в настройках эксперта нет параметра Magic Number. Это не значит, что его нет в советнике. Он есть в коде. Просто авторы советника не захотели предоставлять возможность редактировать его.

Вы можете использовать такой советник, потому что он не станет путать свои ордера с чужими. Его Magic Number скрыт в коде и заранее выставлен разработчиками данного советника.

А какой Magic Number у ручных сделок?

У ручных сделок Magic Number равен нулю. Именно поэтому данный параметр может быть любым числом кроме нуля. Во время открытия ручных сделок вы не присваивайте никакого идентификатора. Такой возможности в терминале нет, но по сути она и не нужна.

Если вы хотите использовать какой-то вспомогательный советник, который будет изменять ордера, открытые вами вручную, то вам нужно будет в его параметре magic number выставить ноль.

На этом у меня всё.

Надеюсь я смог помочь вам разобраться с данным параметром, который будет полезен в вашей торговле на Форекс.

Источник

Ты не пройдёшь: магические числа для начинающих фронтендеров

Выводим Гэндальфа на чистую воду: что такое магические числа и почему верстальщику надо гнать их взашей из своего проекта.

olia danilevich / Ion Ceban / Matheus Bertelli / Skylar Kang / Pexels / Polina Vari для Skillbox

Преподаватель в «Хекслете», автор Telegram-канала LayoutCoder.

Магическими называют такие числа в коде, смысл которых понятен только написавшему их программисту. Например, иногда в интернет-магазинах цену товара автоматически умножают на 1,2, вместо того чтобы ввести понятную переменную для НДС. И без комментариев такие коэффициенты понять очень сложно. Магические числа встречаются в любом языке программирования: JavaScript, Python, Ruby. Они есть даже в CSS.

Чтобы избавиться от магического числа в коде, достаточно ввести для индекса 1,2 специальную переменную VAT — тогда любому разработчику, который читает и дополняет ваш код, будет понятен «физический» смысл числа.

Веб-вёрстка близка к программированию, и проблема магических чисел здесь очень актуальна. Я преподаю и, комментируя код студентов, часто вижу, как отступы, длина, ширина блоков берутся практически с потолка. Постоянно попадаются записи вроде «width = 47%» — из них совершенно непонятно, почему взято именно 47%. Я-то понимаю: если на вёрстке пишут «47% от ширины», это чаще всего означает, что 3% ушло на отступы между блоками. Однако всё равно писать код нужно так, чтобы это было понятно без гаданий.

Магические числа определяют, насколько быстро верстальщик или разработчик, которые будут поддерживать код, разберутся, почему введены такие константы. В общем, проект нужно делать так, чтобы его логику понял даже бэкенд-разработчик, который практически не знает веб-вёрстку. Для этого во время написания кода надо постоянно задавать себе вопрос: «А поймёт ли код другой программист?»

В вёрстке проблема магических чисел решается просто — через переменные CSS или в препроцессорах. Например, она красиво решается в фреймворке Bootstrap — в нём есть отдельный файл _variables.scss, где прописаны все используемые переменные: какие сделаны отступы и почему, какие цвета применяются.

Как избавиться от магических чисел: три способа

Разбивать проект на логические блоки и описывать его с точки зрения архитектуры: например, отступы между колонками, ширину бордеров и тому подобное выносить в переменные, чтобы назначение этих переменных было максимально очевидным. Например, если 3% уходит на отступы между блоками, стоит использовать встроенную в CSS функцию calc и передать в неё значение «50% минус размер отступа».

Не заигрываться с переменными — их не должно быть слишком много, иначе структура разрастётся и снова усложнится. Чаще всего переменные нужны на внутренних и внешних отступах и для цветов.

Стараться не подгонять макет с помощью мелких отступов. Например, если вы видите, что внешний отступ справа 43, а слева 32, то это тревожный звоночек — здесь что-то не так. Как правило, это попытка сделать что-то очень быстро и тут же выпустить в продакшн. Не надо так.

Магические числа — одна из самых распространённых проблем. Однако, чтобы её решить, не нужно алгоритмическое мышление или знание каких-то сложных систем и тайной науки. Если надо отрефакторить проект, однозначно придётся вычищать из него все магические числа. Правда, чаще всего они становятся едиными для всего проекта и используются повсюду, поэтому, чтобы их обнаружить, нужны опыт и насмотренность. А если удалось их найти — смело выводите в переменные и заменяйте.

Хотите научиться верстать сайты с нуля и делать уличную магию — записывайтесь на курс «Веб-вёрстка» в Skillbox.

Источник

После выхода на рынок четвертой и пятой версий популярной платформы МетаТрейдер спрос на автоматические торговые системы значительно вырос. Рост востребованности советников Форекс связан не только с возможностью получения прибыли без вмешательства человека, но и с упрощением работы с роботами и управления ими. В настройках практически любого советника вы встретите такой параметр, как Magic Number. Что он обозначает и для чего используется? Какая цифра должна стоять напротив «магического» параметра? Что нужно знать трейдеру перед началом торговли с помощью автоматической торговой системы?

Что такое Magic Number?

Magic Number (в переводе — магический номер) — специальный идентификатор, который позволяет советнику различать ордера, открытые им, от других сделок. Значимость параметра играет роль только для тех трейдеров, которые на одном торговом счете торгуют как вручную, так и с помощью роботов, или же совмещают торговлю несколькими советниками на одном аккаунте. Если у вас для каждого робота предусмотрен отдельный счет, магическая цифра не имеет никакого значения.

Необходимость в возникновении параметра возникла еще во время существования третьего релиза МетаТрейдера. Трейдерам, устанавливающим два робота на один торговый счет, приходилось быть находчивыми, дабы каждая автоматическая торговая система закрывала только те ордера, которые были ею открыты.

В четвертой версии МТ4 был введен идентификатор — Magic Number. Достаточно установить в поле напротив него цифру, отличную от нуля, и советник будет видеть исключительно свои сделки. При этом параллельно трейдер может торговать вручную на одном и том же аккаунте без страха, что робот закроет по ошибке его операции. В настройках советника параметр Magic Number выглядит таким образом:

Также цифру идентификатора вы можете увидеть после закрытия сделки советником, если подведете курсор мыши к ордеру в списке. Если в перечне у вас присутствуют операции, закрытые другим экспертом, то в истории счета по таким ордерам будет значиться другой идентификатор. Так для примера советника с настройками, как показано выше на рисунке, список сделок будет выглядеть так:

Из скрина видно, что в терминале сохранилась вся информация о сделке — каким советником она была открыта и закрыта, его ID. Это и есть цифра, указанная в разделе настроек как Magic Number.

Настройка Magic Number

Если вы не собираетесь дополнительно нагружать один торговый счет несколькими советниками, достаточно оставить предустановленные настройки неизменными. В некоторых роботах вы вообще не увидите числа Magic Number, но это не означает, что его на самом деле нет. Этот параметр просто зашит в коде автоматической торговой системы и установлен разработчиками. Скорее всего, его числовое значение выбрано таким, которое исключает совпадение с магической цифрой других возможных экспертов.

Рассмотрим ситуации, когда параметр Magic Number необходим. Предположим, что часть средств на своем торговом счете вы отводите для торговли советником, а остальной частью распоряжаетесь по своему усмотрению. Робот торгует автономно — открывает и закрывает сделки. Рано или поздно возникнет ситуация, когда на счете будет открыто одновременно две или более ордеров — по ручной торговой стратегии и по автоматической. В момент, когда советник соберется закрыть операцию, он может ошибиться и закрыть сделку трейдера. В этом случае будут нарушены как правила ручной системы, так и алгоритм эксперта. Такого не произойдет, если в советнике будет установлен уникальный ID.

Аналогичная ситуация возникнет, если вы установите одновременно две разных автоматических торговых системы на один счет или же один и тот же робот на два разных таймфрейма одной валютной пары. Какой же должна быть магическая цифра? Разной.

Параметр Magic Number не должен быть равен нулю. В остальном разработчики не накладывают никаких ограничений. Важно, чтобы цифра была разной для каждого торгового робота, работающего на одном счете трейдера в одной торговой платформе.

Ответы на вопросы пользователей

Наиболее популярным вопросом трейдеров, торгующих автоматическими экспертами, является вопрос о необходимости смены идентификатора при торговле одним советником на разных валютных парах. В этом случае менять Magic Number не нужно. Робот будет самостоятельно распознавать свои сделки на разных финансовых инструментах и путать их не будет. При этом, советник не различает свои же сделки на одной и той же валютной паре, если он дважды установлен на разные таймфреймы. В этом случае ID обязательно должен быть уникальным.

Как поведут себя эксперты, если у них будут одинаковые идентификаторы? Здесь все просто. Советник А будет закрывать ордера советника Б и наоборот, что полностью нарушит алгоритм работы как одного, так и второго робота. Во избежание этого следует обязательно перепроверить параметр Magic Number перед запуском двух автоматических торговых систем одновременно при работе на реальных деньгах. Впрочем, лучше предварительно протестировать корректность работы на демонстрационном счете.

При ручной торговле никакого идентификатора сделок не существует. В этом вы можете убедиться, если в истории счета подведете курсор к любой закрытой сделке. В информационном окне отобразятся следующие данные — «Ордер установлен вручную». Вот как это выглядит на графике в торговой платформе МТ4:

Как мы можем увидеть, операции присваивается лишь уникальный порядковый номер. Больше никакие данные по ручной торговле не отображаются.

Разработчики торговых экспертов обычно самостоятельно прописывают параметры Magic Number в настройках или коде эксперта. Обычно в данном поле присутствует какая-либо цифра по умолчанию. В связи с тем, что это поле ограничено девятью знаками, практически невозможно встретить ситуации, когда цифра в Magic Number в настройках от разработчика совпадает с аналогичной в соответствующем поле другого торгового эксперта. Все, что вам нужно, это перепроверить, чтобы эти параметры были различными и отличались от нуля.

Источник

Магические константы в алгоритмах

Введение

В настоящее время широко известны такие принципы написания программного кода (coding standards), которые позволяют облегчить его поддержку и развитие. Эти принципы используются многими софтверными компаниями, а средства разработки и статического анализа кода предлагают для этого разнообразную автоматизацию. В то же время инженерные задачи в программировании явно требуют расширения понятия «хороший код». Мы попробуем выйти на обсуждение «хорошего» инженерного кода через, казалось бы, весьма частный пример — через практику использования в алгоритмах константных параметров.

Сразу хочется отметить, что эта статья ставит перед собой задачу повышения самоконтроля разработчика, особенно начинающего свою карьеру. Все приведенные далее примеры нужно рассматривать как модельные ситуации, вне привязки к какой-то конкретной вычислительной задаче или какому-то конкретному алгоритму. Можно сказать, что наша цель — сформулировать некоторые паттерны качественного инженерного/алгоритмического программирования.

Давайте подумаем, режет ли нам глаз такой код:

Лично мне режет очень сильно. Во-первых, совершенно непонятно, что такое 150.7?
Вполне возможно, что 150.7 — это сопротивление точного резистора, которое варьируется от одного экземпляра устройства к другому, и на самом деле должно быть считано из калибровочного файла. Что же такое 0.002? Похоже, что это некоторый экспериментальный порог, который может быть уточнен впоследствии, хотя об этом нет никакого специального комментария.

Первая кровь

Представим себе junior-программиста Алешу, которому предложили задачу по автоматизации контроля качества заклепок для космических кораблей компании Inhabited Galactic. По конвейеру поступают эти заклепки и их фотографирует цифровая камера. Алеше необходимо написать код, который анализирует фотографии этих заклепок и принимает решение о соответствии или несоответствии формы заклепки ее нормативу.

Предположим, что к удовольствию своих начальников Алеша быстро реализовал некоторый алгоритм оценки заклепок. Этот алгоритм отлично разделял изображения плохих и хороших заклепок из тестового набора, задача была решена и Алешу переключили на другой проект.

Затем произошло следующее. Заклепок пошло несколько больше, скорость конвейера возросла и инженер Боря немного укоротил выдержку камеры.
При этом поступающие с камеры изображения стали несколько темнее, хотя заклепки все еще были хорошо видны. В то же время Алешин алгоритм начал иногда ошибочно браковать качественные заклепки. Что же произошло?

Пусть это входное монохромное изображение размера с координатами и . Алеша заметил, что пискели заклепки во всех тренировочных изображениях можно было найти пороговой фильтрацией:

При этом качественную заклепку можно было найти по площади:

Итого, Алеша ввел 4 эмпирических константы , , и , по крайней мере одна из которых () потеряла актуальность после перенастройки камеры.

Немного набравшись опыта, Алеша мог бы сделать следующее: перенести значения необходимых констант в конфигурационный файл и дополнить проектную документацию методом их практического вычисления. Это было бы лучше, чем просто спрятать эти значения внутри своего кода, но возложило бы на Алешиных коллег дополнительную задачу по ручной настройке его алгоритма. Конечно, такое решение трудно назвать удовлетворительным, хотя в особенно трудных ситуациях и оно имеет право на существование.

Какое решение было бы более разумным? Параметры полосовых фильтров для яркости и площади можно было перевести в относительные величины к средней яркости и площади изображения. Например, можно было бы заменить на , где — тоже эмпирическое, но уже более инвариантное значение.

Давайте попробуем предположить, что произошло дальше на заводе космических кораблей.
Так как качество отбраковки заклепок было недостаточным, то главный технолог Виталий, далекий от тонкостей программирования, решил срочно поставить на оценочный стенд более дорогую камеру с высокой чувствительностью и вдвое большим разрешением. Закономерный результат такой командной работы — 100%-ая отбраковка, так как все заклепки стали вдвое больше по числу пикселей и ни одна из них не прошла полосовой фильтр. Возможно, что спасло бы грамотное управление проектом, но сейчас мы не об этом.

Нормализация входных данных

Многих проблем с подбором констант можно избежать приводя входные данные к единообразному виду. Изображения — к одной форме гистограммы, 3D модели — к одному разрешению, etc. Зачастую против нормализации выдвигают такой аргумент, что она приводит к потере части исходной информации. Это действительно так, но упрощение дальнейшей работы с параметрами алгоритмов зачастую перевешивают этот минус.

Сама постановка задачи о максимальной нормализации входных данных позволяет разработчику подумать о том, что будет, если изображения придут с поворотом на 90 градусов? А если размеры придут в дюймах? А если кто-то передаст на вход 3D-модель высокого разрешения, которая передает тонкую фактуру материала?

Отличный пример, когда нормализацию, тем не менее, делать не нужно — поиск засвеченных пикселей (бликов) на фотографиях. Пиксели с максимальной яркостью RGB(255, 255, 255) могут образовывать тонкие полоски, которые немного смазываются во время масштабирования картинки. При этом этого яркость засвеченных пискелей усредняется с соседними пикселями и их становится почти невозможно отличить от просто ярких точек изображения. Соответственно, не удастся точно выделить и вырезать блики из изображения.

Калибровочные константы

При обработке достаточно низкоуровневых данных возникает классическая задача калибровки. Это может быть и преобразование напряжения на каком-нибудь терморезисторе в температуру, и преобразование отклика радара в координаты наблюдаемого объекта. Все эти преобразования так или иначе определяются набором постоянных параметров, а процедура определения этих параметров и называется калибровкой.

Калибровочные параметры как правило поступают из внешних источников. Страшный грех — захардкодить эти параметры. Если такой код сразу не отсеять на code review, то он сможет долго портить поведение программного продукта в целом, оставаясь при этом вне подозрений. Система просто будет работать не совсем точно, но едва ли где-то выскочит сообщение об ошибке.

Для полноты картины, однако, необходимо отметить, что в некоторых задачах возможна автокалибровка, когда внутренние зависимости наблюдаемых величин позволяют вычислить также и калибровочные параметры. Смотрите, например, последние главы Multiple View Geometry или работы по Uncalibrated Structure from Motion, где калибровочные параметры камер определяются из набора перекрывающихся снимков с разными ракурсами.

Общие замечания

Давайте константам осмысленные имена и комментируйте их значения. Помните, что это очень хрупкая часть кода, которая не защищена типизацией языка или мудростью компилятора.

Группируйте параметры алгоритмов в структуры. Это обычно улучшает читаемость кода и позволяет не прозевать какой-нибудь важный параметр во время отладки.

Если вы знаете, что один какой-то параметр выражается через другие, обязательно отразите эту связь в коде. В противном случае кто-нибудь с самыми лучшими намерениями поменяет ваши неоптимальные, но консистентные параметры на неконсистентные. Например, вы ищете на изображении кружочки радиусом = 10 и площадью = 314. Это плохо, так как на самом деле у вас один параметр — радиус = 10, а . Код с двумя параметрами может быть легко сломан программистом, забывшим школьную математику, а код с одним параметром выглядит гораздо надежнее.

Бывает так, что в алгоритм входит какая-то неэмпирическая константа. Например, нужно оценить хвост какого-нибудь распределения. Точность такой оценки определяется в большей степени математической подготовкой автора алгоритма.
Константы-оценки иногда можно улучшать, но такое улучшение обычно является изолированной задачей. Важно прокомментировать этот факт для других разработчиков.

Источник