Használsz számok írása esetén ezres elválasztására "." vagy "," karaktert?

Címkék

Példa a fent definiált ezres elválasztásra:

100 millió 2 tizedesjegyig:

hu_HU, de_DE, es_ES: 

100.000.000,00

en_US, en_UK:

100,000,000.00

A fenti példák gondot okozhatnak, ha egyszerre használjuk különböző locale beállításokon.

Szoktad így jelölni a számokat vagy sem?

Szavazatok

Hozzászólások

Én utoljára egy Media Marktban láttam ilyent egy árcédulán, amit a dolgozók fekete filccel egészítettek ki a tagoló aposztrofokkal.

Minden bizonnyal az történt, hogy a kérdéses böszme nagy tévét az ezredik vásárló akarta megvenni 650.000 forintért, mert elképzelhetetlennek tartotta, hogy az ára 6,5 millió legyen.

Pedig de. :-)

Táblázatban (ahová a zsebpénzemet írom be) a milliárdos nagyságrendeket már nehéz enélkül átlátni, ezért használom. De úgy szoktam, hogy a formázásban van beállítva, hogy a pénzt tartalmazó cellák így legyenek formázva. Így mindig az a gép formázza, amivel megnyitják, de általában magyarokkal osztok meg ilyet.

Máshol nem nagyon szoktam, esetleg néha kézzel írt szövegbe kézzel beformázva, de ott nincs gépi feldolgozás, az olvasó AI-jára bízom, hogy rájöjjön melyik jel mit jelent.

Szerkesztve: 2020. 07. 29., sze - 14:23

Na, itt van egy érdekesség!

 

Kiírom a számot (s/f)printf()-fel, visszaolvasom atof()-fal és levágódnak a tizedesek. Úgy kell kézzel a stringben lecserélgetni a ',' és a '.' karaktereket! Tapasztalt már ilyet valaki?

> Sol omnibus lucet.

Az hagyjan, kepzeld el az alabbi szcenariot:

10000+ soros xlsx file 0,01 € es 90.000,00 € kozti ertekekkel: ezt egy nemet Excel exportalja CSV-be.

CSV-n dolgozik egy masik nemet scriptje

A nemet scriptjevel megdolgozott CSV-t megnyitjak (US vagy UK) angol locale-s Excellel es azzal konvertaljak vissza xlsx-be

Masik angol kiexportalja CSV-be:

