Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Хехе, еще один счастливый клиент :)- пока мы здесь, LEHayes, не могли бы вы помочь мне рассчитать управление капиталом в процентах без округления пунктов в большую сторону. Вот что я сейчас использую, когда хочу поставить 1% от капитала моего счета:
double Profit_F=0.00001,Lots=0.1;
Lots=NormalizeDouble((AccountEquity()*Profit_F),1);
если (Lots < 0.1) Lots=0.1;
если (Lots > 1.0) Lots=1.0;
Это отлично работает для моего стоплосса в 100, когда у меня есть $10,000, например. Поскольку $10,000 X 0.00001 = 0.1 лота. Но когда у меня $15 000, размер лота теперь равен 0.15, но округляется до 2.0, возможно, потому что мой брокер не разрешает макро-лоты. Как я могу заставить его оставаться на уровне 0.1, пока капитал не достигнет $20,000? Я уже давно не спал, после прочтения вашей темы я слишком устал для поиска и изучения. Если у вас есть другое уравнение для расчета mm, пожалуйста, приведите его вместо этого.
Это сводит меня с ума, я уже несколько месяцев ищу существующую алгоритмическую схему, которая не делает ничего другого, как вычисляет цену за пипсовку, независимо от пары, на которой она находится. Я нашел 2 действительно хорошие стратегии управления капиталом, которые обе зависят от этого значения как способа предварительного расчета размеров сделок и управления денежными рисками, но я не могу найти ни одного примера расчета, который бы обрабатывал Price Per Pip.
Я готов предложить вам свою систему управления капиталом в обмен на эту функцию. Я предоставлю вам обе техники, предложенные наставниками, с которыми я работал.
Сначала мы должны понять, что существует пять основных типов символов. Это важно, когда речь идет о таких вопросах, как расчет tick_value, кредитного плеча и так далее.
Формального определения типа символа не существует, но для счета, деноминированного в долларах США, вот как я перечисляю типы символов: (это конкретные примеры, не все включено)
Актуальность заключается в том, как деноминация счета связана с базовой валютой и контрвалютой интересующего финансового инструмента. Это одинаково как для CFD, так и для валютных пар.
В этом примере функция вызова, которую я закодировал, уже определила бы, что для AUDCAD CalculatedBasePairForCross - это AUDUSD:После того как вы определили тип инструмента, вы можете рассчитать кредитное плечо для каждого финансового инструмента - например, вот код, необходимый для расчета кредитного плеча для AUDCAD:
CalculatedBasePairForCross=StringConcatenate(SymbolBase,AccountCurrency(),postfix);
А SymbolBase (то есть базовая валюта финансового инструмента Symbol()) является:И так далее.
Для расчета стоимости тика необходимо учитывать тип символа, так как это имеет значение при изменении оценки как интересующего финансового инструмента - Symbol(), так и соединительной валютной пары, которая ведет обратно к номиналу счета. Продолжая приведенный выше пример, где мы обсуждаем тип символа 4 - AUDCAD, когда счет деноминирован в долларах США - стоимость тика явно определяется как:
Где переменная CalculatedCounterPairForCross для AUDCAD ранее была определена как USDCAD:
CalculatedCounterPairForCross=StringConcatenate(AccountCurrency(),SymbolCounter,postfix);
И SymbolCounter был определен как:Запрограммировав вычисление этих значений таким образом, вы можете делать определения рыночной информации без учета брокера.
Помните, что приведенный здесь код полезен только для symboltype = 4, в котором валюта номинала счета является контрвалютой в паре с базовой валютой Symbol(), и точно так же валюта номинала счета является базовой валютой в паре с контрвалютой, образующей пару Symbol().
(AUDCAD -> AUDUSD & USDCAD).
Получается, что хотя существует пять универсальных типов символов, вам нужно классифицировать только четыре из них для вычисления кредитного плеча, маржи и стоимости тика. А математика становится специфическим камнем преткновения только при работе с кросс-валютными парами относительно номинала счета.
Я разработал конкретные соотношения между всеми базовыми и контр-комбинациями, потому что мой подход к управлению капиталом заключается в том, чтобы четко определить стоимость под риском потерь для каждой сделки, а это требует точного знания значения цены, при которой необходимо выйти из сделки так, чтобы потери соответствовали ранее определенному бюджету потерь. Для кросс-пар естественно получается, что стоимость под риском основывается на цене двух валютных пар в любой момент времени (если вы не хеджируетесь против одной или другой).
Помогает ли эта информация?
TICKVALUE, когда используется сам по себе, может быть ненадежным.
Было бы интересно узнать, к какому брокеру (брокерам) это относится, или есть ли другие соображения, такие как нахождение вблизи открытия/закрытия рынка. Я никогда не мог воспроизвести эти ваши выводы.
Помогает ли эта информация?
вау, я никогда не знал, что существует так много способов расчета стоимости пункта, в моем советнике я делал это, позволяя ea рассчитывать его, используя первый открытый ордер, если это покупка, текущая цена спроса - цена открытия ордера / прибыль ордера = стоимость пункта в текущей базовой валюте, или если это продажа, текущая задача + цена открытия / прибыль ордера = стоимость пункта, это не будет работать правильно?
Edit: Я понял, что написал это наоборот, я имел в виду orderprofit/(currentbid-openprice)=pip value
я никогда не знал, что существует так много способов вычисления стоимости пункта, в моем советнике я делал это, позволяя ea вычислять его, используя первый открытый ордер, если это покупка, текущая цена спроса - цена открытия ордера / прибыль ордера = стоимость пункта в текущей базовой валюте, или если это продажа, текущая задача + цена открытия / прибыль ордера = стоимость пункта, будет ли это работать неправильно?
Этот расчет действителен в том пределе, что каждый пункт имеет одинаковую оценку, независимо от текущей цены покупки или продажи.
Это строго верно для валютных пар, которые имеют тип символа = 2, как я определил их выше, т.е. EURUSD и т.д. (любая валютная пара, в которой номинал счета является контрвалютой в паре).
Для большинства людей эти различия вряд ли будут иметь значение, результирующие ошибки будут небольшими. В моем случае я хотел надежно вычислить значения с помощью корректных аналитических выражений.
Например, если я планирую $200 для максимального возможного убытка по предстоящей сделке, а мои стопы установлены на 200 пунктов, то я хочу знать размер лота для моего ордера, чтобы мои потери не превысили $200... чтобы быть надежным в этом, я должен правильно рассчитать оценку пунктов в точке цены стоплосса. Выигрыш не является приемлемым вариантом ни для меня, ни для моих клиентов ;)
Я рад, что LEHayes все уладил. И Филипп, вы полностью демистифицировали TickValue & layout pairs-synthesizing очень хорошо для всех. Потрясающе!
Я только хотел бы добавить: операции синтеза ...
CalculatedCounterPairForCross=StringConcatenate(AccountCurrency(),SymbolCounter,postfix);
SymbolCounter=StringSubstr(Symbol(),3,3);
... нужно следить за дополнительным приложением, как USDJPYm у некоторых брокеров мини-лотов. Не знаю, может ли брокер изменить первые шесть букв символов, поставив или добавив букву перед или между базой и счетчиком, если вы ищете надежность, IMO чтение из .set файла или .sel файла является более безопасной ставкой.
Я рад, что LEHayes все уладил. И Филипп, вы полностью демистифицировали TickValue & layout pairs-synthesizing очень хорошо для всех. Потрясающе!
Я только хотел бы добавить: операции синтеза ...
CalculatedCounterPairForCross=StringConcatenate(AccountCurrency(),SymbolCounter,postfix);
SymbolCounter=StringSubstr(Symbol(),3,3);
... нужно следить за дополнительным приложением, как USDJPYm у некоторых брокеров мини-лотов. Не знаю, может ли брокер изменить первые шесть букв символов, поставив или добавив букву перед или между базой и счетчиком, если вы ищете надежность, IMO чтение из .set файла или .sel файла является более безопасной ставкой.
Хорошая мысль! Однако я не ищу такой надежности, когда говорю о надежных расчетах.
Брокеры могут называть свои валютные пары как угодно, надеюсь, у меня хватит ума заметить это и внести соответствующие поправки в свои коды, прежде чем пытаться торговать в реальном времени с новым брокером, использующим валютный символ lovelyUSDmoonCADcheese! :P
Этот код просто решает 100% случаев, с которыми я сталкивался до сих пор (Alpari, CitiFX, CMS forex, forex.com, FXCM, FXDD, IBFX, MIG, и ODL)... Я не беспокоюсь о том, чтобы сделать его защищенным на будущее, а только на настоящее. Если у вас есть что-то на уме, чтобы сделать его перспективным... что ж, сейчас самое время высказать свое мнение :)
lovelyUSDmoonCADcheese! ...
Лол! Я видел, как брокер неправильно вводил описание символа в свойстве символа (не параметр Symbol(), но в какой-то момент им приходится вводить и его!) Кто знает! :))
Я не могу сказать, будет ли это на 100% надежно (да и что это такое?). Но я думаю что-то вроде этого:
Гордон некоторое время назад высказал мне свое мнение о том, какие достоинства имеет автоматическая проверка на дурака в советнике. Имея это в виду (и уважая его), я все еще думаю, что это может быть чем-то стоящим, даже просто ради этого! :)