一人一党党

一人一人の、一人一人による、一人一人のための政治制度を!

日本の高レベル放射性廃棄物最終処分地は、活断層の真上に選定されるのが理性的

先に北海道寿都町で応募の動きがある、高レベル放射性廃棄物の最終処分地選定。
調査だけなら、莫大な交付金を貰ってお終いという、おいしい話だが。
選定されれば当然、安全なレベルに落ち着くのに何万年もかかる放射性物質を郷里に埋めることになる。
そんな恐るべき調査への応募の動きが、北海道神恵内村でもあるようだ。
一見すると危険な賭けのようにも見えるが、最終処分地決定までは進まない理由が、神恵内村にはある。
経済産業省資源エネルギー庁の公表した「科学的特性マップ」では、村域の大半を覆う「好ましくない特性が推定される地域」が、円を描いているからだ。
不適性地域が円を描いているのは、その中心に火山があることを意味している。
富士山の宝永火口のように、火山の火口の位置は移動することがあるので、円の境界の外側と内側で、安全性が極端に異なるわけではない。
村南部の一部のみが辛うじて不適性地域の範囲からはみ出ているが、大した意味はない。
将来、地元合意の原則を国が捨てて最終処分地選定を行っても、神恵内村が選ばれることは狂気の沙汰だろう。

よって、神恵内村の調査への応募は、賭けにもならない当然の結果だ。
神恵内村商工会、頭良い。
むしろ、先に動きのあった寿都町の方が、適性地域を抱える分だけ、神恵内村と異なり最終処分地の当たる危険な賭けだ。

最後に、神恵内村のように不適性地域で占められ、最終処分地になる危険を冒さず安全に交付金をゲットできる自治体は、中央構造線断層体上にある伊方町など、他にもある。
暫くは、最終処分地への応募はこれら不適性な自治体で占められ、徐々に、ギリギリ微妙な自治体へ調査が広がるのだろう。
最終処分地に最適な自治体は、最後まで応募しない。
もし、応募した自治体に処分地を限定したら、エネルギー庁側が短気であるほど、最終処分地は不適性な危険地域に選定され易くなるわけだ。
日本の原発依存度、つまり核のごみの生成速度を考えると、エネルギー庁側に残された時間は多くない。
地元合意を前提に考えると、日本の高レベル放射性廃棄物最終処分地は、活断層の真上とか火山付近とか、狂気の沙汰になるのが理性的なのだ。

IPCが2命令多ければ、RISC系CPUの周波数当たり性能はx86のと並ぶ

CPUに使われる一般的な命令セットと言えばx86だが、最近は怪しくなっている。
後藤弘茂のWeekly海外ニュース】AppleがArmベースのSoCをMacに採用する背景 - PC Watch
https://pc.watch.impress.co.jp/docs/column/kaigai/1261696.html
それらのCPUの性能を、既存のCPUと比較したいこともあるだろう。
勿論、簡単ではない。
同じ命令のCPU同士ですら、キャッシュ容量とか各命令のレイテンシとか動作周波数の変化とかの所為で、性能は大きく変わる。
走らせるプログラムが変われば、性能差が逆転する事も珍しいことではない。
それを承知で敢えて注目すべき性能指標を挙げるとすれば、IPC(Instructions Per Cycle 動作周波数あたりの命令実行数)の最大値だろう。
他の指標のほとんどは、半導体プロセスを変えるとか小規模の手直しなどで、割と頻繁に変わるが、CPUコアの大規模な設計変更でもない限り、最大IPCはなかなか変わらない。

しかし命令セットが異なると、IPCの意味が変わってくる。
ある命令セットで2命令を要する処理が、別の命令セットでは1命令で済む場合が出てくるからだ。
同じ処理をするときに多くの命令を要する命令セットと、少ない数で済む命令セットでは、前者の方がより大きなIPCを持たなければ、後者と同等の周波数当たり性能を出せない。

