[АРХИВ]Любой вопрос новичка, чтоб не захламлять форум. Профи, не проходите мимо. Без вас никуда - 5. - страница 396

 
rajak:

Доброго всем!

Подскажите, может кто знает что за проблема такая, после компиляции файл ex4 не появляется, через metalang тоже. Что можно с эти сделать, причем пару дней назад все работало нормально.

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

Если у Вас windows7, попробуйте поискать в виртуальной папке

c:\Users\Ваша папка\AppData\Local\VirtualStore\Program Files (x86)\Папка МТ4\experts\ 

Вместо Ваша папка и Папка МТ4 подставляйте Ваши реальные директории. 

 
lottamer:

Когда-то тут добрые люди подсказали как из функции "возврат тикета последней закрытой позиции", сделать функцию " возврат тикетов двух последних закрытых позиций".

И когда мне понадобилась функция "тикеты трех закрытых позиций", я не смог (методом подобия и подбора) ее реализовать

 помогите плиз,  

видно что это две копии , вторая с некоторыми изменениями. но я смог продолжить их... 

у меня для 3-го тикета вот такой вариант получается.. и он снова почему-то возвращает тикет первой позиции...  

 


Замените

if(OrderTicket()==A && (OrderTicket()==B) )continue;

на

if(OrderTicket()==A || (OrderTicket()==B) )continue;

 Только не ясны Ваши действия по возврату трех значений из одной функции

 
Roger:


Замените

на

 Только не ясны Ваши действия по возврату трех значений из одной функции

 



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

fLastClosetPoz();
     OrderSelect( Ticket1,SELECT_BY_TICKET); X=OrderProfit(); SL1=OrderType(); TM1=OrderOpenTime();      Print (Ticket1); Print (SL1,"_",X); //ПОСЛЕДНИЙ 
     OrderSelect( Ticket2,SELECT_BY_TICKET); Y=OrderProfit(); SL2=OrderType(); TM2=OrderOpenTime();      Print (Ticket2); Print (SL2,"_",Y); //ПРЕДпоследний
     OrderSelect( Ticket3,SELECT_BY_TICKET); Z=OrderProfit(); SL3=OrderType(); TM3=OrderOpenTime();      Print (Ticket3); Print (SL3,"_",Z); //ПРЕД-ПРЕДпоследний
 
Roger:


Замените

на


Сработало! честно говоря, была у меня эта мысль подставить ИЛИ вместо И....но ... :)))))))))))))))))))))

спасибо! теперь мне логика ясна, хотя для подсчета 15 закрытых, придется раздуть код до размеров воздушного шара!

а можно это все ужать в один цикл ? и только подставлять параметр количества нужных сделок  N ?

 
Zhunko:

1. Это ты зря. Там же даже выражены мои восхищения его алгоритму. Этот тот самый ХРЕНФИКС. Тогда другой ник у него был.

В префиксе названия скрипта первые буквы наших ников.

===============

2. Дмитрий, не смотря ни на что, я искренне рад, что ты решил какую-то тайную задачу каким-то тайным алгоритмом, которые не подлежат разглашению.

3. Всё выглядело очень загадачно. Спасибо, что похвастался. Ты несомненно самый крутой программист на этом форуме и, может даже, во всей вселенной!

1. О да! После того, как выяснилось, что это твой код, или твоего дружка. Абалдеть, был самым хреновым и позорным, теперь сразу стал восхитетльным.

2. С тем, какой я программист, что я знаю и умею и как я это знаю и умею, с тем чего я не знаю и не умея - с этим разберусь как-нибуь сам. 

 3. Задача совершенно не тайная, абсолютно явная, открытым образом здесь была определена. Все, кто способен понимать, сразу без пролем ее поняли. Решена она у меня не какими-ниубдь тайными волшебными методами, а обычными стандартными и явными (и всемирно известными). Не хвастаюсь я здесь, а над тобой, чудо, ухахатываюсь. Только твоя мания величия не позволяет тебе этого понять и осознать.    

 
Integer:

1. О да! После того, как выяснилось, что это твой код, или твоего дружка. Абалдеть, был самым хреновым и позорным, теперь сразу стал восхитетльным.

2. С тем, какой я программист, что я знаю и умею и как я это знаю и умею, с тем чего я не знаю и не умея - с этим разберусь как-нибуь сам. 

 3. Задача совершенно не тайная, абсолютно явная, открытым образом здесь была определена. Все, кто способен понимать, сразу без пролем ее поняли. Решена она у меня не какими-ниубдь тайными волшебными методами, а обычными стандартными и явными (и всемирно известными). Не хвастаюсь я здесь, а над тобой, чудо, ухахатываюсь. Только твоя мания величия не позволяет тебе этого понять и осознать.    


 



