Доброго дня! Товарищи помогите кто чем может   
В виду постоянных проблем с FPSом решил прейти на Visual Studio.
Поставил последнюю версии 2009, добавил Intel fortran 11 - все срослось вроде.
Компилируется все даже...
Но!!! Результаты вычислений в VS сильно различаются от FPS + есть даже NaNы и 0.000e-0 при 1м и том же коде!
Они вообще различны оказывается!
Тыкал в настройках совместимость с FPS - не помогает...
Подскажите пожалуйста как перейти корректно с FPS на MVS? Как быть?

Это сообщение отредактировал(а) JohnBonJovi - 10.6.2009, 21:51

Насчет отличий результатов можно поподробнее?
Вообще говоря поведение относительно критических ситуаций при вычислениях с плавающей точкой задается в свойствах проекта.
Как правило, Release и Debug-сборки имеют разный набор настроек для вычислений с плавающей точкой. 
Также возможно задавать поведение относительно вычислений с плавающей точкой в программе с помощью так называемого контрольного слова.

Это сообщение отредактировал(а) FCM - 11.6.2009, 16:23

Программа с оконным интерфейсом значит - после компиляции в fps при нажатии на кнопку Расчет выдается конкретное значеное (хоть занажимайся) а после компиляции в VS при нажатии на кнопу 6 раз - 6 разных результатов по убывающей при Release либо infnity и nanы при Debug   
Это к вопросу про разные результаты...
Можно по подробнее про настройки проекта и плавающую точку - нашел эти опции, но не смекнул че к чему там...
Ну и про контрольное слово тоже можно  

Если там простое выражение считается, то покажи какое.
Контрольное слово регулирует поведение FPU (сопроцессора) при возникновении исключительных ситуаций с floating-point numbers: деление на вещ. ноль (divide-by-zero), потеря точности (inexact), учет/неучет денормализованных чисел и еще кое-что - завтра напишу). Также можно регулировать это поведение с помощью свойств проекта - сейчас подробнее где конкретно смотреть не могу сказать, т.к. под рукой нет компьютера с Intel Fortran. 
Например, можно сделать так, чтобы при делении на вещ.ноль происходил авост. Но как правило, настройки по умолчанию таковы, что просто генерится infinity и т.п.
Могут быть некоторые нюансы при опции обнуления денормализованных чисел. Как правило при настройках по умолчанию они учитываются (не обнуляются). 

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 все работает нормально...

А можно увидеть всю программу целиком? Заочно гадать, в чем может быть дело, затруднительно.

(С помощью контрольного слова устанавливается поведенеие 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.) )

Программа написана как единое целое или "декомпозирована" на процедуры? При вызове процедур по неявному интерфейсу также возможны фокусы при неаккуратном использовании вещественных чисел различной разрядности.

Это сообщение отредактировал(а) FCM - 12.6.2009, 15:38

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

На счет деления на 57.3 - писалось на скорюю руку - видимо доделаю.
Завтра гляну про градусы для sin cos
help гляну

А дальше дебри пойдут для меня  

Про точность не вкурсе - мои познания - семестр в универе (там используется только FPS) + некое самообразование... те я не вкурсе...
"буквальные вещественные константы" тоже не знаю
Какой результат SIZEOF(1.) должен выдать чтоб узнать REAL(4) или REAL(8)?

Это сообщение отредактировал(а) JohnBonJovi - 12.6.2009, 20:41

Присоединённый файл ( Кол-во скачиваний: 6 )
 tmm.7z 1,70 Kb

Ну, наиболее очевидное место для ошибок - не указанный явно KIND у типов (а у FPS и IFC по умолчанию они, если память не изменяет, различаются).

Что за KIND и как использовать его в моем случае?

Вместо REAL везде поставить REAL(4) и посмотреть, что получится.

Ясно  
Завтра попробую.

Буквальные - это значит буквально заданные,т.е. например в выражении COS(2.d0*X) 
2.d0 -буквальная константа типа REAL(8), а X - переменная или именованная константа.

SIZEOF(1.) должен выдать соответственно 4 , если 1. по умолчанию интерпретируется как REAL(4) и 8 если 1. по умолчанию интерпретируется как REAL(8).

Переписал Real на Real(4) и SIN на SIND - в результате получилось следующее:
1 - При RELEASE (буду в нем работать лучше) часть результатов в уже не меняется при многократном нажатии кнопки выполнения. При DEBUG - значения плохие.
2 - Часть результатов также верна но меняется после второго нажатия.
3 - Часть результатов НЕ верна (хотя близка к истине) и меняется после второго и последующих нажатий.
4 - 2 nan и 4 нулевых результата.
Потыкал еще настройки плавающей точки...

Это сообщение отредактировал(а) JohnBonJovi - 13.6.2009, 09:23

Методом научного тыка в алгоритме обьединил 2 кнопки  в 1у - и все посчиталось - значит мой косяк в логической цепочке вычислений!
Пришлось переделывать алгоритм - сделал по тупому: читает еще раз уже прочитанные значения. Но тем не менее  

Теперь все вычисления верны и точны из-за cosd и sind и нет nan и infinity

Порадовал еще человеческий формат вывода по-умолчанию вместо научного у FPS

Еще вопрос цепану один: какой графор подключить к IFC?
На FPSовский ругается...

Решено в общем.

Это сообщение отредактировал(а) JohnBonJovi - 14.6.2009, 15:19