件のAppleのCPUはARMの64ビット命令セットだが、ほぼ典型的なRISC命令セットらしい。
典型的なRISC命令セットでは、レジスタ間演算とメモリアクセスを同時に行う命令は、存在しない。
これに対してx86の基本命令では、演算処理とメモリアクセスを一つの命令に纏めることができる。
演算処理だけならば、RISCx86も似たような数の命令数で処理できるが、メモリアクセスが絡むと、その回数だけRISCの方が命令数が多くなる。

ところが、動作周波数1サイクル当たりで考えると、x86命令の強力なメモリアクセス表現力は過剰になる。
現在最も強力なx86のCPUですら、1サイクル当たりに処理できるメモリアクセスは2回が限度だからだ。
このため、メモリアクセス処理能力の限界により、x86のCPUのサイクル当たり処理能力は、サイクル当たり命令実行数が2命令多いRISCと同等になる。

例えば、最近のx86のCPUではIPCは4、つまり1サイクルでx86命令を4個処理できる。
演算は4命令分できるわけだ。
ところがメモリアクセスは2命令分しか処理できない。
このため、その4命令すべてにメモリアクセスが伴っている場合、2命令分のメモリアクセスは次のCPUサイクルに繰り越されてしまう。
サイクル当たりにできる処理は、RISC命令での演算4命令とメモリアクセス2命令の6命令分が限界なのだ。

x86のCPUの構造解析で有名なAgner Fog氏によると、IntelのCPUのIPCは4命令/サイクルが最大らしい。
The microarchitecture of Intel, AMD and VIA CPUs: An optimization guide for assembly programmers and compiler makers
https://www.agner.org/optimize/microarchitecture.pdf
対してAppleのCPUの最大IPCは7。
IntelよりもIPCが2ではなく3多いということは、周波数当たり処理能力では同等ではなく上回っていることになる。
動作周波数ではIntelに大差をつけられているので、動作周波数と周波数当たり処理能力の積であるAppleのCPUの性能は、現時点ではIntelより低い。
しかし、動作周波数の引き上げはIPCほどは難しくないはず。
電力消費を気にしないデスクトップ向けにAppleがCPUを出したとき、何が起こるだろう?

新型コロナでの突然の重症化の一部には予兆がある

コロナ「突然重症化した人」の驚くべき共通点 | The New York Times | 東洋経済オンライン | 経済ニュースの新基準
https://toyokeizai.net/articles/-/346423
によると、新型コロナで突然重症化する仕組みの一つが、自覚症状がないまま進行する肺炎らしい。
この仕組みの場合だと、自分では気付き辛いから重症化が突然発覚するだけで、肺炎の進行自体はもっとゆっくりしている。
だから、肺炎の進行度合いを調べれば予兆がわかる。
上の記事で紹介されている、「パルスオキシメーター」ってものを使う方法は、体温計やマスク並に手遅れのようだ。
血液中の酸素濃度測定機器「一般家庭の購入控えて」新型コロナ | NHKニュース
http://www3.nhk.or.jp/news/html/20200502/k10012414901000.html
しかし、呼吸数の多さなら、時計さえあれば自分で計って自覚できる。
呼吸の変化を自覚できない人が目立つ点は、逆に光明かもしれない。
恐らく、一見しただけでは植物の成長が分からないの同様に、変化がゆっくり過ぎるからで、肺炎の進行も同様にゆっくりしているはずで光明だ。

元気なうちに、呼吸数など正常な呼吸状態を覚えておきたい。

残念ながら、サイトカインストームとか、突然の重症化の仕組みは他にもあるかもしれない。
緊急性の高い13の症状 厚労省がリスト公表
http://www3.nhk.or.jp/news/special/coronavirus/consultation/
確実を期すなら厚労省の方がいい。
緊急には違いないけど新型コロナとは関係ないものが混じっていそうだし。
「いつもと違う、様子がおかしい」って、コロナだろうがなかろうが関係なく緊急だろう。

Inferno - MMU無しでメモリ保護

