關(guān)于可移植的浮點(diǎn)數(shù)操作

starwing83

C標(biāo)準(zhǔn)在這一塊實(shí)在是太混亂了……除了預(yù)定義了IEEE_xxx預(yù)處理符以外就沒干過什么事兒。float.h里面的內(nèi)容太過繁雜了……問問，有沒有人知道有什么標(biāo)準(zhǔn)的庫可以操作浮點(diǎn)數(shù)的？具體是這樣：

1. 取得浮點(diǎn)數(shù)的所有bits，按照規(guī)則填入某個(gè)確定的結(jié)構(gòu)體（fpbits）
2. 能將浮點(diǎn)數(shù)輸出成hexaformat的字符串（C99 printf的%a實(shí)現(xiàn)）
3. 能按照規(guī)則將浮點(diǎn)數(shù)輸出成字符串（C99 printf的f，d，e，E，g，G等等實(shí)現(xiàn)）

關(guān)鍵是體積小，移植性好，有沒有人有點(diǎn)主意的？現(xiàn)在在看gdtoa這個(gè)庫，體積稍微有點(diǎn)大了（編譯出來的.a有185k……），另外代碼實(shí)在很亂（這個(gè)倒不能怪他，畢竟兼顧了幾乎所有的硬件平臺(tái)了），不知道有沒有更好的……

OwnWaterloo

>> 2. 能將浮點(diǎn)數(shù)輸出成hexaformat的字符串（C99 printf的%a實(shí)現(xiàn)）

1. 
   
2. double x = ...;
   
3. unsigend char bytes[sizeof x];
   
4. memcpy(bytes, &x, sizeof x);
   

復(fù)制代碼

然后按整數(shù)來？


>> 1. 取得浮點(diǎn)數(shù)的所有bits，按照規(guī)則填入某個(gè)確定的結(jié)構(gòu)體（fpbits）

取bits和上面一樣吧。。。
"所有bits"的意思其實(shí)是將所有bits分類并取出？ 解析bit pattern？
這C標(biāo)準(zhǔn)肯定不會(huì)規(guī)定的。。。 連整數(shù)都曖昧不明。。。  就不要指望浮點(diǎn)了。。。


>> 3. 能按照規(guī)則將浮點(diǎn)數(shù)輸出成字符串（C99 printf的f，d，e，E，g，G等等實(shí)現(xiàn)）

同上。。。 C就是這么拽。。。


>> 這個(gè)倒不能怪他，畢竟兼顧了幾乎所有的硬件平臺(tái)了

這樣呢？ 就先只負(fù)責(zé)IEEE754。
對(duì)其他的找個(gè)靠譜的fallback。。。 比如你提到的那個(gè)gdtoa，又或者libc。。。
等真正遇到非IEEE754的時(shí)候再說。。。

這么多古怪的機(jī)器哪有精力研究完。。。
說不定gdtoa支持的那些"所有"硬件平臺(tái)當(dāng)中許多都已經(jīng)不存在了呢。。。


BTW：如果找到滿意的了麻煩通知一聲。。。

starwing83

回復(fù) 2# OwnWaterloo


    剩下兩個(gè)同意，第一個(gè)你理解錯(cuò)了，hexaformat不是說的把浮點(diǎn)當(dāng)作整數(shù)然后得到16進(jìn)制表示，而是一種特殊的浮點(diǎn)數(shù)表示格式，比如說1.23456的hexaformat就是0x1.3c0c20p+0，理論上可以根據(jù)hexaformat完全還原一個(gè)浮點(diǎn)數(shù)的。所以這貨其實(shí)依賴1)的實(shí)現(xiàn)（得把浮點(diǎn)數(shù)按照結(jié)構(gòu)劃分開），不然就沒治。

