В таких языках как Delphi, Java и других существуют блоки With, которые позволяют компактно и читабельно записывать выражения без имени структуры.
Хотелось бы в фортране аналогично записывать выражения:



Может быть уже есть такая штука в какой-нибудь современной редакции фортрана?

Нет, такого блока нет. Причем, с учетом специфики языка, это и не требуется: большие структуры с разнородными полями для области применимости Фортрана - вещь не совсем естественная.

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





Это сообщение отредактировал(а) FCM - 25.6.2011, 12:51

FCM, 

Спасибо! Попробую что это такое. Но  если структура представляет собой достаточно большой набор параметров, например, состояния некоторого технического объекта. То сколько ж придется ассоциировать 

Фантом, 

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

Жаль, что программисты - патриархи, которые влияют на формирование стандартов и требований к языку, не прочувствовали (а это только через опыт, который у них большой, но совсем в старом стиле) преимущества элементарного объектного подхода. Но такой подход требует наличие этой элементарной конструкции with  -  end with, а также наличие контекстных подсказок о полях структуры при нажатии "точки", как это реализовано в Delphi и Viesual Basic

--

Это сообщение отредактировал(а) Traum - 24.12.2011, 13:13

Вы обдумывали этот ответ полгода?   

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

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

Существует точка зрения (на мой взгляд, совершенно правильная), что при добавлении в язык разных инструментов для разных потребностей он очень быстро превращается в неудобный в использовании винегрет. Конкретно в случае Фортрана подобный подход вреден еще и тем, что поддержка этого "винегрета" плохо сказывается на быстродействии кода, что для этого языка принципиально важно. Поэтому проще пожертвовать удобством при написании  1% возможных программ ради сохранения эффективности при написании оставшихся 99%.

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

В принципе, на Фортране можно писать в стиле Java или Delphi, возможности по крайней мере 2003-го стандарта это позволяют (за вычетом нескольких незначительных деталей, вроде того же with - впрочем, некоторая замена есть и у этого средства), однако скорость кода при этом существенно упадет - не так сильно, конечно, как у Java или Delphi, но весьма заметно. Но, если это несущественно, то нет смысла использовать именно Фортран, а если существенно, то подобный стиль просто вреден.

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

Нет, чуть меньше. Прошу прощенья что очень долго.



Я тоже так считаю. Именно это и может погубить Дельфи.


Вот как раз массивы активно используются



Речь идет как раз о массиве однотипных однородных параметров. В качестве каждого элемента массива выступает структура одного и того же типа. Все элементы массива строго однородны и однотипны. Возможно тут имелось в виду другое. Поэтому ниже приведу 2 примера

1-й подход (обычные встроенные типы)

2-й подход (структуры)

Примеры слишком просты, но смысл ясен. Согласно Вам, векторная операция во втором случае будет медленнее? Чем массив P1%X отличается от массива X1? Насколько я знаю по сути ничем. Массив в Фортране (насколько я знаю) характеризуется двумя основными параметрами - это размер элемента (в байтах) и расстояние между элементами (в байтах). Так вот, в случае массива X1 имеем размер элемента 4 байта, и расстояние между элементами 4 байта. В случае массива P1%X имеем размер элемента также 4 байта, а расстояние между элементами 8 байт. При более сложной структуре получим не 8 байт а другое число. Но и в том и в другом случае адресация элементов сопровождается сложением: в первом варианте прибавляется одно число, во втором варианте другое. Так в чем же 1-й метод будет быстрее? Отмечу что возможна векторная операция:  X1 = P1%X  .

Если можно, поясните в чем преимущества записи массивов для отдельных переменных (как в 1-м подходе)

Преимущества 2-го подхода (прошу прокомментировать):
Технический объект описывается очень большим количеством параметров. При этом возникает необходимость помнить эти параметры в разных состояниях. При использовании структур достаточно написать всего ОДНУ! строчку :

type(TObjectState) ObjectState(100)

Массив значений некоторого параметра Param1 будет: ObjectState%Param1 . Аналогично можно оперировать массивами остальных параметров. Подчеркну что Массив ObjectState%Param1 - это обычный массив 4-х байтных чисел. И можно было бы написать следующую векторную операцию:

real X(100)

X = ObjectState%Param1 * 1Е5

Некоторое i-е значение этого параметра было бы равно ObjectState(i)%Param1. Добавление дополнительного параметра в описание объекта нигде не потребовало бы добавлять еще объявление массива для данного параметра.

В случае 1-го подхода пришлось бы для "каждой блохи" объявлять ее размерность в виде массива.


Здесь я перебрал наверно. Просто в одной книге я читал, что если речь шла бы о введении объектного подхода, то это непременно следовало было бы поддержать соответствующими средствами IDE. Так оно и произошло в других языках и IDE, что было сделано вполне разумно и трезво.

Я ценю вычислительную мощь фортрана. Однако старый подход всю эту мощь постепенно сводит на нет. По крайней мере программы в старом стиле получаются похожими на винегрет переменных, относящихся к разным по смыслу объектам. Такие программы требуют гораздо больших затрат энергии и времени на их модификацию и поиска ошибок. Передача громадного количества параметров при вызове подпрограмм снижает их быстродействие, а переход к использованию глобальных переменных или common блоков приводит к нечистоте этих подпрограмм и к "аду программирования" (как сказано в одной книге о глобальных переменных).


