Transaq

СБО "Transaq" => Подсистема ATF => Topic started by: nikolz on Марта 13, 2011, 09:43:34 am

Title: Развитие ATF
Post by: nikolz on Марта 13, 2011, 09:43:34 am
Уважаемые разработчики!
С целью расширение выразительности языка ATF предлагаю:
1) оператор(макрос) определения альтернативных имен ( назовем его namedef ).
например есть формула :
line[0]=0.9*line[0][-1]+0.1*(close-line[0][-1]);
в нашем случае  пишем так :
namedef x=line[0];
В результате формула примет вид:
x=0.9*x[-1] +0.1*(close-x[-1]);
что согласитесь более наглядно и привычно.
Так как новый оператор по сути своей является Макросом и исполняется препроцессором, то никаких особых сложностей и замедлений в работе скрипта, кроме ясности в чтении не создает

2) Добавить многострочный комментарий, выделяемый /*...  */

5) добавить возможность определение переменных через запятую одним
 оператором var.
Например, вместо
var x1; var x2; var x3; var x4; var x5;
можно было бы записать :
var x1, x2, x3, x4, x5;

6)     Добавить в окно скриптов опцию "загрузить" , которая позволяла бы обновить загруженный текст скрипта с диска.
  В этом случае можно будет редактировать текст любым редактором, после этого обновить его в терминале, транслировать и исполнять.


7)  Добавить макрос #include , позволяющий включать в тело скрипта другие текстовые файлы, например с описанием функций.

Спасибо
Title: Re: Развитие ATF
Post by: AlexandrBK on Марта 13, 2011, 09:12:37 pm
а разве 3 и 4 пункты не реализованы?
у меня нумерация строк присутствует, редактор красит скрипт в четыре разных цвета,
комментарии - уже зеленые...
или я чего-то не понимаю?
Title: Re: Развитие ATF
Post by: Олег on Марта 13, 2011, 09:31:56 pm
а разве 3 и 4 пункты не реализованы?
у меня нумерация строк присутствует, редактор красит скрипт в четыре разных цвета,
комментарии - уже зеленые...
или я чего-то не понимаю?

Я тоже не понял... Может быть у автора топика какая-нибудь старая версия Транзака? Хотя даже там, по-моему, всё это уже было реализовано.

Лично мне очень понравился пункт №1!
Title: Re: Развитие ATF
Post by: nikolz on Марта 14, 2011, 06:50:57 am
да,была старая версия теперь поставил новую. действительно все есть.
спасибо
Title: Re: Развитие ATF
Post by: nikolz on Марта 14, 2011, 11:54:05 am
Уважаемые разработчики!
Возможно уже реализовано, если нет , то прошу реализовать:
1) функция поиск максимума high[n1,n2]; предполагает параметры n1 и n2 как смещение влево от последней свечи, т.е. значения не больше нуля.
   предлагаю реализовать следующее:
если параметры больше нуля, то они считаются от первой свечи как номер свечи.
2) реализовать функцию ihigh[n1,n2] - смещение до максимума high на заданном интервале.
смещение вычисляется по правилам задания интервала, если интервал задан положительными числами, то смещение - номер свечи максимума, иначе смещение от последней свечи.
спасибо.
Title: Re: Развитие ATF
Post by: nikolz on Марта 15, 2011, 09:13:10 pm
Уважаемые разработчики!
     Я знакомился с вашим ATF год назад, тогда он выглядел убого и я отказался от использования его для написания систем.
    Спустя год, хочу отметить, что ваш ATF произвел на меня теперь очень хорошее впечатление. Если учесть, что я знаю и пишу практически на всех языках программирования, а мой опыт в создании систем различного назначения примерно равен среднему возрасту посетителей сайта, то я знаю, о чем говорю.
    Если  внутренняя реализация ATF по своей эффективности соответствует его описательной части, то у Вас получился хороший и перспективный язык.
    однако, в настоящее время он существенно уступает другим языкам (например скриптовому языку Амиброкера, либо Омеги, либо WLD,либо МТ4 ) в объеме имеющихся библиотечных функций, вернее сказать в отсутствии токовых. 
  Поэтому предлагаю следующее:
Реализовать возможность компиляции функций в библиотеки и указания описания библиотечных функций в программе для подключения их к основной программе на этапе компиляции скрипта (аналог lib или dll).
Опять же сошлюсь на подобные возможности в амиброкере и Омеге,МТ4,МТ5.
  Это позволило бы создавать библиотеки индикаторов и распространять их.
  Кроме того, механизм создания библиотек функций позволил бы реализовать защиту авторских прав, что обеспечило бы более широкое распространение языка ATF, следовательно TRANSAQ , и развитие его возможностей.
благодарю за внимание
Title: Re: Развитие ATF
Post by: Heller on Марта 16, 2011, 01:07:20 pm
По поводу первого сообщения с предложениями.

1) Внесли макрос #define в план в аналогии с препроцессором Си. Правда, приоритет задаче поставили низкий, так что будет еще не скоро, но то что будет - уже точно.

2) Многострочные комментарии есть.

5) Вероятно сделаем в некоторой перспективе, но пока не планируем. С текущей реализацией придется проводить неудобные переделки, а выгода минимальна. Хотя когда-нибудь все же приведем в порядок. Пока более приоритетные задачи - это более адекватная работа с циклами, например. А там видно будет.

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

По второму сообщению.

1), 2) Функция максимума есть: findMax и findMin. Синтаксически наверное ваш вариант был бы более удобен, но не подумали об этом. Ну и вообще синтаксис в таких моментах уже не планируется расширять, по крайней мере пока, только за счет расширения набора функций.

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

И спасибо за лестный отзыв :)
Title: Re: Развитие ATF
Post by: Олег on Марта 16, 2011, 08:05:24 pm
2) Добавить многострочный комментарий, выделяемый /*...  */
2) Многострочные комментарии есть.
А почему в Руководстве об этом ничего нет? Я до сих пор по-старинке выделяю каждую строку всех комментариев (и многострочных тоже) знаком //. Сейчас попробовал, работает.
Title: Re: Развитие ATF
Post by: nikolz on Марта 17, 2011, 08:31:24 am
Уважаемые разработчики!
Предлагаю:
1) реализовать возврат функцией IndRef не только line, но и объекты (массивов и хэшов, буфферов линий)

          Очень желательно реализовать две следующие функции:
2) функция , формирования истории в linebuffer для любого инструмента по его seccode.
Например:
    var buffer_SBER=0;
    var seccode="SBER03";
    var time_frame=1; //интервал 1 минута
    var len_history=100; //глубина  истории 100 свечей
           buffer_SBER=new_object("linebuffer");
           buffer_SBER=get_history(seccode,time_frame,len_history);