この記事は
Plan 9 Advent Calendar 2019 - Qiita
https://qiita.com/advent-calendar/2019/plan9
の21日目のために書いた。

Plan 9由来なら何でもどうぞとの事なので、このOSから派生した特異なOSについて触れてみた。
Inferno (オペレーティングシステム)
https://ja.wikipedia.org/wiki/Inferno_(%E3%82%AA%E3%83%9A%E3%83%AC%E3%83%BC%E3%83%86%E3%82%A3%E3%83%B3%E3%82%B0%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0)
自分はPlan 9に触れたことが無いので分からないが、
http://shirou.prosou.nu/emacs-wiki/Inferno.html
によると基本的にはほとんど変わらないらしい。
しかしOSの実装方法から言えば、Plan 9Windowsが同じ穴のムジナに見えるくらい、InfernoはPlan 9からかけ離れている。

近代的なOSの重要な役割の一つに、ユーザープログラムが一つくらい異常動作しても、OSや他のユーザープログラムを巻き込まずに対処できることが挙げられる。
特に、ソフトウェア開発者が自らのために作った出自を持つUnix以降のOSでは、開発途中の、言い換えればバグ入りのソフトウェアを動かすことが前提になる。
このためには幾つかの機能が必要になるが、その一つがメモリ保護だ。
OSの基幹コードのあるメモリ領域がデタラメな値で埋め尽くされれば、システムはクラッシュするだろう。
他のプログラムのメモリを読めるならば、うっかりスパイウェアを動かすことができない。
これらを防ぐために、Plan 9Windowsも大抵のUnix系OSも、メモリ管理ユニット(MMU)という回路を積んだCPUを必要とする。

一方Infernoでは、メモリ保護機能の実装にMMU回路を使わない。
というより、メモリ保護機能が無い。
Infernoではユーザープログラムをバイトコードコンパイルして仮想マシンで動かしているのだが、このコンパイル済みバイトコードを上手くイジると、OSが落ちる。
私はLinux上でのInfernoエミュレータでしか実験していないが、バイトコードからframe領域確保命令(0x05 "frame")を見つけて確保領域量を過小にするように書き換えてみたところ、未確保領域アクセスを検出してInfernoエミュレータが終了したり、自力では検出できずにLinux側のセグメンテーション違反に引っかかってエミュレータがクラッシュした。
なのに基本的にPlan 9と同じように使える理由は、そのバイトコードを出力するコンパイラにある。
Infernoに搭載されているプログラミング言語limboは、いわゆる強い型付けの言語だ。
怪しげなメモリアクセスをするソースコードコンパイルの時点で殆ど弾かれ、残りも実行時型チェック用のコードを挿入される。
つまり、Infernoのメモリ保護機能を実現しているのは、OS付属のlimboコンパイラということになる。

MMUを使わないということは、物理マシン上で直接動作するInferno OSと、他のOSのアプリケーションとして動作するInfernoエミュレータで、ほぼ同じ実装方法が使えるということだ。
近年では、MMUをユーザープログラムでも使えるCPUが増えてきたが、使用手続きがCPUやOSによって異なり、使い易いとは言い難い。
MMUを使わないOSなら、通常のユーザープログラムの範囲内の技術で実装できる。
コンパイラによってメモリ保護を行なうInfernoの手法は、OS実装の参考になるかも知れない。

・追伸
Verve (operating system) - Wikipedia
https://en.wikipedia.org/wiki/Verve_(operating_system)
Infernoと異なり、OSの受け付けるバイトコードが強い型付けの命令セットなので、怪しげなバイトコードによるOSのクラッシュを防止できる。

開発ツール開発と、独自命令セット

この記事は
アセンブラ Advent Calendar 2019 - Qiita
https://qiita.com/advent-calendar/2019/asm
の9日目のために書いた。

しかし、カテゴリが「OS」になっていて、他のカレンダーはWindows Subsystem for Linuxとか何とかBSDとかPlan 9とかを題材にしている。
それらに並んでアセンブラとは、どういうことだ?
既存のOSや開発ツールなどを使うな、ということか!

