Добро пожаловать, Гость. Пожалуйста, войдите или зарегистрируйтесь.
Вам не пришло письмо с кодом активации?
Октября 05, 2022, 04:49:59 am
Начало Помощь Поиск Войти Регистрация
Новости:

Transaq  |  СБО "Transaq"  |  Подсистема ATF  |  Topic: Пожелания для развития TRANSAQ ATF « предыдущая тема следующая тема »
Страниц: 1 2 [3] 4 5 ... 8 Печать
Автор Тема: Пожелания для развития TRANSAQ ATF  (Прочитано 68330 раз)
Heller
Разработчики
Hero Member
*****
Сообщений: 1277


Просмотр профиля Email
« Ответ #30 : Апреля 14, 2010, 11:53:23 am »

nikolz, спасибо за замечания, возьмем на вооружение, большую часть реализуем.
Записан
dyalexy
Newbie
*
Сообщений: 6


Просмотр профиля WWW Email
« Ответ #31 : Апреля 14, 2010, 01:19:19 pm »

   При написании индикаторов столкнулся с проблемой: http://www.transaq.ru/forum/index.php?topic=10.0

    Для решения которой, желательно бы, расширить и упростить понятные функции типа:getDayCandle(open,close,high,low) [candle namber]. Или Day вообще спрятать в параметр типа: getCandle(day,open,close,high,low) [candle namber]. Соответсвено и другие в качестве временного порядка свечи чтобы можно было указывать и коэффициент 5Day, 22Day или Month. minute,5minute,10minute..., hour,... day,... month,... week,... year,...  Чтобы не сочинять их пользователям ATF :)
Записан

Деньги постоянно перетекают от самых быстрых к самым терпеливым :)
http://www.hitechbusiness.ru/
Heller
Разработчики
Hero Member
*****
Сообщений: 1277


Просмотр профиля Email
« Ответ #32 : Апреля 15, 2010, 11:26:05 am »

Подобные функции по удобной и детальной работе со временем появятся в ближайшей перспективе.
Записан
dyalexy
Newbie
*
Сообщений: 6


Просмотр профиля WWW Email
« Ответ #33 : Апреля 15, 2010, 12:07:32 pm »

Еще есть одно пожелание - это возможность делать свои записи на графике.
Пока там такой возможности не нашел :)
« Последнее редактирование: Апреля 15, 2010, 12:10:33 pm от dyalexy » Записан

Деньги постоянно перетекают от самых быстрых к самым терпеливым :)
http://www.hitechbusiness.ru/
APS
Newbie
*
Сообщений: 49


Просмотр профиля Email
« Ответ #34 : Апреля 16, 2010, 09:56:58 pm »

Добрый день!
Предлагаю следующее:
По языку и компилятору:
1) Сделать объявление VAR факультативным,т.е. не обязательным. Например, если не функция, то переменная.
Вот уж не согласен. Переменная - это переменная. Функция - это функция. Кто мешает описать явно?

3) Сделать допустимым совпадение имен формальных параметров функции с именами внешних переменных.
Тоже не согласен. Польза сомнительна, а отрицательный эффект налицо: имена одинаковые, а переменнные разные. Понятно, что видимость переменных эту проблему решает, но ИМХО юзеров только запутает.

5) определить функцию выделить память и освободить память для массива
Ой. А это-то зачем? malloc() имеется в виду? или аналог New? По-моему, лишнее это... Не юзерская это проблема - памятью выделяемой управлять.
Записан

---
С уважением,
Алексей
Heller
Разработчики
Hero Member
*****
Сообщений: 1277


Просмотр профиля Email
« Ответ #35 : Апреля 19, 2010, 11:05:26 am »

Соглашусь пожалуй с APS. Уход от строгого задания определения функции/переменной - довольно рискованный шаг. Сегодня действительно ничто не мешает сделать неявное определение типа идентификатора, но совершенно не факт, что в дальнейшем такое поведение ATF нам будет легко поддерживать. Да и опять же как-то визуально оно более понятно. Смотришь на код и сразу видно что имеется ввиду.

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