В результате получаем историю по акциям сбербанка  100 свечей с интервалом 1 минута .
Если параметры seccode, time_frame, len_history не заданы, то их значения берутся с графика.
3) функция чтения в массив списка seccode торгуемых инструментов.

Спасибо
 
Title: Re: Развитие ATF
Post by: Олег on Марта 17, 2011, 10:12:16 am
Надо бы сначала с имеющимися багами разобраться, а уже потом дальше идти. Здание надо строить на крепком ровном фундаменте.
Title: Re: Развитие ATF
Post by: Heller on Марта 17, 2011, 10:37:04 am
Да, все три задачи планируются, не совсем в таком виде правда, но близко к тому. Однако пока есть другие задачи связанные с дотачиванием того что есть. Но это все будет.
Title: Re: Развитие ATF
Post by: Олег on Марта 17, 2011, 10:41:40 am
Если учесть, что я знаю и пишу практически на всех языках программирования, а мой опыт в создании систем различного назначения примерно равен среднему возрасту посетителей сайта, то я знаю, о чем говорю.

Ну вот и дожили... :) Все светлейшие умы человечества вместо создания космических ракет и т.д и т.п. бросились писать торговых роботов :) Интересно, как будет выглядеть рынок через пару лет с точки зрения работающих "вручную"? Прошу прощения за это философское отступление, но просто не сомневаюсь, что этот вопрос ставит перед собой каждый из нас. "Обычный" человек уже никогда не сможет выиграть/заработать? Или, наоборот, придёт "ребёнок" и нелепыми нелогичными случайными "ходами" обыграет всех роботов? Кстати, Каспаров бросил шахматы именно из-за роботов. Ну и где теперь шахматы? :) Кто будет самостоятельно торговать на стопроцентно роботизированном рынке? Это будет соревнование роботов между собой?
Title: Re: Развитие ATF
Post by: nikolz on Марта 17, 2011, 07:12:31 pm
Олег !
Недавно показали новый комп IBM с 3000 процессорами, который обыграл двух чемпионов в "свою игру"
При этом комп распознавал вопросы с голоса ведущего. теперь его хотят поместить в больницу для диагностики заболеваний.
Прошло всего 50 лет с того момента, как задали вопрос "Может ли компьютер мыслить"  и лишь сейчас появился практический ответ.
 Так что не грустите, таких компов еще долго не будет у простых игроков на биржах.
Вы успеете стать миллионером играя на бирже, или успеете им не стать.
Title: Re: Развитие ATF
Post by: Олег on Марта 17, 2011, 07:40:04 pm
Так что не грустите...

На самом деле, любое программирование - это рытьё могилы самим себе. Таджика-дворника ни один компьютер не заменит, а вот переводчиков, бухгалтеров, программистов... (этот список бесконечен) с каждым годом будет требоваться всё меньше и меньше. Раньше всего надо было достигать своей башкой, а сейчас сидит девочка, которая с умным видом использует одну и ту же программу, которую написал умный дядя и чувствует себя самой умной на всём белом свете. А как же?! Ведь у неё на столе голова профессора Доуэля!
Title: Re: Развитие ATF
Post by: nikolz on Марта 17, 2011, 07:45:14 pm
Олег!
Вы правы, видел в иностранном журнале рисунок развития человека.
Слева обезьяна и справа обезьяна. В середине космонавт.
Это движение общества от первобытного к постиндустриальному.
Но как сказал классик:
"Но только жить в эту пору прекрасную уж не придется ни мне ни тебе"
Title: Re: Развитие ATF
Post by: Олег on Марта 17, 2011, 08:14:12 pm
Но как сказал классик:
"Но только жить в эту пору прекрасную уж не придется ни мне ни тебе"

/c грустью/ Вот только это и радует :(
Title: Re: Развитие ATF
Post by: nxz on Марта 20, 2011, 03:07:03 pm
Уважаемые разработчики!
Не понятно, почему не реализована команда отмены заявки по ее id.
В результате практически невозможно построить стратегию с условными заявками,
так как любое изменение заявки требует снятия всех заявок данного направления (buy или sell).
Практически получаем лишь примитивные торговые стратегии с одной условной заявкой в каждом направлении.
Прошу прояснить данную ситуацию.
Спасибо
http://www.transaq.ru/forum/index.php?topic=177.msg1246#msg1246 (http://www.transaq.ru/forum/index.php?topic=177.msg1246#msg1246)
Title: Re: Развитие ATF
Post by: pronych on Марта 20, 2011, 03:56:37 pm
Так что не грустите...

На самом деле, любое программирование - это рытьё могилы самим себе. Таджика-дворника ни один компьютер не заменит, а вот переводчиков, бухгалтеров, программистов... (этот список бесконечен) с каждым годом будет требоваться всё меньше и меньше.
Значит мы на своем месте.)) Программисты, одни и останутся)))
Title: Re: Развитие ATF
Post by: nikolz on Марта 20, 2011, 04:01:59 pm
pronych !
Останутся юристы и финансисты
Title: Re: Развитие ATF
Post by: Олег on Марта 20, 2011, 04:54:12 pm
Останутся... финансисты
Ну это-то уж точно мы!  ;D   А все остальные вымрут как мамонты! ;D
Title: Re: Развитие ATF
Post by: Heller on Марта 21, 2011, 02:55:35 pm
Уважаемые разработчики!
1) Не понятно, почему не реализована команда отмены заявки по ее id.
В результате практически невозможно построить стратегию с условными заявками,
так как любое изменение заявки требует снятия всех заявок данного направления (buy или sell).
Практически получаем лишь примитивные торговые стратегии с одной условной заявкой в каждом направлении.
Как говорится пришли на рыбалку, а вместо удочек прихватили динамит.
Прошу прояснить данную ситуацию.

2) Столкнулся с проблемой. При запуске графика с роботом на истории после торгов получил ошибки при обращении к стакану и нулевые значения индикаторов. пришлось добавлять обработку функции isHistoryCalculated().
     Так как эти операции не связаны с алгоритмами торговли, а вызваны особенностями торговых функций, то
 предлагаю функции isHistoryCalculated() и  isTradingAllowed(),  которые обеспечивают изменение работы calc() на истории и в реале встроить в механизм исполнения торговых функций такие как
trade_action::buy , trade_action::sell и т д следующим образом:
   Если обрабатывается история, либо запрещена торговля в реале, то
