Добро пожаловать, Гость. Пожалуйста, войдите или зарегистрируйтесь.
Вам не пришло письмо с кодом активации?
Января 29, 2022, 01:34:09 am
Начало Помощь Поиск Войти Регистрация
Новости:

Просмотр сообщений

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

Pages: 1 ... 9 10 [11]
151
array.sort() - сортирует так : 1234567
array.descsort() так : 7654321

номер первого элемента в массиве всегда 0, а значит любой ресайз массива по 1 (одному элементу ) будет давать возможность работать только с элементом array[0].

Причем если ресайз сделать по "0" (прошу не путать "0" - количество элементов) то там будет пустота и транзак будет выдавать ошибку.

Так же : если вы в массив положили 5 элементов, (12345) получается что номер последнего элемента будет 4 т.е. array[4] = 5; ,  и если вдруг вы попробуете внезапно отресайзить его по 6 элементам, не положив туда что нибудь еще , то шестым элементом там опять же будет пустота, (12345.x.)

А если потом еще десорт сделать то эта пустота вернется на первое место (.x.12345) и огромное множество удобных команд, типа Аншифт-элемента, и все такое уж точно не будет доступно. ведь там пустота. А транзак то как ругаться будет ))))
 
Ну и как было замеченно : порядковых номеров с отрицательными значениями в массиве нет.

152
Спасибо огромное, ломаю голову уже неделю. Ну в общем все нормально остановимся на этом.

Кстати я тут баг обнаружил, новая версия 1,18, сборка 5,05,305,07, у финама.

В общем останавливаешь робота на зеленый значек,....ну типо готовишься его редактировать, потом "ОК" - сохранить, - и !!!! Полностью умирает Транзак. и так много раз.

Ладно думаю, может его сначала с графика удалить,...все равно такая же кухня.

Ну в общем прописал data.clear(); delTimer(timer); в функции onStopRobot() - и все нормально.

Похоже не очищаются массивы и каким то образом таймер не удаляется автоматически. Обратите внимание.


153
Спасибо.

154
Из выше сказанного получается что все -таки таймер может срабатывать параллельно с функцией Calc - правильно.
Но ведь таймер запускает какую - то функцию !!! Будет ли эта функция вызываться параллельно с  Calc, или  все равно по порядку - согласно нахождению в коде - не глядя что ее таймер параллельно вызвал ?

155

Уважаемый Heller, подскажите мне пожалуйста, что будет быстрее вызываться именно при большом потоке сделок (инфы по сделкам), Calc или все - таки быстрее  по таймеру setTimer("f",5, TIMER_PERIODICALLY). Не могу понять какая задержка у Calc между тиками когда они идут потоком.   Дело в том, используя таймер , чувствую что теряю данные (из за пинга, ну примерно 47млс), вот и озадачился. Посоветуйте  ....? 

156
Подсистема ATF / Re: signal
« on: Апреля 23, 2013, 11:21:56 am »
Ну правильно, потому что названия функции я писал схематично руками прям в сообщение,...функция onNewCandle() - посмотрите как правильно на сайте.

157
Подсистема ATF / Re: signal
« on: Апреля 23, 2013, 05:26:55 am »
Потому что 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
Подсистема ATF / Re: Работа со стаканом
« on: Марта 29, 2012, 05:30:12 am »
Не знаю ребята, я вот пользуюсь Транзак 1.8 сборки самой древней, одной из первых у финама,....и доволен причем ничего не ломается и не вылетает,...-Реально обратите внимание - может просто нужно в голове покапаться и найти проблему там,...

159
Подсистема ATF / Re: balance для FORTS
« on: Августа 23, 2011, 01:43:21 pm »
А у меня вообще проблем с этим нет !!! Нет робота - нет проблемм !!! Нет денег,...Хе хе,...

160
Подсистема ATF / Re: Шифрованный код на ATF
« on: Августа 23, 2011, 01:40:37 pm »
Абсолютно поддерживаю !!!! Я за !!!

161
Кстати в стакане всего 20 снизу бид,  и 19 сверху аск позиций,...- это в самый пик торгов, а вечером даже и на это порой не приходится надеяться. 

162
Торгую фьючерсами на трех графиках - РТС, Газпром и Сбер и вот впервые за пару месяцев работы на одном и том же коде во дни высокой волатильности (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
Торгую фьючерсами на трех графиках - РТС, Газпром и Сбер и вот впервые за пару месяцев работы на одном и том же коде во дни высокой волатильности (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
Скажите, а можно ли с помошью роботов заработать 50 000 % в мес. ?

Pages: 1 ... 9 10 [11]


Войти

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