Для обработки статистических данных требуется производить операции (в очень длинных циклах) сложения и сравнения над большими неотрицательными целыми числами, возникает вопрос — как лучше с этими числами работать (с точки зрения повышения производительности) как _int64 или double? Компилятор VC-6, платформа — x86 WinXP.

Здравствуйте, Alexzy, Вы писали:

A>Для обработки статистических данных требуется производить операции (в очень длинных циклах) сложения и сравнения над большими неотрицательными целыми числами, возникает вопрос — как лучше с этими числами работать (с точки зрения повышения производительности) как _int64 или double? Компилятор VC-6, платформа — x86 WinXP.

1. Выкиньте компилятор
2. Premature optimization is the root of all evil
3. Intel любят double, AMD любят int (могу, впрочем, и ошибаться)
4. Что-то мешает сделать typedef и потом устроить бенчмарк?

Здравствуйте, Alexzy, Вы писали:

A>Для обработки статистических данных требуется производить операции (в очень длинных циклах) сложения и сравнения над большими неотрицательными целыми числами, возникает вопрос — как лучше с этими числами работать (с точки зрения повышения производительности) как _int64 или double? Компилятор VC-6, платформа — x86 WinXP.

А в чём чила даны изначально?

Вообще-то, насколько я понимаю, double на современных процах лучше. Но возможны варианты.
В любом случае можешь ли ты оценить вероятность переполнения?
В конце-концов double нельзя сравнивать, а __int64 нельяз переполнять. Что важнее?

ИМХО лучше всего правильно складывать. (например иерархически)

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

Здравствуйте, Alexzy, Вы писали:

A>Для обработки статистических данных требуется производить операции (в очень длинных циклах) сложения и сравнения над большими неотрицательными целыми числами, возникает вопрос — как лучше с этими числами работать (с точки зрения повышения производительности) как _int64 или double? Компилятор VC-6, платформа — x86 WinXP.

Целые? положительные? значит int64. А если есть, то unsigned int64.
Только за переполнением следи.

Здравствуйте, Nose, Вы писали:

N>Целые? положительные? значит int64. А если есть, то unsigned int64.
N>Только за переполнением следи.

Как на С++

adc op1,1

(и иже с ними) провернуть без проверок?

Здравствуйте, Erop, Вы писали:

E>В конце-концов double нельзя сравнивать,

Что за глупости?

Здравствуйте, SWW, Вы писали:

SWW>Здравствуйте, Erop, Вы писали:

E>>В конце-концов double нельзя сравнивать,

SWW>Что за глупости?

Здравствуйте, SWW, Вы писали:

E>>В конце-концов double нельзя сравнивать,
SWW>Что за глупости?

double непредсказуемо ведёт себя при сравнении на равенство. Соответственно, если алгоритм предполагает какие-то сравнения на равенство (скажем, если сумма этих 1000 элементов равнв сумме той 1000), то double использовать сложнее...

А что касается глупостей, то я не знаю. Ты их где-то нашёл, тебе и виднее что за глупости

Здравствуйте, Erop, Вы писали:

E>>>В конце-концов double нельзя сравнивать,
SWW>>Что за глупости?

E>double непредсказуемо ведёт себя при сравнении на равенство.

Во-первых, было написано "нельзя сравнивать". Про сравнение на равенство ничего не не было.

E>Соответственно, если алгоритм предполагает какие-то сравнения на равенство (скажем, если сумма этих 1000 элементов равнв сумме той 1000), то double использовать сложнее...

А во-вторых, при определенных ситуациях можно сравнивать и на равенство. Не результаты подобных вычислений, разумеется, но в определенных случаях можно.

Здравствуйте, SWW, Вы писали:

SWW>Во-первых, было написано "нельзя сравнивать". Про сравнение на равенство ничего не не было.
SWW>А во-вторых, при определенных ситуациях можно сравнивать и на равенство. Не результаты подобных вычислений, разумеется, но в определенных случаях можно.

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