Thompson hackで示されたように、ある種のワームを最初の開発ツールに仕込んでおけば、以後の開発ツールをワームの書かれていないソースコードから構築してもワームが感染し、ワームを取り除くことができない。
勿論、ワームの感染していない開発ツールを使えばいいのだが、何メガバイトもある既存の開発ツールのバイナリを調べて、ワームの有無を判別するのは絶望的だ。
現実的な方法として、異なる二つの開発ツールの出力を比較する方法もあるのだが、二つのツールともに同一のワームに感染している場合に対応できない。
そこで究極の方法が、バイナリの調査が絶望的な既存の開発ツールは一切使わず、何バイトもないショボい開発ツールから出発するものだ。
ショボい開発ツールを使って、もう少しマシな開発ツールを作る。
これを繰り返し、最終的には十分な機能を持った開発ツールを作成することで、ワームに感染していないそれを使い、ソースコードから既存の開発ツールを再構築する。

bcompiler - Bootstrapping a simple compiler from nothing
https://github.com/certik/bcompiler
bcompilerでは、16進数で表記されたバイト列のテキストファイルを、そのバイト列通りのバイナリファイルに変換するだけのコンバータが、出発用の開発ツールだ。
コンバータのサイズは、たったの191バイト。
ワームの有無の判別どころか逆アセンブルまで、人力で何とかできそうな小ささだ。
問題は、bcompilerには移植性が全くないこと。
古き良き32bitのx86linuxにベッタリ。
しかも近年の物理マシンには、Intel Management EngineやPlatform Security Processorなどのバックドアがハードウェアで実装されている。

この移植性と物理バックドアの問題に対応したのがstage0だ。
Stage0 - Bootstrap for the Free Software
https://savannah.nongnu.org/projects/stage0/
https://github.com/oriansj/stage0
開発ツールの構築を、物理マシンではなく仮想マシン上で行なっている。
仮想マシンC言語で記述することによって、移植性を確保しているわけだ。
そして、仮想マシンは必ずしも、ソフトウェアで実装する必要はない。
stage0では仮想マシンの仕様を定めているので、その仕様を満たすようにトランジスタを並べるなりして、自分で物理マシンを用意すれば、stage0のコードがそのまま流用できる。
自作の物理マシンによって、既存の物理マシンに仕込まれているバックドアの問題を回避するわけだ。
ただし、stage0の仮想マシン命令セットは単純なものではない。
殆どの命令は4バイトだが、即値を使う命令は6バイトであり、固定長命令セットではない。
4個の汎用レジスタに同時にアクセスする命令もあり、加算命令と減算命令にそれぞれ6個のバリエーションがある。
物理マシンやFPGAによるソフトコアプロセッサどころか、インタプリタの構築も大変ではないか?

そこで私は、RISC風の仮想マシンを作ってみた。
stage0risc
https://github.com/abo-junghichi/stage0risc
命令の種類は27個しかないし、全ての命令が4バイトの固定長。
その他にも、インタプリタやソフトコアプロセッサを作り易くする工夫を加えたつもりだ。
問題は、肝心の開発ツールは未だ作っていないことだ。

さて、独自命令セットのstage0riscは冗談として、bcompilerとstage0、どちらに見込みがあるだろうか?
bcompilerの方は、現実に存在する物理マシン上で直接動作する。
対してstage0は、独自命令セットを使っているので仮想マシンを介さねばならない。
動作速度の上でbcompilerの方が圧倒的に有利だ。
しかし実際は、stage0の方がbcompilerの先を行っている。
いや、見込みではなく既に、ゴールテープを切っている。
stage0から最新のGNUツールチェーンへ至る道が出来上がっているのだ。
Mes - bootstrapping
https://bootstrapping.miraheze.org/wiki/Mes
開発のし易さの点では、後方互換性が積み重なってグチャグチャになった物理マシンの命令セットより、開発者自身謹製の独自命令セットの方が有利ということなのだろう。

