政治政策として。
www3.nhk.or.jp
We can’t solve a crisis without treating it as a crisis and we must unite behind experts and science.
— Greta Thunberg (@GretaThunberg) 2020年3月11日
This of course goes for all crises.
Now the experts urge us to avoid big public gatherings for a better chance to #flattenthecurve and slow the spreading of the Coronavirus. 1/4 pic.twitter.com/24o3a7J9ed
4 Language Semantics While disregarding details and further unresolved difficulties, we emphasize that the language’s definition must be stated in terms of mathematical formulae and be free of references to any mechanism for execution. A language must be understandable by its static rules alone, without knowledge about any possible implementation. We explain this strong requirement by three familiar examples: 1. Numbers: Operations on numbers (integers) are defined by the axioms of mathematics. Hence there is no need to specify how numbers are represented as sequences of bits. In fact, representation must not be specified, as this would narrow the freedoms of implementers. Such an over-specification would break the notion of the abstraction; it would reveal to the reader properties of their (possible) representation instead of the numbers themselves. 2. Data Structures: Each element of an array is selected by a unique index, and an element of a matrix by a tuple of indices. Hence, there is no need for a programmer to know how an array is allocated within a computer store (whether row- or columnwise or anything else). In fact, this knowledge would allow the programmer to perform operations not specified by the proper abstraction alone. 3. Iterative Statements: Repetitions are typically explained in terms of their implementation with jumps. But there is no need for a programmer to know about jumps, in fact he must avoid the notion of structure-breaking jumps. Instead, the properties of an iterative statement S must be defined in terms of the effect of the iterated statement Q alone.
整数や配列の番地の展開は実装の詳細に依らぬのがいいと言っていて、その通りだと思いますが Fortran を学ぶ上では避けては通れない知識だとも思います。ここが表面的な文法を学んだだけでは苦しい所である気がします。
それは、現在の計算機ではメモリー上のデータの移動が律速段階になっていて、明示的代入を通じてメモリー移動を巧妙に制御しないと計算機資源を有効に活用できない所に遠因していると考えます。
なお三番目のループ（ジャンプ）については Hoare の記述に依っているようです。
ALGOL, PASCAL, Module-2, Oberon の系譜について回顧
Into the Realm of Oberon: An Introduction to Programming and the Oberon-2 Programming Language
Oberon-2 Programming with Windows
Object-Oriented Programming in Oberon-2
Programming in Oberon: Steps Beyond Pascal and Modula (ACM Press)
太陽光で間抜けの菅直人を騙してぼろもうけしたクズがまた汚いことをやろうとしている。
SBIファーマ株式会社(医療機器の研究開発、製造、販売) 取締役 上昌広 ttp://www.sbipharma.co.jp/company/
SBIバイオテック株式会社 取締役(社外) 上昌広 http://www.sbibiotech.jp/corporate/profile.html
![ベニスに死す [WB COLLECTION][AmazonDVDコレクション] [DVD]](https://m.media-amazon.com/images/I/51vGSVN4vVL._SL160_.jpg "ベニスに死す [WB COLLECTION][AmazonDVDコレクション] [DVD]")
ベニスに死す [WB COLLECTION][AmazonDVDコレクション] [DVD]
イラン・イタリア・朝鮮 土葬国はダメだな。
数値計算のためのFortran90/95プログラミング入門(第2版)
数理科学も昔はダイヤモンド社刊だったのですね。
・ FORTRAN(特集)/1～27,33～82 ・ FORTRANの世界(座談会) / 小野 勝章/18～27 ・ 大型FORTRANの特徴 / 小林 達/45～53 ・ JIS FORTRANの特徴 / 菅 忠義/33～38 ・ ぼくたちの失敗 / 江沢 洋/60～62 ・ 数理工学雑記帳-12-不等式の条件 / 森口 繁一/28～32 ・ アンケート--FōRTRAN一覧 / 数理科学編集部/63～79 ・ 特集:FōRTRAN / 東大大型計算機センター 研究開発部員 プログラム指導員/3～82 ・ 多次元の処理と政治的関心の研究例 / 穐山 貞登/39～44 ・ 市場調査とコンピュータ / 磯野 達雄/54～59 ・ ことばのページ / 戸田 英雄/80～82 ・ Burroughs E6000 VRCS / 町田裕叙/86～87 ・ コンピュータ･ニュース / 編集部/88,90 ・ 電子計算機学校紹介 //83～83 ・ 日本科学技術研修所･計算センター //84～84 ・ 富士通電算機専門学校 //85～85 ・ 初心者へのアドバイス--FōRTRANキイ･ポイント / 東大大型計算機センター 研究開発部員 プログラム指導員/3～12 ・ ちいさなFōRTRAN //12～17 ・ 数理科学次号予告 //53～53 ・ 数理科学既刊1月号内容 //59～59
終了処理を伴う派生型変数を静的なスカラー変数に対して代入するとき、静的変数が reallocate されている感じ。[追記：loc関数で番地を見ると変化していないので reallocate ではなかったです。] gfortran ではそうならない。
なお unallocated な allocatble 変数に代入する時は final 処理はされない。
module m_test implicit none type :: t_base integer :: i = 0 contains final :: fin_base end type t_base contains subroutine fin_base(this) type(t_base), intent(in out) :: this print *, 'final' end subroutine fin_base end module m_test program test use m_test implicit none type(t_base) :: a a = a end program test
a=a の所で final subroutine が呼ばれている。 a=t_base() でも同様。
final
module m_test implicit none type :: t_base integer :: i = 0 contains final :: fin_base end type t_base contains subroutine fin_base(this) type(t_base), intent(in out) :: this print *, 'final' end subroutine fin_base end module m_test program test use m_test implicit none type(t_base) :: a type(t_base), allocatable :: b class(t_base), allocatable :: c print *, 'start' a = t_base() print *, 'end: a' b = a print *, 'end: b' c = a print *, 'end: c' end program test
start final end: a end: b end: c
配列の時や部分配列の時は finalization は行われませんが、配列の要素の時は finalization が行われます。スカラーの時だけ異常な振る舞いがなされるようです。
module m_test implicit none type :: t_base integer :: i = 0 contains final :: fin_base end type t_base contains subroutine fin_base(this) type(t_base), intent(in out) :: this print *, 'final' end subroutine fin_base end module m_test program test use m_test implicit none type(t_base) :: a, b(10) print *, 'loc a', loc(a) a = a print *, 'loc a', loc(a) print *, 'loc b', loc(b) b = b print *, 'loc b', loc(b) b(1:1) = b(1:1) print *, 'loc b', loc(b) b(1) = b(1) print *, 'loc b', loc(b) end program test
loc a 14000912 final loc a 14000912 loc b 14000872 loc b 14000872 loc b 14000872 final loc b 14000872
Fortran 2018 with Parallel Programming
数値計算のためのFortran90/95プログラミング入門(第2版)
