hotchpotch/wikipedia-multilingual-ir-pairs huggingface dataset:
設計 標準設計
不特定多数の需要者に大量に住宅を供給する必要がある場合に、設計を標準化してプロジェクトごとの設計作業を最小化するために採用されたのも標準設計である。一般には、nDKといった略称で理解されている住宅タイプである。
公営住宅や公団住宅に共通する標準設計は1970年に中高層プレハブ住宅統一要項としてまとめられ、SPH (Standard of Public Housing)と呼ばれている。
その後、需要の変化に伴って抜本的な改善がなされ、各団地の個別的条件に応じて、適正な計画と合理的な生産を導き出すための標準化された空間構成手法、すなわち、
設計ルールへと発展されていった。
IBM 3340直接アクセス記憶装置で有名なウィンチェスター方式は、ディスク製造業界の標準設計となった。
設計 基本設計と実施設計
建築設計の場合、段階的に基本設計と実施設計という設計区分がある。
のように、国土交通省告示第十五号で、基本設計と実施設計の標準業務が示されている。
実施設計は、にあるとおり、基本設計にもとづき、建物の構造や設備の詳細などをつめていき、設計図（実施設計図）や仕様書作成の他、建築確認申請手続きの実施、設計図書を建主の代理で施工者に提示し、説明し、質問などに応える他、見積金額が妥当かを確認し、適切な施工者を選定するため整理し、建主に助言・進言する業務までになる。
Windows レジストリ
Windows レジストリ（英語: Windows Registry）とは、Microsoft Windows オペレーティングシステムで用いられる設定情報の階層型データベースである。システムに関するデータやアプリケーションの設定、拡張子の関連付け、ユーザーパスワードなどが保存されている。Windows 95およびWindows NT以降で主流となった。
この節では、regファイルや、レジストリの実体であるハイブのバイナリファイルフォーマットregfについても解説する。
Windows レジストリ 歴史
Windows 3.1までは、オペレーティングシステムの各種設定情報をINIファイル等の設定ファイルに保持させる方法で行われてきた。しかし、この方法では大量の設定項目を処理するには非効率的であり無駄が多いため、レジストリに置き換えられた。
現在のようにレジストリが広く用いられるようになったのはWindows 95からであるが、レジストリ自体はそれ以前、Windows 3.1のころから存在した。ただし関連付けやOLE情報など小規模な利用にとどまっていた。
Windows レジストリ アーキテクチャ
エディタ上では、レジストリはキーと値で構成され、それぞれファイルシステム上におけるフォルダ、またはファイルに相当する。そのため、キーは複数のサブキーや値を持つことができ、キーを参照する方法として、File Explorerにおけるパスに似た参照の仕方ができる（例：HKEY_LOCAL_MACHINE\Software\Microsoft\Windows）。
レジストリエディタでは、レジストリは統合階層型データベースとして仮想的に表示されているが、レジストリは実際にはハイブと呼ばれる多数のディスクファイルに保存される。HKLM\HARDWAREなど、ディスクに保存されるのではなく、システムの情報を収集し集約したハイブが存在する。また、HKCUなどディスク上の他のハイブからのショートカットとしてのハイブも存在する。
Windows レジストリ 編集
Windows 3.1ではregedit.exe、 NT系の場合、regedit.exeとregedt32.exeの2つが存在する。Windows NT 3.xや4.xのregedit.exeには複数の制限があったが、Windows XPからは制限が撤廃され、regedt32.exeも単にregedit.exeを呼び出すだけのプログラムとなった。
レジストリは階層型データベースであるため、左側のビューにはツリー構造で表示されたキーやサブキーが表示され、右側のビューには選択されたキーの値のリストが表示される。レジストリエディタは次のことができる。
INIファイル形式の構文を使用して、レジストリの一部をエクスポートおよびインポートするためのテキストベースの人間が読めるファイル。
Windows 9xおよびWindows NT 4.0では、REGEDIT4というヘッダが含まれ、Windows 2000以降では、Windows Registry Editor Version 5.00というヘッダが含まれる。また、REGEDIT4ヘッダを持つREGファイルはWindows 2000以降のシステムでも利用可能。
Windows レジストリ 編集
基本的な構文は、以下の通りである。文字列型の場合、<値型>は必要ないが、値データには、C言語同様に、バックスラッシュはもう一つバックスラッシュ（\\）をつけ、引用符は先頭にバックスラッシュ（\"）をつけて、エスケープしなければならない。
HKLM\SOFTWARE\Hogeキーにさまざまな型で値を追加する場合は、以下の通りである。
データを削除するには、削除するデータの後にマイナス記号（-）を以下のように追加する。
コマンドラインでは、複数のツール（reg.exe、regini.exe、regedit.exe）が利用可能である。
reg.exeのコマンドとその用途は次のとおりである。
PowerShellでは、フォルダと同じようにレジストリキーや値を参照することができる。
プログラムが直接レジストリを編集するための高レベルAPIがadvapi32.dllを通して公開されている。プラットフォームAPIに直接アクセスする方法があるにもかかわらず、ラッパーを公開している言語も存在する（C#やVB：Microsoft.Win32.Registry、Delphi：TRegistry）。特に有名な関数を以下に挙げる（ANSIやUnicodeの区別はしない）。
Windows レジストリ セキュリティ
Windows NT以降のレジストリの各キーは、NTFS上のファイル等と同様、細かくアクセス制御するためのセキュリティ記述子が存在する。ここでは、レジストリキー特有のアクセス制御の種類のみについて説明する。
Windows レジストリ REGFフォーマット
レジストリハイブのバイナリファイルフォーマット（REGF）は公式にはこれまで公開されたことはない。しかし、Microsoft Symbol Serverからは未公開の関数や構造体のシンボル情報が事実上公開されており、Windows Internalsブックには、レジストリとそのバイナリファイル形式の詳細が書かれているセクションが存在する。
REGFファイルには、ベースブロック（ヘッダー）と、ビンのシーケンスで構成され、1つのビンの中にはそのヘッダと断続的に割り当てられたセルが存在する。
フォーマットのバージョン、一番最初のビンのオフセット、全てのビンのサイズなどの情報が含まれた、4096バイト長（HBASE_BLOCK）のデータ。
自身のオフセット、自身のサイズなどの情報が含まれた、32バイト長（HBIN）のデータ。このデータのすぐ後にこのビンの一番最初のセルのデータが続く。
キー、サブキー、値、値データ、ACLなどレジストリエディタで表示される全てのエンティティを表し、自身のサイズと実際のバイナリデータが含まれた可変長（HCELL）のデータ（ビン内部の割り当てられていないスペースもこのデータで表される）。
Windows レジストリ バックアップ・復旧
何らかの原因によりレジストリに不正な設定が書き込まれたり、レジストリデータベースが破壊された際、システムが自動的にバックアップしたデータベースから復旧できる場合がある。Windows XPの場合、レジストリデータベースの本体は、%System%\Config\ の配下にある。システムは、%SystemRoot%\Repair\配下にWindowsのインストール完了時点の設定データベースをバックアップしているため、回復コンソールなどを使用して、ファイルをコピーすることでレジストリの設定値を戻すことができる。
Macバイナリ
Macバイナリ（英語: MacBinary）はClassic Mac OSのファイルシステム中のファイルを、そのマルチフォーク（データフォークとリソースフォーク）とメタデータ（Finder情報）を全て含んだバイナリファイルにまとめる形式（フォーマット）のひとつ。
かつては7ビットテキスト転送用のBinHexと並んでインターネット上でも用いられたが、macOS (OS X)およびHFS+の発表以降はあまり使われなくなっている。
Macバイナリ 概要
Mac OSのファイルシステムでは、一般的なファイルシステムにおける「ファイルの内容」に相当するデータフォークとメタデータを含むリソースフォークという二つのフォークがあり、そのほかに生成時刻などのメタデータを含むFinder情報がある。Finder情報にはクリエータとファイルタイプ、Finderフラグ、ウインドウ位置等が含まれている。データフォークがない場合やリソースフォークがない場合（サイズがゼロ）もある。
パソコン通信の時代において、Ward ChristensenによるXMODEMやMODEM7、Kermit、CompuServeでのAやBといったプロトコルで転送する事を仮定していた。日本でもパソコン通信等で多用された。これらには128バイト単位でデータを転送するものがあるため、MacBinaryも128バイト単位で扱えるような工夫がされている。
Macバイナリ 概要
利用形態としては、送信元の端末がMacBinaryフォーマットで転送し、転送先の端末がそれを展開してローカルのファイルシステムに保存するような方法を想定していた。実際には拡張子.binを付けたMacBinaryフォーマットのファイルに保存し、パソコン通信のサイトに置いたり電子メールで送信する方法も取られた。この場合は受信後に対応ソフトで展開した。
AppleによるHFSの仕様拡張にあわせて、MacBinary II、MacBinary IIIが公開された。
Macバイナリ フォーマットの遍歴
最初のMacBinaryは、1985年にMacBinary Working Groupによって公開された。
先頭の128バイト (MacBinary Header) 内にファイル名、Finder情報、ファイル作成時刻、ファイル更新時刻等を詰め込み、その後にデータフォーク、リソースフォークが続くフォーマットである。データフォークとリソースフォークはパディングして128バイト単位で格納する。ファイル名は63バイト迄扱う事が出来たが、当時のClassic Mac OSには31バイト制限があったので必要以上であった。日本語環境ではファイル名はMacJapaneseで保管される。
この時点ではClassic Mac OSのファイルを8ビットで転送するためには十分なフォーマットであった。
7ビット経路でASCIIに変換して転送する方式としてはBinHexがあり、MacBinaryとBinHexのどちらかを使えば十分であった。
Macバイナリ フォーマットの遍歴
MacBinary IIは1987年にMacBinary II Conferenceで合意された。先頭128バイトの未使用だった領域に拡張されたFinderフラグを格納するようにし、更にリソースフォークの後にコメントを追加出来るように改良された。
MacBinary IIIは1997年に発行された。1996年11月にAppleが公開したMac OS 8の拡張Finder情報を先頭128バイトの未使用領域に格納出来るようにしたものである。ファイル名の長さは31バイト以内でなければならないと明確化されたが、これは当時のClassic Mac OSと同じ制限であるため妥当であった。
このとき既にApple ComputerによりAppleSingleの仕様が公開されていたが普及に至らなかったため、既に浸透しているMacBinaryを拡張したわけである。
Macバイナリ 問題点
日本製のMacLHAというアーカイバでは、ファイルをMacBinaryフォーマットにしてからLHA書庫に格納するという手法を取った。これを考慮しないLHA用ソフトで展開した場合、拡張子.binの付かないMacBinaryフォーマットのファイルが出力されてしまう。
MacBinaryフォーマットのファイルは拡張子.binを付けるのが一般的であるため、ユーザはこれを展開することで本来のファイルを得ることが出来る。しかし、拡張子.binを付けず元のファイル名のままで保存されるケースもある。前述のMacLHAもこのケースに当たる。こうした場合、ユーザはMacBinaryである事に気付かず、そのままアプリケーションで開こうとしてしまう。アプリケーションによってはMacBinaryであることを自動判別して先頭128バイトを読み飛ばしてデータフォークのみを読み取るが、通常のアプリケーションではエラーになってしまう。
MacBinaryを解除するソフトウェアが多数あったが、中には先頭128バイトのMacBinary Headerを取り除くだけのものがあった。この処理法だとデータフォークの後のパディングが残っており、更にその後にリソースフォークとコメントも残ったままになるため、正しい処理とは言えない。
Macバイナリ 問題点
データフォークのみを取り出して保存するソフトウェアも多数あった。また、データフォークの他にリソースフォークを別ファイルとして保存するソフトウェアも多数あった。処理方法としてこれらは正しいと言える。しかしながら、元々リソースフォークが重要なファイルであった場合、Classic Mac OS以外のOSでは正常に扱う事が出来ない。これはMacBinaryの問題というよりも、Classic Mac OSと他のOSとの間の互換性の問題と言える。
単にClassic Mac OS間でファイルの交換するという目的では、データフォークのみを取り出す必要はなく、如何にして全ての情報を転送出来るかが問題となる。この意味ではCompact Pro、StuffIt、MacLHAといったアーカイバが有用であった。
Macバイナリ 問題点
MacBinaryではファイル名の長さは63バイトあるいは31バイトまで表現できるが、現在のmacOSのHFS+では更に長いファイル名をUnicodeで扱っており、更に多くのメタ情報が追加されているため、たとえ最新のMacBinary IIIでも不十分である。この問題の打開策としては、Apple Computerが自ら作ったAppleSingleやAppleDoubleがある。これらはUnicodeファイル名や各種メタデータを取り扱えるが、AppleSingleは単一のファイルなので対応ソフトが必要となる。AppleDoubleはClassic Mac OS固有のデータとデータフォークの2つのファイルにわけてやりとりする方法なので、Classic Mac OS以外ではデータフォークのみを扱える。
現在のmacOSでは、AppleDoubleをtarやzipでアーカイブしたり、HFS+をそのままイメージ化したdmgフォーマット等も使われている。
スカッシュ (スポーツ)
スカッシュ（英語: squash）は、ラケットを用いるインドアスポーツのひとつ。名称は、球が握りつぶせる（squash、英語で「押しつぶす」「潰れる」の意）ことから来ている。
スカッシュ (スポーツ) 概要
四方を壁に囲まれたコートと小さいゴムの球を用いて行う屋内球技であり、2名（ダブルスは4名）がラケットを使用してボールを交互に打ち合う。全ての打球は前方の壁に向かって打つ必要があるが、そのほかの壁も全て利用することができる。相手がボールを2度床にバウンドする前に前方の壁に打ち返すことができなかったり、ボールが壁に届かなかったりすると、自分の得点になる（ラリーポイント制、後述）。
コートが比較的狭く、ボールが弾まない。ボールが行く先にはどこにでも追従する必要がある。少なくとも480mmの高さに打ち返さないといけないので、勢いを殺すことはできない。
スカッシュには世界中にいくつかのバリエーションがある。アメリカでは硬式シングルスとダブルスがあり、これは硬球を使うこととコートのサイズが違っている。広めのコートと通常の球を使うダブルスも、これとは別に存在する。
スカッシュ (スポーツ) 概要
テニス等のゲームの派生として存在しているが、188ヶ国で2000万人がプレーしていると言われる。
日本では、学生の大会も盛んになり全日本学生スカッシュ選手権大会、関東学生スカッシュ選手権大会などが実施されている。全日本スカッシュ選手権大会は50回（2021年度）を数える歴史のある大会である。
高円宮憲仁親王が好んでいたスポーツの一つだった。（高円宮憲仁親王は、2002年11月21日にカナダ大使館で練習を行っていた最中に心室細動による心不全で倒れ47歳で薨去した。）
国内の第一人者としてはスカッシュ黎明期から活動し、男子スカッシュ全日本選手権9連覇、国内大会9年間無敗の149連勝前人未踏の記録を樹立した坂本聖二が知られ、彼は「スカッシュの神様」の異名を取る。
スカッシュ (スポーツ) 主なルール
正式な試合は、1ゲームを11点先取とし（10-10になったときは2点差がつくまで続ける）、これを5ゲーム行う方式（3ゲーム先取で勝利）。サーブ権に関係なく、ラリーに勝てばポイントが取れる（ラリーポイント制）。このほか、3ゲーム行う方式（2ゲーム先取で勝利）、1ゲームを15点先取や9点先取とする方式もある。9点先取の方式では、サーブ権がある時にラリーに勝った時のみにポイントが取れる（ハンドアウト制）。レシーバ側がラリーに勝った場合は、サーブ権のみが移動する。
最初の1球は（ゲームの始めと、サーブ権が代わるとき）サービスボックスに片足か両足を入れ、フロントウォール（前方の壁）のサービスライン（真ん中のライン）とアウトライン（上のライン）の間に打つ。そのボールを、自分とは反対側にある「ハーフコートラインとショートライン（ハーフコートラインと直交する線）に囲まれた床」にワンバウンドするように入れる。最初の1球の後は、選手はコート内を自由に動け、サービスラインとティン（下のライン）の間に打ってもよくなる。
RSS
RSS（Really Simple Syndication（※名称は注釈参照））は、ニュースやブログなど各種のウェブサイトの更新情報を配信するための文書フォーマットの総称である。
RSSには、歴史的経緯によりそれぞれ記述方法や用途が異なる2つの規格が存在している。
RSS 概要
RSSの取得・講読にはRSSリーダー（フィードリーダーとも）と呼ばれるソフトウェアを使う。また、RSSを作成・追加するためのソフトウェアもあるが、比較的シンプルなXML形式なので手作業でも可能である。
RSSに対応しているウェブサイトではRSSに対応していることを明確にするために下記のような表示が使われていることが多い。
ブログなどでの更新情報、ニュース配信サイトの最新ニュース、その他各種サイトのプレスリリースや新情報、サポート情報などを、RSSを使ったヘッドライン情報として配信し、利用者はそれをリーダーやブラウザ付属のリーダー機能で読む。
RSS RSSフォーマットの歴史と変遷
RSSはResource Description Framework（RDF）の採用をめぐって現在分裂状態にあり、1.0と2.0の2つの系列に分かれている。当初、0.9はRDFをベースにしたデータ形式を利用していたが、0.91ではシンプル化するためにRDFを利用しなくなった。その後、1.0では0.9の系列を引継ぎ、複雑なRDFを採用することで応用性の高いデータを利用できるようにした。これに対して、2.0は0.91を引継ぎ、コンテンツ配信に特化することで複雑なRDFを排除している。
最初のRSSであるRSS 0.9は、RDF site summaryとして、1999年3月に米国ネットスケープコミュニケーションズが自社のポータルサイト「My Netscape」において、「チャンネル」の詳細を記すために策定したものである。RDF構文を用いたことから、RDF site summaryと呼ばれる。
その後ネットスケープコミュニケーションズはRDF構文の利用を止め、独自のXMLフォーマットを用いて要素を拡張し、よりリッチな情報を提供できるようにしたRSS 0.91を開発した。
rich site summaryと改名されたRSS 0.91は、RSS 0.9に要素を拡張する目的で作られ、1999年7月にこのバージョンがリリースされた。RDFを用いず、独自のXMLで記述される。
RSS RSSフォーマットの歴史と変遷
ユーザーランド・ソフトウェア社（UserLand Software）の「スクリプティングニュース」（ScriptingNews）から著作権、日付情報などいくつかの要素を取り入れ拡張された。それまでのRSS 0.9より多くの情報を配信できるようになったため、rich site summaryと呼ばれ、その後派生したRSS 0.92、RSS 2.0のベースとなっている。
RSS 0.91のリリース後、8年間にわたってNetscape社はRSSの開発から撤退してしまう。新しくオーナーになったAOL社による会社再編の中で、Netscape社は2001年4月にMy.Netscape.ComでRSSサポートを終了し、RSSのドキュメントや支援ツール類も削除してしまった。
RSS 0.91の登場以降、RSSが持つ「コンテンツ配信」機能に対しての需要がさらに高まっていた。そのときにNetscape社が撤退して空白が生じてしまった。この後、よりリッチなコンテンツ配信を目指そうとする制作者たちが、独自の要素をRSSに追加してしまうなど、フォーマットの拡張における混乱がおこることとなった。
RSS RSSフォーマットの歴史と変遷
この「空白」を埋めようと、二つのグループが立ち上がってきた。いずれのグループもNetscape社の助力や承認は得ていない。一つはRSS-DEV Working Groupのグループであり、もう一つはDave WinerとUserLand Software社のグループである。UserLand Software社はNetscape社外で作られたものとしては最初のものとなる、RSSの読み書きが可能な出版ツールを公開した。
こうした混乱のなかで、RSSでよく使われる語彙や使われる要素群を「コア」として定義し、それ以外は拡張する側が独自の語彙を「モジュール」として定義することで、中核語彙と拡張性を保証させようとする提案が RSS-DEV ワーキンググループ内で起こり、その成果として2000年12月にRSS 1.0がリリースされた。
RSS 1.0は0.9時代に用いられていたRDFを再び採用し、RSSが持つ「メタデータ記述」としての側面を主眼に置いたフォーマットとなっている。
また、RSSコアモジュールの他に公式なモジュールとして、Dublin Core モジュール、Syndication モジュール及び Content モジュールが定められた。これにより RSS 0.9の不満であった語彙の乏しさを解消させ、またコンテンツ配信手段としてRSS 1.0を採用する道を残すものとなった。
RSS RSSフォーマットの歴史と変遷
RSS 1.0 の登場は、（メタデータ記述技術としての）RSSの中核語彙及び拡張性を保証するものとなった。しかしRDFを再び採用したこと、モジュールによるXML名前空間の複雑化はすべてのRSS配信者を満足させず、RSS 0.91 系のフォーマットを拡張する動きが再びみられることとなった。
RSS 1.0の取る道は必ずしも誰もが好むものではなかった、とはいえRSS 0.91以降に起きていたフォーマット拡張の混乱は避ける必要があった。そのため拡張をオプションとして提供し、かつRSS 0.91への互換性を持たせる方法が提案され、それを受けて2000年12月にユーザーランド・ソフトウェア社からRSS 0.92が発表された。
ユーザーランド・ソフトウェア社はその後も互換性を維持したままRSS 0.93、RSS 0.94の素案を公表したが、その後撤回し、2002年8月にRSS 0.91 からRSS 0.94までのすべてのフォーマットに対する互換性を保証したRSS 2.0を策定し、これをreally simple syndicationと名付けた。
RSS 2.0はあくまで0.9x系の流れを汲む規格であって、RSS 1.0の後継ではない。それぞれの目指す方向性は同じではないため、場面に応じて使い分けられている。
RSS RSSフォーマットの歴史と変遷
2003年7月に、RSS 2.0制定の中心人物、デイヴ・ウィナー（Dave Winer）の移籍と併せ、仕様もハーヴァード大学ロースクールのバークマンセンターに移管された。
RSS 1.0 と RSS 2.0 の関係について、バージョンを表す数値の大小関係から、前者が旧規格で後者が後継規格であるという誤解が見受けられるが、これは事実ではない。RSS 2.0 はシンプルさの代償として RSS 1.0 の備える（RDFによる）強力な表現力を放棄したため、RSS 1.0 を置き換えるものではない。
RSS 2.0 に代わるコンテンツ配信技術として、IBMのサム・ルビー (Sam Ruby) などが中心となり、Atom と呼ばれる新しい規格が策定された。Atom にはウェブログ・ツールMovable Typeの開発元のSix Apart社やスタンフォード大学法学部のローレンス・レッシグ教授、XML開発者のティム・ブレイ (Tim Bray) などが支持を表明し、またGoogleも自社のサービスGmailにて、メールの内容をAtomフィードで提供するサービスを行った。
RSS RSSフォーマットの歴史と変遷
WinerとRSS-DEV Working GroupのいずれもNetscapeの関与を受けていないため、両者ともにRSSの名前や形式について、公的な正統性を主張できなかった。これが配信開発コミュニティで現在でも尾を引いている、「RSS」の管理元としてどちらが適切なのかという論争の元となってきた。
この論争の副産物ともいえるのが、2003年7月から開発が始まった新しい配信形式Atomである 。Atom配信形式の開発の動機の一つは、RSSを取り巻く問題から離れて、しがらみのない所で始めたいという動機もあった。AtomはIETFの提案標準RFC 4287として採択された。
その後、RSS 1.0、RSS 2.0 そして Atom は、いずれにも集約されることなく各々が広く普及していた。RSSリーダーの多くはそれら全てに対応しており、一方のウェブサイト側も、フィード配信のためにそれらのうち複数を利用することも珍しくなかった。しかし、SNSやキュレーションアプリの普及に伴い、RSS的な技術そのものの需要が減少していき、2013年にはGoogle リーダーが、2017年にはLive Dwango Readerがいずれも利用者数減少を理由にサービスを終了、次いで2018年には主要ブラウザであるMozilla FirefoxもRSS/Atomのサポートを廃止した。
プール
通称でプール、正式名称でスイミングプール（英: swimming pool）は、水泳をするための水槽。
プールは、学校、スポーツ施設、スイミングクラブ、フィットネスクラブ、レジャー施設、一部のホテル、保養施設、一部の豪華客船、一部の住宅の庭などに設置されている。
用途は、遊泳、教育、競泳、水球、アーティスティックスイミング、飛び込み、潜水などがある。また水泳だけでなく、さらに水中ウォーキングのような運動にも使われ、レクリエーションやリラクゼーションのためにも使われる。
日本語では通常は略称でプールと呼ぶが、英語のpoolは単に「水たまり」や「たまり」（血や化学薬品など単に液体が溜まっている場所）をも指すので、水泳用のプールは正式にはswimming poolという。
日本語におけるプールの数え方は「面」を使う。
プール 種類
遊泳用、水泳教育用、競泳用、飛び込み用などがある。
屋内に設置される屋内プール、屋外に設置される屋外プールという分類がある。
冬季や気温の低い地域でも利用できるように水温を高めに調節したプールを温水プールと分類する。
長い川のように水が流れるものや、水泳のトレーニング用に水が流れる小さなプールを流水プールと分類する。
子供1人～数人分の小さなプールで、ビニール製で空気を入れて膨らませるものはインフレータブルプール、棒材や板をフレームとしてビニールシートで水槽を組み立てるものをフレームプールと分類し、どちらもビニールプールや簡易プールと呼ばれることがある。
そのほか、スキューバダイビング専用プールと分類されるものもある（日本最大級で深さ8メートルほど、世界最大級はドバイのもので深さ60メートルほど）。
清流を一時的に堰き止めた水遊び場を「天然プール」と呼ぶ地域もある。
遊泳用プールの水深は一般遊泳では1.2メートル程度、児童遊泳では0.6-0.8メートル程度が目安とされている。
教育用プールは、水深が小学校では0.8-1.2メートル程度、中学校では0.9-1.4メートル程度が目安とされている。飛び込みで頭を打たないように、飛び込み台の近くは深くなっている。
プール 種類
飛び込みに関しては危険が伴い、死亡などの事故も起きているため、2012年の学習指導要領で禁止になった。2019年現在のスタート時の指導は以下の通り。
競技用プールは国際水泳連盟によって種目別に細かく規格が定められており、オリンピックなどの国際大会で使用するプールはこの規格を達成していなければならない。
競泳用のプールでは、短水路と呼ばれる長さ25メートルのものと、長水路と呼ばれる長さ50メートルのものが定められており、競泳のタイムは水路によって別々に扱われる。これは、ターンの際に壁面を蹴ることによって加速が行われるため、特に長距離の種目ではターンの回数が多くなる短水路の方が長水路に比べてタイムが短くなる傾向があるためである。長水路のプールは幅25メートル、水深2メートル以上のものも多く、長水路のプールを横方向に使って短水路の競技を行うこともある。
プール 種類
正確な長さについては、東京辰巳国際水泳場などの主要な国際水泳大会などが行われるような日本水泳連盟の公認プールは、長水路50.02メートル・短水路25.01メートルに設計されている。これは、タイムを測定するために厚さ1センチメートルのタッチ板を長水路ではプールの両端に1枚ずつ、短水路ではスタートサイドに1枚設置するためである。また、スタート台にはリアクションタイム（号砲が鳴ってから足が離れるまでの時間）を測定するための装置が付いており、台にかかる圧力によってそのタイムを測定する。これらの装置は、リレーのフライング判定にも組み合わせて使用される。
水温についても国際規格で、摂氏25℃から28℃までの範囲内に収まるよう調節しなければならないとされるが、2010年の改正以前は26℃を一つの目安、±1℃を許容範囲としていた。この範囲を逸脱した状態での記録は公認されない。
プール 種類
水球競技では、水深2メートル以上のプールに、男子は縦30メートル×横20メートル、女子は縦25メートル×横17メートルのコートをフィールドロープで区画して作り、コートの両ゴールライン中央にはゴールが浮かべられるため、ゴールのスペースも含めた競技面積以上のプールが必要となる。一般には50メートル競泳プールが使用されるが、宮城県仙南総合プールは35メートル×25メートルの水球公認プールで、国内唯一の屋内温水水球専用プールとして知られる（非公開施設としては、秀明栄光高校の屋内温水水球専用プールや秀明大学の屋内女子水球専用プールも存在する）。
アーティスティックスイミング用のプールでは、定められた面積について3メートル以上の水深を持つことが必要であるが、フィギュアとルーティンによって要求される面積は異なる。競泳用プールと共用するため、東京辰巳国際水泳場などではプールの底が可動式になっており、水深を競技によって変更できる。
飛込競技用のプールでは、水深は5メートル以上が必要であり、高飛び込み用の10メートル、7.5メートル、5メートルの高さの台と、板飛び込み用の3メートルと1メートルの高さの台が設置される。各飛び込み台の端は、プールの上空に張り出した形状になっている。
潜水用のプールでは、水深は1.5メートル程度（初心者は1.35メートル程度）が目安とされている。潜水用のプールには、5.5メートルという深さを持つものもある。
プール 歴史
ローマ皇帝は個人用のプールを持ち、水泳のためだけでなく魚を飼うためにも使われていたのでラテン語でpiscinaと呼ばれた。最初の温水プールはガイウス・キルニウス・マエケナスがローマの丘にあった自宅の庭園内に造らせたもので、紀元前38年から8年ころのものだという。
初期のオリンピックにおいて水泳競技は河川や海で実施されていた。近代オリンピック第1回のアテネオリンピック（1896年）の水泳競技はゼア湾で、第2回のパリオリンピック（1900年）の水泳競技はセーヌ川の河畔で、第3回のセントルイスオリンピック（1904年）の水泳競技は人工湖で開催された。
オリンピックの水泳競技で初めてプールが使用されたのは、1908年のロンドンオリンピックで、陸上競技場のフィールド部分に全長100mのプールが設けられた。しかし、初期のオリンピックプールにはコースロープがなく、1920年のアントワープオリンピックで進路妨害の問題が発生したことから、1924年のパリオリンピックで初めてコースロープが設置された。
プール 歴史
なお、2008年の北京オリンピックからプール外での水泳競技であるオープンウォータースイミングが正式採用されている。
日本では、会津藩校の日新館に設けられた水練場あるいは水練水馬池が、最古のプールとされている。当時の藩校の中では、日新館と長州藩校の明倫館の2校を除いて施設が設けられていなかったとも言われている。また日本最古の温水プールは1917年に東京YMCAに開設された。
プール 設備
プールの材質にはRC製、アルミ製、ステンレス製、FRP製などがある。FRP製を除いて規格を満たせば水泳競技の公認プールとすることができるとされてきたが、FRPについても仮設の50mプールが世界水泳連盟に認められた事例はある（第9回世界水泳大会福岡2001（マリンメッセ福岡））。なお、FRP製プールを製造するヤマハ発動機は、2024年3月末で学校やレジャー施設など向けのプール事業から撤退すると発表しており、徐々に数を減らす可能性がある。
プールの形状は、底面の形状により、フラット（底面が平面）、レギュラー（プール中央に向かって若干勾配。プールサイド側より中央の方が深い）、片寄せ（片側に勾配）、飛び込み兼用、シンクロ兼用、飛び込み用などがある。
プール 設備
プールの排水口は、その膨大な水量を素早く排出するため、銭湯などと比べて非常に大きな物が取り付けられている。通常は金網などで安全対策が行われるが、死亡・負傷事故も起きている。金網や柵が外れて全身が吸い込まれたり、金網や柵があって排水口が小さく作られていても、足だけ嵌り込まれたり、身体の一部が強い水流で排水口に密着することが原因である。こうした危険に対処するため、学校用FRP製プールで国内シェアトップのヤマハ発動機では、排水口を複数設置して（1つあたりの）流水圧の低減を図る、排水口部分の構造をL字型にしてその上から金網を張る、といった措置を取っている。同社製のプールでは2016年時点で一度も事故は発生していないという。
プール 管理
プールには屋外に設置され夏だけ使用されるプールと、屋内に設けられていて室温や水温が調節・管理された通年使用可能なタイプがある。またそのうち通常より水温が高めに設定された温水プールもある。防火用水や非常用水の水源として利用される場合は、使用時期以外にも貯水・管理されている（清掃などで水を抜く場合には消防本部への事前通知を要する）が、水質管理までは行われていない施設が大半である。
通常のプールは不特定多数の人間が利用するため、衛生上、水質管理が必要となる。一般的には殺菌・消毒のためにプールと付帯施設の足洗い場・腰洗い槽に塩素系消毒剤が加えられている。消毒剤は次亜塩素酸ナトリウム、次亜塩素酸カルシウム、塩素化イソシアヌール酸のいずれかであり、遊離残留塩素は0.4ppm～1.0ppmを保持しなくてはならない。水道水基準（0.1ppm～1.0ppm）に比較してわずかに高めだが、有機物（人体や汚れ）と接したり太陽光の紫外線を浴びることなどによって残留塩素濃度が低下するため、定期的な濃度維持が必要である。加える方法はプール・足洗い場・腰洗い槽に消毒剤を直接投入する方法と塩素供給機器に消毒剤を入れて水に溶かす方法がある。
プール 管理
日本では厚生労働省が「遊泳用プールの衛生基準について」（平成19年5月28日健衛発第0528003号）を定めている。この基準では、水素イオン濃度・濁度・過マンガン酸カリウム消費量・遊離残留塩素・大腸菌、一般細菌、総トリハロメタンの7項目について衛生基準が示されており、また循環濾過方式等の浄化設備を備えることも必要とされる。
また、いわゆる1条校のプールにあっては文部科学省が「学校環境衛生基準」を定めている。なお、学校における水泳プールは学校保健法（昭和33年法律第56号）に基づく衛生管理が実施されているため「遊泳用プールの衛生基準について」（平成19年5月28日健衛発第0528003号）の適用対象外となっている。
プールはプール熱などの感染症の媒介となりやすいため、病気に罹患している場合や回復した直後などはプールへの入場が禁止されている。
目が赤くなる原因がプール内の尿と塩素の化合物が原因であることがわかった。
アメリカ合衆国では、感染源がプールや温浴施設等と判明している集団感染のうち、58%はクリプトスポリジウム症であったことが報告されている。アメリカ疾病対策センターの専門家は、消毒剤に対する耐性を持つ菌等の存在を踏まえてプールの水を飲まないことを勧めている。
プール 管理
大量の水を蓄えた施設であるため、溺れたり、飛び込み時に頭などを打ったり する事故が度々発生している。このため学校の水泳授業や部活動では教員らが安全に注意を払うほか、ライフガードや監視員を配置しているプールもある。また未就学児童や小学校低学年では声も物音も立てずに沈んで溺れる事もあるため注意が必要である。
事故・判例
平成19(わ)779 業務上過失致死 さいたま地方裁判所 平成20年5月27日
平成24年（ネ）第316号 損害賠償請求控訴事件 名古屋高等裁判所 平成24年10月4日
『The Promise: A Tragic Accident, a Paralyzed Bride, and the Power of Love, Loyalty, and Friendship』 Rachelle Friedman (著) 2014年5月6日出版 ※結婚式前夜の宴会で、友人が定番の余興で新婦を邸宅のプールに突き落としたところ、新婦がプール底に激突して半身不随となり、車椅子生活となった日々を綴った手記。
その他
感染症
6月から夏季にかけて広まる咽頭結膜熱（「プール熱」と通称される）、皮膚接触で感染する水疱性膿痂疹（とびひ）、伝染性軟属腫（水いぼ）、クリプトスポリジウム症 等がプール利用時に感染する可能性がある。専門医による診療と治療、遊泳を控える事で感染を防ぐ事が可能。
プール 紫外線対策
サンバーン（火傷）や電気性眼炎、及び瞼裂斑、若年時から長期間に渡る屋外活動で加齢と共に紫外線曝露によって発症する白内障、皮膚の色素沈着（しみ・くすみ）の他、皮膚癌のリスクが高まる報告がある。
プール リゾート施設のプール
一般向けのプールは様々なものがあり、レジャー施設用のプールの中には、流れるプール、子供用の水深の浅いプール等があり、附帯設備として滑り台（ウォータースライダー）などが併設されるものもある。
屋外のプールは昼間だけ使用されることが多いが、近年、ホテルやテーマパークでは、リゾート地のような非日常感を楽しんでもらうため夜も営業する「ナイトプール」も見られる。
インフィニティ・プールは、近年、異国情緒あふれるリゾート、高級ホテル等宿泊施設の集客目的で作られることが多くなった。「インフィニティ」は「無限」を意味し、どこまでも限りないさまを現した表現で、水盤や外縁を水で覆い、あたかも外縁が存在しないかのように見えるよう設計されたプールで、外縁が海などのより大規模な水や空と混じり合い境目がわからないように見えるよう設計される。近年は日本でも少しずつ取り入れられるようになってきた。プールのほか、露天風呂に応用したケースもあり「インフィニティ風呂」などと呼称される。
Exchangeable image file format
Exchangeable image file format（エクスチェンジャブル・イメージ・ファイル・フォーマット）は、富士フイルムが開発し、当時の日本電子工業振興協会 (JEIDA)で規格化された、写真用のメタデータを含む画像ファイルフォーマット。デジタルカメラの画像の保存に使われる。略称はExifで「エグジフ」（もしくは「イグジフ」）。
カメラの機種や撮影時の条件情報を画像に埋め込んでいて、ビューワや写真編集ソフトなどで参照、応用することができる。Exif2.2ではExif Printという規格を組み込んでおり、撮影時の条件情報を元に自動的に最適化を行って、的確な状態でプリント出力を可能にしている。また撮影者や著作権情報、コメントなど付随することが出来る。
対応画像形式はJPEG、TIFF、JPEG XR（HD Photo）、PNG。
Exchangeable image file format 記録されるメタデータ
以下のようなデータが記録される。撮影日時や場所を後から参照したりそれらによって写真を整理したり、適切なサイズでのプリント、撮影時のカメラの設定情報の参照などユーザーが使う上での利便性がある。
位置情報（ジオタグ）  - GPS付きカメラや携帯電子機器の場合、GPSにより自動的に記録された緯度・経度・標高などが記録される。また、GPS受信装置の付いていないカメラでも、GPSロガーという機器やスマートフォンの同様のアプリケーションを利用しカメラと一緒に持ち歩くことにより、後で写真に位置情報を付加することも可能。携帯電話やスマートフォンのカメラにおいてGPS機能が普及した一方、2019年現在においてもカメラでは上位機種においてもGPSは普及していない。カメラの起動からGPS観測までの速度やバッテリーへの影響などの観点から実用性が十分でないことが理由とみられる。
Exchangeable image file format 問題点や対策
撮影時のGPSによる位置情報（緯度・経度）や撮影日時など、個人情報を特定できるおそれがある情報が含まれている。例えば、撮影された写真が観光地や市街地などではなく、自宅で撮影した場合はGPSによる緯度・経度がそのまま自宅の位置となる。例えば、ブログやファイルアップローダーなどで写真を公開した際、Exif情報が残ったままだと第三者がExif情報の位置情報から撮影時の緯度・経度で位置を特定され、事件の元になる危険性もある。iPhoneは、iPhoneからSNSへのアップロード時やメッセージへの添付の際に位置情報のみ削除される仕様になっている。一方条件やOSによって仕様は異なるため注意が必要である。
画像内に書かれている住所や名前など、「目に見える画像」にモザイク処理を入れても、「目に見えないExif情報」には位置データが残っており、Exif情報に含まれるサムネイル情報にはモザイクがかけられておらず、住所や名前が観覧できてしまう場合もある。
Exchangeable image file format 問題点や対策
対策としては、各撮影機器でGPS情報を付加しないように設定したり、アプリケーションでExif情報を参照し削除したりする事などがあげられる。また、スマートフォンでExifをアプリケーションを使わず簡易的かつ確実に削除する方法として、画像をスクリーンショット（通常スクリーンショットにはExifが付かない）しそれをアップロードする手段がある。尚TwitterやInstagram等、一部のSNSやブログでは画像アップロード時に独自の変換を行うことでExif情報や、特に位置情報（ジオタグ）を消している所もある。また、Exif情報はソフトウェアなどで容易に変更可能なため、Exif情報として記録されているGPS情報を意図的に書き換えてあることもある。
撮影日時の情報は、UTCとタイムゾーンを組み合わせたものではなく、機種依存のローカルタイム（現地時刻）のみで記録され、タイムゾーン情報が記録されていないので、海外旅行や出張などタイムゾーンをまたいで移動、生活する際に問題となることもある。なお、タイムゾーン情報が記録できるカメラなどもあるが機種依存の機能である。Exif共通の仕様ではv2.31においてUTCからのオフセット値としてタイムゾーン情報が記録できるようになったが、対応しているカメラやソフトウェアは確認されていない。
三連刻
三連刻（さんれんこー）とは、麻雀におけるローカル役のひとつ。333・444・555など、同色で3つ連続した刻子を作ることにより成立する。2翻。喰い下がりはない。
三連刻 概要
比較的広く知られているローカル役だが、現在の一般的なルールでは採用しない場合が多く、各種プロ団体は勿論のことフリー雀荘でもほとんど採用されない。オンライン麻雀では、東風荘・ハンゲーム・麻雀格闘倶楽部が採用しない中、MJシリーズでかつて採用されていた。そのMJシリーズでも、2010年4月1日のルール改正で、四連刻・大車輪・二飜縛りとともに廃止になった。
役の難易度はそれほど高くはなく、狙って作るのもそれほど難しいことではない。例えば
のような形や
のような形は実戦ではありがちで、
このような一盃口含みの形から鳴いてゆくことで比較的簡単に作ることができる。
三連刻 概要
牌の構成がよく似た役として、345・345・345のように同一順子を3つ揃えた一色三順という役がある。例えば手牌中に333444555とある時、333・444・555と取るなら三連刻になるが、345・345・345と取るなら一色三順になる。三連刻と同じく一色三順もローカル役だが、三連刻も一色三順も両方採用する場合、どちらにとるかで得点が変わってくることがある。333444555が手の内で完成していれば、三暗刻が複合することにより三連刻に取ったほうが高くなる。しかし、33344455から5を出あがりした場合や、ジュンチャンが絡む場合は、三連刻に取るよりも一色三順に取ったほうが高くなる。いずれにせよ、得点がより高くなるほうを選択することになる（高点法）。下の牌姿例も参照のこと。
三連刻 牌姿の例
（例）副露したケース
で三連刻になる。なら対々和のみである。
（例）メンゼンのケース
待ちはの変則三門張、高目の五萬で三連刻になった形。ツモ和了の場合はタンヅモ三暗刻三連刻で跳満、ロン和了の場合はタンヤオ三連刻で子5200点である。一色三順を採用するなら、ロン和了でタンピン一色三順の切り上げ満貫になる。したがって一色三順ありの場合のロン和了は、三連刻に取るより一色三順に取ったほうが高くなる。一方ツモ和了の場合は、タンピンツモ一色三順となるが満貫止まり。三連刻に取って跳満とするほうが高い。このように三連刻と一色三順はそれぞれを採用するしないで得点計算が煩雑になる。とはいえ、一般的には三連刻も一色三順も採用しない場合がほとんどである。その場合は（つまり一般的なルールの場合は）この手はロン和了でタンピン一盃口の子3900点、ツモ和了でタンヅモ三暗刻の満貫である。
三連刻 牌姿の例
（例）ジュンチャンが絡むケース
ロン
111・222・333を3つの刻子として見た場合この手は三連刻のみの2飜だが、123・123・123と見ればピンフジュンチャン一盃口で計5飜となる。つまり三連刻に取るよりも高くなる（一色三順を採用していれば一盃口の代わりに付いて6飜）。また、ロン和了ではなくツモ和了の場合でも、ツモ三暗刻三連刻の計5飜より、ピンヅモジュンチャン一盃口の計6飜と取る方が高い。つまりこのようなケースでは、ロン和了の場合もツモ和了の場合も三連刻に取らずジュンチャンに取ったほうが高いということになる。
字一色
字一色（ツーイーソー）とは、麻雀における役のひとつ。役満。読んで字の如く、字牌のみで構成された和了形である。
字一色 概要
7種類ある字牌のうち5種類を使った対々和の形、もしくは7種類すべてを使った七対子の形になるが、ほとんどの場合副露した対々形での和了となる。配牌にどれくらいの字牌暗刻・字牌対子が含まれているかで大きく成否が左右される。鳴いて手作りできるため、配牌の如何によっては比較的早い巡目でテンパイに漕ぎつけることもあるが、派手な副露になってしまうため、警戒されることも多い。使う牌の性質上四喜和や大三元との複合が可能で、非常に稀にではあるが四暗刻や四槓子と複合することもある。
字一色 牌姿の例
（例）副露した字一色
とのシャンポン待ち。
（例）四喜和との複合
とのシャンポン待ち。四喜和が複合しており、北なら大四喜字一色に、白なら字一色小四喜になる。
（例）字一色七対子
待ち。字一色七対子は難易度が非常に高く滅多に見られないため、ルールによっては「大七星」や「七福星」といった名でダブル役満としている場合もある。
カバラ
カバラ（קַבָּלָה qabbalah, Kabbala, Cabbala）、カバラーとは、ユダヤ教の伝統に基づいた創造論、終末論、メシア論を伴う神秘主義思想。ユダヤのラビたちによる、キリスト教でいうところの（『旧約聖書』の伝統的、神秘的解釈による）神智学であり、中世後期、ルネサンスのキリスト教神学者に強い影響をおよぼした。独特の宇宙観を持っていることから、しばしば仏教の神秘思想である密教との類似性を指摘されることがある。
カバラはヘブライ語の動詞キッベール「受け入れる」「伝承する」の名詞形で、「受け入れ」「伝承」を意味する。カバラが登場する以前のゲオーニーム時代には、単に口伝律法を指す言葉として用いられた。したがって、その後ユダヤ教神秘主義を指す呼称となった際にも、個人が独自に体得した神秘思想というよりは、神から伝授された知恵、あるいは師が弟子に伝承した神秘という意味で用いられることになる。
カバラ
カバラはユダヤ教の伝統に忠実な側面を持とうとしたという点において、他の宗教の神秘主義とは異なる。本来のカバラは、ユダヤ教の律法を遵守すること、あるいは神から律法の真意を学ぶことを目的とした。したがって、正統的なユダヤ教との親和性を持っていた時期もあったため、必ずしも秘教的な神秘思想とは言えない。しかし、キリスト教の神秘家に採り入れられるようになると、ユダヤ教の伝統からは乖離した極めて個人的な神秘体験の追究の手段として用いられることになる。
カバラ 小史
伝説では、アブラハムがメルキゼデクから伝授された天界の秘密だとも、モーセが律法（トーラー）（なお、トーラーは律法以外の要素も含む）に記し切れなかった部分を口伝として後世に伝えたものだともいう。しかし、3世紀から6世紀頃に始まり、16世紀頃にユダヤカバラから派生したクリスチャンカバラが成熟し、ほぼ現在の体系が完成したとされる。クリスチャンカバラまでが広義の伝統カバラの歴史とされる。
広義の伝統カバラと異なる日本のニューエイジ(スピリチュアル)型は1990年代から2000年代初頭にかけて確立された。その流れで72天使は「72守護天使」と総称を改変され、天使1柱ごとに元来のカバラには存在しなかった二つ名が与えられた。
カバラ 分類
カバラは、ユダヤカバラと非ユダヤカバラに大別され、非ユダヤカバラはクリスチャンカバラとヘルメティックカバラに分かれる。ユダヤカバラが正統かつ本来のカバラである。カバラはユダヤ教の密教的教義であり、ユダヤ教徒によるトーラーの秘儀的解釈に用いられている。ユダヤ教においてはパルデスと呼ばれる4階層のトーラー解釈があり、これら全てユダヤ教のうちであるが、神秘主義的解釈はこのなかでも最も深いソッドと呼ばれるレベルの解釈とされる。クリスチャンカバラは文字通りキリスト教徒の観点から解釈されたカバラであり、キリスト教神秘主義との関連性もある。ヘルメティックカバラは魔術カバラとも称されており、中世以降のオカルティストや神秘主義派による秘儀的解釈から研究され受け継がれていったものである。魔術カバラは19世紀に特に重視されるようになり、近代西洋魔術の中で重要な位置を占めた。近代西洋魔術では生命の樹の象徴図表が教義の根幹に据えられている事が多い。
カバラ 思想
カバラでは世界の創造を神「アイン・ソフ（エイン・ソフ、エン・ソフとも）」からの聖性の10段階にわたる流出の過程と考え、その聖性の最終的な形がこの物質世界であると解釈をする。この過程は10個の「球」（セフィラ）と22本の「小径」（パス）から構成される生命の樹（セフィロト）と呼ばれる象徴図で示され、その部分部分に神の属性が反映されている。
したがってカバラは一神教でありながら多神教や汎神論に近い世界観を持つ。
別の解釈ではこの世界を一冊の書物とみなす。すべてが書き込まれているこの書を解読することはこの世界のすべてを理解することである。そしてその書はヘブライ文字の22文字で書かれており、それぞれの文字が宇宙の原理となる要素を象徴しているという。それゆえ、そのヘブライ文字のアルファベットを解読することが重要な鍵となる。
また、聖書無謬主義から一見矛盾している『旧約聖書』の記述を神秘主義的解釈を用いて影響を受け読み解く（というよりは書かれたトーラーを補完する「口伝のトーラー」による解釈である）。一例として『創世記』冒頭の天地創造には人間創造の場面が2回出てくる。文献学的にはこれは別系統の神話を一つの書物に統合した為に生じた矛盾と考えられているが、カバラでは実際に人間創造が2回（またはそれ以上）行われたと解釈する。
カバラ 思想
カバラでは、魂は個体の記憶の集合体であり、唯一神は全ての生命に内在し、唯一神は永遠の魂(命の木)である。個体が善悪を分かち、各々の記憶は神へ還っていく。神はただ記憶を収集し、善悪を分かたない。神では、善の記憶が再創造の素材になり、悪の記憶が無くなる。
カバラでは次のような寓話がある。
「毎年贖罪の日では全ての生命は死んで、生き返り、悪も無くなる。あるいは、毎年角笛吹きの祭から贖罪の日までの間に全ての生命は死んで、記憶が神へ還った。贖罪の日から光の祭りまでの間に神は再創造し、善の記憶が全ての生命へ還った。死亡はただ贖罪の日と同じである。」
カバラ 数秘学
また、『聖書』を神秘主義的に解釈する際、ゲマトリアやノタリコン、テムラーと呼ばれる一種の暗号解読法を用いる場合がある。これらが後に世俗化し「数秘学」、「数秘術」と呼ばれる運命解読の方法となった。
大三元
大三元（だいさんげん）とは、麻雀における役のひとつ。白・發・中の3種類をすべて刻子または槓子にして和了した時に成立する。役満。副露可。
大三元 概要
大三元は、国士無双や四暗刻と並んで比較的成立しやすい役満として知られている。鳴いて手を作ることができ、しかも9枚しか手牌を制約しないため、役満の中では最も出現率の高い部類に入る。ただし、あがりやすい分警戒もされやすい。配牌に白發中の対子が揃っていても、すべてポンできるとは限らず、相手方の警戒が強い場合は2つ目さえ鳴けない場合もある。3つのうち少なくとも1つは自力で暗刻にしないと、大三元の和了は難しい。
使う牌の性質上字一色との複合が可能で、後述の通り四暗刻との複合も可能である。
大三元 牌姿の例
（例）高目大三元のケース / ドラは無関係の風牌
のシャンポン待ち。發で大三元となる。一筒の場合は小三元・白・中の満貫にしかならない。
（例）高目大三元のケース / 三元牌を2副露している場合
同じくのシャンポン待ちだが、この場合は2副露しているため、發の出アガリはそうそう期待できない。
（例）大三元確定のケース
待ち。すでに中を暗刻にしているこのようなケースが最も有利である。2副露により大三元が見えているだけに他家の手は止まり、場に1枚も見えていない中を掴んでしまった者はほぼオリに回る。しかし、このケースでは中を止めることで大三元の和了を阻止できるわけではなく、かつ、数牌のどの部分が待ちになっているか分からない上、待ちも広い。
（例）他の役満との複合 / 南4局 / 南家 / ドラは無関係の数牌
ツモ - 大三元と四暗刻が共に成立。役満またはダブル役満。
ロン - 大三元で役満。
ツモ - 四暗刻で役満。
ロン - 混一+混老+対々+三暗刻+役々+小三元で、三倍満または数え役満。