Příspěvky

1336

Vývoj / Re:Násobení matic a automatické přetypování

« kdy: 17. 09. 2015, 17:51:04 »

Ehm ...
ved nasobenie matic je nejaka metoda/funkcia. V nej bude najprv volany konstruktor pre vytvorenie vyslednej matice a tam moze byt volany konstruktor podla toho ci vysledkom bude stvorcova matica alebo nie.
Napr. pre python nieco take:

Kód: [Vybrat]

class ObdlzMatica():
    def sucin(self, matica):
        if self.stlpce == matica.riadky:
            sucin = StvorMatica()
        else:
            sucin = ObdlzMatica()

        # Kod sucinu

        return sucin


class StvorMatica(ObdMatica):
    def determinant(self):
        pass

V dynamickém jazyce to půjde vždy, to je jasné. Tady se řeší staticky typovaný jazyk.

1337

Vývoj / Re:Násobení matic a automatické přetypování

« kdy: 17. 09. 2015, 17:49:33 »

To přece šlo vždycky, z násobení dostanete obecný prapředek Object a zeptáte se přes nějaké instanceof, zda máte jednu nebo druhou instanci a podle toho přetypujete a pokračujete dál.

Ono jde asi o to, jak to udělat bez instanceof a přetypování.

Ale to nejde udelat bez pretypovani! To vyplyva z jeho otazky. Chce z dvou obecnych matic dostat ctvercovou, ale jenom nekdy. Z toho plyne, ze bud:

• Zakoduje informaci o velikosti matice do typoveho systemu (pokud to vubec umoznuje).
• Pretypuje vysledek za behu.

To prvni asi nechce, jak jini napsali. Takze to musi pretypovat.

Je treba si uvedomit, ze typy v programovacich jazycich slouzi k (minimalne) trem rozdilnym ucelum. Z toho pak vyplyvaji tyto zmatky.

Pravě že ne. Třetí cesta je polymorfismus návratové hodnoty (jde to ve Swiftu, jinak nevím, kde ještě).

1338

Vývoj / Re:Násobení matic a automatické přetypování

« kdy: 17. 09. 2015, 17:32:43 »

To je ale zbytečné a navíc ekvivalentní explicitnímu přetypování. Čili bez možnosti polymorfismu návratové hodnoty to nejde.

Takže zavoláte (m1*m2).trace() a když to zbuchne na runtime error, tak víte že SquareMatrix se nekoná a pokračujete kódem pro Matrix

Když volám trace, tak vím, že jde o čtvercovou matici.

1339

Vývoj / Re:Násobení matic a automatické přetypování

« kdy: 17. 09. 2015, 16:21:49 »

Pochopitelně chyba za běhu, to jinak řešit nejde. Kdo explicitně použije trace, očekává čtvercovou matici.

Takže musíte vědět předem, jaké třídy bude výsledek. To je samozřejmě možné přes pomocnou metodu m1.MultiplyWillProduceSquare(m2), ale je to práce navíc.

To je ale zbytečné a navíc ekvivalentní explicitnímu přetypování. Čili bez možnosti polymorfismu návratové hodnoty to nejde.

1340

Vývoj / Re:Násobení matic a automatické přetypování

« kdy: 17. 09. 2015, 15:55:42 »

Lze to použít

Možná to lze to přeložit, ale nelze to použít v případě kdy výsledek operace nebude čtvercová matice. Pak se stane co ? Výjimka ? Runtime error ?

Pochopitelně chyba za běhu, to jinak řešit nejde. Kdo explicitně použije trace, očekává čtvercovou matici. Zajímavé by bylo implementovat "inverse", protože to jde i s nečtvercovou maticí.

1341

Vývoj / Re:Násobení matic a automatické přetypování

« kdy: 17. 09. 2015, 15:52:57 »

To by byl ten případ s (implicitním) přetypováním (operator SquareMatrix()), nicméně ani to mi neumožní napsat v C++ něco jako (m1*m2).trace() (na rozdíl od Swiftu).

Jo, v C++ by bylo třeba něco jako "square(m1*m2).trace()". To není zas tak zlé.

Je mi ovšem záhadou, proč to C# nepovolí.

1342

