Есть ли когда-нибудь причина писать .eqv. .истинный.?

В логике и в *хм* правильно разработанных языках программирования сравнение логического значения с истинным всегда избыточно, т. е. a == True следует заменить просто a. (И аналогично, a == False на not a).

Многие языки, включая C, не имеют надлежащего логического типа, поэтому может иметь значение, сравниваете ли вы с истинным (например, 2 == true дает 0, которое как логическое значение представляет ложь, в то время как 2 само по себе может представлять истинный).

Это также проблема в Фортране, или я всегда могу заменить a .eqv. .true. на a?

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


boolean fortran fortran95
person leftaroundabout    schedule 13.03.2015    source источник

Ответы (3)


arrow_upward
4
arrow_downward

Нет, нет смысла так писать. a .eqv. .true. совпадает с a. Только не используйте ==, который используется для разных типов данных.

Что касается вещей, найденных в устаревших кодах, не забывайте, что многие, если не большинство, пользователей Fortran не являются профессиональными программистами и никогда не проходили тщательного обучения правильным методам программирования. Часто их просто учили правилам языка.

person Vladimir F    schedule 13.03.2015

arrow_upward
4
arrow_downward

Это действительно повсеместная проблема?

так как вы спросили "всегда причину", я могу представить, как использовать его в качестве заполнителя во время разработки/отладки:

 c if(a.eqv.b) .. 
   if(a.eqv..true.)

Точно так же я мог видеть, что если кто-то изменил код, который изначально имел a как целое число, и изменил его на логический, вы могли бы в конечном итоге переключиться с a.eq.1 на a.eqv..true.. Я могу представить, что если у вас много сложных логических выражений, это может быть безопасным/простым подходом.

более неясно, вы можете использовать его, чтобы вызвать ошибку компиляции в событии a, которое не объявлено логическим. (это должно быть в каком-то использовании, которое уже не нуждается в логическом, например, в качестве аргумента подпрограммы, оператора записи и т. д.)

person agentp    schedule 13.03.2015
comment
Для некоторых это проблема. В прошлый раз, когда я проходил курс на Coursera, они вычитали баллы за эти поверхностные сравнения. Но на разных языках, не на Фортране. - person Vladimir F; 13.03.2015

arrow_upward
4
arrow_downward

Для a логического типа вы действительно, как уже говорилось ранее, имеете a и a.eqv..true. эквивалентные.

Вдохновленный ответом агента, где a.eqv..true. является естественным следствием разработки кода, я дам извращенный ответ. Здесь используется оператор .eqv., чтобы принудительно выполнить некоторую форму теста, и поэтому эта часть не бесполезна.

module tdef
  implicit none

  type t
    integer i
  end type

  interface operator (.eqv.)
    module procedure teqv
  end interface

 contains

  logical function teqv(a,b)
    type(t), intent(in) :: a
    logical, intent(in) :: b

    teqv = (a%i.eq.1).eqv.b
  end function teqv 

end module

use tdef
implicit none
print*, t(1), t(2), t(1).eqv..TRUE., t(2).eqv..TRUE.
end

Здесь есть урок, а также глупость: люди делают странные вещи. Всегда тщательно проверяйте перед заменой a.eqv..true. на a.

person francescalus    schedule 13.03.2015