プリマーAI

生成AIの2つの顔（２）からの続き

これら２つの例から考えると，テキスト型生成AIの教育利用のイメージの一つは対話型の本（以下プリマーAI）ということになる（結局，ニール・スティーブンソンのダイヤモンド・エイジに出てくるプリマーに帰着する）。デジタルテキストとして提供される本の場合，(1) 当該の本の本文テキストをコアとして，(2) 同じ著者による関連著書である著者テキストの集合，(3) 本文テキストと関連する主題テキストの集合，(4) "世界"全体の背景常識テキストの集合，に適当な重みをつけて学習させたLLMシステムを作る。利用者は，これに対して，ChatAIインターフェースで，対話しながら内容を読解していく。これに，(5) 対話・学習記録テキストの集合が追加できれば問題ない。

プリマーAIを教科書として利用する場合，対話しながら教科書の内容を理解することができる。つまり，解らない部分は，何度でも角度を変えながら「著者」に質問することができるというわけだ。この場合，教科書検定というか内容（対話部分を担う学習データ部分）の正確性はどう担保するのか。あるいは政治問題化するのか。

ある人の著書だけでなく，全会話記録や全テキスト記録をプリマーAIに入力すれば，その人の仮想人格と対話できることになるので，紙に書かれた文章の読解力がなくとも，著者との対話が実現してしまうことになる。教科書から話はそれるが，対話できるタレント・アイドル本みたいなものができてしまうのか。いいのか？

DeepLに加えてChatGPT+BingChatの魔の手からも逃れられなくなりつつある今日この頃。

生成AIの2つの顔（２）

生成AIの2つの顔（１） からの続き

もう一つは，シンギュラリティサロン・オンラインの「AIは人類社会に革命をおこすのか 〜 OpenAI CEO サム・アルトマン氏の未来予測について考える」だ。ゲストに関西外国語大学の水野義之さんが登場して，AIの問題点を指摘した。ChatGPTは壮大な文化破壊であるというのがキーワードだ。

その意味は次のように説明される。(1) 人間は易きに流れる（勉強嫌い）。(2) 情報は不気味の谷を感じない（気付けない）。(3) 事前に知っていない限り間違いは見抜けない（鵜呑み）。(4) 人間は自分を相手に投影する（思い込み）。これらの結果，ChatGPTの普及によって愚かな人間が増えてしまい，二極分化はさらに進むことになる。それほど厳しい反対論ではない。

なんとなくいいたいことは解るのだけれど，十分に整理しきれていない印象だ。が，水野さんが20年前に原子核実験物理から大学における情報教育へと研究テーマを変えてからの蓄積の上，最近のAIについても十分リサーチしていることから，バランスのとれた興味深い話だった。壮大な文化破壊に対する対策としては，(1) Yann LeCun のFacebook 2/14/2023のコメント#14を引用している。「− LLMは*書き込み補助*として使われている。− 心のない大衆に彼らの作り上げたナンセンスを信じさせることで，社会の布石を破壊することは*しない*。− 人々は役に立つことにそれらを使う」（これ対策ではないけど…）(2) AI倫理による回避，(3) 人間知能の理解進化（？） をあげていた。

水野さんと最初に会ったのは，自分がD1のときの夏の学校の原子核分科の研究会だ。藤田純一先生が来られるはずだったが，病気でかなわなかったときか。修士論文のA=12体系のベータ崩壊におけるCVCの話をしたところ，最前列に座っていた1学年下の水野さん（東北大学の原子核理学研究施設：現，電子光理学研究センターで電子散乱の実験をしていた）が質問してきた。

次に覚えているシーンは1980年5月，阪大核物理研究センターが六甲山の関西地区大学セミナーハウスで開催した原子核物理の夏の学校だ。小林正博君と一緒にエジプト人留学生から英会話を学んで準備したサマースクールだった。夜のインフォーマルミーティングで水野さんはQCDの深部非弾性散乱でOperator Product Expansion の話を始めていた。うーんなんだったのか。

最後は，1996年1月に早稲田大学で催されたのJAIN-OLU合同シンポジウムの場だ。「インターネットと教育　−WWWによる教育情報の提供−*」というタイトルで発表したのだが，同じ場で，水野さんがインターネットとボランティア的な内容の話をした。チラッと顔を合わせて，あらこんなところでとなったのだった。ちなみに，和歌山県のみさと天文台の尾久土正己さんが「過疎地域の天文台におけるインターネット活用」という話をしている。

*リンク先は同趣旨で書いた，大阪大学大型計算機センターニュース（1997.8）の記事

生成AIの2つの顔（１）

2022年の生成AI（DALL-E, ChatGPT）の登場は，インターネット以来のインパクトを持っていた。今も新しいニュースが絶え間なく続き，ほとんど追いつけない状態になっている。SNSで聞こえてくる日々の噂もカバーしきれない。そんな中で，今日見た2つのチャンネルは，大変興味深かった。

一つは，散財小説ドリキンの「ChatGPTが変えたエジケンの新プロダクトとAIにハマる理由」だ。Quoraエバンジェリスト／ソフトウェアエンジニアの江島健太郎が，GPT-3を使った新しいアプリケーションを開発している。ドキュメントをアップロードしてそれとチャットするという単純なものだ。そのドキュメントからword2vecで意味的に質問に近い部分を見つけ，これを取り出してGPT-3に要約させるというのが肝らしい。ポイントはインターフェースとしてのAI-Chatというコンセプトだ。ほとんどの企業や組織ではこうした業務（エンターブライズサーチ）が存在しているので，うまくいけば大当たりする可能性もある。

清水亮もそうだったけれど，目端の聞くソフトウェアエンジニアや企業家は，一斉に生成AIに群がっている。既存サービス業の置き換えだとしても数百兆円のビジネス機会が眠っているが，LLMを開発できる技術者の数は限られているので，ニッチ市場はまったく埋りきらない。今がチャンスだ。

ChatGPTや新しいAI-Chatシステムが普及するとき，既存のWeb+検索のネットワークそれ自身が大きな影響を受ける可能性がある。インターネット草創期のgopherで到達できたftpアーカイブのような1次情報のネットワークさえあれば，SNSなどの2次情報によるシンタックスシュガーは不要で，これら原データを直接取り込んだAI-Chatシステムだけが残るという未来だ。しかも，Synthetic Data（合成データ） の普及によって，必ずしも人間が作ったウェブコンテンツがなくてもAIは学習できるのだった。

行政文書

参議院議員の小西洋之（1972-）が総務省から入手して公開した放送法の政治的公平性解釈を巡る文書（2014年）の件である。

当時の総務大臣であった，経済安全保障担当大臣の高市早苗（1961-）が，参議院予算委員会の質疑の場でそれは捏造文書だと決めつけた。もし真正な文書なら大臣も議員もやめると大見えを切った数日後，現総務大臣の松本剛明（1961-）が行政文書であることを認めて政治的公平に関する文書（78p）として公開した。高市はさっそく議論のポイントをずらしながら逃げ切りを図っている。

もし仮にその行政文書が捏造であるならば，作成当時の総務大臣である高市早苗に責任があることになるのだが，まるで他人事のように，自分の名前が出てくる4ヶ所はでっち上げであると強弁している。どこかでみたと思ったら，大阪維新の橋下に始まり，松井，吉村の常套手段だった。自分が行政の責任者にもかかわらず，大阪府や市の行政担当者をあからさまに非難・攻撃してポピュリズム的な溜飲を下げる手口だ。今回とは少し種類や性質が違うにせよ，行政の責任体系の破壊という意味では共通だ。

