Първоначално изпратено от Mateev
Разгледай мнение
Съобщение
Collapse
No announcement yet.
InstaForex - Мошеници висша класа
Collapse
X
-
Притежаването на качествен Random генератор е от изключителна важност за цялата описана по-долу търговска концепция, и тъй като не намерих такъв в интернет, повиках неволята и си го измислих сам. И сега запрятам ръкави и започвам да пиша класовете - един основен и няколко спомагателни. Ако имате някакви критики по описаната по-долу идея - казвайте. Сега е момента. Ако имате и други, по-добри идеи, ще съм благодарен да ги споделите. Така или иначе ще пиша нов Random генератор и ще преизчисля отново всички дроудауни по всички вероятности.
Тъй като ще е клас, а такъв се пише един път и после се ползва много пъти, мисля да го напудря с една камара екстри. Например ще го направя да може да тегли всякакви случайни числа във всякакви диапазони и размерности, както и по всички възможни разпределения, за които знам. Този клас е основополагащ за цялата търговска дейност, и за целия ресърч на печеливши търговски стратегии, така че няма да правя никакви компромиси с качеството на написания код и с коментарите към него.
Ако някой попита защо този клас е основополагащ, отговорът е много лесен. Ами за да разпознаем една зависимост в каквото и да било (графики, цени, баланси, Equity-та, зигзаци, барове, патерни, дроудауни и т.н.), първо трябва да си изясним какво прави чистата случайност, и чак тогава да започнем търсим разлики от нея. И ако намерим някаква разлика, значи сме намерили някаква закономерност, от която можем да извлечем ПМО. Тоест пътят към намирането на закономерности задължително минава през доброто познаване на чистата случайност.
Коментар
-
Хрумна ми още една тъпа идея, която без да използва файл може да осигури следното:
1. Теглене на 64 битово случайно число
2. Броя на различните изтеглени числа е 18 446 744 073 709 551 616 (2 на 64-та степен)
3. Гарантирано всяко едно число от тази поредица ще се появи точно по 1 път преди да започне повторение на псевдослучайната последователност
4. Тоест повторение ще започне чак след 500 години, ако всяка наносекунда компютъра тегли по 1 число
Идеята е в 4 масива да създам по 65536 двубайтови числа, и после хубавичко да ги разбъркам с MathRand. После развъртам един 64 битов брояч, като битовете му ги деля на 4 групи от по 16 бита, и всяка една от групите използвам за индекс към 4-те масива. От получените елементи от тези 4 масива отново сглобявам 64 битово число и готово. Повторение на това 64 битово число ще се случи чак когато 64 битовия брояч се препълни и започне да брои отново от нулата, но това ще се случи чак след 500 години работа без да се спира компютъра.
На пръв поглед идеята изглежда переспективна. Вярно е, че разбъркването на числата няма да е напълно случайно поради несъвършенствата на MathRand(), но това няма да попречи на повтаряемостта на генерираните случайни числа. Тоест гарантирано няма да започне повтаряне, преди всяко едно от 18-те квадратильона 64 битови числа да се изтегли по 1 път - ни повече, ни по-малко.
Мога допълнително да развъртя още три 16-битови брояча, посредством които да XOR-вам старшите масиви, така че и при 4-те масива да няма повторение в две съседни тегления, като в същото време ще се съхрани базовата идея - всяко едно число се тегли точно един път - ни повече, ни по-малко.Last edited by Mateev; 02.10.2019, 18:46.
Коментар
-
В общия случай всички езици за програмиране използват един и същи код за Random генератор, и той е следния:
[CODE]
a = 16807;
m= 2147483647;
seed = (a * seed) mod m;
random = seed / m;
[/CODE]
Повече информация за коефициентите има във Wikipedia: https://en.wikipedia.org/wiki/Linear...tial_generator
Важното е да се отбележи, че нито един комплект коефициенти не дава равномерно разпределение на генерираните числа, така че нито един генератор не е идеален. При всички видове генератори определени числа се появяват по-често от други, а някои числа от диапазона въобще не се появяват.
Хрумна ми една идея - за да си гарантирам, че всяко едно число се среща еднакъв брой пъти, мога всички възможни uint числа (2 на степен 32) да ги запиша във файл, и после да ги разбъркам с някой алгоритъм за случайни числа. Да, разбъркването няма да е идеално, но ще си гарантирам, че всяко едно число се среща точно 1 път - ни повече, ни по-малко. Ще се получи 17 GB файл, но какво от това - размера е поносим, а четенето ще е бързо, особено ако файла се намира на SSD. Това за момента ми изглежда най-разумния метод за получаване на случайни числа с равномерно разпределение.
От тука нататък получаването на случайни числа с нормално разпределение е много лесно - просто от инверсната кумулативна функция на нормалното разпределение тегля квантил с верните мю и сигма. Мю всъщност е ПМО-то, така че посредством него мога да генерирам произволно желана от мене вероятност. Мога по този начин да тегля случайни числа и от инверсната кумулативна функция на произволно друго разпределение. Във MQL5 библиотеките има пълен комплект от най-важните и най-масовите разпределения, така че тука няма да има проблеми. Нещо повече - тези MQL5 библиотеки съм ги направил да се компилират и под MQL4. Просто един ден ме ухапа мухата це-це и запретнах ръкави и отстраних няколко десетки грешки, които пречеха на MQL4 компилацията.
В момента тези статистически библиотеки ги ползвам и при двата езика и са неразделна част от моя статистически клас, с който определям статистиките на търговските стратегии. Нуждата от тези библиотеки възниква при определянето на доверителния интервал, който се нуждае именно от изчисляване на квантили от инверсната кумулативна функция на нормалното разпределение, както и на разпределението на Стюдънт, когато броя на сделките е по-малък от 30.Last edited by Mateev; 02.10.2019, 18:03.
Коментар
-
Първоначално изпратено от Mateev Разгледай мнение
Ето го кода на Random генератора. Използвам стандартната функция на MetaTrader, като я извиквам няколко пъти, за да получа случайно число със 64 бита. Допълнително поразбърквам тези битове с един брояч и с микросекундите на компютъра, за да избягам от повтарящите се 15-битови последователности. Накрая получавам 64-битова случайна последователност, от която вземам 16 бита, от които пък тегля случайното число. На изхода функцията връща +1 или -1 със зададена на входа вероятност Probability.
Като цяло написаната от мене функция се справя добре с изчистването на повтарящите се последователности на псевдослучайния стандартен MathRand(), но не съм сигурен доколко генерираните числа се доближават до първите 4 момента на нормалното разпределение. Най-вероятно има някаква грешка, която е предопределена от несъвършенствата на стандартния MathRand().
Функцията можех да я направя още по-сложна, а от там и по-бавна, но нека не забравяме, че я извиквам милиарди пъти, и затова се спрях на този разумен компромис от сложност и бързодействие.
[CODE]
//+------------------------------------------------------------------+
//| RandomTick.mqh |
//| Copyright 2019, RSM, Gabrovo, BULGARIA |
//| https://www.mateev.com |
//+------------------------------------------------------------------+
#property copyright "Copyright 2019, RSM, Gabrovo, BULGARIA"
#property link "https://www.mateev.com"
#property version "1.00"
#property strict
//================================================== ===========
// Функцията връща +1 или -1 с вероятност probability, като гарантира,
// че няма да се появи повторяемост дори и след милиарди извиквания.
// Променливата probability трябва да е в диапазона от 0 до 1
int RandomTick(double probability)
{
if (probability <=0) return(-1); // При вероятност 0 ( 0%) винаги се връща -1
if (probability >=1) return( 1); // При вероятност 1 (100%) винаги се връща +1
// Статични променливи, инициализацията на които се изпълнява само веднъж в хода на програмата,
// и след това си пазят стойноста между отделните извиквания на функцията
static ulong counter=0; // Брояч, който нараства с 1-ца при всяко едно теглене на нов тик
static ulong random =0; // Случайно число, от байтовете на което ще се теглят тиковете
// Младшите 2 бита на counter са индекса на 2-та байта, от които ще се тегли следващия тик
ulong wordID = counter & ulong(B'11');
// Веднъж на всеки 4 извиквания на функцията се преизчислява 64-битовото случайно число random,
// от 8-те байта на което в 4 последователни извиквания ще се изтегли по 1 случаен тик от всеки 2 байта
if (wordID == 0) // Ако индекса на байта е равен на 0, значи е време за преизчисляване на random
{
// Осигуряваме си неповтаряща се последователност от числа в променливата random,
// при която броя на нулите и единиците е приблизително еднакъв в безкрайноста
random = random ^ counter ^ GetMicrosecondCount();
// XOR-ваме 64-те бита на random посредством няколко псевдослучайни 15 битови числа
random = random ^ (ulong(MathRand())); // XOR-ваме първите 15 бита (битове 0..14)
random = random ^ (ulong(MathRand())<<15); // XOR-ваме следващите 15 бита (битове 15..29)
random = random ^ (ulong(MathRand())<<30); // XOR-ваме следващите 15 бита (битове 30..44)
random = random ^ (ulong(MathRand())<<45); // XOR-ваме следващите 15 бита (битове 45..59)
random = random ^ (ulong(MathRand())<<60); // XOR-ваме следващите 4 бита (битове 60..63)
}
if(counter<ULONG_MAX) counter++; else counter=0; // Проверка за препълване на Counter
// Вземане на 16-те бита на тази двойка байтове от random, която е определена с wordID
// В резултат на операцията (местене на дясно и AND-ване), в младшите 16 бита остава случайно число от 0000 до FFFF (65535)
ulong word = (random >> (wordID*16)) & 0xFFFF;
// Мащабиране на случайно число byte така, щото диапазона му да стане double от 0.0 до 1.0,
double rnd = double(word) / 65536;
// Изчисляване на тик с вероятност probability
if (probability >= rnd) return(1);
else return(-1);
}
[/CODE]
Имах предвид, дали имаш достъп до сорса точно на MathRand() - първоизточникът. Имах спомен, че манипупации върху 'изкривена' 'случайност' пак могат да генерират изкривена. Спомените ми са всъщност от MFC-библиотеките. (Те сякаш се оказаха някакъв междинен етап, незнам дали все още се ползват, особено след времето на framework, dot.net, clouds т.н.) Но по онова време можеше да се види и сорса на random-генератора, който ползваха.Помня и покрай и някаква хеш функция, която не беше особено удовлетворителна и се учудих дори, когато я видях - но все пак, за радост имаше възможност, да се види сорса. Виждах някъде и из сорсовете на софтуер за embed-устройства много много съмнителни формули за random-функция))
Синтаксисът на МетаTtrader съвсем си наподобява чисtото C, - като в оригинала на Д.Ричи, което си е радост за очите Идеята ми беше, ако не ти харесва в случая самия mathrand(); - да пробваш нещо от изпитаните варианти, въпреки че може да са познати, но поне са изследвани.
Помня също, че е имало период, когато в подобия на матхранд() са залагали на прости квадратични функции от вида Aх^2+B, след което за случайно число се взимат някакво количество битове от средните за голямото число, но се намериха и неприятни контрапримери и след това се възстанови класическия вариант - общо взето от вида f(x)=(Af(x-1)+B) (mod M)
Силата на тази бърза версия е в тунинга, - подходящият избор на А, Б и М. Може да дава почти максималните дължини неповтарящи се поредици, близки до използваният тип число.(ulong - например) За това обаче имаше условия. Например М беше 2^t, t- цифреното двоично число, а за коснтантите- А не трябваше да се дели на 2^3, a B трябваше да е нечетно, но имаше и още зависимости между тях, нещо свързано за sqrt(M);, които зависимости не помня добре, но ще разровя из книгите и ще запиша.Last edited by precakanoto; 02.10.2019, 15:07.
Коментар
-
Първоначално изпратено от precakanoto Разгледай мнение
Точно за генератора на псевдослучайните числа ми се искаше да попитам, какъв му е кода, (вероятно е кратък) защото е базата на която се стъпва за всички следващи нива и изводи. Е в случая и аз не вярвам да е от прекалено голямо значение, но усетът ти, според мен е правилен - че не съществува идеален, досега не исках да повдигам въпроса, защото разсъжденията ми се видяха интересни и да не отклонявам темата в неправилна посока. Преди време се интересувах от такива генератори, по проблематика свързана с увеличаване обемът на информационен канал за връзка, чрез оптимално кодиране (това обаче отпадна с много бързото развитие на технологиите и т.н.) Изобщо въпросът за идеален генератор е като за отделна тема, както бяхте отбелязали относно настройка на сървърите.
От една страна трябва да е възможно екстремно бърз (с по-малко сметки, заради милионите и милиард опити при монте-карлото да кажем). а от друга страна се иска и да наподобява 'истинска" случайна величина, да няма повторяемост и прогнозируемост, да описва разпределението, моментите от първи и по-висок ред, и т.н. Предполагам всеки програмист е позачитал древната книга на Д. Кнут или подобен по-по-осъвременен курс алгоритми, където са упоменати някои такива кодове и проблематиката, Мисля, че японците имаха някакви достижения в насоката, но като цяло мисленето със случайности не е някак силата на човешката логика и вероятно и поставянето на въпроса за ползваният генератор е също актуален. В някои решения се ползват предварително генерирани числа в таблици (за да е максимално бързо изчислението), -числа взети от някакви шумотевици числено дискретизирани, В други случаи се предлагаха извадки на съответни цифри от трансендентни числа (знаем, че нямат точно представяне в реалната област или чрез числител/знаменател), макар, че и това изглежда малко съмнително, Храня съмнения, че тази математическа задача, както я нарекохте, дали изобщо може да се реши, Но е интересно какъв е кодът на ползваният генератор. Вероятно може да се подобри
Като цяло написаната от мене функция се справя добре с изчистването на повтарящите се последователности на псевдослучайния стандартен MathRand(), но не съм сигурен доколко генерираните числа се доближават до първите 4 момента на нормалното разпределение. Най-вероятно има някаква грешка, която е предопределена от несъвършенствата на стандартния MathRand().
Функцията можех да я направя още по-сложна, а от там и по-бавна, но нека не забравяме, че я извиквам милиарди пъти, и затова се спрях на този разумен компромис от сложност и бързодействие.
[CODE]
//+------------------------------------------------------------------+
//| RandomTick.mqh |
//| Copyright 2019, RSM, Gabrovo, BULGARIA |
//| https://www.mateev.com |
//+------------------------------------------------------------------+
#property copyright "Copyright 2019, RSM, Gabrovo, BULGARIA"
#property link "https://www.mateev.com"
#property version "1.00"
#property strict
//================================================== ===========
// Функцията връща +1 или -1 с вероятност probability, като гарантира,
// че няма да се появи повторяемост дори и след милиарди извиквания.
// Променливата probability трябва да е в диапазона от 0 до 1
int RandomTick(double probability)
{
if (probability <=0) return(-1); // При вероятност 0 ( 0%) винаги се връща -1
if (probability >=1) return( 1); // При вероятност 1 (100%) винаги се връща +1
// Статични променливи, инициализацията на които се изпълнява само веднъж в хода на програмата,
// и след това си пазят стойноста между отделните извиквания на функцията
static ulong counter=0; // Брояч, който нараства с 1-ца при всяко едно теглене на нов тик
static ulong random =0; // Случайно число, от байтовете на което ще се теглят тиковете
// Младшите 2 бита на counter са индекса на 2-та байта, от които ще се тегли следващия тик
ulong wordID = counter & ulong(B'11');
// Веднъж на всеки 4 извиквания на функцията се преизчислява 64-битовото случайно число random,
// от 8-те байта на което в 4 последователни извиквания ще се изтегли по 1 случаен тик от всеки 2 байта
if (wordID == 0) // Ако индекса на байта е равен на 0, значи е време за преизчисляване на random
{
// Осигуряваме си неповтаряща се последователност от числа в променливата random,
// при която броя на нулите и единиците е приблизително еднакъв в безкрайноста
random = random ^ counter ^ GetMicrosecondCount();
// XOR-ваме 64-те бита на random посредством няколко псевдослучайни 15 битови числа
random = random ^ (ulong(MathRand())); // XOR-ваме първите 15 бита (битове 0..14)
random = random ^ (ulong(MathRand())<<15); // XOR-ваме следващите 15 бита (битове 15..29)
random = random ^ (ulong(MathRand())<<30); // XOR-ваме следващите 15 бита (битове 30..44)
random = random ^ (ulong(MathRand())<<45); // XOR-ваме следващите 15 бита (битове 45..59)
random = random ^ (ulong(MathRand())<<60); // XOR-ваме следващите 4 бита (битове 60..63)
}
if(counter<ULONG_MAX) counter++; else counter=0; // Проверка за препълване на Counter
// Вземане на 16-те бита на тази двойка байтове от random, която е определена с wordID
// В резултат на операцията (местене на дясно и AND-ване), в младшите 16 бита остава случайно число от 0000 до FFFF (65535)
ulong word = (random >> (wordID*16)) & 0xFFFF;
// Мащабиране на случайно число byte така, щото диапазона му да стане double от 0.0 до 1.0,
double rnd = double(word) / 65536;
// Изчисляване на тик с вероятност probability
if (probability >= rnd) return(1);
else return(-1);
}
[/CODE]Last edited by Mateev; 01.10.2019, 11:10.
Коментар
-
Първоначално изпратено от Mateev Разгледай мнениеЗа тези, на които им е любопитно, публикувам пълния комплект с първични файлове с дълбочината на всички Drawdown-и по всички вероятности от 50.1% до 99.9%, изчислени с различен брой сделки - от 100 до 1 милиард.
https://www.solar.sts.bg/files/Drawdowns.rar
Склонен съм да си мисля, че генератора на случайни числа, който съм използвал, не е съвършен и не дава идеално нормално разпределение, но то това е така с всички генератори на псевдослучайни числа. Ако намеря по-съвършен генератор, ще преизчисля всичко отново, но предполагам че няма да има кой-знае колко голяма разлика. Засега трябва да си имаме едно на ум, че някъде може и да има някаква минимална грешка от порядъка на 0.1%.
Въобще направата на идеален генератор на случайни числа е сложна математическа задача, която доколкото знам все още не е решена напълно от математиците и програмистите. Ако някой знае нещо повече по въпроса, нека да напише в темата и да даде линк към по-добър генератор.
От една страна трябва да е възможно екстремно бърз (с по-малко сметки, заради милионите и милиард опити при монте-карлото да кажем). а от друга страна се иска и да наподобява 'истинска" случайна величина, да няма повторяемост и прогнозируемост, да описва разпределението, моментите от първи и по-висок ред, и т.н. Предполагам всеки програмист е позачитал древната книга на Д. Кнут или подобен по-по-осъвременен курс алгоритми, където са упоменати някои такива кодове и проблематиката, Мисля, че японците имаха някакви достижения в насоката, но като цяло мисленето със случайности не е някак силата на човешката логика и вероятно и поставянето на въпроса за ползваният генератор е също актуален. В някои решения се ползват предварително генерирани числа в таблици (за да е максимално бързо изчислението), -числа взети от някакви шумотевици числено дискретизирани, В други случаи се предлагаха извадки на съответни цифри от трансендентни числа (знаем, че нямат точно представяне в реалната област или чрез числител/знаменател), макар, че и това изглежда малко съмнително, Храня съмнения, че тази математическа задача, както я нарекохте, дали изобщо може да се реши, Но е интересно какъв е кодът на ползваният генератор. Вероятно може да се подобриLast edited by precakanoto; 30.09.2019, 23:05.
Коментар
-
Първоначално изпратено от Mateev Разгледай мнениеКъде да си намеря такова устройство? Колко струва?
Някои компютри имат датчици за записване на определен шум в някоя от частите му – например температура или други стойности, които се смята, че са случайни в процеса на работа, не зависят от човека или машината.
В къщи имам един SBC (едноплатков компютър) Odroid U3, нищо особено, 67 долара преди няколко години, и той има тази възможност. Линукс записва стойностите на този хардуерен шум и ги събира в pool. Има някаква максимална скорост на събиране на шумови данни и ако ги изчерпиш по-бързо, вече не се смятат качествени случайните числа.
Май има и специализирани платки да ги сложиш в слот.
https://en.wikipedia.org/wiki/Hardwa...mber_generator
ПП: Не е малко вероятно твоите сървъри да имат такива генератори; много се използват в криптографията, то ест за криптирана сигурна връзка, https .Last edited by R1a1; 30.09.2019, 13:48.
Коментар
-
Първоначално изпратено от R1a1 Разгледай мнениеА хардуерен ГСЧ не може ли да използваш?
Коментар
-
За тези, на които им е любопитно, публикувам пълния комплект с първични файлове с дълбочината на всички Drawdown-и по всички вероятности от 50.1% до 99.9%, изчислени с различен брой сделки - от 100 до 1 милиард.
https://www.solar.sts.bg/files/Drawdowns.rar
Склонен съм да си мисля, че генератора на случайни числа, който съм използвал, не е съвършен и не дава идеално нормално разпределение, но то това е така с всички генератори на псевдослучайни числа. Ако намеря по-съвършен генератор, ще преизчисля всичко отново, но предполагам че няма да има кой-знае колко голяма разлика. Засега трябва да си имаме едно на ум, че някъде може и да има някаква минимална грешка от порядъка на 0.1%.
Въобще направата на идеален генератор на случайни числа е сложна математическа задача, която доколкото знам все още не е решена напълно от математиците и програмистите. Ако някой знае нещо повече по въпроса, нека да напише в темата и да даде линк към по-добър генератор.Last edited by Mateev; 30.09.2019, 12:06.
Коментар
-
Първоначално изпратено от shkata Разгледай мнение
Дай един мейл да ти го изпратя че тук нещо това за лични съобщения при мен не работи.
Коментар
-
Първоначално изпратено от Mateev Разгледай мнениеАз знам как може да се реши тази задача, но някой трябва да ми помогне с писането на софтуера, за да стане по-бързо. Например ако ми напишеш базовия софтуер, който да сканира диска и да качва в паметта един по един *.str файловете на хиляди стратегии, аз мога да допиша частта, която да прави подбор на най-добрите от тях по мои си критерии, по-добри от тези на SQ. Мога да направя например подбор по долната граница на доверителния интервал, което е много силен критерий, или по вероятността на Equity-то, която я обсъждахме през последните дни.
Коментар
-
Първоначално изпратено от Mateev Разгледай мнениеСметката за 1 милиард се смяташе цяла нощ. Сметката за 10 милиарда ще отнеме 1 седмица, и затова все още не съм я правил
Свалям предложението, щом е така, благодаря.
Коментар
-
Първоначално изпратено от R1a1 Разгледай мнениеВ таблицата се вижда нещо като линейна зависимост, позволяваща да се предскаже, че при 10 милиарда сделки MaxDD би бил 34-35.
Разбира се, това е възможностен извод, но изглеждащ твърде вероятен.
Тази зависимост означава нещо.
Покажи, моля, сметката за 10 млрд. за проверка....
Коментар
Коментар