Float для хранения цен достаточен? - страница 2
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Мысли были по поводу сокращения размеров файлов, в которые писались таймсерии.
Да, экспериментально у меня подтвердилась потеря точности (искажения) 5зн цен при двоичной записи/чтении в BIN файл в формате float.
А вот для хранения типа datetime вполне подошла uint, занимающая в 2 раза менье места. uint можно использовать еще 80 лет. Я столько не проживу 8)
Сталкивался ли кто-нибудь с проблемой потери точности при хранении цен в типе float ? Золото, например, в цене 1266,357 , уже занимает максимальные 7 знаков :( ... Охота уменьшить ширину хранения в файле, а морочиться с относительными приращениями (цены) не охота :)
Уменьшить размер файлов с курсами можно и без ведения базовых уровней и отклонений от них. Во float предусмотрен широкий размах величины индивидуально для каждого курса, а также возможность отрицательного знака, под эти не встречающиеся случаи впустую держатся 8 битов порядка и бит знака. На вариации собственно значения в мантиссе остается лишь 32-9=23 бита. Если перейти к беззнаковым целым путем умножения курса на миллион (на 10 тысяч для пар с иеной и золота), то для хранения курсов хватит трех байт (24 битов) на каждый (256^3=16 млн), с запасом на 6 разрядное котирование. Если речь о распространенных на форексе валютных парах. Для биткоина хуже.
Но это речь не о расчетных курсах открытия торговой позиции в случае неттингового учета в MT5, там можно встретить, например, деление на 3 и в итоге бесконечную дробь.Уменьшить размер файлов с курсами можно и без ведения базовых уровней и отклонений от них. Во float предусмотрен широкий размах величины индивидуально для каждого курса, а также возможность отрицательного знака, под эти не встречающиеся случаи впустую держатся 8 битов порядка и бит знака. На вариации собственно значения в мантиссе остается лишь 32-9=23 бита. Если перейти к целым путем умножения курса на миллион (на 10 тысяч для пар с иеной и золота), то для хранения курсов хватит трех байт (24 битов) на каждый (256^3=16 млн), с запасом на 6 разрядное котирование. Если речь о распространенных на форексе валютных парах. Для биткоина хуже.
для справки - sizeof(double)=8 байт, но при этом 1,08473 (текущий EURUSD с digits=5) в UTF8 = 7 байт включая разделитель.
в качестве транспортного кодирования, текст просто почти идеален. Он и человеко-читаем и компактен
Мысли были по поводу сокращения размеров файлов, в которые писались таймсерии.
Да, экспериментально у меня подтвердилась потеря точности (искажения) 5зн цен при двоичной записи/чтении в BIN файл в формате float.
А вот для хранения типа datetime вполне подошла uint, занимающая в 2 раза менье места. uint можно использовать еще 80 лет. Я столько не проживу 8)
Хотел было возразить, но в последний момент заметил дату начала исследований. Респект, 6 лет скрупулёзного анализа с ошеломляющим выводом, честно, не смог бы так.
Могу подкинуть идею на ближайшую пятилетку: 1 * 3 / 3 != 1 / 3 * 3, подозреваю, что столь же комплексное исследование в этом направлении золотыми буквами впишет имя изыскателя в программерскую летопись.
По моим дилетантским прикидкам (глупо идти против 6 летних исследований, не воспринимайте всерьёз) для float == 8, погрешность представления будет +- 4.768e-7, что, по-моему, вполне приемлемо для 5ти знака.
Да, экспериментально у меня подтвердилась потеря точности (искажения) 5зн цен при двоичной записи/чтении в BIN файл в формате float.
Да, это удивительно. Подтвердите, пожалуйста, конкретными фактами. Какое именно значение курса при 5-разрядном котировании не поместилось со всеми своими десятичными значащими цифрами во float?