行政文書は公文書等の管理に関する法律の第二条４項で次のように定義されている。

この法律において「行政文書」とは、行政機関の職員が職務上作成し、又は取得した文書（図画及び電磁的記録（電子的方式、磁気的方式その他人の知覚によっては認識することができない方式で作られた記録をいう。以下同じ。）を含む。第十九条を除き、以下同じ。）であって、当該行政機関の職員が組織的に用いるものとして、当該行政機関が保有しているものをいう。ただし、次に掲げるものを除く。

一　官報、白書、新聞、雑誌、書籍その他不特定多数の者に販売することを目的として発行されるもの

二　特定歴史公文書等

三　政令で定める研究所その他の施設において、政令で定めるところにより、歴史的若しくは文化的な資料又は学術研究用の資料として特別の管理がされているもの（前号に掲げるものを除く。）

この行政文書と独立行政法人が管理する法人文書および特定歴史的公文書の総称が公文書ということになる。

この法律の第十条では各省庁での行政文書管理のために，行政文書管理規則を定めることになっている。総務省の場合は，公文書管理のページの中に，総務省行政管理規則（2011.4）が公開されている。

この第12条に文書主義についての項がある。

(文書主義の原則)

第12条 職員は、文書管理者の指示に従い、法第4条の規定に基づき、法第1

条の目的の達成に資するため、総務省における経緯も含めた意思決定に至る 過程並びに総務省の事務及び事業の実績を合理的に跡付け、又は検証するこ とができるよう、処理に係る事案が軽微なものである場合を除き、文書を作成 しなければならない。

これが正しく機能していたおかげで，磯崎陽輔（1957-）が，放送法における政治的公平性の解釈を恣意的に変更しようと強要した過程が記録されることになった。松本総務大臣及び総務省は，礒崎−安倍−高市ラインの当時の蠢動は，公平性の解釈変更ではなく補充的説明であると言い張っている。普通に考えると，解釈変更であり，実際に発動はしていなくともその効果によって，テレビ界の言論が大きく萎縮しているのは間違いない。日曜のサンデーモーニングでは，このニュースは末尾に少しだけ取り上げられたが，強い意思表明などは全くなかった。

面倒なのは，奈良県知事選挙で高市が総務完了崩れを推選して奈良県自民党の分裂をまねいていることだ。天理市長は，反現知事派＝高市派だしなあ。

2000.12 女性国際戦犯法廷

2001.01 NHK ETV特集「戦争をどう裁くか／問われる戦時性暴力」

　　　中川昭一（1953-2009）・安倍晋三（1954-2022）による圧力

2006.09 第一次安倍内閣発足（-2007.09）

2007.07 礒崎陽輔が参議院議員（大分県選挙区-2019.07）

2012.12 第二次安倍内閣発足（-2020.09）

2013.12 国家安全保障会議の設置

2014.04 礒崎陽輔が内閣総理大臣補佐官（-2015.10）

2014.11.20 「選挙時期における報道の公平中立ならびに公正の確保についてのお願い」

　　　　　自由民主党筆頭副幹事長 萩生田光一・報道局長 福井照

2014.11.21 衆議院解散

2014.11.26 礒崎陽輔から総務省放送政策課へのアクション開始

2014.12.14 衆議院選挙

2015.05 高市総務大臣が参議院総務委員会で調整版回答を答弁

［１］橋下劇場に関する批判的評論の分析 −ポピュリズム研究の進展のために−（有馬晋作）

［２］放送事業規制の日米比較と日本の問題点（鶴田達成）

［３］我が国のメディアの現状と課題（黒須俊夫）

［４］日本版公正原則の現在（魚住真司）

［５］「国民投票運動のための広告放送」等に関する資料（衆議院）

プログラミング遍歴（２）

プログラミング遍歴（１）からの続き

(4) Mathematica：

Mathematicaについては既に書いているので，少し捕捉しておく。物理数学だったか計算物理だったかの授業で，Mathematicaを何年か授業で教えていたことがある。情報処理センターでは，キャンパスライセンスが導入されていて，実習室のMac（一時 Silicon Graphics のIndigo?）を使って，一通りの基礎的文法から微分方程式までをカバーしていた。

その経験があったので，卒業生の杉木君が尼崎小田高校のSSHの担当のときに，柏原キャンパスで高校生対象の1-2日のMathematica実習を実施した。尼崎小田高校では出前授業でMathematica/Excel?を使ったケーキカップの落下実験をとりあげたこともある。

(5) Perl：

インターネットの教育利用についてをテーマとするようになったのは，1994年からだ。1995年から7年ほどの黎明期に，インターネットと教育という教育利用サイトのリンクリストを運営していたが，それと連動して，全国の学校に対するアンケート調査を実施していた。今ならば絶対にアウトになりそうなやつだ。

まだ，数が少なかった学校のウェブページをクロールして，何階層かをダウンロードする。そこからメールアドレスをとり出して，ここに年１回アンケートを送り付ける。この処理にperlを用いた。wgetやlynxで入手したHTMLファイルからメールアドレスを切り出して，ユニークなものにすること。メールアドレスのデータをまとめて自動的にメール送信すること。こうした処理には，当時はPerlが最適任だったのだ。

(6) Julia：

もう退職が近づいてきたころに出会ったのがJuliaだった。スーパーコンピュータでガリガリの並列計算をするような仕事には縁遠くなってしまったので，Julia程度の軽快で高機能なプログラミング言語は大変有難かった。Mathematicaほどの自由度にはかけるが，手続き的プログラミングでは，Juliaの方が使いやすいので，現在はこの両者を使いわけている。COVID-19のシミュレーションはJuliaで，北朝鮮ミサイルのシミュレーションはMathematicaでという具合だ。

プログラミング遍歴（１）

(1) FORTRAN：

高校理数科のとき，試験にも出たFORTRANは座学だけで学んだ，というか聞きかじった程度。参考書というわけでもないが，興味があって自分で買ったのが電子計算機と人間だったけれど，これを読んでもさっぱり分からない。テレビでは，森口繁一（1916-2002）のNHKコンピュータ講座フォートラン入門をやっていたが，これもたまにチラ見する程度で何が何だかやっぱりよく分からない。

阪大の物理学科に入ると，初年次セミナーというのがあった。意欲的な同級生らは，バークレーの統計力学やFORTRAN入門にエントリーしていた。自分は億劫でどれにも参加しなかったが，学籍番号が隣の越湖直人君が，FORTRANのプログラミングで，銀河系形成のシミュレーションをやっていると聞いた。残念ながら最終結果を得るにはリソースが足りなかったようだ。

さて，その森口繁一のJIS FORTRAN入門の第2版上下を買ってしばらくしてから，大学4年の村岡光男先生の数値計算法で，はじめてのFORTRANプログラミングを体験することになる。文法の説明が数回あった後に，課題に取り組んだ。豊中データステーションの様子は以前に書いたとおりだ。いくつかの課題があって，そのうち2つを選択してレポートとして提出すれば単位がもらえる。

