[Dune] Kleine ?nderungen an der Schnittstelle

[Oliver Sander]

>> Umgekehrt braucht man aber ein Array f?r jeden vorhandenen
>> GeometryType.  Und bei jeder Umrechnung mu? man erst in einer
>> map nachschauen, welches Array jetzt verwendet werden soll:
>>
>>     std::map<GeometryType,std::vector<int> > umrechnungsmap;
>>     const std::vector<int>& umrechnungsarray =
>>     umrechnungsmap.find(entity->type()).second;
>>     B-Index = umrechnungsarray[A-Index];
>
> Dein Rechenaufwand ist O(1) und Dein Speicheraufwand ist
> O(1). Natürlich hast Du hier einen Zusatzaufwand, jedoch ist der
> unabhängig von Deiner Gittergröße.

Der Rechenaufwand ist natürlich in beiden Fällen O(1), aber mir
geht es um die Konstante.  So wie ich obiges Beispiel geschrieben
habe ist dort der Speicheraufwand auch O(n), weil ja die Summe
der Längen der Umrechnungsarrays wieder n ist.  Ich habe aller-
dings übersehen, daß man die Indizes auch errechnen kann,
(dämlich, so ist es in meiner lokalen Implementierung ja auch
gemacht)
also

>>     std::map<GeometryType, int> umrechnungsoffsets;
>>     B-Index = A-Index + umrechnungsoffset[entity->type()];

Also wirklich O(1) Speicher.  Punkt gegen mich.  Da ist man
dann schnell bei
>
> Man kann zusätzlich noch die Abfrage beschleunigen, indem man zwei
> verschachtelte Vektoren verwendet:
>
>   std::vector< std::vector<int> > codimGeomOffset;
>   offset = codimGeomOffset[Entity::codim]
>                           [static_cast<BasicGeometryType>(entity->type())];
>   B-Index = A-Index + offset;
>

Und dann ist es wohl wirklich Geschmacksfrage, ob man lieber mehr
Speicher oder mehr Zeit verbrät.  Ich ziehe hiermit meinen Antrag
zurück.

Oliver