高度な制御機器や近年のECU（エンジンコントロールユニット）では、IEEE754という形式のデータでマップが組まれています。
初期のECUでは、一つの項目を8ビット「バイト byte」で、 00からFF までの 0から255 で表現していましたが、これでは256段階の設定しかできず、高精度な制御には不足します。テーブルの四点を使った補完などで多少精度を上げることはできますが、最初の設定が256であることには違いありません。
精度的に最低10ビット相当の1024段階、さらに12ビットの4096段は欲しいところで、8ビットでは最新の燃料制御に不足します。
そこで 16ビットの「ワード word」が使われているECUが15年ほど前から使われ始めました。
16ビットで表現できるのは 0000 から FFFF までの65536段階です。
これで、かなり精密な制御が可能になりましたが、様々な弊害も発生します。
CPUやROMの内部構造が8ビットであったり、演算にメインのCPUコアを使うので効率の悪化や処理速度の低下（オーバーヘッドが増える）可能性が高くなります。
そこで最近使われつつあるのが、Single IEEE754です。
これは 00000000 から FFFFFFFF、の32ビットを使って表現する単精度実数です。
表現できる範囲が ± 1.5 × 10－ 45～± 3.4 × 1038 という膨大な範囲が表現可能です。
例えば、IEEE754と10進数の対比は以下のようになります。
>IEEE754 → 10進数
>42DC0000 → 110
>47D73200 → 180
>47800000 → 65536
>10進数 → IEEE754
>0.00000001 → 322BCC77
>44881651229444276000 → 601BB6EA
32ビットあれば4294967296段階の表現ができるので、わざわざIEEE754など無駄なようにも思えますが、これには意味があります。
20年ほど前、NEC PC9801初期の頃に浮動小数点演算用のコプロセッサ（浮動小数点演算ユニット）を後付けして高速化を図るのが一般的に行われていました。この「コプロセッサ」によってメインCPUの負担を減らす事で、システムの処理速度を上げるという物でしたが、最近のマイコンにはこのコプロセッサが標準で内蔵されつつあります。
コプロセンサがIEEE754での演算を行っている間に、メインCPUは、他の通信やタイミング制御に多くの時間を割くことができます。
CPUにとってマップテーブルの演算処理は意外と手間がかかることで、別のプロセッサが処理すれば都合がよいことになります。
特に制御系ではテーブル参照（ルックアップテーブル）やマップ制御が多くを占めますので、その効果が高くなります。
このような理由から、マイコンの分野でも IEEE754 が使われつつあります。
最近の外車や国産車の大半はIEEE54形式になっていますが、ほとんどのバイナリエディタはこの形式を扱う事ができません。
ROMMaker 3D は、このIEEE754の編集を可能にする次世代のバイナリエディタです。
→ 
byteでは無意味に見える配列 IEEE754表示ではマップ
近年の車種のROMデータで、４バイトずつきれいに並んでいるが何が何だかさっぱり・・・とい場合は、IEEE754 データの可能性がほとんどです。