при существовании специального лог-файла или макроса, указывающего на лог-файл, например, с именем tradeHistory, параметры торговых операций пишутся в этот файл, либо выводятся на экран.
Если лог файл не указан, то функции реализуют пустой  оператор.
  В этом случае практически не надо будет специально программировать обработку функций isHistoryCalculated() и  isTradingAllowed().
Спасибо.

Ну не именно в таком виде, но будем работать в том числе и в этом направлении.
Title: Re: Развитие ATF
Post by: pronych on Марта 22, 2011, 09:10:08 pm
Останутся... финансисты
Ну это-то уж точно мы!  ;D   А все остальные вымрут как мамонты! ;D
А программисты? Кто будет писать программу для роботов-дворников? ;D
Title: Re: Развитие ATF
Post by: Олег on Марта 24, 2011, 01:38:19 pm
Кто будет писать программу для роботов-дворников? ;D

Роботы-бригадиры :)
Title: Re: Развитие ATF
Post by: nikolz on Марта 31, 2011, 09:20:20 am
Уважаемые Разработчики!
Реализуйте макрос #Include, позволяющий тестовый файл с функциями на ATF вставлять в тело основной программы.
Не учите начинающих программистов дурным манерам написания всего и сразу в одном файле.
Прививайте методы системного, то бишь структурного,  программирования.
Спасибо
Title: Re: Развитие ATF
Post by: nikolz on Апреля 04, 2011, 03:16:59 pm
Уважаемые разработчики!
  Предлагаю ввести объект типа  "linecolor[0] ",
 где в [ ] указывается номер линии,
 в данном объекта записываем код цвета линии
(как вариант - толщина линии, тип линии, код графического символа и т д)
для каждого отсчета,
что позволит раскрашивать линии индикаторов, управлять толжиной и типом линии.
Например , рост индикатора - в зеленый, а снижение индикатора  - в красный.
В момент buy- вывести код стрелки вверх, в sell - вывести код стрелки вниз.
Спасибо
Title: Re: Развитие ATF
Post by: Heller on Апреля 04, 2011, 04:14:12 pm
В принципе ничего против не имеем, но если только в относительно отдаленной перспективе - довольно много сейчас более срочны задач, связанных с ATF.
Title: Re: Развитие ATF
Post by: nikolz on Апреля 04, 2011, 05:03:16 pm
Heller!
     Один из принципов структурного программирования гласит примерно следующее:
   Любой алгоритм должен занимать не более листа формата А4 (Одного экрана монитора)
    ATF не позволяет реализовать этот принцип.
Недавно на форуме ваших конкурентов прочитал, высказывание горе-разработчика, что он пишет по 1000 операторов и потом начинает
отлаживать.
     Просьба:
Cделайте возможность разделять программу и  функции
    в различные файлы, если не возможно делать библиотеки.
   Прививайте хорошие манеры начинающим программистам.
Спасибо
 

Title: Re: Развитие ATF
Post by: Олег on Апреля 05, 2011, 05:07:03 pm
Heller!
     Один из принципов структурного программирования гласит примерно следующее:
   Любой алгоритм должен занимать не более листа формата А4 (Одного экрана монитора)
    ATF не позволяет реализовать этот принцип.
Недавно на форуме ваших конкурентов прочитал, высказывание горе-разработчика, что он пишет по 1000 операторов и потом начинает
отлаживать.
     Просьба:
Cделайте возможность разделять программу и  функции
    в различные файлы, если не возможно делать библиотеки.
   Прививайте хорошие манеры начинающим программистам.
Спасибо

Давайте попробуем разобраться...
Для кого разрабатывается язык ATF? Исключительно для профессиональных программистов или же для "широких народных масс"?
Если только для профессионалов, тогда я согласен, - действительно, нужны такие средства (вроде макроса #Include), которые позволяют использовать многократно УНИВЕРСАЛЬНЫЕ и ХОРОШО ОТЛАЖЕННЫЕ подпрограммы в разных скриптах.
Но, по-моему, среди нас подавляющее большинство - непрофессионалы, которым это не нужно.
Title: Re: Развитие ATF
Post by: nikolz on Апреля 05, 2011, 05:39:21 pm
Олег!
Вы не правы и вот почему.
1) Вы собираетесь играть в написание программ
      или хотите написать программу, которая приносит прибыль?

2) Не надо гордится собственным невежеством.
  Если Вы не учились разрабатывать программы, то не стоит этим гордится.
Возможность разделить программу на отдельные модули - это основы
технологии создания правильно работающих программ.

3) Чем выразительней язык, тем проще на нем выражать свои мысли  (алгоритмы) тем более не профессионалу.
  Профессионал может это сделать на любом языке.
Поэтому мои предложения в первую очередь направлены на развитие языка для облегчения работы на нем всем желающим.
Ну вот примерно так.
Title: Re: Развитие ATF
Post by: Олег on Апреля 05, 2011, 07:22:28 pm
Heller!
     Один из принципов структурного программирования гласит примерно следующее:
   Любой алгоритм должен занимать не более листа формата А4 (Одного экрана монитора)
    ATF не позволяет реализовать этот принцип.
Недавно на форуме ваших конкурентов прочитал, высказывание горе-разработчика, что он пишет по 1000 операторов и потом начинает
отлаживать.
     Просьба:
Cделайте возможность разделять программу и  функции
    в различные файлы, если не возможно делать библиотеки.
   Прививайте хорошие манеры начинающим программистам.
Спасибо
 

Вы когда-нибудь слыхали поговорку "Москва не сразу строилась"?
Ну вот примерно так :)
Title: Re: Развитие ATF
Post by: Heller on Апреля 06, 2011, 11:32:56 am
nikolz, я с вами согласен, это действительно важно. У нас есть клиенты, которые пишут библиотеки на несколько тысяч строк кода, и потом копируют их в каждый скрипт. Это не удобно, и это надо решать. К тому же был бы #include, они могли бы делиться своими библиотеками со всеми. Поэтому это довольно приоритетное направление развития. Не в первую очередь, но будет сделано обязательно.
Title: Re: Развитие ATF
Post by: Олег on Апреля 06, 2011, 01:25:04 pm
nikolz, я с вами согласен, это действительно важно. У нас есть клиенты, которые пишут библиотеки на несколько тысяч строк кода, и потом копируют их в каждый скрипт. Это не удобно, и это надо решать. К тому же был бы #include, они могли бы делиться своими библиотеками со всеми. Поэтому это довольно приоритетное направление развития. Не в первую очередь, но будет сделано обязательно.