最初の課題は単純な四則演算の組み合わせだったのでそれを選択したものが多かった。それではつまらないと思い，5次方程式の解法と行列の対角化の2課題に取り組んだ。それぞれについて結果を出した自信があったが，後で考えるとどうも答えが間違っている。実際，村岡研に進んだ楠本君から，当時の成績が悪かったらしいと聞くことになる。

そんなわけで，大学院に進学して修士論文に取り組み始めてからも，なかなか研究がはかどらない。業をにやした大坪先生が，簡単なルンゲクッタ法のプログラムを作ってみるように指示し，教育的配慮でほめてくれたので，それをきっかけに，FORTRANプログラミングへの抵抗はなくなった。

こうして，修士課程以降は2000年ごろまでは，普通にFortran77を研究に使っていた。1990年代には京大の総合人間学部（旧教養部）の科目の非常勤でFortran77の実習も担当した。そんなわけで，Macを使うようになっても，長らくabsoft Fortranのライセンスを維持していたけれど，実際にはほとんど使うことはなかった。absoft Pro Fortranは2022年の8月に販売終了していた。

(2) BASIC：

大阪教育大学に勤めてまもなく研究室に導入したパーソナルコンピュータが，NECのPC-9801だった。これにはN88BASICがROMでプレインストールされていて，OSのように使われた。アプリケーションソフトもまだ高額だったので，BASICがなければパソコンが使いこなせない。学生の卒論もBASICで計算していたし，授業や公開講座などでも良く使った。

もっとも，最初に，BASICに出会ったのは，1980年ごろに阪大附属図書館でアルバイトをしていたときに，図書館2Fの事務室に導入されたOKIのif800のBASICだった。チラッと眺めたけれど，四則演算は分かるがグラフィックスが皆目見当がつかない。同じアルバイトで1-2学年下の化学の学生が，スラスラと図形を表示させているのにビックリしてしまった。

さて，そのNECのBASICである。BASICコンパイラなども使ったけれど，自分の研究のための計算をすることはほとんどなかった。卒論にもそれほど使い込んだ記憶がない。そうこうしているうちに，8087に対応したTurbo Pascal 3.0 がやってきたからだ。非常に快適なプログラム作成環境で，コンパイルのスピードにほれぼれしていた。これは，斎藤昌久君が，グラフ作成ツールなどを作ってくれて重宝した。

BASICではないが，PC-9801に8087数値演算プロセッサを積んだころ，その能力を活かそうと，8080+8087のアセンブリ言語プログラミングに取り組んだ。当時のパソコン雑誌にはこうした記事がたくさんあったので，素人でも簡単に手を出すことができた。Clebsh Gordan係数やRacah係数のコードを作り，BASICと組み合わせて連立方程式の計算を高速で実行するというあたりで，若松正志さんにそれで何をしますかと聞かれて，そうですね・・・と終了を迎えることになった。

(3) C:

C言語は，カーニハン・リッチーのプログラミング言語Ｃ（石田晴久訳）を買って少しだけ勉強した。そのころは，Lattice C，LightSpeed C/Think C，Turbo C など，あまたのC言語処理系が乱立していた。Oh PC にはCとアセンブリ言語の中間のようなコンパクト言語なども掲載されている時代だ。で，さきに述べたように，ポインタのあたりでつまづいてサンプルプログラムを越えるものは作れなかった。

UNIX時間（６）

UNIX時間（５）からの続き

世界で活躍し『日本』を発信する日本人の一人にも選ばれている，まつもとゆきひろ（松本行弘）さんが作った ruby（1995-）は，日本発のオブジェクト指向スクリプト言語だ。ウェブアプリケーションフレームワークのRuby on Rails まで進めば御利益が多そうだけれど，近づいたことはないので，小波英雄さんが京都女子大のプログラミング教育で使っていたPerlの後継言語といった印象を持っていた。

一方のRust（2010-）は，評判だけ耳にしていた。この度改めて一からインストールして試してみた。日曜プログラマがちょっと遊んでみるには敷居が高いのかもしれない。C++代替を目指している現代的なプログラミング言語で，プロの評判は一番だけれど習得しにくさもトップレベルという面倒なやつ。

BingChatに，「rustを使って次の内容を実行する１つのプログラムを書いてください。 (1) 現在時刻をミリ秒単位まで取得して年月日時分秒の形式で表示する。 (2) (1) の結果をUNIX時間へ変換して表示する。 (3) UNIX時間=0に対応する年月日時分秒を表示する。 (4) UNIX時間=2**31-1（or 2^31-1）に対応する年月日時分秒を表示する。」と指示したところ，次のまともに動作するプログラムが出力された（コメントのみ手を入れている）。

#!/usr/bin/ruby

require "time"

## msec単位の現時刻

tn =  Time.now

tm = tn.iso8601(3)

p tm

## 年月日時分への変更

t = Time.now.to_i

d = Time.at(t).strftime("%Y/%m/%d %H:%M:%S")

p d

## UNIX時間への変更

t =  Time.parse(d).to_i

p t

## UNIX基準時

t = 0

d = Time.at(t)

p t,d

## 2038年問題

t = 2**31-1

d = Time.at(t)

p t,d

use std::time::{SystemTime,UNIX_EPOCH};

use chrono::{DateTime,Utc,Local};

fn main() {

// 現在日時の取得（ミリ秒）

//    let datetime = DateTime::<Utc>::from(now);

    let now = SystemTime::now();

    let datetime = DateTime::<Local>::from(now);

    println!("現在時刻: {}", datetime.format("%Y-%m-%d %H:%M:%S%.3f"));

// UNIX時間への変換

    let unix_time = now.duration_since(UNIX_EPOCH).expect("Time went backwards").as_millis();

    println!("UNIX時間: {}", unix_time);

// UNIX基準時

    let zero_time = UNIX_EPOCH;

    let zero_datetime = DateTime::<Utc>::from(zero_time);

    println!("UNIX時間=0: {}", zero_datetime.format("%Y-%m-%d %H:%M:%S%.3f"));

// 2038年問題

    let max_unix_time = UNIX_EPOCH + std::time::Duration::from_secs((2u64.pow(31)) - 1);

    let max_unix_datetime = DateTime::<Utc>::from(max_unix_time);

    println!("UNIX時間=2^31-1: {}", max_unix_datetime.format("%Y-%m-%d %H:%M:%S%.3f"));

}

Rustは次のようにインストールした。Cargoというビルドシステム兼パッケージマネージャを使うのが普通らしい。

% brew install rustup-init

% rustup-init

% source "$HOME/.cargo/env"

% which rustup

~/.cargo/bin/rustup

% rustup --version

rustup 1.25.2 (2023-02-01)

% which rustc

~/.cargo/bin/rustc

% rustc --version

rustc 1.67.1 (d5a82bbd2 2023-02-07)

% which cargo

~/.cargo/bin/cargo

% cargo --version

cargo 1.67.1 (8ecd4f20a 2023-01-10)

% cargo new hello_rust

% cd hello_rust

% cargo run

   Compiling hello_rust v0.1.0 (~/code/hello_rust)

    Finished dev [unoptimized + debuginfo] target(s) in 0.64s

     Running `target/debug/hello_rust`

% cargo install cargo-edit

% cargo install cargo-watch

% rustup component add rustfmt

% rustup component add clippy

% rustup component add rls rust-src rust-analysis

