Bitové operace ve vyšších jazycích

[Kiwi]

Právě protože nejsem lopata, tak řeším řádově složitější problémy. A bitové posuny jsou asi cool, ale tak před 30 lety. Dneska máš daleko zajímavější problémy a bez bitových posunů se můžeš klidně obejít. Jen aby z toho někdo nedělal nějaké základy, které je potřeba umět.

 
Například jaké? Ať se taky trochu pobavíme... 

[Reklama]

[Kolemjdoucí]

velmi jednoduchy priklad na vyuzitie bitovych operacii vo vyssich jazykoch...

nejaka vec ma 40 priznakov true/false a tych veci je 20 milionov riadkov v databaze
a truhlik tam spravil 20 stlpcov s hodnotou true/false  -  pri ceste ku service sa to kade-tade serializuje + EntityFramework a podobne takze ten overhead je masivny...
namiesto 1 stlpca s cislom (nie, nefiltruje sa podla tych priznakov, su pouzite cisto len pri zobrazeni)

Na to mu bude skvěle fungovat dotazování s využitím indexu.

No to samozřejmě bude, ale jen pokud udělá správný index (pomocí funkce která bude pracovat s příslušnými bity).

[gl]

velmi jednoduchy priklad na vyuzitie bitovych operacii vo vyssich jazykoch...

nejaka vec ma 40 priznakov true/false a tych veci je 20 milionov riadkov v databaze
a truhlik tam spravil 20 stlpcov s hodnotou true/false  -  pri ceste ku service sa to kade-tade serializuje + EntityFramework a podobne takze ten overhead je masivny...
namiesto 1 stlpca s cislom (nie, nefiltruje sa podla tych priznakov, su pouzite cisto len pri zobrazeni)

Na to mu bude skvěle fungovat dotazování s využitím indexu.

No to samozřejmě bude, ale jen pokud udělá správný index (pomocí funkce která bude pracovat s příslušnými bity).

Tohle v mysql AFAIK nejde. Navíc tím moc místa neušetříš.

[gl]

Pro práci s IP a RGB se používají knihovny, často implementované v C. Množiny jsou součástí jazyka. Neříkám, že bitové operace není dobré znát, ale ve spoustě oborů se s nimi člověk nesetká.

Obecné množiny (které jsou IMHO v Pythonu reprezentovány jako normální dict s dummy hodnotami) jsou něco jiného než množiny reprezentované binárně. Ty uměl starý (ne-dobrý :-) Pascal. Takže při požadavku na efektivní reprezentaci a složitost všech operací O(1) to stejně někdo musí naprgat, ať již v C či v Pythonu. Opět  = někdo tady zmínil BitSet, to je Javovina a ta třída existuje, protože se to používá. Ne denodenně ale používá.

Složitost jakých všech operací je O(1)? Nezáleží to na velikosti domény? Pokud pracuji s malými množinami nad velkou doménou, tak je reprezentace hash tabulkou efektivnější a téměř vždy dostatečně efektivní. Ty pascalovské množiny mají jen dost omezené použití.

[Kit]

Složitost jakých všech operací je O(1)? Nezáleží to na velikosti domény? Pokud pracuji s malými množinami nad velkou doménou, tak je reprezentace hash tabulkou efektivnější a téměř vždy dostatečně efektivní. Ty pascalovské množiny mají jen dost omezené použití.

Pascalovské množiny se běžně používají v souborových systémech pro mapování volných clusterů.

[Reklama]

[v]

prý nízkoúrovňové OMG to je dělění taky, ne? a otázka na papíře co je výsledkem výpočtu 1/0 je taky, blbost, ne? někteří tady jsou fakt lopaty

[Kolemjdoucí]

velmi jednoduchy priklad na vyuzitie bitovych operacii vo vyssich jazykoch...

nejaka vec ma 40 priznakov true/false a tych veci je 20 milionov riadkov v databaze
a truhlik tam spravil 20 stlpcov s hodnotou true/false  -  pri ceste ku service sa to kade-tade serializuje + EntityFramework a podobne takze ten overhead je masivny...
namiesto 1 stlpca s cislom (nie, nefiltruje sa podla tych priznakov, su pouzite cisto len pri zobrazeni)

Na to mu bude skvěle fungovat dotazování s využitím indexu.

No to samozřejmě bude, ale jen pokud udělá správný index (pomocí funkce která bude pracovat s příslušnými bity).

Tohle v mysql AFAIK nejde. Navíc tím moc místa neušetříš.

Ale jde, jen jak je již v MySQL tradicí tak se to dělá trochu jinak: http://mysqlserverteam.com/generated-columns-in-mysql-5-7-5/

Pokud si nemůžete dovolit použít víc místa kvůli zrychlení přístupu k datům tak máte problém.

[gl]

velmi jednoduchy priklad na vyuzitie bitovych operacii vo vyssich jazykoch...

nejaka vec ma 40 priznakov true/false a tych veci je 20 milionov riadkov v databaze
a truhlik tam spravil 20 stlpcov s hodnotou true/false  -  pri ceste ku service sa to kade-tade serializuje + EntityFramework a podobne takze ten overhead je masivny...
namiesto 1 stlpca s cislom (nie, nefiltruje sa podla tych priznakov, su pouzite cisto len pri zobrazeni)

Na to mu bude skvěle fungovat dotazování s využitím indexu.

No to samozřejmě bude, ale jen pokud udělá správný index (pomocí funkce která bude pracovat s příslušnými bity).

Tohle v mysql AFAIK nejde. Navíc tím moc místa neušetříš.

Ale jde, jen jak je již v MySQL tradicí tak se to dělá trochu jinak: http://mysqlserverteam.com/generated-columns-in-mysql-5-7-5/

