Zobrazit příspěvky

Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.


Příspěvky - linuxak

Stran: 1 2 [3] 4 5
31
Vývoj / Re:C++ Appendovanie parameter packs
« kdy: 07. 08. 2021, 02:51:17 »
Co třeba něco takového?
Kód: [Vybrat]
#include <any>
#include <vector>

class PackClass
{
private:
    std::vector<std::any> m_values;

public:
    template <typename... Args>
    PackClass(Args&& ...args)
        :m_values(args...)
    {
    }
   
    template<typename T>
    PackClass(std::vector<std::any> values, T value)
        :m_values(std::move(values))
    {
        m_values.emplace_back(value);
    }

    template<typename T>
    PackClass Append(T value) const
    {
        return PackClass(m_values, value);
    }
};

32
Studium a uplatnění / Re:Zlepšení znalosti matematiky - CBT
« kdy: 09. 05. 2021, 16:08:28 »
Ono to stejně souvisí.
Jasný, no, je to přístup z jiné strany a postupně se potkají uprostřed :)

BTW, když už jsme u toho, máš povědomí o tom, jak na tom dneska ta formální lingvistika je? IIRC někdy v šedesátých a devadesátých (?) letech se myslelo, že stačí "jenom" přirozený jazyk přepsat do logiky a překlad jazyků bude skoro zadarmo. To se asi ukázalo jako dost slepá větev a dneska je v kurzu spíš jít na to přes strojové učení, ne?
Mám. Většina teorií dělá blbě už to “přepsat do logiky.” Překlad se dělá neuronkama, ale různé analýzy (Siri, IBM Watson) jsou založené na pravidlech. I správně udělaný přepis do logiky je ale k ničemu bez rozsáhlé ontologie, to je asi největší problém těchto přístupů.
K tomu je nutné dodat, že Watson je 10 let starý koncept, za tu dobu se v NLP stalo strašně moc. Aktuálně v NLP všechno válcují neuronky, konkrétně BERT a jeho deriváty, což je model založený ná sémantické reprezantaci textu jako vektoru. Kdyby se Watson (i Siri) dělaly dnes, asi by vypadaly úplně jinak.

33
Server / Re:Databáze - 300 GB tabulka
« kdy: 13. 03. 2021, 21:22:45 »
Na takové úlohy mám dobrou zkušenost s LMDB, je to okleštěná databáze, v podstatě jen b-tree, ale killer feature je, že to funguje nad mmapovaným souborem, stovky GB dat to zvládá docela dobře: http://www.lmdb.tech/doc/

34
Vývoj / Re:Práce s vlákny v C
« kdy: 25. 01. 2021, 20:41:06 »
Rozjela se tady docela flamewar. Moc teda nechápu proč, go skutečně negarantuje, že v programu není data race. Pokud chci takové garance, musím sáhnout jinam.

35
Vývoj / Re:Práce s vlákny v C
« kdy: 19. 01. 2021, 16:54:13 »
Ptal jsem se na to jestli ten muj prilozenej kod bude fungovat korektne.
Nebude fungovat korektně, máš tam data race a helgrind ti to řekne. K proměnné thread_var přistupuješ z více vláken bez synchronizace.
Kód: [Vybrat]
g++ -lpthread -o test -g main.cc
valgrind --tool=helgrind ./test

==5579== Possible data race during read of size 8 at 0x10C048 by thread #1
==5579== Locks held: none
==5579==    at 0x1091AF: init_function(void*) (main.cc:37)
==5579==    by 0x10917F: main (main.cc:17)
==5579==
==5579== This conflicts with a previous write of size 8 by thread #2
==5579== Locks held: none
==5579==    at 0x109232: handle_function(void*) (main.cc:58)
==5579==    by 0x483C8B6: ??? (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_helgrind-amd64-linux.so)
==5579==    by 0x4886FA2: start_thread (pthread_create.c:486)
==5579==    by 0x4CBA4CE: clone (clone.S:95)
==5579==  Address 0x10c048 is 0 bytes inside data symbol "_ZL10thread_var"

36
Vývoj / Re:prace s vlakny v C
« kdy: 18. 01. 2021, 21:44:22 »
Jinak ta proměnná by měla být pokud se nepletu volatile
Volatile použité na sychronizaci v multithread aplikaci je vždy chyba. Volatile zaručuje jen to, že se vykoná čtení/zápis z paměti a ne z registru, ale z hlediska sychronizace mezi vlákny je to prakticky k ničemu. Není tam žádná memory bariéra, není zaručena atomicita, CPU může udělat read/write reorediring na HW úrovni... Je třeba používat standardní sychronizační primitiva (mutex), které všechno tohle řeší, volatile určitě ne.