Vývoj / Re:Násobení matic a automatické přetypování

« kdy: 17. 09. 2015, 15:47:41 »

To přece šlo vždycky, z násobení dostanete obecný prapředek Object a zeptáte se přes nějaké instanceof, zda máte jednu nebo druhou instanci a podle toho přetypujete a pokračujete dál.

Ono jde asi o to, jak to udělat bez instanceof a přetypování.

Instanceof tam bude povinně, z důvodu že se mohou vrátit instance dvou různých nezávislých tříd a předem nevíme co se vrátí. (Teoreticky to v případě násobení matic vědět můžeme, ale tento případ se neuvažuje).

a když se použije (m1*m2).trace, tak se automaticky vybere druhá implementace, protože nečtvercová matice stopu nemá.

(m1*m2).trace nelze použít, protože dopředu nevíte co bude výsledkem operace. Když to nějakým způsobem budete umět odhadnout předem, pak samozřejmě ano.

Lze to použít, kdyby mi to nešlo přeložit, tak to sem nepíšu. Čili jde to i bez instanceof a explicitního přetypování.

1343

Vývoj / Re:Násobení matic a automatické přetypování

« kdy: 17. 09. 2015, 15:32:25 »

A je fakt nutné mít jiný typ (třídu) pro čtvercovou matici? Jinak, podobné věci umí třeba Scala.

Je to vhodné, ale nemusí od sebe dědit. Vlastně by to mělo být struct, a tam se dědit ani nedá.

1344

Vývoj / Re:Násobení matic a automatické přetypování

« kdy: 17. 09. 2015, 15:11:08 »

Mám třídy pro obecnou matici a čtvercovou matici. Násobení dvou obecných matic někdy dá čtvercovou matici. Lze v nějakém OO jazyce zajistit, abych v takovém případě dostal instanci čtvercové matice (aby šly použít metody dávající smysl jen pro čtvercovou matici)?

Asi bych to nekomplikoval. Násobení vrátí obdélníkovou matici a čtvercová se z ní udělá pomocí funkce co sežere tu obdélníkovou a vykrade jí vnitřnosti (drobně si uprav podle jazyka).

To by byl ten případ s (implicitním) přetypováním (operator SquareMatrix()), nicméně ani to mi neumožní napsat v C++ něco jako (m1*m2).trace() (na rozdíl od Swiftu).

1345

Vývoj / Re:Násobení matic a automatické přetypování

« kdy: 17. 09. 2015, 15:09:02 »