А что касается "глупостей" из твоего сообщения, то я с его источником определился Спасибо и на этом.

Здравствуйте, Erop, Вы писали:

SWW>>Во-первых, было написано "нельзя сравнивать". Про сравнение на равенство ничего не не было.

E>Ты, мил человек, русский хорошо знаешь? Я писал ответ человеку, вполне в контексте. Думаю, что там всё понятно написано.

Для обработки статистических данных требуется производить операции (в очень длинных циклах) сложения и сравнения над большими неотрицательными целыми числами

В конце-концов double нельзя сравнивать,

Человек пишет что требуется сравнение. Ты утверждаешь, что double сравнивать нельзя. В этом контексте могу заявить только одно: ты не прав, так как сравнивать их можно. А то, что требуется сравнение на равенство нигде не написано. Не говоря уже о том, что в определенных ситуациях можно сравнивать и на равенство.

Здравствуйте, SWW, Вы писали:
SWW>Человек пишет что требуется сравнение. Ты утверждаешь, что double сравнивать нельзя. В этом контексте могу заявить только одно: ты не прав, так как сравнивать их можно. А то, что требуется сравнение на равенство нигде не написано. Не говоря уже о том, что в определенных ситуациях можно сравнивать и на равенство.


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

Короче разные алгоритмы.

Чтобы ты наконец понял о чём биш то я, я тебе приведу задачу.

Дан большой (скажем 1е9) массив целых чисел (пусть знаковых)
Нужно найти идущий подряд подмассив этого массива с максимальной суммой элементов.
При этом из всех подмассивов с одиниковой суммой выбрать тот, у которого самая маленькая левая граница.
А из всех подмассивов с совпадающей левой границей надо выбрать тот, у которого правая граница расположена левее всего.

приведи решение с даблами и с длинными целыми, пжлст

Здравствуйте, Erop, Вы писали:

E>Здравствуйте, SWW, Вы писали:

E>>>В конце-концов double нельзя сравнивать,
SWW>>Что за глупости?

E>double непредсказуемо ведёт себя при сравнении на равенство. Соответственно, если алгоритм предполагает какие-то сравнения на равенство (скажем, если сумма этих 1000 элементов равнв сумме той 1000), то double использовать сложнее...

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

E>А что касается глупостей, то я не знаю. Ты их где-то нашёл, тебе и виднее что за глупости

я согласен с SWW

Здравствуйте, Erop, Вы писали:

E>вообще говоря у целых чисел, сравнение на больше подразумевает исравнение на неравенство.
E>То есть если ты знаешь, что одно целое меньше другого, то ты знаешь, что они не равны. А если ты сравниваешь даблы, и выяснил что один меньше другого, то ты не знаешь равны ли они

Если я выяснил, что один меньше другого, то я могу однозначно утверждать, что они не равны.
Вот если я выяснил, что один не меньше другого — то да, он может быть больше или равен.

E>(так как равенство надо проверять хитро, с относительной погрешностью или ещё как )

Зависит от природы задачи. Вообще, мне как-то не встречались задачи, в которых double приходилось бы сравнивать на равенство. Ведь когда в вычислениях используются double, то ими кодируются какие-то "аналоговые" величины, а их сравнивать на равенство бессмысленно. Если и приходится сравнивать с относительной погрешностью, то по причине "аналоговости" этой величины, а не потому что double нельзя сравнивать на равенство. Но ведь могут быть особые, "искусственные", случаи — например функция возвращает результат вычислений или 0 когда вычисления по какой-то причине провести не удалось (разумеется если 0 не может быть результатом). То есть, одно из значений просто используется в качестве флага. В таком случае можно совершенно безопасно написать return 0; и проверять if(f() == 0).

