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

Question

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

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

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

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

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

 

 

Answer 1

Уважаемый yumakaev!
Большое Вам спасибо за попытку помочь! Однако разберу по пунктам.

Начну, пожалуй, в порядке исключения с №6: Приношу тысячу извинений за то, что Вам пришлось копаться в этой непотребной программе. Изначально она не предназначалась для чужих взоров, а теперь переделывать уже как-то не с руки...

2.truncate.Дело в том, что я, наверное, в последний раз привела не самый удачный фрагмент протокола, предлагаю еще кусок:

125 1ver.Для 01 72 001 суммы совпали pl2r=17574250.0000 plslr=17574250.0000
126 2ver.Для 01 72 001pl2t=17574250.0000 > plslt=17574249.0000
127 3ver.Для 01 72 001pl2=0001757.425000> plsl=00001757.425000
128 4ver.Для 01 72 001pl2m=17574250.000000> plslm=17574250.0000

Т.е. truncate (2 ver) работает с этими числами у меня тоже некорректно.

 Да и вообще, согласна с S.E. - округление тут более логично.

3. Вы правы -setformat определяет именно внешность чисел, именно для этого и только для этого я его и использую. Ясно, что он ничего не отсекает.

Если у меня встречается это в каждой итерации, то только для выведения большей разрядности в 3м случае, где я не умножаю переменные на коэффициент. Если где-то еще попалось - это случайность, не досмотрела.

4.Не правы Вы. Вот посмотрите еще кусок:

2201 1ver.Для 09 42 002 суммы совпали pl2r=4530692.0000 plslr=4530692.0000
2202 2ver.Для 09 42 002 суммы совпали pl2t=4530692.0000 plslt=4530692.0000
2203 3ver.Для 09 42 002pl2=0000453.069200> plsl=00000453.069200
2204 4ver.Для 09 42 002 суммы совпали pl2m=4530692.0000plslm=4530692.0000

Напомню: 1 вариант - (числаХна множитель=10000).round

                2 вариант -(числаХна множитель=10000).truncate

                3 вариант - числа в непосредственном виде

                4 вариант -(числаХна множитель=10000)

Вот тут как раз 3 и 4 варианты не равны! И это не единичный случай.

5. Да, конечно.В прошлый раз я выбрала неудачный фрагмент протокола, добавляю:

093 1ver.Для 01 71 002 суммы совпали pl2r=27832581.0000 plslr=27832581.0000
094 2ver.Для 01 71 002pl2t=27832581.0000 > plslt=27832580.0000
095 3ver.Для 01 71 002pl2=0002783.258100> plsl=00002783.258100
096 4ver.Для 01 71 002pl2m=27832581.000000> plslm=27832581.0000

Если какие мысли или советы еще появятся - буду рада прочитать.

 Если все же, несмотря на всю "непроходимость" программы,  грубых ошибок, приводящих к столь странным результатам, там нет - то возникает вопрос: как доказать неработоспособность ArcView (того, что у меня, а не вообще) ?

Похоже, что дело именно в этом. Вы же сами говорите: 3й и 4й вариант просто обязаны быть одинаковы! Но это у меня не так!

Очень надеюсь на толковый совет. 

 

 

Answer 2

По-моему, ROUND все же более правильный вариант. Округление же должно производиться при изменении разрядности.

Извечный вопрос об округлении в дробной части... Тут, конечно, всё зависит от постановки конкретной задачи.

Например, возьмём число 1.445 . Если округлять до целых, как есть, то получится 1 (1.445 всё-таки ближе к 1, чем к 2). Если начать округлять справа налево, то получим сначала 1.45, потом 1.5, ну и потом уже по всем правилам округления выходит 2.

Теперь пример к нашей теме. Положим, сравниваются два числа 1.444433 и 1.444455. Применяем подход, принятый в алгоритме Лии. Полагаем, что все методы работают без глюков .

При truncate получим, что 14444 = 14444, при round - что 14444 < 14445 .