Это сообщение отредактировал(а) Traum - 25.12.2011, 22:09

Блок with не привел бы хоть к малейшему замедлению, поскольку еще на этапе компиляции короткие имена были бы заменены на их истинные длинные. Есть некоторые аспекты объектного подхода которые привели бы к замедлению (полиморфизм и т.п.). Но остальное - структура данных, а также методы, работающие с этой структурой - ни в кой мере не привело бы хоть к каким либо замедлениям (по-моему скромному мнению).

Это сообщение отредактировал(а) Traum - 25.12.2011, 21:58

Да, на один день.   



Я бы сказал, что это уже погубило Delphi. То, что сейчас еще шевелится - это остаточное явление.


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


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



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


Это в предположении, что для работы вообще используется IDE (в Visual/Delphi-понимании), что бывает не так уж часто.


Знаете, судя по тому, что Вы пишете, и по тому, какие примеры приводите, Вы боретесь с "неправильностями" в Фортране образца примерно 1977 года. "Огромное количество параметров", COMMON-блоки и т.п. - это уже седая древность. Не обижайтесь, но, наверное, Вам стоит сначала прочитать приличное описание хотя бы Фортрана 95, думаю, по итогам станет понятно, что with-блок и в самом деле уже не очень актуален. 

Дело даже не в том, что он чем-то уж очень вреден, его действительно можно ввести (и, как я уже писал выше, фактически некий его аналог в языке, начиная с 2003 стандарта, есть). Но он не лучшим образом вписывается в идеологию языка и к тому же не слишком нужен в реальной жизни.

Спасибо за поддержку .


Массив по определению может состоять только из однотипных элементов. В качестве элемента может быть обычный real или сложная структура. Если правда то, что сказано в цитате, то получается работа с сечениями многомерных массивов также будет более медленной как и в случае массива из структур, поскольку в этих сечениях элементы находятся также на нестандартном расстоянии. Но учитывая, что для работы с массивами всегда требуется знать размер элемента и расстояние между элементами, которое всегда одинаково как в случае простых массивов, так и в случае сечений из структур или из многомерных массивов, а также учитывая что это расстояние становится известным еще на этапе компиляции, то что либо вычленять (т.е. рассчитывать расстояние между элементами) на этапе выполнения уже не требуется, поэтому никакого замедления из-за "вычленения" не может быть (я полагаю, но не претендую на истину).


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


Может сейчас такая тенденция есть. Но Delphi - это супер дисциплинированная среда программирования. Чего стоят исходники к Дельфи 7. Это не исходники а пример того что значит дисциплина и культура программирования. В этих исходниках практически нет комментариев к переменным, потому что имена у них предельно осмысленные, короткие и в тоже время очень ясные. Сам код оптимально структурирован и ясен, каждый метод выполняет четко поставленную цель и имеет предельно ясное имя. Никаких свалочных подпрограмм там не найти.

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

У фортрана есть ряд преимуществ по синтаксису перед паскалем. Однако вот к примеру, пусть в Дельфи и Фортране имеем ситуацию когда используются два модуля Module1 и Module2. В каждом из этих модулей встречаются некоторые одинаковые по имени публичные переменные Var1, Var2 и так далее, а также некоторые одинаковые по имени публичные подпрограммы Sub1, Sub2 и так далее. Так вот в Дельфи конфликт имен просто не возникает, потому что там обратиться к переменной Var1 из модуля Module1 можно самым естественным из естественных путей - через имя самого модуля, т.е. Module1.Var1, и соответственно обратиться к переменной Var1 из модуля Module2 можно путем Module2.Var1. Аналогично с подпрограммами:  Module1.Sub1 или Module2.Sub1. Разумеется при отсутствии конфликта имен можно обращаться просто используя имена переменных и процедур как обычно.

Казалось бы что мешало бы сделать аналогичное решение проблемы конфликта имен в фортране, т.е. использовать обращения типа Module1%Var1 и Module2%Var1. Как известно в фортране предусмотрен совершенно громоздкий путь решения этой проблемы, который еще можно применить для одной, двух переменных, но далее это будет похоже на нелепое занятие.

Относительно этого тоже хотелось бы сделать предложение ввести в стандарт возможность в случае конфликта имен обращаться к переменной через имя модуля. Это нововведение никак не повлияет на снижение производительности.


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


Подскажите что за аналог, частное слово я с большим интересом многое изучал из фортрана 95 или 2003 но ничего не нашел.


Ну подскажите, как решить проблему огромного количества параметров, пожалуйста.


Это сообщение отредактировал(а) Traum - 27.12.2011, 20:52

Да, и в среднем это действительно так. 


Полагаю, что математикам Фортран как раз не нужен, там задачи другие.


В этом в основном и проблема. Плохой код можно написать практически на любом языке, и Фортран - не исключение.


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


А это и есть нелепое занятие.


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


Конструкторы структур. Некое "расширение" идеи конструкторов массивов. Не самое изящное, но оно есть.


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