| Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
| Форум программистов > Fortran > [Tools] Проект из FPS на MVS |
| Автор: JohnBonJovi 10.6.2009, 21:40 |
Доброго дня! Товарищи помогите кто чем может  В виду постоянных проблем с FPSом решил прейти на Visual Studio. Поставил последнюю версии 2009, добавил Intel fortran 11 - все срослось вроде. Компилируется все даже... Но!!! Результаты вычислений в VS сильно различаются от FPS + есть даже NaNы и 0.000e-0 при 1м и том же коде! Они вообще различны оказывается! Тыкал в настройках совместимость с FPS - не помогает... Подскажите пожалуйста как перейти корректно с FPS на MVS? Как быть? |
| Автор: FCM 11.6.2009, 16:13 |
| Насчет отличий результатов можно поподробнее? Вообще говоря поведение относительно критических ситуаций при вычислениях с плавающей точкой задается в свойствах проекта. Как правило, Release и Debug-сборки имеют разный набор настроек для вычислений с плавающей точкой. Также возможно задавать поведение относительно вычислений с плавающей точкой в программе с помощью так называемого контрольного слова. |
| Автор: JohnBonJovi 11.6.2009, 19:57 |
Программа с оконным интерфейсом значит - после компиляции в fps при нажатии на кнопку Расчет выдается конкретное значеное (хоть занажимайся) а после компиляции в VS при нажатии на кнопу 6 раз - 6 разных результатов по убывающей при Release либо infnity и nanы при Debug  Это к вопросу про разные результаты... Можно по подробнее про настройки проекта и плавающую точку - нашел эти опции, но не смекнул че к чему там... Ну и про контрольное слово тоже можно |
| Автор: FCM 11.6.2009, 20:49 |
| Если там простое выражение считается, то покажи какое. Контрольное слово регулирует поведение FPU (сопроцессора) при возникновении исключительных ситуаций с floating-point numbers: деление на вещ. ноль (divide-by-zero), потеря точности (inexact), учет/неучет денормализованных чисел и еще кое-что - завтра напишу). Также можно регулировать это поведение с помощью свойств проекта - сейчас подробнее где конкретно смотреть не могу сказать, т.к. под рукой нет компьютера с Intel Fortran. Например, можно сделать так, чтобы при делении на вещ.ноль происходил авост. Но как правило, настройки по умолчанию таковы, что просто генерится infinity и т.п. Могут быть некоторые нюансы при опции обнуления денормализованных чисел. Как правило при настройках по умолчанию они учитываются (не обнуляются). |
| Автор: JohnBonJovi 11.6.2009, 21:18 |
| psi=epss-(zs*((cos(20/57.3)/cos(alfa/57.3))-1)/2) eps=(sqrt(rl1**2-ro1**2)+sqrt(rl2**2-ro2**2)-a*sin(alfa/57.3))/(t*cos(20/57.3)) (расчет зубчатой пары) Примерно из 20 подобных вычислений состоит пол-программы. Не самые сложные... Использую f90. Повторюсь - в FPS все работает нормально... |
| Автор: Фантом 11.6.2009, 23:08 | ||
А можно увидеть всю программу целиком? Заочно гадать, в чем может быть дело, затруднительно. |
| Автор: FCM 12.6.2009, 15:36 |
| (С помощью контрольного слова устанавливается поведенеие FPU относительно -деления на вещ. ноль -inexact - потеря точности (т.е. в двоичном представлении нельзя точно представить и происходит округление) -обнуление/учет денормализованных чисел -underflow -overflow -invalid (ошибки связанные с недопустимыми значениями аргумента функций) Подробности можешь посмотреть в help: GETCONTROLFPQQ, SETCONTROLFPQQ, GETSTATUSFPQQ В свойствах проекта з это отвечает раздел Floating Point/ Floating Point Exception Handling и быть может неявно еще кое-что) Но в твоей ситуации может и не в этом дело. Например, очень мне не нравится использование числа 57.3 - оно слишком неточное. 180/Pi = 45.d0/atan(1.d0) = 57.2957795130823. Более того в Intel Fortran есть триг функции для "градусного" аргумента: COSD, SIND и т.п. Вообще в программе какая точность используется REAL(4) или REAL(8) ?. Посмотри, как интерпретируется в твоем проекте Intel Fortran 11 буквальные вещественные константы без суффиксов, например 1. , как REAL(4) или как REAL(8) ( с помощью SIZEOF(1.) ) Программа написана как единое целое или "декомпозирована" на процедуры? При вызове процедур по неявному интерфейсу также возможны фокусы при неаккуратном использовании вещественных чисел различной разрядности. |
| Автор: JohnBonJovi 12.6.2009, 20:35 |
| Текст части программы прикрепил. ... Там дальше есть вызовы программ рисования, вызов всех подпрограмм (вычислительния - в одной подпрограмме только) идет через формальные параметры (или фактические - не помню как называется - вобщем через позиционное соответствие). Оконный интерфейс взят из примера в FPSе На счет деления на 57.3 - писалось на скорюю руку - видимо доделаю. Завтра гляну про градусы для sin cos help гляну А дальше дебри пойдут для меня Про точность не вкурсе - мои познания - семестр в универе (там используется только FPS) + некое самообразование... те я не вкурсе... "буквальные вещественные константы" тоже не знаю Какой результат SIZEOF(1.) должен выдать чтоб узнать REAL(4) или REAL(8)? |
| Автор: Фантом 12.6.2009, 20:50 |
| Ну, наиболее очевидное место для ошибок - не указанный явно KIND у типов (а у FPS и IFC по умолчанию они, если память не изменяет, различаются). |
| Автор: JohnBonJovi 12.6.2009, 21:08 |
| Что за KIND и как использовать его в моем случае? |
| Автор: Фантом 12.6.2009, 21:23 | ||
Вместо REAL везде поставить REAL(4) и посмотреть, что получится. |
| Автор: JohnBonJovi 12.6.2009, 21:45 |
| Ясно Завтра попробую. |
| Автор: FCM 12.6.2009, 21:52 | ||
Буквальные - это значит буквально заданные,т.е. например в выражении COS(2.d0*X) 2.d0 -буквальная константа типа REAL(8), а X - переменная или именованная константа. SIZEOF(1.) должен выдать соответственно 4 , если 1. по умолчанию интерпретируется как REAL(4) и 8 если 1. по умолчанию интерпретируется как REAL(8). |
| Автор: JohnBonJovi 13.6.2009, 09:19 |
| Переписал Real на Real(4) и SIN на SIND - в результате получилось следующее: 1 - При RELEASE (буду в нем работать лучше) часть результатов в уже не меняется при многократном нажатии кнопки выполнения. При DEBUG - значения плохие. 2 - Часть результатов также верна но меняется после второго нажатия. 3 - Часть результатов НЕ верна (хотя близка к истине) и меняется после второго и последующих нажатий. 4 - 2 nan и 4 нулевых результата. Потыкал еще настройки плавающей точки... |
| Автор: JohnBonJovi 13.6.2009, 13:36 |
| Методом научного тыка в алгоритме обьединил 2 кнопки в 1у - и все посчиталось - значит мой косяк в логической цепочке вычислений! Пришлось переделывать алгоритм - сделал по тупому: читает еще раз уже прочитанные значения. Но тем не менее Теперь все вычисления верны и точны из-за cosd и sind и нет nan и infinity Порадовал еще человеческий формат вывода по-умолчанию вместо научного у FPS Еще вопрос цепану один: какой графор подключить к IFC? На FPSовский ругается... Решено в общем. |