累積レジスタ割付による仮想マシンの高速化

この記事は
言語実装 Advent Calendar 2019 - Qiita
https://qiita.com/advent-calendar/2019/lang_dev
の5日目のために書いた。

言語実装に興味のある人ならコンパイラにも興味があるはずで、コンパイラに興味のある人なら、一度はコンパイラを実装しようとして、コンパイル先命令セットの選択に悩むはず。
スマートフォンの枠を越えてWindowsにまでARMが進出を始めている上に、大学発の命令セットとしてRISC-VがMIPS再来の如く台頭する中、x86ベッタリのコードは恐い。
PA-RISC,Alpha,IA-64(Itanium)…、物理マシンの命令セットは製造元の都合で将来性を絶たれてしまう。
この時、JavaやInfernoのように仮想マシン命令セットに行き着くのは、言語実装に興味のある人ならよくあること。

そんな用途に最も向いていると現在私が考える仮想マシンが、「累積レジスタ割付」を前提とするレジスタマシンだ。
「累積レジスタマシン」とでも呼ぼうか。
レジスタの数に上限のない仮想レジスタマシンの一種なのだが、レジスタの性能に偏りがあり、番号の若いものほど性能が高くなるように仮想レジスタが並んでいる。
これにより、言語処理系を実行時(JIT)コンパイラと事前(AOT)コンパイラに分ける場合に、性能劣化を大きく抑えることができる。

普通の仮想レジスタマシンでは、たとえ仮想レジスタの数に上限がなくとも、どの仮想レジスタも性能が等しいという建前になっている。
このため、変数に割り付ける仮想レジスタの選択に事前コンパイラは悩まずに済む。
使用頻度が高いなどの重要な変数を置くのに、どの仮想レジスタを選んでも性能に違いは生じないからだ。
勿論、物理レジスタの数には上限があるから、全ての仮想レジスタに物理レジスタを割り付けることはできず、物理レジスタを割り付けるものとメモリで済ますものに分ける必要がある。
物理レジスタの数は物理マシンによって異なるから、仮想マシンの仕様しか知らない事前コンパイラでは物理レジスタの割付を行えず、実行時コンパイラですることになる。
が、実行時コンパイラでは、どの仮想レジスタに重要な変数が置かれているか知ることが難しい。
仮想レジスタの選択を事前コンパイラは悩まないので、デタラメに行うからだ。
実行時コンパイラの重さは事前コンパイル済みプログラムの実行時間に加算されるので、実行時コンパイルされたコードの性能向上による実行時間短縮効果を打ち消してしまいかねず、あまり強力な解析を実行時コンパイラはできない。
結果、普通の仮想レジスタマシンでは物理レジスタの活用が難しい。

これに対して累積レジスタマシンでは、仮想レジスタの性能に偏りがあるので、変数の重要性に応じた性能の仮想レジスタを割り付けることで、事前コンパイラ仮想マシン向けコードの性能を高めることができる。
2018年6月17日のブログで触れた論文は、そのようなマシンでのレジスタ割付アルゴリズムを「cumulative register allocation」と呼び4種類ほど紹介している。
"Combining Offline and Online Optimizations: Register Allocation and Method Inlining" by Hiroshi Yamauchi and Jan Vitek
https://pdfs.semanticscholar.org/9a4a/d55afd9159f037aa163cbf4a5a770a49999c.pdf
直訳すれば「累積レジスタ割付」となるだろうか。
実行時コンパイラからすれば、仮想レジスタの番号順に、重要性の高い変数が置かれているように見える。
このため、仮想レジスタへの物理レジスタ割付は簡単で、番号の若い仮想レジスタから順番に物理レジスタを割り付ければ良い。
レジスタ割付が済んでいるので、仮想命令の前後関係を考えずに命令単位でコンパイルするだけで良く、実行時コンパイラが簡単・高速になる。
事前コンパイラは重くなるが、事前コンパイルされたプログラムの実行時間には加算されないので、あまり問題にならない。