Aztan felkapja egy junior PHPistike, aki explode-dal olvassa be a CSV-t, es implode-dal visszairja. :(

Tudod, van különbség aközött, hogy egy nyelven valaki gányol kifejezetten sok erőfeszítést beleölve, vagy eleve olyan megoldásokat tartalmaz a nyelv, ami gányolás. Pl. próbáltál már egy osztály statikus methodját példány szintű methodként meghívni? Értem én, fun, hogy akkor egyszer csak mágikusan értelmezve lesz a $this is, és megkapod a hívó osztályét, csak... no thx. Vagy amikor ami az egyik verzióban bugos, a következő verzióban syntax error, a harmadikban meg megint egy harmadik megoldás a jó. Stb.

123 456 789,01

mondjuk nekem tetszit a pyton underscore-ja is

4 és fél éve csak vim-et használok. elsősorban azért, mert még nem jöttem rá, hogy kell kilépni belőle.

Szerkesztve: 2020. 07. 29., sze - 14:45

Lehet, hogy nem értem a kérdést pontosan.

A használok számok írására az milyen környezetet jelent?

Pl. Calc-ban beírom azt, hogy 100000000,2, mire az megjelenik úgy, hogy 100 000 000,2

Ha kézzel írok, papírra, akkor ugyanígy írom le, szóközökkel elválasztva.

Programozás közben ugyanúgy, ahogy Calc-ban, elválasztás nélkül írnám be, és a locale-nak megfelelően majd a program ügyesen kiírja, ahogy a felhasználó látni szeretné. Ha úgy írom meg a programot.*

Esetleg egy kicsit pontosabban a use case-t definiálni lehetne?

* Most gyorsan megnézve nem találtam olyan shell parancsot, ami a számokat akárhogyan darabolná. Tudsz mutatni példát?

disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.

Nem. A space ezres elválasztásra bocsánatos bűn, de integer számot egybe illik írni.

Így van. Az 11. és 12. helyesírási szabályzat szerint is szóközzel kell tagolni hármasával a helyiértékeket a 4 számjegynél hosszabb számokban, HA valaki tagolja, tipográfiában ezen még annyit finomítanak, hogy el nem választandó szóköz (non breakable space) használatát javasolják. Alternatív lehetőségként mindkét szabályzat megengedi a pont használatát, de én ez nem használom, mert keveredést okoz az angolszász megoldással szemben.

Így én magyar nyelvű doksikban szóközökkel tagolok, ha tagolok egyáltalán. Nem a lokalizáció miatt, mert az nálam mindig en_US.UTF-8 és sose hu_HU.

Az viszont nem zavar, ha valaki másként tagolja, csak kiderüljön. Ez 7+ számjegynél nem probléma, mert két tagolás is lesz benne, 5-6 számjegynél viszont megtévesztő lehet, mert ha valaki 21.375-öt ír, arról sokan nem fogják tudni, hogy ez tört, vagy egész érték.

“I didn’t start using Linux so I could have friends.” (Luke Smith, 2019) 🐧

Lehet hogy egy kicsit túl sokat beszélgetek szoftverekkel és keveset írok emberi fogyasztásra szánt doksiba, levelekbe számokat, de mindig arra gondolok hogy ha leírom azt hogy 1000000 akkor azt majd egy szoftver előbb-utóbb megkapja, ne nehezítsük meg a dolgát hülye vesszőkkel és társaival :)

Elválasztásra néhány éve a pont is elfogadott, 291. pont:

Ha a számokat számjeggyel írjuk, az öt vagy ennél több számjegyű számok írásában a számjegyeket a hátulról számított szokásos hármas számcsoportok szerint tagoljuk, s az egyes csoportokat közzel (esetleg ponttal) választjuk el egymástól, például: 20 611 vagy 20.611, 357 864 vagy 357.864, 5 602 164 vagy 5.602.164.

Igen is, meg nem is. Én azt vallom, hogy ez elsősorban annak a következménye, hogy az anyanyelvünk is fejlődik, változik, idomul. Jellemzően az ilyen "megengedett" változásokból lesznek később, néha csak évtizedek múltán a konkrét szabályok. És mivel a mai világban az angol a legelterjedtebb közvetítő nyelv, s mivel ezt sok magyar is használja, így szép lassan beszivárog hozzánk is az angolszász kultúrának pár (akár nyelvi) alapvetése is pl. az e-mail cím helyesírásának (ami önmagában is evolválódik jelenleg az "email"-ből épp az "e-mail"-be hasonló MTA ajánlás alapján) és a számok tagolásának használatától kezdve egészen hétköznapi dolgokig (Starbucks, szoftverek, zenék stb.).

Ergo van ebben kultúrális nyomulás/elnyomás/beszivárgás (ki minek tartja) is bőven, nem csak a béna, műveletlen magyarokhoz való igazodás :) Ez utóbbinak a megjelenése - ha már helyesírásnál tartunk - nyomokban inkább a legutolsó MHSZ módosítás számokra vonatkozó részeiben lelhető fel. Ez utóbbiakról elég jó a wikis összefoglaló.

És mivel a mai világban az angol a legelterjedtebb közvetítő nyelv, s mivel ezt sok magyar is használja, így szép lassan beszivárog hozzánk is az angolszász kultúrának pár (akár nyelvi) alapvetése is

Épp tegnap olvastam, hogy egy darabig az amerikaiak a milliárdot billiónak hívták, de az angolok ezer milliónak (és a billió az millió millió volt, rendesen), és ugyanígy az ausztrálok is.

