Обсуждение статьи "Библиотека для простого и быстрого создания программ для MetaTrader (Часть XVII): Интерактивность объектов библиотеки" - страница 3

 
Artyom Trishkin:

Свойства ордеров получать можно. Свойства позиций - тоже можно. Из свойств позиций можно получить всю её историю - от торгового приказа, до закрытия. Каждая сделка позиции позволяет узнать ордер, при помощи которого была получена сделка. В общем - вся история любой позиции легко получается, а в ней - все ордера и сделки.

отлично!

это нужный для меня материал для изучения, я знаю, что Вы владеете знанием как устроенна ордерная система МТ5 (к сожалению, на этом форуме практически отсутствуют люди обладающие этой информацией)

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

 
Igor Makanu:

отлично!

это нужный для меня материал для изучения, я знаю, что Вы владеете знанием как устроенна ордерная система МТ5 (к сожалению, на этом форуме практически отсутствуют люди обладающие этой информацией)

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

В первой части рассказано про общую структуру библиотеки (она остаётся практически такой, как описана, но претерпевает доработки в процессе повествования).

Со второй части начинается создание коллекции ордеров и позиций. В четвёртой части начинают обсуждаться торговые события... И всё это тянется до девятой статьи, где начинается доработка до совместимости с MQL4.

 
Artyom Trishkin:

Сюрреализм, Пётр, он только в вашей голове - здесь же всё структурировано и легкодоступно....

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

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

Вдумайтесь в это: "...размера контролируемого изменения и величину контролируемого уровня значения свойства объекта." Что такое " величина контролируемого уровня значения свойства объекта"? То есть, 1. Есть свойство объекта. 2. У свойства есть контроллируемый уровень значения. 3. У контроллируемого уровня есть n- ое кол-во величин  и ... 4. Есть еще размер контроллируемого изменения, который может меняться. Не кажется, что перебор в количестве сущностей? Это только капля в море философии в вашей статье.

Далее:

"Поэтому здесь подходит контроль за изменением состояний свойств объекта: целочисленных и вещественных — их список для каждого класса-наследника уникален и будет представлять собою идентификатор события. Также нам необходимо будет учитывать направление изменения свойств — увеличение или уменьшение значения свойства — назовём это причиной события, и величину, на которую было изменено свойство объекта. Идентификатор события, его причину и величину изменения будем записывать в простой класс базового события объекта и сохранять в списке одновременно произошедших событий. "

Перечислим найденные сущности:

1. "Изменение состояний свойств объекта". То есть, есть свойства и есть состояния свойств объекта. По видимому, под состоянием свойства подразумевается его значение. Но значение можно представить как объект, свойством которого будет его тип. Что вы и сделали, разделив состояния свойства (значение) на целочисленное и вещественное. Потом, возникла отсылка к некому уникальному списку (не знаю когда именно возникшему) целочисленных и вещественных состояний свойств объектов наследников класса.

2. "Направление изменения свойств" Ну, это понятно - увеличение/уменьшение значения это и есть направление изменения. НО ПОЧЕМУ НАПРАВЛЕНИЕ ИЗМЕНЕНИЯ ЯВЛЯЕТСЯ ПРИЧИНОЙ СОБЫТИЯ? В принципе, смена направления причина события, а не само направление.

3. " Идентификатор события, его причину и величину изменения будем записывать в простой класс базового события объекта и сохранять в списке одновременно произошедших событий."

Ну, это поразительно. Есть идентификатор события. Хорошо. Есть причина события и величина изменения чего то (просто величина изменения. абстрактно), хорошо. НО ЕСТЬ ПРОСТОЙ КЛАСС БАЗОВОГО СОБЫТИЯ! Повторю: Простой класс базового события! Абстракция от абстракции. Событие, как вещь в себе, обрела свой класс! Но это только событие объекта. Значит могут быть события свойств, уровня значения (состояний свойства).

И вишенка на торте:

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

Это только малый фрагмент большой статьи серии. Вы считаете, что все очень просто? )) Буду изучать ваши статьи как интересный программный эксперимент человека, который по призванию должен был стать философом.))

 
Реter Konow:

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

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

Вдумайтесь в это: "...размера контролируемого изменения и величину контролируемого уровня значения свойства объекта." Что такое " величина контролируемого уровня значения свойства объекта"? То есть, 1. Есть свойство объекта. 2. У свойства есть контроллируемый уровень значения. 3. У контроллируемого уровня есть n- ое кол-во величин  и ... 4. Есть еще размер контроллируемого изменения, который может меняться. Не кажется, что перебор в количестве сущностей? Это только капля в море философии в вашей статье.

Далее:

"Поэтому здесь подходит контроль за изменением состояний свойств объекта: целочисленных и вещественных — их список для каждого класса-наследника уникален и будет представлять собою идентификатор события. Также нам необходимо будет учитывать направление изменения свойств — увеличение или уменьшение значения свойства — назовём это причиной события, и величину, на которую было изменено свойство объекта. Идентификатор события, его причину и величину изменения будем записывать в простой класс базового события объекта и сохранять в списке одновременно произошедших событий. "

