Просмотр сообщений
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Messages - ddd323
16
« on: 25.04.2014, 13:16:54 »
var statline; function init() { statline = new_object("statline"); statline.subscribe(); }
Остальное без изменений, кроме стирания тех строк, которые я в инит перенес
17
« on: 25.04.2014, 11:39:36 »
а зачет создавать объект на каждом тике вместо того чтобы сделать это один раз в ините?
18
« on: 08.04.2014, 14:35:05 »
а может просто переменную z сделать глобальной типа static? будет всего одна постоянно перезаписываемая (вместо сотен или тысяч вновь созданных за одну свечу - до следующей уборки мусора). кстати, а зачем на каждом тике запрашивать массив ВСЕХ заявок - может стоит запоминать id только нужных (требующих отслеживания) заявок и проверять периодически их статус. Даже если их 100 одновременно и статус их нужно знать на каждом тике - с точки зрения памяти это может быть более экономным.
19
« on: 01.04.2014, 12:13:02 »
Реализуйте, пожалуйста. В контексте всех функций из сабжа этой темы - это может пригодиться для сортировки или поиска потерянных из-за разрывов связи заявок
20
« on: 31.03.2014, 20:34:14 »
alexejshevchenko, а вы где время для заявок добываете? Согласно хелпу нет такого поля у хеша заявки...
21
« on: 24.03.2014, 09:54:21 »
Heller?
22
« on: 19.03.2014, 13:40:58 »
Heller, когда можно ожидать доступность пограничных цен в атф и трансляцию туда вышеупомянутого события от сервера - в следущем релизе или через релиз?
23
« on: 19.03.2014, 13:34:45 »
полагаю открывать файл в режиме wopen, а не waopen + афаир file.seek(0)
24
« on: 18.03.2014, 16:07:17 »
регулярное обновление значения пограничных цен и информирование о событии "биржа изменила торговый диапазон" это немного разный функционал. Просто очень не хочется на каждой свече или перед каждой сделкой самому в скрипте атф проверять, не изменился ли диапазон (особенно, если получение этих пограничных цен будет асинхронным, т.е. приводить к ожиданию и потерям времени), вместо ожидания соответствующего события от сервера. Я в посте #14 изложил свое видение идеала.
25
« on: 18.03.2014, 10:19:53 »
klimov, посмотрите пожалуйста вопросы в постах #6 и #9. Можете что-то определенное про серверную функциональность сказать?
26
« on: 17.03.2014, 20:35:44 »
Вероятно, вы имели в виду: OrdrHash["price"] = book.getAskPrice(book.getAskPosCount()-1);
Но это в любом случае не дает границу торгового диапазона, а лишь границу известного клиенту стакана, глубиной 20, как я сейчас проверил (что кстати, странно, вроде кто-то на форуме говорил, что атф получает на фортсе стакан глубиной 100). Т.е. если я бы подал такую заявку из onNewCandle() в 10.00 при гигантском гепе вверх с параметром "поставить в очередь" моя заявка к моменту поступления на биржу просто повисла бы в стакане на уже давно пройденной высоте.
27
« on: 17.03.2014, 08:28:07 »
Heller, в дополнение к вопросу из поста #9. В части получения информации от сервера об изменении торгового диапазона - в идеале неплохо бы сделать что-то типа вызова функции onTradeRangeChanged() по соответствующему событию, полученному от сервера. Естественно, при одновременном приходе этого события с другими (новая свеча, трейд) функция onTradeRangeChanged() должна обрабатываться/вызываться ДО исполнения соответствующих onNewCandle() и calc() (т.к. в них уже могут быть торговые операции, требующие знания новых "пограничных" цен)
28
« on: 16.03.2014, 11:24:50 »
Что необычного вы собираетесь в нем увидеть? Обычная подача рыночной заявки через хеш. Если знаете как подавать рыночные заявки на ФОРТСе так, чтобы они в очередь ставились - так и напишите, как их подавать. (Добавка поля "unfilled", как я понял разработчиков, не поможет - оно будет игнорироваться.)
var OrdrHash = new_object("hash"); OrdrHash["quantity"] = 2; OrdrHash["operation"] = OP_BUY; OrdrHash["brokerref"] = 1; var ordr_trnid = trade_action::transactMultiple(OrdrHash);
P.S. Хэш локальный.
29
« on: 15.03.2014, 19:05:48 »
Под термином имею в виду то же самое. Последний раз это было 3 марта 2014 года на гепе вниз на открытии, причем диапазон менялся 2 раза в течение часа. Сделки по границе диапазона на продажу после его достижения еще шли (торги не были остановлены), т.к. находились иногда желающие покупать по этой цене. Суть вопроса - нужно исполнить объем на любых условиях без всяких остатков (в итоге, т.е. можно в несколько порций) и снятий. Готового инструмента для этого не существует. Ближайший аналог - заявка по рынку согласно рекомендации биржи и мнению разработчиков о "классике" этой цели не удовлетворяет, т.к. эмулируется лимитной с "пограничной" ценой с параметром "снять остаток", т.е. если прямо сейчас желающих купить нет - то она снимается. А нужно чтобы, если желающих купить нет, заявка оставалась в стакане - тогда, например, через 5 или 50 секунд, когда появится желающий купить - моя заявка исполнилась бы. 3 марта моя заявка, поданная в 10.00.00 похоже дошла до биржи и стала активной на 242 трейде, а еще на 239 трейде граница торгового диапазона не была достигнута. Т.е., если бы моя заявка не была снята и осталась в стакане - она была бы третьей в очереди на продажу по "пограничной" цене и наверняка была бы исполнена. Идеальное решение было бы - получить до начала торговой сессии нижнее значение торгового диапазона и подавать заявку в 10.00.00 как лимитную по этой нижней границе с параметром "поставить в очередь". Тогда моя заявка на продажу осталась бы в стакане. Но для этого нужен соответствующий функционал терминала, и, наверное, сервера транзака. Возможное сейчас противодействие о котором я писал с предыдущем посте (поймать статус "отменена" и переподать заявку) будет означать что я был бы не 3-м в очереди на продажу по этой цене, а условно тысяча первым с призрачными шансами на исполнение. Разница - проскальзывание ~10000 пунктов вместо ~5000, а с учетом того, что я не просто закрывал длинную позицию, а переворачивался этой сделкой, разница для меня была бы между сильным убытком и заметной прибылью на этом гепе на открытии. (Хотя такие события случаются очевидно в среднем 1 раз в год - они достаточно крупные с точки зрения влияния на прибыль, чтобы о них стоило заботиться)
Про объем - если честно, не понял, при чем здесь объем. Я, к счастью, пока в тестовом режиме работаю и продавал всего 2 контракта. Но если бы я продавал 200, то разница для меня между 3-м и тысячным местом была бы еще важнее. При любом риск- менеджменте (или его отсутствии) задача закрыться как можно раньше и как можно надежнее при гигантских гепах, которые как показывает история иногда случаются, существует.
30
« on: 14.03.2014, 21:28:54 »
2 Heller, функцию на сервере тоже надеюсь не сложно? Когда можно ждать функцию в терминале - в следующем релизе? А когда на сервере?
2 White Noise. Нет не решил. Сейчас единственный способ получать значения торгового диапазона - делать реальные заявки по рынку - в onOrder вернется хэш с заполненной ценой. Но, соответственно, даже таким способом до начала утренней торговой сессии получить торговый диапазон предстоящей сессии невозможно. Так что все что можно делать сейчас - это ловить в onOrder статус рыночных заявок "отменено пользователем" (это если отмену заявок сам скрипт не делает) и повторять последнюю заявку как лимитную уже с параметром "поставить в очередь". Но с точки зрения потенциального проскальзывания (или точнее вероятности все-таки совершить сделку по этой цене на краю диапазона) из-за потерь времени это очень далекое от идеала решение.
|