% rustup update stable

$ rustup doc

file://~/.rustup/toolchains/stable-aarch64-apple-darwin/share/doc/rust/html/rust-by-example/index.html

UNIX時間（５）

UNIX時間（４）からの続き

いつの間にか，Python（1991-）がプログラミング言語の主役に躍り出ていた。Jupyterでも使えるので，環境は整っている。一方のPerl（1987-）は，今ではオブジェクト指向のRuby（1995-）に取って代わられたのかもしれない。

最初に，Pythonという言葉を耳にしたのは「インターネットと教育」祭の最終段階のころだったか。誰かが，Zope（1999-）というPythonで書かれたすごいシステムがあって何でもできるような話をしていたころだ。それがどこかでCMSのPlone（2001-）につながるのだが，そのデザインに引かれて，自分でもポータルサイトに使いかけていたことがあった。

#! /Users/koshi/bin/python

#

import datetime

import pytz

import time

#

# 現在のUNIX時間を出力

unix_time = int(time.time())

print(unix_time)

print(datetime.datetime.fromtimestamp(unix_time))

# UNIX時間に変換

ud = datetime.datetime(1973, 9, 20, 6, 0, 0, 0)

tz = pytz.timezone("Asia/Tokyo")

ud = tz.localize(ud)

ut = ud.timestamp()

print(ut)

# 年月日日時分に変換

ud=datetime.datetime.fromtimestamp(ut)

print(ud)

# UNIX基準時

n = 0

print(n)

print(datetime.datetime.fromtimestamp(n))

# 2038年問題

n = 2**31-1

print(n)

print(datetime.datetime.fromtimestamp(n))

#!/usr/bin/perl

#

use strict;

use warnings;

use Time::Local 'timelocal';

use Time::HiRes 'gettimeofday';

my $ut = 0;

my ($msec, $sec, $min, $hour, $day, $month, $year) = shift;

# 現在時刻の取得

($year, $month, $day, $hour, $min, $sec, $msec) = getCurrentTimeStr();

printf("JST: %04d/%02d/%02d %02d:%02d:%02d.%003d\n", $year ,$month, $day, $hour, $min, $sec, $msec);

# UNIX時間への変換

$ut = timelocal($sec, $min, $hour, $day, $month-1, $year);

print($ut,"\n");

# 年月日時分秒への変換

getDateTimeStr($ut);

# UNIX基準時

$ut = 0;

print($ut,"\n");

getDateTimeStr($ut);

# 2038年問題

$ut = 2**31-1;

print($ut,"\n");

getDateTimeStr($ut);

exit 0;

sub getCurrentTimeStr {

    my ($epochSec, $microSec) = gettimeofday();

    my ($sec, $min, $hour, $day, $month, $year) = localtime($epochSec);

    $year += 1900;

    $month++;

    return ($year,$month,$day,$hour,$min,$sec,$microSec)

}

sub getDateTimeStr {

($sec, $min, $hour, $day, $month, $year) = localtime($ut);

$year += 1900; $month += 1;

printf("JST: %04d/%02d/%02d %02d:%02d:%02d\n", $year ,$month, $day, $hour, $min, $sec);

}

炭素年代測定法

ヤポネシアからの続き

14Cを用いた，炭素年代測定法について。

炭素14（0+1）から窒素14（1+0）へのガモフテラーベータ(−)崩壊の半減期5730年(1.81*10^11 s)は，アイソバリックアナログ状態の酸素14（0+1）から窒素14（1+0）のベータ(＋)崩壊/電子捕獲の半減期70.6秒に比べると9桁ほどと圧倒的に大きい。その理由は次のように説明される。

β+崩壊の方は，ほとんどが，0+1→0+0励起状態の許容フェルミ遷移になるため，1+0基底状態への分岐比は0.61%である。これを補正すれば 4桁回復する。また，遷移エネルギー差が大きく影響する位相空間からくる寄与（f値）を計算してみれば 4桁の差が縮まる。これらを考慮すると，荷電対称性から1になるべき遷移行列要素の比率が1桁以内に収まる（それでも結構な違いが残る）。

炭素年代測定法は，授業の課題でもたびたび取り上げたし，AMS（加速器質量分析）の話題とからめて入試問題も作成したので，馴染のはずだった。ところが，縄文人のDNA分析の話の中で，重要な補正項があることを始めて知った。

地球の炭素循環は大気圏，表層海洋圏，深層海洋圏，陸上生物圏，海洋生物圏などのブロックに分割できるが，それぞれの部分に蓄えられる炭素の割合と，その拡散時間が異なっている。そこで，これらの炭素リザーバーの効果を適切に評価する必要がある。例えば，海洋生物を主に食べているヒトの炭素では，深層海洋圏に長くとどまることで14Cの割合が減少した炭素が海洋生物圏に達し，その割合が大きくなることから，年代推定に影響を与えることになる等々。

ヤポネシア

ヤポネシアは，戦後奄美大島に住んだ作家の島尾俊雄（1917-1986）が考えた造語だ。 樺太や千島列島から日本本土，琉球列島までの地理上の日本列島弧を指す。

学術用語としても定着しており，2018年度から2022年度までの科研費の新学術研究で「ゲノム配列を核としたヤポネシア人の起源と成立の解明」というテーマの研究が進められている。研究代表者の国立遺伝学研究所，斎藤成也さんの講演をいくつかYouTubeで見ることができる。

大陸と陸続きだった日本列島に最初に住み着いたのが狩猟生活をしていた縄文人で，その後朝鮮半島や琉球列島などを経由して渡来した弥生人が農耕文化をもたらした。縄文人は北海道のアイヌと沖縄にその血を濃く残しているというのが，これまでのボンヤリした理解だった。これが，東大の埴原和郎（1927-2004）による二重構造説らしい。

それが，DNAのゲノム解析の技術が進んだことで，縄文人や弥生人や古墳人のDNA解析が進み，この三者がはっきりと異なる特徴を持っていることが明らかになり，日本人の起源は二重構造ではなく三重構造ではないかというのが最近の研究成果らしい。この場合，古墳人につながる集団は弥生時代の日本に様々な技術を持ち込んで，卑弥呼によるヤマト王権の成立につながることになる。

図：縄文人，弥生人，古墳人，現代人の遺伝的特徴

（Ancient genomics reveals tripartite origins of Japanese populations から引用）

この論文では，金沢市の岩出横穴墓の古墳人のデータが用いられている。小学校の修学旅行では，安宅の関や実盛の首洗い池とともに，加賀市の法皇山横穴古墳を訪ねているが，ここも古墳時代のかなり大規模な古墳群である。

［１］ヤポネシア人のゲノム解析（斎藤成也，生体の科学 2020）
［２］私たちは何者か～DNAで迫る現代日本人への道（NHK 2021 ）

［３］パレオゲノミクスで解明された日本人の三重構造（金沢大学 2021）

UNIX時間（４）

UNIX時間（３）からの続き

昔憧れていた（しかも一度も使ったことがない）S言語（1984-）の流れを汲むR言語（1993-）は統計処理を得意としており，ほとんど使わないがなんとなく手放せない。macOSで起動すれば，Rの実行環境あるいはRStudioでの処理となる。コマンドラインではどうなるかというと，homebrewに rscript というインタープリタが導入されていた。