問題は、仮想マシンを介してコンパイル・実行されるコードの性能だ。
物理マシンの命令セットへ直接コンパイルする場合は、物理レジスタの数についての知識を事前コンパイラは使うことができるが、仮想マシンへの場合はそうではない。
物理レジスタ数が分かっている状態で行う通常のレジスタ割付アルゴリズムと比べて、累積レジスタ割付の出力するコードの性能はどれくらい落ちているのだろう?
先の論文では、先ほどの4種類の累積レジスタ割付アルゴリズムと、仮想マシン内の物理レジスタ数を知らされた通常のレジスタ割付でベンチマークを採っている。
それらのベンチマークを平均すると、通常のレジスタ割付に対する累積レジスタ割付の性能差は4%以内。
ベンチマークの種目によっては-6%から+10%まで幅がある。
驚くべきことに「-6%」、つまり、物理レジスタ数を分かっている通常アルゴリズムの吐いたコードよりも6%速い結果が観測されたらしい。
ベンチマークのデータ品質が悪いからとも言えるが、4%の差は誤差の範囲だろう。

先に述べたように、仮想累積レジスタマシンでの実行時コンパイラは、実行時コンパイラとしては簡単な方だ。
しかし、移植性が高くてラクチンな、純粋なインタプリタ仮想マシンを実装したいこともあるだろう。
その場合の速度はどうだろう?
結論から言えば、累積レジスタマシンはレジスタマシンの一種だから、最も高速な部類に入る。
"Virtual Machine Showdown: Stack versus Registers" by Yunhe Shi
https://scss.tcd.ie/publications/tech-reports/reports.07/TCD-CS-2007-49.pdf
勿論、レジスタ数に上限がないので、厳密には各仮想命令のoperand fieldは可変長になり、単純なインタプリタ実装では速度は得られない。
しかし、ここでも普通のレジスタマシンとの違いが効いてくる。
累積レジスタ割付により若い番号のレジスタの使用率が上がるので、大きな番号のレジスタを使う頻度は普通のレジスタマシンよりずっと少ない。
ならば、大きなレジスタを扱う仮想命令は動作の確保に留め、効率の追求は若い番号のレジスタしか扱わない仮想命令でのみ行う設計にすればどうだろうか。
例えば、同じ演算を行う仮想命令を二つずつ、若い番号のレジスタしか扱わないoperand fieldが固定長のものと、レジスタ番号に上限はないが効率の悪いものを用意するとか。
累積レジスタ割付により殆どの仮想命令は効率的な方のが使えるので、性能は殆ど落ちないだろう。

このように、コンパイル先に選ぶ仮想マシンとして累積レジスタマシンは最適だと私は考えている。
この記事がコンパイラ作成に挑戦する人の参考になれば幸いだ。

2019年参議院選挙に於ける「一人一党党」視点での各党の評価

参議院選挙も近いので、全国比例区に立候補している各党の政策を、我が「一人一党党」の興味、つまり選挙制度統治機構に絞ってまとめてみた。

政治的ねじれ現象など統治機項の問題に触れたのは、日本維新の会幸福実現党だけ。
まあ、これを解決するには、多数決の仕方を「賛成・反対」から「選択肢A,選択肢B,選択肢C,...」に変えねばならないだけでなく、憲法の定める議会・内閣の関係にも手を入れねばならない。
すると、政権をとるだけではなく憲法改正もしなければならないから、実現のハードルがとても高い。
各党が公約にできないのは無理からぬ所か。