Перечислим найденные сущности:

1. "Изменение состояний свойств объекта". То есть, есть свойства и есть состояния свойств объекта. По видимому, под состоянием свойства подразумевается его значение. Но значение можно представить как объект, свойством которого будет его тип. Что вы и сделали, разделив состояния свойства (значение) на целочисленное и вещественное. Потом, возникла отсылка к некому уникальному списку (не знаю когда именно возникшему) целочисленных и вещественных состояний свойств объектов наследников класса.

2. "Направление изменения свойств" Ну, это понятно - увеличение/уменьшение значения это и есть направление изменения. НО ПОЧЕМУ НАПРАВЛЕНИЕ ИЗМЕНЕНИЯ ЯВЛЯЕТСЯ ПРИЧИНОЙ СОБЫТИЯ? В принципе, смена направления причина события, а не само направление.

3. " Идентификатор события, его причину и величину изменения будем записывать в простой класс базового события объекта и сохранять в списке одновременно произошедших событий."

Ну, это поразительно. Есть идентификатор события. Хорошо. Есть причина события и величина изменения чего то (просто величина изменения. абстрактно), хорошо. НО ЕСТЬ ПРОСТОЙ КЛАСС БАЗОВОГО СОБЫТИЯ! Повторю: Простой класс базового события! Абстракция от абстракции. Событие, как вещь в себе, обрела свой класс! Но это только событие объекта. Значит могут быть события свойств, уровня значения (состояний свойства).

И вишенка на торте:

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

Это только малый фрагмент большой статьи серии. Вы считаете, что все очень просто? )) Буду изучать ваши статьи как интересный программный эксперимент человека, который по призванию должен был стать философом.))

Как у вас всё оказывается сложно лежит в голове :D

Вы сами себе придумали сложность.

Может конечно я очень плохо поясняю, но...

Есть у нас цена. Цена - это свойство символа. У цены есть возможность изменяться. Либо в сторону её увеличения, либо в сторону её уменьшения. Размер (величину, на которую цена увеличилась или уменьшилась мы имеем право контролировать и устанавливать - это " размер контролируемого изменения"). А ещё цена может пересечь заданное (контролируемое нами в программе) значение, которое мы тоже можем устанавливать - это " величина контролируемого уровня значения свойства объекта".

Это понятно?

Есть у нас спред. Спред- это свойство символа. У спреда есть возможность изменяться. Либо в сторону его увеличения, либо в сторону его уменьшения. Размер (величину, на которую спред  увеличился или уменьшился мы имеем право контролировать и устанавливать - это " размер контролируемого изменения"). А ещё спред может пересечь заданное (контролируемое нами в программе) значение, которое мы тоже можем устанавливать - это " величина контролируемого уровня значения свойства объекта".

Это понятно?

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

Итак: разные свойства одного и того же объекта можно контролировать по-разному - создать методы контроля для каждого из свойств - написать для каждого свойства свой контроль и на том и успокоиться. А можно написать один метод контроля за абсолютн любыми свойствами любых объектов, и не писать тонны кода для каждого свойства.  А написать лишь один метод сразу для всех.
И вот после того, как объект записал свои события в список собственных событий (эти события называются базовыми - они есть у абсолютно каждого объекта), потом в программу отправляются события - полноценные события, которые пользователь уже может обработать и принять решение, то чтобы знать в программе от какого объекта пришло событие, и что это вообще за событие, нам требуется его описать. И описать однозначно. Для этого существуют три параметра:

  1. тип объекта - это идентификатор коллекции, в которой мы проверяем состояние некоего свойства. Допустим, это коллекция символов - значит первое число - это идентификатор коллекции символов, и оно нам указало на то, что мы проверяем именно объект-символ на предмет изменения какого-то из его свойств.
  2. причина события - это то, что послужило тому, чтобы объект зарегистрировал своё событие - увеличение или уменьшение значения свойства на величину, которую мы контролируем (например - увеличение спреда больше, чем на 2 пункта), или пересечение ценой контролируемого нами уровня - цена стала ниже контролируемого нами уровня, и можно отправить пользователю событие о том, что можно и прикупиться...
  3. свойство, в котором произошло событие - свойств много, и чтобы знать какое свойство сгенерировало событие, нам нужно получить его номер в списке свойств объекта.

Итого: мы точно знаем, что (1) именно символ послал нам событие, (2) - свойство стало меньше контролируемого уровня, и (3) - это свойство есть цена Bid.

Сложно? Не придумывайте - всё просто.

И тут - бац и:

Есть у нас разрешение на торговлю. Разрешение на торговлю- это свойство аккаунта. У разрешения на торговлю есть возможность изменяться. Причём на несколько значений. Размер (величину, до которуой разрешение на торговлю изменилось мы имеем право контролировать и устанавливать - это " размер контролируемого изменения"). А ещё разрешение на торговлю может пересечь заданное (контролируемое нами в программе) значение, которое мы тоже можем устанавливать - это " величина контролируемого уровня значения свойства объекта", например - возник запрет на открытие позиций на покупку.

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

Это понятно?

