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

>В конце-концов double нельзя сравнивать,
>double непредсказуемо ведёт себя при сравнении на равенство.

А сдаётся мне, что если на входе целые числа, исходные данные
и промежуточные результаты не более 2^52,
то все вычисления на Double будут производиться точно.

А если взять Extended, то можно поднять верхнюю планку точности до 2^63.

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

W>А если взять Extended, то можно поднять верхнюю планку точности до 2^63.
нет такого типа на этом компилере The representation of long double and double is identical. However, long double and double are separate types.

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

W>>А если взять Extended, то можно поднять верхнюю планку точности до 2^63.
P>нет такого типа на этом компилере The representation of long double and double is identical. However, long double and double are separate types.

если Вы посмотрите, то форум С/C++, и не надо о ограничениях конкретного компилятора.

ps
в русском языке нет слова "компилер", "компилиться" и тп

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

СМ>если Вы посмотрите, то форум С/C++, и не надо о ограничениях конкретного компилятора.

Исходный пост про VC6. Но если гуи у автора нет, то перенести не долго

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

W>>>А если взять Extended, то можно поднять верхнюю планку точности до 2^63.
P>>нет такого типа на этом компилере The representation of long double and double is identical. However, long double and double are separate types.

СМ>если Вы посмотрите, то форум С/C++, и не надо о ограничениях конкретного компилятора.

Если так рассуждать, то придется признать что и double может быть не только IEEE 754...

Прикольно люди Микрософт лечат http://www.rsdn.ru/Forum/Message.aspx?mid=922025&only=1

Автор: adontz
Дата: 29.11.04

__declspec(align(2)) class long_double
    {
        private:
            unsigned char data[10];
        public:
            __forceinline long_double()
                {
                    __asm FLdZ;
                    __asm Mov ECX, this;
                    __asm FStP TBYTE PTR [ECX];
                }
            __forceinline 
................................
__asm 
__asm 
__asm 
__asm 
.................................

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


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

Не, мужчина, вы вообще не свои посты читаете?

В оригинале рассказывали что-то о вычислениях "с неотрицательными целыми".
Я всё пытаюсь обратить твоё драгоценнейшее внимание на то, что double немного не под то заточен.
Ты всё правильно пишешь, что для double интересоваться точным равенстовм странно. Но для целых-то не странно, а наоборт естественно
Так что если ты для реализации операций над целыми, которые надо ещё и сравнивать, заюзаешь double возможны трудности.
Они конечно не непреодилимые, но на борьбу с ними потребуется тратить производительность...


E>>Чтобы ты наконец понял о чём биш то я, я тебе приведу задачу.
Видимо не помогло. Попробуй ещё раз. Ключевое слов я выделил!

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

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

SWW>Но в реальной задаче скорее всего сравнивать на равенство будет бессмысленно так как точное равенство будет встречатьс крайне редко, а заказчика вероятно устроило бы и равенство с погрешностью, а ты его мне не задал.

интересно бы узнать откуда это следует? Числа-то целые. Пусть даже ограниченные по модулю числом 10 000 000.

В общем я человек простой, с русским у меня непросто всё.
Не могёшь на С++ написать ответ?

пусть у тебя есть мегафункция

int getNextValue()

Которая возвращает последовательность целых чисел. И надо указать порядковые номера границ искомого подмассива.

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

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

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

казалось бы...
Тут вроде и обсуждают что будет, если целочисленные вычисления по каким-то соображениям делать через double...

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

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

И тебе, мил человек, задача:

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

int getNext()

первый вызов возвращает 1-й элемент массива, второй -- 2-й и т. д..

ОТвет желательно на C++
через __int64 и через double.
Потом смотрим и сравниваем что увидили....

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

W>А сдаётся мне, что если на входе целые числа, исходные данные
W>и промежуточные результаты не более 2^52,
W>то все вычисления на Double будут производиться точно.

W>А если взять Extended, то можно поднять верхнюю планку точности до 2^63.

В целом никто не обещал, хотя скорее всего так и будет конечно, но вдруг значение всегда нормализуют?
Кроме того, если просто вязть и использовать __int64 (о котором и спросили, собственно), то сразу бужем иметь границу в 2^63 или даже 2^64 вообще без извратов совместимо и гарантированно

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

E>И тебе, мил человек, задача:

мне трудно понять, человек, который путает int & size_t, который говорит, что double не сравниваются, мне будет задачки давать? Бред

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

СМ>мне трудно понять, человек, который путает int & size_t, который говорит, что double не сравниваются, мне будет задачки давать? Бред

Выделенное -- это конечно печально. Но попробуй сконцентрироваться
И если ты уже постучал по столу всем чем хотел и крепость ствола демонстрировать закончил, то попробуй не переходить на личности, а пояснить можно или нельзя сравнивать double в рамках предложеной задачи (она как раз такая, как в стартовом сообщении темы. ПРо большое число целых чисел, которые надо складывать и сравнивать)

Потому что я не знаю как объяснить понятнее

И. Т. Егор.
p. s.
А как ты узнал, что я "путаю" size_t и int? Их очень просто отличить, например по позиции буквы "i" в названии типа

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

E>Дан большой (скажем 1е9) массив целых чисел (пусть знаковых)

Не пусть, а именно знаковых. Иначе ответ будет — [0;1e9)

E>Нужно найти идущий подряд подмассив этого массива с максимальной суммой элементов.

E>При этом из всех подмассивов с одиниковой суммой выбрать тот, у которого самая маленькая левая граница.
E>А из всех подмассивов с совпадающей левой границей надо выбрать тот, у которого правая граница расположена левее всего.

Проще сказать, выбрать крайне левый (или первый попавшийся, если алгоритм потоковый).

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

Спасибо за этюд, в таком ракурсе я над этой задачей не сталкивался...
То есть, наша задача — не просто найти такой массив, но ещё и побороться с переполнениями и округлениями.

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

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

Я что-то пропустил в мире ИТ? С каких это пор числа с плавающей точкой обрабатываются быстрее целочисленной арифметики?

Здравствуйте, Аноним, Вы писали:

А>Я что-то пропустил в мире ИТ? С каких это пор числа с плавающей точкой обрабатываются быстрее целочисленной арифметики?
Тема про 32-х разрядную платформу. Вполне возможно изза памяти — шина шире и регистров для пар по 32 может не хватать, прийдется промежуточные в памяти заводить.

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

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

А как реализован _int64 в VC-6, вот если через MMX (нам же флоаты не нужны), то вопросом просто и быть не должно, если нет — сделайте сами...

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

К>Спасибо за этюд, в таком ракурсе я над этой задачей не сталкивался...
К>То есть, наша задача — не просто найти такой массив, но ещё и побороться с переполнениями и округлениями.

Точно так.
Правда этюд так себе.
Так как 1е9 мало, чтобы переполнить int64 складывая int32
А вот с double уже веселее всё будет

Здравствуйте, <Аноним>, Вы писали:

А>Я что-то пропустил в мире ИТ? С каких это пор числа с плавающей точкой обрабатываются быстрее целочисленной арифметики?

С тех пор, как 32х битные процессоры научились умножать и делить 64 битные целые.

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

VEA>Как на С++
VEA>

VEA>adc op1,1 
VEA>

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

Использовать компилятор с поддержкой 64 битных целых.

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

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

VEA>>Как на С++
VEA>>

VEA>>adc op1,1 
VEA>>

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

GN>Использовать компилятор с поддержкой 64 битных целых.

Ну это я написал неправильно прочтя исходный пост (думал о очень длинных целых (много много слов), а не о длинных циклах).