選挙制度については、やはり、現行制度への特化が激しい主要政党にとっては、触れたくないもののようだ。
対して小政党・確認団体はどうかというと、さすがに小選挙区制を目指す団体はないようだが、幸福実現党オリーブの木構成員が中選挙区制を唱えていて、見てられない。
中選挙区制」が指すものを、この人達は分かっているのか甚だ疑問。
仮に1994年までの日本の選挙制度とするなら、一つの選挙区で当選できる人数は最大でも6人までで、7位以下の票は死ぬ。
8位以下になろうものなら泡沫候補のループに嵌るが、この人達は7位以上に滑り込む自信、いや、過信があるのだろう。
あるいは単に、選挙制度の恐ろしさを自覚していないのか?
1994年の選挙制度改正の破壊力を身を以って学んだはずの、社民党の公約は呆けてしまった。
そんな中、選挙制度に対する感性が一番鋭いのは労働者党のようだ。
共産党の主張する半端なブロック制すら許さない。

総じて、「一人一党党」の政策に最も近いのは、労働者党のようだ。
彼ら・彼女らに勝利あれ。

以下、ネタ元。
我が党に興味の無い人でも、各党の公約入手先として参考になるかも。

幸福実現党
2019年5月主要政策
http://publications.hr-party.jp/files/policy/2019/001/origin/all.pdf
「116
政治への新規参入の障壁となっている公職選挙法や政党助成法などを見直して、競争条件の公平化を図ります。

衆議院選挙制度については、死票が多いなど弊害のある小選挙区制を廃止し、中選挙区制に改めます。

118
参議院の廃止により、国政における意思決定の迅速化を図ります。
二院制を維持する場合は、参議院に「 廃法府」としての機能も持たせ、衆議院との機能分化を行うとともに、不要な法律や規制の廃止を進めます。

中選挙区制」を目指す、自信過剰な党。
統治機構について触れているところは立派だが、衆参両院のうち参議院の方を廃止するという、二者択一のうち間違った方を選んでいる。
解散総選挙中は、残った唯一の立法府である衆議院は空っぽになる。
この時を狙って有事を仕掛けられたら、超法規的措置に頼るしかない。
半数改選の参議院では、総選挙中も議員が半分残っているから、一院制の元で総選挙中でも、このような隙は生じない。

日本共産党
https://www.jcp.or.jp/web_policy/2019/06/2019-bunya44.html

衆議院選挙制度について、小選挙区比例代表並立制を廃止し、民意を正確に反映する比例代表制への抜本改革を行います。議員総定数は元に戻し、全国11ブロックを基礎とした比例代表制にすることを提案します。
参議院議員選挙制度について、総定数の削減は行わず、多様な民意が正確に反映される比例代表を中心とした選挙制度にすることを提案します。

政党助成金をもらう資格がありながら、助成制度の存続だけでなくもらうのも拒否し続ける筋金入りのこの政党がなぜ、衆議院には死票が増えるブロック分割を主張するのか理解できない。

社民党
http://www5.sdp.or.jp/election_sangiin_2019

得票率と議席率の乖離をなくし、多様な民意が反映するよう、比例代表を中心とした選挙制度に抜本改革します。

「…を中心とした」とか言葉を濁すとは、選挙制度について、理想像を持っておらず党利党略の妥協案としか理解できないからか?

・労働の解放をめざす労働者党
http://wpll-j.org/sinntoukouryoukiyaku.html

七、社会主義の勝利と共に、あるいは社会主義をめざす闘いの過程で勝ち取るべき、労働の解放をめざす労働者党の具体的な要求

3、不正で、不公正な現行選挙制度と議会運営の根本的で、徹底的な民主主義的改革の実行。

労働者、勤労者の意思が正確に表現される選挙制度の実現。一切の選挙参加及び選挙運動の規制の原則的撤廃と、労働者の自由な政治闘争の保障。小選挙区制の廃止と全国単一比例代表制の実施。衆参共に、自由で無制約の政党及び個人の選挙参加制の実現。腐敗大政党にのみ有利で、民主主義の精神に根底からもとる、不当不正の供託金制度、政党助成金制度の即時廃止。

「七 具体的な要求」には18の項目があるが、そのうち3番目にこれを持ってくるほど、この党は選挙制度・議会制度を重要視している。

