сравнение площадей

Question

Столкнулась с какой-то чепухой при элементарном сравнении площадей полигонов и не могу разобраться в чем тут дело. Может кто-то сталкивался с чем-то подобным? Подскажите, пожалуйста.

Создаю поле 10.4 из area/10000, чтобы отсечь лишнюю значность.Выделяю по определенному признаку, получаю суммарную площадь группы (2 записей порой достаточно), хоть по statistic. Сравниваю непосредственно это число (забиваю его в программу для теста) с вновь посчитанной в программе площадью группы, выводятся одинаковые числа с одинаковой значностью (10.4), но проверка на равенство порой дает отрицательный результат!

Если бы area, то понятно, там реальная значность теряется в сумерках..., но я-то ее вроде бы обрезала!

Стала изощряться: умножать обе части на одинаковый множитель, так чтобы они стали целыми, потом еще truncate, round к ним применяла... Только round дает всегда правильный ответ. Но писать это нагромождение при каждом сравнеии... Это бред просто. Где я заблудилась?

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

 

 

Answer 1

Я подозреваю, что таков уж характер ваших данных - где-то там всё время появляется значность до 13 разряда.

Я использую самые обычные данные, ибо площади стандартных (т.е. самых обычных!!!) полигонов являются таковыми - именно с ними работают тысячи пользователей. И я использую их самым стандартным образом, т.е. складываю, сравниваю и т.п.

 Я не понимаю как люди могут работать, если у них стоят такие же реализации AV как у меня. Это абсолютный нонсенс. Это просто невозможно. Ошибки будут сыпаться как из рога изобилия. С таким пакетом работать невозможно. Странно, что Вы не сталкивались с такими проблемами до данного момента, если у Вас  такой же AV.

 

Answer 2

Тут даже еще смешнее получается. Выполнив те же пересчеты из 24.14 в 10.4 и снова в 24.14 на следующих цифрах получим такой же результат:

2456.12339999000010      &nbsp ; ;      2456.1234     2456.12339999999990

Загадка....

А еще смешнее как 5, умноженная на 10000 превратилась в 7.  Как в одном из предыдущих фрагментов. Просто умереть можно со смеху.

Я только не могу понять как с этим работать? И, главное, как все люди работают??? Или все люди работают все же с другим AV? А только некоторые счастливчики, типа нас с Вами, так вляпались?

Какая в принципе разница, двойная там точность или нет, результаты ОБЯЗАНЫ быть адекватными. Тем более на самых стандартных операциях.

 

 

Answer 3

Лия, давайте вернемся к началу. Я так понял, у вас есть шейп с полигонами. В атрибутивку вы заносите площади. Реальные примеры числовых значений приведите. В каких единицах измерения ваши данные? Может что-нибудь всплывет на этом этапе, что нам поможет...

Небольшое отступление сделаю. Расскажу об одной истории, которая случилась некогда с моим братом. Как-то братец мой поехал по делам в город Первоуральск. Дали ему машину с водителем, адрес и рассказали как ехать - где свернуть, какие ориентиры и т.д. Заезжают они в город и начинают искать нужный адрес. Вроде по приметам ехали правильно, но что-то сориентироваться не могут... Решили спросить местного товарища. Тот давай им рассказывать, что они де не туда заехали, надо было свернуть там-то, подняться в горку и т.д. Водитель начал с ним спорить и рассказывать, что им все не так объяснили - и что горки никакой нет, и поворачивать надо в другом месте... Вообщем чувствовалось, что спорщики уже не понимают друг друга. Тогда мой брат Андрей и говорит:

 - Подождите спорить. Давайте начнем с начала. Это город Первоуральск?

 - Нет, Ревда!

 

Answer 4

Я тут внимательно перечитал собственный пост, и обнаружил ошибку (теперь уже исправил). Везде в данном эксперименте целая часть была 2345 или 0, хотя отдельно я экспериментировал и с 2456. Просто втрорпях перепутал, откуда надо было Ctrl+C.  Поспешишь, людей насмешишь, блин.

Но сути дела это не меняет. Дробная часть у нас "играет" из-за особенностей машинного представления чисел. Самое простое и толковое, что удалось найти на эту тему - http://en.wikipedia.org/wiki/IEEE_floating-point_standard , правда, на английском. Есть более короткий текст на русском http://onembedding.com/info/float/ , и он тоже ссылается на википедию. Но, там есть также ссылка на интересную утилиту http://onembedding.com/tools/utility/fpconvert/ . Попробуйте скачать, и посмотреть, какова разница в представлении чисел например 2345.12339999999990, 2345.1234, и 2345.123 в стандарте IEEE 754.  НИКАКОЙ! Теперь то же самое с целой частью равной 0.  Почувствуйте разницу. В принципе, логично - чем больше целая часть, тем меньше разрядов остаётся на представление дробной, ведь формат представления чисел экспоненциальный

