Мое определение теряет свой первоначальный смысл, когда цитируется вне контекста. Чтобы уточнить - слово "цена" в определении для MODE_TICKSIZE относится к фактическим возможным котировкам цены, тогда как в определении для Point оно относится к любой цене.
- Гордон, мое определение тоже не слишком горячее ("Point" = коэффициент умножения для наименьшей десятичной цены), а шестнадцатеричная аналогия такая неубедительная... Но, возможно, у меня есть победитель...
Логика Брокеру необходимо установить ценовые отношения между парами, чтобы они вращались вокруг MODE_LOTSIZE - 100,000 единиц котируемой валюты и MODE_TICKVALUE - 10 единиц котируемой валюты. Только при этом равном условии взаимосвязи, цена может котироваться между собой. Это, я полагаю, и есть основа построения цены на Форекс.
Point = MODE_LOTSIZE / Tickvalue в котируемой валюте. например: GBPUSD 0.0001 = 100,000 / 10 USD USDJPY 0.01 = 100,000 / 1,000 JPY <-- MathRound( MODE_TICKVALUE * последний Bid котируемой валюты) CHFJPY .... и т.д. если вы или кто-либо другой может подтвердить это, было бы здорово.
Все ставки сделаны, если мы собираемся начать говорить о фьючерсных контрактах. Например, у FXPro есть фьючерсные контракты в почти обычном формате #AAmy, где "my" - это стандартный код экспирации, например M0. EUR_JPY_fut звучит как какой-то странный синтетический контракт.
- Хорошо, Jjc... Я предполагаю, что фьючерсы также имеют разное построение цены и TICK_VALUE. Так что это определенно исключает все нефорексные инструменты. Префиксы и промежуточные фиксы считаются менее вероятными.
- CB Мне было бы очень интересно услышать ваше мнение по поводу вышеприведенного расчета. Спасибо за ваше мнение до сих пор.
- Гордон, мое определение тоже не слишком удачное ("Point" = коэффициент умножения для наименьшей десятичной цены), а аналогия с шестнадцатеричной системой так неубедительна... Но, возможно, у меня есть победитель...
Логика Брокеру необходимо установить ценовые отношения между парами, чтобы они вращались вокруг MODE_LOTSIZE - 100,000 единиц котируемой валюты и MODE_TICKVALUE - 10 единиц котируемой валюты. Только при этом равном условии взаимосвязи, цена может котироваться между собой. Это, я полагаю, и есть основа построения цены на Форекс.
Point = MODE_LOTSIZE / Tickvalue в котируемой валюте. например: GBPUSD 0.0001 = 100,000 / 10 USD USDJPY 0.01 = 100,000 / 1,000 JPY <-- MathRound( MODE_TICKVALUE * последний Bid котируемой валюты) CHFJPY .... и т.д. если вы или кто-либо другой может подтвердить это, было бы здорово.
- Хорошо, Jjc... Я предполагаю, что у фьючерсов также есть различные построения Price и TICK_VALUE. Так что это определенно исключает все нефорексные инструменты. Префиксы и промежуточные фиксы считаются менее вероятными.
- CB Мне было бы очень интересно услышать ваше мнение по поводу вышеприведенного расчета. Спасибо за ваше мнение на данный момент.
наилучшие пожелания камея
Изменится ли логика, если цифры = 5 или цифры = 3?
Would the logic change if Digits = 5 or Digits = 3?
Нет engcomp, логика не должна меняться. По крайней мере, это то, что я пытаюсь выяснить.
Я пытаюсь разобраться в нескольких вещах, пока что это : Point, MODE_TICKVALUE, MODE_TICKSIZE, Price. Возможно, в итоге я представлю их в новом свете, но если я смогу использовать их дальше, то это будет того стоить.
IMO, MODE_TICKVALUE, преобразованный в котируемую валюту, очень важен. Так что ради обсуждения я буду называть его QUOTE_TICKVALUE. Кстати, предыдущее уравнение является обратным.
Чтобы вычислить, действительно ли Point является : QUOTE_TICKVALUE (TickValue в котируемой валюте) / MODE_LOTSIZE, у меня есть следующее. (Calc_Point должен соответствовать Point).
Примечание: для кросс-пары, у которой котируемая валюта является базовой в долларовой форме (например, EURGBP), необходимо немного изменить вышеуказанное.
Итак, влюбой момент времени, по любой цене:
USDJPY, GBPJPY, AUDJPY, XXXJPY............. имеет QUOTE_TICKVALUE --> 1000 [JPY] EURUSD, AUDUSD, GBPUSD, XXXUSD ........ имеет QUOTE_TICKVALUE --> 10 [USD] EURCHF, USDCHF, XXXCHF....................... имеет QUOTE_TICKVALUE --> MathPow(10, x) [CHF].
Я должен подчеркнуть, что я "извлекаю" QUOTE_TICKVALUE из плавающего TICK_VALUE. Я думаю, что это означает, что QUOTE_TICKVALUE предопределены брокером, и что более важно: они паралельно будут согласованы между каждой валютой, которая служит в качестве котируемой валюты. Таким образом, пока MODE_LOTSIZE = 100,000 и QUOTE_TICKVALUE USD = 10, мы можем быть уверены, что другие компоненты символа, которые служат валютой котировки, также будут согласованы (т.е. вы не можете изменить 10 USD на 1 USD, не разделив другие QUOTE_TICKVALUE на 10 - это, я полагаю, то, где мы можем определить мою Valid_Point в целом). Надеюсь, это понятно...
Я не могу (ради жизни) иметь net и MT4 одновременно в эти дни (это сложно...). Так что если кто-то может помочь или проверить, было бы здорово.
Я нашел то, что мне нужно, Valid_Point и даже больше. Более глубокое понимание Point, TickValue, Ticksize, Symbol(), и цены в целом. Спасибо всем, кто поделился своими соображениями и комментариями с тех пор, как LEHayes начал эту тему.
Блин, посмотрите, сколько мозгового штурма я устроил. Надеюсь, это было полезно. У меня не было времени следить за этой темой, но я надеюсь получить шанс просмотреть ее.
После всех этих обсуждений и отличной работы, пришли ли мы к тому, что у нас есть какая-то стандартная функция для генерации того, что мы искали? Этот вопрос призван подвести нас к итогу.
Есть ли у кого-нибудь опыт использования вышеприведенных советов по расчету на металлах или других символах, отличных от кросс-валют?
Я нашел эту тему, так как меня интересовал расчет изменения цены в валюте счета от движения одного пункта в символе.
Моя базовая теория была следующей:
Цена за пункт = Размер контракта * Пункт
Цена за пункт в валюте счета = Цена за пункт * Кросс-курс счетчика,
где
Размер контракта = MarketInfo(Symbol(), MODE_LOTSIZE)
Пункт = Пункт = MarketInfo(Symbol(), MODE_POINT)
Account Counter Cross rate - это цена встречной валюты символа, выраженная в валюте счета (CCCAAA bid rate, где AAA - валюта счета, а CCC - встречная валюта символа).
Я проверил вышесказанное на демо-счетах разных брокеров (icm, insta, fxopen, fxopen ecn) против фактических сделок лотом 1.0 в истории счета. Я также проверил метод расчета тикового значения у cloudbreaker.
Я обнаружил следующее:
- Цену движения одного пункта символа нелегко рассчитать у разных брокеров, а в случае металлов
- даже формула cloudbreaker'а tickvalue * point / ticksize может привести к ложным результатам (insta - серебро, icm - eurusd, fxopen - серебро и золото).
- в случае icm - золото, даже Contract size * Point приводит к плохому результату (0.5 вместо фактических 5.0, это ошибка данных брокера?).
Спасибо, что поделились этой маленькой программой, которую вы написали. Я не могу поверить, что это было так просто!!! вы сэкономили мне кучу времени :-)
engcomp:
Прилагается небольшой скрипт, который я разработал и который может ответить на ваш вопрос.
Поскольку у скриптов нет параметров "extern", вам придется изменить их в коде и перекомпилировать.
Просто загрузите его в папку experts/scripts, скомпилируйте и прикрепите к графику.
double PointValuePerLot(string pair=""){
/* Value in account currency of a Point of Symbol.
* In tester I had a sale: open=1.35883 close=1.35736 (0.0147)
* gain$=97.32/6.62 lots/147 points=$0.10/point or $1.00/pip.
* IBFX demo/mini EURUSD TICKVALUE=0.1 MAXLOT=50 LOTSIZE=10,000
* IBFX demo/standard EURUSD TICKVALUE=1.0 MAXLOT=50 LOTSIZE=100,000
* $1.00/point or $10.0/pip.
*
* https://forum.mql4.com/33975 CB: MODE_TICKSIZE will usually return the
* same value as MODE_POINT (or Point for the current symbol), however, an
* example of where to use MODE_TICKSIZE would be as part of a ratio with
* MODE_TICKVALUE when performing money management calculations which need
* to take account of the pair and the account currency. The reason I use
* this ratio is that although TV and TS may constantly be returned as
* something like 7.00 and 0.0001 respectively, I've seen this
* (intermittently) change to 14.00 and 0.0002 respectively (just example
* tick values to illustrate).
* https://forum.mql4.com/43064#515262 zzuegg reports for non-currency DE30:
* MarketInfo(Symbol(),MODE_TICKSIZE) returns 0.5
* MarketInfo(Symbol(),MODE_DIGITS) return 1
* Point = 0.1
* Prices to open must be a multiple of ticksize */if (pair == "") pair = Symbol();
return( MarketInfo(pair, MODE_TICKVALUE)
/ MarketInfo(pair, MODE_TICKSIZE) ); // Not Point.
}
Я пытался рассчитать процент риска на нефорексных символах, однако мне не удалось придумать ничего, что было бы хотя бы отдаленно надежным, поскольку большинство нефорексных символов ведут себя совершенно по-разному. Есть ли у кого-нибудь советы, как правильно рассчитать значение пункта на нефорексных символах, чтобы вычислить правильный процент риска?
Мое определение теряет свой первоначальный смысл, когда цитируется вне контекста. Чтобы уточнить - слово "цена" в определении для MODE_TICKSIZE относится к фактическим возможным котировкам цены, тогда как в определении для Point оно относится к любой цене.
- Гордон, мое определение тоже не слишком горячее ("Point" = коэффициент умножения для наименьшей десятичной цены), а шестнадцатеричная аналогия такая неубедительная... Но, возможно, у меня есть победитель...
Логика
Брокеру необходимо установить ценовые отношения между парами, чтобы они вращались вокруг MODE_LOTSIZE - 100,000 единиц котируемой валюты и MODE_TICKVALUE - 10 единиц котируемой валюты. Только при этом равном условии взаимосвязи, цена может котироваться между собой. Это, я полагаю, и есть основа построения цены на Форекс.
Point = MODE_LOTSIZE / Tickvalue в котируемой валюте. например:
GBPUSD 0.0001 = 100,000 / 10 USD
USDJPY 0.01 = 100,000 / 1,000 JPY <-- MathRound( MODE_TICKVALUE * последний Bid котируемой валюты)
CHFJPY .... и т.д. если вы или кто-либо другой может подтвердить это, было бы здорово.
Все ставки сделаны, если мы собираемся начать говорить о фьючерсных контрактах. Например, у FXPro есть фьючерсные контракты в почти обычном формате #AAmy, где "my" - это стандартный код экспирации, например M0. EUR_JPY_fut звучит как какой-то странный синтетический контракт.
- Хорошо, Jjc... Я предполагаю, что фьючерсы также имеют разное построение цены и TICK_VALUE. Так что это определенно исключает все нефорексные инструменты. Префиксы и промежуточные фиксы считаются менее вероятными.
- CB Мне было бы очень интересно услышать ваше мнение по поводу вышеприведенного расчета. Спасибо за ваше мнение до сих пор.
наилучшие пожелания
камея
- Гордон, мое определение тоже не слишком удачное ("Point" = коэффициент умножения для наименьшей десятичной цены), а аналогия с шестнадцатеричной системой так неубедительна... Но, возможно, у меня есть победитель...
Логика
Брокеру необходимо установить ценовые отношения между парами, чтобы они вращались вокруг MODE_LOTSIZE - 100,000 единиц котируемой валюты и MODE_TICKVALUE - 10 единиц котируемой валюты. Только при этом равном условии взаимосвязи, цена может котироваться между собой. Это, я полагаю, и есть основа построения цены на Форекс.
Point = MODE_LOTSIZE / Tickvalue в котируемой валюте. например:
GBPUSD 0.0001 = 100,000 / 10 USD
USDJPY 0.01 = 100,000 / 1,000 JPY <-- MathRound( MODE_TICKVALUE * последний Bid котируемой валюты)
CHFJPY .... и т.д. если вы или кто-либо другой может подтвердить это, было бы здорово.
- Хорошо, Jjc... Я предполагаю, что у фьючерсов также есть различные построения Price и TICK_VALUE. Так что это определенно исключает все нефорексные инструменты. Префиксы и промежуточные фиксы считаются менее вероятными.
- CB Мне было бы очень интересно услышать ваше мнение по поводу вышеприведенного расчета. Спасибо за ваше мнение на данный момент.
наилучшие пожелания
камея
FInally have connection to post...
Would the logic change if Digits = 5 or Digits = 3?
Нет engcomp, логика не должна меняться. По крайней мере, это то, что я пытаюсь выяснить.
Я пытаюсь разобраться в нескольких вещах, пока что это : Point, MODE_TICKVALUE, MODE_TICKSIZE, Price. Возможно, в итоге я представлю их в новом свете, но если я смогу использовать их дальше, то это будет того стоить.
IMO, MODE_TICKVALUE, преобразованный в котируемую валюту, очень важен . Так что ради обсуждения я буду называть его QUOTE_TICKVALUE. Кстати, предыдущее уравнение является обратным.
Чтобы вычислить, действительно ли Point является : QUOTE_TICKVALUE (TickValue в котируемой валюте) / MODE_LOTSIZE, у меня есть следующее. (Calc_Point должен соответствовать Point).
Примечание: для кросс-пары, у которой котируемая валюта является базовой в долларовой форме (например, EURGBP), необходимо немного изменить вышеуказанное.Итак, в любой момент времени, по любой цене:
USDJPY, GBPJPY, AUDJPY, XXXJPY............. имеет QUOTE_TICKVALUE --> 1000 [JPY]
EURUSD, AUDUSD, GBPUSD, XXXUSD ........ имеет QUOTE_TICKVALUE --> 10 [USD]
EURCHF, USDCHF, XXXCHF....................... имеет QUOTE_TICKVALUE --> MathPow(10, x) [CHF].
Я должен подчеркнуть, что я "извлекаю" QUOTE_TICKVALUE из плавающего TICK_VALUE. Я думаю, что это означает, что QUOTE_TICKVALUE предопределены брокером, и что более важно: они паралельно будут согласованы между каждой валютой, которая служит в качестве котируемой валюты. Таким образом, пока MODE_LOTSIZE = 100,000 и QUOTE_TICKVALUE USD = 10, мы можем быть уверены, что другие компоненты символа, которые служат валютой котировки, также будут согласованы (т.е. вы не можете изменить 10 USD на 1 USD, не разделив другие QUOTE_TICKVALUE на 10 - это, я полагаю, то, где мы можем определить мою Valid_Point в целом). Надеюсь, это понятно...
Я не могу (ради жизни) иметь net и MT4 одновременно в эти дни (это сложно...). Так что если кто-то может помочь или проверить, было бы здорово.
камея
Я нашел то, что мне нужно, Valid_Point и даже больше. Более глубокое понимание Point, TickValue, Ticksize, Symbol(), и цены в целом. Спасибо всем, кто поделился своими соображениями и комментариями с тех пор, как LEHayes начал эту тему.
С наилучшими пожеланиями
Камея
Блин, посмотрите, сколько мозгового штурма я устроил. Надеюсь, это было полезно. У меня не было времени следить за этой темой, но я надеюсь получить шанс просмотреть ее.
После всех этих обсуждений и отличной работы, пришли ли мы к тому, что у нас есть какая-то стандартная функция для генерации того, что мы искали? Этот вопрос призван подвести нас к итогу.
Есть ли у кого-нибудь опыт использования вышеприведенных советов по расчету на металлах или других символах, отличных от кросс-валют?
Я нашел эту тему, так как меня интересовал расчет изменения цены в валюте счета от движения одного пункта в символе.
Моя базовая теория была следующей:
Цена за пункт = Размер контракта * Пункт
Цена за пункт в валюте счета = Цена за пункт * Кросс-курс счетчика,
где
Размер контракта = MarketInfo(Symbol(), MODE_LOTSIZE)
Пункт = Пункт = MarketInfo(Symbol(), MODE_POINT)
Account Counter Cross rate - это цена встречной валюты символа, выраженная в валюте счета (CCCAAA bid rate, где AAA - валюта счета, а CCC - встречная валюта символа).
Я проверил вышесказанное на демо-счетах разных брокеров (icm, insta, fxopen, fxopen ecn) против фактических сделок лотом 1.0 в истории счета. Я также проверил метод расчета тикового значения у cloudbreaker.
Я обнаружил следующее:
- Цену движения одного пункта символа нелегко рассчитать у разных брокеров, а в случае металлов
- даже формула cloudbreaker'а tickvalue * point / ticksize может привести к ложным результатам (insta - серебро, icm - eurusd, fxopen - серебро и золото).
- в случае icm - золото, даже Contract size * Point приводит к плохому результату (0.5 вместо фактических 5.0, это ошибка данных брокера?).
Вы можете найти подробные результаты здесь:Цена одного пункта.
Таким образом, я пришел к выводу, что не существует 100% уверенного метода расчета цены за пункт.
Прилагается небольшой скрипт, который я разработал и который может ответить на ваш вопрос.
Поскольку у скриптов нет параметров "extern", вам придется изменить их в коде и перекомпилировать.
Просто загрузите его в папку experts/scripts, скомпилируйте и прикрепите к графику.
Дайте мне знать, как это работает, Хельмут.