Да кто бы спорил с тем, что это нужно и важно. Разумеется, это нужно и важно. Вопрос в том, что коллеге, судя по тональности и настойчивости его последних постов, хочется, чтобы всё это появилось немедленно здесь и сейчас. Но, увы,  развитие любого серьёзного дела требует определённого времени.
Так что, потерпите, nikolz, потерпите... всё у Вас будет... и дудочка и кувшинчик :) Всему своё время.
http://www.transaq.ru/forum/index.php?topic=406.msg2106#msg2106
http://www.transaq.ru/forum/index.php?topic=406.msg2150#msg2150
Title: Re: Развитие ATF
Post by: nikolz on Апреля 06, 2011, 03:01:01 pm
Олег,спасибо за Ваше беспокойство!
Title: Re: Развитие ATF
Post by: Олег on Апреля 06, 2011, 03:10:06 pm
Олег,спасибо за Ваше беспокойство!

И Вам не хворать! :)
Title: Re: Развитие ATF
Post by: Олег on Апреля 17, 2011, 04:57:46 pm
Хотелось бы иметь в ATF нечто наподобие бейсиковского SELECT CASE. Планируется?

И ещё... Мне сейчас для выполнения одной задачки понадобились двумерные динамические массивы. Насколько я понимаю, на данном этапе развития ATF их использование недоступно. Ну вот ещё одно пожелание для развития ATF :) 
А пока придётся мне, видимо,  использовать два одномерных динамических массива, сопряжённых вместе.
Title: Re: Развитие ATF
Post by: nikolz on Апреля 18, 2011, 06:19:47 am
Олег!
Хочу заметить, что для торговли в реале многомерные массивы не требуются. Максимум двухмерные - это таблицы.
Двухмерный Массив X[N,L] заменят  L массивов Y[N] или N Y[L].
 Два одномерных массива могут заменить
лишь пародию на многомерность  X[N,2].
Если таблицы динамические, то это уже базы данных.
Так можно домечтаться до реляционных баз данных, нейронных сетей, преобразовании Каруне-Лоева и т д.
Такие  опасные мысли могут привести к народным волнениям
Мечтать не вредно,но опасно.
Title: Re: Развитие ATF
Post by: Олег on Апреля 18, 2011, 09:22:31 am
Олег!
Хочу заметить, что для торговли в реале многомерные массивы не требуются. Максимум двухмерные - это таблицы.
Двухмерный Массив X[N,L] заменят  L массивов Y[N] или N Y[L].
 Два одномерных массива могут заменить
лишь пародию на многомерность  X[N,2].
Если таблицы динамические, то это уже базы данных.
Так можно домечтаться до реляционных баз данных, нейронных сетей, преобразовании Каруне-Лоева и т д.
Такие  опасные мысли могут привести к народным волнениям
Мечтать не вредно,но опасно.

Уважаемый коллега!
Должен признаться, Ваше мнение по данному вопросу меня интересует в очень малой степени. Вопрос был задан разработчикам. Ну сами посудите, не у Вас же я спрашиваю, планируется что-нибудь в развитии Транзака или нет? Ну Вам-то откуда это знать?
Поэтому, чтобы не было недоразумений, я позволю себе повторить свой вопрос с уточнением, что я задаю его именно РАЗРАБОТЧИКАМ Транзака, а вовсе не каждому желающему пофлудить:

Хотелось бы иметь в ATF нечто наподобие бейсиковского SELECT CASE. Планируется?

И ещё... Мне сейчас для выполнения одной задачки понадобились двумерные динамические массивы. Насколько я понимаю, на данном этапе развития ATF их использование недоступно. Ну вот ещё одно пожелание для развития ATF :) 
А пока придётся мне, видимо,  использовать два одномерных динамических массива, сопряжённых вместе.
Title: Re: Развитие ATF
Post by: Heller on Апреля 18, 2011, 01:56:19 pm
Олег, select-case планируется (правда в виде сишного switch-case).

Насчет многомерных массивов пока не думали, но скорее всего сделаем. Вещь нужная.
Title: Re: Развитие ATF
Post by: Олег on Апреля 22, 2011, 03:36:17 pm
Олег, select-case планируется (правда в виде сишного switch-case).

Это очень хорошо. А то, честно говоря, достали уже эти бесконечные "матрёшки" из вложенных друг в друга IF... ELSE IF. Код получается трудночитаемым, даже несмотря на соответствующие отступы.
Title: Re: Развитие ATF
Post by: nikolz on Апреля 29, 2011, 07:19:57 am
Добрый день,Heller!
  Почему бы не реализовать функцию чтения из произвольной таблицы торгового терминала строки по ключам в столбцах, например так:

Row=GET_TABLE(Имя_таблицы, ИмяСтолбца, "ключ1,ключ2,,,,,ключN");

Первый параметр - имя таблицы, например money_position
Row=GET_TABLE("money_position","saldoin", "CLIENTCODE=12454");
Т.е. получить из таблицы лимитов по деньгам значение входящего остатка по ключу - код клиента =12454
Ключи можно задавать через хеш, аналогично заявкам
 Таким образом, данная функция обеспечила бы доступ к любым табличным данным (балансу , лимитам, сделкам,заявкам и т д ) и таким образом возможность доступа ко всей торговой информации без исключения.

Планируется ли и если да, то когда будет реализована данная возможность.
Спасибо.
Title: Re: Развитие ATF
Post by: nikolz on Июня 19, 2011, 06:57:28 pm
Добрый день, Heller!
1)Так как большинство торговых систем строятся на обнаружении пересечения двух линий графиков,
предлагаю включить в ATF
функцию пересечения двух линий (векторов) :  cross(x,y);
при пересечении "x" линией "y" снизу вверх - результат плюс 1,
 сверху вниз - результат минус 1, иначе ноль.

2) Почему бы не предоставить пользователям API
для подключения внешних функций в виде dll,
 для разработки индикаторов и генераторов сигналов(я так называю советников).  
А автоматизацию торговли можно было бы на ATF реализовывать.
Можно было бы быстро создать большую библиотеку индикаторов
и генераторов торговых сигналов.
А вот работу с торговыми позициями заявками сделками реализовывать средствами ATF.  
Получился бы очень хороший вариант софта для разработки роботов.
Пока конкурентов такой реализации нет, а преимуществ - воз и малая тележка.
Title: Re: Развитие ATF
Post by: Heller on Июня 20, 2011, 10:03:55 am
Вначале отвечу на вопрос от 29 апреля про GET_TABLE, в свое время я его просто не заметил и прочитал только сейчас. Описанного функционала разрабатывать мы не планируем, потому что тут есть множество тонких моментов: таблиц с одним именем может быть несколько, они могут быть разнесены по разным экранам, на них могут быть установлены различные фильтры, сортировки и т. д.  Причем все эти настройки могут меняться по действиям пользователей в реалтайме - сделать надежную связку с ATF будет просто довольно сложно. Если в ATF не хватает каких-то данных, то проще добавить их отдельными функциями ATF.

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

