Programátorský úkol

[Aoidhghean]

Píšu tak, aby byl kód bezpečný. Zvlášť když vector není pomalejší než raw pole. Ostatně v tom stupidním kódu je chyba právě ve správě paměti, pro pole se používá delete[].

Ved som povedal, ze su tam chyby, ale islo mi o jednoduchost, spatne zmenit to uz neviem. Kazdopadne algoritmus samotny funguje, je najrychlejsi a pouziva najmenej pamate z tu zverejnenych. Pises tu vacsinou v tomto vlakne techicky dobre veci, ale preco si sa namiesto normalnej kritiky priklonil k arogancii to je len o tebe...

Třeba mi vadí, když někdo neuzná chybu. Nejde o delete[], ale o fakt explicitního použití new. Ovšem je na každém, chce-li se poučit z vlastních chyb, na než byl upozorněn.

[Reklama]

[mon]

Píšu tak, aby byl kód bezpečný. Zvlášť když vector není pomalejší než raw pole. Ostatně v tom stupidním kódu je chyba právě ve správě paměti, pro pole se používá delete[].

Ved som povedal, ze su tam chyby, ale islo mi o jednoduchost, spatne zmenit to uz neviem. Kazdopadne algoritmus samotny funguje, je najrychlejsi a pouziva najmenej pamate z tu zverejnenych. Pises tu vacsinou v tomto vlakne techicky dobre veci, ale preco si sa namiesto normalnej kritiky priklonil k arogancii to je len o tebe...

Třeba mi vadí, když někdo neuzná chybu. Nejde o delete[], ale o fakt explicitního použití new. Ovšem je na každém, chce-li se poučit z vlastních chyb, na než byl upozorněn.

Mas pravdu, ze raw pointer a takyto explicitny new nie je vacsinou spravna cesta pre normalne projekty. Ale na druhu stranu, nie vzdy mas stl alebo smart pointer, kazdy c/c++ projekt ma svoje specifika a pravidla, niekto stl, niekto ma tie smart pointre, niekto ma gc, niekto ma overloadnuty new operator a vlastne alokatory, niekto pouziva inplace new, videl som vela projektov a kazdy to mal inak, ja som volil citatelnost a mi to prislo mi to citalnejsie ako stl alebo malloc.

[O.]

Nemel jsem uplne cas cist cele vlakno, jak je tedy slozitost reseni v big O notaci pro to "otaceci" reseni?

[Aoidhghean]

Píšu tak, aby byl kód bezpečný. Zvlášť když vector není pomalejší než raw pole. Ostatně v tom stupidním kódu je chyba právě ve správě paměti, pro pole se používá delete[].

Ved som povedal, ze su tam chyby, ale islo mi o jednoduchost, spatne zmenit to uz neviem. Kazdopadne algoritmus samotny funguje, je najrychlejsi a pouziva najmenej pamate z tu zverejnenych. Pises tu vacsinou v tomto vlakne techicky dobre veci, ale preco si sa namiesto normalnej kritiky priklonil k arogancii to je len o tebe...

Třeba mi vadí, když někdo neuzná chybu. Nejde o delete[], ale o fakt explicitního použití new. Ovšem je na každém, chce-li se poučit z vlastních chyb, na než byl upozorněn.

Mas pravdu, ze raw pointer a takyto explicitny new nie je vacsinou spravna cesta pre normalne projekty. Ale na druhu stranu, nie vzdy mas stl alebo smart pointer, kazdy c/c++ projekt ma svoje specifika a pravidla, niekto stl, niekto ma tie smart pointre, niekto ma gc, niekto ma overloadnuty new operator a vlastne alokatory, niekto pouziva inplace new, videl som vela projektov a kazdy to mal inak, ja som volil citatelnost a mi to prislo mi to citalnejsie ako stl alebo malloc.

Mám za to, že STL je standard a předpokládá se, ale budiž, nechci se hádat, jen bych u jednoduchého prototypického příkladu očekával “štábní kulturu”. V C++11/14/17 je vše potřebné pro vytvoření hezkého kódu. Možná jako cvičení by stálo za to přepsat tu haskellí verzi do (víceméně funkcionálního) C++.

[Aoidhghean]

Nemel jsem uplne cas cist cele vlakno, jak je tedy slozitost reseni v big O notaci pro to "otaceci" reseni?

O(n) (při použití náhledů)

[Reklama]

[O.]

Nemel jsem uplne cas cist cele vlakno, jak je tedy slozitost reseni v big O notaci pro to "otaceci" reseni?

O(n) (při použití náhledů)

Tak to asi tezko, kdyz jenom projit vsechny prvky ctvercove matice trva O(n^2), pripadne O(m*n) u nectvercove

Co jsou to ty nahledy?

[Aoidhghean]

Nemel jsem uplne cas cist cele vlakno, jak je tedy slozitost reseni v big O notaci pro to "otaceci" reseni?

O(n) (při použití náhledů)

Tak to asi tezko, kdyz jenom projit vsechny prvky ctvercove matice trva O(n^2), pripadne O(m*n) u nectvercove