Конечно, Лия сама должна выбрать, какой метод в её случае логичнее, но в самом первом постинге говорилось про отсечение лишней значности... а это truncate... imho...

Answer 3

Кстати, про round vs. truncate - вспомнился ещё такой метод, как Floor. Правда, не совсем понятно, чем он принципиально отличается от Truncate, но может стоит поэкспериментировать.

Answer 4

Хммм...

...Если все же, несмотря на всю "непроходимость" программы,  грубых ошибок, приводящих к столь странным результатам, там нет - то возникает вопрос: как доказать неработоспособность ArcView (того, что у меня, а не вообще) ?....

Грубых ошибок в программе я не вижу. Но очевидно, что-то в каком-то месте не работает - то ли у вас, то ли в вашей копии ArcView. Тяжело понять, как такое происходит, не погоняв программу на разных машинах и разных инсталляциях ArcView, да ещё желательно в Debug, а для этого нужны данные. Можно выслать мне на aycontact@gmail.com .

Ещё такой вопрос: на одних и тех же данных результат всегда один и тот же? Т.е. расхождения всегда одни и те же на конкретных парах чисел, или по погоде?

Answer 5

Сначала про truncate. С Вашими рассуждениями я согласна, но в данном случае это несущественно.Посмотрите какой я привожу Вам пример в п.2 прошлого поста - нет там ни .444433, ни .444455. В третьей строке, где выводятся "чистые" сравниваемые числа - сплошные нули в меньшей разрядности в обоих числах.

Ещё такой вопрос: на одних и тех же данных результат всегда один и тот же?

Расхождения, похоже, всегда одинаковые. Весь протокол на этот предмет я не просматривала - очень велик, но все, что видела совпадает.

а для этого нужны данные

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

Теперь, раз уж пошла такая пьянка, то бишь разборка, хочу поделиться еще некоторыми результатами анализа. Может это поможет.

Дело в том, что когда я сравниваю площадь по одной записи - все работает всегда отлично. Несуразности начинаются лишь в тех случаях, когда сравнивается площадь полученная путем суммирования площадей из нескольких записей с одинаковыми ключевыми реквизитами (естественно, ошибка не всегда происходит). Причем, когда я попыталась раскрутить одну такую странную площадь сравнивая каждую входимую площадь с ее числовым эквивалентом, чтобы определить источник ошибки, то получила правильный результат для каждой входящей записи!!! А когда сравниваю итоговую площадь так же с числовым эквивалентом (прямо забиваю во всех случаях в программу для верности ), то получаю то, что Вы уже видели.Вот такая вот фигня. Получается что операция сложения не работает????? Но в других случаях она вроде бы работала.  Или словарь? Тоже вроде обычно работает. Не знаю, но, похоже, что дело не в данных. А в чем?

 

 

Answer 6

как-то выбрать и скорректировать базу, чтобы все так же работало, но прицепиться было бы не к чему. Это требует некоторого времени.

Так высылайте только dbf - для проверки вашего алгоритма не нужна никакая пространственная информация, если все площади уже забиты в атрибутах. Обещаю, меня будут интересовать одни только числа, и то, как они обрабатываются. Любые текстовые поля из таблиц можно смело поудалять. Если у вас слишком много записей, то можно также оставить выборку, в которой записей будет меньше, но чтобы были представлены и те, которые работают, и те, что нет, если такое не слишком сложно сделать. Так и начальству огородов спокойнее, и нам с вами меньше мегабайт гонять.

-----

Ну а насчёт есть или нет числа вида 0.44443 - мы говорим о программе, которая будет работать универсально, или только на данном, раз и навсегда зацементированном наборе данных?

Answer 7

Данные посланы.

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

 Жду ответа здесь.

Answer 8

Я пока ничего не получил, хотя вроде уже много времени прошло.

Answer 9

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

Answer 10

Если получите, отвечайте здесь, на форуме, т.к. обратный адрес не мой (так получилось) .