Aztán (ha jól emlékszem), 1974-ben az angol miniszterelnök kiadta a parancsot, hogy mostantól az ezer millió neve billió, merthogy az amerikaiak így mondják.

Aztán 1999-ben az ausztrálok is váltottak, mert hát a brittttek így mondják, és legyünk kompatibilisek!

disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.

Az amerikai short scale mellett szól, hogy long scaleben csak milliárdig van szó 10^3-as ugrásokra. Onnantól már 10^6 ugrásokkal következik a billió, trillió, kvadrillió stb. Így például egy hétszázhatvanötezer-négyszázharmincegy-billió sokkal körülményesebb mint short scaleben a hétszázhatvanötezer-kvintillió-négyszázharmincegy-kvadrillió - magyarban short scalere fordítva. 

Azaz amerikai short scaleben csak 0-999 -ig terjedő szám kerül az n-illionok elé, még long scaleben 0-999999.

Long scale mellett szól viszont, hogy mivel csak 10^6 hatványonként használ el egy latin n-illion előtagot, sokkal nagyobb számoknál fogy ki a rendelkezésre álló latin számokból. 

Tudományos szövegben egyre többen forszírozzák a metrikus kilo mega giga tera peta stb előtagok használatát a félreértések elkerülése miatt. 

ez elsősorban annak a következménye, hogy az anyanyelvünk is fejlődik, változik, idomul

Ennek semmi köze a nyelvhez; ez a nyelv lejegyzésére használt jelrendszer (aka. latin alapú "magyar ábécé"), illetve a hozzá kapcsolt számírási rendszer (aka. "arab számok") szabályaihoz van köze.

A két fogalom many-to-many kapcsolatban áll egymással; azaz egy nyelvet több fajta írásrendszerrel, és egy írásrendszerrel több fajta nyelvet is le lehet jegyezni. Egy nyelvnek nem feltétlen van lejegyzésre használt jelrendszere, és egy jelrendszernek sem kell feltétlen egy nyelvet kódolnia.

Szerkesztve: 2020. 07. 29., sze - 15:22

A számok tárolásánál igen nagy luzerség ilyeneket használni.

A megjelenítésénél pedig a standard 'locale aware' fügvvényeket illene használni.

papírra (vagy notepadszerű appokba) nem igen írkálok, de ha mégis akkor ot space teszek a nagyságrendek láthatóvá tetelére, és veszzőt haználok a tizedesek leválasztására.

 

szerintem

Pont ezzel szívtam nemrég excelben. Van egy külső program, ami "."-t használ a számok ábrázolásához. Az egyik adatot nekem át kellett számolnom. Mivel ezek az adatok is egy táblázatban vannak és CTRL+C-vel másolhatóak, ezért kitaláltam, hogy Excel-ben gyorsan összedobok hozzá egy konvertálót... Mint kiderült, a magyar Excel nem tud mit kezdeni a "."-al elválasztott számokkal, annak ellenére, hogy felismeri számként őket, ezért workaround-ként fel kellett vennem egy segédtáblázatot is, amiben a pontokat lecserélem vesszőkre (lokalizációval nem akartam külön vacakolni, mert nem ér annyit a dolog).

Egyrészt ez, másrészt meg egy csomó prognyelv, matekprogram, számológépprogram lokalizációtól függetlenül tizedespontot használ. Sok keveredés elkerülhető, ha az ember következetes ebben a tekintetben. Bár ez az Excelen nem segít, mert úgy ahogy van, egy hulladék szoftver, eleve elkezdve a magyarosított függvényneveitől.

“I didn’t start using Linux so I could have friends.” (Luke Smith, 2019) 🐧

Adatbevitelnél nyilván nem. Megjelenítésnél meg oldja meg az adott szoftver a megfelelő lokalizáció szerint.

Ha dokumentumot állítok elő, akkor 1/6 em széles nem törhető szóköz.
LaTeXben: 12\,345\,678,999\,999  vagy angol szövegben 12\,345\,678.999\,999

