- A hozzászóláshoz be kell jelentkezni
- 1896 megtekintés
Hozzászólások
123'456'789.01
- A hozzászóláshoz be kell jelentkezni
Papirra tollal en is igy irom. Futottam mar olyanba, aki nem ertette.
- A hozzászóláshoz be kell jelentkezni
É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. :-)
- A hozzászóláshoz be kell jelentkezni
Én is kizárólag így. Eddig mindenki értette.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
Olasz liraban szamolsz, hogy a zsebpenzed milliardos nagysagrendu ? :)
- A hozzászóláshoz be kell jelentkezni
Most kicsit le van égve, de amúgy aranyrudakban tartja, és annak darabszáma ekkora :)
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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. :(
- A hozzászóláshoz be kell jelentkezni
(Hasonlo amikor Majus 2-bol Februar 5 lesz en_US export en_UK import miatt)
- A hozzászóláshoz be kell jelentkezni
Jó, jó, de az én példám ugyanazon gép ugyanazon programja csinálja.
> Sol omnibus lucet.
- A hozzászóláshoz be kell jelentkezni
Na igen, szerintem szepen ossze lehetne szedni pusztan a glibc-s eseteket is. Azokbol is lenne par erdekes.
- A hozzászóláshoz be kell jelentkezni
Aztan felkapja egy junior PHPistike, aki explode-dal olvassa be a CSV-t, es implode-dal visszairja. :(
Jaj, ne is említsd. Amikor jön a bugreport, hogy szar a CSV exportunk, mikor nagy vörös keretben ott volt a dokumentációjában, hogy ne csináld, ott az fgetcsv()...
- A hozzászóláshoz be kell jelentkezni
Látod, ezért mondja mindenki, hogy szar a PHP.
Igaz a fejlesztő nem ismeri a lehetőségeket, nem tudja a dokumentációt használni és értelmezni, gányol, és ezért szar a végeredmény, de sebaj, mert szar a PHP!
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
Be kell látni, hogy a PHP indult valahogy, és azóta rengeteget fejlődött, változott. Eközben kompatibilitási okokból valamennyire meg is tartotta a múltjának egy részét, ami miatt lehet könnyen szarul használni és ekézni, de eközben az is garantált valamelyest, hogy egy jól megírt kód több főverzión át képes akár működni.
Viszont eközben látok más nyelveken is gány kódot, és hidd el, nem tűnik nagy erőfeszítésnek. A java nagy átka például, hogy az SDK-ban mindenre is akar megoldást adni, és többnyire ugyanarra több eszköz is van. Győzd megtanulni mind, hogy tudd mikor mit kell használni pl dátum kezelésre.
Én szerettem PHP-val dolgozni, még úgy is, hogy az általad említett faszságokról tudtam, és nem is igazán szerettem miatta a nyelvet.
Na nem vagyok elfogult, most se használom már egy ideje. Helyette javascriptezek. Ne is menjünk bele, mert ez nagy shitstormot indíthat :D
- A hozzászóláshoz be kell jelentkezni
Amatorok vagytok. Tegyetek bele egy FKERES parancsot, es azzal egyutt toljatok at az XLS allomanyt s nemeteknek, doljon ossze naluk.
Eljen a kompatibilitas es a magyaritott programnyelv. Aki kitalalta, na annak esernyot a seggibe! Nyitva!
- A hozzászóláshoz be kell jelentkezni
Tökéletesen fog működni nála is, lévén az XLSX fájlban az angol nevén van tárolva.
Itt egy ÁTLAG függvény:
<row r="6" spans="1:1" x14ac:dyDescent="0.3"><c r="A6"><f>AVERAGE(A1:A5)</f><v>3</v></c></row>
- A hozzászóláshoz be kell jelentkezni
Gondolom te sem hallottál még az adat és a megjelenítés elválasztásáról ;)
Segítek, egy németnek SVERWEIS() fog megjelenni :)
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
In [1]: 564_234.890_452
Out[1]: 564234.890452
In [2]: 0b1100_0101
Out[2]: 197
- A hozzászóláshoz be kell jelentkezni
+1, ugyanezt kezdtem fogalmazni
- A hozzászóláshoz be kell jelentkezni
perlben is lehet bárhová _-t rakni a számokba (persze az elejébe nem)
- A hozzászóláshoz be kell jelentkezni
PHP 7.4-ben is működik az underscore. Az már más kérdés, hogy a legritkább esetben tudok elképzelni olyan helyzetet, amikor számot beégetve kell használni a kódban. :)
It is our choices that define us.
Thinkpad X1 Carbon | Arch linux
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
Nem. A space ezres elválasztásra bocsánatos bűn, de integer számot egybe illik írni.
- A hozzászóláshoz be kell jelentkezni
Pedig a magyar helyesírás szerint szóközzel kell tagolni.
Gyakorlatilag nagyon vegyesesen használják.
- A hozzászóláshoz be kell jelentkezni
Í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.
“The world runs on Excel spreadsheets.” (Dylan Beattie)
- A hozzászóláshoz be kell jelentkezni
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 :)
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
Ez annak lehet a következménye, hogy annyira sokan használják helytelenül?
- A hozzászóláshoz be kell jelentkezni
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ó.
- A hozzászóláshoz be kell jelentkezni
É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.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
törhetetlen félszóközzel...
10-féle lény van:
-- aki ismeri a bináris számrendszert,
-- és amelyik nem.
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
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).
- A hozzászóláshoz be kell jelentkezni
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.
“The world runs on Excel spreadsheets.” (Dylan Beattie)
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
LaTeX: siunitx, \num miért nem jó? Ha változtatsz a számodon (mert elírtad), akkor a szóközöket is írhatod át.
- A hozzászóláshoz be kell jelentkezni
Már aggódtam, hogy pont erről nem ír senki :)
10-féle lény van:
-- aki ismeri a bináris számrendszert,
-- és amelyik nem.
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
Mondjuk számokat kézzel írni, rendezetten a franciakockás füzet való, annak a rubrikái alkalmasabbak a számok írására, mint a négyzetrácsos füzet.
- A hozzászóláshoz be kell jelentkezni
Sajnos nem nagyon látni a boltokban. Nekem csak "örökségből" van (szülők) franciakockás papírom, pedig szerintem is az a legjobb.
- A hozzászóláshoz be kell jelentkezni
http://web.engr.oregonstate.edu/~traylor/ece474/beamer_lectures/verilog…
https://doc.rust-lang.org/stable/rust-by-example/primitives/literals.ht…
Ha hosszu szam literalt akarsz olvashatoan akkor: _
Amit nem lehet megirni assemblyben, azt nem lehet megirni.
- A hozzászóláshoz be kell jelentkezni
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 hozzászóláshoz be kell jelentkezni
Szóközt használok ezres elválasztásra, ha szükséges. Úgy is helyes, nem csak a pont. Sőt, a szóköz a preferált a megfogalmazás szerint:
- A hozzászóláshoz be kell jelentkezni
Némileg kapcsolódik. https://hu.wikipedia.org/wiki/Rövid_és_hosszú_skála
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
Ahogy más már megjegyezte, az eredeti leírásban csak "számok írásáról" volt szó, formátumról (pl. CSV) nem.
Másrészt pl. egy .md vagy .txt fájl is szöveges. Akkor szerinted abban sem "szabad" számokat tagolva írni?
- A hozzászóláshoz be kell jelentkezni
-
- A hozzászóláshoz be kell jelentkezni
[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.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
Én is space-szel választom el. Amúgy elég vicces, hogy sem a tizedes vessző/pont sem a szám elválasztás, sem a dátum/idő megjelenítésre nem sikerült az emberiségnek összehoznia egy egységes formátumot.
- A hozzászóláshoz be kell jelentkezni
"sem a dátum/idő megjelenítésre"
Szerintem a vilag osszes orszagabol ki kene tiltani az osszes YYYY-MM-DD -tol eltero formatumot. Persze magyarkent ugyanolyan konnyen beszelek, mint a Tavol-Keleten tehetnem.
- A hozzászóláshoz be kell jelentkezni
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.
“The world runs on Excel spreadsheets.” (Dylan Beattie)
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
A 11. szabályzat megengedte az YYYY-MM-DD-t, de a 12. valóban nem. Azt viszont nem tudtam, hogy az ISO formátumnak nem része a tagolás.
“The world runs on Excel spreadsheets.” (Dylan Beattie)
- A hozzászóláshoz be kell jelentkezni
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/…
- A hozzászóláshoz be kell jelentkezni
"Magyarul szóközzel szokás elválasztani a hármas csoportokat nem ponttal"
A glibc nem igy tudja, neki ugy tanitottak, hogy "."-ot hasznalunk ezres elvalasztasra :(
- A hozzászóláshoz be kell jelentkezni
¯\_(ツ)_/¯
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)
- A hozzászóláshoz be kell jelentkezni
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)
- A hozzászóláshoz be kell jelentkezni
É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.
- A hozzászóláshoz be kell jelentkezni
Mert az ls meg a df, meg a free leszarja a lokalizációt. De nem minden szoftver.
- A hozzászóláshoz be kell jelentkezni
Tudsz példát, ami használja?
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.
- A hozzászóláshoz be kell jelentkezni
De nem minden szoftver.
És iyenkor van az, hogy a szoftver kimenetét parse-olgató script szépen elszáll magyar oprendszer alatt, amit angol verzió alatt készítettek, és a fene se gondolt rá, hogy ott más a formázás.
- A hozzászóláshoz be kell jelentkezni
A Windows viszont helyesen tudja.
- A hozzászóláshoz be kell jelentkezni
- A hozzászóláshoz be kell jelentkezni
Perl, PHP7.4, Python3.6, Rust, Octave, Julia, ...
- A hozzászóláshoz be kell jelentkezni
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.
“The world runs on Excel spreadsheets.” (Dylan Beattie)
- A hozzászóláshoz be kell jelentkezni
Off. Excelbe láttam már beírva számot így:
1000.-
Nem értették miért nem tud számolni vele. /Off
- A hozzászóláshoz be kell jelentkezni
Ráadásul angol tipográfiát követi a ponttal és akötőjellel, ez dupla hiba azon kívül, hogy így írta be oda. Tehát összegezve ez triplabaromság
10-féle lény van:
-- aki ismeri a bináris számrendszert,
-- és amelyik nem.
- A hozzászóláshoz be kell jelentkezni
En is lattam ilyesmit, csak ott nem a felhasznalo volt alapvetoen a hulye, copy-paste-elte mashonnan. Amugy nem szeretem a hulye tagolast.
A strange game. The only winning move is not to play. How about a nice game of chess?
- A hozzászóláshoz be kell jelentkezni
ügyes
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.
- A hozzászóláshoz be kell jelentkezni
A .net megérti, meglepő módon külön paraméterek nélkül is. No persze nem úgy, ahogy gondolták… ☺
csharp> Decimal.Parse("1000.-")
-1000
int getRandomNumber() { return 4; } // ← aláírás
//szabályos kockadobással választva. garantáltan véletlenszerű. xkcd- A hozzászóláshoz be kell jelentkezni
Csak ha valakinek azt írom, mennyi pénzt utaljon, nehogy eltévessze! ;-)
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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.
“The world runs on Excel spreadsheets.” (Dylan Beattie)
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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!
- A hozzászóláshoz be kell jelentkezni
" 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.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
Én meg a pokolra küldeném azt, aki nem tud különbséget tenni a tárolás és a megjelenítés között.
Na? :)
- A hozzászóláshoz be kell jelentkezni
Vannak azert hibrid megoldasok, ahol nem feltetlen vagy in control, hogy mi hogyan lesz tarolva (xlsx pl.)
- A hozzászóláshoz be kell jelentkezni
Mire gondolsz? AFAIK xlsx-nél pont elválik az, hogy mi van tárolva és mi hogyan jelenik meg (ld. a fentebb is említett FKERES, ami VLOOKUP-nak van tárolva.)
- A hozzászóláshoz be kell jelentkezni
Fuggvenyeknel igen, de szamoknal lehet addig kattintgatni, hogy szovegkent legyen tarolva. Aztan a kovetkezo szint az "Export as CSV".
- A hozzászóláshoz be kell jelentkezni
Jó, hát ha valaki direkt lábon lövi magát, az vessen magára.
- A hozzászóláshoz be kell jelentkezni
Nekem ez is jó lenne... csak nem ez a valóság.
Céges windows-on ezért van lecserélve a lokalizációs beállításokban pontra, nagyon sok fejfájástól megkímél :)
(Igen, ez az a nagyon ritka pillanat, amikor a windows-ról valami jót is tudok mondani.)
- A hozzászóláshoz be kell jelentkezni
Hja, hát meg kellene tanulni szoftvert írni.
- A hozzászóláshoz be kell jelentkezni
Nem mindig hasznalhatod azt a szoftvert, amit te irtal.
- A hozzászóláshoz be kell jelentkezni
A másik szoftver írója is megtanulhat szoftvert fejleszteni.
- A hozzászóláshoz be kell jelentkezni
Megtanulhat, de amig nem tanul meg, valasztekosan karomkodok a gep elott, ami amugy azoknak, akik csak kozepesen probalnak epp koncentralni, talan meg szorakoztato is. ;)
- A hozzászóláshoz be kell jelentkezni
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...)
Csaba
- A hozzászóláshoz be kell jelentkezni
PDF-nél van, hogy az összetartozó tartalom valahogy külön blokkokba kerül és egy sima szöveg kimásolás más sorrendben adja ki a darabobak, mint ahogy a PDF-ben volt. Fincsi.
- A hozzászóláshoz be kell jelentkezni
Ez nem lehet, hogy szándékos volt?
- A hozzászóláshoz be kell jelentkezni
Nem. Lekvaros. :)
- A hozzászóláshoz be kell jelentkezni
:D
- A hozzászóláshoz be kell jelentkezni
... a PDF úgy is csak arra jó, hogy kinyomtassák. PDF-ben feldolgozandó adatot küldeni elég beteg dolog... és sajnos sok ilyen van :(
-fs-
Az olyan tárgyakat, amik képesek az mc futtatására, munkaeszköznek nevezzük.
- A hozzászóláshoz be kell jelentkezni
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.
Csaba
- A hozzászóláshoz be kell jelentkezni
... 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.
- A hozzászóláshoz be kell jelentkezni
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.
Csaba
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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)
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
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- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
Akkor mar jobb szeretem szepen kiirni:
1.6*10^11
- A hozzászóláshoz be kell jelentkezni