北海道の噴火湾に住んでいるとされ、湾の主ともいわれた。足を広げると1ヘクタールもの大きさで、船やクジラも一呑みにしてしまうという。体全体が赤く、アッコロカムイの付近は海はもちろん、空までが体色を反射して赤く染まっていたという。船がうかつに近づくとアッコロカムイに丸呑みにされてしまうので、人々は海や空が赤く染まっている光景を見ると決して近づかず、漁に出るときは用心のために大鎌を携帯したという。アッコロカムイの謂れとして、次のような民話がある。かつてレブンゲ（虻田郡豊浦町字礼文華）の地に巨大なクモの怪物「ヤウシケプ」が現れ、家々を破壊し、土地を荒らし回った。恐れおののく人々の声は神々の耳に届き、海の神レプンカムイが、地上の人々を救うためにヤウシケプを海に引き取ることになった。そうして噴火湾内に引き入れられたヤウシケプは、姿をタコに変えられ、アッコロカムイとして威を振るうようになったのだという。なお、民俗学研究所による『日本妖怪変化語彙』にもアッコロカムイの記述があるが、解説では「大章魚」と書かれているものの、タコとは書かれておらず、そのためか一部書籍では、アッコロカムイはタコではなく巨大な魚と記述されていることもある。
国道168号の東側を通るが、香芝市内では住宅地の間を縫う狭隘な道となっており、車両同士の離合が困難な箇所も散見される。また、国道168号と真美ヶ丘ニュータウンを結ぶ最短ルートの一つであり、通勤時間帯を中心に往来が激しい。
奈良県道203号上中下田線（ならけんどう203ごう かみなかしもだせん）は、奈良県香芝市上中を起点とし、同市下田東を終点とする一般県道。
膨大な博物標本等を有しているのが、フィラデルフィア自然科学アカデミーの特徴で、1700万点以上の生物標本、数十万冊の、学術雑誌、図版、写真、歴史資料があり、個人コレクションの寄付や購入、アカデミーが支援した採集探検の成果やアカデミーの職員として働いた科学者たちによる収集によって充実したものになった。19世紀末にはアメリカ哲学協会の博物標本もフィラデルフィア自然科学アカデミーに移された。保管されている古い博物標本は20世紀後半からの分子系統学などの分類の見直しのための貴重な資料を提供することになった。
画像処理などデータ解析系の処理において、ルックアップテーブル(LUT)は入力データを処理に適した形に変換するのに使われる。例えば、グレイスケールの土星の映像をカラー画像へ変換し、土星の輪のそれぞれを強調するといった処理が行われる。ルックアップテーブルを使用した計算量削減の代名詞として、正弦などの三角関数の計算が挙げられる。三角関数の計算のために処理が遅くなっている場合は、例えば正弦の値を1度ずつ360度すべてに対して予め計算しておくことで、処理の高速化を図ることができる（この際、コンパイル時に静的変数としてテーブルを定義しておけば、実行時に毎回計算を行うコストも省くことができる）。プログラム中で正弦の値を使う際には、最も近い正弦の値をメモリから取得する。この際、求める値がテーブルにない場合は、公式を用いて求め直すこともできるが、テーブル中の最も近い値をもとに内挿することもできる。このようなルックアップテーブルは数値演算コプロセッサの内部でも使用されている。例えば、Intelの悪名高い浮動小数点除算バグはルックアップテーブルの誤りが原因であった。変数が1つしかない関数（例えば正弦や余弦）は単純な一次元配列として実装できるが、複数の変数を持つ関数の場合は多次元配列を使用する必要がある。例えば、ある範囲のxとyに対してを求めるのであれば、power[x][y]という二次元配列を使うことになる。また、複数の値を持つ関数の場合はルックアップテーブルを構造体の配列として実装する。前述のように、ルックアップテーブルと少量の計算処理（例えば内挿）を組み合わせて使う方法もある。予め計算しておいた値と内挿を組み合わせることで、比較的精度の高い値を求めることができる。この手法は単純なテーブルルックアップよりも多少時間がかかるが、処理結果の精度を高めるのには非常に効果的である。またこの手法には、予め計算しておく値の数と求める値の精度とを調整し、ルックアップテーブルのサイズを削減するといった使い方もある。画像処理の分野では、ルックアップテーブルはLUTとも呼ばれる。よくあるLUTの使用法としてはカラーマップ（あるいはパレット）があり、これは画像を表示する際の色や輝度を決めるのに使われる。コンピュータ断層撮影においては、これと同様の概念をウィンドウと呼び、計測された放射線の強度をどのように表示するか決めるのに使われる。LUTは高い効果が得られる場合がある一方で、置き換え対象の処理が比較的シンプルだと、ひどいペナルティが発生する場合もある。計算結果として求める内容によっては、メモリからの値の取得処理やメモリの要求処理の複雑性が原因で、アプリケーションの処理時間や複雑性が逆に増加することがある。また、キャッシュ汚染が原因で問題が発生する場合もある。大きなテーブルへのアクセスは、ほぼ確実にキャッシュミスを誘発してしまう。この現象は、プロセッサとメモリの速度差が大きくなればなるほど大きな問題となる。似たような問題はコンパイラ最適化の際の再実体化においても発生する。他にもJavaなど一部の環境では境界チェックが必須となっているため、ルックアップの度に追加の比較・分岐処理が発生してしまう。ルックアップテーブルの構築を行うタイミングによっては、以下の2つの制約が発生する。一つは使用可能なメモリ量で、それよりも大きなルックアップテーブルを作ることはできない（ディスク上にテーブルを作ることも可能だが、ルックアップが非常に高価になってしまう）。もう一つは、テーブル作成の際にかかる時間で、通常この処理は一回しか行われないが、それでも法外に長い時間がかかるとしたら、そのルックアップテーブルの使用法は不適切だと言えるだろう。ただし前述したように、多くの場合テーブルは静的に定義しておくことができる。