Идея dll она в общем-то хорошая, но я просто пока слабо себе представляю как оно должно выглядеть в конечном варианте, и затраты на реализацию этого кажутся довольно большими. В голове мы это держим, но пока конкретных планов на реализацию у нас нет. В принципе вы можете сформулировать более конкретно свои идеи (видимо лучше на почту), мы оценим насколько это трудозатратно, и вероятно будем двигаться в этом направлении. Но пока ничего конкретного мы не планируем.
Title: Re: Развитие ATF
Post by: nikolz on Июня 20, 2011, 10:22:08 am
Heller!
Хороший пример
  The EasyLanguage DLL Extension Kit provides an interface between Omega Research EasyLanguage and 32-bit Microsoft Windows dynamic-link libraries (DLLs). It consists of an extension to Omega Research EasyLanguage - a dynamic-link library programming tool kit (ELKIT32.DLL). With the help of the EasyLanguage DLL Extension Kit, an EasyLanguage user is now able to call any Exported Function within any DLL, including those functions that come with Microsoft Windows. 
Если надо - пришлю документацию
Title: Re: Развитие ATF
Post by: nikolz on Июня 20, 2011, 10:25:20 am
И еще
Предлагаю на Интре вместо непонятно каких цен брать хотя бы исторические данные с запаздыванием например на 1 час или вообще выбирать день с помощью датчика случайных чисел и транслировать цены
А то практически ничего тестировать нельзя
Title: Re: Развитие ATF
Post by: nxz on Июня 20, 2011, 10:38:01 am
Поностью поддерживаю, надо что-то придумать.
Title: Re: Развитие ATF
Post by: Heller on Июня 20, 2011, 11:28:31 am
nikolz, да, документация была бы полезна. Отправьте на support@transaq.ru - посмотрим.

Насчет усовершенствования Интры донесу мысль разработчикам, которые этим занимаются, но насколько я знаю в планах таких усовершенствований нет.
Title: Re: Развитие ATF
Post by: nikolz on Июня 20, 2011, 12:08:52 pm
отправил
Title: Re: Развитие ATF
Post by: suslik on Июня 21, 2011, 01:04:35 pm
Олег!

По-настоящему большие деньги никогда не доверят роботам. Роботы будут дрочить на фьючерсах, следить за маржин-коллами и стоп-лоссами, но никогда не будут двигать рынки. Рынки всегда будет двигать "личность" с большими деньгами. Даже роботы, которые дрочат вслед за всевозможными западными индикаторами (фьючерсам на S&P, на нефть, на евро) никогда не смогут сравняться по доходности с крупными игроками, которые могут "переставить" Газпром или Роснефть на 15-20% выше или ниже, не взирая ни на какие S&P и иже с ними.
Title: Re: Развитие ATF
Post by: nikolz on Июня 21, 2011, 02:17:14 pm
suslik!
 Чтобы Вы не утонули в собственных рассуждениях, привожу Вам факты из СМИ подробности найдете в инете:
  Загадочный обвал, случившийся на фондовых рынках Америки 6 мая 2010 года.
В историю этот обвал вошел двумя обстоятельствами.
Во-первых, падение индекса Доу-Джонса (990 пунктов) стало самым головокружительным за все годы существования биржи.
Во-вторых, продолжалось падение всего… 5 минут (с 14:42 по 14:47), после чего рынок как ошпаренный отыграл за 90 секунд обратно 543 индексных пункта.
  Виновника знали в лицо, по меньшей мере, на протяжении последнего года, однако все это время и политики, и официозная ангажированная пресса упрямо делали вид, что не видят «героя» в упор.
  Формальная привязка Высокочастотного Трейдинга (HFT, High Frequency Trading) к обвалу состоялась уже к середине мая.
     Главными игроками высокочастотного трейдинга в стране являются Goldman Sachs, Morgan Stanley и еще десяток крупнейших банков. И именно эти банки обеспечивают те самые 40–70% ежедневного биржевого оборота.

     Сенатор Чарльз Шумер обратился в SEC c требованием запретить систему flash orders еще летом прошлого года. В сентябре 2009-го SEC предложила прописать запрет в документах финансовой реформы, продвигаемых администрацией Обамы. Политики дружно закивали, однако ничего никуда не добавили. Только после кризиса 6 мая тема flash orders снова замелькала на страницах прессы. Правда, как-то вяло и неубедительно (вспомним статью Джулии Кресуэлл).
    Возвращаясь к событиям 6 мая, можно предположить, что весь спектакль, разыгранный между 14 и 15 часами, состоял именно из алгоритмов, давно уже апробированных HFT трейдерами (правда, в меньших масштабах).
      Сначала продажа колоссального числа акций «в короткую», затем отключение компьютеров для создания вакуума ликвидности, молниеносное возвращение на рынок и закрытие коротких позиций на самом пике падения с одновременным открытием длинных позиций для последующей их ликвидации на чисто техническом отыгрыше вверх.
      С учетом феноменальной амплитуды искусственно вызванного двойного колебания рынка (сначала вниз, затем вверх) можно предположить, что 6 мая удалось заработать десятки миллиардов долларов. Может, сотни. За несколько минут. На одной лишь ловкости рук, суперкомпьютерах и... теплых чувствах, питаемых финансовой системой Америки к собственной элите.
Title: Re: Развитие ATF
Post by: nikolz on Июня 21, 2011, 02:24:21 pm
Уважаемые разработчики!
Почему нельзя в качестве отладочного сервера для ATF использовать учебный сервер финама как это сделано на comon.ru.
Title: Re: Развитие ATF
Post by: Heller on Июня 22, 2011, 09:46:52 am
Уважаемые разработчики!
Почему нельзя в качестве отладочного сервера для ATF использовать учебный сервер финама как это сделано на comon.ru.

