Легенда:
новое сообщение
закрытая нитка
новое сообщение
в закрытой нитке
старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
или я ничего в арфметике не понмаю, или одно из двух 08.08.05 13:17
Автор: whiletrue <Роман> Статус: Elderman Отредактировано 08.08.05 13:18 Количество правок: 1
|
В виндах: в вижула сях, в 1С, в некоторых SQL и через раз в калкуляторе (особенно если в десятичном виде считать)
DB2DCD5700000000
+
000000000C0000000
=
DB2DCD56C0000000 !!!
Почему?!
|
|
Вот почему [upd: очепятки] 08.08.05 17:17
Автор: leo <Леонид Юрьев> Статус: Elderman Отредактировано 08.08.05 17:22 Количество правок: 3
|
> В виндах: в вижула сях, в 1С, в некоторых SQL и через раз в > калкуляторе (особенно если в десятичном виде считать) > > DB2DCD5700000000 > + > 000000000C0000000 > = > DB2DCD56C0000000 !!! > > Почему?!
В "неправильно" считающих системах это будет соответствовать С-коду:
int m_h = -617755305; // == 0xdb2dcd57;
int m_l = -1073741824; // == 0xc0000000;
__int64 mantissa = (((__int64)m_h) << 32) + (__int64) m_l; // -2653238832979247104 == 0xdb2dcd56c0000000 ---
В "правильно" считающих системах это будет соответствовать С-коду:
unsigned int m_h = 3677211991; // == 0xdb2dcd57;
unsigned int m_l = 3221225472; // == 0xc0000000;
unsigned __int64 mantissa = (((unsigned __int64)m_h) << 32) + (unsigned __int64) m_l; // 15793505245025271808 == 0xdb2dcd56c0000000 ---
Или, другими словами, знаковое расширение 0xc0000000 до 64 бит дает -1 в старшей половине, поэтому из 7 получается 6. Если расширение беззнаковое, то результат вычисляется "правильно".
|
| |
Сработало! Спасибо. А если язык не дает задавать жестко тип - то "нормализовать" до положительных.... Danke Schoen! 08.08.05 18:13
Автор: whiletrue <Роман> Статус: Elderman Отредактировано 08.08.05 18:16 Количество правок: 1
|
|
|
куркулятор выдал: DB2DCD57C0000000 (P4, XP_SP2) 08.08.05 15:57
Автор: Deviator <n/a> Статус: Member
|
|
| |
а у меня тоже щас нормально выдает... но прога однозначно неправильно пашет (см. ниже) 08.08.05 15:59
Автор: whiletrue <Роман> Статус: Elderman
|
|
|
скажи наркотикам "иногда"! 08.08.05 15:31
Автор: NKritsky <Nickolay A. Kritsky> Статус: Elderman
|
|
| |
[upd] я сам сомневаюсь за свой рассудок! Но почему в некоторых прогах ТАК считается? 08.08.05 15:41
Автор: whiletrue <Роман> Статус: Elderman Отредактировано 08.08.05 15:52 Количество правок: 2
|
типа вот так:
int m_h = 0xdb2dcd57;
int m_l = 0xc0000000;
__int64 mantissa = (__int64(m_h) << 32) + __int64(m_l);
mantissa = 0xdb2dcd56c0000000
Совсем, чтоли туплю?!
|
| | |
Народ, а че у всех эта прога правильно работает?! 08.08.05 17:06
Автор: whiletrue <Роман> Статус: Elderman
|
|
| | |
У тебя там в проге сдвиги побитовые... На Intel могут криво работать — смотри ветку 08.08.05 17:00
Автор: HandleX <Александр М.> Статус: The Elderman Отредактировано 08.08.05 17:02 Количество правок: 1
|
Кривизна
|
| | | |
Если заменить на умножить - эффект тот же, хотя она, наверняка оптимизируется... 08.08.05 17:08
Автор: whiletrue <Роман> Статус: Elderman
|
|
| | | | |
Да, умножения/деления на степени двойки наверняка оптимизируются... Будьте аккуратнее со сдвигами! ;-) 08.08.05 17:20
Автор: HandleX <Александр М.> Статус: The Elderman Отредактировано 08.08.05 17:20 Количество правок: 1
|
|
| | | | | |
А вообще, leo прав — замени int на dword или uint, всё заработает правильно. По крайней мере, у меня в дельфях так ;-) 08.08.05 17:37
Автор: HandleX <Александр М.> Статус: The Elderman Отредактировано 08.08.05 17:44 Количество правок: 5
|
Правильный вариант:
Var
m_h, m_l: DWORD;
mantissa: INT64;
begin
m_h := $db2dcd57;
m_l := $c0000000;
mantissa := (Int64(m_h) SHL 32) + m_l;
Caption := '$' + IntToHex(Mantissa, 16);
End;
---
Неправильный вариант:
Var
m_h, m_l: Integer;
mantissa: INT64;
begin
m_h := $db2dcd57;
m_l := $c0000000;
mantissa := (Int64(m_h) SHL 32) + m_l;
Caption := '$' + IntToHex(Mantissa, 16);
End;
[Warning] Unit1.pas(31): Constant expression violates subrange bounds
[Warning] Unit1.pas(32): Constant expression violates subrange bounds
---
Видно, что компилер ругается на присвоение констант в коде к целым знаковым переменным, говоря, что константы выходят за границы диапазона типа Integer.
|
| | |
Странно... 08.08.05 15:46
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman Отредактировано 08.08.05 15:48 Количество правок: 1
|
Похоже не программа виновата, если на разных то же самое.
А с другими парами чисел то же самое?
А что за процессор? На другом процессоре то же самое? Если не софт, то надо проверить проц. Многие с ходу припомнят ошибки в процах, которые уже были. И косинус, и при делении определенных чисел, и зависание f0 0f c4 c8, и многие другие.
Хотя все может быть очень даже банально - окислившийся контакт в слоте/сокете, подбитый транзистор в регистре/кеше/памяти, просто брак отдельного экземпляра.
|
| | | |
Я так понял - это на стыке как раз двух 32-х разрядных чисел, если самый младший бит первого числа =1 08.08.05 15:54
Автор: whiletrue <Роман> Статус: Elderman Отредактировано 08.08.05 15:58 Количество правок: 1
|
|
| | | | |
То, что это какой-то глюк стыковки многоразрядных чисел - похоже, причины - не знаю. 08.08.05 16:05
Автор: Deviator <n/a> Статус: Member
|
|
| | | | | |
Вот на 1С... 08.08.05 16:10
Автор: whiletrue <Роман> Статус: Elderman
|
m_h = 3677211991; //DB2DCD57
m_l = 3221225472; //C0000000
mantissa = m_h * 4294967296 + m_l;
дома не правильно выдает (но там версия ее чуть другая), а на работе правильно...
я щас повешусь!
|
| | | |
На домашней и на рабочей. Процы Intel Celeron и тоже Celeron 08.08.05 15:50
Автор: whiletrue <Роман> Статус: Elderman
|
|
|
|