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





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
скажи наркотикам "иногда"! 08.08.05 15:31  Число просмотров: 1580
Автор: NKritsky <Nickolay A. Kritsky> Статус: Elderman
<"чистая" ссылка>
<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: 1 s   Design: Vadim Derkach