Не уверен, что правильно понимаю, что вы имеете ввиду, но в любом случае это по-видимому вопрос к Финаму, а не к нам.
Title: Re: Развитие ATF
Post by: nikolz on Июня 22, 2011, 10:41:32 am
Heller !
А разве Вы это не они?
Title: Re: Развитие ATF
Post by: Heller on Июня 22, 2011, 11:11:10 am
nikolz, нет :)
Title: Re: Развитие ATF
Post by: nikolz on Июня 22, 2011, 11:51:12 am
Тут у меня Ошибочка вышла
Title: Re: Развитие ATF
Post by: nikolz on Июня 29, 2011, 06:21:24 am
Добрый день,Heller!
Предложение следующее.
как я понял, в ATF вы пошил по пути создания своих параметров, не транслируемых с биржи, для работы с лимитами.
В результате получили кучу проблем не работающих функций getMoneyBalance, getBoughtMoney, getSecBalance.
А между тем есть простое решение, позволяющее решить все эти проблемы.
Ранее я предлагал реализовать следующее, повторю опять.
  Предлагаю реализовать в ATF функцию запроса  данных из таблиц лимитов либо получение хэша с содержимом таблицы лимитов для заданного инструмента  и клиента.
  Предполагаю, что реализация данной функции мало чем отличается от реализации функции получения данных из таблиц сделок, заявок, стоп-заявок при заданном инструменте и номере заявки(сделки) или номере строки в таблице.
А вычислять сколько денег потрачено на сделки сегодня можно и путем суммирования в ATF параметров этих таблиц.
       Еще добавил бы фильтр для выборки из таблиц по ключам.

   Если смотреть на ATF как язык для работы на бирже, то он должен реализовывать функции для работы с векторами и таблицами (фиксированной и переменной длины) и операций выборки из таблиц по ключам и операций с векторами.  

Тогда нет разницы что фортс что не фортс,
все работает одинаково.
  
Я так сделал при подключении языка Амиброкера к КВИКУ.
Title: Re: Развитие ATF
Post by: Heller on Июня 29, 2011, 02:32:06 pm
nikolz, лично мне идея таблиц нравится, но по историческим причинам у нас есть технические трудности с реализацией единого интерфейса. Разработка терминала ведет свои история от 98-го года, и поэтому разные таблицы по-разному реализованы (например, таблица всех сделок не является стандартным листконтролом из WinApi, так как на момент реализации стандартный контрол тормозил для большого количества трейдов; по тем же причинам есть таблицы с подпиской на онлайновые данные, а есть диалоги отображения результатов запросов с кнопкой "Обновить"), так что для создания единого интерфейса придется вероятно делать значительные переработки.

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

Ну а невозможность (временная) получить позиции по ФОРТСу связаны не с тем, что мы реализуем как-то по отдельному каждую функцию, а с какими-то более глубокими архитектурными вопросами, которые честно говоря выходят за рамки моей компетенции. Но это будет перерабатываться. Я надеюсь, что завтра мы сделаем уже наконец какое-то решение по позициям ФОРТС.
Title: Re: Развитие ATF
Post by: Олег on Июня 29, 2011, 05:19:30 pm
Я надеюсь, что завтра мы сделаем уже наконец какое-то решение по позициям ФОРТС.

Удачи Вам!
Title: Re: Развитие ATF
Post by: nikolz on Июля 07, 2011, 08:04:02 am
Добрый день,Heller!

Хочу услышать Ваше мнение по следующему вопросу:

  Предлагаю реализовать возможность подключения внешних библиотек пользователя следующим образом:
1) Библиотеки создаются по соглашениям C или C++, передаваемые параметры тип double или указатель
2) В ATF реализуется оператор "Myfunc" :
  Myfunc(path, Namefun,var,var,,,,&var);
 path - "путь к библиотеке"
Namefun-"имя функции"
 или &Namefun - если функция возвращает значение
var  - указывается если параметр передается по значению
&var - указывается, если параметр передается по ссылке (хеш,массив,линия,буфер);

  В программе ATF,
 обращение к функции определяется обычным образом:

Например:

Myfunc("C:MyLib.dll","&robot,var,var); //описание функции
var x1=10; var x2=5;  //передаваемые в функцию значения переменных
var y=robot(x1,x2);   //обращение к функции

  Так как механизм подключения DLL на уровне Cи(С++)
достаточно прост,  
предполагаю,
что реализация функции "Myfunc" в ATF
у Вас не займет много времени ,
а открывающихся возможностей
с появлением ее в ATF бесконечное множество.

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


Title: Re: Развитие ATF
Post by: Heller on Июля 07, 2011, 11:05:47 am
Реализовать в том виде, как вы указали, действительно не сложно и можно вообще очень быстро, но просто я не очень вижу как вы будете эффективно взаимодействовать с ATF при таком подходе. Ведь насколько я могу судить, максимум, что вы можете с помощью этого делать - перекидываться с ATF дабловыми значениями (если только вы не хотите сохранять нужные вам данные и вести историю на вашей стороне).

Ну и со ссылками тоже не очень понятно. Данные в ATF имеют свой внутренний тип, и если давать ссылки на double или int можно, то не понятно как быть со строками, линиями индикатора и более сложными объектами типа массивов.

Хотя вероятно я пока просто не очень понимаю суть идеи как это будет использоваться.
Title: Re: Развитие ATF
Post by: nikolz on Июля 07, 2011, 01:24:43 pm
Пример:
1) Передаем в функцию указатель на массив close,
 его длину и номер последнего значения.
2) Возвращаем из функции текущее значение индикатора

Получаем возможность быстро рассчитывать сложные индикаторы и генераторы сигналов
Title: Re: Развитие ATF
Post by: Heller on Июля 07, 2011, 02:55:19 pm
Ну в принципе возможно конечно. Меня единственное что смущает рискованность этого. Массива close например у нас нет - есть массив структур Candle, причем это массив std::vector, а не просто. Переменные ATF - это union. Линии индикатора - это вообще достаточно сложный объект (класс, представляющий собой массив авторесайзируемых массивов). Можно конечно сделать классы-интерфейсы и отдавать указатели на них.