Processing（2001-）はグラフィックスやアニメーションに秀でており，Arduino などのワンボードマイコンの処理系としても登場する。Javaのアプレットとして取り出せないこともないが，基本的にはProcessing実行環境の中が舞台だ。p5.jsというJavascriptライブラリを使うと，このProcessingに相似した言語（まったく同じかと期待したがそうではなかった）でJavascriptを操ることが出来る。これによって，プログラムを実行環境の外へ取り出せたようにも見えるが，実際にはなんだかまだるっこしい。

そこで，代わりにコマンドラインで使える TypeScript（2012-）を使うことにする（Processingはどこへ行ったのだろう）。macOSでのTypeScriptでは，.tsファイルを作成した後，tsc で .jsファイルを生成し，nodeで .jsファイルを実行することが出来る。一方，ts-nodeコマンドを使えば， .ts ファイルをスクリプトとして直ちに実行することも可能だ。

#! /opt/homebrew/bin/rscript

#

library(lubridate)

options(digits.secs=3)

#現在時刻の取得（ms単位）

dt <- now(tzone = "Asia/Tokyo")

dt

dt <- Sys.time()

dt

#UNIX時間へ変換

dt <- as.POSIXlt("1973-09-20 12:34:56.789 JST")

dt

ut <- as.numeric(as.POSIXlt(dt))

ut

#年月日時分秒へ変換

dt <- as_datetime(ut, tz="Asia/Tokyo")

dt

#UNIX基準時（JST）

as.numeric(as.POSIXlt("1970-01-01 09:00:00 JST"))

as_datetime(0, tz="UTC")

#2038年問題（JST）

as.numeric(as.POSIXlt("2038-01-19 12:14:08 JST"))

as_datetime(2**31, tz="UTC")

#! /opt/homebrew/bin/ts-node

//

// 現在時刻を取得する (ミリ秒単位)

var date = new Date()

console.log(date.toISOString())

var time = date.getTime()

console.log(time)

// UNIX時間への変更

var date = new Date(Date.parse('1973-09-20T12:34:56.789Z'))

var time = date.getTime()

console.log(time)

// 年月日日時分への変更

var date = new Date(time);

console.log(date);

// UNIX基準時

var n0 = 0;

console.log(n0);

var t0 = new Date(n0);

console.log(t0)

// 2038年問題

var n8 = 2**31-1;

console.log(n8);

var t8 = new Date(n8*1000);

console.log(t8);

UNIX時間（３）

小学校でプログラミング教育などともがいているうちに，時代は，プロンプト工学（Wikipediaに中文はあるが日本語はない）へ向かう。AI Chat で使う自然言語である英語自身がこれから最も重要なプログラミング言語になるという怪しいうわさが流れている。日本語は，もとのドキュメント量が1桁少なくて，良質の結果を得られない三流プログラミング言語になろうとしている。

そこで時代に逆行して，いろいろなプログラミング言語の表層入門 のために，UNIX時間を出力するコードを調べている。頭がぐちゃぐちゃになってどれもこれも身につかないところが楽しい。まあ，40年前にカーニハン・リッチーのポインタでつまずいて，Turbo Pascalで少し息を吹き返したころから，自分の進歩は止まっているのだ。

第1回ではお気に入りのWolfram 言語とJulia，第2回ではFortran95を取り上げたので，今回は，C++（1983-）とSwift（2014-）である。Cに挫折しているのでC++も同じようになりそうだし，Appleの最新言語Swiftだとどうなることか。Swiftはスクリプト言語（swift）としてもコンパイラ言語（swiftc）としても使えるところがありがたい。なお，Apple M1 macOS場合，cppではエラーが起きるので c++ でコンパイルする必要があった。あと，swiftの拡張子が.swiftというのも少しだるい。

#include <iostream>

#include <sys/time.h>

#include <cmath>

using std::cout; using std::endl;

int main() {

    struct timeval ima;

    time_t ut, ut0, ut8;

    struct tm t;

    struct tm t0 = { 0, 0, 9, 1, 0, 70, -1 };

    struct tm t8 = { 7, 14, 12, 18, 0, 123, -1 };

//現在時刻の取得（msec）

    gettimeofday(&ima, nullptr);

    time_t mnow = (ima.tv_sec * 1000) + (ima.tv_usec / 1000);

    cout << "  msec since epoch: " << mnow << endl << endl;

//UNIX時間へ変換

    ut = time(nullptr);

    cout << "  unixtime: " << ut << endl;

//年月日時刻へ変換

    cout << "  day-time: " << ctime(&ut) << endl;

//UNIX基準時（JST）

    ut0 = mktime(&t0); // ut0 = 0

    cout << "  unixtime: " << ut0 << endl;

    cout << "  day-time: " << ctime(&ut0) << endl;

//2038年問題（JST）

    ut8 = mktime(&t8); // ut8 = 2^31-1

    cout << "  unixtime: " << ut8 << endl;

    cout << "  dat-time: " << ctime(&ut8) << endl;

    return EXIT_SUCCESS;

}

#! /usr/bin/swift

import Foundation

//現在時刻の取得（msec）

let date: Date = Date()

let unixtime: Int64 = Int64(date.timeIntervalSince1970)

let utime_ms: Int64 = Int64(date.timeIntervalSince1970*1000)

print(utime_ms)

//UNIX時間へ変換

var time = TimeInterval(integerLiteral: unixtime)

print(time)

//年月日時分秒へ変換（GMT）

var day = Date(timeIntervalSince1970: time)

print(day)

//UNIX基準時（GMT）

var zt = Int64(0)

var ut = TimeInterval(integerLiteral: zt)

var ud = Date(timeIntervalSince1970: ut)

print(ut)

print(ud)

//2038年問題（GMT）

zt = Int64(pow(2,Double(31)))-1

ut = TimeInterval(integerLiteral: zt)

ud = Date(timeIntervalSince1970: ut)

print(ut)

print(ud)

C++の構造体に代入しようとして四苦八苦した。C言語の系列は includeファイルが面倒なので，どうも好きになれない。情報が沢山あるのはありがたいのだけれど。Swiftは，Appleから出ているドキュメントがわかりにくいので，これも好きになれないかも。

レコード煎餅

水木十五堂からの続き

第11回水木十五堂賞授賞式のやまと郡山城ホールには，桂文我が収集した落語関係資料の一部が公開されていた。その中に，桂春団治の煎餅缶というのがあったがサラッと通り過ぎた。

帰ってから調べてみると，それはなんとレコード煎餅というものだった。必ずしも確かではないネット情報とYouTubeでの桂文我自身の話を組み合わせると次のようなことらしい。

まず，Wikipediaのレコードの項には次のようにある。

1924年に神戸で煎餅レコードが販売されていた。タイヘイレコード設立者の森垣二郎が作ったものとされ，童謡が収録されていた。これを見た落語家の初代桂春団治（1878-1934）が1925年に，今度は大阪市の住吉区にあった「ニットーレコード（日東蓄音機）」の協力のもと，やはり煎餅レコードを作った。湿気ない様に缶にパッケージされていた。春団治のレコードの価格は8枚入りの1缶が1円50銭，10枚入りの1缶が1円95銭だった[19][20]。1926年1月に天理教の大祭の人出の多さを当て込んで売り出されたが，値段の高さや，あいにくの雨で煎餅の多くが湿気ったことなどでほとんど売れず，春団治は大損した。落語やコントなどが収録され，「聴き飽きたら食べる」というコンセプトだった。