De figyelem! 4 jegyűeknél számoknál nincs tagolás, kivéve, ha táblázatban, egymás alá rendezve vannak a számok, és azonos oszlopban van legalább egy darab legalább 5 számjegyű szám is.

Három jegyűnél nagyobb számokat tollal vagy ceruzával eleve csak kockás azaz négyzetrácsos papírra írok.
Számítógépen meg bőven elég a szóköz tagolásnak. A táblázatkezelők amúgy is szépen megformázzák, ha úgy állítom be, tehát ott még tagolnom sem kell.

Tertilla; Tisztelem a botladozó embert és nem rokonszenvezem a tökéletessel! Hagyd már abba!; DropBox

Ha tehetem, az ezres csoportokat szóközzel választom el, úgy átláthatóbb. A vessző szóba sem jön, mert a magyarban az az egész- és a törtrészt választja el. (Ezért hívjuk ebben a szerepében tizedesvesszőnek, ugye.)

A tagolás nem az ember feladata, hanem a gépé.

:)

A szam (tartalom) es annak megjelenesi formaja ket kulonbozo dolog. A szam nem tarlamaz elvalaszto jelet (az esetleges tizedespontotn kivul); a megjelenesi forma barmi lehet.

Aki CSV-ben vagy barmi mas szoveges formatumban ezres tagolast alkalmaz azt ki kell csapni a szakmabol.

Szerkesztve: 2020. 07. 29., sze - 22:19

-

[x] Egyéb

Numerikus adatokat tartalmazó fájlban soha, de szövegben néha így írok le nagyobb számokat kifejezetten az átláthatóbb tagolás végett.

Magyarul szóközzel szokás elválasztani a hármas csoportokat nem ponttal:

100 000 000,000 000

Egyébként attól függ, hogy hova: ha gépnek megy, akkor a kérdés számomra értelmetlen, nem választom el. Ha szövegbe, akkor meg az adott nyelv helyesírási szabályai alapján.

Ez tisztán kulturális kérdés, mint az is, hogy a keresztnév vagy vezetéknél legyen-e elöl. Amelyik nyelvekben fordítva van, nap/hó/év, ott az a logika mögötte, hogy azt többször kell emlegetni hogy hányadika van, mint azt, hogy milyen hónap/év. De végül is ez az YYYY-MM-DD ISO világszabvány lett. Én a rendszereim en_US lokalizációval használok, emiatt a dátum MM/DD/YY (kivéve magyar dokumentumokban), de pl. fájlkezelőkben, fájllistákban az ISO YYYY-MM-DD-t preferálom, jobban formázható, átlátható. Bár az en_US dátumon még annyit szoktam csavarni az óránál, hogy ott 24 órásra állítom, nem am/pm-ezek. Felesleges, ma már az időmérő eszközök nagy része digitális, és nem kell a körben járó analóg óramutató miatt kettőbe törni a napot, hanem az lineárisan telik 0-24-ig. Bár én ebben mindig is rendhagyó voltam, mert ezt a tradicionális délután háromnegyed négy lesz 3 perc múlva vergődést sose szerettem, 15:42 és kész, nem kell matekozni, hogy négyzetgyök alatt szinusz pi ketted szer integrál nullától egyig kotangens iksz déiksz és az egész szorozva i-vel majd az e-re hatványozva, aztán matekozza ki az ember, hogy akkor most mennyi az istenverte idő. Tudom így elegánsabb, meg szabatosabb, de azért kérdezem, mert esetleg nincs időmérő nálam, nem azért, mert matekfeladványt szeretnék megoldani unalmamban.

“I didn’t start using Linux so I could have friends.” (Luke Smith, 2019) 🐧

A magyar formátum sem YYYY-MM-DD, hanem YYYY. MM. DD. Azaz az elválasztás ponttal és szóközzel történik.

https://helyesiras.mta.hu/helyesiras/default/akh12#F11_0_0_2

 

Illetve persze kevesen tudják, hogy az alapértelmezett ISO formátum az YYYYMMDD, szeparátor nélkül, a szeparátor a kiterjesztett formátum része.

Része, csak az ún "extended" formának. Ugyanis az ISO 8601 két formát definiál: basic és extended.
Basic formában nincs tagolás, nem is emberi olvasásra szánják ezt.

MAga a szabvány sajnos nem érhető el ingyenesen, de itt egy jó összefoglaló a basic és extended formátumokról:

https://support.sas.com/documentation/cdl/en/lrdict/64316/HTML/default/…

¯\_(ツ)_/¯

Számot tároljunk számként, aztán a reprezentáció történjen az adott localenak megfelelően. Ha ASCII-ban tároljuk, akkor meg legyen egy tizedespont és ne legyen elválasztás. El lehet választani az adatot a reprezentációtól...

(Tudom, tudom, szegény unix toolok, jajúristen. Kevés dolog egyike, ami ilyen szempontból jó a PowerShellben, hogy típusos)

Csakhogy a probléma itt nem a tárolás, hanem pont az, hogy a glibcben a hu_HU locale szerint pont az elválasztó.

https://lh.2xlibre.net/locale/hu_HU/

Itt van a kurvanagy bug.

 

Miközben úgy általában a világ jól tudja:

ICU locale: http://www.localeplanet.com/icu/hu-HU/index.html (az ICU adatok forrása az Unicode CLDR)

És milyen tool az, ami a glibc használatával a locale szerint tagolja a számokat?

Amikor ez a kérdés megjelent itt a hupon, megnéztem lssel és dffel meg toppal, és nem volt semmiféle tagolás.

disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.

Ezt nem is tudtam, hogy működik ilyesmi is. Ezek közül csak a Pythont és az Octave-ot használom, de mostantól én is így tagolok, nagy királyság. Kár, hogy arbitrary C-calc-ban működik, pedig bőven lenne erre igényem, mikor nagy számokat írok be, hajlamos vagyok véletlenül plusz/mínusz 1 nullával mást írni.

“I didn’t start using Linux so I could have friends.” (Luke Smith, 2019) 🐧

Off. Excelbe láttam már beírva számot így:

1000.-

Nem értették miért nem tud számolni vele. /Off

En is lattam ilyesmit, csak ott nem a felhasznalo volt alapvetoen a hulye, copy-paste-elte mashonnan. Amugy nem szeretem a hulye tagolast.

When you tear out a man's tongue, you are not proving him a liar, you're only telling the world that you fear what he might say. -George R.R. Martin

Csak ha valakinek azt írom, mennyi pénzt utaljon, nehogy eltévessze! ;-)

Szerkesztve: 2020. 07. 29., sze - 21:51

Magyarország a számírás tekintetében a német szabványt követi, ergo nem a franciát vagy az angolt.

4 számjegy fölött már félszóközt használok, tizedesnél vesszőt.

Pl.:

tex-kód:

\num{50000,00}

\num{50000},--

50\,000,--

ez azt jelenti, hogy "\," félszóköz, a ,-- pedig egy vessző és egy gondolatjel, ami nem kötőjel és k virtminusz, hanem gondolatjel, mint amilyen hosszúságú a párbeszédeknél van.

 

Ha a szövegkörnyezet már mondjuk angolra ugrik egy táblázattal vagy egy angol szöveggel, akkor minden változik. Texnél az siunitx csomag elég vaskos manuallal rendelkezik, ha valaki mondjuk egyszerre ír angol, francia és német doksit

 

-----

Programozás pedig más tészta, azt kézikönyv, manual szerint kell használni; egy programot nem érdekli a tipográfia, csak azt, hogy mit számoljon és hogyan.

10-féle lény van:
-- aki ismeri a bináris számrendszert,
-- és amelyik nem.

Pokolra küldeném azt is, akinek nem volt jó a tizedespont. Ha nagyon tördelni kell, akkor tördeljék szóközzel, de amúgy meg írják normál alakban, és nincs vita.