To se řeší buď implicitním přetypováním za běhu (v C++, C# to nesmyslně zakazuje) ...

Tak jednoznačně neodsuzoval. Mám pocit, že se častěji chytám do pasti, než že by mi to implicitní přetypování nějak často pomáhalo. I autoři C++ standardu si párkrát naběhli na vidle. Ta debata kam explicit patří a kam ne je celkem výživná.

BTW C# v tomto případě zakazuje i explicitní casting.

1346

Vývoj / Re:Násobení matic a automatické přetypování

« kdy: 17. 09. 2015, 14:59:24 »

To se řeší buď implicitním přetypováním za běhu (v C++, C# to nesmyslně zakazuje) ...

Tak jednoznačně neodsuzoval. Mám pocit, že se častěji chytám do pasti, než že by mi to implicitní přetypování nějak často pomáhalo. I autoři C++ standardu si párkrát naběhli na vidle. Ta debata kam explicit patří a kam ne je celkem výživná.

Jistě, ale zde by se právě dost hodilo.

1347

Vývoj / Re:Násobení matic a automatické přetypování

« kdy: 17. 09. 2015, 14:40:02 »

To se řeší buď implicitním přetypováním za běhu (v C++, C# to nesmyslně zakazuje), nebo v jazycích umožňujících mít stejnou metodu s různým návratovým typem nějakým vesměs nepěkným trikem. Ve Swiftu by bylo například

Kód: [Vybrat]

func *(m1:Matrix,m2:Matrix)->Matrix
func *(m1:Matrix,m2:Matrix)->SquareMatrix

a když se použije (m1*m2).trace, tak se automaticky vybere druhá implementace, protože nečtvercová matice stopu nemá.

Podobně, ale poněkud elegantněji, lze řešit problém dědičnosti funktorů; například diferenciální operátor bere tenzor a vrací něco jako MultidimensionalArrayWithUpperAndLowerIndices (ať žije čitelnost ), nicméně některé vrací zase tenzor. V C# a C++ pak můžu mít dva delegáty/funktory, které od sebe dědí, a pokud použiju například kovariantní nebo absolutní derivaci, lze s výsledkem pracovat jako s tenzorem bez přetypování. Obecně se takové věci ale řeší těžko, protože typový systém je záležitost doby kompilace, kdežto tady se bavíme o době běhu.

1348

Vývoj / Re:Násobení matic a automatické přetypování

« kdy: 17. 09. 2015, 14:01:28 »

To přece šlo vždycky, z násobení dostanete obecný prapředek Object a zeptáte se přes nějaké instanceof, zda máte jednu nebo druhou instanci a podle toho přetypujete a pokračujete dál.

Ono jde asi o to, jak to udělat bez instanceof a přetypování.

1349

Vývoj / Re:Omezená dědičnost (je něco lepšího než OOP?)

« kdy: 17. 09. 2015, 10:50:21 »

Tady ale směšuješ dvě různé věci. Defaultní metody v Javě slouží jednak k omezené vícenásobné dědičnosti a jednak k tomu, aby bylo možné bezpečně rozšiřovat interfacy, které jsou součástí veřejných API. Druhý bod byl Oraclem prezentován jako jejich hlavní selling point, tzn. že defaultní metody jim umožnili rozšířit do té doby zamrzlé API kolekcí. Sranda je to, že nakonec k tomu prakticky vůbec nedošlo a veškeré funkcionální operace se místo kolekcí dostaly do nového typu - streamů.

Extension metody v C# naproti tomu slouží k rozšiřování tříd, nad kterými nemám kontrolu (jsou součástí SDK, knihoven atd.) a to v Javě dodnes není možné. Proto např. Guava definuje spoustu statických tříd pojmenovaných plurálem třídy, nad kterou operují (Strings, Ints, Iterables, Lists atd.). Takže pak můžu dělat toto: Lists.filter(list, predicate), ale už ne tohle: list.filter(predicate).

Jenže v C# to jde i pro rozhraní.

Teď si asi nerozumíme. Jestli jde o třídu/rozhraní/trait/whatever je jedno. Rozdíl je v tom, že zatímco v Javě mohu defaultní metody umisťovat pouze do svého vlastního kódu, tak v C# lze extension metodami rozšiřovat i typy, které nevlastním.

Jinak řečeno, extension metody jsou nástroj jak pro autora API, tak pro jeho klienta, default metody naproti tomu pouze pro autora.

Jasně, mně se jen nelíbí, jak se to zapisuje. Ve Swiftu prostě napíšu "extension String ..." a v ObjC "@interface NSString ()" a můžu rozšiřovat. V C# by to mělo být něco jako "partial class ..." (a místo partial třeba extension). Je to jen syntax, ale teď je to nelogické.

1350

Vývoj / Re:Omezená dědičnost (je něco lepšího než OOP?)

« kdy: 16. 09. 2015, 17:27:35 »

https://developer.apple.com/videos/wwdc/2015/?id=408

Když uz jsme u toho, nevíte někdo, proč v C# udělali tak debilně extension methods v cizích statických třídách?

A v čem je to debilní, resp. jak by to mělo být?

Má to být přímo v tom rozhraní, jako v Javě.

Java nemá extension metody vůbec, ta má jen defaultní metody, ne? Navíc u defaultních metod musíte mít možnost rozhraní měnit (tj. přístup k jeho kódu).

Extension metody v C# jsou jen syntaktický cukr - kdyby mělo jít rozšířit existující rozhraní (bez možnosti ho přímo měnit - např. rozhraní z jiné assembly) nebo implementovat rozhraní pro existující třídu (bez možnosti ji přímo měnit), vyžadovalo by to změny v CLR (případně obejít CLR).

Výhodou stávajícího řešení je, že můžete mít více implementací jedné extension metody a není třeba měnit CLR.

BTW může třída ve Swiftu mít více implementací jednoho protokolu?

Může mít více implementací jedné metody.