　一方，次のような話もある［2］。

せんべいで作ったレコードは大正期の終わりに京都市内のお菓子屋が始めたという。実際に制作されたせんべいのレコードは兵庫・神戸市にある有馬温泉名物の温泉せんべいのように表面がすべすべしたもので，水飴でコーティングしてそこに溝を入れ，竹の針を落として聴く。神戸では「桃太郎」や「金太郎」，そして「花咲かじいさん」のような童謡を吹き込んだせんべいのレコードが売られていた記録も残っていた。

（中略）

レコードは初代師匠の十八番の落語などを吹き込み，いずれも専用の竹針を入れた8枚入りと10枚入りの2種類を売り出して，「鈴鹿馬子唄」の歌詞を拝借した「昔はウマが物云う鈴鹿の関，今は煎餅で物云う春団治」というキャッチコピーで売り出した。

発売されたのは，1926年の天理教の大祭の3日間だけだったが，全国から信者が集まっていたために，缶だけが残されたものがあって，ヤフーオークションにかかった。落札価格は35万円。桂文我はその後会津若松地方で見つけたということだ。

写真：桂春団治のものいふせんべい（大和郡山市資料から引用）

［１］食べるレコード

［２］昔はせんべいで作ったレコードもあった

［３］レコードが食えるか！

［４］【噂は本当！】大正時代「せんべい」で作られた伝説のレコードがヤフオク出品‼

水木十五堂

奈良県大和郡山市が主催する水木十五堂賞というのがある。

水木要太郎（1865-1938）（雅号：十五堂）は，現在の愛媛県伊予市出身だが，東京高等師範学校を出た後，奈良県尋常師範学校の教員となって大和郡山市に住むことになる。奈良県尋常中学校（現，奈良県立郡山高等学校）の教員や奈良女子高等師範学校（現，奈良女子大学）の教授として勤めた。

大和の歴史や地誌の研究を進める一方，漢詩，和歌，俳句，書画，狂歌から茶道，演劇等を通じ，多くの文人や芸術家と交流し，幅広い分野であらゆる収集を行い，その数7,000点あまり，『水木コレクション』として，今日に受け継がれている。

中近世の古文書，近世の刊本，近世から近代の絵地図，文化人の書状など多岐にわたる膨大な資料群であり，学術的に貴重な資料も多く含まれている。

特に異彩を放つのが，『水木の大福帳』と呼ばれる半紙四分の一大の帳面であり，300冊以上にものぼる大福帳には，多くの学者や文人，芸術家などあらゆる階層の人たちが署名やコメント，似顔絵などを残している。まさに時代の息吹が直接伝わる貴重な資料である。（大和郡山市ホームページより引用）

古事記1300年を記念して，文化伝承の重要性を発信する取り組みとして大和郡山市が2012年に設けたのが水木十五堂賞だ。その今年（第11回）の受賞者が落語家の四代目桂文我であり，今日はその授賞式と記念講演会に出かけた。第4回授賞式で，辻本一英氏（阿波木偶箱回し保存会）の話を聞いて以来7年ぶりだった。

桂文我は，10万点にもおよぶ落語関係の資料を収集するとともに，埋もれた上方落語の発掘と復活を続けている。記念講演では旅ネタ「東の旅」から伊勢参宮までの一部と「三十石」の抜粋が演じられた。

記念座談会での文我の話が面白かった。落語公演日が決まると3,4日前に，ワープロで話を全部さらうのだそうだ。そして，当日はそのままには演じない。観客との相互作用＝対話によってライブの演目が形づくられていくということだった。ChatGPTのようなAI対話システムが検索に代替できるできないの議論がある。そもそも検索とは何か，知識は相互作用で構成され，ネットワークの中に維持されるものだとすれば，むしろ対話のほうが本質なのかもしれない。

写真：水木十五堂の大福帳（大和郡山市資料から引用）

天理大学附属天理図書館蔵・国立民俗博物館提供写真

［１］館蔵水木家資料中世文書（国立歴史民俗博物館）

［２］水木家資料中の中世東大寺関係文書（東京大学史料編纂所）

한글（ハングル）

韓国ドラマを見るのが習慣化しているので，ハングルや韓国・朝鮮語の勉強をしておく必要がある。doulingoで毎日少しづつ学んでいるが，なかなかおもしろい。

ハングルは，1443年に李氏朝鮮第4代国王の世宗大王が，訓民正音（朝: 훈민정음，略称: 正音）の名で公布した表音文字だ。日本の表音文字のカタカナやひらがなと異なり，陰陽五行思想の創成原理に基づいたものであり，理論的で美しいし学びやすい。macOSのHangulローマ字入力（HNC）を使うと，簡単に入力することもできる。

韓国ドラマでは漢字はほとんど出てこない。漢字復活論があると耳にしたので，Bing Chatに聞いてみると次のようなことだった。知らんけど。

漢字の利用を進めるようにという意見や、韓国政府の施策についてですね。漢字復活論は、保守新聞や学術界、保護者などが主導しています12。彼らは、漢字は文化や歴史の伝承に重要であり、また外国語学習や知的活動にも有益だと主張しています13。一方で、漢字廃止論は、ハングルだけで十分であり、漢字は民族主義や反日感情に基づいて排除されるべきだと言っています3。

韓国政府はこの問題に対して消極的な姿勢をとっており、「教えろとも教えるなとも言わない」という態度を示しています4。しかし、2019年から小学校の教材に漢字を一部復活させる方針を打ち出しました52。これは、多くの韓国人が漢字の必要性を認識し始めたことや、中国との経済関係の強化などが背景にあると考えられます56。

基本子音（14）うち激音(4)：

ㄱ (g), ㄴ (n), ㄷ (d), ㄹ (r, l), ㅁ (m), ㅂ (b), ㅅ (s), 

ㅇ (ng: x), ㅈ (j), ㅊ (ch: c), ㅋ (k), ㅌ (t), ㅍ (p), ㅎ (h)

重子音=濃音（5）：

ㅋ (kk: G), ㄸ (dd: D), ㅃ (pp:B), ㅆ (ss: S), ㅉ (jj: J)

基本母音（10）：

 ㅣ (yi: i),  ㅏ (a),  ㅑ (ya, ia),  ㅗ (o),  ㅛ (yo, io),

ㅡ (eu: w),  ㅓ (eo: e), ㅕ (yeo: ye, yie),  ㅜ (u),  ㅠ (yu), 

重母音（11）：

ㅐ (ae: ay, ai), ㅒ (yae: iai, iay, yai, yay)

ㅔ (e: ei, ey), ㅖ (ye: yei, yey) , ㅢ (wi: wi)

ㅘ (wa: oa), ㅙ (wae: oai, oay), ㅚ (oe: oi, oy)

ㅝ (wo: ue), ㅞ (we: uei, uey), ㅟ (ui: ui, uy)

終声パッチムの音価（7）：

앙 (ang); 안 (an); 암 (am); 알 (ar); 악 앜 앆 (ag)

앋 앝 앗 았 앚 앛 앟 (ad); 압 앞 (ab) 

大奥

