🚀 go-pugleaf

Aquila <braempje@netscape.net> wrote:
> Arnold Hendriks wrote:
> 
>> Als je je operator bijvoorbeeld als turning < state.turning definieert,
>> dan zou de compare wel moeten werken. Nu de compare niet strict is, deugt
>> de sortering niet en dat kan best verklaren waarom de find() functie niet
>> goed werkt.
> 
> Je hebt gelijk, ik had daar een < moeten gebruiken. Nu ben ik er nog niet
> want dat was een (domme) vereenvoudiging. Normaal bestaat possiblestate uit
> een positie pos, een direction dir en een boolean turning. Maar ik wil dat
> die laatste 2 genegeerd worden want dat mag in die map geen verschil maken.
> Dus heb ik:
> bool PossibleState::operator<(const PossibleState & state) const{
> return (getPos().x < state.getPos().x) || (getPos().y < state.getPos().y);
> }
> Is dat ook verkeerd met die strict weak ordering? Ik heb eens gekeken op
> <http://www.sgi.com/tech/stl/StrictWeakOrdering.html> en dan zou ik niet
> voldoen aan antisymmetrie: (4,4) < (4,4) is false maar het omgekeerde is
> niet true zoals ge?ist...
> 
> Bedankt voor uw hulp!

Die antisymmetrie geldt enkel voor over verschillende waarden, als ze
gelijk zijn geldt de irreflixitiviteitsregel.

Ik heb de oorspronkelijke code niet bekeken, maar bovenstaande operator<
kan heel onverwachte resultaten geven. Immers maps werken met
equivalentie en niet met gelijkheid en met jouw operato< is (2,4) en
(2,3) equivalent, en dus als je zoekt naar (2,4) kun je een iterator
naar (2,3) terugkrijgen.
Ik kan niet oordelen of dit in uw geval een praktisch probleem is of
niet.

Bert

-- 
The three laws of thermodynamics:
	(1) You can't get anything without working for it.
	(2) The most you can accomplish by working is to break even.
	(3) You can only break even at absolute zero.