operator <

[Igors]

Добрый день

Есть такая структурка

Код

C++ (Qt)
struct CMatrix {
 double m[16];
 
 bool operator == ( const CMatrix & sec ) const
 {
   for (size_t i = 0; i < 16; ++i)
    if (fabs(m[i] - sec.m[i]) > epsilon) 
     return false;
 
  return true;
 }
};

Как теперь определить оператор < для использования напр в std::map ?

Спасибо

[RedDog]

А как он должен действовать? Может суммы сравнивать?
тогда примерно так:

Код:

bool operator < ( const CMatrix & sec ) const
 {
   return sum(m[0], m[15]) < sum(sec.m[0], sec.m[15]);
 }

[kamre]

Как теперь определить оператор < для использования напр в std::map ?

Оператор < для для использования в std::map никак не связан с оператором ==, поэтому можно как угодно определить, удовлетворяя StrictWeakOrdering. Например, сравнивая лексикографически.

А если же вдруг появится дополнительное требование, чтобы отношение эквивалентности из оператора <, определяемое как !(x < y) && !(y < x), совпадало с отношением, определяемым оператором ==, то это невозможно, т.к. приведенный выше оператор == не транзитивный, а StrictWeakOrdering требует транзитивности.

[kambala]

Например, сравнивая лексикографически.

по-моему это абсолютно естественный вариант

[Igors]

А как он должен действовать? Может суммы сравнивать?

Мне хотелось бы побыть в роли незнающего, которому вумные люди покажут "как правильно" - а Вы сразу встречный вопрос(ы), типа творческая дискуссия - я на это не подписывался  

Оператор < для для использования в std::map никак не связан с оператором ==, поэтому можно как угодно определить, удовлетворяя StrictWeakOrdering. Например, сравнивая лексикографически.

А если же вдруг появится дополнительное требование, чтобы отношение эквивалентности из оператора <, определяемое как !(x < y) && !(y < x), совпадало с отношением, определяемым оператором ==, то это невозможно, т.к. приведенный выше оператор == не транзитивный, а StrictWeakOrdering требует транзитивности.

Я понял все что Вы сказали - ну а делать-то что?    Кстати мое первое впечатление было подобным - недостижимо именно из-за требований транзитивности

по-моему это абсолютно естественный вариант

Но не дающий разумных результатов

[Fat-Zer]

Например, сравнивая лексикографически.

по-моему это абсолютно естественный вариант

только вот матрицы, для которых operator==() будет возвращать труъ, будут добавляться по нескольку раз...

[Igors]

только вот матрицы, для которых operator==() будет возвращать труъ, будут добавляться по нескольку раз...

Совершенно верно, матрицы могут быть реально равны/идентичны но из-за неизбежной погрешности double "точное" сравнение вернет false

[/offtop]
У меня одного впечатление что форум как-то приуныл, много дней "нiчого цiкавого"?
Well, "Good Times Bad Times" 

[kamre]

ну а делать-то что?

Использовать другие структуры данных, т.к. std::map здесь явно не подходит.

[Fat-Zer]

может через std::unordered_map сделать?
hash примерно такая будет:

Код:

size_t hash<CMatrix>(const CMatrix & M) {
  return hash<double>( round(sum(M.m), 16*epsilon) ); 
}
// round(v, e) - округление числа v с точностью не больше e 
// с ходу для неё формула не придумывается...

[Igors]

Использовать другие структуры данных, т.к. std::map здесь явно не подходит.

Вариант, но дороговато выходит (напр свое дерево), "при прочих равных условиях" std предпочтительнее (как справедливо рекомендует наш модератор). Нет ли ходов попрактичнее?

[kamre]

Вариант, но дороговато выходит (напр свое дерево), "при прочих равных условиях" std предпочтительнее (как справедливо рекомендует наш модератор). Нет ли ходов попрактичнее?

В std нет контейнеров для spatial indexing, поэтому или самому реализовывать или брать какие-то готовые реализации.

[kamre]

может через std::unordered_map сделать?

Не будет корректно работать, т.к. найдутся два элемента a==b, для которых будут разные значения функции hash.

[m_ax]

А как он должен действовать? Может суммы сравнивать?

Мне хотелось бы побыть в роли незнающего, которому вумные люди покажут "как правильно" - а Вы сразу встречный вопрос(ы), типа творческая дискуссия - я на это не подписывался  

Уже сам факт того, что Вас совершенно не смущает (или судя по постановки вопроса, для Вас это совершенно естественно) определять для такой структуры как матрица (похоже матрица 4x4) оператор <, вызывает как минимум сомнения в адекватности подхода к проблеме..
Может стоит отмотать несколько шагов назад и задаться вопросом что привело к такой безапелляционной мысли писать этот совершенно не свойственной для матриц оператор?

И потом, для матриц нет однозначного оператора < ... Их можно придумать бесконечное множество реализаций (в зависимости от Вашего настроения или положения звёзд и т.д.)...
А теперь подумайте о том, кто будет использовать Ваш код..

В общем это очень, подчёркиваю, очень плохая идея(
    

[Old]

Может стоит отмотать несколько шагов назад и задаться вопросом что привело к такой безапелляционной мысли писать этот совершенно не свойственной для матриц оператор?

Реализация оператора это уже последствия, мне интересней для чего может понадобиться использовать матрицы в качестве ключа коллекции?
Что-то мне подсказывает, что лучше изменить архитектуру, что бы не приходилось так делать.

[Igors]

Может стоит отмотать несколько шагов назад и задаться вопросом что привело к такой безапелляционной мысли писать этот совершенно не свойственной для матриц оператор?
...
В общем это очень, подчёркиваю, очень плохая идея(

Да отчего же "несвойственной", друг мой? Напр я получаю кучу трансфомеров в виде матриц по каждому полигону - неужели это неестественно проверить и сохранить только уникальные их них? 

Реализация оператора это уже последствия, мне интересней для чего может понадобиться использовать матрицы в качестве ключа коллекции?
Что-то мне подсказывает, что лучше изменить архитектуру, что бы не приходилось так делать.

Ага, а вот и "тип из второго батальона", рад его видеть  Ну ладно m_ax - молодой, увлекается "синтаксическим сахаром", это пройдет. Но Вы-то - человек с немалым опытом - как насчет упереться рогом и подумать - или четко доказать что это невозможно. А то сразу в кусты, мол, меняем архитектуру