Немного удивлен :) Решил поделиться и задать НЕ риторический вопрос. - страница 21
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Легко перескакиваете с одного неудавшегося утверждения на другое.
Вот когда у Вас будет процессор с рациональными типами данных и когда очередной набор команд SSExxx сможет с ними работать быстрее double, тогда и сможете прилинковать рациональные числа к обсуждению темы ускорения расчетов. Когда опубликуете тесты расчета SMA разными методами и покажете победу над double, тогда это будет речь практика.
А пока исходное утверждение об ускорении реальных математических расчетов при переходе на целые числа провалено.
Вы чего ?! Я НИКУДА не перескакивал. Если вы читаете только половину. То увы. Я про рациональные цисла раз двадцать уже сказал. Но вот пока носом не ткнул что это дроби, ни у кого понимание не пришло. :) Я же говорю - смешно. Увы. :(
:) Проваленно - я говорил про целые числа и понятия ПОИНТ, а поинт это и есть знаменатель всегда. 13000 пунктов если пункт равен 10000 - то величина равна = 13000/10000 = 1.3 :)
Вы чего ?! Я НИКУДА не перескакивал. Если вы читаете только половину. То увы. Я про рациональные цисла раз двадцать уже сказал. Но вот пока носом не ткнул что это дроби, ни у кого понимание не пришло. :) Я же говорю - смешно. Увы. :(
:) Проваленно - я говорил про целые числа и понятия ПОИНТ, а поинт это и есть знаменатель всегда. 13000 пунктов если пункт равен 10000 - то величина равна = 13000/10000 = 1.3 :)
Те вы предлагаете вместо 8 байтового дубля обрабатывать три 8 байтовых лонга (целочисленная часть + знаменатель + числитель), памяти не хватит такую махину тянуть. А начнёте урезать лонги на чтото более шортовое получите переполнение на вполне адекватных расчётах.
Даже три инта и те больше одного дубля.
Те вы предлагаете вместо 8 байтового дубля обрабатывать три 8 байтовых лонга (целочисленная часть + знаменатель + числитель), памяти не хватит такую махину тянуть. А начнёте урезать лонги на чтото более шортовое получите переполнение на вполне адекватных расчётах.
Вы выбрали самый плохой способ реализации. С учетом того что вы мне наговорили - не стыкуется. Кто из нас лучше знает?
Есть число в километрах - это int32 И не надо ему ничего больше. Просто не надо его складывать с величиной в другой размерности. :) Хотите большей точности чем километры - перейдите на нанометры. :) И храните их в целом числе. :)
TheXpert:
А во-вторых сильно сомневаюсь, что арифметика с double медленней, чем с рациональными числами.
Вапчета медленнее. Только ссылку он привёл неудачную.
1. Реализация в BOOST нормализует рац. числа при каждой операции с ними. Это необязательно делать на каждой, ибо дорого. Лучше делать только при реальной угрозе переполнения знаменателя.
2. Приведение к общему знаменателю (точнее, вычисление наибольшего общего делителя) там сделано не по самому быстрому алгоритму. На сегодняшний день есть быстрее.
С поправкой на сказанное он прав в отношении скорострельности рац. чисел.
Я б их на mql забацал, ежли б перезагрузка арифметических операций была. А без её - нудный очень синтаксис получается (функциональный), так что ну её в... С++ :-)
--
А вот действительно классно было б, ежли б на уровне процессора поддержка появилась...
Вапчета медленнее. Только ссылку он привёл неудачную.
1. Реализация в BOOST нормализует рац. числа при каждой операции с ними. Это необязательно делать на каждой, ибо дорого. Лучше делать только при реальной угрозе переполнения знаменателя.
2. Приведение к общему знаменателю (точнее, вычисление наибольшего общего делителя) там сделано не по самому быстрому алгоритму. На сегодняшний день есть быстрее.
С поправкой на сказанное он прав в отношении скорострельности рац. чисел.
Я б их на mql забацал, ежли б перезагрузка арифметических операций была. А без её - нудный очень синтаксис получается (функциональный), так что ну её в... С++ :-)
--
А вот действительно классно было б ежли б на уровне процессора поддержка появилась...
Сама арифметика медленнее потому что приходится ещё обрабатывать плавающую запятую (это если сравнивать чистую арифметику дубля и лонга), если же дубли переводить в целочисленную арифметику проиграешь. Одно только рекурентное вычисление НОД потребует log(N) операций, не говоря уже о том что на каждую операцию умножения потребуется if для проверки переполнения. Потом ещё 4 деления (два на НОД и для выделения целочисленной части и дробного остатка).
Плюс ко всему этому всё равно нужно будет выделить больше памяти для хранения всей этой ахинеи чем нужно для дубля.
Вапчета медленнее. Только ссылку он привёл неудачную.
Пруф? Вы конечно в моих глазах поавторитетней топикстартера, но заявление сильное.
Посему хотелось бы увидеть сравнительные тесты.
Сама арифметика медленнее потому что приходится ещё обрабатывать плавающую запятую (это если сравнивать чистую арифметику дубля и лонга),
1. если же дубли переводить в целочисленную арифметику проиграешь.
2. Одно только рекурентное вычисление НОД потребует log(N) операций, не говоря уже о том что
3. на каждую операцию умножения потребуется if для проверки переполнения.
4. Потом ещё 4 деления (два на НОД и для выделения целочисленной части и дробного остатка).
5. Плюс ко всему этому всё равно нужно будет выделить больше памяти для хранения всей этой ахинеи чем нужно для дубля.
1. Это однократная операция для каждого дубля. Проигрыш незначительный, затем сплошные выигрыши. :) Предполагаю, что исходный котир однократно логарифмируется и переводится в целочисленное представление.
2. Это верно. Хотя и быстро, ибо есть шустрый алгоритм использующий битовые сдвиги.
3. не больше чем проверок на переполнение лонгов.
4. целочисленную часть выделять совсем не нужно. дробь хранится как пара лонгов. а при возможности - как пара интов.
5. ровно столько же, если хранить как пару лонгов, и вдвое меньше в случае, если достаточно интов (это от требовательности алгоритма зависит).
Если учесть, что основной потребитель памяти - котировки, то при целочисленном представлении выигрыш по пространству неоспоримый.
При том, что основная фишка вовсе не в экономии памяти, а в ускорении. Это куда важнее.
--
С Академиком проблема не в том, что он неправ. А в том, что выставляет других неправыми.
Это и вызывает раздражение присутствующих и отторжение здоровых идей... вместе с грязной водой... :(
Посему хотелось бы увидеть сравнительные тесты.
Я попробую. На mql5, ежли уж пошла такая пьянка... :)
Время только понадобится. Библиотечку написать придётся.
Я попробую. На mql5, ежли уж пошла такая пьянка... :)
Да зачем? С++ принимается.
С Академиком проблема не в том, что он неправ. А в том, что выставляет других неправыми.
Проблема в том, что он считает себя умнее других и постоянно пытается выставить кого-то дураком.
При этом лажает. Местами сильно.
С Академиком проблема не в том, что он неправ. А в том, что выставляет других неправыми.
Это и вызывает раздражение присутствующих и отторжение здоровых идей... вместе с грязной водой... :(
Я никому в голову не лезу. Но ко мне инверсно. :) Кто кого звал с советами "не пойти ли мне с темой?" :)
А то что уже потом я - :) Ну дак нефиг и ко мне.
Да какая разница то в целом? - Что тут вообще можно обсуждать? ИМХО - все осталось на том же зачаточном уровне как и было. Так что нет никакой проблемы со мной - меня как бы нет. :)