По остальному - будем делать. В планах предоставить максимально широкие возможности по работе с заявками и сделками.
Записан
nikolz
Sr. Member
****
Сообщений: 285


Просмотр профиля Email
« Ответ #36 : Апреля 21, 2010, 08:48:04 pm »

Добрый день!       
     Странно читать спор об отмене или нет обязательного описания переменных, когда во всех современных скриптовых языках это в настоящее время поддерживается по умолчанию.
          Обязательное явное описание - это пререгатива языков 60-х годов 20-го века.    К стати можно ввести макрос, указание которого включает либо отключает необходимость явного описания переменных.
         Если уж так сложно поддержать неявное описание переменных, то введите возможность перечисление переменных в объявлении через запятую.
          А еще лучше взять готовый скриптовый язык и транслятор для него с открытой лицензией, а не изобретать новый диалект неизвесного языка.
"Как много языков на свете  - красивых и могучих."
Например, векторные языки Amibroker,Маtlab или взять за основу Piton или C++.
    Можно бы и библиотеку функций Amibroker взять за основу и реализовать
 ( правда добавить массивы с фиксированными границами )  к существующим векторным.
   В основном же плохо, что в ATF не реализован доступ ко всей информации, доступной в API коннекторе. Потому что индикаторы  написать можно, а вот автоматически торговать нельзя.
     Благодарю за внимание.
Записан
nikolz
Sr. Member
****
Сообщений: 285


Просмотр профиля Email
« Ответ #37 : Апреля 21, 2010, 09:00:50 pm »

    Дополнительно предлагаю реализовать интерфейс подключения внешних dll библиотек, как это реализовано в Omega Research и в Amibroker.
   Из своего опыта знаю, что реализация функций через внешние библиотеки на языках C,C++  для Omega Research ProSuite  позволила ускорить вычисления в 100 раз.
 Думаю, что в случае с ATF эффект ускорения будет не меньший.
  К тому же сразу снимуться все претензии к ATF.
Благодарю за внимание.
Записан
nikolz
Sr. Member
****
Сообщений: 285


Просмотр профиля Email
« Ответ #38 : Апреля 21, 2010, 09:13:22 pm »

В качестве набора необходимых функций для работы с биржевыми данными предлагаю реализовать все функции реализованные в QPILE в QUIK и описанные в документации QUIK ( можно  взять их за прототип, чтобы не придумывать заново и сделать лучше ).
Благодарю за внимание.
 
Записан
Heller
Разработчики
Hero Member
*****
Сообщений: 1277


Просмотр профиля Email
« Ответ #39 : Апреля 22, 2010, 10:43:54 am »

nikolz, лично мне не очевидны преимущества отмены обязательного объявления переменных. Во-первых, реализация языка, в котором эти определения отменены - более сложная задача (в частности возникают тонкие моменты с областями видимости), во-вторых многие языки содержат специальные  директивы для запрета неявного  объявления переменных и любой программист этим всегда пользуется, так как это реально защищает от ошибок (вы например не найдете ни одного профессионального проекта на Perl, который бы не содержал объявления use strict 'vars', хотя собственно Perl стал в современных условиях "законодателем мод" на всякие штуки вроде неявного определения переменных и автооживление).

Насчет "взять за основу", то так же преимущества не очевидны. Все перечисленное вами (кроме Amibroker-а, с которым я не знаком) - это очень большие проекты, и совершенно не ясно зачем их дублировать если все равно 90% функций этих языков не пригодны для трейдера. К тому же все перечисленные вами языки (помимо Amibroker-а) созданы для решения совершенно других задач, не относящихся к трейдингу, и соответственно они никак не учитывают специфику области. Например, python без возможностей функционального программирования так вообще не представляет никакого интересна, но разве трейдеру нужно функциональное программирование? То же самое можно сказать и об остальных языках.

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

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

