Как наиболее Ъ занулить последние байты мантиссы для double и float?

ворнинги отключи.

а отнять это не достаточно быстро?

-epsilon>x-y>+epsilon

break strict-aliasing rules

Должно помочь __attribute__((__may_alias__))

double x

(long*)&x

Фу таким быть.

убрать влияние накопившейся машинной ошибки

Ты его не уберёшь, только добавишь ещё.

ворнинги отключи.

Можно еще голову под подушку спрятать.

а отнять это не достаточно быстро?

Нет, тем более что одним вычитанием там не обойдешься.

Гениально! Еще кажите чему эпсилон равняется В ОБЩЕМ СЛУЧАЕ.

Ты его не уберёшь, только добавишь ещё.

Таки оно работает.

Гениально! Еще кажите чему эпсилон равняется В ОБЩЕМ СЛУЧАЕ.

0x0000000000001111 = 2.1019476e-44

Показатель степени неизвестен тащем то.

При чём тут это? Вот. Число которое я привёл это четыре младших бита в 1.

Че то не очень...

O_O... а зачем указатель на указатель то???

Спасибо КО. Только сравниваемые числа могут быть порядка десять в дцатой (или десять в минус дцатой). Причем тут единица?

Упс. Ну убери их.

Что работает? Сравнение? Так оно на определённой выборке и в виде (long)x < long(y) будет работать! А вот ошибки никуда не денутся.

Можно еще голову под подушку спрятать

да у тебя и так там (long)double

наиболее Ъ это не делать такой быдлокод. Эпсилон в общем случае

e = ((A + B) >> 1) >> (2**s)

Ошибка это неизбежное зло. Мне нужно, что бы числа у которых различаются последние 16 бит мантиссы (за счет ошибки) считались при сравнении равными.

Я конечно понимаю, что ТС идиот, но таки не видеть отличий между (long)double и (long*)(double*) - это надо постараться.

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

/0

зря ты так делаешь.

Что такое A, B, s? В С нету операции **, побитовый сдвиг не поддерживается для плавающей точки.

Ну так юзай эпсилон же. Ты только добавляешь ещё ошибок, ну неужели это не очевидно?

зря ты так делаешь.

Да, ЛОР не то что не торт - ЛОР вообще скатился хрен-знает-во-что. Я что, где то у кого то спрашивал делать мне так или не делать?

А мнение анонимуса насчет того идиот я или нет меня вообще не интересует.

Куда добавляю? Ничего, что less принимает аргуметы по значению? Блин, анонимусы тоже пошли какие то тупые...

Ошибка это неизбежное зло.

ошибка — не зло. Это просто погрешность вычислений.

считались при сравнении равными.

зачем ты сравниваешь double?

Подумай немножко, прежде чем бред писать. Очевидно, что добавляешь только при сравнении (и они дальше не лезут), но тем самым делаешь сравнение ошибочным.

у него все в скобках с префиксным разыменованием, фактически double к long

зачем ты сравниваешь double?

Потому что мне нужно сравнивать double. Есть альтернативы?

зачем ты сравниваешь double?

Ну приехали... :)

Я знаю, что у меня последние 16 бит невалидные, а актуальные значение (которое должно сравниваться) лежит в первых скольки-то-там битах. Зачем мне сравнивать числа с учетом заведомо ошибочного хвоста? Кто из наc пишет бред?

http://gcc.gnu.org/onlinedocs/gcc-4.1.1/gcc/Optimize-Options.html#index-fstri... ?

Even with -fstrict-aliasing, type-punning is allowed, provided the memory is accessed through the union type.

Я уже боюся, не заразны ли идеи прокодера с фихед пойнт... как бы не началось.

О, спасибо... про union я и забыл;-(

Что такое A, B, s?

что, мне капитанить обязательно? A и B операнды сравнения, s желаемый порядок загрубления сравнения. Второй сдвиг просто на s, не на (2**s). Т.е. ддя твоих желаемых 16и будет примерно 36.

побитовый сдвиг не поддерживается для плавающей точки.

man ldexp(), fpu это делать умеет.

ещё от знака нужно избавиться у A и B

Есть нюанс - это будет гораздо медленней, чем снести последние биты.

Есть нюанс - это будет гораздо медленней, чем снести последние биты.

хз как это заоптимизирует компилятор, лень сравнивать. Но по крайней мере этот вариант правильный в отличие от твоего подхода. Ты же не знаешь какой размер будет у типа double - с/с++, афаик, не обещают что это будет double из ieee754

Черт... да, это убедительно, я ступил;-( Спасибо!

Ну, под целевую архитектуру я размеры всех типов знаю... но анонимус тут привел пример когда нулить хвост мантиссы низя;-(

В общем как то так вышло:

inline bool less(double x, double y) {
	int px, py; frexp(x, &px); frexp(y, &py);	
    return y-x >= ldexp(1., (px<py?px:py)-40);
}

Прочит тему - так и не понял, что за фигня - вы long=4байта, double=8 байт, приводя указатель вы используете первые 4 байта от double.

Не проще умножить->каст->поделить.

А почему нигде нет fabs? Y больше X потому что флюгер прибит гвоздями и ветер дует в заданную сторону?

Деление ОЧЕНЬ дорогая операция.

PS у меня long 8 байт.

Y больше X потому что флюгер прибит гвоздями и ветер дует в заданную сторону?

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

это всё отлично, посмотрев ещё раз на код, но всё же, как мне пауки в голове говорят, >= надо поменять на >.

Что за процессор если не секрет?:)

самые разные х86. На 64 битах лонг обычно 8 байт таки, инт 4, шорт 2.

С удивлением узнал что на рабочей машине стоит 32битная убунта:-D

А так да, long 64bit, хотя сам стараюсь везде писать uint64_t или int64_t если нужно именно 64

Вот интересно, случай, когда мантиссы вида (укороченные)

1100 0000 0000 0001

1011 1111 1111 1111

ТС не волнует? То есть разница чисел в пару единиц младшего разряда, но при этом различаются старшие разряды. При обнулении младших бит разница будет возрастать, а не уменьшаться.