約 1,979,713 件
https://w.atwiki.jp/heroonline/pages/12.html
武器データ 装備可能クラスの「剣」は乾坤一刀、「悲」は普陀剣后、「槍」は小医仙、「斧」は大力覇王、 「雙」は那琵亜を表します。 入手方法の「店」はお店、「製」は製造アイテム、「モ」はモンスター、「ク」はクエスト、 「イ」はイベントを表します。表示が薄くなっているところは各当しない部門です。 「※」は現在サーバーに存在しないアイテムを表します。 「Lv」は装着に必要な内功を表します。 特殊防御力の「毒」は毒防御、「麻」は麻痺防御、「混」は混乱防御を表します。 「上段」は上段防御力、「中段」は中段防御力、「下段」は下段防御力を表します。 「s」は秒、「m」は分、「h」は時間を表します。 【防具リスト】 面（男） 面（女） 冠（男） 冠（女） 鎧（男） 鎧（女） 靴（男） 靴（女） 名前 装備可能条件 入手方法 画像 一般防御 武功防御 重さ Lv 上段 中段 下段 詳細 特殊能力 名前 装備可能条件 入手方法 画像 一般防御 武功防御 重さ Lv 上段 中段 下段 詳細 特殊能力 【データ提供】－英雄オンライン－Front Page－友朋の方▲戻る
https://w.atwiki.jp/kenken-tonton/pages/57.html
攻略データ一覧 ----------------------------------- ■攻略データ ○クエスト関連 ├村クエ ├集会場 下位 └集会場 上位 ○装備品関連 ├装備品一覧 └スキル一覧 ○モンスター関連 鳥竜種 ドスジャギィ ドスバギィ ドスフロギィ クルペッコ クルペッコ亜種 飛竜種 リオレウス リオレウス希少種 リオレイア リオレイア希少種 ギギネブラ ギギネブラ亜種 ディアブロス ディアブロス亜種 ベリオロス ベリオロス亜種 ナルガクルガ ナルガクルガ亜種 ティガレックス ティガレックス亜種 アカムトルム ウカムルバス 海竜種 ロアルドロス ロアルドロス亜種 アグナコトル アグナコトル亜種 ハプルボッカ 獣竜種 ボルボロス ボルボロス亜種 ウラガンキン ウラガンキン亜種 ドボルベルク イビルジョー 牙獣種 ドスファンゴ アオアシラ ウルクスス ラングロトラ 牙竜種 ジンオウガ 古竜種 ジエン・モーラン アルバトリオン アマツマガツチ その他 小型モンスター ○オトモアイルー関連 ├武器 ├防具 頭 └防具 胴
https://w.atwiki.jp/awhile/pages/25.html
データストア データストアとは、データセットを保持、管理、配布するためのリポジトリです。 br; br;この用語には、組織によって作成、使用、および保管される、あらゆるタイプのデータが含まれます。 データマート データマートは、企業の財務部門、マーケティング部門、営業部門など、特定のビジネスユニットのニーズに対応するデータウェアハウスです。 データウェアハウス データウェアハウスは、構造化された形式でデータを格納します。これは、分析およびビジネスインテリジェンス用に前処理されたデータの中心的なリポジトリです。 データレイク データレイクは、生データと非構造化データの中心的なリポジトリです。最初にデータを保存し、後で処理できます。 データベース データベースとは、論理的な意味を持ち、データの検索、取り出し、操作、分析を容易にする方法で保存された、組織化された情報の集合体である。データベースは、営業、人事、マーケティング、顧客サービス、その他のさまざまな要件に対応するビジネス・タスクを実行するために、必要に応じて検索できる、類似のトピックや類似のタイプのデータに関する情報を保存するために不可欠です。データベースは、さまざまなスキーマを使用して、目の前のタスクに最適な方法でデータを整理または構造化します。
https://w.atwiki.jp/cg-miku/pages/93.html
調理データ 各調理品回復量一覧表 R1 R2 R3 R4 NPC売材料 メモ 各調理品回復量一覧表 回復量は☆0の最低と☆5の最高を書いたものです。 RCVの関係もあると思うので多少の誤差が出ます。 当サイト運営人達による調査を元にしています。 調理品のNPC販売価格についてはバランサーシステムによって多少変動します。書いてあるのは基本の売値です。 R 名称 HP回復量 MP回復量 備考 R1 ケチャップ 14～18 63～72 現在☆3.5までのデータ R1 ソース なし 70～83 現在☆3.5までのデータ R1 醤油 R1 砂糖 R1 だし汁 R2 ご飯 R2 塩コショウ なし 92～105 現在☆1までのデータ R2 麺調理 R R1 MP消費：8 使用武器：ナイフ 取得経験値 24 画像 名称 効果 NPC売価格 必要材料 前提スキル ケチャップ HP･MP回復 180G トマト 13瓶(NPC) 1 なし #ref error ：画像URLまたは、画像ファイル名を指定してください。 ソース MP回復 180G トマト 6リンゴ 6瓶(NPC) 1 なし #ref error ：画像URLまたは、画像ファイル名を指定してください。 醤油 MP回復 180G 大豆 13瓶(NPC) 1 なし #ref error ：画像URLまたは、画像ファイル名を指定してください。 砂糖 HP･MP回復 180G サトウキビ 13瓶(NPC) 1 なし #ref error ：画像URLまたは、画像ファイル名を指定してください。 だし汁 MP回復 180G 海藻 14水(NPC) 1 なし ※(NPC)と書いてあるものはNPCが販売している物です。※NPCから買う以外に取得方法はありません。 R2 MP消費：20 使用武器：ナイフ 取得経験値 24 画像 名称 効果 NPC売価格 必要材料 前提スキル #ref error ：画像URLまたは、画像ファイル名を指定してください。 ご飯 MP回復 米 20水(NPC) 20 #ref error ：画像URLまたは、画像ファイル名を指定してください。 塩コショウ MP回復 岩塩 20胡椒(NPC) 16 #ref error ：画像URLまたは、画像ファイル名を指定してください。 麺調理 HP･MP回復 岩塩 12小麦 12水(NPC) 10 ※(NPC)と書いてあるものはNPCが販売している物です。※NPCから買う以外に取得方法はありません。 R3 MP消費： 使用武器：ナイフ 取得経験値 Gr 画像 名称 効果 NPC売価格 必要材料 前提スキル #ref error ：画像URLまたは、画像ファイル名を指定してください。 バケット #ref error ：画像URLまたは、画像ファイル名を指定してください。 だし巻き卵 #ref error ：画像URLまたは、画像ファイル名を指定してください。 オムレツ #ref error ：画像URLまたは、画像ファイル名を指定してください。 ※(NPC)と書いてあるものはNPCが販売している物です。※NPCから買う以外に取得方法はありません。 R4 MP消費： 使用武器：ナイフ 取得経験値 Gr 画像 名称 効果 NPC売価格 必要材料 前提スキル #ref error ：画像URLまたは、画像ファイル名を指定してください。 #ref error ：画像URLまたは、画像ファイル名を指定してください。 #ref error ：画像URLまたは、画像ファイル名を指定してください。 #ref error ：画像URLまたは、画像ファイル名を指定してください。 ※(NPC)と書いてあるものはNPCが販売している物です。※NPCから買う以外に取得方法はありません。 NPC売材料 R 画像 名称 価格 備考 R1 胡椒 48G 20個価格ばら売り不可 R1 カレー粉 308G 20個価格ばら売り不可 R1 水 38G 20個価格ばら売り不可 R1 瓶 128G 20個価格ばら売り不可 #ref error ：画像URLまたは、画像ファイル名を指定してください。 メモ 名前 コメント
https://w.atwiki.jp/tf-matome/pages/2.html
武器データ 剣 / ナイフ / ロッド / 斧 / 槍 / ナックル 武器の属性関係 【無＜火＜水＜土＜風＜雷＜闇＜光】 剣 ときどきクリティカルがでてダメージ増える。(1鯖) 戦士、聖騎士、忍者、暗黒騎士、魔法剣士、侍、傭兵、魔界道士、神殿騎士、風来人、狂戦士、剣闘士、司祭、重戦士、流浪剣士、魔獣道士、精霊騎士、アサシン - 名称 攻撃 属性 入手 価格 エクスカリパー 1 無 盗：暴れ大砲拾：暴れ大砲、カリブの薔薇 50 ハリケーン 2 風 盗：トリアングルム拾：トリアングルム 100 ブロンズソード 3 無 拾：暴れ大砲、不吉なカラス 150 ゴブリンソード 4 無 拾：ゴブリンキング、暴れ大砲、ゴブリンライダー 200 ブロードソード 5 無 盗：淡水エイ 300 ロングソード 6 無 拾：不吉なカラス、モロ 400 ミスリルソード 7 無 盗：ジョン、ｴﾄﾞﾜｰﾄﾞ･ﾃｨｰﾁ拾：ゴブリンキング、占い師 500 オーガキラー 8 無 拾：ケルベロス、カリブの薔薇 800 珊瑚の剣 9 水 盗：ラスボスの右腕【ラス亀】、復活の天使拾：ブルードラゴン 1200 古代の剣 10 無 盗：ヒアエノドン拾：ヒアエノドン、リザードナイフ、人喰い蟻 1500 風切りの刃 11 風 盗：ピラルクー拾：ﾈｯﾄﾗﾝﾅｰ 2600 眠りの剣 12 無 拾：不浄骨、ｴﾄﾞﾜｰﾄﾞ･ﾃｨｰﾁ 3300 ルーンブレード 13 光 盗：闇竜王拾：【神蛙】ウラのウラボス使：クリスマスプレゼントの袋 3900 グレートソード 14 無 盗：ドラゴンゴールド 3500 フレイムタン 15 火 盗：パープルバウバウ拾：死鳥 4200 アイスブランド 15 水 盗：光のエルフ拾：ラスボスの右腕【ラス亀】 4000 サンダーブレード 15 雷 盗：リザードナイフ、異次元への扉、ブバスティスの猫 4000 ビーストキラー 16 無 拾：カリブの薔薇 5000 ブラッドソード 17 闇 拾：コロン、モノクル、ﾒｯｾﾝｼﾞｬｰの叫び 8000 エイビスキラー 18 無 拾：ジャイアントスネーク、不吉なカラス 9200 ダイアソード 19 無 拾：( ﾟдﾟ)ｳｯｳｰ、占い師、モルボル 11600 ディフェンダー 20 無 拾：サイクロプス、大蜂 13400 星降りの剣 20 雷 拾：アイボ使：クリスマスプレゼントの箱 18000 エンハンスソード 21 無 拾：人食い蟻、嘆きの亡霊 15700 エクスカリバー 22 光 拾：ゲレゲレ、【神蛙】ウラのウラボス使：クリスマスプレゼントの袋 17900 グラディウス 23 無 拾：アト、ｴﾄﾞﾜｰﾄﾞ･ﾃｨｰﾁ 18500 クサナギブレード 24 土 拾：牛鬼、ちょｗｗｗｗｗ 21000 クリスタルソード 25 無 拾：ジャック 19000 プラチナソード 26 無 拾：カメレオン、コロン 22100 ライトブリンガー 27 光 拾：アンドロスコルピオ、【神蛙】ウラのウラボス 31000 アルテマソ－ド 28 闇 拾：ｴﾙﾒｽﾙｰｼｰｸﾛｺﾀﾞｲﾙ、ﾒｯｾﾝｼﾞｬｰの叫び 34800 ラグナロク 29 火 盗：ワーウルフ拾：ワーウルフ、神竜 41000 ブレイブブレイド 30 無 拾：ダークエルフ、アリゲーター 46000 セイブザクイーン 31 無 拾：首狩り族 50000 アポカリプス 32 無 拾：ラスボス【メタル骸骨】、カリブの秘宝 60000 エクスカリバー２ 33 光 拾：【神蛙】ウラのウラボス 80000 オニオンソード 34 無 拾：鼻血ネ申、オメガ 70000 アルテマウエポン 35 無 拾：ラスボス【メタル骸骨】 100000 タイダルウェイブ 35 水 拾：フォカロル 2450000 ジャガーノート 35 土 拾：リラ 2450000 カラドボルグ 35 風 拾：ガンダルヴァ 2450000 天叢雲剣 35 雷 拾：ガルーダ 2450000 アポロンソード 36 光 使：クリスマスプレゼントの袋 3210000 真剣十代 50 火 拾：鯊草ネ申(1鯖) 0 タシロの見えざる手 50 風 拾：戌ネ申(1鯖) 0 ライオンニート 50 闇 拾：jacoネ申(1鯖) 0 ナイフ 先制のとき、ときどき敵の攻撃をかわす。(1鯖) 逃げるときに攻撃を受けにくい。(1鯖) 盗賊、忍者、赤魔道士、海賊、風来人、魔獣道士、アサシン - 名称 攻撃 属性 入手 価格 ナイフ 2 無 盗：アックスピーク、ゴブリンライダー、スネーク、ゴブリンキング、占い師拾：淡水エイ、カリブの大樽、ケビン 100 ダガー 3 無 盗：大蜂 150 ブロンズナイフ 4 無 盗：パラディン、人喰い蟻、洗礼者ヨハネ 200 ミスリルナイフ 5 無 盗：キノコエルフ拾：アサシン、カリブの熱い夜 400 マインゴーシュ 6 無 盗：海賊船拾：気、カリブの熱い夜 500 オリハルコンダガー 7 無 盗：ブルードラゴン、カリブの熱い夜、ﾊﾞｰｿﾛﾐｭｰ･ﾛﾊﾞｰﾂ 1200 ダンシングダガー 8 無 盗：パイク兵、アリゲーター拾：カリブの熱い夜 2000 エアナイフ 9 風 盗：ｷｬﾌﾟﾃﾝ．ﾊﾞﾙﾎﾞｯｻ、ﾈｯﾄﾗﾝﾅｰ、聖霊の鈴拾：ﾈｯﾄﾗﾝﾅｰ、ライライ 2500 盗賊のナイフ 10 無 盗：カリブの秘宝拾：死鳥 3000 アサシンダガー 11 闇 拾：ウッド、ﾒｯｾﾝｼﾞｬｰの叫び 5600 マンイーター 12 無 盗：シエル拾：海賊の財宝 9800 鬼の腕 14 闇 使：大きな福袋 11600 オニオンダガー 15 無 拾：海賊の財宝、オメガ 24800 ダイヤモンドナイフ 15 光 使：カリブの財宝 24800 チキンナイフ 25 風 拾：田舎将軍、ﾈｯﾄﾗﾝﾅｰ 47000 氷晶の欠片 30 水 拾：フォカロル 2215000 スイスアーミー 30 土 拾：リラ 2215000 マイティナイフ 30 風 拾：ガンダルヴァ 2215000 リッパーナイフ 30 雷 拾：ガルーダ 2215000 破邪の短刀 30 光 拾：ラダマンテュス 2215000 ひのきの棒 50 無 拾：おかちネ申(1鯖)、マリーネ申(2鯖) 0 録音できる冷蔵庫 50 水 拾：meisterネ申(1鯖) 0 どうみても○～ 50 光 拾：鮭ネ申(1鯖) 0 ロッド 同じ属性の魔法が強くなる。 黒魔道士、白魔道士、魔法剣士、赤魔道士、召喚士、青魔道士、賢者、魔界道士、神殿騎士、剣闘士、司祭 - 名称 攻撃 属性 入手 価格 ロッド 1 無 盗：マジョリカ、カリブの薔薇拾：マジョリカ 50 ミスリルロッド 2 無 盗：グレムリン、カリブの大樽 100 炎のロッド 3 火 拾：呪われしバファロー 300 氷のロッド 3 水 拾：光のエルフ、ミニドラゴン、ラスボスの右腕【ラス亀】 300 雷のロッド 3 雷 盗：異次元への扉 300 ポイズンロッド 4 土 盗：スケルトンガード、ちょｗｗｗｗｗ、聖なる福音 1200 リリスのロッド 5 風 拾：ピラルクー、ﾈｯﾄﾗﾝﾅｰ 2600 檜扇 6 火 使：大きな福袋 6200 ウィザードロッド 6 闇 拾：デビルキング、ﾒｯｾﾝｼﾞｬｰの叫び 5800 光の杖 7 光 盗：【神蛙】ウラのウラボス拾：ゾンビ、モルボル 9760 賢者の杖 8 無 拾：baazilネ申(1鯖)、マリーネ申(2鯖)使：クリスマスプレゼントの袋 12000 雪洞扇 9 水 使：大きな福袋 14800 裁きの杖 9 光 拾：薬師、【神蛙】ウラのウラボス、アト 17200 ガイアの杖 10 土 盗：アイボ拾：ちょｗｗｗｗｗ、タウラス、降霊術師 25600 ルビーのロッド 10 闇 使：カリブの財宝 12000 きらきら棒 10 光 盗：ピクシス使：クリスマスプレゼントの箱 12000 ゼウスの杖 12 雷 拾：サハギンデビル 31000 老眼フリーマン 50 水 拾：リィリィネ申(1鯖) 0 逆世界遺産 50 地 拾：焔の鷹ネ申(1鯖) 0 ぴぴるぴるぴ～ 50 光 拾：桃姫ネ申(1鯖) 0 斧 与えるダメージが減ったり増えたり。(1鯖) 暗黒騎士、海賊、傭兵、狂戦士、重戦士、精霊騎士 - 名称 攻撃 属性 入手 価格 ニッケルアクス 4 水 盗：ドロイド拾：ドロイド 400 ハンドアクス 5 無 拾：デビルキング、カメレオン 500 ブロンズアクス 6 無 拾：海賊の証 700 アイアンアクス 7 無 拾：トマス、ﾊﾞｰｿﾛﾐｭｰ・ﾛﾊﾞｰﾂ 2380 ゴールデンアクス 8 無 拾：蘇我有紗、アリゲーター 3500 ヘヴィアクス 9 無 盗：アークデーモン 5400 オウガアクス 10 無 盗：カウバード拾：カウバード、カリブの秘宝 8600 巨人の斧 11 無 拾：ゲレゲレ 11500 古代の斧 12 無 盗：オヴィラプトルの卵拾：オヴィラプトルの卵、ジトジト 17420 大地のハンマー 15 土 盗：ティラノサウルス拾：ノーム、ヤンチュアノサウルス、ちょｗｗｗｗｗ 27980 アンバーハンマー 17 土 拾：岩蛇、ちょｗｗｗｗｗ 33500 死神の鎌 25 闇 使：クリスマスプレゼントの袋 471000 スノウディアー 37 水 使：クリスマスプレゼントの袋 3800000 萌える闘魂 50 火 拾：alizeネ申(1鯖) 0 オマージュ 50 水 拾：jamネ申(1鯖) 0 物干し竿 50 風 拾：baazilネ申(1鯖)、†疾龍†ネ申(1鯖) 0 槍 防御が少し上がる。(1鯖) 竜騎士、聖騎士、モンク、流浪剣士 - 名称 攻撃 属性 入手 価格 スピア 4 無 拾：ボブゴブリン、キノコ、カメレオン 200 ブロンズスピア 5 無 拾：海賊の証 500 ロングスピア 6 無 盗：気、コロッピ、第五の天使拾：ﾊﾞｰｿﾛﾐｭｰ･ﾛﾊﾞｰﾂ 750 ミスリルスピア 7 無 盗：アサシン拾：アリゲーター 900 トライデント 8 水 盗：蜃気楼の兵士 1000 ウインドスピア 9 風 拾：ライライ、パイク兵、ﾈｯﾄﾗﾝﾅｰ 1200 ヘヴィランス 10 無 拾：サイクロプス 3000 ジャベリン 12 無 盗：フォレストジャイアント拾：フォレストジャイアント、上階の重装兵、カリブの秘宝 6000 パルチザン 14 無 拾：ジャック 10000 ホーリーランス 16 光 拾：岩蛇、【神蛙】ウラのウラボス 14900 飛竜の槍 18 風 盗：プテラノドン拾：ブルーリザード、プテラノドン、ネットランナー 18900 グローランス 20 無 拾：ABCDEFネ申、龍ネ申 22500 サファイアの槍 20 火 使：カリブの財宝 22500 ロンギヌス 22 光 拾：【神蛙】ウラのウラボス 36000 グングニル 25 雷 盗：異次元への扉 49000 ハイペリオン 30 火 拾：デュラハン 2470000 オベリスク 30 水 拾：フォカロル 2470000 ゲイボルグ 30 雷 拾：ガルーダ 2470000 ランスオブカイン 30 闇 拾：冥竜王ヴェルザー 2470000 ブリューナク 30 光 拾：ラダマンテュス 2470000 スターゲイザー 38 雷 使：クリスマスプレゼントの袋 3640000 竹やりファンド 50 土 拾：ﾓｸﾞﾓｸﾞネ申(1鯖) 0 インスパイヤ 50 風 拾：saiネ申(1鯖) 0 ハードゲイボルグ 50 雷 拾：mamoネ申(1鯖) 0 ナックル 与えるダメージが増えるかわりに受けるダメージも増える。(1鯖) モンク - 名称 攻撃 属性 入手 価格 メタルナックル 30 無 拾：ハヌル 2000000 流星拳 35 雷 使：クリスマスプレゼントの袋 2550000 エアガイツ 45 無 拾：アトポン 4700000 志村拳 50 水 拾：露魅王ネ申(1鯖) 0 エアガイル 50 風 拾：鼻血ネ申(1鯖) 0 ツンデレビンタ 50 雷 拾：てんネ申(1鯖)、マリーネ申(2鯖) 0
https://w.atwiki.jp/irarchive/pages/1014.html
サイト ホームページ（データアプリ） IRサイト（データアプリ） CSRサイト（データアプリ） 各種ツール 事業報告書（データアプリ） アニュアルレポート（データアプリ） ＣＳＲレポート（データアプリ） 総会通知（データアプリ） 有価証券報告書（データアプリ） 決算短信（データアプリ） 中期経営計画（データアプリ） その他資料（データアプリ） 戻る
https://w.atwiki.jp/ssf4/pages/93.html
ゲームデータ 体力・気絶値一覧 ライバルキャラ一覧 ステージ一覧 溜め時間一覧 着地硬直 起き上がりフレーム ダメージ補正 歩行速度、ダッシュ速度 SSF4での変更点一覧 SSF4 AEでの変更点一覧 基礎知識一覧初心者向け講座一覧（未作成） 基本戦術一覧 目押し一覧 コンボ一覧 起き攻め一覧 連係一覧 反撃一覧 ボイス一覧 キャラ対策一覧 スーパーコンボ一覧 ウルトラコンボ一覧 上段技一覧 中段技一覧 下段技一覧 飛び道具一覧 コマンド投げ一覧 アーマーブレイク技一覧 空中技一覧 うつぶせダウン誘発技一覧 コンボ表示一覧 BPランク一覧 キャラ別 即死・最大コンボ集 ～式テクニック一覧 その他データ 身長/体重一覧 3サイズ一覧 声優一覧 ムック スパ４版(テクニカルガイド 新しき挑戦者達へ) 誤植 ムック スパ４AE版(鍛錬の書) 誤植 ムック スパ４AE家庭用版(精進の書) 誤植 ムック スパ４AE2012版(極の書) 誤植 作業用テンプレート キャラ一覧 キャラ基礎知識 簡易キャラ対策 キャラ対策 キャラ別対策TOP カラーバリエーション キャラ概要 名前 コメント すべてのコメントを見る
https://w.atwiki.jp/thehunter_cotw/pages/77.html
バックアップツール セーブデータ保存場所「COTW」フォルダ\COTW\Saves\数字（steam版 steamID・Epic版 ？） \COTW\Saves\数字\slots\0～2 「Call of the Wild」フォルダ\Call of the Wild\Saves\settings\数字（steam版 steamID・Epic版 ？） \Call of the Wild\Saves\数字（steam版 steamID・Epic版 ？） その他 theHunter Call of the Wild™のセーブデータはプレイヤーのPC上に保存されます。 Steamクラウドは異なるPC間のセーブデータ同期システムのため、場合によりバックアップにはなりません。 保存タイミングがゲーム終了時のため最悪の場合クラッシュが発生した際に破損したセーブデータをアップロードする可能性も有ります。 バックアップツール その1 その2 その3 動作を保証するわけではありません。ユーザー制作ツールのため使用は自己責任でお願いします。 セーブデータ保存場所 theHunter Call of the Wild™のセーブデータはマイドキュメント内の「Avalanche Studios」フォルダに、後述のデータが保存される。 （開発元が同じGeneration Zeroなどもプレイしている場合は、同じくこのフォルダに保存されている） OSインストール時期によっては自動的にOneDriveフォルダの内にマイドキュメントフォルダが作成されている。 ※Epic版の場合Avalanche Studiosフォルダ内に「Epic Games Store」フォルダが作られ、その中に後述のデータが保存される。 セーブデータの内容はSteam版とEpic版でほぼ共通(フォルダの数字などに違いがある程度)で互換性があるので、例えばSteam版のセーブデータをコピーして、Epic版で続きを遊ぶことも可能。 「COTW」フォルダ ゲームのプレイデータが保存されている場所。 \COTW\Saves\数字（steam版 steamID・Epic版 ？） プレイデータ。基本的にこのフォルダを別の場所にコピーしておけば、データが消失しても復旧が可能。 ※悪用厳禁 ファイル名 ファイル内容 ニューゲーム時削除 achievements_adf アチーブメント関連 削除されない adf_fog_of_war_data_faster_0～ マップ開放状況 削除される animal_population_0～ 動物生息状況 削除される missions_missiondata_adf ミッション進行状況 削除される thp_dog_profile_adf 狩猟犬のデータ（名前・レベル等） 削除される trophy_lodges_adf トロフィー・トロフィーロッジのデータ 削除されない \COTW\Saves\数字\slots\0～2 バックアップフォルダ フォルダ名の数字が若いほど新しいデータではない。 一番古いものが最新データで上書きされているためフォルダを開き更新日で新・旧を判断する。 ※安易にこの階層に保存されてるデータで上書きをしないこと。上書き前にバックアップを忘れないように。 「Call of the Wild」フォルダ 設定データ、旧データが保存されている場所。 \Call of the Wild\Saves\settings\数字（steam版 steamID・Epic版 ？） 設定ファイルの保存フォルダ。 ファイル名 ファイル内容 keymap.json 操作キー設定ファイル settings.json ゲーム設定ファイル \Call of the Wild\Saves\数字（steam版 steamID・Epic版 ？） データの保存形式が変更される前のフォルダ。 変更以前からプレイしていれば旧データが存在している。 旧データがあり、新データがなければゲーム開始時にCOTWフォルダに変換されたデータが生成される。 その他 正式実装前のベータテストに参加していると、これ以外のフォルダが存在する場合がある。
https://w.atwiki.jp/nicoap16tsubasa/pages/563.html
チームデータ チームデータ 説明 / キャラクター変更 / エンブレム変更 / ユニフォーム変更 / ユニフォーム早見表(仮) / 限定フィールド選手ユニフォーム / 限定ゴールキーパーユニフォーム / イベント戦歴 コメント 説明 チーム全体のデータが参照できる。 チーム名やプレイヤー名等の変更はここから行う。 キャラクター変更 キャラクターの各種変更ができる。 顔パーツ（目、眉、鼻、口、輪郭）の変更 髪の毛の変更 服（首周り、肩ライン、胸ライン、ユニフォーム柄、ユニフォームベース）の変更※試合時のユニフォームとは無関係？） その他：名前と背景（未実装？）の変更 エンブレム変更 チームのエンブレム（画面左上に表示）とチーム名を変更できる。 ユニフォーム変更 ユニフォームを変更できる。 ユニフォーム早見表(仮) チーム フィールド選手・ホーム フィールド選手・アウェイ ゴールキーパー シャツ パンツ ソックス シャツ パンツ ソックス シャツ パンツ 大友中学 大友中1 白-06 緑-04 大友中2 白-07 白-10 オレンジ-01 黒-03 明和東中学 明和東1 黒-03 青-06 明和東2 白-03 白-08 黒-02 黒-04 花輪中学秋田商工 はなわ1 緑-03 白-05 はなわ2 緑-03 緑-03 黒-05 黒-08 南宇和中学 南宇和1 黒-04 白-02 南宇和2 黒-04 オレンジ-03 青-02 黒-05 大阪東第一中学立浪高校 東一中1 青-05 黒-03 東一中2 青-05 白-06 緑-02 緑-01 ふらの中学道立ふらの高校 ふらの1 黒-04 白-05 ふらの2 黒-04 赤-02 ピンク-01 ピンク-01 比良戸中学 比良戸1 赤-03 ※1 比良戸2 赤-03 赤-02 黒-06 黒-08 武蔵中学 武蔵1 紫-03 青-10 武蔵2 白-04 青-10 黒-04 黒-02 東邦学園東邦学園高等部 東邦学園1 黒-05 黒-03 東邦学園2 黒-05 黒-03 赤-01 赤-01 南葛中学 南葛1 白-05 白-08 南葛2 赤-04 赤-03 緑-01 黒-05 イタリア(JY)イタリアリーグ選抜イタリア(WY) イタリア1 白-04 青-08 イタリア2 青-06 白-06 白-01 黒-02 ウルグアイ(JY)ウルグアイ(WY) ウルグアイ1 黒-05 黒-02 ウルグアイ2 白-08 白-01 黒-01 黒-01 イングランド イングランド1 黒-04 白-04 イングランド2 黒-04 白-03 黄-02 黒-06 アルゼンチン(JY)アルゼンチン(WY) アルゼンチン1 黒-04 白-01 アルゼンチン2 黒-04 青-06 黒-04 黒-02 フランス(JY)フランス(WY) フランス1 白-04 青-07 フランス2 黒-04 白-03 赤-02 赤-01 ドイツ(JY)ドイツ(WY) ドイツ1 黒-04 白-02 ドイツ2 黒-04 黒-02 エンジ-01 青-01 全日本(JY) 全日本1 白-05 白-07 全日本2 青-05 青-09 青-01 黒-02 国見学院 国見学院1 黒-04 黒-04 国見学院2 青-07 青-11 赤-01 赤-01 南葛高校 南葛高校 白-05 白-08 南葛2 赤-04 赤-03 緑-01 黒-05 オランダユースオランダ(WY) オランダ1 白-04 オレンジ-02 オランダ2 オレンジ-03 黒-04 ピンク-01 ピンク-01 サンパウロ サンパウロ1 白-04 白-04 サンパウロ2 黒-04 白-03 黒-09 黒-11 リオ リオ1 白-04 赤-04 リオ2 白-07 赤-04 黒-04 黒-02 リアル・ジャパン・7 RJ7-2 青-02 青-02 RJ7-1 白-05 白-06 緑-03 黒-08 タイ タイ1 赤-05 赤-05 タイ2 青-08 青-12 黄-03 黒-12 ウズベキスタン ウズベキスタン1 青-09 青-13 ウズベキスタン2 白-09 白-11 緑-04 黒-13 サウジアラビア サウジアラビア1 緑-04 白-12 サウジアラビア2 緑-05 緑-05 黒-10 黒-14 中国 中国1 白-10 赤-06 中国2 白-11 白-13 黒-11 黒-15 韓国 韓国1 黒-06 赤-07 韓国2 青-10 白-14 黒-12 黒-16 全日本(アジア1次予選)全日本(合流組) 全日本(アジア1次)-1 白-12 白-15 全日本(アジア1次)-2 青-11 青-14 緑-03 黒-08 メキシコ メキシコ1 白-13 赤-08 メキシコ2 白-14 白-16 オレンジ-04 オレンジ-01 スウェーデン スウェーデン1 白-15 白-17 スウェーデン2 青-12 黄-04 赤-03 赤-02 ブラジル ブラジル1 青-13 白-18 ブラジル2 白-16 青-15 黒-13 黒-17 全日本(WY) 全日本(WY)1 白-17 青-16 全日本(WY)2 青-14 白-19 青-03 黒-18 ※1 どうしても再現したい場合は、白-01あるいは白-08あたりを代用してください。 限定フィールド選手ユニフォーム SAMURAI BLUE 2012-2013モデル フィールド選手 入手方法 シャツ パンツ ソックス [JFA×翼]ユニフォーム(ホーム)参考 ? ? ? 1．期間限定('13/06/07(金) - '13/06/14(金))のSAMURAI BLUE[U]シュートパネルガチャシート1枚目報酬(詳細：ニコ/モバ)2．期間限定('13/06/21(金) - '13/06/24(月))のツバサクラッシュガチャ撃破数 x20報酬(詳細：ニコ/モバ) [JFA×翼]ユニフォーム(アウェイ)参考 ? ? ? 期間限定('13/06/21(金) - '13/06/24(月))のツバサクラッシュガチャ撃破数 x40報酬(詳細：ニコ/モバ) 限定ゴールキーパーユニフォーム SAMURAI BLUE 2012-2013モデル ゴールキーパー 入手方法 シャツ パンツ [JFA×翼]GKユニフォーム(ホーム)参考 ? ? 1．期間限定('13/06/07(金) - '13/06/14(金))のSAMURAI BLUE[U]シュートパネルガチャシート3枚目報酬(詳細：ニコ/モバ)2．期間限定('13/06/21(金) - '13/06/24(月))のツバサクラッシュガチャ撃破数 x30報酬(詳細：ニコ/モバ) [JFA×翼]GKユニフォーム(アウェイ)参考 ? ? 期間限定('13/06/21(金) - '13/06/24(月))のツバサクラッシュガチャ撃破数 x55報酬(詳細：ニコ/モバ) イベント戦歴 今までに参加したイベントでの戦歴を閲覧できる。 チームデータ 説明 / キャラクター変更 / エンブレム変更 / ユニフォーム変更 / ユニフォーム早見表(仮) / 限定フィールド選手ユニフォーム / 限定ゴールキーパーユニフォーム / イベント戦歴 コメント コメント このページの話題のみでお願いします。 名前 コメント すべてのコメントを見る
https://w.atwiki.jp/mopsprogramming/pages/169.html
データの扱い方についての諸観念について、ここで、もうちょっと補完しておくことにします。特に、いつもついでに言及されてきた「抽象データ型」という観念について、もう少し正確に書いておこうかと思います。きちんとやろうとすると本一冊分くらいにはなってしまう題材のようですが、まあ、ごく簡単に。複雑なデータ構造の使い方とか、得失とかにはふれません。また、コードも書きません。って、そういう話を、コードを交えてやるのが、「データ構造とアルゴリスム」とかいう学科の教科書そのものなんで、このページに教科書の一章分を書くなんて大変なことは、わたしにはできません。定評のある教科書を写してもしょうがないし(^^;;)。でも、まあ、汎用の知識ですから、よい教科書はいっぱいあるでしょう。もし後で実際に使う例を見つけられたら、コードも考えてみたいと思います。ここでは、表面を撫で撫で(^^;;)。 抽象データ型という言葉は、ここまでも何回かでてきました。データの並べ方(構造化)と処理手続がパックになったような考え方、これが抽象データ型という言葉で意味されているものだといえます。オブジェクト、というか、クラスという考えは、まさにこの「抽象データ型」という考えに適合しています。構造化されたデータの塊と、それに適合した処理手続であるメソッドのパッケージ化。 アレイ(配列)もスタックも抽象データ型 でも、抽象データ型という考え方は、必ずしもクラスに限られるものではありません。実をいうと、ここまでにも、抽象データ型といえるものをいくつか説明してきました。アレイ(配列)も、スタックも、一種の抽象データ型といえるのです。 というのは、例えば、アレイの説明として、同じ幅のアイテムを縦列し、ポインタのジャンプでもって必要なデータアイテムに到達するというようなことを書いた記憶があります。アレイを、等幅データのメモリー上への縦列として実装するのは、まさにそのような簡単なポインタ計算によるデータの読み出し、あるいは上書きに適合したやりかたであるといえます。このアイテムを隣り合わせで並べていくというのが、アレイのデータ構造(データの構造化方法)であるということができます。そして、アイテムポインタ経由の高速なデータのアクセス(読み出しと上書き)というデータ処理と、アレイのデータ構造はパッケージ化されていると考えることができます。なので、こういったアレイのパターンを用いることは、抽象データ構造の一例と考えることができるわけです。 スタックは、先入後出しという規則を適用することによって、特にデータアイテムの追加/削除を効率化を図ったものです。この規則によって、アイテムの追加/削除にはトップアイテムの所在を管理するポインタだけで済むようになり、アイテムの追加/削除ごとに他のアイテムを移動して順番を詰めたりする必要がなくなるわけです。この観点から、スタックもまたデータ構造とそのアイテムの加除操作を結びつけた抽象データ型としてとらえることができます。 最初の交通整理 ところで、Mopsや一般のForthのスタックは、1セル幅のアレイ風データ構造で実装されていますが、スタック一般がそうでなければならないわけではありません。例えば、いわゆるスタックフレームなどは、区々の幅の塊がつまれていくようになっています。また、各アイテムを隣り合わせで並置していくことも、スタックには必然ではありません。トップスタックを指すポインタが管理できて、先入後出しのデータ追加/削除をするようになっていれば、それはスタックといえるわけです。アレイは「配列」ということで、メモリー上のデータ配置にこだわった名前ですが、スタックは先入れ後出しという処理プロセスにこだわったもので、観点は少しずれていることにも注意してください。 これを言葉としてどのように整理するかです。これは要するに、アレイには、データ構造を示すものとしての意味と、抽象データ型を示すものとしての意味の、二つの意味があると考えればいいでしょう。メモリー上に隣り合わせで縦列された同じ幅で区画されている領域(ハイレベルには、同じ型のデータ格納領域)にデータを格納しておくというデータ構造としてのアレイと、その配置の仕方を利用して高速なデータアクセスを実現するという抽象データ型としてのアレイ、ということですね。Mops/Forthのスタックは現実にはデータ型としてアレイを利用していますが、スタックの概念は、データ型まで指定するわけではなく、先入後出という「構造化データの動的操作」に注目した本来的な抽象データ型概念である、ということになります。なんか、もうだいたいネタばれちゃいましたか？(^^;)。 ええと、弁解です(^^;;)。アレイの定訳は「配列」なんですが、ここまで、大抵、カタカナで「アレイ」と書いてきました。「配列」はわかりやすい言葉なんで、そう書くべきなんでしょうが、この配列という言葉は、逆に一般的な言葉過ぎて、何の気なしに「配列する」なんて動詞風にも使うんで、文の中に埋もれてしまって、そこでコンピュータのデータ構造の配列の話をしているんだよ、という印がなくなっちゃう気がするんですね。なんか、そのまま読み過ごしちゃうというか。「アレイ」とカタカナで書くと、一応そこだけ目立つんで、自分としてはその方がいいかと思ってるんですが、人によっては、かえって分かりづらいかもしれませんね。すみません。でも、そういうことなので、「アレイ」で通したいと思います。 ちなみに、「鉄アレイ」の「アレイ」は、このアレイじゃありませんよ。鉄アレイの方は、実は、漢字なんですよ、ええ。「亜鈴」。もとは「唖鈴」ですね。ダンベル(dumbbell)の意訳。つまり、Dumb(唖 )Bell(鈴)。きっと、教会とかで礼拝に使う、柄付きのベル見たいのがあって、それに形が似てたんでしょうね。なんか、日本の密教の道具にもありそう。で、音がしないのでdumb。いやあ一本取られた(^^;;)。ああ、語源の話は空想なんで、信用しないでください。漢字なのはホント。 抽象データ型としてのリスト、一般名としてのリスト 抽象データ型としてのリスト(List)という観念があります。最古の関数型言語のLISPが、「全てはリストである」という措定の下に設計されているのは有名ですね。LISPはList Processorの略だとかナントカ。もっとも、この場合のリストは、データ構造としてのリストだったようで、データのメモリー上への配置の仕方を特定したもののようです。つまり、リストについても、アレイと同じように、抽象データ型の名前とデータ構造の名前との二つの用法があるわけです。さらに、もっと広くアレイなんかも含めた意味での抽象データ型の一般名としてリストという言い方もあります。こちらには別の名前(シーケンスとか)を与えているものもあるようです。データ構造としてのリストは、後で触れます。 まず、一般名としての広義のリストについて。"リスト(List)"を直訳すると「目録」とかそんな感じですか(ちなみに、"アイテム(Item)"は「項目」と訳せます。)。コンピュータでの概念としては、一列に並べられているものとして互いに関連づけられデータの集まり、というような程度でしょうか。ちょっと、まわりくどいな(^^;;)。観念的には、一列の長さが無限にあってもいいんでしょうが、現実的にはコンピュータは有限のデータしか扱えないわけですから、どこかで切れます。つまり、現実的にはサイズに何らかの人為的制限があります。記憶装置の容量限界までというのも含みますが。 すこし分析的にいうと、まず、複数のデータがあって、それらが関連づけられているんですね。で、その関連づけ方が、一列に並んでいるよ、といわんばかりの関連づけ方である、と(^^;;)。いや、「いわんばかり」じゃなくて、一列にならんでいるんですが。ともかく、「一列に並んでいる」とは、つまり、線状に並んでいるということ、つまり、両端(あれば)以外のアイテムについては左右(上下でもいいけど)両隣関係がそれぞれ1対1で決まっていて、その関係経由でもって全アイテムデータがつながっているということですか。「端がない」リストというのは、つまり、環状に両端がつながっている、ということですね。これもリスト。 じゃあ「隣」関係ってのは何だ、となりますが、これには大別して二つの実現方法があります。 アレイデータ構造でのリストの実現 ひとつは、まさに文字通り、メモリー上に隣り合わせで並べるという方法があります。つまり、アレイデータ構造。だから、アレイというのはリストの実装方法のひとつなわけです。抽象データ型としていうと、アレイはリストの一特殊類型という関係にあります。ある特定の動作の効率性に特化したのがアレイですね。 アレイは、「特化してる」といいましたが、じゃあ、一般的にはどうなんだということですが、抽象データ型としてリストを考えた場合、その動作としては、リスト内のデータの検索と読み出し/上書き(修正)という、いわば静的な動作と、リストへの新規項目の追加、あるいは逆に既存項目の削除、という動的な動作が考えられます。「静的」というのは、リスト長の変更を伴わないということです。もちろんアレイだってリスト長を変更することができないわけではありません。ただ、アレイデータ構造だと、途中にアイテムを追加したいときには、アイテムの追加操作だけでなく、それよりも後ろにあるデータを全部一個ずつ後ろにずらさなければなりません。また、途中のアイテムを取り除くには、そこより後ろのデータを全部一個ずつ前に詰めないといけません。アイテム数がたくさんある場合には、結構な手間になります。そこで、アイテムの追加/削除はほとんどしないことにして、静的な動作に特化したのが抽象データ型としてのアレイ、ということなわけです。 ただ、すぐに分かるように、アイテムを移動して、列を詰めたり、場所を空けたりする必要があるのは、列の中途に何かしたいときだけです。列の端だけを考えるなら、追加/削除のために他のアイテムを移動させる必要はありません。この事実を利用して、高速な加除を可能にしたもののひとつが、スタックなのです。 抽象データ型としてのスタック 抽象データ型としてのスタック(stack)もまた、アイテムの追加/削除という動的な操作に特化したリストということがいえます。データ構造としてはアレイである必然性はありませんが、アレイデータ構造であることと先入後出し操作に限定して効率することとは密接に結びついています。端っこだけ操作するという決まりは、必ずしもアレイデータ構造のリストでなくても、加除操作の効率化をもたらします。ですが、より柔軟な、つまり、複雑な機構を伴ったデータ構造には、それ相応の超過負担があるわけで、アレイデータ構造のようにシンプルであれば、それだけより効率化が図れるといえます。つまり、いってしまえば、どうせスタックにするのならデータ構造にわざわざ複雑な機構を使って柔軟性を与える価値はあまりないといえます。 抽象データ型としてのキュー 端だけ操作することに注目したもうひとつの抽象データ型として、キュー(queue)があります。定訳は「待ち行列」。これは、先入先出(FIFO -- First-In First-Out)法、つまり、突っ込んだ順にしか取り出せないという動作制限をつけて効率化を図った抽象データ構造です。横1列に並べたと考えると、付け足すときは右端、取り出すのは左端から、と決めておけばいいわけです。そして、両端のポインタデータを維持しておけばOKです。使っていくうちにどんどん右に移動していっちゃいますが、限界を設定しておいて、そこに当たったら、突っ込み先のポインタを、ポンと左端に戻せばいいわけです。で、左端から詰めていく。取り出す方も、限界に達したら左端に飛ばす。そうすれば、全体が溢れない限りいつまででも使えますね。 使用済み アイテム アイテム アイテム 入力待ち ↑ ↑ 取出口ポインタ 新規取入口 キューは昔やって来た古いものから順に使っていくわけです。コンピュータでこれがよく使われるのは、イベント処理ですね。つまり、マウスクリックとか、キーボードのタイピングとかすると、その信号が順々にコンピュータに送られていくわけですが、これは、ソフトウェアとしては、イベントとかメッセージとか呼ばれるデータ構造に抽象化されて、キューに突っ込まれるわけです。で、その処理ができる状態になったら一個ずつ順番に処理していくということになります。 ときどき、バッファーという言葉を聞きませんか？キューは、この「バッファー」という言葉の意味に、まったくピタリと適合した動作をします。というか、キューというのはアルゴリスムの観点からの名前、バッファーはハードウエアよりの名前で、働きとしては同じものといっていいような気もしますが。 スタックにしても、キューにしても、アレイデータ構造にする以上、人為的に限界を設定してあるわけで、その限界を超えてアイテムを突っ込むことのないようにしなければなりません。限界を超えることをオーバーフローといいます。まあ、溢れ出し、ですね。逆に、もうアイテムがないのに取り出そうとするのもいけません。それはアンダーフローといいます。 キューもスタックも、その前提からして、そこにデータを溜め込んでおいて使うというものではないように思われます。当座しのぎに取りあえずおいておく場所、というか。この辺は、他のアレイやリストとは違います。「スタックにアイテムをたくさん溜め込むのはよくない」というForth系でよく聞く主張は、その抽象データ型の本質からも正当化できるわけですね。もっとも、加除操作を止めてしまえばただのアレイですが。 キューにもスタックにもバリエーションはあり得ます。例えば、キューの順番でも、単純に入ってきた順序ではなくて、優先順位があって順番が破られ得るものもあります。また、Mops/Forthのスタック操作子は、DROPとDUP以外はトップアイテム以外にもアクセスするので、厳格なスタックの用法には反するといえます。それで、スタック操作には批判も多いのでしょう。もっとも、アレイデータ構造である以上、奥の方のアイテムの読み出しについては効率がいいはずで、効率性の点に関していえば、PICK系(overも含む)は批判される謂れは無いともいえますね。ただ、スタックを操作するのにもう一個スタックアイテムを積むというのは、不格好といえば不格好ですが(自分としてはこの点が引っ掛かってPICKを避けてます(^^;;)。つーか、必要にならないように組めよ、ってことなんですが。)。 「待ち行列」についてなんですが、分かってみれば「なるほど」の訳です。って、もともとが何かを待ってる人の行列って意味のことばが、コンピュータに転用されたんでしょう。でも、始めてこの言葉を見たときには、何のことか全然わかりませんでしたよ(^^;;)。むか～し、よく行ってた本屋に、「応用待ち行列」(今もでてますかね)とかいう題の本があって、そのタイトルだけながめて、応用されるのを待ってる公式かなんか(自然科学系の棚にあったから)が行列をつくってるのをイメージしてましたよ(^^;;)。「応用を待ってるぞ、なんて、妙にキャッチーな題名の公式集だな。受験参考書か？」なんて(^^;;;)。あれがコンピュータアルゴリズムの本だったなんてねえ(遠い目)。 キューってのは、ほら、玉突きの棒もキューですね(スペル違うか？でも意味合いは同じでしょう。)。ギュッと後ろを押すと前からでてくる「ところてん式」(って、ところてん製造機って見たこと無いんですがね。)。あるいは、上からクリームをいれて絞り出してケーキを装飾するやつ(名前忘れた)。 もうぼろぼろだな(||_ _)。イメージはそんな感じ。ともかく、「待ち行列」って言葉にはそういうトラウマがあるので、なんか言葉はあまり使いたくない。すみません。 データ構造としてのリスト データ構造としてのリストは、データ構造としてのアレイに対抗するものといえますが、そこでは「相隣関係」が抽象化されています。アレイではまさにメモリー上の隣、なわけですが、リストでは次のアイテムがあるメモリー上の場所を指すポインタをデータと一緒に保管しておくのです。次のアイテムのポインタを保管する分だけ余分なメモリーを使うわけですが、その分だけ柔軟性が得られます。そのことによって、各アイテムはメモリー上のどこにあってもよいことになるからです。端には無効なポインタ(大抵は0)を詰めておくことも、先頭のアイテムのアドレスを入れて環にすることもできます。 次のアイテムのポインタだけを保存しておく場合には、頭から後ろの方向には辿ることができても、逆向きには進むことはできません。そこで、前のアイテムのポインタも保存しておけば、逆向きに辿ることもできます。そのようなものは、双方向リストと呼ぶようです。 リストデータ構造の利点 -- 柔軟性 データ構造としてのリストのアレイに対する具体的利点は、第一には、端以外のアイテムの追加/削除が軽くなることです。一方向リストでいうと、途中にアイテムを追加する場合でも、挿入する場所のひとつ手前のアイテムに付属している次アイテムのポインタデータを取って、新しいアイテムの次アイテムのポインタデータとして格納し、続いて、ひとつ手前のアイテムの次アイテムポインタをその新アイテムのポインタに付け替えればいいわけです。双方向だとふたつ分ありますが、ともかく、ポインタデータを付け替えるだけでよく、後ろにあるアイテムの移動は必要ありません。その結果、アイテム数が増えても、アイテム追加操作自体には変動はありません。 アイテムの削除のときには、削除するアイテムが保有している次アイテムのポインタを、自分の前のアイテムの次アイテムポインタデータに格納するだけで縁が切れます。 第二には、リスト長の限界が事実上無くなるという利点もあります。アレイデータ構造では、アイテムを一列に並べなければならないため、長いリストのためには、広い、連続したメモリー領域を確保しておく必要があり、いきおい、どこかに明確に限界を設定する必要があります。ところが、リストデータ構造では、アイテム自体は、メモリー上の何処にあってもよく、新規アイテムのためには、メモリーにその分の隙間があればそこに突っ込んでおけば充分です。「相隣関係」は、ポインタによる参照だけで定めることができるからです。動的で柔軟性の高いデータ構造であるといえます。 抽象データ型としての狭義のリスト 上のような見方は、既に、リストデータ構造を、アイテム加除の効率化に注目した抽象データ型としてとらえています。抽象データ型であることに着目するときは狭義のリストということにします。やっぱり、抽象的なリスト概念には別の名前をつけるべきですね。 リストデータ構造の苦手 -- アイテム探索 さて、長所があれば短所もあるものです。各アイテムがメモリーの何処にあるのか予めはわからないのですから、「何項目」と指定して、すぐにそこに到達することはできません。基本は、頭から、ポインタを辿りながら、項目を数えていって、目的地に到達したところで初めて、必要なデータにアクセスできます。つまり、探索など、各アイテムデータへのアクセスは遅くなるのです。挿入/削除のときにも、どこに挿入/どのアイテムを削除するかを決めるのに場所を探索するとすれば同じことです。 そのようなわけで、リストデータ構造を基礎とする抽象データ型としての狭義のリストは、探索の効率性は捨てて、アイテムの自由な追加削除という操作に注目したものといえます。しかし考えてみると、データアクセスにしても、リストの全体に一様な処理を施したい場合には、アレイデータ構造と比較して特に遅いことはありません(nに比例)。すると、リストの全項目への繰り返し操作(Iteration)もまた、抽象データ型としてのリストが得意な動作といえるでしょう。これは、一列に整列されているということの効果であると考えられます。 リストデータ構造とメモリ あと、「弱点」として、もうひとつ挙げておきましょう。これは、リストからのアイテムの削除の図から知ることができます。もっとも、これは柔軟性の裏返しであって、必ずしも弱点ではないともいえますが。 リストアイテムを削除した場合、削除されたアイテムは孤立してしまいます。このアイテムを参照しているアイテムがなくなってしまうからです。この場合、この削除されたアイテムに到達する方法が原理的には失われてしまいます。もはや、このアイテムは要らなくなってしまったわけですが、それでも、人知れずメモリー領域を占拠し続けます。このような状態は、メモリーリークと呼ばれ、非常に見つけにくいバグのひとつです。普通のコンピュータなら、小さいリーク一個で困ることはありませんが、リストへの項目の追加/削除を繰り返しているうちに、要らないデータを格納していながら、他の目的には転用できないメモリー領域がどんどん増大して、システムを圧迫し始めます。 PASCALやC、C++といった「低級」言語では、アイテムを削除するときに、削除されたアイテムを見失う前に、それがあるメモリー領域を解放しないといけません。そうすると、その領域はシステムに返却され、その領域の再利用が可能となります。メモリー領域解放の機能はシステムライブラリ関数として提供されていますから、「複雑な参照関係がない」という前提の下では、これ自体はプログラミング上では大した手間ではありません。 傍論：ガーベージコレクタ 少し話はそれてきますが、このようなリストアイテム削除を取り巻く状況は、LISPが大昔からガーベージコレクタ(Garbage Collector ゴミ集め)機構を備えていた理由を説明するものとなっています。関数型言語であるLISPでは、全てのデータ処理は、値を返すことに専念するものである関数によっておこなわれなければなりません。「メモリーを解放する」などという、計算でもない、関数でもない、機械の特殊性にかかわる低水準のことをプログラムの内容として書き込むことは許されないことだったわけです。そういう「醜い」操作は隠してしまいたい。そのようなわけで、リストから削除され、もう必要の無い項目は、取りあえずはそのままにしておくものの、定期的に自動的にそれを探し出してメモリー領域を解放し再利用可能にするという機構が、開発環境に漏れなくついてきたのです。リストから切り離されても、その開発環境の中では、その項目への参照は保持しておくわけですね。ガーベージコレクトのときのガーベージを探し出す、あるいは印をつける技巧(アルゴリズム)は、いくつか知られているようです。もちろん、速やかにゴミを発見して解放するためのアルゴリズムの工夫です。古いLISPでは、ガーベージコレクトのタイミングで、処理が、クククッと遅くなったりしたそうです。今では高級なプログラミング言語にはガーベージコレクトは不可欠の補助機構と見なされており、複雑な参照関係が張り巡らされた柔軟なデータ構造の処理とともに、うんこの後にケツも拭かず(洗わず)放置するプログラミング習慣も支援しています(^^;;)。 もっと複雑なデータ構造 アレイデータ構造は、複雑にしようとしても限度がありますね。でも、ポインタで関連を付けるデータ構造、つまり、リストデータ構造の応用としては、いくらでも複雑な関連がつくれそうです。アイテムを一列に並べる必要は、全くありませんからね。一般的には、データアイテムを頂点(vertexあるいはnode)で表し、それらの間の参照関係を辺(edge -- 図としては向きがあれば矢印で表す)表すことによって、グラフとして表現できるデータ構造にまで複雑化することができます。 そういった変種の中でも比較的簡単で実用的なのは、Tree(ツリー)構造ですね。「木」とか訳されますが、「木」といわれて、木材というか材木というか、素材としての木を思い浮かべてしまう私は、いかにも日本人なんですかね。「ツリー」とカタカナで書くと、クリスマスツリーという連想経由で、木が生えている状態を想像しますね。やっぱ、ど日本人だわ。まあ、このツリー構造というのは、要は樹形図構造ということなんですが。慣習上、根元を上に、枝の伸びる方向を下に描くようです。「逆木」ですねえ。 ツリーの定義としては、グラフ理論の用語を使うのが普通です。頂点と辺からなる、というわけですが、頂点はアイテム、辺はアイテム間のポインタによる参照関係と思えばいいわけです。ポインタデータを保有している頂点(アイテム)を「親」、そのポインタで参照されている頂点(アイテム)を「子」と呼ぶことがあります。ツリー構造では、どの頂点も、ふたつ以上の親を持つことはできません。これに対して、子は大抵複数になります。データ構造としては根(root)のあるツリーだけで取りあえず充分です。「根」というのは、ひとつの頂点であって、何処からも参照されておらず、逆にそこから参照をたどれば、全ての頂点に至ることができるもののことです。どんなツリーにも根はひとつだけあると考えます。ツリーの定義は再帰的におこなわれます。まず、頂点ひとつだけのものも、ツリーの一種と認めます。次に、ひとつの頂点と、n個のツリーがあって、各ツリーの根に、その頂点から辺をおろしたものもツリーと認めます。これで、ツリーは定義できます。ひとつの頂点を適当に取って、そこからたどることのできる頂点と辺を合わせたものもツリー構造になりますが、これはもとのツリーの部分ツリーといいます。 なぜツリー構造が考えられるに至るのか、というと、リスト構造のアイテム探索が苦手であるという特性を克服しようとしたわけです。リスト構造では、アイテムの探索には、基本的には頭からひとつずつたどっていくしかないので、アイテムの個数nに比例して、探索の手間が増えてしまいます。これに対して、ツリー構造にしておけば、枝分かれしている分だけ、探索していく道が短くなります。大体、nが増えるときには、規模としては平均的にlog nに比例する程度にしか、探索の手間は増大しません。ちなみに、コンピュータ関係でlog nと書くときは、その底は2だそうです。つまり、log2nということですね。ビットで測るってことでしょうか。 基本的なものとしては、Binary Tree(二分枝木)というのと、Balanced Tree (平衡木)くらいは簡単にふれておきましょう。 Binary Treeはその名の通り、枝わかれ(子)が二本(以下)のツリーです。必ず二つというのではなくて、二つ以下ということです。結果として、枝が一本きりのリスト構造も、Binary Treeに属するということになってしまいます。そのため、ツリーの作り方によっては、探索の効率化が望めなくなってしまいます。一番いいのは、できるだけきれいに二分枝を張ることです。そうすれば、階層の深さ、つまり、根から枝の末端(「葉」(leaf)といいます)に至るまでの中間のアイテム数が、全アイテム数nに対してlog n程度になることがわかるでしょう。 という話で気付くかもしれませんが、Binary Treeという名前は、そのデータ構造に着目した名前ということになります。抽象データ型としてみると、アイテムの探索とデータアクセスの効率化です。アレイと比べると劣りますが、狭義のリストよりは性能が上です。 アイテムの加除も、ポインタ参照によるリストデータ構造の応用ですから、ポインタの付け替えだけで済み、効率は悪くありません。ツリーへのアイテムの追加は、何らかの方法でアイテムに順番をつけておいて、その順番にしたがって挿入箇所を決めることが前提とされています。いつもお尻だけを操作するというのでもいいのでしょうが。ただ、一般的には、追加削除を繰り返すうち、枝分かれが減ってリスト構造に近づいてしまい、探索効率が落ちてしまう危険があります。この点を回避しようとするのがBalanced Treeなんですが、むしろ、Binary Treeは、そういった配慮をしない二分枝木であるという形で、Balanced Tree区別されるに過ぎません。 平衡木(Balanced Tree)の「平衡(Balanced)」というのは、枝分かれを平均にして、枝の長さが偏らないように、かつツリー階層の深さができるだけ浅くなるように配慮しつつ、アイテムの追加削除をおこなうという意味です。探索の効率にかかわるのは結局、ツリー階層の深さであることは明らかですね。 その「平衡」は、枝分かれの個数に、上限だけでなく、下限も設定することで実現されます。メモリー上のデータ構造として使い道がありそうと考えられているものに、2-3木というのがあります。これは、枝分かれは、最大3、最低でも2に維持する平衡木です。アイテムの追加とか削除の結果、3本以上の枝わかれが必要になりそうなとき、あるいは、枝が一本に減ってしまいそうなときは、新しく分岐点をつくったり、隣の分岐と合併したりして、枝数を調整します。そして最終的には、根から葉までの距離が全て等しくなるようにします。そうすれば、アイテムの追加/削除を繰り返しても、探索の効率が極端に落ちてしまう構造に変改することを防ぐことができるわけです。 枝のすげ替えによる調整は、ひとつの作業自体はそれなりに手間がかかりますが、全アイテム数nの増大のときには、その割には負担は増えていかないということが知られています(log nの規模)。 2-3木を一般化したものとしてB-Treeという概念があります。これは、最多分枝数をm(3以上)とし、最少分枝数をmの半分より大きい最少の整数として、深さを均一にしたものです。m=3で2-3木になることは容易にわかりますね。ただ、一般のB-Treeは、メモリー上のデータ構造よりも、ファイルとかそういう外部記憶装置に保管するデータ構造に向いているとされています。 抽象データ型について書こうかと思ったので、公共の図書館からその方面の本を借りて、読んでみました。この種の本を読む(多くは立ち読み...すみません)といつも思うんですが、退屈です。いや、それなりに興味深いことは書いてあるし、大抵はプログラム例が載っていて、本来ならそれなりに面白いはずなんですけど、どうも...。いや著者が悪いとかいうつもりは無いです。多分、汎用アルゴリスム一般なんてのには、普通は関心が向かないからじゃないかと思います(もちろん、人による)。つまり、なにか自分が面白いと思うことをするプログラムを書いていて、その途中で何かうまい手順が必要になったというなら、きっと目を剥いて読むんじゃないでしょうかね。 喩えていうなら、釘と金槌、のこぎりとかんなでもって木造建築をつくるのはおもしろいとしても、釘や金槌のことばかり延々説明されても、という感じですか。もっとも、釘の打ち方やノコのひきかたをきちんと習得していないと、まともな木造建築などできそうにない、というのも確かなことではあります。 現実問題、「アルゴリズムとデータ構造」の教科書レベルででてくるアルゴリズムなんてのは、大抵の開発環境には、ライブラリとしてついてきます。ですから、普通のプログラミングでは、そのアルゴリスムを自分で実装するなんて必要は無い。まあ、上の喩えでいえば、釘や金槌などから自作することはないっ、ってことですか。でも、使い方は知らないと、建築はできない。ので、アルゴリズムの名前と、その得失を憶える、というところに集中するんでしょうね。でも、それじゃあ、達成感はあまりない。そんなわけで、入門者にはとりあえずいくつか金槌とか釘とかつくってみましょう、と勧めるわけですね。作ってみて初めて得心がいく、って場合もありますし。それに喜びを見いだせる人はそれでいいんですがねえ。 Forth系でも、商品版ではついてくるんじゃないかと思います。ライブラリ。Mopsでは、その手のライブラリは薄いですね。リストとしては、ポインタリストとハンドルリストがありますが、どっちも上で説明したような、前後を参照した線形のリストじゃないです(アイテム探索速度はO(n0)てか、O(1)です。ポインタ/ハンドルを伸縮するアレイ(追加はいつもお尻に)で管理してますから。だから、Mopsマニュアルにかいてあるんですね、「アイテムの削除をあまり頻繁にはしないということを前提にしている」って。)。一応、Mopsでも内部的には線形のリストも使われてます。単純なデータ構造なんて、プログラムに必要になったらつくりゃいいんで、理屈がわかりゃあ大した手間じゃないです(つくれないのは、理屈が充分にわかっていないからですね)。というか、ツリーとかなんか、シミュレーション以外にどうしても必要って局面なんかあるんですかね。探索ならハッシュでいいわけだし。構文解析とか、かな？まあ、よくわかりません。 自分としては「茶道」主義だと思いますね、Mopsは。生け花とか、山水画とか、造園とか、今じゃあ分かれてますけど、そういうのはみんな、お茶室を演出する技巧として茶道から派生したんですよね。茶碗を焼くところから入るんですからね、お茶は。お客様をもてなす心を突き詰めれば、ひとつだにゆるがせにはできない...って、やりすぎだって。ま、自作じゃなくても、良いものを見極めて使えば良い、ということですがね。そういえば、Forthの心は禅の心なんて話もありますが、喫茶の習慣は禅僧から始まったんですよね。ん～、商品化というのは心を喪うことなのでしょうかね(^^;;)。ただ、「お客様をもてなす心(一期一会)」に当たるMops/Forthプログラミングの求心力って、何でしょうねえ ... ？ 前へ 次へ 目次へ トップページへ