|
Просмотр сообщений
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 - White Noise
151
« on: 26.04.2013, 15:07:35 »
array.sort() - сортирует так : 1234567
array.descsort() так : 7654321
номер первого элемента в массиве всегда 0, а значит любой ресайз массива по 1 (одному элементу ) будет давать возможность работать только с элементом array[0].
Причем если ресайз сделать по "0" (прошу не путать "0" - количество элементов) то там будет пустота и транзак будет выдавать ошибку.
Так же : если вы в массив положили 5 элементов, (12345) получается что номер последнего элемента будет 4 т.е. array[4] = 5; , и если вдруг вы попробуете внезапно отресайзить его по 6 элементам, не положив туда что нибудь еще , то шестым элементом там опять же будет пустота, (12345.x.)
А если потом еще десорт сделать то эта пустота вернется на первое место (.x.12345) и огромное множество удобных команд, типа Аншифт-элемента, и все такое уж точно не будет доступно. ведь там пустота. А транзак то как ругаться будет ))))
Ну и как было замеченно : порядковых номеров с отрицательными значениями в массиве нет.
152
« on: 24.04.2013, 11:45:54 »
Спасибо огромное, ломаю голову уже неделю. Ну в общем все нормально остановимся на этом.
Кстати я тут баг обнаружил, новая версия 1,18, сборка 5,05,305,07, у финама.
В общем останавливаешь робота на зеленый значек,....ну типо готовишься его редактировать, потом "ОК" - сохранить, - и !!!! Полностью умирает Транзак. и так много раз.
Ладно думаю, может его сначала с графика удалить,...все равно такая же кухня.
Ну в общем прописал data.clear(); delTimer(timer); в функции onStopRobot() - и все нормально.
Похоже не очищаются массивы и каким то образом таймер не удаляется автоматически. Обратите внимание.
153
« on: 24.04.2013, 11:36:15 »
Спасибо.
154
« on: 24.04.2013, 07:12:31 »
Из выше сказанного получается что все -таки таймер может срабатывать параллельно с функцией Calc - правильно.
Но ведь таймер запускает какую - то функцию !!! Будет ли эта функция вызываться параллельно с Calc, или все равно по порядку - согласно нахождению в коде - не глядя что ее таймер параллельно вызвал ?
155
« on: 24.04.2013, 05:35:10 »
Уважаемый Heller, подскажите мне пожалуйста, что будет быстрее вызываться именно при большом потоке сделок (инфы по сделкам), Calc или все - таки быстрее по таймеру setTimer("f",5, TIMER_PERIODICALLY). Не могу понять какая задержка у Calc между тиками когда они идут потоком. Дело в том, используя таймер , чувствую что теряю данные (из за пинга, ну примерно 47млс), вот и озадачился. Посоветуйте ....?
156
« on: 23.04.2013, 11:21:56 »
Ну правильно, потому что названия функции я писал схематично руками прям в сообщение,...функция onNewCandle() - посмотрите как правильно на сайте.
157
« on: 23.04.2013, 05:26:55 »
Потому что Calc просчитывает индикатор по истории,....в момент установки этого скрипта на график. А вот если бы ты сделал вот так :
static x=5;
static y;
function NewCandle()
{ y = 1;}
function calc()
{ if(y){signal::outputMultiple(x); x=6; }
}
Вот теперь получится 5 6 6 6 6 6 6
158
« on: 29.03.2012, 05:30:12 »
Не знаю ребята, я вот пользуюсь Транзак 1.8 сборки самой древней, одной из первых у финама,....и доволен причем ничего не ломается и не вылетает,...-Реально обратите внимание - может просто нужно в голове покапаться и найти проблему там,...
159
« on: 23.08.2011, 13:43:21 »
А у меня вообще проблем с этим нет !!! Нет робота - нет проблемм !!! Нет денег,...Хе хе,...
160
« on: 23.08.2011, 13:40:37 »
Абсолютно поддерживаю !!!! Я за !!!
161
« on: 19.08.2011, 13:20:57 »
Кстати в стакане всего 20 снизу бид, и 19 сверху аск позиций,...- это в самый пик торгов, а вечером даже и на это порой не приходится надеяться.
162
« on: 19.08.2011, 13:19:19 »
Торгую фьючерсами на трех графиках - РТС, Газпром и Сбер и вот впервые за пару месяцев работы на одном и том же коде во дни высокой волатильности (9-10 августа 2011) получил странный глюк - не выставились несколько заявок по рынку. (До и после все работало как часы)
В onATFOrderErr() написали мне, что де попытка выставить заявку с нулевой ценой. В таблице заявок в терминале заявка не появилась.
Мой код схематично следующий:
static OrdrHash;
function init()
{
OrdrHash = new_object("hash");
}
function onATFOrderErr(var str)
{
file_ATFlog.writeLn(getFormattedDateTime(getServerTime())+" Ошибка выставления заявки: "+str);
}
function onNewCandle()
{
OrdrHash["quantity"] = 1; OrdrHash["operation"] = OP_BUY/OP_SELL; trade_action::transactMultiple(OrdrHash);
}
Т.е. использую единожны, глобально определенный хэш. Нигде в коде поле цены этого хэша не заполняется и вообще не используется (т.е. я использую только заявки по рынку). Т.е. оно (поле цены) должно вечно быть равно NULL и не не может превратиться в 0. Если только это не сделали внутретнности АТФ (например при некорректном приведении типов) или не моргнули биты в оперативке (или есть еще варианты связанные с глюками в управлении динамически выделенной памятью?).
В лог я получил соответственно следующие записи (все эти 3 заявки подавались из onNewCandle() ):
10:55:00 09.08.11 Ошибка выставления заявки: RTS-9.11 (r1): Некорректный ордер: Покупка RIU1 по цене 0
14:25:08 09.08.11 Ошибка выставления заявки: GAZR-9.11 (gazr1): Некорректный ордер: Покупка GZU1 по цене 0
19:09:57 10.08.11 Ошибка выставления заявки: SBRF-9.11 (sbrf1): Некорректный ордер: Покупка SRU1 по цене 0
Соответственно, возникают вопросы:
1. это мне биржа этой ошибкой ответила или терминал АТФ, т.е. запрос на биржу даже не ушел?
2. изменяют ли хоть в каких-либо ситуациях внутренности вашего движка ATF состояние хэшовых переменных при выставлении заявок по хэшу?
3. каков все-таки алгоритм формирования цены в заявке по фьючам, которая уходит на биржу при ее выставлении по рынку? (Это важно понимать с точки зрения исправления ситуации путем повторного направления заявки)
Эта тема немного поднималась:
http://www.transaq.ru/forum/index.php?topic=467.msg2569#msg2569 (сообщения 17-21). Тогда сказали, что терминал/сервер Транзак в этой ситуации "выставляет заявки по минимальной или максимальной допустимой цене на данный момент",
а эти макс/мин. цены определяются каким-то непонятным (Heller'у) образом сервером ФОРТС и возможно (по мнению daytrader'a) изменяются только во время клирингов, т.е. могут не меняться часами.
Типично из опыта - этот отступ мин/макс цен ставится от текущей цены на расстоянии 2%. Я раньше делал рыночные заявки сам - в trade_action::buy() добавлял отступ ~2.5% к текущей цене.
Так 2 или 3 раза на ~1000 попыток заявки не выставлялись и я получал в "окно вывода ATF" тексты а-ля "Некорректный ордер: Покупка RIU0 по цене 148500".
Потом появилась возможность выставлять заявки по рынку через хэш - я обрадовался - типа теперь мне сервер всегда правильную цену с правильным отступом будет подставлять. И тут на тебе - опять непонятный облом. Я почему про это вспомнил - во всех этих 3-х случаях невыставления по хэшу по причине нулевой цены,
рынок к моменту попыток поставить заявку уже успевах сходить на 4-5% от цены последнего клиринга, то есть выходил за эти пресловутые коридоры от сервера РТС. Соответственно, я опасаюсь, что
повторение высталения заявки по рынку через функцию trade_action::transactMultiple() выдаст ту же ошибку нулевой цены (чего-то мне не очень верится в моргание битов в оперативной памяти, испортившее мен хэши 3 раза за 2 дня),
а повторение высталения заявки по рынку старым способом выдаст старую ошибку "некорректный ордер" и как тогда с этим бороться непонятно. Есть еще идея послать на сервер условную заявку с заведомо истинным условием, предполагая, что сервер Транзак правильно сделает заявку по рынку.
Но эта идея имеет смысл, только если цену исходя из коридора в запрос подставляет терминал Транзак... Если этим занимается сервер и ошибку нулевой цены генерирует он - он и в случае заведомо истинной условной заявки не выставит заявку по рынку...
4. ну и вообще какие есть соображения о причинах этого глюка, появляющегося с вероятностью ~0.5% (на мой вкус неприемлемо много).
Версия 5.02.274 rev 48 ATF 1.8. Брокер - финам.
P.S. Воспроизведения этого глюка, буде у Вас такое желание Вам наверное тоже придется несколько месяцев ждать
Все просто, в стакане нет нужного колличества заявок,...а ваша цена в хеше, или точнее позиция по которой вы выставляете на продажу из хеша - просто не содержится в стакане,....т.е. вы выставляете например на 15 позицию купить,...а в стакане их всего 10,...значит цены то как таковой и нет на 15 номере,...атф это не распознает ему нужна конкретика, ....вот он ее и зануляет как статик переменс,...
Причем цену вы наверное вычисляете методом разницы хая и лоуа,...а представьте если лоу - хай 300 р, ...на ртс вам приходится делить на 5,...а это будет 300/5 = 60,.....хе,....откель в стакане столько позиций .....вот и ноль....
163
« on: 19.08.2011, 13:16:19 »
Торгую фьючерсами на трех графиках - РТС, Газпром и Сбер и вот впервые за пару месяцев работы на одном и том же коде во дни высокой волатильности (9-10 августа 2011) получил странный глюк - не выставились несколько заявок по рынку. (До и после все работало как часы)
В onATFOrderErr() написали мне, что де попытка выставить заявку с нулевой ценой. В таблице заявок в терминале заявка не появилась.
Мой код схематично следующий:
static OrdrHash;
function init()
{
OrdrHash = new_object("hash");
}
function onATFOrderErr(var str)
{
file_ATFlog.writeLn(getFormattedDateTime(getServerTime())+" Ошибка выставления заявки: "+str);
}
function onNewCandle()
{
OrdrHash["quantity"] = 1; OrdrHash["operation"] = OP_BUY/OP_SELL; trade_action::transactMultiple(OrdrHash);
}
Т.е. использую единожны, глобально определенный хэш. Нигде в коде поле цены этого хэша не заполняется и вообще не используется (т.е. я использую только заявки по рынку). Т.е. оно (поле цены) должно вечно быть равно NULL и не не может превратиться в 0. Если только это не сделали внутретнности АТФ (например при некорректном приведении типов) или не моргнули биты в оперативке (или есть еще варианты связанные с глюками в управлении динамически выделенной памятью?).
В лог я получил соответственно следующие записи (все эти 3 заявки подавались из onNewCandle() ):
10:55:00 09.08.11 Ошибка выставления заявки: RTS-9.11 (r1): Некорректный ордер: Покупка RIU1 по цене 0
14:25:08 09.08.11 Ошибка выставления заявки: GAZR-9.11 (gazr1): Некорректный ордер: Покупка GZU1 по цене 0
19:09:57 10.08.11 Ошибка выставления заявки: SBRF-9.11 (sbrf1): Некорректный ордер: Покупка SRU1 по цене 0
Соответственно, возникают вопросы:
1. это мне биржа этой ошибкой ответила или терминал АТФ, т.е. запрос на биржу даже не ушел?
2. изменяют ли хоть в каких-либо ситуациях внутренности вашего движка ATF состояние хэшовых переменных при выставлении заявок по хэшу?
3. каков все-таки алгоритм формирования цены в заявке по фьючам, которая уходит на биржу при ее выставлении по рынку? (Это важно понимать с точки зрения исправления ситуации путем повторного направления заявки)
Эта тема немного поднималась:
http://www.transaq.ru/forum/index.php?topic=467.msg2569#msg2569 (сообщения 17-21). Тогда сказали, что терминал/сервер Транзак в этой ситуации "выставляет заявки по минимальной или максимальной допустимой цене на данный момент",
а эти макс/мин. цены определяются каким-то непонятным (Heller'у) образом сервером ФОРТС и возможно (по мнению daytrader'a) изменяются только во время клирингов, т.е. могут не меняться часами.
Типично из опыта - этот отступ мин/макс цен ставится от текущей цены на расстоянии 2%. Я раньше делал рыночные заявки сам - в trade_action::buy() добавлял отступ ~2.5% к текущей цене.
Так 2 или 3 раза на ~1000 попыток заявки не выставлялись и я получал в "окно вывода ATF" тексты а-ля "Некорректный ордер: Покупка RIU0 по цене 148500".
Потом появилась возможность выставлять заявки по рынку через хэш - я обрадовался - типа теперь мне сервер всегда правильную цену с правильным отступом будет подставлять. И тут на тебе - опять непонятный облом. Я почему про это вспомнил - во всех этих 3-х случаях невыставления по хэшу по причине нулевой цены,
рынок к моменту попыток поставить заявку уже успевах сходить на 4-5% от цены последнего клиринга, то есть выходил за эти пресловутые коридоры от сервера РТС. Соответственно, я опасаюсь, что
повторение высталения заявки по рынку через функцию trade_action::transactMultiple() выдаст ту же ошибку нулевой цены (чего-то мне не очень верится в моргание битов в оперативной памяти, испортившее мен хэши 3 раза за 2 дня),
а повторение высталения заявки по рынку старым способом выдаст старую ошибку "некорректный ордер" и как тогда с этим бороться непонятно. Есть еще идея послать на сервер условную заявку с заведомо истинным условием, предполагая, что сервер Транзак правильно сделает заявку по рынку.
Но эта идея имеет смысл, только если цену исходя из коридора в запрос подставляет терминал Транзак... Если этим занимается сервер и ошибку нулевой цены генерирует он - он и в случае заведомо истинной условной заявки не выставит заявку по рынку...
4. ну и вообще какие есть соображения о причинах этого глюка, появляющегося с вероятностью ~0.5% (на мой вкус неприемлемо много).
Версия 5.02.274 rev 48 ATF 1.8. Брокер - финам.
P.S. Воспроизведения этого глюка, буде у Вас такое желание Вам наверное тоже придется несколько месяцев ждать
Все просто, в стакане нет нужного колличества заявок,...а ваша цена в хеше, или точнее позиция по которой вы выставляете на продажу из хеша - просто не содержится в стакане,....т.е. вы выставляете например на 15 позицию купить,...а в стакане их всего 10,...значит цены то как таковой и нет на 15 номере,...атф это не распознает ему нужна конкретика, ....вот он ее и зануляет как статик переменс,...
164
« on: 19.08.2011, 11:10:02 »
Скажите, а можно ли с помошью роботов заработать 50 000 % в мес. ?
|