ребята, идите трите в другом месте! здесь люди решают ПРАКТИЧЕСКИЕ задачи. а вы засераете ветку эмоциями... 
 
lottamer:


ребята, идите трите в другом месте! здесь люди решают ПРАКТИЧЕСКИЕ задачи. а вы засераете ветку эмоциями... 


А что ты мне об этом пишешь? Возми да Жунко это напиши, это он здесь четвертый день понять не может о чем разговор, все остальные в первый день поняли. 
 

Конечно, любым спорам должны быть ограничения. Иначе это уже может перейти границы разумного.

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

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

Но переходить на обвинения и апеллированию к личности (а не к задаче, вопросу, делу) - это уже снижать свой авторитет. Это лишнее и осуждаемое (за оскорбления личности).


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

Видимо, если в решении программных вопросов, спорщики и являются профессионалами, то в вопросах ведения споров - новички. Что не выбивается из темы ветки, но позволяет дать профессиональный совет. Надеюсь, этот совет будет услышан.

 
Integer:

1. О да! После того, как выяснилось, что это твой код, или твоего дружка. Абалдеть, был самым хреновым и позорным, теперь сразу стал восхитетльным.

2. С тем, какой я программист, что я знаю и умею и как я это знаю и умею, с тем чего я не знаю и не умея - с этим разберусь как-нибуь сам. 

 3. Задача совершенно не тайная, абсолютно явная, открытым образом здесь была определена. Все, кто способен понимать, сразу без пролем ее поняли. Решена она у меня не какими-ниубдь тайными волшебными методами, а обычными стандартными и явными (и всемирно известными). Не хвастаюсь я здесь, а над тобой, чудо, ухахатываюсь. Только твоя мания величия не позволяет тебе этого понять и осознать. 

1. Чуствуешь разницу между кодом и алгоритмом? При чём, алгоритм не имеет отношение к окрытию окна графика. Код, конечно, поправил. То место, где открывается график почти не изменилось. На тот момент другого варианта не было. В DLL подругому сделал. Надёжнее.

2. Замечательно! Ты самый самый!

3. Ты про это: 

FAQ:

1) Задача : каждый скрипт (советник) должен знать о наличии всех остальных.

2) Проблема : если произойдет сбой, то глобалки от сбойного будут висеть неприкаянные и очередь запнется.

3) Решение :

Каждый эксп организует 1 глобалку с именем - общий префикс + хендл окна + символ. значение глобалки - время последнего тика по этому инструменту. 2 общую глобалку со своим хендлом (после того как отработает пишет в нее свой хендл или обнуляет если самый старший)

Очередь организуем по возрастающей (хендлы), самый старший обнуляет вторую глобалку

в каждом экспе создаем три массива (за неимением структур) - символ\хендл\последнее время доступа\ время последнего тика.

все эксперты следят за  (время посл. доступа\ время посл. тика) для всех и как только они разнятся (сбой по одному из експов) обе глобалки сбойного эксперта удаляются и он считается неактивным. его  ячейки в массивах удаляются (массив перестраивается).

очередь восстанавливается 

реально это будет делать эксп который стоит на самом активном графике (частые тики).

принормальном деините, каждый эксп убирает за собой 

максимальный пропуск - один тик. 

ЗЫ. а вообще лучше делать один мультивалютник 

Так это благодаря телепатическим способностям Рустама добыто. Это гипотетическая задача и гипотетическое решение. Какое это имеет отношение к твоей задаче? Ты ниразу ничего об этом не сказал. Приходилось выпытывать. В ответ сплошь бранные слова вместо конструктива, который всё предлагаешь, но не реализуешь.

У меня была похожая задача в 2008 году. Тайны не буду делать, как некоторые. Расскажу на конкретном примере , что за задача, как решил, и почему считаю, что решение подобных задач таким способом неудачное.

============================ 

Исходные данные задачи:

1. Есть несколько одинаковых зацикленных экспертов. Т.е. полностью независимые потоки.

2. Есть БД коэффициентов, разбитых на 8 групп, к которой обращается часть экспертов. Размер БД от 2 Гб.

3. БД иногда пополняется. Пополняется через периоды кратные 2 часам. Время обработки зависит от кратности к времени суток. Продолжительность от 5 минут до 45 минут в зависимости от кратности к времени суток и производительности процессора.

Задача:

1. Т.к. пополнение БД занимает много времени, необходимо сделать ответственным за её пополнение только одного эксперта. Иначе, можно не дождаться, когда это закончится.