Co jsou to ty nahledy?

Jenže tady někdo zavedl, že n je počet prvků (a chybně tvrdil, že ten algoritmus je kvadratický). Doporučuju zjistit kontext před psaním.

[O.]

Nemel jsem uplne cas cist cele vlakno, jak je tedy slozitost reseni v big O notaci pro to "otaceci" reseni?

O(n) (při použití náhledů)

Tak to asi tezko, kdyz jenom projit vsechny prvky ctvercove matice trva O(n^2), pripadne O(m*n) u nectvercove

Co jsou to ty nahledy?

Jenže tady někdo zavedl, že n je počet prvků (a chybně tvrdil, že ten algoritmus je kvadratický). Doporučuju zjistit kontext před psaním.

No tak to si myslim, ze zavedl chybne. To taky muzu rict, ze algoritmus je O(1), protoze na vstupu je 1 matice (kdyz to prezenu )
Me prave zajimala ta slozitost maticovych operaci.....

[aaa]

Nemel jsem uplne cas cist cele vlakno, jak je tedy slozitost reseni v big O notaci pro to "otaceci" reseni?

Ked su strany tej matice a,b a a<b, tak O(a²b). Teda vzhladom k poctu prvkov pre stvorec O(n^3/2), ako sem uz niekto spravne napisal.
Vychadzal som z toho, ze pri obracani matice operacia trva konstantny cas na kazdy zostavajuci prvok, potom uz iba matika.

[Aoidhghean]

Nemel jsem uplne cas cist cele vlakno, jak je tedy slozitost reseni v big O notaci pro to "otaceci" reseni?

O(n) (při použití náhledů)

Tak to asi tezko, kdyz jenom projit vsechny prvky ctvercove matice trva O(n^2), pripadne O(m*n) u nectvercove

Co jsou to ty nahledy?

Jenže tady někdo zavedl, že n je počet prvků (a chybně tvrdil, že ten algoritmus je kvadratický). Doporučuju zjistit kontext před psaním.

No tak to si myslim, ze zavedl chybne. To taky muzu rict, ze algoritmus je O(1), protoze na vstupu je 1 matice (kdyz to prezenu )
Me prave zajimala ta slozitost maticovych operaci.....

Zavedl to korektně, je to prostě parametr pro analýzu, jen se to musí říct. Když budu chtít O vzhledem k n x m (tak jsem to původně chápal i já), bude to O(nm).

[Aoidhghean]

Nemel jsem uplne cas cist cele vlakno, jak je tedy slozitost reseni v big O notaci pro to "otaceci" reseni?

Ked su strany tej matice a,b a a<b, tak O(a²b). Teda vzhladom k poctu prvkov pre stvorec O(n^3/2), ako sem uz niekto spravne napisal.
Vychadzal som z toho, ze pri obracani matice operacia trva konstantny cas na kazdy zostavajuci prvok, potom uz iba matika.

V naivní implementaci O(n**3/2), v optimální O(n), resp. O(ab), jak už tu bylo vysvětleno asi třikrát.

[JardaP .]

Hm, tohle byl zcela trivialni ukol. Jesteze to neni treba o naprogramovani piskvorku, to by si urcite vyzadalo alespon tri vedecka sympozia.

[aaa]

Nemel jsem uplne cas cist cele vlakno, jak je tedy slozitost reseni v big O notaci pro to "otaceci" reseni?

Ked su strany tej matice a,b a a<b, tak O(a²b). Teda vzhladom k poctu prvkov pre stvorec O(n^3/2), ako sem uz niekto spravne napisal.
Vychadzal som z toho, ze pri obracani matice operacia trva konstantny cas na kazdy zostavajuci prvok, potom uz iba matika.

V naivní implementaci O(n**3/2), v optimální O(n), resp. O(ab), jak už tu bylo vysvětleno asi třikrát.

Pytal sa na otacacie riesenie. Ze pri nahladoch sa nic neotaca, meni sa iba pohlad na data.

[Aoidhghean]

Hm, tohle byl zcela trivialni ukol. Jesteze to neni treba o naprogramovani piskvorku, to by si urcite vyzadalo alespon tri vedecka sympozia.

Snad “piškvorek”, nebo si už pleteš i rody?

[Aoidhghean]

Nemel jsem uplne cas cist cele vlakno, jak je tedy slozitost reseni v big O notaci pro to "otaceci" reseni?

Ked su strany tej matice a,b a a<b, tak O(a²b). Teda vzhladom k poctu prvkov pre stvorec O(n^3/2), ako sem uz niekto spravne napisal.
Vychadzal som z toho, ze pri obracani matice operacia trva konstantny cas na kazdy zostavajuci prvok, potom uz iba matika.

V naivní implementaci O(n**3/2), v optimální O(n), resp. O(ab), jak už tu bylo vysvětleno asi třikrát.

Pytal sa na otacacie riesenie. Ze pri nahladoch sa nic neotaca, meni sa iba pohlad na data.

To je pořád otáčecí řešení - jde o sémantiku (x ++ snail $ rotate xs).