オリーブの木
https://oliveparty.jp
この党は、さらに小さな複数の党の連合体であり共通政策を掲げているが、そこには選挙制度が全く触れられていない。
恐らく、戦犯は「護憲保守政党・平和の党」だ。
基本政策 | 平和の党
https://heiwanotou.com/basic

国会議員の定数と歳費削減
中選挙区制の復活
議員の文書通信交通滞在費の削減と公開
議員年金復活反対、企業団体献金の禁止

望み通り中選挙区制が復活した暁には、オリーブの木は改選議席を失うと思う。

・れいわ新選組
選挙制度・議会制度に関する政策が見つかりません。
知っている方が居られたら、コメント下さい。

NHKから国民を守る党
安楽死制度を考える会
党名から言って、選挙制度についての政策は期待できない。

公明党
https://www.komei.or.jp/campaign/sanin2019/_assets/pdf/manifesto2019.pdf
選挙制度についての言及が見つからない。

自民党
https://jimin.jp-east-2.storage.api.nifcloud.com/pdf/manifest/20190721_manifest.pdf

選挙人の投票機会を確保するため、郵便等投票制度の対象者の拡大を図ります。
また、幅広く意見を聴きながら被選挙権年齢を引下げの方向で検討するとともに、選挙運動規制等の公選法全般の見直しも進めます。

現行制度(小選挙区比例代表並立制)を変えるつもりはないようだ。

・国民民主党
https://www.dpfp.or.jp/assets/election2019/downloads/pamphlet_20190613.pdf

3. 議員定数削減と参議院選挙制度見直し
国民民主党が提出した参議院議員の定数を6減らす法案の成立を目指します。
衆参両議院のあり方を踏まえ、合区解消など参議院選挙制度の抜本的見直しを行うとともに、国会議員の定数削減など身を切る改革を進めます。

「全国一区」や「道州ブロック」ではないことから、「合区解消」が意味するのは一票の格差の問題が大きくなる「鳥取・島根や徳島・高知の分離」ということか!?
北海道民に嫌われるのは確実。

立憲民主党
https://special2019.cdp-japan.jp/rikken_vision_04/

民意が多様化・複雑化した現在の社会に対応するためには、一人ひとりの現実に真正面から向き合う政治が必要です。
参加民主主義を促進することで、多様な声を受けとめるための仕組みをつくります。
熟議に不可欠な情報やデータを厳重に管理し、情報公開の徹底と国会による行政の監視を強化します。
○20歳から立候補できるよう被選挙権年齢引き下げを行い、立候補休暇制度を創設します。

単記非移譲式投票や小選挙区制のまま被選挙権を広げたら選挙結果がどうなるか、被選挙権を広げる効果があるのか、この党は分かっていないのか?
それとも、小選挙区制の方が自分たちには有利だと信じる民主党時代の傲りか?

日本維新の会
https://o-ishin.jp/sangiin2019/common/img/manifest2019_detail.pdf

1. 身を切る改革・徹底行革、国会改革~小さく合理的、効率的な行政機構に~
(14)選挙制度改革(被選挙権年齢を 18 歳に引下げ)

7. 統治機構改革
(1)地方分権(道州制)・(究極的には)一院制・首相公選制
(2)大阪都構想の実現。グレーター東京構想を
(3)東京・大阪のツインエンジンを先頭に自立分散型国家へ
(4)消費税の地方税化。交付税制度等の見直しにより地方共有税の創設
(5)内閣の機能強化(予算編成権・組織編成権の内閣への一元化)
(6)参議院の抜本改革(自治体首長と参議院議員の兼職禁止規定を廃止)

被選挙権拡大については、立憲民主党と同じまちがい。
一院制・首相公選制」は「衆参のねじれ」とは別のねじれ現象「首相と院を別々の政党が獲る」が生じる。
アメリカなど大統領制の国々では時々起こるし、日本の地方自治体も首長と議会を別々に選挙するから、このタイプのねじれ現象が見られる。
当会の母体である大阪維新の会地方自治体に長く関わっているはずなのに、「首長と議会のねじれ」を気にしないのか?