Вопрос к разработчикам. А почему бы не сделать клиент на Java. Зачем изобретать велосипед? - страница 2

Новый комментарий
 
Собственно, MQL4 полностью устраивет, - отличный язык прогаммирования. Можно реализовать буквально все фантазии. Зачем еще чего-то придумывать.
Для особо изобретателей можно и в dll-ке творить что хочешь :) .
 

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

 
Reshetov:
паче, что Java в отличие от .NET распространяется бесплатно,

MS .Net всегда был бесплатным - http://www.microsoft.com/downloads/details.aspx?FamilyID=0856EACB-4362-4B0D-8EDD-AAB15C5E04F5&displaylang=ru
 
natlam:

А разве С++ это не ООП?
to KimIV: А чам так плох .NET?


С++ - это не только ООП, но и мета-П. Но ожидать полной реализации ANSII C++ в MT... я смотрю на вещи более реалистично :)
 
klot:
Собственно, MQL4 полностью устраивет, - отличный язык прогаммирования. Можно реализовать буквально все фантазии. Зачем еще чего-то придумывать.
Для особо изобретателей можно и в dll-ке творить что хочешь :) .

Ну все-таки не хватает структур данных. А если в MQL5 будут классы, то это будет супер.
 
Да и классы-то не слишком уж так и необходимы. Представь, bstone, насколько он при этом утяжелится. Классы - это ж не просто поддержка компилятором таких структур, но еще и соответствующие библиотеки. Писали же на чистом С операционки без классов... Но вот насчет возможности создания новых типов данных я бы тебя поддержал безусловно. И расширить возможности управления компиляцией (#ifdef, #ifndef, скажем).
 
В принципе, можно было бы добавить UDT или структуры, и перечисления. А можно и не добавлять, т.к. новая фича -> новый баг. ИМХО, с помощью существующих языковых примитивов MQL4 можно изваять практически все, что душа пожелает. А ООП - ну его к лешему. Опять же ИМХО, здесь не те задачи. Процедурного языка для их решения более чем достаточно. Насчет расширенного управления компиляцией - честно говоря, не вижу, где это может потребоваться. А вот что было бы, на мой взгляд, желательно - поддержка в режиме тестирования контрольных точек с поп-апом, т.к. распринтовкой отлаживаться долго и нудно. Хотя теперь уже и привычно.

Кстати, по ходу дела вопрос: каков алгоритм работы функции AccountFreeMarginCheck( string symbol, int cmd, double volume) ? Как-то странно она работает. Похоже, обЪем открываемой позиции получается сильно заниженным. Вот кусок кода:

double GetSizeLot(int cmd, int lots_percent, double lot_min, double lot_max, double lot_step) 
 { 
  double dLot, fm_after; 
  //
  dLot = MathCeil(AccountFreeMargin() / 10000 * lots_percent) / 10; // "прикидочный" лот 
  //---- 
  NormalizeDouble(dLot, 1); // нормализуем 
  //----
  if (dLot < lot_min) { dLot = lot_min; } 
  //----
  if (dLot > lot_max) { dLot = lot_max; } 
  //---- 
  // стараемся избежать ошибки 134 (недостаток свободных средств на счете) 
  // вычисляем размер свободных средств на счете после открытия позиции 
  fm_after = AccountFreeMarginCheck(Symbol(), cmd, dLot); 
  //
  while (fm_after < 0) 
   { 
    // уменьшаем лот на величину шага изменения лота 
    dLot -= lot_step; 
    // если лот стал меньше или равен 0, приравниваем его 0 и выходим 
    if (dLot <= 0) { dLot = 0; break; } 
    // вычисляем размер свободных средств на счете после открытия позиции 
    fm_after = AccountFreeMarginCheck(Symbol(), cmd, dLot); 
   }
 //----
  return(dLot);  
 }
lot_min = 0.1, lot_step = 0.1. Непонятно, почему иногда "прикидочный" лот превышает уточненную величину в 10 и более раз, даже когда открытых позиций вовсе нет. Может, я что-то не так делаю? Хотелось бы разобраться.

З.Ы. Опять с подсветкой какая-то бяка. lot_min почему-то посинел.
 
Mathemat:
Да и классы-то не слишком уж так и необходимы. Представь, bstone, насколько он при этом утяжелится. Классы - это ж не просто поддержка компилятором таких структур, но еще и соответствующие библиотеки.
Соотвтествующие библиотеки, если их не будет сразу, появятся очень быстро точно так же, как и многочисленные эксперты/индикаторы/библиотеки, присутствующие на данный момент в Codebase.

alexjou 03.04.2007 15:22
ИМХО, с помощью существующих языковых примитивов MQL4 можно изваять практически все, что душа пожелает.

Теоретически можно, но на практике отнимает гораздо больше времени и намного сильнее подвержено ошибкам, чем аналоги, использующие ООП.

Я ратую за ООП потому, что я программист с большим опытом в этой области. Естественно для трейдеров без соответствующего образования такие возможности в МТ ничего не меняют. Однако на этом форуме уже как-то была озвучена мысль о том, что MQL - это все-таки язык больше для программистов, а не трейдеров. Последние всегда могут найти квалифицированного программиста для реализации своих идей. Я полностью поддерживаю такой взгляд на вещи и в этом всете поддержка ООП имеет гораздо больший смысл.
 
bstone:
Mathemat:
Да и классы-то не слишком уж так и необходимы. Представь, bstone, насколько он при этом утяжелится. Классы - это ж не просто поддержка компилятором таких структур, но еще и соответствующие библиотеки.
Соотвтествующие библиотеки, если их не будет сразу, появятся очень быстро точно так же, как и многочисленные эксперты/индикаторы/библиотеки, присутствующие на данный момент в Codebase.

alexjou 03.04.2007 15:22
ИМХО, с помощью существующих языковых примитивов MQL4 можно изваять практически все, что душа пожелает.

Теоретически можно, но на практике отнимает гораздо больше времени и намного сильнее подвержено ошибкам, чем аналоги, использующие ООП.

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

А что если не на java а на C#?
 
Нет, давайте уж сразу на Smalltalk. Как раз язык AI. Там, кажется, даже число - это объект. Поправьте меня, если ошибаюсь...
1234
Новый комментарий