Возможность подключать dll в ATF пока не обсуждалась, но реализовать вполне можно. Обсудим, вероятно внесем в план (хотя сейчас все равно есть довольно обширный список более приоритетных задач).
« Последнее редактирование: Апреля 22, 2010, 11:09:10 am от Heller » Записан
nikolz
Sr. Member
****
Сообщений: 285


Просмотр профиля Email
« Ответ #40 : Апреля 22, 2010, 11:24:55 am »

Heller
1) В плане дискуссии, все что Вы сказали имеет место быть.
Но, вот Amibroker как раз тот язык, который сделан для трейдеров.
Когда я ознакомился с Вашим ATF, то у меня сложилось впечатление , что именно его Вы и повторяете, очевидно ошибся.
 2)  Когда я писал программы исключительно на CИ, а ранее на алголе, фортране, паскале,ассемблерах ,то был с вами полностью солидарен.
 Когда стал писать на скриптовых языках - привык не объявлять.
И знаете ошибки из за этого не появились.
3)  Возможно, что проблема в слабой диагностике Вашего транслятора.
На все проблемы у него почти всегда одно сообщение: Неожиданно появилось....  И вот когда начинаешь искать, что же появилось, а потом когда не находишь , что появилось, вспоминаешь , что надо перед каждой переменной писать var. 
    Ну сделайте хотя бы  объявление через запятую.
4) Я вообще не очень понимаю, почему возникнут ошибки при отсутствии объявления.
    В древних языках ошибка была связана не с отсутсвием объявления, что это переменная, а с отсутствием  объявления  типа переменной.
    У вас же тип переменной не объявляется, поэтому считаю, что необходимость объявления, что это VAR (хотя трудно переменную спутать еще с чем-то)  является надуманной.
   С уважением, к Вашему мнению
Записан
Heller
Разработчики
Hero Member
*****
Сообщений: 1277


Просмотр профиля Email
« Ответ #41 : Апреля 22, 2010, 11:46:41 am »

Amibroker-а я посмотрю, интересно.

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

В декларациях же функций я пока не хочу выкидывать var по той причине, что даже не смотря на то, что ATF не типизирован, я держу в уме например возможность передачи указателя на функцию, либо передачу параметров по ссылке. Понятно, что все это может быть решено и без деклараций, но я не готов брать риск заглядывать так сильно вперед и выкидывать var сегодня. Если в отдаленной перспективе будет 100% очевидно, что эта декларация действительно является совершенно несущественной, то выкинем. Пока же не вижу смысла (в конце концов не так уж сильно это и мешает все же - это всего навсего одно трехбуквенное слово, а последствия от его выкидывания могут быть неприятными в перспективе).
Записан
nikolz
Sr. Member
****
Сообщений: 285


Просмотр профиля Email
« Ответ #42 : Апреля 22, 2010, 01:27:10 pm »

Heller
1)Да, действительно, я не имел ввиду декларации функций, тут я с Вами согласен,
а говорю об объявлении переменных в теле программы, внутри блока.
2) В плане дискуссии.
      Я считаю, что попытки создать свой встроенный язык, вместо использования существующих с открытой лицензией является стратегической ошибкой, особенно в малобюджетных проектах .
     Получается так, что на строительство высотного здания денег нет, поэтому прочный кирпич не нужен, и будем тратить деньги на изобретение своего не очень прочного, но как раз какого надо кирпича.
    Резонный вопрос - а на само здание денег хватит или его будут строить бесконечно долго либо построим столько этажей на сколько хватит оставшихся. после создания своего кирпича. денег.
3)   Если оценить объем сделанной Вами работы ( в смысле строительства здания, а не создания кирпича) то это примерно не более 10% .
     Для подключения дополнительных индикаторов можно было бы просто реализовать механизм подхвата внешних dll и описать интерфейс . После чего практически на любом языке можно было бы создавать любые индикаторы и нет никакой проблемы ни с трансляторами ни с языками.