Pokud si nemůžete dovolit použít víc místa kvůli zrychlení přístupu k datům tak máte problém.

Co mi to přinese oproti separátním sloupcům?

[Kolemjdoucí]

velmi jednoduchy priklad na vyuzitie bitovych operacii vo vyssich jazykoch...

nejaka vec ma 40 priznakov true/false a tych veci je 20 milionov riadkov v databaze
a truhlik tam spravil 20 stlpcov s hodnotou true/false  -  pri ceste ku service sa to kade-tade serializuje + EntityFramework a podobne takze ten overhead je masivny...
namiesto 1 stlpca s cislom (nie, nefiltruje sa podla tych priznakov, su pouzite cisto len pri zobrazeni)

Na to mu bude skvěle fungovat dotazování s využitím indexu.

No to samozřejmě bude, ale jen pokud udělá správný index (pomocí funkce která bude pracovat s příslušnými bity).

Tohle v mysql AFAIK nejde. Navíc tím moc místa neušetříš.

Ale jde, jen jak je již v MySQL tradicí tak se to dělá trochu jinak: http://mysqlserverteam.com/generated-columns-in-mysql-5-7-5/

Pokud si nemůžete dovolit použít víc místa kvůli zrychlení přístupu k datům tak máte problém.

Co mi to přinese oproti separátním sloupcům?

Rychlejší mapování do aplikace - přes ORM půjde jen ten jeden sloupec který si pak v aplikaci rozložíte na jednotlivé bity. Indexy si naděláte jen nad těmi bity (nebo kombinacemi bitů) kde budou doopravdy potřeba, jen tam to bude brát víc místa (jak je u indexů obvyklé).

[Kit]

Ale jde, jen jak je již v MySQL tradicí tak se to dělá trochu jinak: http://mysqlserverteam.com/generated-columns-in-mysql-5-7-5/

Pokud si nemůžete dovolit použít víc místa kvůli zrychlení přístupu k datům tak máte problém.

Co mi to přinese oproti separátním sloupcům?

Rychlejší mapování do aplikace - přes ORM půjde jen ten jeden sloupec který si pak v aplikaci rozložíte na jednotlivé bity. Indexy si naděláte jen nad těmi bity (nebo kombinacemi bitů) kde budou doopravdy potřeba, jen tam to bude brát víc místa (jak je u indexů obvyklé).

Podle mne je jednodušší použití databázové množiny. Tedy v případě neklíčových atributů.

BTW: K čemu ORM?

[gl]

velmi jednoduchy priklad na vyuzitie bitovych operacii vo vyssich jazykoch...

nejaka vec ma 40 priznakov true/false a tych veci je 20 milionov riadkov v databaze
a truhlik tam spravil 20 stlpcov s hodnotou true/false  -  pri ceste ku service sa to kade-tade serializuje + EntityFramework a podobne takze ten overhead je masivny...
namiesto 1 stlpca s cislom (nie, nefiltruje sa podla tych priznakov, su pouzite cisto len pri zobrazeni)

Na to mu bude skvěle fungovat dotazování s využitím indexu.

No to samozřejmě bude, ale jen pokud udělá správný index (pomocí funkce která bude pracovat s příslušnými bity).

Tohle v mysql AFAIK nejde. Navíc tím moc místa neušetříš.

Ale jde, jen jak je již v MySQL tradicí tak se to dělá trochu jinak: http://mysqlserverteam.com/generated-columns-in-mysql-5-7-5/

Pokud si nemůžete dovolit použít víc místa kvůli zrychlení přístupu k datům tak máte problém.

Co mi to přinese oproti separátním sloupcům?

Rychlejší mapování do aplikace - přes ORM půjde jen ten jeden sloupec který si pak v aplikaci rozložíte na jednotlivé bity. Indexy si naděláte jen nad těmi bity (nebo kombinacemi bitů) kde budou doopravdy potřeba, jen tam to bude brát víc místa (jak je u indexů obvyklé).

máš pravdu. V některých případech to asi bude lepší.

[gl]

Ale jde, jen jak je již v MySQL tradicí tak se to dělá trochu jinak: http://mysqlserverteam.com/generated-columns-in-mysql-5-7-5/

Pokud si nemůžete dovolit použít víc místa kvůli zrychlení přístupu k datům tak máte problém.

Co mi to přinese oproti separátním sloupcům?

Rychlejší mapování do aplikace - přes ORM půjde jen ten jeden sloupec který si pak v aplikaci rozložíte na jednotlivé bity. Indexy si naděláte jen nad těmi bity (nebo kombinacemi bitů) kde budou doopravdy potřeba, jen tam to bude brát víc místa (jak je u indexů obvyklé).

Podle mne je jednodušší použití databázové množiny. Tedy v případě neklíčových atributů.

BTW: K čemu ORM?

Řekl bych, že množina se ukládá stejně a snáz se používá. Opravdu je to lepší a nemusím řešit bitové operace.

[javaman ((]

BTW: K čemu ORM?

Jak jinak bys to chtěl automaticky mapovat?

[gl]

BTW: K čemu ORM?

Jak jinak bys to chtěl automaticky mapovat?

Mapovat co? Já používám ORM hlavně abych nemusel stále dokola psát ty stejné podmínky joinů.

[javaman ((]

Tak máš objekty a vůbec tě nezajímá, že je to v DB. Nemyslím doslova, ale skoro všechen kód už byl napsaný, takže máš jen modely a pár detailů. Vše ostatní zařídí někdo za tebe. Na složitější věci to není tak růžové, ale ty většina lidí stejně nikdy dělat nebude.