よしながふみ原作の歴史改変ジェンダーSFマンガ大奥が，NHKでドラマ化された。あまり真面目に視聴していない大河ドラマの徳川家康よりよほどおもしろいのだ。10月にはシーズン２も予定されている。

さて，高等学校で日本史をとらなかったため，徳川歴代将軍についてもあまりよくわかっていない。そこで，Bing ChatやChatGPTに聞いてみた。

『歴代の徳川将軍について調べています。次のような形式の将軍在位順のテーブルを作ってください。｜第○代｜名前｜在位期間（16xx-17xx）｜在位年齢（30-50）｜生没年（16xx-17xx）｜父｜母｜』

何となくそれらしいアウトプットはできたもののWikipediaでチェックした（それもどうかという話だが）。半分くらいは間違っているが，そこそこの結果が出てきた，あとは手動で校正したところ，次のようになったので，テレビ視聴の参考資料とする。

第 1代｜徳川家康｜1603-1605｜在位年齢：49-51｜1543-1616｜松平広忠｜伝通院 |

第 2代｜徳川秀忠｜1605-1623｜在位年齢：26-44｜1579-1632｜徳川家康｜西郷局 |

第 3代｜徳川家光｜1623-1651｜在位年齢：19-47｜1604-1651｜徳川秀忠｜崇源院 |

第 4代｜徳川家綱｜1651-1680｜在位年齢：10-39｜1641-1680｜徳川家光｜宝樹院 |

第 5代｜徳川綱吉｜1680-1709｜在位年齢：34-63｜1646-1709｜徳川家光｜桂昌院 |

第 6代｜徳川家宣｜1709-1712｜在位年齢：47-50｜1662-1712｜徳川綱重｜長昌院 |

第 7代｜徳川家継｜1713-1716｜在位年齢： 7-10｜1709-1716｜徳川家宣｜月光院 |

第 8代｜徳川吉宗｜1716-1745｜在位年齢：32-61｜1684-1751｜徳川光貞｜浄円院 |

第 9代｜徳川家重｜1745-1760｜在位年齢：33-48｜1712-1761｜徳川吉宗｜深徳院 |

第10代｜徳川家治｜1760-1786｜在位年齢：23-49｜1737-1786｜徳川家重｜至心院 |

第11代｜徳川家斉｜1787-1837｜在位年齢：14-64｜1773-1841｜徳川治斉｜お富の方 |

第12代｜徳川家慶｜1837-1853｜在位年齢：44-60｜1793-1853｜徳川家斉｜香琳院 |

第13代｜徳川家定｜1853-1858｜在位年齢：29-34｜1824-1858｜徳川家慶｜本寿院 |

第14代｜徳川家茂｜1858-1866｜在位年齢：12-20｜1846-1866｜徳川斉順｜実成院 |

第15代｜徳川慶喜｜1867-1868｜在位年齢：30-31｜1837-1913｜徳川斉昭｜貞芳院 |

徳川家康が征夷大将軍だったのは2年ほどだったとか，家継が子供であっという間に亡くなったとか，いろいろ知らないことが多い。結局，大河ドラマの綱吉と吉宗と家定（篤姫）の記憶でしか定着していないのだった。

NHKのテレビ放送が1953年2月1日に始まって70周年だ。

wolframscript

Wolfram Engine からの続き

ChatGPTは，因数分解ができないので，Wolfram Alphaと連携すればよいという話について。

ChatGPT数学が苦手である。Stephen Wolframもそう言っている。BingChatに聞いてみると，WolframAlphaのAPIを使う必要があるようだ…というかそんなことは先刻承知。それにはライセンスが必要なので少々ためらう。何か他の方法はないものかと眺めていると，wolframscriptというWolfram言語のコマンドライン版が見つかった。

とりあえずインストールしてみようと（すでに当初の目的から話がずれつつある），確かめてみれば，自分のMacBook Air M1には既にインストール済みだった。以前，JupyterでWolfram言語を使うためにWolfram Engineを導入した時にインストールしていたらしい。うかつなことだ。

最近，Mathematica本体を立ち上げるのが億劫な場合，コマンドラインでフリーのMathicsを使うことが多かった。ただ機能はかなり制限されている。今回，はじめて wolframscript を実行してみると，Mathicsよりは大分制限が少ないというか，インストール済みのMathematica 12.0 の機能がフルに使えるのかもしれない。そこで次のような単独で実行可能なスクリプトも組めるのだった。拡張子は .wls である。

#!/usr/local/bin/wolframscript

(* ::Package:: *)

n=ToExpression[$ScriptCommandLine[[2]]]

Print[RandomInteger[{1,6},n^2]]

コマンドライン引数（文字列変数）が，$ScriptCommandLine[[2]]以下で取得できる。これを整数型に変換するために，ToExpression[] 関数を使った。これで，プログラム外から与えた変数に対して，Wolfram言語での処理が可能になる。

［１］LangChainのWolfram Alpha連携を試す（npaka）

［２］WolframScript（Wolfram言語＆システム ドキュメントセンター）

UNIX時間（２）

UNIX時間（１）からの続き

macOS上のgfortran（Fortran 95）で，UNIX時間を表示させようとしてつまづいた。

他の言語の場合，対応する組み込み関数が用意されているので簡単に実現できるのだけれど，Fortranの場合，date_and_timeという日時取得関数やsystem_clockというシステム時間取得関数などがあるが，いずれもUNIX時間には対応していない。

ChatGPTやBingChatにきいても，Fortranの場合はシステム依存性があるので処理系によってまちまちだというばかり，macOSではどうかと水を向けても思わしい答えが返ってこない。

仕方がないので，ユーザ関数として定義することにするが，適当な例題がみつからない。C言語の例ならすぐに見つかった。これをChatGPTにFortranに変換してもらったが，うまくいなかい。そもそも，例題のアルゴリズムが，西暦0年3月を起点にしてとか，UNIX日から月の算出にmonth = (unixday * 5 + 2) / 153 を使うとか技巧的すぎるのだ。

そこで，シンプルに，与えられたUNIX時間（秒）を24*60*60=86400秒で割ったUNIX日（日）から毎年の日数を引き算することにした。グレゴリオ暦のある年がうるう年かどうかの判定なら簡単である。これが負になるところが対応する年であり，足し戻したUNIX日から月単位で引き算し，これが負になるところが対応する月である。これを足し戻せば対応する日付にたどりつく。

このプログラムでは，整数を4バイト=32ビットの符号付き整数として扱っているため，2038年問題に引っかかる。ut = (2**15-1)*(2**16+1) +2**15 -9*3600 =2**31-1 -9*3600 に1加えると異常値が出ることを確かめられる。

!------- time.f95 ------- 2023.02.22 ------- K.Koshigiri -------!

!-------+-------+-------+-------+-------+-------+-------+-------!

program time_code

!-------+-------+-------+-------+-------+-------+-------+-------!

  implicit none

  integer :: dtm(8),dtm0(8),ut,ut0,jst; 

  integer(8) :: ut8

  character*10 a,b,c,fmt

!

  interface

    function dtm2ut(dtm)

      integer :: dtm(8),dtm2ut

    end function dtm2ut

    function ut2dtm(ut)

      integer :: ut2dtm(8),ut

    end function ut2dtm

  end interface

!

!現在時刻の取得

  call date_and_time(a,b,c, dtm)

  call system_clock(count=ut)