А вообще - в статьях всё расписано. Но вы, похоже просто троллите? :) Ведь чтобы задавать такие вопросы - нужно читать сразу с настроем "как всё тут запущено", а не вникать в простую организацию данных.

 
Artyom Trishkin:
...Сложно? Не придумывайте - всё просто....

Классическая ошибка авторов статей, - считать, что если им материал понятен, то он понятен всем.) Но, это не так. 

Ваше пояснение сейчас многое поставило на место, и если бы поместили его в статью (скажем вначале), далее было бы яснее. И вас я не троллю. Просто когда поток абстракции (пусть оправданной и нужной) не перемешивается с конкретикой и когда они не ссылаются и не объясняют друг на друга, (абстракция начинает преобладать), возникают мнения как те, что я высказывал выше.

ЗЫ. В общем, как я понял, вы стремитесь в этой библиотеке обобщить и собрать все, что есть в алготрейдинге.

 
Реter Konow:

Классическая ошибка авторов статей, - считать, что если им материал понятен, то он понятен всем.) Но, это не так. 

Ваше пояснение сейчас многое поставило на место, и если бы поместили его в статью (скажем вначале), далее было бы яснее. И вас я не троллю. Просто когда поток абстракции (пусть оправданной и нужной) не перемешивается с конкретикой и когда они не ссылаются и не объясняют друг на друга, (абстракция начинает преобладать), возникают мнения как те, что я высказывал выше.

ЗЫ. В общем, как я понял, вы стремитесь в этой библиотеке обобщить и собрать все, что есть в алготрейдинге.

Всё, что я хочу сделать - дать людям инструмент для удобного создания программ любой сложности алгоритмов.

Библиотека просто-напросто всю рутину, которую приходится всегда писать самому, берёт на себя.

Пользователю останется только "задать вопрос - получить ответ - обработать его"

Причём библиотека сама будет напоминать о происходящих событиях. Т.е., в принципе, достаточно будет лишь поглядеть что за событие, и от какого объекта пришло, и далее - по задуманной логике обработать его.

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

Либо попросить дать последнюю закрытую позицию и далее самому её разобрать по составляющим - благо библиотека позволяет получить все данные о любой позиции, которую пользователь взял из данных библиотеки.

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

Да в принципе, можно много навыдумывать и реализовать - я стараюсь дать все возможные для этого инструменты. Автоматические - всё уже есть, и самому их придумывать уже не нужно - только получать готовое и заботливо отданное ;)

 
Реter Konow:

Классическая ошибка авторов статей, - считать, что если им материал понятен, то он понятен всем.) Но, это не так. 

...

А классическая ошибка некоторых читателей - что они не читают, но сразу задают вопросы :)

Если начать читать с первой статьи, то таких вопросов точно не будет, ведь вся "философия" - там, и она разъяснена.

 

Артем, спасибо!

Не надо, не останавливайся, пиши - получается классно.

С интересом прочитал вашу дискуссию с Петром. Очень корректно и по делу.

Написал письмо в компанию "AMD",-  Я хоть и не занимаюсь проектированием и выпуском процессоров, но, ребята, ерунду вы спороли в 8-нм техпроцессе...

Жду ответа

 
Реter Konow:

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

Философия здесь вот в чём: индукция (от частного к общему) или дедукция (от общего к частному).

Артём использует индуктивный метод подачи материала.

Шеф: Нус, Глеб Георгиевич, имеется пуля. Ваши суждения...

Жеглов: Ну, что скажешь, "разведка"?

Шарапов: Ну что, пуля как пуля, обыкновенная, пистолетная...

Жеглов: Да, хорошо бы еще гильзу найти.

Шеф: Лучше уж посмотреть само оружие.

Жеглов: Верно. ну значится так: пуля выпущенная из импортного оружия калибра 6.35 системы "Баярд" или, скажем, "Омега".

Шеф: А сие из чего следует?

Жеглов: Из пули, Сергей Ипатич, из пули. Шесть левых верликальных нарезов, вот они - почерк вполне "самостоятельный".

Шеф: А что вы скажете на это? Судя по маркировке - гильза наша, отечественная.

Жеглов: Да. А где нашли?

Шеф: Там где и следует. Слева от тела. Нормально сработал отражатель.

Жеглов: Да, гильза наша. Хм. Ну что же, запишем в загадки. И всё равно надо искать оружие. Надя, вы не знаете, в доме было оружие?

Надежда: Не знаю.

[Вайнеры. Эра милосердия]

 
Aleksei Mikhanoshin:

Артем, спасибо!

Не надо, не останавливайся, пиши - получается классно.

С интересом прочитал вашу дискуссию с Петром. Очень корректно и по делу.

Написал письмо в компанию "AMD",-  Я хоть и не занимаюсь проектированием и выпуском процессоров, но, ребята, ерунду вы спороли в 8-нм техпроцессе...

Жду ответа

Привет, Алексей.

Зачем останавливаться в начале пути? Уже все остановки на раздумье были - теперь только вперёд по кочкам ;)

Ну и как, ответили тебе из AMD ?

Причина обращения: