高度な制御機器や最新の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
IEEE754を使わなくても、32ビットあれば0から4294967295 の4294967296段階までは表現できるので、大きな数を扱えるからと言ってわざわざIEEE754など無駄なようにも思えますが、これには意味があります。
20年ほど前、NEC PC9801初期の頃に浮動小数点演算用のコプロセッサ（浮動小数点演算ユニット）を後付けして高速化を図るのが一般的に行われていました。
この「コプロセッサ」によってメインCPUの負担を減らす事で、システムの処理速度を上げるという物でしたが、最近のマイコンにはこのコプロセッサが標準で内蔵されつつあります。
コプロセンサがIEEE754での演算を行っている間に、メインCPUは、他の通信やタイミング制御に多くの時間を割くことができます。
CPUにとってマップテーブルの演算処理は意外と手間がかかることで、これを別のプロセッサが処理してくれれば非常に都合がよいことになります。
特に制御系ではテーブル参照（ルックアップテーブル）やマップ制御が多くを占めますので、その効果が高くなります。
こういった理由から、現在では IEEE754 が使われつつあるのです。
最近の外車や国産車の大半はIEEE54形式になっていますが、ほとんどのバイナリエディタはこの形式を扱う事ができません。
ROMMaker 3D は、このIEEE754の編集を可能にする次世代のバイナリエディタです。
→
byteでは無意味に見える配列 IEEE754表示ではマップ
ROMデータをエディタで見た時、４バイトずつきれいに並んでいるが何が何だかさっぱり・・・と言うときには、IEEE754 データの可能性がほとんどです。