Фикус-пикус в том, что утилита работает с 32-битовым представлением чисел, т.е. single precision. А у нас должно быть 64 бита (double). Но поскольку всё это очень напоминает чехарду с нашими дробными частями, возникает подозрение, что где-то там внутри ArcView случаются преобразования между single и double. Но это только догадка. Копаем дальше.

Answer 5

Я только не могу понять как с этим работать? И, главное, как все люди работают???

А вот так и работают, хехе: https://forum.esri-cis.ru/index.php?qa=16445 =1

Answer 6

А вот так и работают, хехе: ....

Ну это совсем другая тема.

А вообще я просмотрела большую часть Ваших ссылок. Все это очень интересно и я готова заняться вплотную изысками в области представления чисел (в свободное от насущной работы время), но только после того как я пойму наконец как это получилось, что столь серьезные баги никому до меня не стояли поперек горла и не мешали работать. Что это я делаю такое необыкновенное, что до меня никто не делал?

Не спорю, баги есть в каждой достаточно большой программе, но, когда ПС используется достаточно долго, то все они постепенно становятся достоянием общественности и о них можно найти информацию хотя бы на форумах. И в AV я находила и другие баги, но и информацию о них. А тут - тишина.

Вот я и хочу понять в чем закавыка?

Answer 7

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

 Площади в шейпе вообще-то сами изначально считаются, я их только делю на 10000 и заношу в поле с разрядностью 10.4. В другом файле-справочнике эти же площади, но предварительно собранные по общему ключевому реквизиту (тоже 10.4). В программе-тесте я пытаюсь просто сравнить площади из справочника и заново собранные площади из шейпа. Все.

Реальные примеры на webfile, ссылочные номера и на данные, и на тестовую программу в моих последних постах (боюсь сейчас переврать, там прочитайте).Тест очень прост - загоняете в пустой проект тестовую программу, справочный файл и малюсенький шейп подключаете. Программу запускаете, получаете протокол в той же директории. Можете сравнить с моим протоколом на тех же самых данных (все в переданном архивчике). Все. Думаете, делаете выводы и т.д.  Данные в метрах. Если при загрузке шейпа единицы измерения сами не установятся, то надо их через меню, для теста без разницы, пробовала.

Answer 8

Извиняюсь, что влезаю в вашу дискусию и ооочень интересные изыскания , но вы к сожалению не первооткрыватели данного вопроса. Как уже говорил наш коллега, формат dbf хранит числа с плавающей точкой в формате Double (и не важно сколько знаков после запятой вы указали при определении поля), а он (это достаточно известный факт) имеет погрешность. Не стоит валить вину на AV (а я согласен - она долека от совершенства), ведь не компания ESRI придумала формат Double. Наберите в YANDEX, например "погрешность Double", и вы увидите что данная проблема присуща не только AV, она имеет более глобальные масштабы... Кстати, на форумах по другим языкам программирования есть много разных способов избежания данной проблемы.

Answer 9

Все это очень интересно и я готова заняться вплотную изысками в области представления чисел

Тут хотелось бы поддержать сказанное dindzilin'ом - Яндекс в этих изысканиях придётся весьма даже кстати!

столь серьезные баги никому до меня не стояли поперек горла и не мешали работать.

Мешали, и ещё как мешали. Вот коллега сегодня рассказал, как его друг, работавший в банке, намаялся, когда пришла пора сводить какой-то там баланс, и вдруг повылазили похожие чудеса. Опять же, dindzilin говорит, что все мучаются. И конечно, дело здесь не в AV и не в ESRI.

Что это я делаю такое необыкновенное, что до меня никто не делал?

Видимо, всё-таки не столь многие занимаются вопросами сравнения площадей секретных огородов . Может, всё дело в секретности?

Ну, слава богу, решение-то для поставленной задачи здесь прозвучало - употребляйте ROUND и ему подобное! В остальном дискуссия перешла в плоскость обсуждения double precision, что оказалось весьма увлекательно.

Answer 10

 И конечно, дело здесь не в AV и не в ESRI.

Судя по логике Ваших рассуждений - именно в них( коль они что-то используют, то должны это предварительно проверять). Или Вы что-то еще имеете в виду? 

Видимо, всё-таки не столь многие занимаются вопросами сравнения площадей секретных огородов . Может, всё дело в секретности? .

 

Думаете несекретные огороды будут сравниваться лучше? Мысль интересная. Как бы проверить?

Ну, слава богу, решение-то для поставленной задачи здесь прозвучало - употребляйте ROUND и ему подобное!

Хочу заметить, что с этим самым решением я и пришла на форум. Так что уж не знаю кому там слава, но я, кроме проникновения с Вашей помощью в некоторые нюансы ситуации, ничего тут не почерпнула. Проблема осталась - уж не знаю удастся ли мне убедить поставщиков покрытия использовать везде ROUND, но проблема эта не из легких. И боюсь, что этот форум им не указ.  И пошлют они меня...Они мне уже говорили, что у них все работает правильно.