Хотя в принципе принципиально против я ничего не имею. Мне лишь не нравится, что это получается довольно низкий уровень, и программирование становится весьма рискованным. Но вообще такой минимальный функционал я не против сделать.
Title: Re: Развитие ATF
Post by: nikolz on Июля 07, 2011, 05:19:31 pm
Heller!
Как Вам такой вариант( основа - AutoIt)
Вызов функции DLL библиотеки.
DllCall ( "dll", "return type", "function" [, "type1", param1 [, "type n", param n]] )
Параметры
dll   Название DLL, например, "user32.dll".
return type   Тип возвращаемого значения функции. См. ниже.
function   Название функции DLL, например, "MessageBox", или ее порядковый номер, например 62, в вызываемой библиотеке
type   [опциональный] Тип папаметра. См. Замечания.
param   [опциональный] Значение параметра. См. Замечания.
Замечания
Если в качестве параметра dll указано название файла, то библиотека автоматически будет загружена и закрыта DLL сразу после вызова функции.
Если требуется вручную управлять загрузкой и выгрузкой файла DLL библиотеки, то следует использовать функции DllOpen и DllClose,
а в качестве параметра dll указать идентификатор библиотеки вместо названия файла.
По умолчанию используется так называемый 'stdcall' способ вызова функции.
Чтобы применить 'cdecl' вызов требуется поместить выражение ':cdecl' вслед за типом возвращаемого значения. Например,
DllCall("SQLite.dll", "int:cdecl", "sqlite3_open", "str", $sDatabase_Filename , "long_ptr", 0).
При вызове можно указать любое количество типов (types) и параметров (param). См. ниже пример использования нескольких параметров.
Используются следующий типы:
•   none - не имеет значения. Используется только для типа возвращаемого значения. Совпадает с void языка C.
•   byte - 8-ми битовое целое
•   ubyte - 8-ми битовое целое без знака
•   short - 16-ти битовое целое
•   ushort - 16-ти битовое целое без знака
•   dword - 32-х битовое целое
•   udword - 32-х битовое целое без знака
•   int - 32-ти битовое целое
•   uint - 32-ти битовое целое без знака
•   long - 32-ти битовое целое
•   short_ptr - указатель на 16-ти битовое целое
•   int_ptr - указатель на 32-ти битовое целое
•   long_ptr - указатель на 32-ти битовое целое
•   str - строка
•   wstr - строка широких символов (преобразуется в/из ANSI строки при вызове)
•   hwnd - внутренний идентификатор окна
•   ptr - абстрактный указатель (void *)
•   float - действительное с плавающей запятой одинарной точности
При удачном выполнении возвращается массив, который содержит возвращаемое функцией значение вместе с копией всех параметров, включая те, которые были изменены вызовом функции.
•   $return[0] = function return value
•   $return[1] = param1
•   $return[2] = param2
•   ...
•   $return[n] = paramn

Примечание: можно вернуть лишь значение а не массив

Пример 1 - прямой вызов MessageBox из API
$result = DllCall("user32.dll", "int", "MessageBox", "hwnd", 0, "str", "Some text", "str", "Some title", "int", 0)

   В ATF при трансляции  функции DllCall  , передаваемые в вызываемую функцию параметры преобразуются к указанному в вызове виду .
Title: Re: Развитие ATF
Post by: Heller on Июля 08, 2011, 11:38:00 am
Момент, который меня смущает - это невозможность узнать на этапе компиляции самого Транзака определение функций, которые собирается вызывать пользователь. На сколько я могу судить, чтобы реализовать это, мне придется возиться вручную через ассемблер со стеком, причем любое решение может оказаться сильно платформозависимым. В принципе попробовать можно, но не уверен, что я что-то положительное сделаю прямо в ближайшей перспективе, просто потому что я больше математик, чем программист.
Title: Re: Развитие ATF
Post by: nikolz on Июля 08, 2011, 11:46:35 am
Добрый день,Heller!
На этапе трансляции
Вам известна вся информация о вызываемых функциях
она содежится в параметрах вызова  

Вызов функции из DLL библиотеки.
в вызве DllCall ( "dll", "return type", "function" [, "type1", param1 [, "type n", param n]] )
Вам известно имя функции,
 число параметров,
требуемый тип каждого из передаваемых параметров

Вы знаете, какой тип передаваемого в функцию у Вас внутри ATF
и по вызову знаете какой тип нужен функции

Таким образом на этапе трансляции вся информация известна.
Title: Re: Развитие ATF
Post by: nikolz on Июля 08, 2011, 11:53:29 am
Осталось лишь реализовать и мощь ATF будет безгранична
Title: Re: Развитие ATF
Post by: Heller on Июля 08, 2011, 11:58:39 am
На этапе трансляции - да. А на этапе компиляции?

Грубо говоря вот у меня есть имя библиотеки и имя функции. Я в своем коде на C++ делаю следующее:

HANDLE hm = LoadLibrary(dllname);

Дальше я делаю вызов

void *f = GetProcAddress(hm, funcname);

А что делать мне с этим f? Чтобы этот вызов осуществить с верными параметрами, мне необходимо руками забивать стек, а затем через _asm {call ...} уже вызывать функцию, потому что на этапе компиляции проекта transaq (а не скрипта ATF) определения для функции у меня нет, и я не могу сделать что-то вроде

typedef __declspec(dllimport) int (__stdcall *dllFunction)(BYTE* data);
dllFunction myFunc = (dllFunction)f;
myFunc(/*параметры, которые мне неизвестны на этапе компиляции моего кода*/);
Title: Re: Развитие ATF
Post by: nikolz on Июля 08, 2011, 02:15:35 pm
Heller!
Что скажите о таком варианте(кратко):
INTRODUCTION
TRANSAQ plug-in DLLs are regular Win32 dynamic link libraries.
•   ATF plugins
•   Optimizer plugins
The ATF plugins can expose unlimited number of functions to the ATF engine. The functions provided by the plugin are integrated tightly with ATF engine so there is no difference in performance or functionality between built-in functions and the ones provided by the plug-in.
   The plug-ins can be created in any language that meets the following requirements:
•   ability to build regular API-like 32bit or 64 bit Windows DLL (non ActiveX/COM)
•   support for user defined datatypes, structures and unions
•   support for pointer data type, pointers to functions, calling functions by pointer
•   support for _cdecl calling convention
Visual C++ 6.0 was used to create all source code examples in the TRANSAQ Development Kit. However you can use other development platform and/or language. To demonstrate this ATF plugin examples include also project (.dev) files for Bloodshed DevC++ package (http://www.bloodshed.net). DevC++ is a FREE development package that can be used to build plugins for TRANSAQ. It produces slightly larger binaries than VisualC++ but other than that it is fully compatible. To compile ATF samples just install DevC++ package and then double click on supplied .dev file, then choose Execute->Compile from DevC++ IDE.
Note to Delphi users: Delphi does not support returning 8 byte structures by register so this is an obstacle in developing plugins in Delphi.
INTERFACE ARCHITECTURE
Plugin interface is designed to be as simple as possible. ATF plugins need to export just 5 functions to be fully functional. The simplest data plugin needs only 4 functions. The full definition of interface is included in Plugin.h header file and below you will find all necessary information to get going with the development.
1.2.1 Background
To provide maximum flexibility TRANSAQs plug-in interface must provide the methods for two-way communications between TRANSAQ and plugin. TRANSAQ as the process that loaded the DLL can call the functions exported by the DLL but also the DLL has to have a way to call back TRANSAQ functions. For this purpose TRANSAQ provides a "site interface" which is a structure containing function pointers that can be used to call back internal TRANSAQ code. Data plugins have also ability to send messages to TRANSAQ main window notifying about the updates.
Each plugin DLL must export at least one function called GetPluginInfo(). DLLs without this function are ignored by TRANSAQ. GetPlugin info function provides basic information about the plugin needed by TRANSAQ to access all remaining functions.
When TRANSAQ starts (or when a "Load" button is pressed in the Plugins window) the following things happen:
•   "Plugins" folder is scanned for the files with .DLL extension
•   each DLL file is examined if it exports GetPluginInfo() function. If there is no such function, this DLL is not a valid TRANSAQ plugin. If GetPluginInfo() function is found, it is called to examine the name and properties of the plug-in. After successful check the DLL is added to the TRANSAQ's internal plugin table. At this stage the type of the plugin is determined. From then on ATF plugins are treated differently than data plugins (different functions are called)
After this step DLL is loaded but waits for the second initialization phase.
For ATF plugins this second initialization phase happens when ATF engine starts for a very first time initializing its function table. Then TRANSAQ performs the following operations:
•   TRANSAQ calls SetSiteInterface() function exported by the plug in. The site interface is used later in DLL for calling back various TRANSAQ functions (including allocating/freeing memory, reading/writing ATF variables, calling back ATF functions)
•   TRANSAQ calls Init() function from the plug in DLL that should be used for initializing working variables/allocating extra memory if necessary
•   TRANSAQ calls GetFunctionTable() from the plug in DLL. In this step the ATF functions provided by the DLL are added to the internal TRANSAQ dispatch tables allowing futher calls of these functions.
For Data plugins the second initialization phase happens when given data source is selected for the very first time in current TRANSAQ session. Then TRANSAQ just calls Init() function from the plugin that should be used for initializing working variables/allocating extra memory if necessary. No other function is called for data plugins at this time.
After such initialization process the plugin is ready to be used. Next actions depend on type of the plugin.
For ATF plugins if any external function call is included in the formula being parsed by ATF engine, TRANSAQ finds appropriate pointer to the function in its dispatch table and calls either internal code or the code found in one of the plug-in DLLs.
For Data plugins TRANSAQ may call different functions descibed in Data plugin section of this document.
The final stage is performed when TRANSAQ exits:
•   for each plug-in DLL Release() function is called which should release all the resources allocated via Init() call in the second phase.
Title: Re: Развитие ATF
Post by: nikolz on Июля 08, 2011, 08:45:03 pm
Heller!
Еще два момента
1) Почему бы не использовать технологию COM ?
2) Как вариант,  могу предложить свои услуги
по разработке модуля для подключения dll
или реализацию технологии COM в ATF


Title: Re: Развитие ATF
Post by: Heller on Июля 11, 2011, 10:03:42 am
1) Почему бы не использовать технологию COM ?
Потому что технологию COM способны использовать единицы людей. Даже в среде профессиональных разработчиков единицы этой технологией владеют. Да и она вытесняется сейчас технологиями, завязанными на .Net, если говорить о решениях Microsoft, либо более универсальными решениями Boost. Если бы реализация интерфейса COM для ATF занимала один день, этим можно было бы заняться, но поскольку это требует время, а единственный человек, кто заинтересован в COM-интерфейсе - это вы, то смысла реализовывать такую махину в ATF я не вижу никакого смысла.

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

Вариант с простой DLL рассмотрим, но не обещаем, что реализуем в ближайшее время.
Title: Re: Развитие ATF
Post by: Олег on Июля 24, 2011, 05:31:56 pm
Ну а невозможность (временная) получить позиции по ФОРТСу связаны не с тем, что мы реализуем как-то по отдельному каждую функцию, а с какими-то более глубокими архитектурными вопросами, которые честно говоря выходят за рамки моей компетенции. Но это будет перерабатываться. Я надеюсь, что завтра мы сделаем уже наконец какое-то решение по позициям ФОРТС.

Ну и чем дело кончилось, чем сердце успокоилось? :)
Title: Re: Развитие ATF
Post by: Heller on Июля 25, 2011, 11:07:54 am
Ну и чем дело кончилось, чем сердце успокоилось? :)

Мы внесли это в ближайший план разработки, и этот функционал войдет в ближайший апдейт. Видимо в конце августа уже.
Title: Re: Развитие ATF
Post by: Олег on Июля 25, 2011, 01:18:16 pm
Мы внесли это в ближайший план разработки, и этот функционал войдет в ближайший апдейт. Видимо в конце августа уже.

Классно! 
Жалко только, что до "конечного потребителя" это дойдёт не раньше чем через полгода :(
Title: Re: Развитие ATF
Post by: 352362457 on Ноября 16, 2011, 02:28:54 pm
Честно говоря очень сильно был удивлен блоку с макросами и возможностью создавать МТС в транзаке. НО:

почему нельзя сделать дружественный интерфейс в плане создания скриптов наподобии Метастока? не все торгующие владеют объектно-ориентированным програмированием.

хочу создать систему, но даже нет возможности вставлять готовые конструкции (например индикаторы) в систему. приходится ВСЕ описывать как например в паскале (помнится в мгу изучали давненько))).

кстати - сунулся в тех описание, кажется с официального сайта. так там тоже полные вилы(((

и еще один момент: транзаком пользуются люди, которым либо не интересно изучать все возможности QUIKа, который 4 года назад значительно превосходил Транзак, либо устраивает простота работы купил-продал! поэтому огород городить насчет крутейшего программирования вокруг слабой платформы изначально и без справки как то некорректно.
Title: Re: Развитие ATF
Post by: Bigbrother72 on Ноября 24, 2011, 08:24:48 am
В документации на сайте транзака написано:
"Начиная со сборки 291, в Transaq доступно тестирование торговых систем "

Где бы найти эту 291 версию?

Title: Re: Развитие ATF
Post by: Heller on Ноября 24, 2011, 04:47:40 pm
В документации на сайте транзака написано:
"Начиная со сборки 291, в Transaq доступно тестирование торговых систем "

Где бы найти эту 291 версию?



Только ждать обновление брокера.
Title: Re: Развитие ATF
Post by: nxz on Ноября 24, 2011, 05:10:21 pm
А Интра поддерживает тестирование ТС?
Будет ли сборка 291 для ИНтры?