2. Необходимо запретить обращение к БД в период её обновления. Сделать это по группам, чтобы сильно не тормозить обновление коэффицентов, с которыми работают эксперты.

3. Эксперты работающие с коэффициентами, которые на данный момент обновляются, должны работать со старыми коэффициентами.

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

Решение на тот момент:

1. Сделана общая очередь идентификаторов экспертов, состоящая из их индексов.

2. Сделана очередь идентификаторов экспертов, которые обращаются к БД, состоящая из их индексов.

3. Обе очереди являются общим ресурсом. Доступ к очередям синхронизирован единым объектом синхронизации.

4. Ответственным экспертом за обновление БД назначается первый эксперт из второй очереди. 

5. Далее почти, как Рустам описал. Только немного проще из-за реализации в DLL.

Идентификаторы это сквозные индексы. При удалении эксперта идентификатор удаляется из очереди. Переиндексация не производится. Оставшиеся эксперты оставляют свои индексы.

При добавлении нового эксперта, если индекс последнего экперта не соответствует их количеству, то присваивается первый свободный старый индекс. Иначе присваиваются новые индексы.

Привязка к дескриптору и инструменту графика не нужна. Также, не надо отслеживать сбой выгрузки. Ниразу не было сбоев. Даже, если такое произошло бы, то это не является катастрофой. Эксперты продолжали бы работать со старыми коэффициентами. К следующему обновлению контроллер счётчика обновления обнаружил бы отсутствие обновления и выкинул из второй очереди идентификатор ведущего эксперта. Следующий эксперт подхватил бы миссию ведущего. Этот же контроллер занимается при переходе эксперта в режим подключения к БД. Т.е. вносит его во вторую очередь. Т.е. пострадали бы только эксперты, работающие на М1, где не критично значение коэффициента.

Такое решение полностью выполняло задачу, но мне сильно не нравилось из-за привязки экспертов друг к другу и несвойственной задачи для эксперта, который пополнял БД, что не добавляет надёжности. На тот момент много чего не знал и не умел. Через год переделал.

Решение 2:

1. БД обслуживается в отдельном потоке, где сама себя пополняет по таймеру.

2. Доступ к БД в момент пополнения защищён объектом синхронизации.

Всё получилось гораздо проще. Без очередей. Но это тоже мне не очень нравилось. Перед пополнением, БД вызывала скрипт подкачки котировок, что иногда приводило к переполнению памяти. Что сильно тормозило МТ4. Тогда МТ4 работал с памятью 2 Гб. Это сейчас он работает с 4 Гб.

Решение 3:

1. БД это отдельное приложение. Т.е. другой процесс со своей выделенной памятью независимой от МТ4.

2. БД сама себя пополняет.

3. Обмен данными происходит посредством маппинга. Что увеличило скорость обмена данными и скорость пополнения БД. Ранее всё считывалось с диска. Иначе было нельзя. У МТ4 сильно огранниченная рабочая память.

4. Подкачка истории происходит средствами МТ4 удалённо из приложения БД, где его пинаешь, как требуется. Любой сбой МТ4 - выгрузка его и последующая загрузка.

5. Пункт 4 выполняется путём создания символьной ссылки на текущий каталог МТ4. Т.е. это полная копия текущего МТ4. Обновление истории происходит на ходу прямо в каталоги МТ4, не дожидаясь выгрузки рабочего МТ4.

6. Синхронизация обращения к БД в момент её обновления через мьютекс, т.к. критическая секция работает только для одного процесса.

========================

Так, что, Дмитрий, не зная твоей задачи, можно с большой вероятностью предполагать, что твою задачу можно решить без организации очереди и сохранением независимости потоков экспертов. Что повысит надёжность и производительность работы в целом. Именно об этом (независимости потоков) говорю уже несколько страниц.

 

Извини. На это не ответил:

Integer:

Это блок атомарного доступа и никакой синхронизации. Обращаться только к депозиту так нет смысла. Вызов любой из функций параметров депозита сам по себе будет атомарным, без всяких накрутов. Если делать атомарно, то всю работу советника. Вот так вот вы и решаете задачи - думаете, что что-то сделали, а на самом деле - иллюзию.

Дмитрий, не надо думать, что вокруг одни дураки. Из вопроса Сергея видно, что он хорошо разбирается в проблеме.

Конечно, простое обращение к параметрам депозита с синхронизацией бессмысленно. Синхронизация нужна для изменения этих параметров. Чтобы параллельный эксперт получил правильный уже изменённый параметр, а не получал его в процессе изменения.

Причина обращения: