Možnosti scanf (jazyk C)

13.12.2016 00:58 | Přečteno: 4255× | Ostatní | | poslední úprava: 13.12.2016 00:57

Zde je příklad jednoduché kalkulačky, čísla můžete zadávat ve formátu 12+5.5 nebo s mezerami 45.1 * 8, nebo jen +50, *30.5, program se ukončuje nulou. Snažil jsem se pomocí sscanf co nejlépe ošetřit vstup.

#include <stdio.h>
#include <string.h>
#include <math.h>

#define	MAX	50
#define	FRM2	"%.2lf\n"
#define	FRM0	"%.0lf\n"

double calc(double a, double b, char *op);

int main()
{
        char 	line[MAX], oper[2], end[2];		
	double	a, b, c = 0, whole;
	
	while (fgets(line, MAX, stdin)) {
	
		if (sscanf(line," %lf %1[+*-/] %lf %1s", &a, oper, &b, end) == 3 && oper[0] != '.')	{		
			c = calc(a, b, oper);
			modf(c, &whole) ? printf(FRM2, c) : printf(FRM0, c);		
		}
		
		else if (sscanf(line," %1[+*-/] %lf %1s", oper, &b, end) == 2)	{			
			c = calc(c, b, oper);		
			modf(c, &whole) ? printf(FRM2, c) : printf(FRM0, c);		
		}
		
		else if (sscanf(line,"%lf", &a) == 1 && a == 0 && strlen(line) == 2) 
			break;
		
		else
			printf("!\n");			
	}

	return 0;
}

double calc(double a, double b, char *op)
{
	double c;
	
	c = *op == '+' ? a + b : 
		*op == '-' ? a - b :
		*op == '*' ? a * b : a / b;

	return c;
}

V C se velikost řetězce deklaruje včetně ukončovacího znaku '\0', proto řetězec oper, který uchovává pouze znaménko, má velikost dva bajty.

Ukazatel *op ve funkci calc ukazuje na první znak v poli oper. Mimochodem u pole na rozdíl od ukazatelů nefunguje pole++ nebo *pole++, protože jazyk C neumožňuje u pole přiřazení (pole = pole + 1).

Protože sscanf načítá správně i číslo ve formátu 123abc, přidal jsem čtvrtý argument s řetězcem end, a vstup je platný, pokud sscanf vrátí tři (sscanf vrací počet správně načtených argumentů).

Funkce double modf(double x, double *ip) z hlavičkové souboru math.h vrací zlomkovou část proměnné x a celočíselnou část uloží do ukazatele *ip.

Přikaz break ukončuje větvení switch a nejniternější smyčku u cyklů while, for a do.

Funkce fgets nechává na konci řetězce znak nového řádku '\n', proto aby správně fungovalo ukončení programu nulou, musí se strlen rovnat dvěma. Pokud by byla podmínka && strlen(line) == 3, mohli bychom program ukončit zadáním třeba 0A, což nechceme.

Hranaté závorky ve scanf určují, z jakých znaků se řetězec musí skládat, již se nepřidává příznak s pro řetězce

char cislo[11];
scanf(" %10[0-9]", cislo);

mezera za % přeskakuje všechny bílé znaky na začátku, v hranaté závorce je možné použít i [A-Za-z].

Hranaté závorky se stříškou načítají řetězec tak dlouho, dokud nenarazí na znak v závorce

char radek[21];
scanf(" %20[^\n]", radek);

načte celý řádek i s mezerami.        

Komentáře

[pc2005]

Vida scanf umí i výčet znaků? To jsem ještě nikdy nepoužil .

[Xerces]

Dík za tenhle blogísek. Takhle krásně to rozpitvat pro nás co v C nejsme kovaný, ale osudově nás přitahuje

[sad]

Tak já vlastně programovat moc neumím, ale C mě baví, alespoň dokud si hraji s takovými jednoduchými prográmky.

[pavelx]

Díky, jen jsem si potvrdil, že C++ byla správná volba a C je bazmek.

[pavlix]

Stále se držím přesně opačného názoru.

[pavlix]

To bylo na pavelx, sorry.

[podlesh]

Soudě dle použitého nicku to asi byl cíl celého komentáře, ne?

[pavlix]

Asi bych se nerad vzdával pythoního luxusu načíst data ze vstupu pomocí regulárního výrazu.

[kralyk z abclinuxu]

Regexy nejsou ani pythonní ani luxus. Na takovéhle věci bych doporučil spíše Ragel.

[Michal Kubeček]

(f)lex :-)

[pavlix]

Au.

[pc2005]

Hezký, ale v céčku je flex fakt dost neflexibilní. Zvlášť když to porovnám s tím, co všechno umí načítat jednořádkovej regexp v perlu.

[Michal Kubeček]

Pokud se netrápíte přemýšlením, co se při tom "načítání" děje, proč ne.

Jinak… kdybyste napsal, že vám to připadá nepraktické, chápal bych to. Ale napsat "když to porovnám s tím, co všechno umí načítat"? Co konkrétně umí zpracovat "jednořádkovej regexp v perlu" a nelze to implementovat ve flexu?

[chochi]

Perlovy regex treba zvladne vsechny bezkontextove jazyky (pomoci reukrzivnich sub-patterns) - to podle me flex nezvladne.

[Michal Kubeček]

To je na můj vkus moc mlhavé. Nemluvě o tom, že (f)lex umí pracovat i s kontextem.

[kralyk z abclinuxu]

Nemluvě o tom, že (f)lex umí pracovat i s kontextem.

Ano, ale krkolomně. Já bych tady souhlasil s pánama, flex není moc neflexibilní. Jeho integrace do projektu a build systému není úplně snadná, na to, kolik toho (neumí).

Přesně z toho důvodu jsem nahradil posledně flex výše zmíněným Ragelem, který toho umí mnohem víc, přitom se ale integruje do projektu/zdrojáku výrazně snáz.

[Michal Kubeček]

Já jsem přece vůbec nerozporoval, že někomu může flex připadat nepraktický - dokonce jsem výslovně zmínil, že to připouštím. Výslovně jsem se ptal na příklad toho, co (f)lex nezvládne a "jednořádkovej regexp v perlu" ano. Zatím jsem se nedočkal.

[Mirek]

Ragel is released under the GNU General Public License, Version 2.

nesvobodne software odmitam pouzivat

[xkucf03]

Regulární výraz jsem hlavně schopný napsat z hlavy a vykonat zavoláním jednoho příkazu/funkce.

Ten klasický přístup s lexikálním analyzátorem a generátorem parseru bude na větší úlohy lepší/mocnější, ale často to je kanón na vrabce. Ta režie na tom mě trochu odrazuje. Zajímavou alternativou je ten Ragel a nebo ještě lépe PEG, konkrétně implementace parboiled.

[pc2005]

Co konkrétně umí zpracovat "jednořádkovej regexp v perlu" a nelze to implementovat ve flexu?

Ve flexu nelze implementovat některé věci stejně rychle jako jednořádkovej regexp v perlu. Flex není součástí syntaxe C. Při vývoji parsování stringu v perlu nemusím kontrolovat segfaulty.

Samozřejmě je to vykoupeno větším overheadem interpretovaného jazyka, ale v mých úlohách nebyly regexpy nikdy největší brzda.

[Michal Kubeček]

Co konkrétně umí zpracovat "jednořádkovej regexp v perlu" a nelze to implementovat ve flexu?

Ve flexu nelze implementovat některé věci stejně rychle jako jednořádkovej regexp v perlu.

Ale no tak… To je dost průhledný úhybný manévr. Přečtěte si, co píšu v komentářích 21 a 25.

[pc2005]

V tom případě došlo k mýlce, já mluvil o neflexibilitě flexu ne o absolutní síle jazyka. Ekvivalent jde samozřejmě implementovat i v čistém céčku přes if-then-goto nebo v assembleru, ale až na vyjímky to je nepraktické.

Ale fajn, měl jsem napsat něco jako: "v porovnání s tím, co všechno se vejde do jednoho řádku v perlu"

Když jsme už u toho, tak ty zbylé věci snad úhybný manévr nejsou ne? Syntaxe flexu má v sobě ty %% bloky, což je jaksi víc než jeden řádek. Musí se speciálně kompilovat, což jsou další příkazy navíc někde.

BTW měl jsem dojem, že flex je hlavně parser a na skládání symbolů do smysluplných kombinací se používá gramatika v yaccu/bisonu. Nebo jde (nějak lehko = bez reimplementace bisonu) ve flexu z jednoho regexpu vytáhnout najednou několik substringů?

P.S. Jde ve flexu napsat tohle na jeden řádek? Ale to už je spíš gramatika no :-/.

} elsif ($line=~m/^[ \t]*\(tile_summary ([^ ]+) ([^ ]+) (\d+) (\d+) (\d+)\)(?: (.*))*$/) {

Návratové hodnoty v $1-$5, nerelevantní zbytek v $6 a v $7 je relevantní substring v nerelevantní zbytku (velmi zajímavá funkce ).

[Michal Kubeček]

BTW měl jsem dojem, že flex je hlavně parser a na skládání symbolů do smysluplných kombinací se používá gramatika v yaccu/bisonu.

U složitějších jazyků ano, ale v jednodušších případech bývá často jednodušší použít samotný flex.

P.S. Jde ve flexu napsat tohle na jeden řádek? Ale to už je spíš gramatika no :-/.

} elsif ($line=~m/^[ \t]*\(tile_summary ([^ ]+) ([^ ]+) (\d+) (\d+) (\d+)\)(?: (.*))*$/) {

Na jeden určitě ne. :-) Jinak to samozřejmě půjde, ale musím přiznat, že perl mi k srdci nepřirostl (no, to byl hodně silný eufemismus), takže syntaxi PCRE bych musel pracně dohledávat.

[ET]

mezera za % přeskakuje všechny bílé znaky na začátku?

[sad]

Kvůli větší srozumitelnosti jsem asi mohl napsat mezera předcházející %.

[ET]

nejsem Cckar, tak jsem koukal, jestli mi neco neuteklo - ja bych (s)proste nahradil "za" za "pred" ;)

jinak diky za blog, konecne neco inspirativniho "k veci", asi to Ccko opet oprasim

[unicode]

Zkusil jsem 3+4*2 a nic :)

[pomocnik VB]

u mne se objevila stranka google nahore s kalulackou a pod tim prvni odkaz 'Fraction Calculator - Calculator.net'

[Radovan]

Pěkné, ale trochu složité. Jednoduchou kalkulačku bych si představoval takhle

#include <stdio.h>
#include <math.h>

int main(void)
    {
    float x,y;
    char z;

    for (printf("Kalkulačka\n");3==scanf("%f%1[+-*/]%f",&x,&z,&y);printf("%.3f %c %.3f = %.3f\n",x,z,y,'+'==z?x+y:'-'==z?x-y:'*'==z?x*y:y&&'/'==z?x/y:NAN)) while ('\n'!=getchar());

    return 0;
    }

[sad]

Taky dobrý

[RM]

Pěkné, tohle v Perlu nejde :(.

[Josef Kufner]

Ale jde.

[RM]

Tak ukažte?! while z pravé strany a for bez svorek, ale klidně i s, ze strany druhé.

[Josef Kufner]

Samozřejmě ta konstrukce bude vypadat maličko jinak. Jinak by vypadala i v C, kdyby to mělo být čitelné a ne takto naprasené. Ale přečíst řádek, regexpem rozparsovat a vypsat výsledek poskládaný z načtených hodnot není nijak těžké ani o nic delší (a do jednoho řádku to půjde nahňácat taky).

[Radovan]

Účel světí prostředky, šlo právě o ten jeden řádek. Ale kdybych chtěl být opravdu velké prase, tak bych do toho for() napral i ty deklarace proměnných, aby to bylo totálně nečitelné. Jenže jsem zatím C99 nějak nepřišel na chuť

[RM]

Proč nečitelné?. Čte se to jako kniha zleva do prava (tedy až na ten while), tak co je na tom nečitelného; deklarace by tomu vůbec neuškodily. Horší je, když se člověk musí neustále teleportovat na jiná místá v kódu a nebo skákat po špatně uspořádaných či příliš krátkých řádcích. ;)

[Josef Kufner]

Jenže kód se nečte jako kniha. Po kódu se skáče očima nahoru a dolu podle úrovní odsazení a kolikrát ani není třeba jednotlivé řádky číst, stačí tušit, co tam zhruba je. A čím delší kód je, tím mlhavější je i to tušení (mnohdy stačí jít po celých odstavcích). Pak takováto jednořádková konstrukce zabere na rozluštění déle jak celá obrazovka slušně napsaného kódu.

[wamba]

v Perlu while psát z pravé strany lze, ale taky můžete použít přepínače -p, -n;

V Perlu by šla jednoduchá kalkulačka rychle napsat, třeba takhle

perl -MRegexp::Common -pE 's{^ ( $RE{num}{real} \s* [\+\-\*\/] \s* $RE{num}{real} ) $}{$1 . "=" . eval $1}xmse'

[RM]

Pěkné! Tu knihovnu jsem neznal. Stačilo by jen }xe , když výraz bude jen na jednom řádku, stejně -n čte ze STDIN řádek po řádku.

[lertimir]

Už jsem líný se do programků zahloubat, ale pamatuji si, jak jsem asi před 15 lety demonstroval několik možností, jak na nedostatečně ošetřovaném scanf udělat buffer overflow a exekuci uživatelem vloženého kódu na zásobníku. Považuji je za sice hodně hezkou, ale extrémně nebezpečnou funkci.

[kralyk z abclinuxu]

sscanf_s()

[Agent]

Můžu mít dotaz, dá se nějak vypsat ASCII kód znaku, nejlíp v dvojkový soustavě? Ale může být i desítkový nebo 16kový, kdyžtak si to pak převedu. Jde mi o to, že jsem kdysi luštil hádanku a bylo třeba xorovat text s klíčem. Nemusí to být nutně v C, klidně i Java.

[Fluttershy, yay!]

char je v C číselný typ...

[Agent]

char je v C číselný typ... Takže mi bude fungovat jak int znak; tak char znak; ? A do něj pak zadám patřičný znak. Takže něco jako:
char znak; nebo int znak;
printf("Zadej znak");
scanf("%c",&znak);
printf("\nZadal si znak %c, jehoz ASCII kod %d");

[Josef Kufner]

Typy int a char se liší délkou. Char je na 1 byte, int bývá na dva nebo čtyři byty (záleží na procesoru).

Pokud uděláš:

int c = 0x1234;
scanf("%c",&c);

Tak paměť bude vypadat 0x??34, kde ?? je zadaný znak.

Pokud uděláš naopak:

char c = 0x12; char d = 0x34;
scanf("%d",&c);

Tak se načtené číslo zapíše částečně do c a částečně do sousedního bytu, což v závislosti na implementaci může být d a nebo taky cokoliv jiného (a nebo taky nic, neboť tam může být mezera kvůli zarovnání na šířku datové sběrnice).

[Jendа]

> cat scanf.c 
#include <stdlib.h>
#include <stdio.h>

int main(int argc, char **argv) {

  int c = 0x1234;
  scanf("%c",&c);

  printf("got: %x\n", c);
}

> gcc -o scanf scanf.c 
> ./scanf 
a
got: 61001234

;)

[Jendа]

(mimochodem… co za procesor je ten tvůj 16bitový big endian?)

[Michal Kubeček]

Typy int a char se liší délkou. Char je na 1 byte, int bývá na dva nebo čtyři byty (záleží na procesoru).

Šestnáctibitový int už jsem neviděl zatraceně dlouho…

Pokud uděláš:

int c = 0x1234;
scanf("%c",&c);

Tak paměť bude vypadat 0x??34, kde ?? je zadaný znak.

Zdaleka nejpravděpodobnější je, že v c bude 0x12??. A pokud ne, tak bych vsadil spíš na 0x??001234.

[Jendа]

Šestnáctibitový int už jsem neviděl zatraceně dlouho…

Podle mě nejrozšířenější s 16b intem bude avr-gcc.

[sad]

#include  <stdio.h> 

int main()
{
	int c = 0;
	
	while (c < 128)	{
		printf("%d\t%x\t%o\t%c\n", c, c, c, c);
		c++;
	}

	return 0;
}

Funkci na převod do binární soustavy si musíš napsat sám.

[Radovan]

void printb(unsigned int n)
     {
     if (n) printb(n>>1), putchar((n&1)?'1':'0');
     }

[sad]

Jdu se učit rekurzi a bitové operátory

[kralyk z abclinuxu]

Jestli to chceš ještě zhustit, můžeš (n&1)?'1':'0' nahradit '0'+(n&1) a místo unsigned int stačí unsigned ...

Ale číst je to hrůza. Hlavně kvůli těm odsazeným závorkám

[Jendа]

nahradit '0'+(n&1)

Norma určitě nespecifikuje, že za nulou musí následovat jednička. Určitě bude nějakou továrnu řídit mainframe, který má znaky uspořádané 1234567890

[xkucf03]

Stačí použít nějaké ASCII-nekompatibilní kódování…

[Jendа]

Tak třeba v EBCDIC je to taky 0123456789.

[pavlix]

Stačí použít nějaké ASCII-nekompatibilní kódování…

1) To je docela velký objev, že to nebude ASCII, když má ASCII sekvenci 0123456789. To je skoro na cenu kapitána obvijouse.

2) Zjevně nestačí.

[Radovan]

Právě ty odsazené závorky to zčitelňují, na první pohled vidím odkud kam sahá blok a jestli jsem nějakou nezapomněl:

void printb(unsigned int n)
     {
     if (n)
        {
        printb(n>>1);
        if (n&1)
           {
           putchar('1');
           }
        else
           {
           putchar('0');
           }
        }
     }

Vytiskni si to a udělej v tom prázdném sloupci čáry podle pravítka

Našel jsem to kdysi v jedné staré učebnici Algolu (zkus si tam místo {} napsat begin a end), podobně to měl například Whitesmiths. A když ty závorky vyházím tak je z toho Python

[xkucf03]

Tohle odsazování mi vždycky přišlo hodně podivné. Normálně používám:

blok {
	vnitřek bloku;
}

a ještě dokážu pochopit:

blok
{
	vnitřek bloku;
}

Ale závorky na stejné úrovni s vnitřkem bloku mi přijdou rušivé.

P.S. a šířku tabulátoru mám 4 znaky, takže to nevypadá tak hrozně jako tady (kde se ti asi tabulátor zobrazí široký 8 znaků)

[Radovan]

Příloha:

• bloky.png (14771 bytů)

To je o zvyku, já jsem se k tomu dopracoval postupně, a navíc každému vyhovuje něco jiného. Není jedna svatá pravda

Já tabulátor nepoužívám, odskáču to mezerami podle délky příkazu, aby to bylo zároveň s mezerou. Pak mi vyjde to na obrázku příloze.

[johniez]

Jezis, jeste promenliva velikost odsazeni. Ja myslel ze je to chyba, ze v ty ukazce je to nejdriv 5 a pak 3 mezery, ale ono je to schvalne! :)

Pak uz snad chybi jen mezery mezi nazvem funkce a oteviraci zavorkou.

[Radovan]

Nechybí, název funkce a parametry jsou jedno slovo, takže bez mezery.

Mezeru dělám pouze mezi příkazem a závorkou, a jinak jich moc nepíšu. Ani za čárkami ne. Nakonec třeba ve FORTRANu se dají naplácat i do příkazů nebo naopak nedělat vůbec, a funguje to

[pavlix]

Jezis, jeste promenliva velikost odsazeni. Ja myslel ze je to chyba, ze v ty ukazce je to nejdriv 5 a pak 3 mezery, ale ono je to schvalne! :)

Já bych toto a k tomu veškeré zarovnávání (kromě klasického odsazení o přesně daný násobek odsazovacích sekvencí) tvrdě odmítal. Přijde mi to jako hrozné zvěrstvo. A závorky zarovnané na vnitřek bloku nemají podle mě žádné opodstatnění. Ale se mnou tohle neřešte, já jsem trochu moc na rozum a logiku. :)

[xkucf03]

+1

Ale občas ve výjimečných situacích zarovnávání používám – když tím chci vyjádřit, že ty řádky jsou z většiny* stejné – díky zarovnání je pak líp vidět, co je stejné a čím se liší. Jenže pak je zase problém, když se něco změní – je potřeba upravit odsazení všech řádků.

Zavádět ale zarovnávání jako nějakou systémovou součást konvencí mi přijde zbytečné. Např. se změní typ návratové hodnoty a je potřeba změnit odsazení/zarovnání celého bloku.

*) ano, nabízí se možnost si udělat metodu/funkci, která to stejné implementuje, ale taková metoda by často nic moc nedělala, a hlavně by stejný problém nastal při jejím volání – protože ty rozdíly jsou např. v délce názvu proměnných.

[pavlix]

+1

Nic není tak svaté, aby to nemohlo mít výjimku. Jinak v NetworkManageru a dalším GLib based kódu mě to vyloženě zdržovalo a navíc to úplně rozbíjí diffy, takže jsem si k tomu vypěstoval vyloženě averzi.

[Ondrej Santiago Zajicek]

Např. se změní typ návratové hodnoty a je potřeba změnit odsazení/zarovnání celého bloku

GNU coding style doporucuje mit navratovou hodnotu na separatnim radku.

[pavlix]

Proti tomu vůbec nic nemám. Ale při používání zarovnání se ten problém přenáší na název API. A navíc mi přijde, že se takový kód i špatně píše, zvlášť když se třeba odsazuje tabuláry a zarovnává mezerami. Pak různé projekty vymýšlí, že definují šířku tabu, ačkoli je jeho jediným smyslem proměnná šířka, aby zakryl chyby v nešikovně navrženém formátování, které navíc nikdo úplně nedodržuje.

[RM]

V Perlu, kde je hodně svorek jsem to začal používat, ale jen u cyklu for a jen s odsazením o dvě mezery, kód v těle o další dvě. Je to pak v kódu rychleji rozeznatelné a je to takové zpestření :).

[Radovan]

Jo, to jsem kdysi zkoušel také. Šlo to, ale nějak mi to nestačilo.

[pavlix]

Odsadit nejdřív závorky a pak ještě kód, to mi něco připomíná... že by glibc?

[RM]

Je to možné, já glibc neznam.

[Bedňa]

Toto radím medzi top najhoršieho odsadzovania, nad tým vedie už len náhodný počet medzier

[Radovan]

Viz například strana 35: http://bitsavers.informatik.uni-stuttgart.de/pdf/chromatics/CGC_7900_C_Programmers_Manual_Mar82.pdf

[Bedňa]

Bez urážky, vyzerá to hrozne, osobne používam"

foo (bar) {
	a = b
	if (a > 1) {
		print "a > 1"
	}
}

Proste jasne vidíš zarovnanie začiatku a konca. Je viacero zápisov ktoré akceptujem a sú čitateľné, ale ten tvoj medzi ne nepatrí, sorry :)

[Radovan]

Já v tom tvém zase vidím nějak podivně rozházené výkřiky, kde musím hledat co k čemu patří. Ale zkusím to ještě jinak:

void printb(unsigned int n)
     begin
     if (n)
        begin
        printb(n>>1);
        if (n&1)
           begin
           putchar('1');
           end
        else
           begin
           putchar('0');
           end
        end
     end

Takhle v tom ty obdélníky prostě vidím, na obrazovce, na výtisku, i když to napíšu rukou.

[xkucf03]

Jenže to vyvolává pocit, že kód, který je pod printb nebo if odsazený, pod printb nebo if i skutečně patří – jenže tak to nefunguje, na odsazení nezáleží a záleží na tom, co je mezi begin/end (což už odsazené není, je to na stejné úrovni).

[Radovan]

Však patří, ne? Takhle:

     if (n)
        begin
        end

A blok kódu uvnitř je zarovnaný podle begin-end.

Ale neřeš to, mě to prostě vyhovuje a kdysi bylo něco podobného v módě, dneska to už skoro nikdo nepoužívá. Holt musím mít vždycky něco extra

[Bedňa]

Môže to odradiť keď to hodíš na GitHub, medzi nás obyčajných ľudí :)

[Radovan]

Gitco? Neboj, tak zlý nebudu

[Bedňa]

U teba nevidím uzatvorenie funkcie, pretože je odsadené.

void printb(unsigned int n) begin
	if (n) begin
		printb(n>>1);
        	if (n&1) begin
			putchar('1');
		end
        	else begin
			putchar('0');
		end
	end
end

Teraz vidím kde končí. Toto je nekonečné flame, buď uznáš že je to čitatelnejšie, alebo to nikam nepovedie :)

[wamba]

mně vždycky přišlo přirozenější psát

if ( True, False, ).pick {
    say 'a';
} else {
    say 'b';
}

oproti doporučovanému

if ( True, False, ).pick {
    say 'a';
}
else {
    say 'b';
}

[Bedňa]

Tvoje riešenie akceptujem a ešte aj:

if ( True, False, ).pick
{
    say 'a';
}
else
{
    say 'b';
}

Stále tam vidím na prvý pohľad začiatok a koniec a môžem rýchlo hľadať v kóde.

[Kate]

Doporučovaného jak kde :) Třeba golang (a obecně styling guides googlu třeba pro C++) preferují tvou variantu, stejně jako Qt, tady to máš pro C…

[wamba]

hm, tak koukám, že i perltidy pomocí --cuddled-else lze na takové chování přepnout. Děkuji za upozornění.

[pavlix]

Na tomhle kódu je jasně vidět, že je if, else a end na stejné úrovni. Jenže ve skutečnosti end patří k begin a tudíž by mezi nimi na stejné úrovni nic být nemělo. Ten systém je nelogický a neodpovídá skutečné struktuře kódu.

[pavlix]

A jinak zlatý Python, kde tohle nejde prasit, jen škoda, že neřeší podobně i datové struktury, tak se je už většinou snažím vykopnout do YAML.

[Radovan]

V Pythonu by to bylo to samé bez begin a end, ne?

void printb(unsigned int n)
     if (n)
        printb(n>>1);
        if (n&1)
           putchar('1');
        else
           putchar('0');

[Fluttershy, yay!]

Nebylo.

[pavlix]

Jak to myslíš? Jako že by v Pythonu bylo stejné odsazení begin a end, které tam v žádné podobě nejsou? A pak se divíš, že tě nebere nikdo vážně?

[sad]

V PHP se k převodu do binární soustavy používá funkce decbin(), zde je její upravený kod

char *decbin(int value)
{
	static char digits[] = "0123456789";
	static char buf[128];
	char *ptr;
	
	ptr = buf + sizeof(buf) - 1;	
	*ptr = '\0';
		
	do {
		*--ptr = digits[value % 2];
		value /= 2;
	} while (ptr > buf && value);	
	
	return ptr;	
}

Originál funkce je zde, hledejte funkci _php_math_longtobase.

[sad]

V poli digits jsem mohl nechat jen jedničku a nulu, funkce v PHP převádějí čísla i do osmičkové a šestnáctkové soustavy.

[unicode]

To je ale kod jak z roku 1980, thread safety, nic?

[sad]

Takhle pokročilý ještě nejsem.

[pavlix]

Vždyť si to může podle potřeby upravit. Jak ukázka to stačí.

[Kvakor]

To je ale kod jak z roku 1980, thread safety, nic?

Stačilo by umazat ten druhý static, ten první se tam klidně může nechat (i když by bylo dobré tam dát navíc const), a na konci přidát jeden strdup() a je to. Vysledek by se ovšem musel uvolnit přes free().

Nicméně žádný opravdový Cčkař se zkušeností s hardwarem by nikdy nenapsal do vnitřní smyčky dělení a modulo, pokud se jedná o dvojku, ale použil by bitový posun doprava o jeden bit a vymaskování s nejnižším bitem. A těch 128 znaků velký buffet je zbytečně moc, pokud se to nebude pouštět na nějaké obludnosti, kde je int stodvacetiomsibitový, tak by stačilo 32+1 nebo 64+1 znaků v bufferu (případně místo +1 dát +4, kvůli zarovnání), dá se to zjistit podle INT_MAX. No a nakonec, nepoužil by konverzní tabulku (ze které se stejně používají jen dva znaky z deseti), ale přičetl by výsledek maskování ke znaku '0', protože číslice jsou za sebou jak v ASCII, tak dokonce i v EBCDIC

[deda.jabko]

Nicméně žádný opravdový Cčkař se zkušeností s hardwarem by nikdy nenapsal do vnitřní smyčky dělení a modulo, pokud se jedná o dvojku, ale použil by bitový posun doprava o jeden bit a vymaskování s nejnižším bitem.

Ano, to je oblibena zabava pravych ceckaru, misto toho, aby v programu vyjadrili, co ma dany program delat, tak pisou, co ma delat dany procesor. A pak, aby se v tom prase vyznalo, kdyz se clovek snazi desifrovat, jak dany program funguje. Znam lidi, kteri misto x = 0, pisou x ^= x, protoze si mysli, ze to je rychlejsi, protoze tomu tak kdysi davno bylo.

Deleni i nasobeni dvojkou prekladace prevadi na shift automaticky, podobne optimalizuji i obecne nasobeni a deleni konstantou.

[kralyk z abclinuxu]

Tobě se určitě bude líbit následující funkce:

float wtf(float x)
{
	float x2 = x * 0.5f;
	long i = *(long *)&x;
	i  = 0x5f3759df - (i >> 1);
	x  = *(float *)&i;
	return x * (1.5f - (x2 * x * x));
}

[pc2005]

To je z to quake enginu?

[kralyk z abclinuxu]

jj

[deda.jabko]

Ano. A ja zase pouzivam toto, hec!

x = (x & 0x55555555) + ((x >> 1) & 0x55555555);
x = (x & 0x33333333) + ((x >> 2) & 0x33333333);
x = (x & 0x0F0F0F0F) + ((x >> 4) & 0x0F0F0F0F);
x = (x & 0x00FF00FF) + ((x >> 8) & 0x00FF00FF);
x = (x & 0x0000FFFF) + ((x >>16) & 0x0000FFFF);

Ale nastesti buh stvoril komentare, takze vim, co to dela. ;-]

[kralyk z abclinuxu]

To vypadá jako popcount nebo něco na ten způsob, ale možná jsem mimo...

[Jendа]

Ano, je to popcount, sčítá to postupně po sloupcích. Normální člověk použije builtin překladače a ten pak z toho vyrobí to, co je na daném procesoru nejrychlejší (může to být třeba varianta s modulem nebo ještě lépe některé architektury na to mohou mít instrukci).

[deda.jabko]

Normální člověk použije builtin překladače a ten pak z toho vyrobí to, co je na daném procesoru nejrychlejší

Pokud potrebujes cilit na ruzne platformy, kde se pouzivaji ruzne prekladace, prestavas byt normalnim clovekem.

[hypvofxy]

x86 ma popcnt

[deda.jabko]

Ano.

[Jendа]

float x2 = x * 0.5f;

Určitě by bylo lepší od mantisy odečíst integerově jedničku, ne? Sice to na současných procesorech bude pomalejší (místo jedné FPU instrukce, která může klidně trvat jenom jeden takt, že musí extrahovat bajt), ale to přece nevadí…

[pc2005]

Znam lidi, kteri misto x = 0, pisou x ^= x, protoze si mysli, ze to je rychlejsi

BTW Na které architektuře to je rychlejší, vím jen že na x86 to je kratší o bajt (xor ax,ax), MIPS to má snad podobný - já teda dělal jen na derivátu microblaze.

[deda.jabko]

AFAIK, bylo to rychlejsi na nekterych sestnactibitovych x86, pak to paradoxne vedlo ke zpomaleni, protoze to delalo zavislost mezi hodnotami a blokovalo to prejmenovani registru, a kdyz jsem se pred casem dival, tak by to melo byt u novych architektur prekladano na stejne uops.

[hypvofxy]

Jo, na 286 trval XOR jeden a MOV, tusim, dva takty.

[unicode]

Nove intel penalizuje vetsinu instrukci, ktere pouzivaji 66H prefix (tj. 16bitova operace), krome memory loads a stores, dale nema rad pouzivani 8bitovych AH|BH|CH|DH (spodni AL|BL|... jsou ok).

To znamena, ze pouzivat 16bitove typy v C mimo struktury neni ok (ani pro ARM a dalsi).

[pc2005]

Jo aha přejmenování registrů, to mě hnedka nedošlo...

[unicode]

xor eax, eax
33C0
xor rax, rax (zbytecne)
4833C0
mov eax, 0 (zbytecne)
B800000000

Kratsi to samozrejme je, ale takovou trivialitu resi prekladac. Napsat x^=x je negramotnost.

[Michal Kubeček]

Ano, to je oblibena zabava pravych ceckaru, misto toho, aby v programu vyjadrili, co ma dany program delat, tak pisou, co ma delat dany procesor. A pak, aby se v tom prase vyznalo, kdyz se clovek snazi desifrovat, jak dany program funguje.

Naprosto souhlasím s myšlenkou (že nemá smysl napovídat optimalizátoru), ale v tomhle konkrétním případě bych řekl, že shift a bitový and s jedničkou jsou přinejmenším stejně názorné jako dělení a zbytek (ty mají výhodu spíš v tom, že stačí drobná změna, pokud by základ soustavy nebyla mocnina dvojky).

[unicode]

Tak ono hlavne bit-and a modulo delaji neco jineho, takze zalezi na situaci:

#include <stdio.h>

int a(int x) { return x & 1; }
int b(int x) { return x % 2; }

int main(int argc, char* argv[]) {
  printf("a(-11) -> %d\n", a(-11));
  printf("b(-11) -> %d\n", b(-11));
  
  return 0;
}

Vysledek:

a(-11) -> 1
b(-11) -> -1

[Michal Kubeček]

Člověka, který chování modulo vymyslel, a hlavně toho, kdo ho pak kodifikoval, bych někdy rád dostal do ruky, abych to s ním mohl proinzultovat…

[unicode]

Ja jsem myslel ze v C je modulo dokonce implementation dependent, ale nechce se mi hledat :)

[Michal Kubeček]

Není:

When integers are divided, the result of the / operator is the algebraic quotient with any fractional part discarded.⁸⁸⁾ If the quotient a/b is representable, the expression (a/b)*b + a%b shall equal a.

…

⁸⁸⁾ This is often called “truncation toward zero“.

[unicode]

Tak jsem to nasel a je to tak od C99:

in C99 or later, division of integers involving negative operands always truncate towards zero.

Note that, in C89, whether the result round upward or downward is implementation-defined. Because (a/b) * b + a%b equals a in all standards, the result of % involving negative operands is also implementation-defined in C89.

[kralyk z abclinuxu]

Člověka, který chování modulo vymyslel, a hlavně toho, kdo ho pak kodifikoval, bych někdy rád dostal do ruky, abych to s ním mohl proinzultovat…

Proč ti to vadí?

[Michal Kubeček]

Protože nemá některé elementární vlastnosti, které je logické očekávat, např.

  (a + k * d) % d == a % d
  (a + k * d) / d == (a / d) + k

Nevzpomínám si, že bych někdy narazil na situaci, kde by se při záporné hodnotě prvního operandu hodila definice z C99. Naopak, už mockrát jsem to musel obcházet buď větvením nebo rovnou dodefinováním real_mod() a real_div().

Bohužel už tahle definice "vyhrála" a je pozdě s tím něco dělat, stejně jako s kalendářem bez roku 0. Tvůrce kalendáře aspoň omlouvá doba, kdy se tak stalo.

[Appleby]

Že Kubeček nechápe modulo, asi nikoho nepřekvapí, ale že nepochopil ani princip kalendáře, to už je opravdu zarážející. Dělit dějiny na tři úseky, BC, AD a AK (An(n)us Kubeceki), by bylo úžasně praktické :)

[pc2005]

Hmm to by bylo zajímavé jméno instrukce je kongruentní modulo d .

[xkucf03]

stejně jako s kalendářem bez roku 0. Tvůrce kalendáře aspoň omlouvá doba, kdy se tak stalo.

Na pravítku je taky nula jen ten bod, ale první centimetr (úsek) je první (č. 1, ne 0). Kalendář funguje stejně, ne?

[Michal Kubeček]

Jestli je nula jen ten bod, pak jednička taky. A stejně tak -1 atd. V tom problém není, je jedno, jestli chci číslovat body nebo intervaly. Problém je v tom, že tady někdo vzal dvě kopie přirozených čísel (bez nuly), jednu otočil a nalepil je k sobě bez potřebné nuly, čímž rozbil aritmetiku. Ta nula tam prostě chybí. Takže když se budeme např. ptát, kolik let uplynulo od 1.6.5 př.n.l. do 1.6.5 n.l., oproti očekávání to nebude deset, ale jen devět.

Lidi si na to samozřejmě zvyknou a naučí se s takovým systémem s nelogickými a zbytečnými výjimkami pracovat (nebo taky ne). (Koneckonců by to šlo i s kalendářem, který by na obě strany začínal třeba desítkou.) Někteří na to jsou dokonce hrdí a ten systém zuby nehty obhajují. Já jsem holt na takové zbytečné a nelogické komplikace citlivější.

[pavlix]

A proto jsem někde zahlédl škálu, kdy rok -5 je rok 6 BC.

[kralyk z abclinuxu]

Při použití ISO 8601 se IIRC obvykle předpokládá astronomický rok, který rok nula má, ie. 0 = 1BC, -1 = 2BC, atd.

Pokud jsi citivlivější na drobné nelogičnosti, pak bys s datem a časem raději vůbec neměl pracovat. Absence roku 0 je asi tak ten nejmenší problém.

[pavlix]

Pokud jsi citivlivější na drobné nelogičnosti, pak bys s datem a časem raději vůbec neměl pracovat. Absence roku 0 je asi tak ten nejmenší problém.

+1 :D

[xkucf03]

astronomický rok, který rok nula má, ie. 0 = 1BC, -1 = 2BC, atd.

To mi přijde ještě pošahanější, než zapisovat nedokončené roky, měsíce a dny a vedle toho vesele zapisovat jen dokončené hodiny, minuty a vteřiny.

[Ondrej Santiago Zajicek]

To je prirozeny zpusob, vychazi z toho, ze se 'bod 0' proste posune o rok drive.

Rozdil mezi cislovanim roku a cislovanim 'nizsich' udaju (mesicu az sekund) je v tom, ze zatimco 'nizsi' udaje jsou na omezenem intervalu, tak roky jsou neohranicene. U 'nizsich' udaju muzeme cislovat prirozenymi cisly a je vcelku jedno, zda cislujeme od 0 nebo od 1 (i kdyz by bylo lepsi to mit konzistentni). Oproti tomu roky jdou zpet prakticky neomezene, takze nelze rozumne pouzit cislovani prirozenymi cisly [*], ale je treba cislovat celymi cisly. A tam je prave jeden rok 0.

[*] Cislovat to prirozenymi cisly lze. ale nerozumne. Tak jak se to bezne dela. Pomoci dvou separatnich jednosmernych os.

[xkucf03]

To je prirozeny zpusob, vychazi z toho, ze se 'bod 0' proste posune o rok drive.

Bod nula se ale nikam neposouvá – nachází se na hranici prvního úseku (roku) vpravo a prvního roku vlevo.

Rozdil mezi cislovanim roku a cislovanim 'nizsich' udaju (mesicu az sekund) je v tom, ze zatimco 'nizsi' udaje jsou na omezenem intervalu, tak roky jsou neohranicene.

To bohužel nefunguje. Měsíce a dny totiž zapisujeme stejným způsobem jako roky – dne 10. 2. uběhl 1 celý měsíc a 9 celých dní (+ nějaké menší jednotky, které zápis nevyjadřuje) od začátku roku a jsme v 2. měsíčním úseku a v rámci něj v 10. denním úseku.

Zatímco v 12:30 uběhlo od začátku dne 12 celých hodin a 30 celých minut (+ nějaké menší jednotky, které zápis nevyjadřuje) a jsme tedy ve 13. hodinovém úseku dne a v rámci něj v 31. minutovém úseku.

[Ondrej Santiago Zajicek]

nachází se na hranici prvního úseku (roku) vpravo a prvního roku vlevo.

Tak tomu je v 'klasickem' cislovani roku. V astronomickem cislovani roku (ktere pouziva ISO 8601) je na hranici mezi rokem 0 a rokem -1. Tedy o rok driv nez v 'klasickem' cislovani roku.

[xkucf03]

To mají ale špatně. Leda, že bychom letošní rok zapisovali jako 2015 nikoli 2016 – pak by to smysl dávalo.

Ale tvrdit, že existuje rok nula a zároveň, že letos máme 2016, je naprosto zcestné.

[kralyk z abclinuxu]

Ale tvrdit, že existuje rok nula a zároveň, že letos máme 2016, je naprosto zcestné.

Šmarja. Nic nesmyslného na tom není. Prostě akorát udávají tu nulu v jiný moment, než kde na ní z nepochopitelného důvodu trváš ty. Má to tu výhodu, že astronomický letopočet je v rovině s gregoriánský anno dominy, což je mnohem užitečnější než být kompatibilní s BC částí, pokud bys nulu umístil o rok později, jak navrhuješ...

[xkucf03]

A k čemu je rok 0, když nemáme měsíc 0 nebo den 0?

Jakou má logiku formát: yyyy-MM-dd HH:mm:ss, kde

yyyy – máme nulu
MM   – nemáme nulu
dd   – nemáme nulu
HH   – máme nulu
mm   – máme nulu
ss   – máme nulu

?

[pavlix]

A k čemu je rok 0

K tomu aby se dalo s letopočty dobře počítat.

[xkucf03]

Příloha:

• kalendář.jpeg (176860 bytů)

jj, to dává vážně smysl…

[pavlix]

Ano, dává, narozdíl od toho obrázku, co postuješ.

[xkucf03]

Jak se v tomhle liší čas a prostor?

[pavlix]

Nijak.

[Ondrej Santiago Zajicek]

Jak pisu vyse. U mesicu ci dni na tom az tak nezalezi, protoze nemame zadne mesice ci dny cislovane zaporne, takze 0 je na kraji, Interval 1..12 je 'bez der' stejne jako interval 0..11; oproti tomu u roku mame zaporne roky, takze v cislovani -hodne..-1,1,..+hodne je proste jedno cele cislo vynechane uprostred. To je stejne nesmyslne cislovani, jako by nekdo cisloval mesice stylem 1..6,8..13.

[pavlix]

+1

[xkucf03]

Nikoli. Je to jako kdybys třeba půlnoc z úterý na středu považoval za nějak důležitou a pak čísloval:

pondělí = -2
úterý   = -1
středa  =  1
čtvrtek =  2
pátek   =  3
sobota  =  4
neděle  =  5

Tzn. kolikátý den od bodu nula to je. Zcela logické.

[xkucf03]

Resp. lepší zápis (což je ale jen formát, logika za tím zůstává stejná) by byl označovat úterý i středu jako 0 dní a vzdálenost od bodu nula vyjádřit menší jednotkou (v případě středy kladné číslo, v případě úterý záporné). Tzn. zapisovat dokončené úseky (jako to děláme u hodin, minut, dní) a ne nedokončené (jako se to dělá u dní, měsíců a let).

[xkucf03]

A s tím by se skutečně dobře počítalo, protože by to bylo normální číslo, třeba i desetinné, jako když měříš délky, hmotnost bajty atd.

Toto je správné řešení – upravit formát, nikoli posouvat začátek. Pak bychom tedy aktuální rok psali jako 2015 (nikoli 2016).

[xkucf03]

P.S. pokud chceš letošnímu roku říkat 2016 a formátovat to kompatibilně se zbytkem světa (abys ten zápis neměl posunutý), je potřeba si být vědom toho, že to číslo vyjadřuje pořadí roku od počátku (bodu nula). A pokud si pak chceš psát cykly typu

for (int i = x; i < y; i++) {
    // dělej něco s rokem i
}

tak si to pořadí (např. 2016) musíš převést na počet celých let od počátku a na výstupu si to zase naformátovat zpět (převést dokončené roky na pořadí).

Ale posunout kvůli pouhému formátování bod nula o rok je nehorázná prasárna.

[Ondrej Santiago Zajicek]

Ocislovani objektu (napr. roku, dni) neni nic jineho nez vzajemne jednoznacne zobrazeni mezi temi objekty a intervalem celych cisel, ktere zachovava usporadani a operace predchudce/naslednika.

Cislovani, ktere mapuje utery na -1 a stredu na 1 je pitome, nebot vynechava 0 z toho intervalu a 'ma v sobe diru'.

Cislovani, ktere mapuje utery i stredu na 0 je jeste pitomejsi, nebot ani neni proste (dva objekty se mapuji na stejne cislo).

Obe tato cislovani navic rozbijeji zachovani operaci predchudce/naslednika.

Tve uvahy vychazi z te zasadni chyby, ze zamenujes strukturu usporadani prirozenych a celych cisel a konvence s nima spojene.

[xkucf03]

Musím říct, že jsem během této diskuse trochu změnil názor a posunul svoje hodnocení z „je to úplná blbost“ k „je to dost podivné a má to různé nevýhody, ale svým způsobem to dává smysl“.

Ocislovani objektu (napr. roku, dni) neni nic jineho nez vzajemne jednoznacne zobrazeni mezi temi objekty a intervalem celych cisel, ktere zachovava usporadani a operace predchudce/naslednika.

Pokud to bereš čistě jako mapování nějakých seřazených entit na celá čísla, tak to nějaký smysl dává. To uznávám.

Co mi na tom moc nesedí, je, že běžně a primárně nečíslujeme úseky – prakticky vždy číslujeme body – např. délka, teplota, hmotnost. A číslování úseků je až odvozené od číslování těch bodů (např. úsek x-tý kilometr).

Cislovani, ktere mapuje utery i stredu na 0 je jeste pitomejsi, nebot ani neni proste (dva objekty se mapuji na stejne cislo).

Tam se totiž nejedná o mapování, ale o měření, jako kdybys měřil třeba teplotu nebo délku. Tam máš 0,5 a -0,5 centimetrů nebo stupňů, tzn. oboje je 0 celých jednotek, akorát jednou je ta nula kladná a jednou záporná (resp. kladné nebo záporné jsou ty menší jednotky/desetiny).

BTW: číslují se ještě někde jinde úseky místo bodů? Napadají mne třeba stránky v knize, ale to není zrovna fyzikální veličina.

[kralyk z abclinuxu]

BTW: číslují se ještě někde jinde úseky místo bodů? Napadají mne třeba stránky v knize, ale to není zrovna fyzikální veličina.

To je dobrá poznámka, letopočty se blíží právě spíše něčemu takovému jako je číslování knih. Jsou podobně vágní. Číslo stránky nedopovídá číslu v jiném vydání téže knihy.

Ani nemusíme chodit moc daleko do nějakého starověku. Například mezi lety 1155 až 1752 začínal v Británii oficiálně rok 25. března. V důsledku toho například poprava Karla I. Stuarta je v historických záznamech datována na 30. ledna 1648, z pohledu standardního gregoriánského kalendáře to ale bylo 30. ledna 1649.

Letopočty a kalendáře mají do fyzikálních veličin dost daleko. Je to v podstatě záležitost kulturních zvyklostí.

[xkucf03]

Například mezi lety 1155 až 1752 začínal v Británii oficiálně rok 25. března. V důsledku toho například poprava Karla I. Stuarta je v historických záznamech datována na 30. ledna 1648, z pohledu standardního gregoriánského kalendáře to ale bylo 30. ledna 1649.

A jak se s tím vyrovnává astronomický rok?

(oproti tomu je „absence roku nula“ úplná prkotina, která se kompenzuje jednoduchou konverzí: „do určitého okamžiku posouvám o konstantu, pak už neposouvám“)

[pavlix]

Jak prosím souvisí určení začátku kalendářního roku s astronomickým rokem?

[kralyk z abclinuxu]

A jak se s tím vyrovnává astronomický rok?

Také nerozumim souvislosti. Astronomický rok je určený pro - ehm - astronomii, ne úplně pro historii středověké Evropy...

[kyknos]

Oser to musí být pro astrology...

[Ondrej Santiago Zajicek]

Co mi na tom moc nesedí, je, že běžně a primárně nečíslujeme úseky – prakticky vždy číslujeme body – např. délka, teplota, hmotnost. A číslování úseků je až odvozené od číslování těch bodů

Pokud mam spojitou velicinu (napr. delka, teplota, cas). tak v ni body odpovidaji hodnotam realnych cisel. Pokud mam diskretni objekty, tak ty cisluji celymi cisly.

Cas je sice spojita velicina, ale v okamziku, kdy ji rozdelim na pevne intervaly, tak ty intervaly jsou jiz diskretni objekty, ktere normalne cisluji celymi cisly.

Neni pravda, ze by primarni byl u roku/mesicu/dnu pevny bodovy pocatek a z nej se teprve odvozovaly intervaly. Historicky je to naopak. Intervaly byly prirozene vymezene prirodnimi cykly (dny, lunarni mesice, solarni roky) ci jejich vice ci mene arbitrarni aproximaci podle stylu konkretniho kalendare. Ale v oznacovani konkretnich intervalu byl dost zmatek. Napriklad za doby stareho Rima se roky oznacovaly jmeny podle jmen konzulu, kteri ten rok nastoupili do uradu.

Model 'AD' cislovani roku julianskeho kalendare od 'bodoveho pocatku' odvozeneho od mytickych krestanskych udalosti vznikl az teprve cca 500 let po vzniku julianskeho kalendare, tedy hranice tech intervalu byly jiz davno vymezene, nez je nekdo zpetne ocisloval a zpetne stanovil 'bodovy pocatek'.

[unicode]

Jo, pod to bych s podepsal. Pri prechodu z Julian na Gregorian vznikla taky pekna sranda. Nejhorsi je, ze ten prechod probehl v ruznych zemich v ruzny cas, takze implementovat neco jako historicky kalendar je neco, co bych fakt nechtel :)

List_of_adoption_dates_of_the_Gregorian_calendar_per_country

[xkucf03]

Tam jde jen o to, že datum zapsané jako 1. 6. 0005 není 5,5, ale 4,5 (od bodu nula). Stejně jako na tom pravítku pět milimetrů z prvního centimetru není 1,5, ale 0,5. Ale to není v rozporu s tím, že ten první rok je první a letošní je dvoutisící šestnáctý.

Podle mého tedy není problém v tom, že počátek je nula a první rok je první, ale v tom, jak formátujeme datum a že někteří lidé od toho můžou mít nereálná očekávání. Dnešek a aktuální čas bychom tedy mohli logičtěji zapsat jako 2015'11'19 23:53 (místo apostrofu by byl asi vhodnější nějaký jiný symbol).

[kralyk z abclinuxu]

Tam jde jen o to, že datum zapsané jako 1. 6. 0005 není 5,5, ale 4,5 (od bodu nula).

V gregoriánském kalendáři žádný bod 0 není, v tom je ten fór.

[xkucf03]

Rok nula: Neexistuje v našem (křesťanském) letopočtu, který se používá souběžně s gregoriánským kalendářem (dříve s juliánským kalendářem). V tomto systému je rok 1 př. n. l. přímo následován rokem 1.

To chápu tak, že rok (úsek) nula sice nemáme, ale jako bod nula můžeme označit okamžik (půlnoc) mezi lety 1 př.n.l a 1 n.l.

Jako kdybys dal dvě pravítka proti sobě a to levé prohlásil za záporné – pak nemáš nultý úsek, ale máš první a mínus první centimetr a mezi nimi je bod nula.

[kralyk z abclinuxu]

ale jako bod nula můžeme označit okamžik (půlnoc) mezi lety 1 př.n.l a 1 n.l.

A k čemu to je dobré?

[xkucf03]

K čemu je dobrá nula na pravítku?

[kralyk z abclinuxu]

To spolu nějak souvisí? Jak?

[Michal Kubeček]

Takový způsob označování by měl smysl, kdyby ten "bod 0" byl nějaký naprosto zásadní přelom, kde bychom měli dvě zcela oddělené epochy, mezi nimiž by nebyla žádná kontinuita. Pak by mělo smysl mít nezávislé a oddělené datování "před" a "po" a vůbec by nevadilo, že se na obě strany čísluje od jedničky. Tak tomu ale není, zvolený "bod 0" je naprosto náhodně zvolený okamžik, který není významný vůbec ničím (kromě toho, že byl kdysi za ten počátek zvolen). Takže neexistuje žádný praktický důvod, proč uměle vymýšlet dva nezávislé letopočty a komplikovat si život při práci s jakýmkoli intervalem, který prochází přes počátek.

Mimo jiné bych doporučil zamyslet se nad tím, že jen proto, abychom se za na levé straně osy vyhnuli použití záporných čísel, číslujeme tam roky v opačném směru, než plyne čas - ale kupodivu jen roky, u všech menších komponent používáme stejný směr jako vpravo.

zapisovat nedokončené roky, měsíce a dny a vedle toho vesele zapisovat jen dokončené hodiny, minuty a vteřiny.

…což je ale vlastně opět jen důsledek uměle vynechané nuly. :-)

A tím bych radši skončil, diskusí na toto téma už jsem absolvoval spoustu a všechny (včetně této) probíhaly tak, že se mi lidé snažili trpělivě stále dokola vysvětlovat, jak byl ten kalendář navržen, a ignorovali, že chápu, jak byl navržen, ale považuji za nešťastný, nelogický a nepraktický a snažím se jen vysvětlit proč. Pro mne je to prostě jen názorný příklad, jak to dopadne, když se matematický model pokouší udělat někdo bez matematického myšlení.

[pavlix]

A tím bych radši skončil, diskusí na toto téma už jsem absolvoval spoustu a všechny (včetně této) probíhaly tak, že se mi lidé snažili trpělivě stále dokola vysvětlovat, jak byl ten kalendář navržen, a ignorovali, že chápu, jak byl navržen, ale považuji za nešťastný, nelogický a nepraktický a snažím se jen vysvětlit proč. Pro mne je to prostě jen názorný příklad, jak to dopadne, když se matematický model pokouší udělat někdo bez matematického myšlení.

+1

Můžeme k tomu zkusit přidat římský kalendář, který je přirozeným rozšířením debility římského systému zápisu čísel.

[Michal Kubeček]

Obzvášť zábavné jsou historky, jak ten či onen císař nesnesl pomyšlení, že "jeho" měsíc je kratší, tak si půjčil den odjinud. :-)

[Ondrej Santiago Zajicek]

Ta historka muze byt zabavna, ale je nepravdiva. Jak July tak August mely 31 dni uz od vzniku Julianskeho kalendare, tedy par desitek let drive, nez se vubec Augustus stal cisarem (a nez byl po nem mesic August pojmenovan).

[kralyk z abclinuxu]

Tahle konkrétní historka pravdivá asi není, ale je pravda, že se v Římě s kalendářem šachovalo z politických důvodů. Před juliánským kalendářem měli krátkej rok (něco mezi 350-360 dní, už nevim přesně) a jednou za pár let si přidali celej měsíc mezi únor a březenm (nazývaný Mercedonius). Rozhodnutí přestupný měsíc přidat/nepřidat ale bylo často motivováno snahou podržet kámoše u vlády déle nebo naopak způsobit kratší úřadování nepřátelům. Takže se stávalo, že kalendář byl v důsledku rozsynchronizován s tropickým rokem.

Výsledkem byl totální bordel. Tohle celý bylo koneckonců motivací k zavedení juliánského kalendáře...

[xkucf03]

Takový způsob označování by měl smysl, kdyby ten "bod 0" byl nějaký naprosto zásadní přelom, kde bychom měli dvě zcela oddělené epochy, mezi nimiž by nebyla žádná kontinuita. Pak by mělo smysl mít nezávislé a oddělené datování "před" a "po" a vůbec by nevadilo, že se na obě strany čísluje od jedničky. Tak tomu ale není, zvolený "bod 0" je naprosto náhodně zvolený okamžik, který není významný vůbec ničím (kromě toho, že byl kdysi za ten počátek zvolen).

O významnosti dané události nemá smysl se hádat. Klidně nad tím můžeme uvažovat v teoretické rovině a zvolit si libovolnou jinou událost. Např. si zvolíme 1. 1. 1970 jako bod nula a od něj počítáme vteřiny:

$ date --date="1970-01-01 00:00:00" --utc +%s
0
$ date --date="1970-01-01 00:00:01" --utc +%s
1
$ date --date="1970-01-01 00:01:00" --utc +%s
60
$ date --date="1970-01-01 01:00:00" --utc +%s
3600
$ date --date="1970-01-02 00:00:00" --utc +%s
86400

Co se týče zápisu, jde o to, zda si dohodneme, že budeme zapisovat dokončené úseky nebo nedokončené, právě probíhající. Ale to nic nemění na tom, že nultý úsek neexistuje, existuje jen bod nula.

Všude jinde např. při měření vzdáleností nebo peněžních částek se zapisují jen dokončené úseky a zbytek se vyjádří menší jednotkou nebo se zaokrouhlí nebo zahodí a nezapisuje vůbec.

Dokonce i věk člověka se uvádí v dokončených letech a ten zbytek se zahodí resp. neuvádí. Tzn. novorozeně je staré nula let, prožívá svůj první rok, ale žádný nultý rok/úsek tu není.

Mimo jiné bych doporučil zamyslet se nad tím, že jen proto, abychom se za na levé straně osy vyhnuli použití záporných čísel, číslujeme tam roky v opačném směru, než plyne čas - ale kupodivu jen roky, u všech menších komponent používáme stejný směr jako vpravo.

Ano, tohle je skutečný problém tohoto systému – na rozdíl od absence „roku nula“, která je zcela logická, protože nula je bod, nikoli úsek a neexistuje nultý rok, existují jen první (a další) roky na obě strany od tohoto bodu.

Na druhou stranu chápu, že je to dané snahou mít vztah mezi datem a ročním obdobím, dnem a nocí.

…což je ale vlastně opět jen důsledek uměle vynechané nuly. :-)

Nezaměňuj příčinu a následek.

chápu, jak byl navržen, ale považuji za nešťastný, nelogický a nepraktický a snažím se jen vysvětlit proč

Souhlasím, že ten systém je v mnoha ohledech špatný a nelogický. Ovšem zavedením „roku nula“ ničemu neprospěješ a naopak situaci ještě zhoršíš.

[xkucf03]

Teď jsem našel Číslování roků:

Léta Páně se počítají od kdysi předpokládaného dne Ježíšova obřezání, ke kterému mělo dojít 1. 1. roku 1. Za tohoto předpokladu k narození Krista došlo osm dní před začátkem letopočtu, tedy v roce označovaném 1 ante Christum natum, doslova v roce 1 před narozením Krista. Půlnoc na počátku dne, kdy měl být Kristus obřezán, tedy představuje bod na časové ose. Od tohoto bodu jsou oběma směry v čase roky (jednoroční časové úseky) číslovány počínaje číslem jedna. Není tedy rok 0, protože nulu představuje právě onen časový bod.

což potvrzuje moji představu.

[xkucf03]

Když budeme chtít spočítat kolik vteřin uběhlo od počátku, nemůžeme počítat:

2016 × počet_vteřin_v_roce + 12 × počet_vteřin_v_měsíci* + 20 × počet_vteřin_ve_dni + 23 × počet_vteřin_v_hodině + 53 × počet_vteřin_v_minutě

ale musíme počítat:

2015 × počet_vteřin_v_roce + 11 × počet_vteřin_v_měsíci* + 19 × počet_vteřin_ve_dni + 23 × počet_vteřin_v_hodině + 53 × počet_vteřin_v_minutě

Tam je ta nelogičnost v zápisu data oproti zápisu času (kde jedničku neodečítáme a rovnou násobíme). Chyba je v tom, že zapisujeme rok, který ještě nedoběhl – zatímco u hodin, minut, vteřin, centimetrů atd. zapisujeme jen celé části a ten zbytek (po dělení) vyjadřujeme menší jednotkou, kterou logicky přičítáme.

BTW: v některých programovacích jazycích resp. knihovnách je leden = 0 a první den v měsíci/týdnu je taky 0.

*) teď ignorujme, že měsíce jsou navíc různě dlouhé

[pavlix]

To píšeš jako by měly roky stejný počet vteřin. :D

[xkucf03]

Ano, ta poznámka *) se týká i toho – jinak to na věci ale snad nic nemění – přijde mi nelogické jednou zapisovat dokončený úsek a jindy nedokončený, právě probíhající.

[pavlix]

Co je přesně dokončeného na tom, že je půlnoc 00:00? Asi tvé teorii úplně nerozumím. :)

[Michal Kubeček]

IMHO tím bylo myšleno, že v datu píšeme "1" už během prvního dne, měsíce nebo roku, zatímco při zápisu času "1" až ve druhé hodině, minutě nebo sekundě.

[xkucf03]

Přesně tak.

[pavlix]

No dobře, ale to vůbec neospravedlňuje takovou interpretaci. Jako osobní pomůcka je to možná fajn, pokud to člověku vyhovuje, ale tlačit to ostatním je nesmysl.

[xkucf03]

0 = zatím nebyla dokončena žádná hodina a žádná minuta nového dne

Asi jako když jedeš z domova do cíle vzdáleného 100 km – doma máš dokončeno 0 km, po ujetí 900 m máš stále dokončeno 0 km, ale nacházíš se na úseku zvaném první kilometr, a v cíli máš dokončeno 100 km, ve chvíli, kdy ten cíl překročíš, tak se nacházíš na sto prvním kilometru od domova a jsi vzdálen např. 100,001 km.

[kralyk z abclinuxu]

To je naprosto nesmyslný výpočet hned z několika důvodů. To, čemu říkáš počátek, je rok 1, ie. ten výpočet je 2016 - 1 = 2015. To samé s měsícem - počítáš rozdíl mezi lednem (1) a prosincem (12), ie. 12 - 1 = 11. Ale to je celkem vedlejší, vzhledem k tomu, že rok 1 AD byl zadefinován asi 1000 let před vznikem gregoriánského kalendáře, kolem romu 1 AD je mezi nimi asi 2 dny rozdílu. Netuším, kolik to přesně dělá v sekundách. To že, roky a měsíce jsou různě dlouhé je další věc. Ano, roky, měsíce a dny indexujeme od jedničky narozdíl od časových údajů, ale při počítání rozdílů je to jedno a žádný skutečně dobře definovaný počátek stejně neexistuje.

[xkucf03]

Viz #165

Dejme tomu, že byl Ježíš obřezán 1. ledna roku 1 v 6:35. Pak bychom toto datum a čas mohli logičtěji zapsat jako 0000'00'00 06:35. A aktuální čas by byl 2015'11'20 00:44.

[kralyk z abclinuxu]

To s tou obřízkou je IMHO jen nějaká církevní bajka, česká wikipedie saje. Mrkni na Anno Domini.

Ano, mohli bychom počátek označit jako 0000'00'00 anebo taky třeba jako 123'04'00 a pak by dnes byl 2138'15'00 - v čem je pointa? Ten "bod 0" mi nepřijde v ničem relevantní.

[xkucf03]

Není to jen česká záležitost: Feast of the Circumcision of Christ a vzhledem k tomu, že tyhle věci chtě nechtě s křesťanstvím souvisí, tak náboženské zdroje relevantní jsou.

Nemusíme nad tím uvažovat v náboženské rovině, můžeme si zvolit jakýkoli jiný bod a od něj počítat – třeba vznik republiky, oznámení GNU manifestu, vydání první verze Linuxu atd.* A fungovalo by to úplně stejně. Ta událost se stala v nějakou hodinu určitého dne. Půlnoc na začátku toho dne prohlásíme za bod nula. Den té události je první den.

Ano, mohli bychom počátek označit jako 0000'00'00 anebo taky třeba jako 123'04'00 a pak by dnes byl 2138'15'00 - v čem je pointa? Ten "bod 0" mi nepřijde v ničem relevantní.

Ano a pravítko by taky mohlo začínat bodem 123 a pokračovat 124, 125… ale začíná bodem nula, což dává mnohem větší smysl – stejně jako bod nula v čase, po kterém následuje rok 1, což je vlastně první rok resp. úsek mezi bodem nula a bodem „1 R“ (analogicky: první centimetr je úsek mezi body 0 cm a 1 cm).

*) akorát když to nebude 1. ledna, tak to nebude sedět přírodní roky a měsíce – ale na ty bychom se mohli vykašlat a používat jiné úseky a nelpět na souvislosti s oběhem slunce a měsíce.

[xkucf03]

Půlnoc na začátku toho dne prohlásíme za bod nula. Den té události je první den.

Nebo za bod nula označíme přesně okamžik té události, pokud je nám jedno, kdy je světlo a kdy tma a stačí nám počítat úseky a označovat okamžiky nějakou jednotkou, aniž by v ní celé hodnoty měly souvislost s něčím dalším (oběh slunce, měsíce…).

Nic to nemění na tom, že počátkem je bod nula.

A pak jde jen o to, dohodnout si způsob zápisu dalších bodů, pokud budeme mít nějaké větší jednotky než základní. Např. bychom mohli počítat v kilosekundách, megasekundách… pak by počátek byl 0'0'0, o tisíc sekund později bychom měli 0'1'0 a o milion sekund později 1'0'0 (nebo jinak zapsáno 1 Ms + 0 ks + 0 s). To je ta logičtější varianta zápisu.

Nebo bychom to mohli zapisovat méně logicky (jako dnes píšeme datum a čas): např. 1. 1. 1, což by znamenalo bod vzdálený od počátku 0 000 001 vteřin tzn. jednu vteřinu a ne, jak by jeden čekal, 1 001 001 vteřin. Protože by autor normy rozhodl, že jedny jednotky (zde megasekundy a kilosekundy) budeme zapisovat ty nedokončené, právě probíhající, zatímco jiné budeme zapisovat ty dokončené (sekundy).

[kralyk z abclinuxu]

Obávám se, že mi to stále nedává vůbec žádný smysl. Bod nula na pravítku potřebuju, protože potřebuju občas zjistit, kolik centimetrů je mezi bodem A a B, na což je nula praktická, protože je neutrálním prvkem vzhledem ke sčítání (a tudíž také odčítání).

V kalendáři ale žádnou takovou potřebu nemam. K čemu je mi dobré zjišťovat, kolik času uběhlo od okamžiku, který nějaký mizerný historik i matematik v 6. století z nábožensko-politických důvodů víceméně náhodně určil za počátek? To je přece naprosto k prdu.

Kalendář není jako pravítko, resp. je jako pravítko, které je nekonečné na obě strany a nemá stejně dlouhé dílky. Ty dílky jsou nestejně dlouhé jednak z historických důvodů (na některých částech pravítka jsou definované jinak), ale také z fyzikálních důvodů (viz), ie. nikdy ani při sebelepší přesnosti měření stejně dlouhé nebudou.

Protože by autor normy rozhodl, že jedny jednotky (zde megasekundy a kilosekundy) budeme zapisovat ty nedokončené, právě probíhající, zatímco jiné budeme zapisovat ty dokončené (sekundy).

To, že rok ti připadá "nedokončený" je dáno pouze tím, že sis bod nula zvolil jako první sekundu roku 1, což je ale v podstatě pouze tvoje osobní arbitrátní/náhodná volba a nevím, proč to děláš. Objektivně není definováno, jestli je rok dokončený nebo ne.

Můžeš zkusit vymyslet nějaký praktický use case, pro který je ten tvůj návrh užitečný. Osobně moc žádný nevidim...

[pavlix]

To, že rok ti připadá "nedokončený" je dáno pouze tím, že sis bod nula zvolil jako první sekundu roku 1, což je ale v podstatě pouze tvoje osobní arbitrátní/náhodná volba a nevím, proč to děláš. Objektivně není definováno, jestli je rok dokončený nebo ne.

Asi tak. Ta dokončenost a nedokončenosti mi taky připadá jako bullshit vycucaný z prstu, jenom jsem to nechtěl hned napsat takhle naplno, kdyby za tím byla třeba nějaká myšlenka. Už jsem se nedávno spálil s Andrejem...

[Agent]

Já myslel, že 0 je vždycky na začátku. Kam jinam dát nulu, doprostřed pravítka?

Když teda pravítkem naměřim 0.5 mm od nuly tak je teda jedno jestli napíšu 0cm a 5mm nebo 1cm 5mm?

[kralyk z abclinuxu]

Když teda pravítkem naměřim 0.5 mm od nuly tak je teda jedno jestli napíšu 0cm a 5mm nebo 1cm 5mm?

No jestli se snažíš změřit vzdálenost od místa, kde byl podle legendy Ježíš narozen/obřezán/etc., pak nejspíše ano...

[pavlix]

Kam jinam dát nulu, doprostřed pravítka?

I takové někde doma mám, ale to není předmětem diskuze. I když potom, co jsem viděl tu fotku pravítek, co Franta posílal, už si vůbec nejsem jistý, zda vůbec existuje nějaký předmět diskuze společný všem účastníkům, spíše asi ne.

[xkucf03]

To bude asi pokus o nějaký vánoční trolling, protože se mi nechce věřit, že bys nezvládal úplné základy logiky a češtiny. :-)

V kalendáři ale žádnou takovou potřebu nemam. K čemu je mi dobré zjišťovat, kolik času uběhlo od okamžiku, který nějaký mizerný historik i matematik v 6. století z nábožensko-politických důvodů víceméně náhodně určil za počátek? To je přece naprosto k prdu.

Jak už jsem tu psal, v diskusi se klidně můžeme oprostit od jakýchkoli náboženských a historických souvislostí a jako bod nula si zvolit třeba začátek dne 1. 1. 1970 UTC nebo jakýkoli jiný okamžik, který dokážeme identifikovat a shodnout se na něm tak, abychom všichni mluvili o tom samém okamžiku. Následně si zvolíme základní jednotku (např. sekundu) a pak i nějaké větší jednotky (např. kilosekundy, megasekundy) a pak už jednoduše počítáme.

Nultá sekunda neexistuje, resp. není to úsek, ale bod nula. Existuje první sekunda, první kilosekunda, první megasekunda… a taky mínus první s, ks, Ms.

To, že rok ti připadá "nedokončený" je dáno pouze tím, že sis bod nula zvolil jako první sekundu roku 1, což je ale v podstatě pouze tvoje osobní arbitrátní/náhodná volba a nevím, proč to děláš. Objektivně není definováno, jestli je rok dokončený nebo ne.

Je to zcela objektivní. Pokud ujdeš 1 100 metrů, ušel jsi jeden celý (dokončený) kilometr + 100 metrů. Novorozeně žije svůj první rok, ale je staré nula let (nula celých let), staré jeden rok bude až po prvních narozeninách.

Když vlezeš do prázdné místnosti, jsi tam první, nikoli nultý. Když tam vleze další člověk, tak je druhý a jsou tam dva celí lidé (dokončení – proces vlezení do místnosti byl dokončen u dvou lidí). Když si další stoupne do dveří, můžeme říct, že v místnosti je 2,5 člověka, ale jsou tam jen dva celí lidé a on je třetí.

Pokud hledáš anologii s indexováním polí např. v C, tak index je něco jiného než pořadí a navíc index pole může být jen kladný, takže by nešlo vyjádřit roky před Kristem. A index vyjadřuje vzdálenost adresy počátku prvku od adresy počátku pole, kde měrnou jednotkou je délka datového typu. První rok bychom tedy mohli označit indexem 0, ovšem pak bychom letos měli rok označený jako 2015, nikoli 2016.

Nemůžeš smíchat tyto dva koncepty dohromady a tvrdit, že byl rok 0 a zároveň, že letos máme 2016 – to nedává smysl.

Kalendář není jako pravítko, resp. je jako pravítko, které je nekonečné na obě strany a nemá stejně dlouhé dílky. Ty dílky jsou nestejně dlouhé jednak z historických důvodů (na některých částech pravítka jsou definované jinak), ale také z fyzikálních důvodů (viz), ie. nikdy ani při sebelepší přesnosti měření stejně dlouhé nebudou.

Taky už jsem to tu psal – ten systém je v mnoha ohledech nedokonalý a nelogický, ale zavedením „roku nula“ tomu nijak nepomůžeš – naopak situaci ještě zhoršíš.

[Fluttershy, yay!]

Tak si nahraď číslovku základní číslovkou řadovou.

[xkucf03]

Přijde mi jednodušší se smířit s nelogičností ve formátování:

• roky, měsíce a dny zapisujeme ještě nedokončené, právě probíhající (tzn. 21. 12. znamená, že se nacházíme v průběhu dvacátého prvního dne dvanáctého měsíce daného roku)
• zatímco hodiny, minuty a sekundy zapisujeme, dokončené – kolik celých jednotek už uběhlo (tzn. 15:03 znamená, že se nacházíme v průběhu čtvrté minuty šestnácté hodiny daného dne).

než zavádět nějaký nesmyslný „rok nula“ – což nelogičnost ve formátování neodstraní, ba dokonce zhorší (roky se budou uvádět dokončené, měsíce a dny právě probíhající a hodiny, minuty a sekundy pro změnu zase dokončené) a ještě to udělá bordel v historických datech (před počátkem).

[Fluttershy, yay!]

a ještě to udělá bordel v historických datech

Víš, kdy byla VŘSR? 😏

[pavlix]

Obávám se, že tvoje interpretace o smysluplnosti nebo nesmyslnosti roku nula neříká vůbec nic. Když zapisuješ nedokončený první rok, jaký nedokončený rok je o rok dříve?

[xkucf03]

Nedokončená vzdálenost o délce jednoho roku od počátku.

[kralyk z abclinuxu]

Stále ještě jsi neuvedl žádný praktický use case tvého formátování, kromě "mně to dává větší smysl".

[xkucf03]

To ale není nějaké moje formátování – to je běžné formátování, které používají všichni včetně tebe. Všimni si, že já žádné změny nenavrhuji, jen upozorňuji na nesmyslnost/zbytečnost „roku nula“. A nemám (na rozdíl od některých) mentální problém s tím, že letopočet (tak jak ho běžně chápeme) označuje pořadí nedokončeného roku (aktuálně probíhajícího) od bodu nula, zatímco hodiny, minuty a vteřiny vyjadřují počet dokončených úseků. To mi sice přijde trochu nelogické (jednou je to tak a jednou tak), ale dá se s tím žít, je to jakási historická zátěž starého systému.

Pokud si chce někdo očíslovat všechny roky souvislou řadou celých čísel, aby se mu s tím „dobře počítalo“, tak je to jeho věc. Ale aby byl kompatibilní se zbytkem světa, tak ty záporné stejně musí převádět tam a zase zpátky.

[kralyk z abclinuxu]

A nemám (na rozdíl od některých) mentální problém s tím, že letopočet (tak jak ho běžně chápeme) označuje pořadí nedokončeného roku (aktuálně probíhajícího) od bodu nula, zatímco hodiny, minuty a vteřiny vyjadřují počet dokončených úseků.

Rok můžeš klidně chápat i jako dokončený, nebude v tom vůbec žádný rozdíl. U měsíců/dnů by to sice jistý rozdíl byl (mohlo by ti připadat, že máme aktuálně 13. měsíc), ale měsíce jsou stejně nepravidelné, takže se s nima beztak moc nedá pracovat běžnou aritmetikou...

Pokud si chce někdo očíslovat všechny roky souvislou řadou celých čísel, aby se mu s tím „dobře počítalo“, tak je to jeho věc.

Má to svoje použití v astronomii, např. počítání, kdy dojde/došlo k všelijakým zatměním a podobně... No a krom toho se to využívá v ISO8601.

Ale aby byl kompatibilní se zbytkem světa, tak ty záporné stejně musí převádět tam a zase zpátky.

Jistě, ale pánové IMHO celkem střízlivě vyhodnotili, že muset přepočítávat BC roky bude menší PITA než AD...

[kralyk z abclinuxu]

Je to zcela objektivní. Pokud ujdeš 1 100 metrů, ušel jsi jeden celý (dokončený) kilometr + 100 metrů. Novorozeně žije svůj první rok, ale je staré nula let (nula celých let), staré jeden rok bude až po prvních narozeninách.

Ano, ale tohle nemá moc smysl aplikovat na letopočet, protože nikde žádný objektivní počátek nemá, a navíc vzdálenost od tohoto počátku nikoho nezajímá a není k ničemu dobrá. Když jdu na túru, zajímá mě, kolik jsem ušel kilometrů, proto je tam užitečný ten výchozí nultý bod. Naproti tomu nemám úplně potřebu se ptát, kolik sekund uplynulo od okamžiku, kdy se na Ježíšovy genitálie někdo vrhl s nožem nebo jakéhokoli jiného podobného náhodného bodu historie.

Pokud hledáš anologii s indexováním polí např. v C, tak index je něco jiného než pořadí a navíc index pole může být jen kladný

Je to sice mimo diskusi, ale čistě pro pořádek, index pole v C klidně může být záporný.

Nemůžeš smíchat tyto dva koncepty dohromady a tvrdit, že byl rok 0 a zároveň, že letos máme 2016 – to nedává smysl.

Tak znova a postupně. Řekni, na kterým checkpointu ti selhavá logika:

Položení nuly je arbitrární, můžeme si ji položit kamkoli (checkpoint). Pokud ji položíme na začátek gregoriánského roku 1600AD, bude letos rok 416 (checkpoint). Pokud ji položíme na začátek roku gregoriánského 1AD, bude letos 2015 (checkpoint). Pokud na začátek 1BC, bude letos 2016 (checkpoint). Žádná z těchto voleb není nadřazená ostatním, protože objektivní nula neexistuje (leda bychom počítali big-bang, ale to je příšerně dávno, to by bylo jako používat Kelviny pro pečení kuřete) (checkpoint). Výhoda astronomického roku je v tom, že v něm funguje běžná aritmetika i pro roky před našim letopočtem, ie. třeba výpočet vzdálenosti roku -1000 a 1000 netrpí tím off-by-one jako v gregoriánském kalendáři (checkpoint). Astronomický rok byl zarovnán tak, aby označení let odpovídalo naším aktuálním AD rokům v greogriánském kalendáři, čistě z praktických důvodů (checkpoint). To, že BC roky gregoriánského kalendáře se v absolutní hodnotě liší o 1 od astronomických nás až zas tak netrápí, ačkoli ideální to není (grand finish).

[Fluttershy, yay!]

tohle nemá moc smysl aplikovat na letopočet, protože nikde žádný objektivní počátek nemá

Třeba je Franta kreacionista.

leda bychom počítali big-bang, ale to je příšerně dávno

Kdo říká, že letopočet musí růst lineárně...

[xkucf03]

Třeba je Franta kreacionista.

V tom případě by ale počátek byl mnohem dřív než v době narození Ježíše.

Už jsem tu psal, že za počátek si klidně můžeme zvolit 1. 1. 1970 a bude to fungovat stejně.

Kdo říká, že letopočet musí růst lineárně...

Pak ale nepotřebuješ ani rok nula, protože by ses stejně ničeho kloudného nedopočítal.

[xkucf03]

Chápu, že je to jakási aproximace a snaha o zjednodušení. Ale jde o to, že všechny historické události před naším letopočtem, u kterých známe konkrétní rok, tudíž ty u kterých by teoreticky dávalo smysl si aritmeticky počítat jejich vzdálenosti (např. kolik let uběhlo od události A př.n.l do události B n.l.), bys musel přečíslovat, což je krajně nepraktické a přineslo by to víc zmatků než užitku. A u těch řádově vzdálenějších, u kterých stejně nevíš, který rok se přesně staly, na nějakém posunu +/- jeden rok oproti konkrétním událostem n.l. už nesejde.

[kralyk z abclinuxu]

Příloha:

• bc.jpg (30748 bytů)

Chápu, že je to jakási aproximace a snaha o zjednodušení. Ale jde o to, že všechny historické události před naším letopočtem, u kterých známe konkrétní rok, tudíž ty u kterých by teoreticky dávalo smysl si aritmeticky počítat jejich vzdálenosti (např. kolik let uběhlo od události A př.n.l do události B n.l.), bys musel přečíslovat, což je krajně nepraktické a přineslo by to víc zmatků než užitku.

Při výpočtu kolik let uběhlo mezi událostmi A a B musíš přepočítávat v gregoriánském kalendáři úplně stejně jako v astronomickém letopočtu.

Historické události před rokem 1AD (a vlastně i nějakou dobu po něm) jsou stejně tak jako tak vždy přepočítané na juliánský nebo gregoriánský kalendář. Nebo máš pocit, že to tehdy fungovalo jako v picrelated? To asi úplně ne, že, oni používali svoje historické kalendáře (např. ten římskej byl mimořádně zmatenej) a naše datování historických událostí je uměle dopočítané (s větší či menší přesností) - říká se tomu proleptické datování.

[Agent]

Ano, ale tohle nemá moc smysl aplikovat na letopočet, protože nikde žádný objektivní počátek nemá, a navíc vzdálenost od tohoto počátku nikoho nezajímá a není k ničemu dobrá. Když jdu na túru, zajímá mě, kolik jsem ušel kilometrů, proto je tam užitečný ten výchozí nultý bod. Naproti tomu nemám úplně potřebu se ptát, kolik sekund uplynulo od okamžiku, kdy se na Ježíšovy genitálie někdo vrhl s nožem nebo jakéhokoli jiného podobného náhodného bodu historie.

IMHO Tady přece nejde o to, abychom věděli kolik let uběhlo od toho, kdy se někdo na někoho vrhnul s kudlou. Jde (asi) o to, abychom měli nějaký všeobecně uznávaný souřadný systém, ze kterého se dá odvodit, kolik let uplynulo od nějaký události.

Jak jinak počítat uplynulý čas třeba od narození mého potomka, to si mám jako dělat někam každý rok čárku, abych věděl, že už je mu třeba 18 let a je načase ho vypalejstrovat do světa? A co když jak se tak znám, nějaký rok zapomenu, nebo udělám čárku dvakrát, protože jsem zapomněl, že už jsem ji dělal, nebylo by to trochu nepohodlný?

[kralyk z abclinuxu]

Jde (asi) o to, abychom měli nějaký všeobecně uznávaný souřadný systém, ze kterého se dá odvodit, kolik let uplynulo od nějaký události.

Přesně tak, z tohohle hlediska je úplně jedno, kde máš nulu. To, že kolem roku 1AD je v gregoriánském kalendáří určitá nepravidelnost je pravda, ale těch nepravidelností tam stejně bude vícero (různé přestupné roky, juliánský kalendář, etc.) - záleží, co se snažíš spočítat a s jakou přesností to potřebuješ.

[Fluttershy, yay!]

*) akorát když to nebude 1. ledna, tak to nebude sedět přírodní roky a měsíce – ale na ty bychom se mohli vykašlat a používat jiné úseky a nelpět na souvislosti s oběhem slunce a měsíce.

Gratuluji, právě jsi dospěl k systému založenému na vydávání Linuxu.

[Kvakor]

Hezky řečeno. Dodal bych, že pokud někdo píše v Cčku a přesto nechápe, co znamená bitový posuv o n bitů doleva/doprava, vymaskování b itů pomocí bitového součinu a podbně, tak je buďto začátečník, nebo očividně používá nesprávný jazyk a měl by raději zvolit něco výšeúvovňovějšího.

[pc2005]

Jo mě nakopal zápornej bitshift v mpg123 .

[Agent]

Mohou být situace, že to z nějakého důvodu, který nedokáže sám ovlivnit, v tom Cečku psát prostě musí. Jinak bych předpokládal, že dnešní překladače dokážou optimalizovat tak, aby to bylo jedno, jak se to napíše.

[sad]

Proč vlastně není strdup() ve standardní knihovně? Je to docela důležitá funkce a je použita i v druhém vydání The C Programming Language.

[pavlix]

Na standardní knihovně je hodně věcí špatně.

[sad]

Takže by to vypadalo takto?

#include  <stdio.h> 
#include  <string.h> 
#include  <stdlib.h>

char *decbin(int value);

int main()
{
	int n;
	char *ps_bin;
	
	for(n = 0; n < 101; n++) {
		ps_bin = decbin(n);
		printf("%d\t%s\n", n, ps_bin);
		free(ps_bin);
	}

	return 0;
}

char *decbin(int value)
{	
	char buf[64 + 1];
	char *ptr;
	
	ptr = buf + sizeof(buf) - 1;	
	*ptr = '\0';
		
	do {
		*--ptr = '0' + (value % 2);
		value /= 2;
	} while (ptr > buf && value);	
	
	return strdup(ptr);	
}

Akorát je špatné, že ten kod funguje normálně, i když odstraníte free().

[kralyk z abclinuxu]

Akorát je špatné, že ten kod funguje normálně, i když odstraníte free().

Co je na tom špatného? To je leak, funkci by neměl ovlivnit...

[Jendа]

Akorát je špatné, že ten kod funguje normálně, i když odstraníte free().

Pokud chceš kontrolovat konzistenci paměti a leaky, musíš si o to říct. Třeba satan (ASAN) to umí:

/tmp> jcc decbin.c
/tmp> ./decbin 
0	0
...
100	1100100

=================================================================
==21025==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 682 byte(s) in 101 object(s) allocated from:
    #0 0x7f8336536d28 in malloc (/usr/lib/x86_64-linux-gnu/libasan.so.3+0xc1d28)
    #1 0x7f8335c361d9 in __strdup (/lib/x86_64-linux-gnu/libc.so.6+0x801d9)

SUMMARY: AddressSanitizer: 682 byte(s) leaked in 101 allocation(s).

Problém je že podle úlohy se program zpomalí 0.1-3x (za což asi může hardwarově neakcelerovaná kontrola out-of-bounds přístupu (mají nejnovější Intely) a mohlo by jít nastavit že chceš kontrolovat jenom něco).

[pavlix]

Nějaký důvod, proč nepoužít Valgrind?

[Jendа]

Je ještě mnohem pomalejší.

[pavlix]

Tak zase ho pouštíš jen při testování a přitom používáš v podstatně normální nestripnutou binárku, nebo si něco pamatuju špatně?

[Kvakor]

Přesně tak, Valgrind vlastně jen potřebuje, aby se binárka přeložila s -g. Mimo toho, proti pomalosti jde u některých typů úloh použít trik, že se na místa, kde se něco dělá, ale žádná paměť se nealokuje ani neuvolňuje, nandají "zapoznámkovací" #ifdefy a pro Valgrind se vytvoří speciální omezená verze binárky. Občas je to i nutné, některé knihovny po sobě moc neuklízejí ...

[pavlix]

Psal jsem do NetworkManageru (GLib) valgrind suppressions, takže trochu tuším. :) Ale asi je lepší, když se ta knihovna umí aspoň trochu chovat slušně, což GLib kupodivu i celkem zvládá.

[pavlix]

Správný céčkař by tu funkci psal tak, aby byl buffer poskytovaný volajícím, a zároveň aby uměla vydat požadovanou velikost bufferu, pokud se místo něj zadá NULL, viz snprintf(). Pro lamy by se kolem toho udělal wrapper s alokací, viz asprintf(). ;)

[unicode]

Nicméně žádný opravdový Cčkař se zkušeností s hardwarem by nikdy nenapsal do vnitřní smyčky dělení a modulo

To platilo v minulem tisicileti, a je mi lito tech lidi, co takto pisou... priklad.

[pc2005]

Tak například MIPSovej gcc-based kompilátor pro PIC32MX vyžaduje pro optimalizace (-O2 a c++ komplet(?)) koupi ne zrovna levné licence. A některý MCU výrobci jsou ještě horší.

[pavlix]

Closed source GCC based kompilátor?

[pc2005]

Víceméně ano:

... the following are disabled: C++, MIPS16e, LTO, -Os, -O3 and -O2

A nejspíš používaj nějakou vlastní uzavřenou libc (na tu by se GPL z GCC vztahovat nemělo).

Asi by šlo nahradit vanilla GCC, akorát se tu bavíme o velikostech kódu okolo 100kB, takže pokud GCC/newlib nemá ty optimalizace dostatečné, tak se prostě program nevejde (rozdíl optimalizací, co jsem testoval na eval licenci XC32 byl opravdu velký).

[pavlix]

A je to legální?

[Michal Kubeček]

Is that legal? :-)

[pc2005]

Tak to teda nevím, ale zatím jim to roky prochází . Kromě klasických binárek jsou v toolchainu už jen crtbegin.o, crtend.o, libgcc.a a libgcov.a (pro různé konfigurace jako mips16, size, speed apod.). Libc je taky ve formátu libc.a. Takže to není součást binárky GCC, ale nejspíš daný kompilátor ten objektovej soubor potřebuje, aby vytvořil funkční MCU kód.

Pak jsou ještě objektové soubory pro periferie v MCU.

[pavlix]

A vynutitelné? :)

[pc2005]

No zdrojáky kompilátoru by měli mít k dispozici, je možný že část věcí půjde ve zdrojáku prostě zakomentovat, ale kód optimalizace by měl být přímo od Microchipu.

Každopádně já to na PIC32 neřešil, můj komp má slabou CMOS baterku a jako na potvoru vždycky vypadne čas před pokusem o kompilaci eval verzi :-P.

[xkucf03]

protože číslice jsou za sebou jak v ASCII, tak dokonce i v EBCDIC

Že to pro nějaká dvě kódování (nebo dokonce většinu dnes běžně používaných kódování) funguje, neznamená, že bys to měl zadrátovat do kódu. Podle mého je to předpoklad/závislost na něčem, na čem bys záviset neměl – je to podobně špatný přístup jako např. předpokládat, že klient bude používat stejné kódování jako server. A když už tam takový předpoklad zadrátuješ, tak bys to měl napsat do dokumentace.

[kralyk z abclinuxu]

To bych neřešil... Jednak si myslim, že budeš mít dost problém najít kódování, které se vejde se do charu a ve kterém '0'+1 != '1'; ale hlavně ve chvíli, kdy chceš v C podporovat všelijaká kódování, použiješ nějakou knihovnu jako ICU nebo něco takového místo blbinek s charem...

[Michal Kubeček]

Když už tu byla řeč o napovídání překladači a dělání práce za optimalizátor, zkusil jsem přeložit

char b1(unsigned int n)
{
        unsigned int i = n % 2;

        return i ? '1' : '0';
}

char b2(unsigned int n)
{
        unsigned int i = n & 1;

        return '0' + i;
}

pomocí gcc6 a výsledek je

0000000000000000 <b1>:
   0:   83 e7 01                and    $0x1,%edi
   3:   8d 47 30                lea    0x30(%rdi),%eax
   6:   c3                      retq   
   7:   66 0f 1f 84 00 00 00    nopw   0x0(%rax,%rax,1)
   e:   00 00 

0000000000000010 <b2>:
  10:   83 e7 01                and    $0x1,%edi
  13:   8d 47 30                lea    0x30(%rdi),%eax
  16:   c3                      retq   

Závěr: nekomplikujme si život a nesnažme se za překladač dělat jeho práci, pokud k tomu nemáme opravdu dobrý důvod. I když totiž občas zašmodrcháním kódu opravdu nějaký takt získáme, zdaleka ne vždy to bude mít měřitelný efekt, zato tím spolehlivě naštveme toho, kdo po nás ty mikrooptimalizace bude muset luštit (nezřídka sami sebe).

Zajímavé je, že gcc 4.8 přeloží první funkci jako

0000000000000000 <b1>:
   0:   83 e7 01                and    $0x1,%edi
   3:   83 ff 01                cmp    $0x1,%edi
   6:   19 c0                   sbb    %eax,%eax
   8:   83 c0 31                add    $0x31,%eax
   b:   c3                      retq   
   c:   0f 1f 40 00             nopl   0x0(%rax)

tj. překladač ještě není dost chytrý, aby si uvědomil, že výsledek první operace může být jen 0 nebo 1, ale je dost chytrý na to, aby využil toho, že '1' je hned za '0', a vyhnul se podmíněnému skoku.

[kralyk z abclinuxu]

Zajímavé. Koukl jsem se, co stím dělá clang:

b1(unsigned int):                                 # @b1(unsigned int)
        andb    $1, %dil
        orb     $48, %dil
        movl    %edi, %eax
        retq

b2(unsigned int):                                 # @b2(unsigned int)
        andl    $1, %edi
        leal    48(%rdi), %eax
        retq

... což je dost podivný. Zřejmě v první funkci eliminuje branch, ale z nějakýho důvodu už to nepřevede na lea.

[unicode]

Toto prelozi stejne. Clang z nejakeho duvodu pouziva nejak divne 8bitove registry...

char b1(unsigned int n)
{
        unsigned int i = n % 2;

        return i ? unsigned('1') : unsigned('0');
}

char b2(unsigned int n)
{
        unsigned int i = n & 1;

        return '0' + i;
}

[kralyk z abclinuxu]

To je ale kod jak z roku 1980, thread safety, nic?

1980? Kéžby. Spousta těhle interpreterů skritovacích jazyků jsou stále víceméně napsány s předpokladem, že kód poběží v zásadě single-threaded. PHP, JavaScript, CPython, ...

[unicode]

U toto JS zalezi na VM, treba V8 uz snad kompletne opustil TLS a jeden proces tech VM muze spustit klidne 100. Celkove nove API uz s TLS a konceptem globalniho kontextu (jak zname napriklad z OpenGL|OpenVG atd) nepocita, viz Vulkan, DirectX, atd.

[kozzi]

Tak proc by neslo?

import std.stdio;
void main()
{
	writefln("%b", 16);
}

[kozzi]

toto je priklad v D