其實(shí)我也不想這么麻煩，遇到問題轉(zhuǎn)發(fā)給sprintf也就算了。問題是1)該死的微軟的printf根本不支持%a的格式（C99規(guī)范） 2)微軟沒有snprintf。這樣基本上浮點(diǎn)這一塊就沒轍了。所以我得想辦法自己弄一個(gè)出來。

starwing83

回復(fù) 2# OwnWaterloo


    還有，IEEE754也分大小端，處理起來也未必輕松………………

OwnWaterloo

回復(fù) 3# starwing83

我的錯(cuò)。。。 也就是3個(gè)都需要理解浮點(diǎn)格式了。。。

微軟好像有snprintf，只是不叫這個(gè)名字。。。

也就是說。。。 在windows上一個(gè)靠譜的fallback都找不到？
gdtoa呢？ 非windows上的libc呢？（mingw好像也是直接用的ms的runtime...）
還有windows只支持幾個(gè)硬件平臺(tái)的吧。。。 它們是不是都是ieee754的。。。？

OwnWaterloo

回復(fù) 4# starwing83

大小端比浮點(diǎn)格式容易吧？
大小端也是所有byte換順序吧？ 不是幾個(gè)part當(dāng)中的bits換順序吧。。。 這就煩了。。。

folklore

@starwing83

微軟沒有snprintf

http://msdn.microsoft.com/ja-jp/library/vstudio/2ts7cx93.aspx

1. 取得浮點(diǎn)數(shù)的所有bits，按照規(guī)則填入某個(gè)確定的結(jié)構(gòu)體（fpbits）

除了自已解析IEEE，沒想到什么好辦法，不然寫個(gè)自定義的float的類。如果要支持3D運(yùn)算，因?yàn)楹陀布�相關(guān)，基本就更法子了

2. 能將浮點(diǎn)數(shù)輸出成hexaformat的字符串（C99 printf的%a實(shí)現(xiàn)）
3. 能按照規(guī)則將浮點(diǎn)數(shù)輸出成字符串（C99 printf的f，d，e，E，g，G等等實(shí)現(xiàn)

簡單點(diǎn)的，就寫個(gè)myprintf,在里面除了解析%a外，都二轉(zhuǎn)給vsprintf吧。。。

starwing83

回復(fù) 5# OwnWaterloo


    似乎有個(gè)sprintf_s，但是據(jù)說語義不太一樣……

反正如果是IEEE_x的話，會(huì)定義這個(gè)預(yù)處理符的，所以如果真要解析也不是什么很困難的事情……

MinGW就猥瑣了……從glibc里面提了一個(gè)snprintf，用的就是這個(gè)，其他的才轉(zhuǎn)發(fā)給msvcrt，也就是說，如果限定MinGW倒也沒多大問題，但是最終編譯的大小會(huì)增加40K左右的樣子…………然后MSVC就完蛋了。

如果下定決心分析IEEE754也還好，可是這個(gè)標(biāo)準(zhǔn)的執(zhí)行也語焉不詳。比如說long double吧，有些平臺(tái)是80，有些平臺(tái)是64，你咋搞……

總的來說就是困難啊………………

Lua的源代碼里面很簡單的用LUA_USE_AFORMAT判定是否支持%a……典型的鴕鳥策略……不過也很成功就是了……然后Lua完全放棄了snprintf，而采取預(yù)先計(jì)算長度，然后用確定的format讓sprintf搞事……也不是不可以，但是計(jì)算長度的代碼很那個(gè)啥……

starwing83

回復(fù) 7# folklore


    應(yīng)該是非常后期才加，msvcrt里面就別想了，如果用了可能導(dǎo)致dll依賴msvcrtxxx.dll，這個(gè)很麻煩的。

%a的問題我記錯(cuò)了，好像微軟是支持的，但是有bug（？）反正Lua郵件列表專門討論過這些問題。

我打算放棄了，整數(shù)部分我自己搞，浮點(diǎn)轉(zhuǎn)發(fā)給sprintf好了……反正這幾個(gè)精度都是確定的，那么長度就很好確定了……