Írnom kell egy számításból származó adatokat, amelyeket később a Paraview (.vtu vagy vtk fájl) olvas el.
Ha a fájlméretről van szó, akkor az ASCII vagy a bináris formátumot kell választanom?
Válasz
Ha az egyetlen gond a fájlméret, akkor bináris fájlokat szeretne. Szemléltető példaként tegyük fel, hogy 1 dupla pontosságú lebegőpontos számot írsz egy fájlba. Tegyük fel, hogy a fájlrendszer ezt tökéletesen tudja kezelni, és a fájl, a fejlécek és a kitöltés mind 0.
Bináris fájl esetén ez a szám pontosan a RAM méretét veszi fel, vagy 8 bájt.
ASCII formátumban a következőket tartaná:
- az alap 16 számjegye
- 1 pont a tizedesig
- 1 karakter a kitevő határolására
- 1 karakter a kitevő jelére
- 2-3 karakter a kitevő
Feltételezve csak 1 bájtot használ egy karakterhez, azaz 22 bájtot ugyanarra a számra. Ez nem számolja azokat a karaktereket, amelyek szükségesek a számok közötti dilimációhoz (általában legalább 1). Ezért az ASCII formátum fájlmérete körülbelül háromszor nagyobb lesz.
A fájlmérettel kereskedhet a pontosság érdekében a tárolt fájlokban (csak 5-6 számjegyet tartson az alapban), de ez attól függ, hogy arra használod őket. Az ASCII fő előnye az ember által olvasható adatok hibakeresése vagy előállítása.
Megjegyzések
- A tudományos színtéren szintén fontos a hosszú távú archiválás és megbízható megosztás, éppen ezért ‘ hatékonysága ellenére az ASCII CSV annyira elterjedt és ajánlott (PDF) .
- Egy másik hasznos szempont, hogy bár az ASCII CSV kódolás nem ‘ nem túl hatékony, fájltömörítő segédprogramot (például zip, gzip stb.) használ az ascii-n A fájl általában a bináris fájl méretéhez hasonlóra csökkenti a fájl méretét.
- Legyen óvatos, mert egyes bemeneti / kimeneti könyvtárak ‘ nem eléggé óvatosak hogy megkaphassuk a bitek reprodukálhatóságát, amikor IEEE Double Precision számokat adunk ki az ASCII-ben, majd visszaolvassuk őket. Tapasztalataim szerint a biztonság érdekében néha 17 vagy 18 tizedesjegy használata szükséges.
- Horchler ‘ s megjegyzés: Én ‘ biztos vagyok benne, hogy a jól használt, szabványosított nyílt bináris formátumok, mint például a HDF5, sokáig rendelkezésre állnak. ‘ amit személyesen ajánlok ‘.
- + A bináris lehetőségekhez ragaszkodom, amikor csak lehetséges, a pontosság érdekében, tömörség, nyugalom és (különösen) gyorsaság. Aztán ha további tömörségre van szükségem, akkor cipzárral zárhatom. Ha vizuálisan el kell tudnom olvasni a tartalmat, írhatok ehhez egy kis programot. Másrészt, ha ‘ fontosabb, hogy vizuális legyen, és könnyen átadható olyan véletlenszerű programoknak, mint az Excel, R stb., Akkor a CSV a megfelelő út.
Válasz
A gyakorlatban ritkán van szükség olyan adatokra a vizualizációs fájlokban, amelyek pontosabbak, mint mondjuk 3 érvényes számjegy. Ebben az esetben az ASCII – talán meglepő módon – gyakran kompaktabb, mint a bináris forma. Ha az archiválásra gondol, akkor ezeknek az ASCII fájloknak a bzip-beírása valószínűleg a lehető legkisebb fájlokat fogja eredményezni.
A Paraview elolvassa a VTU formátumot, amelynek tömörített bináris formája van (XML-alapú, de az adatokat először libz-formátumban tömörítik, majd újra kódolják, hogy ASCII szöveget kapjanak). A tipikus fájlokon ez 4-10-es tényezőt takarít meg. Nagy fájlok esetében ez mindenképpen a helyes út.
Megjegyzések
- Ezt a másik válasz ellentétére szavaztam. Nincs ‘ egyik oldalon sem erős véleményem, de ‘ jó szempont lehet itt.
- Alternatív megoldásként kifejezetten nullázzuk az alacsony biteket, és tömörítsük a bináris fájlokat.
- Hűha, ehhez meglehetősen kevés fikázásra lenne szükség. Vagy vannak olyan funkciók, amelyek ezt csinálják? (Az úszás és a kettős visszaállítás kivételével.)
Válasz
tl; dr – fájlokat tárol az utf8 fájlban. Ha táblázatos, akkor használja a tabulátorral elválasztott értékeket.
Számomra úgy tűnik, hogy a megfelelő beállítások a következők:
- utf8 szöveg ( nem ASCII . Nem vagyunk minden amerikai angolul beszélők)
- bináris
ASAICT a bináris fájlok egyetlen igazi előnye a teljesítmény. Sokkal gyorsabban be lehet tölteni egy memóriakiírást a memóriába, mint a kifelé vezető úton szöveget generálni, vagy a belépéskor elemezni.
Vagy itt: https://auth0.com/blog/beating-json-performance-with-protobuf/ (Ez nem tudományos, és az általános teljesítményt tárgyalja, a nagy különbségek a továbbított adatok mennyisége és a szöveges adatok felé torzított elemzési idő között vannak. )
Az esély, hogy egy bináris fájlformátum megfelelően támogatja az unicode szöveget, gyenge, ezért ha az adatok integritása érdekli, ne használja a bináris . Hallottál már endian problémákról is? Az aláírt egész számok és lebegők különböző bináris ábrázolása?
-100000 és -1e + 6 szövegábrázolása nem változtat értéket a CPU-n (mindenképp az utf-8 és az ASCII fájlokban).
Az esélye, hogy egy bináris fájlt értő program még mindig meg fogja érteni, vagy 50 év múlva is fut, ismeretlen, valószínűleg nem jó . Ha érdekel a hosszú élettartam, ne használja a bináris .
Gyakran nehéz elolvasni egy másik program bináris adatait, ezért ha fontos az interoperabilitás, ne használja a bináris .
Mellékül: A CSV egy rettenetes fájlformátum . Ez egyszerű, de rosszul definiált és állapotfájl-elemzőt igényel. Ne használjon CSV-t. Ha szükséges, használja a TSV-t. Egyszerűbb, de jobban meghatározható, és elemzése csekély.
https://chriswarrick.com/blog/2017/04/07/csv-is-not-a-standard/
https://www.cloudbakers.com/blog/everything-you-didnt-want-to-have-to-know-about-csv
Ha aggódsz a méret miatt, tömörítsd a tömörítést.
(Ide a tömörített bináris ábrázolás és a tömörítés relatív mérethatékonyságát vizsgáltam szöveg. A VRML vizsgálatán kívül még nem találtam jó információt, de még abban sem biztos, hogy összehasonlítja-e a base64 kódolású bináris és a bináris összehasonlítást. https://www.cs.unc.edu/~isenburg/papers/is-bcraf-03.pdf .)