4)      Важно создать средства программного доступа к биржевой инофромации и средствам отображения TRANSAQ TRADER, чего пока в ATF практически нет.
5)    Теперь о библиотеке функций.
  Вот например QPILE в КВИКЕ - язык убогий, но перечь фйнкций работы с биржевой  информаций  и  торговыми операциями достаточно полный.
Почему бы Вам не взять этот перечень за основу  и созделать свою реализацию, усовершенствовав имеющуюся, а не изобретать велосипед. 
 6)    Считаю важным предоставить Интерфейс подключения DLL как это есть Омеге Амброкере
     Это обеспечит возможность создания  бибилиотек практически любых быстродействующих индикаторов на любой вкус и цвет.
  Благодарю за внимание. 

 Благодарю за внимание
Записан
Heller
Разработчики
Hero Member
*****
Сообщений: 1277


Просмотр профиля Email
« Ответ #43 : Апреля 22, 2010, 06:33:19 pm »

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

Использование сторонней разработки совершенно не избавляет от решения архитектурных вопросов, а зачастую даже делает эту часть более сложной. К тому же из тех языков, что вы перечислили, открытые решения есть только для Python и C++. Даже если оставить в стороне тот факт, что Python объективно не подходит, а C++ для большинства трейдеров сложен, большая часть открытых реализаций использует лицензии навроде GPL, которые разрешают использовать их код только в Open Source продуктах, что нам явно не подходит.

Попытки внедрить сторонние разработки нами уже предпринимались, и они были неудачными. На самом раннем этапе была попытка не писать свои индикаторы, а использовать ta-lib, в результате две недели пришлось потратить на отлавливание ошибок, которые возникают из-за разного видения архитектуры нами и ta-lib, к тому же выяснилось, что ta-lib весьма медленная. Когда от него отказались, я все почти все индикаторы, реализованные сейчас в Transaq, написал за несколько дней. Была так же неудачная попытка внедрить высокоуровневую библиотеку и для самих графиков (реализация базовых вещей врое отрисовки свечей, работы с графическими объектами и мышью) - она оказалась слишком негибкой и мы просто поняли, что она заводит нас в тупик. Прежде чем приступить к ATF мы так же рассмотрели несколько простых готовых альтернатив - всё что мы рассматривали по какой-то причине не подходило. Что-то слишком сильно тормозило при постоянном обращении, где-то были принципиальные разногласия по архитектуре.

Вообще не смотря на то, что "возьмите готовое" - самая распространенная рекомендация, которая на первый взгляд кажется здравой, до сих пор никто еще на готовом ничего не добился в этой сфере, и это не просто так. Я уверен что и Amibroker и QUIK тоже рассматривали эти варианты прежде чем приступить к разработке. Что же касается изобретения самого языка, то разработка концепции вообще почти не отнимает времени. Как правило видение языка приходит уже в момент чтения соответствующей теоретической литературы, если конечно разработка подобного проекта - личное желание из любви к предметной области, а не просто ТЗ.

Собственно сторонние продукты могут привлекаться только в каких-то малозначительных для проекта областях. Например, мы не изобретаем свой компилятор C++ для компиляции наших исходных кодов и не пишем своих библиотек для работы с XML-файлами, так как для нас это области не критичные - XML и C++ для нас не более чем средство. Но ATF - это именно наш продукт, реализация которого для нас критична, и на него у нас есть свое видение. В качестве примеров можно привести Google, который для своих проектов использует свой собственный веб-сервер, а не привлекает сторонние разработки вроде Apache или IIS, или Excel, для компиляции первой версии которого специально был написан отдельный компилятор. Просто это все - примеры критичных задач, которые нельзя переложить на сторонние продукты. В конце концов софтверные компании всегда предлагают решение задачи. Если бы Transaq был бы целиком составлен из готовых решений, и мы бы не заморачивались разработкой ATF или графиками, используя что-то стороннее и разработанное до нас, то мне думается, что мы вообще были бы не нужны конечному пользователю.
Записан
nikolz
Sr. Member
****
Сообщений: 285


Просмотр профиля Email
« Ответ #44 : Апреля 23, 2010, 08:35:15 am »

Heller
В порядке дискуссии
1) Про индикаторы.
 Мне не понятно, почему Вы не реализовали интерфейс dll библиотек для индикаторов.
Тогда задача их разработки вообще бы решалась вне вашего языка и вашей системы, а в систему лишь интегрировались готовые решения на любых языках.
   Для примера возьмем Omega Research ProSuite и его клоны в виде MultiCharts, TradeStation.
Я написал свою библиотеку с реализацией практически всех методов из МАТЛАБ, включая искусственный интеллект, используя лишь их SDK для подключения dll,  все это работает в 100 раз быстрее, чем тоже , написанное на их языке.
   Не говоря о том, что на встроенном языке Вы никогда не реализуете методы искусственного интеллекта или адаптивного спектрального анализа, например, метод Берга.
2) О языках.  Что имеете против этого:
     Lua — интерпретируемый язык программирования, разработанный подразделением Computer Graphics Technology Group of Pontifical Catholic University of Rio de Janeiro in Brazil.
Является свободно распространяемым, с открытыми исходными текстами на языке Си.
По возможностям, идеологии и реализации язык ближе всего к JavaScript, однако Lua отличается более мощными и гораздо более гибкими конструкциями, спроектирован с целью «не плодить сущности сверх необходимого». Хотя Lua не содержит понятия класса и объекта в явном виде, механизмы объектно-ориентированного программирования с поддержкой прототипов (включая множественное наследование) легко реализуются с использованием метатаблиц, которые также позволяют перегрузку операций и т. п. Реализуемая модель ООП (как и в JavaScript) — прототипная.
3) Об архитектурных решениях.
     По-моему мнению Вы несколько путаете, вернее сказать, пытаетесь совместить две блюда в одной тарелке.
     Во-первых , реализуете средства для ручной торговли и создания для этой цели различных индикаторов.
Во-вторых, реализуете средства для автоматической торговли.
        В первом случае требуются различные окошечки, замочные скважины и разные кнопочки и финтефлюшечки - это называется интерфейсом пользователя.
     Во втором случае этого ничего, в основном, не требуется, роботу не нужен ни свет, ни еда ни окошки, ни двери, ни мониторы.
    Нужны функции получения биржевой информации, функции торговых операций, функции информации о состоянии счетов, функции получения истории, функции получения текущих котировок, сделок, заявок и функции индикаторов, функции работы с файлами для хранения отчетов и ввода начальных настроек и состояний.
     Вопросы общения с человеком не являются в этом случае первостепенной задачей.
 Поэтому в этой задаче интерфейс или как вы говорите архитектура может быть самой убогой.
4) И еще по поводу использования готовых решений.
  Вы пишите, что не знаете примеров.
Например, TSLAB - собрали три бесплатных пакета на модном решении NET и получился тяжелый красочно раскрашенный танк. Теперь пытаются сделать его летающим.
   Хотя есть другие  бесплатные, но быстрые пакеты, которые предназначены для создания подобных систем, но очевидно как говорил Райкин:
"Портной думал о чем угодно только не о пиджаке. К пуговицам претензии есть?  "
Благодарю за внимание.
Записан
Страниц: 1 2 [3] 4 5 ... 8 Печать 
Transaq  |  СБО "Transaq"  |  Подсистема ATF  |  Topic: Пожелания для развития TRANSAQ ATF « предыдущая тема следующая тема »
Перейти в:  


Войти

Powered by MySQL Powered by PHP Powered by SMF 2.0.10 | SMF © 2006-2008, Simple Machines LLC Valid XHTML 1.0! Valid CSS!