Normál alaknál ott van a tizedespont/vessző problematikája, meg hogy a 10 hatványát hogy vitelezed ki tipográfiailag.

Engem egyébként az bosszant legjobban, hogy a nagy számokra az angolszász területeken is két megoldás van, a short és long scale rendszere, pl. Amerikában a milliárd az billion, míg a régi brit és hagyományos európai rendszerben milliard. Ráadásul sokszor nem tisztázott, hogy mikor doksiban használják, akkor hova valósi az író, milyen értelemben használja. Ezen sokat segítene a normál alak.

“I didn’t start using Linux so I could have friends.” (Luke Smith, 2019) 🐧

Az országok kb. fele-fele használ tizedesvesszőt és tizedespontot:

https://en.wikipedia.org/wiki/Decimal_separator#Hindu-Arabic_numerals

Európa amúgy tizedesvesszőt használ, kivéve a UK, innen exportálták ezt ők a világ nagy részébe. Az USA és a brit gyarmatok és a nemzetközösség államai tizedespontot használnak (meg még Kína), míg a többi európai ország és gyarmatai meg tizedesvesszőt.

Ez pont olyan, mint a birodalmi vs. metrikus mértékegységek.

Hol volt először számítógép? Az összes program default-ból mit használ?

Amikor én felnőttem, akkor a számítógép még angolul beszélt, és ma is ha bárhonnan kell importálnom, az pontot használ, addig nekem csak szivatás a tizedesvessző.

Régi szép időkben ezt meg lehetett volna úgy oldani, hogy a 437-es kódlapon pontként, a 852-n meg vesszőként jelenjen meg, de ne legyen már más karakter!

" Hol volt először számítógép? "

Ennek mi köze a kultúrahelyes megjelenítéshez? Nem mi vagyunk a számítógépért, az van értünk. Az, hogy amikor felnőttél, a számítógépek még nem értünk voltan igazán, az teljesen irreleváns a kérdésben.

Nekem teljesen jó volt akkor is a csak angolul beszélő informatika. Az hogy a dátumformátumban van eltérés az ok (bár abban meg határozottan a mienk a logikus, és még az ISO szabványhoz is ez áll a legközelebb), de ez a tizedesvessző/pont dolog ez csak egy kicseszés.

Azt, hogy az akadémikusok meg mit írnak a helyesírás szabályaiba, az engem nagyon nem érdekel, amióta észszerűsítették. Ennyit a nyelv nyugodtan tud alkalmazkodni, másban is tud.

Gyakran találkozom ezzel a problémával, elsősorban olyankor, amikor humán fogyasztásra szánt doksiból kell valamilyen analízis miatt programmatikusan kiszedni az numerikus értékeket. Pédául élvezet PDF-ben található táblázatokból kihalászni bizonyos adatokat, mert ott lehetőleg minden esetben valamilyen más formátumot használnak. És akkor még nem is beszéltem azokról az esetekről, ahol a szerző szándékosan próbálja akadályozni a publikált adatok kinyerését. (Persze az analóg gap-nek semmi sem áll ellen...)

Félreérted. Csomó tudományos publikációhoz mellékelnek adatokat, pl nyers mért értékeket. Kutató beküldi pl Excelben,vagy csvben, az újság honlapjáról viszont csak PDFben tölthered le,mert mindent automatikusan konvertálnak.

A következő fokozat, hogy pl x város megpályázott egy EU forrást adott projektre, amiből adatok keletkeznek. (Pl Helsinki közszolgálati villanyfogyasztásának modernizálása.)  Az EU rutinszerűen előírja, hogy az általa finanszírozott projektekből keletkező adatokat kötelező nyilvánosan elérhetővé tenni. Ha valamelyik partner ezt nem igazán akarja, akkor  Ilyenkor csomószor csinálják, hogy ezeket az adatokat kinyomtatják, pdfbe szkennelik, és úgy rakják ki a honlapjukra. Ugye az adatok publikálva vannak, de használni nem lehet őket.