! call gtime(count=ut)

  print *, ut

  print *, ' '//a(1:4)//'-'//a(5:6)//'-'//a(7:8)

  print *, ' '//b(1:2)//':'//b(3:4)//':'//b(5:10)

  jst = dtm(4) ; print *, c, jst ; write(*, *)

!UNIX時間へ変換

  ut = dtm2ut(dtm)

  write(*,'("unixtime = ",i10)') ut

!年月日時分秒へ変換

  write(*,'(i6,"-",i2,"-",i2,i6,i3,":",i2,":",i2,".",i3)') ut2dtm(ut)

!UNIX基準時(JST)

  dtm0 = [1970,1,1,jst,9,0,0,0]

  write(*,'("unixtime = ",i11)') dtm2ut(dtm0)

  ut0 = 0

  write(*,'(i6,"-",i2,"-",i2,i6,i3,":",i2,":",i2,".",i3)') ut2dtm(ut0)

!2038年問題(JST)

  dtm = [2038,1,19,jst,12,14,7,0]

  write(*,'("unixtime = ",i11)') dtm2ut(dtm)

  ut = (2**15-1)*(2**16+1) +2**15 -9*3600 

  write(*,'(i6,"-",i2,"-",i2,i6,i3,":",i2,":",i2,".",i3)') ut2dtm(ut) 

!

end program time_code

!-------+-------+-------+-------+-------+-------+-------+-------!

function dtm2ut(dtm) result(ut) 

!-------+-------+-------+-------+-------+-------+-------+-------!

! dtm=[y,m,d,dev,hour,min,sec,msec]@JST ->

! unixtime@GMT (formal seconds from 1970-1-1 00:00:00)

  implicit none

  integer :: ut, dtm(8), ud, y, m, d, hour, min, sec

  integer, parameter :: ed = 719468  ! 1970_1_1 <= 1900_1_1

  integer, parameter :: md(13) = &

  [0,31,61,92,122,153,184,214,245,275,306,337,365]

!

  y = dtm(1) ; m = dtm(2) ; d = dtm(3)

  hour = dtm(5) - 9 ; min = dtm(6) ; sec = dtm(7)

  if (m<3) then

    m = m + 12; y = y - 1

  endif

  m = m - 3 ! 0:March

  ud = y*365 + y/4 - y/100 + y/400 + md(m+1) + d - 1 - ed

  ut = (ud * 24 + hour) * 60 + min

  ut = (ut * 60 + sec)  ! return unixtime(s)

end function dtm2ut

!-------+-------+-------+-------+-------+-------+-------+-------!

function ut2dtm(ut) result(dtm)

!-------+-------+-------+-------+-------+-------+-------+-------!

! ut=unixtime to dtm[y,m,d,dev,hour,min,sec,msec] for JST

  implicit none

  integer :: dtm(8), ut, jst, ud, wd, y, m, d, hour, min, sec

  integer, parameter :: md(12) =  [31,28,31,30,31,30,31,31,30,31,30,31]

!

  interface

    function lp(y, m)

      integer :: lp, y, m

    end function lp

  end interface

!

  jst = 9*60

  ut = ut + jst*60

  sec = mod(ut, 60)

  min = mod(ut / 60, 60)

  hour = mod(ut / 3600, 24)

  ud = ut / (24*60*60)

!  wd = mod(ud + 3, 7)

!

  y = 1969

  do while (ud >= 0)

    y = y + 1 ; ud = ud - 365 - lp(y,2)

  end do

  ud = ud + 365 + lp(y,2)

!

  m = 0

  do while (ud >= 0)

    m = m + 1 ; ud = ud - md(m) - lp(y,m)

  end do

  d = ud + md(m) + lp(y,m) + 1

!

  dtm = [y,m,d,jst,hour,min,sec,0]

end function ut2dtm

!-------+-------+-------+-------+-------+-------+-------+-------!

function lp(y,m) result(leap)

!-------+-------+-------+-------+-------+-------+-------+-------!

  implicit none

  integer y, m, leap

!

  leap = 0

  if(m == 2) then

    if( mod(y,4)==0 .and. mod(y,100)/=0 .or. mod(y,400)==0 ) then

      leap = 1

    endif

  endif

end function lp

!-------+-------+-------+-------+-------+-------+-------+-------!

UNIX時間（１）

UNIX時間の定義は，「協定世界時 (UTC) での1970年1月1日午前0時0分0秒（UNIXエポック）から形式的な経過秒数として表される」 。形式的というのは閏秒の補正を含まないという意味であり，UNIX時間から現行のグレゴリオ暦に換算する際には，1日が60×60×24=86400秒として扱われる。

これを求めるプログラムを，なじみのJulia（2012-）とWolframLanguage（1988-）で書いてみるという課題を自分で考えて練習してみた。Wolfram言語では，1900年1月1日午前0時0分0秒を基準とする絶対時も用いられる。Juliaともども非常に高機能の関数が多数用意されていた。

#! /opt/homebrew/bin/julia

#

using Dates

using DateFormats

using TimeZones

#

# 現在時刻の取得

utime=Int64(round(time()))

println(utime)

#

# 年月日日時分に変換

dt_utc = unix2datetime(utime)

dt_jst = ZonedDateTime(dt_utc, tz"Asia/Tokyo") # JSTに変換

println(Dates.format(dt_jst, "yyyy-mm-dd HH:MM:SS (z)"))

#

# UNIX時間に変換

ut = datetime2unix(DateTime(dt_jst))

println(Int64(ut))

# 

# UNIX基準時（JST）

zt_utc = unix2datetime(0) 

zt_jst = ZonedDateTime(zt_utc, tz"Asia/Tokyo") # JSTに変換

println(Dates.format(zt_jst, "yyyy-mm-dd HH:MM:SS (z)"))

#

# 2038年問題（JST）

zt_utc = unix2datetime(2^31-1)

zt_jst = ZonedDateTime(zt_utc, tz"Asia/Tokyo") # JSTに変換

println(Dates.format(zt_jst, "yyyy-mm-dd HH:MM:SS (z)"))

#! /usr/local/bin/wolframscript

#

#絶対時間の出力

Print[AbsoluteTime[]]

#絶対時間原点の日付

Print[DateString[0]]

#

#現在時刻の取得（msec）

Print[DateString[{"ISODate"," ","Hour",":","Minute",":","Second",".","Millisecond"},TimeZone->"Asia/Tokyo"]]

#

#UNIX時間へ変換（JST）

Print[UnixTime[TimeZone->"Asia/Tokyo"]]

#

#年月日時分秒へ変換（JST）

Print[DateString[TimeZone->"Asia/Tokyo"]]

#

#UNIX基準時（GMT）

Print[UnixTime[FromUnixTime[0,TimeZone->0]]]

Print[DateString[FromUnixTime[0,TimeZone->0]]]

#

#2038年問題（GMT）

Print[UnixTime[FromUnixTime[2^31-1,TimeZone->0]]]

Print[DateString[FromUnixTime[2^31-1,TimeZone->0]]]

UNIX時間は，2038年1月19日に2,147,483,647 = 2^31-1 に達する（今は1,676,850,000あたり）。これが符号付き32ビット整数の最大値なので，これをオーバーフローすればコンピュータの動作が保証できない場合がある。2000年問題より深刻になる可能性があり，2038年問題といわれている。あと15年か。