hotchpotch/wikipedia-multilingual-ir-pairs huggingface dataset:
雑家 概要
雑家の代表的著作には秦代の呂不韋『呂氏春秋』と前漢の 劉安『淮南子』があるが、いずれもひとりで書いたものではなく、多数の学者を集めて著したものである。『呂氏春秋』が儒家の思想を基本に置いて諸家を折衷しているのに対し、『淮南子』では根幹を道家に置いている。また、道家のうちで『老子』と『荘子』を並称していることも特徴的である（老荘思想を参照）。
『淮南子』の故事成語から象徴的なものを引用するのであれば、「鹿を追う者は山を見ず」（一事に熱中すると他の事を考える余裕がなくなること、利欲に迷うと道理がわからなくなること）の語が、端的に雑家の思考（大局観の為の思想）成立を表したものといえる。
雑家 書物
このほか、雑家に何を含めるかは揺れが大きい。例えば『尉繚子』は、『漢書』芸文志や『隋書』経籍志では雑家とされるが、『四庫全書』では兵家とされる。
また、『四庫全書』では、所属する書物の数が少ないものをまとめて雑家に統合したため、従来の墨家・名家・縦横家はすべて雑家として分類されている。
ロック開発
ロック開発株式会社（ロックかいはつ、LOC development Co., Ltd.）は、かつて存在したイオングループの近隣型ショッピングセンター（NSC）事業を展開・運営するデベロッパー。大和ハウス工業とイオンの共同出資により設立されていた。
2011年8月31日をもってイオンの完全子会社となり、同年9月1日にイオンタウン株式会社となった（後述）。
ロック開発 概要
会社名の「ロック」（LOC）は「Land Owner and Company」の頭文字を取ったもので、大和ハウスグループの土地有効活用事業（LOCシステム）の名称でもある。大和ハウスによるイオングループ向の中小型ロードサイド店舗開発の事業主体となっていた。2000年代以降は工場跡地への進出（再開発）が多かった。
イオンリテールやイオンモールが大規模複合型SC（「イオンショッピングセンター」「イオンモール」など）を展開する一方で、ロック開発によるSCは中規模のオープンモール型（ロックシティのみエンドクローズモール型）ショッピングセンターを主に展開していた。具体的には「マックスバリュ」や「カスミ」などの食品スーパーを核店舗とした、中小商圏における低層の独立建物が集合している「近隣（ネイバーフッド）型ショッピングセンター（NSC＝Neighborhood Shopping Center）」と呼ばれる形態のSCを展開していた。2008年度からはディスカウントストア業態である「ザ・ビッグ」（ザ ビッグ）を核店舗としたSCも増加している。
従来は先述のオープンモール型SC「ロックタウン」を展開してきたが、近年はコミュニティセンター機能を持つエンクローズドモール型SC「ロックシティ」を並行して展開しつつあった。
ロック開発 概要
2011年8月31日もってイオンが大和ハウスの保有する全株式を取得してロック開発を完全子会社とし、翌9月1日をもって社名を「イオンタウン株式会社」に変更することが発表された。ショッピングセンター名は「ロックタウン」「ロックシティ」およびイオン川之江SC（ロック開発が展開）が同日付で「イオンタウン」を冠にしたSC名に変更され、看板も順次変更された。本社もイオングループ各社の本社が入居する千葉市美浜区に移転している。なおロック開発によりオープンした最後のSCは同年2月1日にオープンした「ロックシティ姫路ショッピングセンター」であった。
元々「イオンタウン」の名称はイオンリテールを含め全国のマックスバリュ運営会社やイオンスーパーセンター運営会社等がそれぞれに展開しているNSCに用いられてきた呼称であり、ロック開発の商号変更前から存在している。多くのイオンタウンやNSC形態もしくは類似の小規模ショッピングセンターは2011年11月21日付でイオンタウン（株）に移管されている。
なおイオンと大和ハウスの提携については、マックスバリュなどを核店舗にした小規模ショッピングセンターの開発にLOCシステムを採用する（例：マックスバリュ清須春日店。ロックシティを当初から名乗っていなかった）などの形で継続されている。
ロック開発 店舗展開
全国に45箇所のSC（うち「ロックシティ」が7箇所）を展開した。北海道・北陸・沖縄には未進出。大半のSCは核テナントが「マックスバリュ」または「ザ・ビッグ」（何れも各地域のマックスバリュ運営会社が運営）だが、館山・大田・川之江・日向はイオン（旧：ジャスコ）が、水戸南・守谷・佐野は「カスミ」が核テナントである。このうち「ザ・ビッグ」は、周南を除いて全て「マックスバリュ」「ジャスコ」「ヤオハン」からの転換店舗。
また以下のSCはイオングループの店舗が進出しておらず、イオングループ以外の企業が核テナントとなっている。これらは何れも他のイオングループが運営するショッピングセンターなどが隣接している為である。
なお、徳島県のイオングループのショッピングセンター形態による店舗はイオンタウンへの名称変更時点で北島・上板の2つのロックタウンのみであった。
店舗ごとの詳細については公式サイト並びに下記テンプレートリンク先の各SCの記事参照。
ロックシティ
ロックシティ、ロック・シティ
英語で「岩石の都市」、ないし、「（音楽の）ロックの都市」を意味する語句の音写。
チュンマリー・サイニャソーン
チュンマリー・サイニャーソン（ラーオ語: ຈູມມະລີ ໄຊຍະສອນ / Choummaly Sayasone, 1936年3月6日 - ）はラオスの軍人、政治家。ラオス人民軍中将。元ラオス人民革命党中央委員会書記長。第5代ラオス人民民主共和国主席を務め、同国の最高指導者の地位にあった。革命第二世代で、党の保守的な路線を継承する。
チュンマリー・サイニャソーン 経歴
ラオス南部のアッタプー県サイセター郡ウットヌア村に生まれる。1954年よりフアパン県にて革命運動に参加し、左派勢力の兵士となる。1955年、ラオス人民党に入党。ラオス内戦が始まると、左派軍事勢力パテート・ラーオの将校として1960年から1974年にかけてシェンクワン軍管区司令官を務める。その間にベトナム人民軍陸軍学校で学び、1969年に同校を卒業した。
ラオス内戦はパテート・ラーオの勝利に終わり、1975年12月2日にラオス人民民主共和国が成立した。チュンマリーは国軍となったラオス人民軍（建国当初はラオス人民解放軍）の准将として任官し、作戦部長や参謀次長を歴任した（1980年まで）。この間、ソ連陸軍学校に留学している（1978年卒業）。1982年4月に開催されたラオス人民革命党（1972年2月にラオス人民党から改称）第3回党大会で党中央委員に選出され、党内序列第43位となる。同年、少将に昇進し国防副大臣に任命された。翌年、ベトナム政治行政学院に留学し、同院を修了。1986年11月、第4回党大会で中央委員に再選されて政治局員候補となり、党内序列13位まで昇進。同年、国防第一副大臣に昇格。1990年、中将に昇進。
チュンマリー・サイニャソーン 経歴
1991年3月の第5回党大会でチュンマリーは党政治局員に選出され、党内序列第8位となる。同年8月15日、副首相兼国防大臣としてチュンマリーの直属の上司であったカムタイ・シーパンドーンが首相に就任すると、チュンマリーは後任の国防大臣に任命され、カムタイ内閣に入閣する。1996年3月、第6回党大会において政治局員に再選され、党内序列第3位に昇格。1998年2月24日、カムタイ首相が国家主席に就任し、シーサワット・ケーオブンパンが後任の首相となると、チュンマリーはシーサワット内閣に入閣して国防大臣に再任され、さらに副首相を兼任した。
2001年3月の第7回党大会で政治局員に再選されたチュンマリーは、3月27日、国家副主席に就任。党国防・治安維持委員会委員長も兼任した。
2016年1月の第10回党大会にて政治局員から引退した。
ラオスの最高指導者であるカムタイ・シーパンドーン党議長兼国家主席の側近を務めたチュンマリーは、2006年3月の第8回党大会でカムタイが党議長を退任すると、3月21日、党綱領改正によって廃止された議長職に代わる最高職として再設置された書記長に選出された。さらに同年6月8日、国民議会において国家主席に選出され、カムタイから最高指導者の地位を継承した。
国家主席就任後、日本には2009年5月と2010年3月の2度訪問している。
2011年3月の第9回党大会で書記長に再選された。
2016年1月の第10回党大会では書記長職をブンニャン・ウォーラチット国家副主席に譲り、また党政治局からも退き、党中央委員会顧問に選出された。
チュンマリー・サイニャソーン 人物像
前妻とケオサイチャイ夫人との間に3男5女を儲けた。趣味は読書とガーデニング。
ケオサイチャイ夫人はチュンマリーの国家主席在任中、ファーストレディを務めた。ケオサイチャイ夫人はファーストレディ退任後の2021年にナムグムダムで船に乗船していた際に嵐に巻き込まれ、息子と共に水死した。
小林哲也 (近畿日本鉄道)
小林 哲也（こばやし てつや、1943年〈昭和18年〉11月27日 - ）は実業家。近鉄グループホールディングスの取締役相談役および近畿日本鉄道取締役（近鉄社長としては大阪電気軌道創立から15代目）。また、2004年（平成16年）をもって解散したプロ野球球団・大阪近鉄バファローズ最後の球団社長でもあった。
小林哲也 (近畿日本鉄道) 来歴
大阪府生まれ。1962年（昭和37年）大阪府立大手前高等学校を経て、1968年（昭和43年）早稲田大学政治経済学部（当時は第一政治経済学部）を卒業、近畿日本鉄道（近鉄）に入社。
上本町営業局及び天王寺営業局の各運輸部で勤務したあと、業務局営業課長を経て、1980年(昭和55年)に天王寺営業局運輸部営業課長兼企画課長に、1982年(昭和57年)には上本町営業局運輸部営業課長にそれぞれ就き、1992年(平成4年)に事務局部長、2000年(平成12年)に営業推進局長に就任。
2001年（平成13年）取締役就任（営業推進本部副本部長兼伊勢志摩支社長）、2003年常務取締役就任。同時に社長に就任した山口昌紀のもと、採算の悪化していたレジャー部門の再建を任され、近鉄あやめ池遊園地や近鉄劇場を2004年に閉鎖した。また同年、大阪近鉄バファローズの球団社長に就任、球団をオリックス・ブルーウェーブに譲渡する（吸収合併させる）ことを発表、プロ野球再編の主役の一人として、厳しい批判を浴びながらも強行した。これらリストラ策もあり、レジャー部門は2006年3月期の決算で黒字に転換し、一定の成果を得ている。
小林哲也 (近畿日本鉄道) 来歴
2005年には専務取締役に昇格（ホテル・レジャー事業本部長兼流通事業本部長）、2007年3月23日、山口昌紀の後任となる社長に就任することが発表され、6月28日の株主総会後の取締役会をもって就任した（山口は会長に就任）。社長就任後は積極的な攻めの経営姿勢が随所に見られる（ただし攻めの経営姿勢自体は山口時代末期からのものである）。
近畿日本鉄道の持株会社移行に伴い、2015年（平成27年）4月1日発足の近鉄グループホールディングス（近鉄GHD）の代表取締役会長および鉄道事業を継承する（新）近畿日本鉄道の代表取締役会長に就任した。
2016年7月、大阪商工会議所副会頭に就任。2018年（平成30年）3月、大商副会頭を退任（後任は同じ近鉄GHDの吉田昌功社長）。同年5月、関西経済連合会副会長に就任。2019年6月、近鉄GHDおよび近鉄の役員人事異動により、近鉄の代表取締役会長を退任して取締役に就任（なお近鉄GHDの会長は引き続き在任）。同年、旭日中綬章受章。
2023年6月の株主総会をもって近鉄GHDの代表取締役会長を退任し同社取締役相談役となる。近鉄GHDの会長は近畿日本鉄道（事業会社）の社長である都司尚が引き継ぐと発表したが、同年4月に傘下の近畿日本ツーリストにおいて、新型コロナウイルスワクチン接種業務で過大請求の不祥事が発覚したため、退任せず会長職にとどまることになった（都司は近鉄GHD社長に就任する）。
2024年6月21日の第113回定時株主総会において、取締役相談役に就任した。
小林哲也 (近畿日本鉄道) 人物
幼少期は「わんぱくでいたずらばっかりやっていた」。大阪市立東中学校では竹刀競技部に所属し、大手前高校では剣道部を創設し武道で心身とも鍛える。若い世代へのアドバイスとして、「社会人は『人事を尽くして天命を待つ』という姿勢が大事だ」と話す。球団社長として進めた球団合併（プロ野球再編）の際も、「野球の撤退のとき、いつもそう思って」おり、「気持ちをおおらかに、結果にうじうじとしないで、自分の事業に関わっていってもらったら、かえって物事がうまくいく」と語る。そして、心構えとして、「新渡戸稲造先生の『武士道』を是非若い人たちに読んで欲しい」と訴え、武士道で示されている「義」「勇」「仁」の３つの道を守っていれば「人として大きく道をそれることは無い」「気持ちがくじけそうになったり、人に対して傲慢になりそうなとき、そういう時に思い出して欲しい」と説いている。
小林哲也 (近畿日本鉄道) 人物
社長在任中に特急車22600系Aceの投入、阪神なんば線開業による阪神電気鉄道との相互直通運転の実施、平城遷都1300年記念事業輸送、伊勢神宮式年遷宮に合わせ観光特急『しまかぜ』の運行開始、大阪阿部野橋駅、京都駅、大阪上本町駅および大阪難波駅などのターミナル整備、良好な住環境の整備としてけいはんな線沿線とあやめ池遊園地跡地の開発、近鉄劇場再開発による上本町YUFURAや日本一の超高層ビルあべのハルカスの開業といった事業を推進した。
また、近鉄社長のほか、2007年6月27日よりMBSメディアホールディングス取締役（2023年6月21日まで）、2015年6月25日より関西電力取締役をそれぞれ務めている。
小説家 (諸子百家)
小説家（しょうせつか）は、中国春秋戦国時代の諸子百家の一学派。
故事（世間の出来事、説話など）を語り伝え、書物にして残した。『漢書』芸文志によれば、稗官、すなわち民間の風俗を管理管轄する役人の間から発生したと推察される。主な人物または書名に、鬻子・青史子・師曠・宋子があげられる。
小説家の書物はほぼ現存しないが、法家の『韓非子』（とくに篇名に「説」が付く篇）や、道家の『荘子』、前漢の劉向『説苑』『戦国策』などから、当時の「小説」がどのようなものだったかが窺える。
佚書の『青史子』には、胎教についての記述があったとされ、現存の『賈誼新書』胎教篇や『大戴礼記』保傅篇に引用されている。
後世の目録学・四部分類においては、文言小説が「子部小説家類」、白話小説が「集部」に分類される。
C SharpとJavaの比較
C#とJavaの比較（シーシャープとジャバのひかく）の記事では、プログラミング言語C#とJavaの比較について説明する。
C SharpとJavaの比較 言語
いずれの言語もクラスベースのオブジェクト指向言語であり、その文法はC++に類似しているが、C++との互換性はない。メモリ再利用の手段として、従来の手動で解放する方法ではなくガベージコレクション (GC) を使用する。また、スレッド同期の手段を言語構文に組み込んでいる。
また、いずれの言語もC++のデストラクタに相当する機能を持たないため、ガベージコレクションの管理対象外となるリソース（ファイルやネットワーク接続など）はプログラマが明示的に破棄する処理を記述する必要がある。例外安全に破棄を実行する手段として、try-finallyステートメントのほか、C#ではIDisposableインターフェイスとusingステートメント、JavaではAutoCloseableとtry-with-resourcesが用意されている。両言語にはファイナライザという機能も用意されているが、ファイナライザの動作タイミングは決定論的ではなく、プログラマがリソースを破棄し忘れた場合の最終防壁として用意されている手段であり、一般的に使われることはない。Java 9ではファイナライザが非推奨となっている。
C SharpとJavaの比較 言語
Java、.NETいずれもガベージコレクションの実装形態は細かく規定されていないが、多くの実装でコピーGCとマーク＆スイープGCを併用した世代別ガベージコレクションが使われている。.NET Frameworkは当初から世代別GCだったが、組み込み環境向けの.NET Compact Frameworkは世代別GCではなくマーク＆スイープGCである。
いずれの言語も強い参照と弱い参照の両方をもつ。Javaでは参照がガベージコレクタによって回収された時に通知を受けるリスナーを登録することができる。これはWeakHashMapの性能を考慮したものである。C#にはこれに相当する機能はなく、ファイナライザを使用する方法しかない。その一方、C#は指定したオブジェクトのファイナライザ呼び出しをプログラマが抑止することができる。「世代」の概念をもつガベージコレクションにおいてファイナライザの呼び出しは性能に大きな影響を与えるため、これは非常に有効である。ファイナライザをもつオブジェクトは通常余分な世代が与えられ、回収されるまでに長くかかる。
C SharpとJavaの比較 言語
基本的に実行時コンパイラにより中間表現（.NETの場合は共通中間言語、Javaの場合はJavaバイトコード）を機械語に変換しつつ仮想機械上で実行させる形態をとっており、通常のプログラムコードの実行は実行環境（ランタイム）によってすべて管理される。.NETではこれをマネージコード（マネージドコード）と呼び、C#のような言語をマネージ言語と呼ぶが、Javaについても同様にマネージ言語と呼ぶことがある。いずれもC言語やC++と比べて安全性が高く、例えばnullのデリファレンスや配列の範囲外アクセスなどが発生しても未定義動作とはならず、ランタイム例外として安全に処理される。
C#は、一部の言語設計者から危険であると指摘されるポインタを使用した演算が制限つきながら利用できる。C#はポインタを使用するメソッド、型あるいはコードブロックをunsafeキーワードで修飾することでこの懸念に対応している。これにより、このコードを利用する者はそれが他の部分に比べて危険であるということを知ることができる。また、このようなコードをコンパイルする際にはコンパイラに対して/unsafeスイッチを指定する必要がある。一般に、unsafeコードが使われるのはアンマネージなAPIやシステムコールとの相互運用が必要なとき、あるいは性能の向上が必要なときのみである。
C SharpとJavaの比較 言語
Javaには大別して参照型（クラス型）とプリミティブ型（基本型）が存在する。参照型はjava.lang.Objectクラスから派生するが、プリミティブ型はスーパークラスを持たない。
一方、C#には大別して参照型、値型、ポインタ型が存在する。このうちポインタ型を除き、あらゆる型はすべてSystem.Objectクラスから派生する。クラス (class) は参照型であり、数値型や論理型を含む構造体 (struct) および列挙型 (enum) は抽象クラスSystem.ValueTypeから暗黙的に派生する値型である。
Javaの組み込み型 (built-in type) はプリミティブ型 (primitive data type) と呼ばれる。C#は組み込み型をJavaよりも多く持ち、すべての組み込み型はSystem名前空間に存在する型へのエイリアスである。組み込み型には以下のようなものがある。
C#ではさらに、10の累乗の形で指数部を表す浮動小数点数であるdecimal型をサポートする。decimal型は値型かつ組み込み型であるが、CLRのプリミティブではない。
C SharpとJavaの比較 言語
文字列はいずれの言語においても不変 (immutable) なオブジェクトとして扱われるが、特殊な構築方法として文字列リテラルを利用することができる。C#ではエスケープ文字を処理しないような逐語的文字列リテラル（verbatim文字列: ヒアドキュメントを参照）をサポートする。
C#言語自体にはプリミティブ型という用語は存在しないが、.NET Frameworkの共通言語ランタイム (CLR) では、System.Type.IsPrimitiveプロパティによって、型がCLRプリミティブ型であるかどうかを判定できる。.NET言語組み込みの値型は必ずしもCLRプリミティブ型ではないが、CLRプリミティブ型はすべて値型である。
C SharpとJavaの比較 言語
いずれの言語もプリミティブ型（もしくは値型）と参照型との間で変換するためにボックス化 (boxing) とボックス化解除 (unboxing) が可能である。これによってプリミティブ型（もしくは値型）は参照型のサブセットとみなすことができる。値型は仮想メソッドテーブルを持たず、したがってそのままでは多態性を利用できないが、C#においては、ボックス化によって値型で多態性を利用することが可能である（例えばobject型のToString()メソッドをオーバーライドすることができる）。C#では数値リテラルもオブジェクトであり、たとえば42.ToString()のようにint型のリテラルからメソッドを呼び出すことも可能である。Javaではこのような用途のためにプリミティブ型をラップするクラスが別に定義される。すなわち、42.toString()のようなインスタンスメソッド呼び出しでなくInteger.toString(42)のような静的メソッド呼び出しが必要になる。もう一つの相違点として、Javaではジェネリクスにおいてこのような型を多用するため、暗黙的なボックス化解除が可能になっている（C#ではボックス化せずにジェネリクスを利用できる）。このような変換はnullポインタ例外を発生する可能性があるが、Javaではそれがコード上で明白ではない。
C SharpとJavaの比較 言語
C#では、structキーワードによって構造体を定義することができる。構造体にはフィールドやメソッド、プロパティなどの任意のメンバーを定義できる。引数を持たないコンストラクタ（デフォルトコンストラクタ）をプログラマが定義することはできないが、一つ以上の引数を持つパラメータ化されたコンストラクタを定義することはできる。デフォルトコンストラクタはすべてのメンバーを各々の既定値（通例ゼロ相当の値）で初期化する。C# 10.0以降の構造体は、引数のないコンストラクタをユーザー定義することもできるようになった。また構造体を定義する際、メンバーのメモリレイアウトを属性によって細かく制御することができるため、P/Invokeなどによるネイティブコードとの相互運用にも便利である。なお、構造体は継承元となる基底型を指定することはできず、派生型を定義することもできない。ただし任意のインターフェイスの実装は可能である。Javaには構造体が存在せず、ユーザー定義の値型を作成することはできない。
C SharpとJavaの比較 言語
C#の列挙型は抽象クラスSystem.Enumから暗黙的に派生する値型の一種であり、組み込みの整数型をベースとしている。ベースとなる整数型のどの値も列挙型の値として有効になる（明示的なキャストは必要であるが）。このため、ビットフラグにおいてビットごとのOR演算で列挙型の値を組み合わせることが可能である。ただし構造体と違って任意のインターフェイスを実装することはできない。一方、Javaの列挙型は抽象クラスjava.lang.Enumから暗黙的に派生する参照型である。Javaの列挙型として有効な値は定義においてリストされたものだけである。列挙型の値を組み合わせるためには列挙セットクラスを使用する必要がある。Javaの列挙型では、値によって異なるメソッドの実装が可能である。JavaとC#はいずれも列挙型を文字列に変換することができるが、Javaにおいてはこの変換をカスタマイズすることができる。また、Javaの列挙型は任意のインターフェイスを実装することができる。
C SharpとJavaの比較 言語
プリミティブ型（あるいは値型）は参照型（クラス）とは異なり、インスタンスはヒープ領域ではなくスタックに置かれる。また、（フィールドとして、あるいはボックス化された状態で）クラスの一部になることも、配列の要素になることも可能である。クラスのインスタンスはメモリ上で間接的に参照される必要があるが、プリミティブ型（あるいは値型）はその必要がない。プログラマの視点からは、C#の値型は軽量なクラスとみなせる。しかし、プリミティブ型（あるいは値型）には前述のように多数の制限がある。値型は通常nullの値をとることができないが、.NET Framework 2.0でnull許容型 (System.Nullable) が導入され、C#でも擬似的にnull値を取り得る値型が利用可能となった。
型そのものをコード上で表現するメタデータ型（メタクラス）として、Javaではjava.lang.Classを、C#ではSystem.Typeを利用する。これらはいずれもリフレクションやイントロスペクションで重要な役割を果たす。
C#およびJavaの配列は参照型であり、第一級オブジェクトである。C#の配列は共通の基本クラスSystem.Arrayから派生するが、Javaの配列はjava.lang.Objectから派生する。代わりに、配列のユーティリティクラスとしてjava.util.Arraysが用意されている。
C SharpとJavaの比較 言語
いずれの言語も配列は共変性 (covariance) を持つ。
なお、Java 1.5で拡張for文がサポートされた。これはC#のforeach文に相当する。配列を始めとするコレクション型を、イテレータにより走査することができる。
C#は真の多次元配列（矩形配列）をサポートするが、Javaはサポートしない。C#およびJavaはともに「配列の配列」をサポートする（C#ではジャグ配列と呼ばれる）。
いずれの言語もネストされた型（入れ子にされた型：クラスや構造体のブロックの中で定義されたクラス・構造体・列挙型・インターフェイス）をサポートする。Javaではインターフェイス内部にクラスや列挙型を定義することもできる。C# 7.xまではインターフェイス内部にクラス・構造体・列挙型・インターフェイスを定義することはできなかったが、C# 8.0以降は定義できるようになった。
C SharpとJavaの比較 言語
Javaでは、ネストされたクラス (nested class) は既定で内部クラス (inner class) となる。内部クラスは外側のクラスのインスタンスを暗黙的にキャプチャすることで、静的メンバ、非静的メンバいずれにもアクセスすることができる。ネストされたクラスがstatic修飾されていた場合は静的メンバのみにアクセスできる。メソッドの内部にクラスを定義することもでき、これはローカルクラス (local class) と呼ばれる。ローカルクラスでは、外側のローカル変数には読み取りアクセスのみできる。また、型の名前を持たないローカルクラス（匿名クラス: anonymous class）を定義し、同時にインスタンス生成をすることもできる。
C SharpとJavaの比較 言語
C#では、ネストされたクラス／構造体から外側のクラス／構造体の非静的メンバにアクセスするためには外側のクラス／構造体のインスタンスへの明示的な参照が必要になる。Javaの内部クラスやローカルクラスに相当する機能は存在しない。代わりに、C# 2.0以降では匿名メソッド (anonymous method) が、C# 3.0以降ではラムダ式が、そしてC# 7.0以降ではローカル関数がサポートされ、外側の変数をキャプチャするクロージャとして利用できる。なお、C# 3.0では限定的なローカルクラスとして、匿名型（読み取り専用プロパティのみを持つ、匿名のクラス型）がサポートされる。
C SharpとJavaの比較 言語
Javaではジェネリクスは型消去 (type erasure) によって実装されている。これによってジェネリック型についての情報は実行時には失われ、リフレクションを通してのみ取得できるようになる。.NET 2.0では、ジェネリック型についての情報は完全に保存される。Javaはプリミティブ型に対するジェネリック型は定義できないが、C#では参照型・値型（プリミティブ型を含む）いずれに対してもジェネリック型を定義できる。Javaはその代わりにボックス化した型を使用することができる（List<int>の代わりにList<Integer>など）が、全ての値をヒープに確保し直す必要があるため、パフォーマンスコストが高い。JavaとC#はいずれも、参照型に特殊化されたジェネリック型は、型によらず共通のコードが実行される。しかし、C#において値型に特殊化された場合、CLRは型に最適化されたコードを動的に生成する。.NETにおいては、ジェネリック型に対する型安全性はコンパイル時にチェックされ、CLRにロードされる時に強制される。Javaにおいてはコンパイル時に部分的にチェックされるのみであり、Java VMは実行時にジェネリック型に関する情報を持たないため、キャスト操作を行う必要がある。
C#、Javaともに、ジェネリクスの型制約を持つ。
C SharpとJavaの比較 言語
C#では基底型指定以外に、class（参照型）、class?（null許容またはnull非許容の参照型）、struct（値型）、new()（デフォルトコンストラクタあり）、notnull（null非許容型）、unmanaged（アンマネージド型）の各制約を指定できる。
C#、Javaともに、ジェネリクスの共変性と反変性 (covariance and contravariance) を持つ。ただしC#における共変性・反変性のサポートはバージョン4.0以降である。
C#では、型定義側で共変性outあるいは反変性inを指定し、利用側では変性の指定を行わない。なお、C#の値型は不変 (invariant) であり、共変性・反変性は適用されない。
Javaでは、型定義側では変性の指定を行わず、利用側で共変性extendsあるいは反変性superを指定する。
Javaではさらに、上限と下限のいずれも指定しないワイルドカード?による型引数の指定が可能である。以下にJava 8の例を示す。
C SharpとJavaの比較 言語
C# 3.0でコンテキストキーワードvarによる限定された型推論が導入された。ローカル変数の宣言時に、型を右辺から推論できる。メソッド引数やフィールドには使えない。また、ラムダ式の戻り値および仮引数は型推論により決定される。ラムダ式の仮引数は型を省略することで型推論されるが、型推論が困難な場合には明示的に型を指定する。
Java 7で導入されたダイヤモンド演算子<>は宣言文の右辺ジェネリクスの型を省略できる程度のものでしかなかったが、Java 10ではC#同様に予約型名varによるローカル変数の型推論が導入された。Java 8で導入されたラムダ式では、仮引数の型を省略することで型推論されるが、さらにJava 11ではラムダ式の仮引数の型にvarを使用して型推論できるようになった。
Java 1.5で、あるクラスの静的メソッド・静的フィールドを短い名前で使用するためにstatic import構文が導入された。これにより、例えばClassAクラスのfoo()メソッドを静的インポートして、無関係のClassBクラスにてClassA.foo()のように型名で修飾することなく、foo()を直接使用できる。C# 6.0でも同様の機能としてstatic usingディレクティブがサポートされた。
C SharpとJavaの比較 言語
C#は静的クラス（Javaの静的内部クラスとは異なる）の構文をもち、これによってクラスは静的メソッドのみを持つことができるようになる。C# 3.0から、型に静的にメソッドを追加するための拡張メソッドが導入されている（Foo型のインスタンスfooについての処理を行うBar()拡張メソッドを定義することで、あたかもFooにインスタンスメソッドが追加されたかのように、foo.Bar()と記述できる）。この機能は、クラスの外部で定義した静的メソッドを、そのクラスのインスタンスメソッドであるかのように見せかけて呼び出せるようにする糖衣構文であり、またターゲットとなるクラスのプライベートメンバにアクセスすることはできないため、カプセル化は維持される。
C SharpとJavaの比較 言語
Javaでは、Observer パターンの記述を容易にするために匿名クラスという糖衣構文が用意されている。匿名クラス構文により、クラス本体の定義とインスタンスの生成を同時に行なうことができ、また定義と生成がひとつの式として扱えるため、インターフェイス実装クラスのインスタンスを一度限りしか生成しない場面、例えば特定のインターフェイス実装（あるいは特定のスーパークラスのメソッドのオーバーライド）を要求するイベントハンドラーの設定時などによく用いられる。Java 8ではラムダ式がサポートされ、匿名クラスの代わりに使うこともできる。Java 7まではC#のデリゲートに相当するものは存在しなかったが、Java 8では類似機能としてメソッド参照がサポートされるようになった。
C SharpとJavaの比較 言語
C#ではデリゲート (delegate) 型をはじめ、イベント処理をサポートするための機能が広範囲に渡って言語レベルでサポートされている。デリゲート型はメソッドへの型安全な参照であり、複数のデリゲートを結合してマルチキャスティングすることもできる。デリゲートを結合／分離するための+, -演算子、イベントハンドラーをカプセル化するためのイベント構文 (event, add/remove) や、イベントハンドラーを登録／削除するための+=, -=演算子が用意されている。デリゲートは共変性と反変性 (covariance and contravariance) をサポートし、完全なクロージャとしての性質をもつ匿名関数（匿名メソッドおよびラムダ式）を作成することができる。
JavaおよびC#はともに標準ライブラリでスレッドをサポートしている。OSのスレッド（カーネルレベルのスレッド）に対する薄い抽象化を提供するクラスとして、Javaにはjava.lang.Thread、C# (.NET) にはSystem.Threading.Threadが用意されている。そのほか、セマフォなどの同期オブジェクトやアトミック演算なども標準ライブラリでサポートされている。
C SharpとJavaの比較 言語
言語組み込みの同期構文として、Javaにはsynchronizedブロックおよびsynchronizedメソッドが用意されている。C#にはlockステートメントが用意されている。
C# 5.0以降はasync/awaitコンテキストキーワードによる非同期メソッド構文がサポートされた。このasync/await構文はFuture パターンをさらに発展させたもので、イテレータおよび.NET 4以降で追加されたタスク並列ライブラリ (Task Parallel Library; TPL) を実行基盤とする糖衣構文であり、非同期タスクの完了待機と実行結果の取得、そして後続処理（継続）をあたかも同期メソッドのように記述することができる。このasync/await構文はMicrosoft Visual Studio 2012と同時期にリリースされたVisual Basic .NET 11にも搭載された。その後、さまざまな言語で同様の構文がサポートされるようになった。
Java 1.5以降はjava.util.concurrent.FutureによるライブラリベースのFutureパターンをサポートするものの、async/await構文はサポートされていない。
数学・科学計算・金融分野のアプリケーション開発に十分対応するための言語仕様が、それぞれに存在する。
C SharpとJavaの比較 言語
Java SE 1.2からJava SE 16までは、IEEE 754に準拠した厳密な浮動小数点計算を強制するためのstrictfpキーワードが存在した。これによってあらゆるプラットフォームで必ず同じ値が結果として得られることを保証することができた。1990年代後半の当時、この機能が必要とされた背景は、もともとIntelのx86アーキテクチャにおけるx87浮動小数点命令セットの残念な特性に起因していたが、x64アーキテクチャではスカラー浮動小数点演算にもSSE/SSE2命令を使用するようになったため、厳密な浮動小数点セマンティクスを余分なオーバーヘッドなしに自然にサポートできるようになった。Java SE 17以降は一貫して厳密な浮動小数点セマンティクスが必須となり、意味を失ったstrictfpの機能は廃止された。詳細はstrictfpの記事も参照のこと。C#にはこれに相当する機能はない。
C SharpとJavaの比較 言語
単精度浮動小数点数floatや倍精度浮動小数点数doubleといった二進表現の浮動小数点数は、多くの環境でCPU命令によるハードウェアサポートがあるため高速な処理に適しているが、「0.1」のような十進数の値を正確に表現することができないため、丸め誤差が生じてしまう。金融分野のアプリケーションソフトウェアでは、厳密な十進表現のサポートは必須である。C#には、十進数の厳密な浮動小数点計算に適した128ビットの組み込み型decimalが存在する。この型はSystem.Decimal構造体のエイリアスであり、速度性能および表現可能な値の範囲はfloatやdoubleに劣るものの、有効桁数が28桁と大きく、有効桁数の範囲内であれば十進数データの誤差が存在しないため、二進浮動小数点表現に存在する問題の多くが解決される。Javaでは、このような用途のためにjava.math.BigDecimalが導入されている。また、Java 1.1では巨大な整数を扱うためのクラス型としてjava.math.BigIntegerが導入されている。BigDecimalとBigIntegerは最大で約21億桁程度までの数を任意精度で表現できる。C#においては、.NET Framework 4よりSystem.Numerics.BigInteger型が導入されている。
C SharpとJavaの比較 言語
Javaでは、BigDecimalや複素数型といったライブラリ定義の型をプリミティブ型と同じレベルで使用することは不可能である。また、Javaではユーザー定義型はすべて参照型扱いとなり、メモリブロックの実体はヒープに確保される。一方、C#は次のような機能をサポートする。
これらに加え、C#では数値処理アプリケーションのために、コード中の特定領域において整数型の算術演算および変換に対する算術オーバーフローの実行時チェックの有効・無効を制御するchecked/uncheckedキーワードを使用できる。
Javaは言語仕様をシンプルに保つため、また乱用による難読化を防ぐため、ユーザー定義の演算子オーバーロードをサポートしていない。一方でコードの書きやすさおよび直感性は犠牲になっている。
C#は表記法の多くの点でJavaよりも多機能である。演算子多重定義やユーザー定義キャストなど、それらの多くはC++プログラマによって既に親しまれているものである。
C#はインデクサ（C++のoperator[]に相当）をサポートする。インデクサの定義構文はプロパティと似ているが、this[]という名前をもち、一つ以上の引数（インデックス）を持つ点が異なる。インデクサを定義する際、インデックスには任意の型を使用することができる。
C SharpとJavaの比較 言語
C#は（論理的一貫性を保つための制限はあるものの）ユーザー定義の演算子オーバーロードをサポートしており、注意深く使用すれば簡潔で可読性の高いコードを記述することができる。
また、C#では明示的メンバ実装 (Explicit Member Implementation) が可能である。これによって、インターフェイスメソッドの実装とクラス自身のメソッドの実装とを分離することができ、また同じシグネチャ（名前および引数の数と型の順序）を持つメソッドが異なるインターフェイスにそれぞれ存在した場合に、インターフェイス名を指定して区別することでそれらの実装を別々に行うことができる。
C#のメソッドはデフォルトで非仮想（非virtual）であり、仮想メソッドにする必要がある場合は明示的にvirtualと宣言しなければならない。Javaのメソッドは常に仮想 (C#でvirtual指定された状態) であり、非仮想にすることはできないが、final修飾子を指定することでオーバーライドを禁止することはできる。
C SharpとJavaの比較 言語
Javaでは、メソッドを非仮想的にする方法はない。これは、派生クラスが同名の無関係なメソッドを再定義することが不可能であることを意味する。これは基底クラスが別のプログラマによって書かれており、バージョン更新の際に、派生クラスに既に存在していたものと同じシグネチャのメソッドが追加されてしまった場合に問題になる。Javaでは、この場合どちらのプログラマの意図とも異なり、派生クラスのメソッドは暗黙的に基底クラスのオーバーライドになってしまう（基底クラスでfinal宣言されていた場合はコンパイルエラーになってしまう）。
これらのバージョン更新の問題を部分的に解決するため、Java SE 5.0では@Overrideアノテーションが導入された。これにより、基底クラスが同一シグネチャのメソッドを持ち、それが派生クラスで正しくオーバーライドされていることを保証することはできる。しかし後方互換性維持のため、この指定は必須ではない。従ってIDEやツールなしに上記のように思いがけずオーバーライドしてしまうような問題を防ぐことはできない。
C SharpとJavaの比較 命名規則
.NETでは、外部に公開される識別子のうち、名前空間、型、メソッド、定数フィールドなどの命名にはパスカルケース（アッパーキャメルケース）が使われ、引数の命名にはキャメルケース（ローワーキャメルケース）が使われる。C#コードの命名規則もこのガイドラインに準ずるが、ローカル定数の命名にはパスカルケースが、ローカル変数の命名にはキャメルケースが使われる。
Javaでは、パッケージの命名には小文字の英数字（アンダースコアは含めるべきではない）、型の命名にはアッパーキャメルケース、メソッドの命名にはローワーキャメルケース、定数フィールドの命名にはアッパースネークケース、変数の命名にはローワーキャメルケースが使われる。
詳細は各言語のガイドラインを参照のこと。これらの命名規則は、後述の姉妹言語と相互運用する際にも重要な要素となるため、特に外部に公開される識別子に関してはガイドラインを遵守する必要がある。
C SharpとJavaの比較 字下げスタイル
言語の本質とは無関係だが、公式リファレンスなどのコード例における字下げスタイルとして、C#ではBSD/オールマンスタイル、Javaではサン・マイクロシステムズが1995年（最終改訂は1999年4月20日）に発表した公式のコーディング規約「Code Conventions for the Java Programming Language」に従うことが多い。統合開発環境の自動フォーマッターは通例これらのスタイルに沿っている。
ただし両言語とも構文規則はフリーフォーマットであり、基本的に空白や改行の位置に左右されない。本記事では構文的および機能的な比較のしやすさと省スペース化の観点から、C#のコード例に関してもJavaと同じ字下げスタイルとしている。
C SharpとJavaの比較 実装
Javaはまったく異なる多くのオペレーティングシステム間で実行できる。またパーソナル・コンピュータに限らず、高度な計算処理や制御を必要とする家電製品や、Blu-ray Discのインタラクティブ技術にもBD-Jとして使用されている。このように数多くのJava仮想マシン (Java VM, JVM) 実装が存在する。
C#および.NETテクノロジー自体はクロスプラットフォーム指向であったものの、当初はWindows専用の実装しか存在しなかった。.NET Frameworkはマイクロソフトによる最初の.NETの実装であり、共通言語ランタイム (CLR) はマイクロソフトによる共通言語基盤 (CLI) の実装である。のちに他のプラットフォーム向けに実装された有名なものとしてMono/Xamarinがあり、多くのオペレーティングシステム向けの.NET開発が可能となった。ただし、マイクロソフトによる実装と比較して未実装部分が多く、利用できるライブラリに大きく制限があった。マイクロソフトによるモバイル／組み込み環境向け実装としては.NET Compact Frameworkがあり、Xbox 360などに搭載されていた。
C SharpとJavaの比較 実装
その後、.NET Frameworkとは別に、マイクロソフトおよび.NET Foundationによるクロスプラットフォームなオープンソースソフトウェア (OSS) としての標準実装である「.NET Core」が公開された。なお、.NET CoreのCLR実装はCoreCLRと呼ばれていた。.NET Coreはバージョン5.0で「.NET」と改称された。.NET Frameworkの機能的なバージョンアップは4.8で終了しているが、Windowsへのバンドルおよびメンテナンスは続けられている。
両言語の構文（文法）、プログラミングインターフェイス、バイナリ形式（実行ファイル形式）、実行環境などは様々な機関によって管理されている。
C#はEcmaとISO、JISによって定義されている。標準化の対象は言語構文、基本クラスライブラリ、アセンブリ形式、実行環境（共通言語基盤: CLI）など多岐に渡る。下位層フレームワークの上に新しく実装された上位層ライブラリの多くはこの標準には含まれない（Windows Forms、ASP.NET、ADO.NETなど）。
C SharpとJavaの比較 実装
現在のところ、Javaのどの部分も第三者の標準化団体によって標準化されていない。Javaの商標、ソースコードやその他の素材に関してはオラクル（旧サン・マイクロシステムズ）が無制限の独占的な権利を保持しているが、オラクル（サン）はJava Community Process (JCP) と呼ばれるプロセスに参加し、当事者たちがJavaに関連する技術（言語、SDKからAPIに至るまで）に対する変更を専門家団体や諮問会議を通して提案することを許可している。JCP内の規定では、Javaに対する新しい仕様や変更はオラクル（サン）による承認が必要であるとされている。JCPは営利寄与者に対しては会費が必要としているが、非営利寄与者や個人は無料で参加できる。JavaのAPIセットにはいくつかのエディションがあり、標準エディションのJava SE、エンタープライズ向けエディションのJakarta EE（旧Java EE）、モバイル／組み込み環境向けエディションのJava MEが存在する。
C SharpとJavaの比較 姉妹言語
C#およびJavaには、それぞれの実行環境を用いて動作する姉妹言語が存在し、それぞれ.NET言語およびJVM言語と呼ばれている。姉妹言語は他の既存言語からの移行のしやすさや、記述能力および生産性の向上、あるいは新たなプログラミングパラダイムを導入するなどの目的で開発されたものであり、異なる言語間でユーザー定義のクラス型などを再利用する相互運用も可能である。
各々の代表的な姉妹言語を列挙する。
.NET言語
C#は登場当初、C#.NETと呼ばれており、VB.NETもまた.NET Frameworkに対応する言語として同時期に登場し、当初はほぼ同等の言語機能を持っていたが、C#と比べてバージョンアップおよび新機能の追加は遅れることが多かった。2023年には、VB.NETには今後新しい言語機能は追加されないことが発表された。
C SharpとJavaの比較 姉妹言語
Visual Studio 2005から利用可能になったC++/CLIはC++マネージ拡張の後継言語で、C#やVB.NETほど統合開発環境との親和性は高くないが、マネージコードとネイティブコード両方を混在して記述することができる唯一の言語である。
汎用プログラミング言語ではないが、コマンドラインシェル向けに特化したDSLとして、PowerShellが存在する。もともとは.NET Framework上に実装された「Windows PowerShell」だったが、クロスプラットフォームな.NET Coreに対応したPowerShell Coreとして再実装され、さらにPowerShellと改称された。
JVM言語
矢作神社 (八尾市)
矢作神社（やはぎじんじゃ）は、大阪府八尾市南本町にある神社。式内社で、旧社格は郷社。
「別宮八幡」とも称するほか、「矢作」は「やつくり」とも読む。
矢作神社 (八尾市) 概要
当地は、元は物部氏の傍系一族である矢作連の屋敷跡であったとされ、神社は矢作連の氏神である。
11世紀に石清水八幡宮の掃部別宮（八尾掃部別宮）となり、江戸時代には石清水八幡宮の掃部奉仕をしている。別宮八幡といわれる所以である。
境内には大きなクスノキが数本茂っている。また、社前の大きな銀杏の木は幹に乳房状の突起が多数あり、この樹皮を煎じて飲むと母乳がよく出るとの言い伝えがある。
当社には境内から出土したとされる「三角縁神獣鏡」が伝わっており、八尾市指定有形文化財となっている。
矢作神社 (八尾市) 祭神
主祭神
経津主命
配神
住吉三神
品陀別気命
八重事代主命
高野温泉
高野温泉（こうやおんせん）は、和歌山県伊都郡高野町上筒香（旧国紀伊国）にある温泉。温泉宿があったが、宗教法人 真言宗 女人高野帰命院の施設に代わった。
高野温泉 泉質
※効能はその効果を万人に保証するものではない。
高野温泉 温泉地
和歌山県伊都郡上筒香の狭小な谷間にある僧侶が経営していた一軒宿の温泉。
宿泊のほか、日帰り入湯も可能。渓流沿いの岩風呂は先代が自らの手で造りあげたものである。高野温泉の名から、高野山真言宗総本山である金剛峯寺辺りにあるのではないかと勘違いされやすいが、実際は金剛峯寺からは東へ直線距離にして約12キロ離れた山間にひっそりとある、来る人もまれないわゆる秘湯である。岩風呂はほの暗い半地下に下りてゆくような造りであり、胎内回帰をイメージさせる演出と感じられる。浴槽からは小魚の戯れる小さな渓流が眺められる。浴室内には元々あったと思しき大岩がある。源泉の傍らには弘法大師（空海）の像が祀られている。なお、冬期（1月中旬〜2月）は寒さの為休業している。
また、天然うなぎ料理を出し、和歌山県伊都郡高野町西富貴295の高野山真言宗阿弥陀院住職、西祐慶による水子供養なども行なっていた。
高野温泉 歴史
2007年ごろまでは営業していたが、現在は住職の死去に伴い廃業、「宗教法人 真言宗 女人高野　帰命院」施設となっている（女人高野とは、女性も参拝できるという意味)。
PLCC
PLCC（Plastic leaded chip carrier）とは、電気部品の半導体集積回路のパッケージの一種でQFJとも言う。
イーグル佐藤
イーグル佐藤（イーグルさとう、本名：佐藤 哲夫、 1949年6月11日 - ）は、東京都品川区出身の元プロボクサー。元日本スーパーライト級チャンピオン。野口ジム所属。アマのエリートからプロに転じ、強打とビッグマウスで知られた。
イーグル佐藤 略歴
野口ジム主催のベビーボクシング出身。アマで活躍、59勝4敗の成績を残し、1969年6月プロデビュー。
デビュー戦は引分け、その後4連勝を飾るが、6戦目で初の黒星。8戦目では元日本王者の窪倉和嘉に5回KOで敗れる。その後は快進撃、1971年1月15日、開行憲を判定で破り日本スーパーライト級獲得。その後は開行憲との再戦で初防衛を果たし、ノンタイトルでフェル・ペトランザ、南久雄の両強豪を破るなど気を吐いたが、1972年2月13日、二度目の防衛戦で東海林博に判定で敗れ王座を失った。
4月13日の東海林への挑戦は実らず。その後は李昌吉の持つ東洋スーパーライト級王座に二度、ライオン古山の持つ日本スーパーライト級にも二度挑んだがいずれも不首尾に終わり、再度の王座獲得はならなかった。
水無瀬家
水無瀬家（みなせけ）は、藤原北家隆家流の藤原親信を祖とする公家・華族である。公家としての家格は羽林家、華族としての家格は子爵家。家紋は菊。
水無瀬家 概要
平安時代中期、藤原隆家は兄・伊周とともに叔父・道長と摂関の地位を争って敗れ出雲権守に左遷された。その後、隆家は京に戻り次男・経輔は正二位権大納言となり水無瀬大納言と呼ばれた。経輔の子孫は五堂上家に分かれた。そのうちの坊門中納言親信の子である親兼と、その子の信成は共に後鳥羽上皇の近臣であったが、承久の乱の敗北によって隠岐に流された上皇の遺言（『後鳥羽天皇宸翰御手印置文』）により、信成が上皇より水無瀬離宮跡を託されて、御影堂（水無瀬神宮）を建立し上皇の菩提を弔ったため、水無瀬と称するようになり、これが水無瀬家となって明治維新まで続いた。戦国時代に血統が途絶え、歌道で有名な三条西家から季兼を養子を迎えたため、以後水無瀬家も和歌の家となった。室町時代以降、摂家を除く公家は交替で御所に出仕・宿直する禁裏小番と呼ばれる制度があったが、水無瀬家は水無瀬御影堂への奉仕を理由に免除されていたとされる（『雲上当時鈔』）。明治維新後、忠輔の代に子爵に叙せられた。
水無瀬家 概要
16世紀末には書家として知られた水無瀬家4代の間に将棋の駒銘を印し、「水無瀬駒」と称され「駒の銘は水無瀬公の筆をもって宝とす」と賞賛され、後陽成天皇、豊臣秀次、足利義昭、徳川家康をはじめとする公家や大名家に納められた。特に兼成とその孫の兼俊がよく知られる。水無瀬神宮（大阪府三島郡島本町）にその作品が残されている。兼成の駒製作記録『将棊（しょうぎ）馬日記』から、その作と特定された注文主が道休（足利義昭の法号）の象牙の駒などが有名である。江戸時代の家禄は631石。
明治維新後の明治2年（1869年）6月17日の行政官達で公家と大名家が統合されて華族制度が誕生すると水無瀬家も公家として華族に列した。明治17年（1884年）7月7日の華族令の施行で華族が五爵制になると、同8日に大納言直任の例がない旧堂上家として忠輔が子爵に叙された。
その子忠政は貴族院の子爵議員に当選して務めた。忠政の代に水無瀬子爵家の邸宅は大阪府三島郡島本町にあった。
水無瀬家 系譜
実線は実子、点線（縦）は養子、点線（横）は婚姻関係。
確率質量関数
確率質量関数（かくりつしつりょうかんすう、英: probability mass function, PMF）とは、確率論および統計学において、離散型確率変数にその値をとる確率を対応させる関数のことである（単に確率関数ということもある）。
確率質量関数の定義域は離散的であるスカラー変数や確率変数ベクトルなどの確率要素であることもある。
離散型確率変数の場合は連続型確率変数の場合と異なり、事象の確率は高々可算個の確率質量の和で表される。
確率質量関数 定義
X : S → A (A ⊆ R) を標本空間 S に定義される離散型確率変数とすると、X に対する確率質量関数 fX : A → [0, 1] は次の式で定義される。
確率変数値 a には質量（確率質量）P(X = a) がかかっており、確率質量の総和は
であると考えることができる。
離散型確率変数には順序を与えておくことでその離散確率分布がグラフで表せる。確率変数ベクトルなどの確率要素に対しても同様である。離散型確率変数の像以外では確率質量関数値は 0、すなわち全ての  に対して fX(x) = 0 である。
すると、X の像は高々可算集合であるので、確率質量関数 fX(x) は可算個の点を除いて全領域で 0 となる。確率質量関数の不連続性は、離散確率変数の累積分布関数もまた不連続であることを示す。微分可能な範囲では、微分値は 0 であり、その範囲では確率質量関数もまた 0 である。