E>Чтобы ты наконец понял о чём биш то я, я тебе приведу задачу.
E>Дан большой (скажем 1е9) массив целых чисел (пусть знаковых)
E>Нужно найти идущий подряд подмассив этого массива с максимальной суммой элементов.
E>При этом из всех подмассивов с одиниковой суммой выбрать тот, у которого самая маленькая левая граница.
E>А из всех подмассивов с совпадающей левой границей надо выбрать тот, у которого правая граница расположена левее всего.
E>приведи решение с даблами и с длинными целыми, пжлст

Поскольку задача искусственная, то и подходить к ее решению можно формально
if(s1 > s2) то выбираем s1 так как он больше.
else if(s1 == s2) то сравниваем их левые границы.
Но в реальной задаче скорее всего сравнивать на равенство будет бессмысленно так как точное равенство будет встречатьс крайне редко, а заказчика вероятно устроило бы и равенство с погрешностью, а ты его мне не задал.

Здравствуйте, Сергей Мухин, Вы писали:

СМ>абсолютно предсказуемо, процессор не датчик случайных чисел!
СМ>т.е. если есть два 8битных плавающих, то результат сравнения предсказуем.

Если даны флаги процессора, опции типа /Op Improves floating-point consistency то результат предсказуем. Точнее говоря можно, но очень осторожно. Переполнение не возникает, но потеря точности наступит раньше.


Дорого стоит преобразование из унсигнед в флоат. Также дорого флоат — целое, если без опции QIfist Suppresses the call of the helper function _ftol when a conversion from a floating-point type to an integral type is required Вроде SSE2 тоже можно задействовать, но не знаю

Здравствуйте, SWW, Вы писали:

SWW>Поскольку задача искусственная, то и подходить к ее решению можно формально
Вот например геометрия разная очень веселая бывает. Лежит ли например точка на прямой ? или просто мышкой чуть-чуть рядом ткнули.

Здравствуйте, Programador, Вы писали:

SWW>>Поскольку задача искусственная, то и подходить к ее решению можно формально
P>Вот например геометрия разная очень веселая бывает. Лежит ли например точка на прямой ? или просто мышкой чуть-чуть рядом ткнули.

Казалось бы, при чем тут double? Все пикселы имеют целочисленные координаты.

У меня была программа, которая рисовала некие графики, и при наведении курсора на график выводился тултип со значением графика в этой точке. Там приходилось задавать погрешность, с какой нужно было попасть на график. Но вычисления там были целочисленными!

Здравствуйте, SWW, Вы писали:

Попал — не попал это простой случай. А как Вам операция обьединения полигонов?

Здравствуйте, SWW, Вы писали:

SWW>Здравствуйте, Programador, Вы писали:

SWW>>>Поскольку задача искусственная, то и подходить к ее решению можно формально
P>>Вот например геометрия разная очень веселая бывает. Лежит ли например точка на прямой ? или просто мышкой чуть-чуть рядом ткнули.

SWW>Казалось бы, при чем тут double? Все пикселы имеют целочисленные координаты.
Пиксили-то целочисленные, а все вычесления, в компьютерной графике — в double, и только в самом конце округляются при выводе на девайс. Ради эксперимента, попробуй потрансформировать какую-нибудь векторную фигуру используя целочисленные матрицы

SWW>У меня была программа, которая рисовала некие графики, и при наведении курсора на график выводился тултип со значением графика в этой точке. Там приходилось задавать погрешность, с какой нужно было попасть на график. Но вычисления там были целочисленными!
Это только для самых простейших вариантов подходит. Ты такому графику даже зум не сможешь сделать, ну разве что кратный двум.

Здравствуйте, Programador, Вы писали:

P>Здравствуйте, SWW, Вы писали:

P>Попал — не попал это простой случай. А как Вам операция обьединения полигонов?

Только хотел про GPC вспомнить и совершенно замечательные решения. Кстати есть там и куски которые на равенство плавающие числа сравнивают ,о конечно иони полученны из одного источника.