37
Musíš mít jasno v tom, jestli učíš klasifikátor, nebo regresor. Používáš metriku accuracy, která funguje jen pro klasifikační úlohy. Zároveň používáš modely, které nedělají klasifikaci, ale regresi. Jestli má být model klasifikátor nebo regresor, záleží na typu úlohy a musíš si to rozhodnout sám, nikdo to za tebe neudělá. Jsou to úplné základy, doporučuju začít studium např. tady: https://machinelearningmastery.com/classification-versus-regression-in-machine-learning/

38
Vývoj / Re:C++ - Filter pattern
« kdy: 19. 12. 2020, 20:06:07 »
Pokud chceš filtr, který se bude dynamicky rozhodovat podle více možných typů vstupu, tak můžeš použít třeba std::variant.

39
Cisco to umí, označuje to jako DTPC (dynamic transmit power control). Bežně se to ale asi moc nepoužívá.
Primárně to není cíleno na úsporu energie, ale na zlepšení služby s ohledem na kvalitu přenosu. Když se vysílá menším výkonem, dochází k menším interferencím v okolních sítích.

40
Vývoj / Re:Type trait na zistenie stringových typov
« kdy: 19. 10. 2020, 11:31:36 »
Pokud děláš logger ze studijních důvodů, tak nic proti tomu.

Pokud děláš logger, který máš v plánu použít v nějakém produkčním kódů, tak to silně nedoporučuju, je to obtížnější úloha, než jak na první pohled vypadá. V takovém případě bych doporučil použít nějaké hotové řešení, např. boost log nebo glog.

41
Vývoj / Re:C++ funkcionálny typ
« kdy: 10. 09. 2020, 04:35:14 »
Kód: [Vybrat]
template<typename T1, typename T2> using Mapper = std::function<T2(T1)>;
To je všechno. Kdyby tě zajímalo, tak to uvnitř funguje, tak klíčová fráze je type erasure.

42
Vývoj / Re:C++ načo slúži constexpr?
« kdy: 29. 08. 2020, 02:38:08 »
constexpr je mnohem mocnější než makra, od C++20 jsou constexpr i standardní algoritmy, např. std::sort, takže je možné vyrobit v compile time třeba seřazené pole. Přidej si tam -O2 a z celého kódu se stane jedna instrukce.

43
Vývoj / Re:C++ stack vs heap.
« kdy: 08. 08. 2020, 07:42:24 »
Se standardní knihovnou a initializer listem kratší syntax neuděláš, můžeš ale použít variadické šablony a udělat třeba tohle:
Kód: [Vybrat]
template <typename T, typename... Args>
std::shared_ptr<std::vector<T>> make_shared_vector(Args&&... args)
{
    auto vec = std::make_shared<std::vector<T>>();
    vec->reserve(sizeof...(Args));
    (vec->emplace_back(std::forward<Args>(args)), ...);
    return vec;
}

int main()
{
    auto vec = make_shared_vector<char>('a', 'b', 'c');
    return 0;
}
Tohle používá fold expression a potřebuje C++17, ale jsou možné i jiné varianty, tady najdeš víc možností, jak to udělat: https://tristanbrindle.com/posts/beware-copies-initializer-list

44
Vývoj / Re:C++ stack vs heap.
« kdy: 07. 08. 2020, 20:55:56 »
Vektor je kontajner, který podporuje dynamickou změnu velikosti, což na stacku prakticky nejde udělat. Z důvodů možné realokace musí být vektor implementovaný tak, že data drží na heapu. Se stackem se pracuje jinak než s heap pamětí a má omezenou velikost, doporučuju nastudovat https://en.wikipedia.org/wiki/Call_stack

45
Vývoj / Re:Dalsi, UZ POSLEDNI KIKS V PYTHONU
« kdy: 01. 04. 2020, 11:52:21 »
JSON zachovava poradi klicu, a proto kdyz mam knihovnu ktera deserializuje JSON, tak to MUSI TA KNIHOVNA ctit.

Kam na ty nesmysly chodíš? Co takhle si přečíst třeba JSON standard?

An object is an unordered set of name/value pairs.

Stran: 1 2 [3] 4 5