информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
Страшный баг в WindowsПортрет посетителяГде водятся OGRы
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Три миллиона электронных замков... 
 Doom на газонокосилках 
 Умер Никлаус Вирт 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / humor
Имя Пароль
ФОРУМ
если вы видите этот текст, отключите в настройках форума использование JavaScript
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
куркулятор выдал: DB2DCD57C0000000 (P4, XP_SP2) 08.08.05 15:57  Число просмотров: 1609
Автор: Deviator <n/a> Статус: Member
<"чистая" ссылка>
<humor>
или я ничего в арфметике не понмаю, или одно из двух 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
<"чистая" ссылка>
1




Rambler's Top100
Рейтинг@Mail.ru


  Copyright © 2001-2024 Dmitry Leonov   Page build time: 0 s   Design: Vadim Derkach