Mindkét verzióval rendszeresen találkozok, és meg kell tudni oldani, hogy ezekből szedjem ki a számokat.

... a pdf nem adat, hanem kép... akkor is, ha nem scannelt. Vagyis: nem adat kerül nyilvánosságra, hanem kép. A projektek adatot írnak elő, nem képet, tehát elvileg ez a feltétel nem teljesül.

-fs-
Az olyan tárgyakat, amik képesek az mc futtatására, munkaeszköznek nevezzük.

Gondolom előbb utóbb realizálja ezt az EU szerveknél is valaki, és hoznak egy vonatkozó szabályt. Több EUs projektben vettem részt az asztal mindkét oldalán (jelenleg is fut egy), a projekteket felügyelők tipikusan nem értenek ilyesmihez, ez alapján nem hamar várható ebben változás.

Szerkesztve: 2020. 07. 30., cs - 20:37

Short scale kontra long scale mellett a másik zavaró hibafaktor számoknál. 

A legfaszább amikor különböző nyelvi beállítások miatt egyik pc által kiköpött magyar nyelvnek megfelelő 1000,34 -et hibásan olvassa  be a másik angol beállítású pc. 

Akkor szarul van megválaszva a transzport formátum. Vagy szarul van kezelve és humanoidnak szánt output lesz egy másik szoftverrel megetetve.

(Igen, tudom, hogy mi a realitás, de ezen esetek jó része visszavezethető egy rosszul tartjuk esetre. Meg amikor kijönnek az unix toolok stringbuzerálásának gyengeségei)

Transzport formátum? Mármint egy txt meg egy csv? Nem mindent szeretünk binárisan tárolni.

És amíg az oszcilloszkóp és a bármi egyéb csak az angolt ismeri, addig továbbra is azt mondom, hogy szivatás volt az informatikába a vesszőt behozni. De még egyszer: ez sem lenne baj, ha erre lenne egy dedikált karakter, csak sajnos az ASCII kitalálásánál erre nem gondoltak.

CSV-ben is megoldható, hogy "C"-s localeben menjenek az adatok, aztán a megjelenítő eszköz meg a beállított locale-nak megfelelően jelennek meg. Csak van egy olyan sejtésem, hogy te úgy gondolod, hogy a CSV-t is humán fogyasztásra (is) szánod. TXT meg ilyen szempontból limitált, bár picit adott a kérdés, hogy mire használod a TXT-t: arra, hogy struktúrálatlanul adatokat, jegyzetet írj bele, amit egy ember ír vagy transzport formátumnak két szoftver között.

De még egyszer: ez sem lenne baj, ha erre lenne egy dedikált karakter, csak sajnos az ASCII kitalálásánál erre nem gondoltak.

Ezzel mondjuk egyet tudok érteni, csak ugye a 8 bites ASCII tábla kitalásakor sok mindenre nem gondoltak. Most az Unicode-ban lehetne is csinálni ilyet, más kérdés, hogy valószínűleg egy örök élet lenne, mire elterjedne, addig csak +1 dolog lenne, amire figyelni kellene. (Arról nem beszélve, hogy igazából picit még mindig reprezentációs kérdés, meg mit csinálsz

Ha más számait kell elolvasnom, akkor előre megegyezek vele, hogy hogyan fogom értelmezni.

Ha én írok számokat, akkor nem tagolom, mert az olvasásra jó, én pedig a számokkal számolni szoktam.

int getRandomNumber() { return 4; }  // ← aláírás
//szabályos kockadobással választva. garantáltan véletlenszerű.  xkcd

Ha hivatalos formában kell valamit leírnom, akkor azt használom, ami az elfogadott. Minden egyéb esetben szóközzel választom el, és ponttal a tizedesjegyeket. 

openSUSE Leap 15

Nem szeretem az ilyet, sem gépen, sem papíron. Túl nagy vagy túl kis számoknál meg jobban szeretem az 1.234E+56 formátumot.

-fs-
Az olyan tárgyakat, amik képesek az mc futtatására, munkaeszköznek nevezzük.