operator <

[Old]

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

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

[m_ax]

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

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

Вот я, собственно, о том же.. Мне не понятна такая категоричная исходная позиция "как реализовать оператор <". Почему всё, что привело к этой точке не может подлежать сомнению? Диктаторство какое то, ей богу)

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

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

 

Хорошо, тогда, чтоб направить обсуждение в "конструктивное русло" может стоить внести некую предысторию, которая бы воссоздавала корень самой проблемы?  

[Fat-Zer]

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

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

нет... для любых матриц a==b сиё должно выдавать одинаковый хеш... возможно надо будет ещё epc округлить в большую сторону до следующего двоичного разряда ...

как насчет упереться рогом и подумать - или четко доказать что это невозможно.

дык kamre уже объяснил, что это не возможно и почему...

[Igors]

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

Есть N полигонных объектов каждый из которых может иметь до 8 текстур. Каждая текстура имеет матрицу. Если у каких-то объектов все текстуры равны (с заданной точностью) то они используют/шарят одни и те же данные (UV координаты), иначе разные. Как видите, дело совершенно рядовое.

[kamre]

для любых матриц a==b сиё должно выдавать одинаковый хеш...

Функция round разрывная, поэтому всегда можно найти два элемента a==b, для которых будет разное значение. Просто сами представьте: все пространство разбивается на области с одинаковыми значениями hash функции, всегда есть граница между областями, можно взять сколь угодно близкие элементы находящиеся по разные стороны от границы.

[Fat-Zer]

Функция round разрывная, поэтому всегда можно найти два элемента a==b, для которых будет разное значение. Просто сами представьте: все пространство разбивается на области с одинаковыми значениями hash функции, всегда есть граница между областями, можно взять сколь угодно близкие элементы находящиеся по разные стороны от границы.

да... правда...

[Igors]

Однако же - "углубление в корень/первоосновы" никакого прогресса пока не принесло 

дык kamre уже объяснил, что это не возможно и почему...

И это всем понятно? Или не очень - но лучше промолчать?   Почему напр не просто так

Код

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

2kamre А Вас, Штирлиц, я попрошу пока воздержаться 

[Old]

Есть N полигонных объектов каждый из которых может иметь до 8 текстур. Каждая текстура имеет матрицу. Если у каких-то объектов все текстуры равны (с заданной точностью) то они используют/шарят одни и те же данные (UV координаты), иначе разные. Как видите, дело совершенно рядовое.

Только отсюда не следует, что для реализации этого, необходимо обязательно использовать map.
Если отказаться от него, то хватит операторов равенства/не равенства.

[m_ax]

На крайний случай можно написать свой специфичный  предикат и передать его map.
В смысле примерно так:

Код

C++ (Qt)
struct unusual_pred {
    bool operator()(const CMatrix & m1, const CMatrix &m2) const {
        for (size_t i = 0; i < 16; ++i) {
            double delta = m1[i] - m2[i];
            if (delta < -epsilon) return true;
            if (delta > epsilon) return false;
        }
     return false;
    }
};
 
...
 
std::map<CMatrix, Data, unusual_pred> my_strange_map;
 

Но писать в самом CMatrix этот оператор< идея бредовая.
 

[Igors]

Только отсюда не следует, что для реализации этого, необходимо обязательно использовать map.
Если отказаться от него, то хватит операторов равенства/не равенства.

Ну использование прямого перебора, мягко говоря, не украшает программиста - этим он расписывается в своей беспомощности.

На крайний случай можно написать свой специфичный  предикат и передать его map.
В смысле примерно так:
..
Но писать в самом CMatrix этот оператор< идея бредовая.

А почему оператор < для структуры кажется Вам бредовым? Ну есть какое-то отношение упорядочивания. Если их много - может и лучше подсовывать той или иной функтор, а если 1 и др не видно - так чего в структуре не объявить? Впрочем это дело вкуса. Главное - а корректен ли предложенный оператор/функтор?

[Old]

Ну использование прямого перебора, мягко говоря, не украшает программиста - этим он расписывается в своей беспомощности.

Да? Не знал.
Т.е. придумать невозможный оператор для структуры, что бы ее можно было использовать  в map для вас показатель класса?

[m_ax]

А почему оператор < для структуры кажется Вам бредовым? Ну есть какое-то отношение упорядочивания. Если их много - может и лучше подсовывать той или иной функтор, а если 1 и др не видно - так чего в структуре не объявить? Впрочем это дело вкуса. Главное - а корректен ли предложенный оператор/функтор?

Да как уже неоднократно говорили: введение такого оператора нарушает свойства транзитивности для объектов матриц. Этого одного факта уже вполне достаточно чтоб хотя бы призадуматься (а может есть решение более логичное)..

[Igors]

Да? Не знал.
Т.е. придумать невозможный оператор для структуры, что бы ее можно было использовать  в map для вас показатель класса?

Я на map не настаиваю - предлагайте др решения, только без "пускания пузырей" с прямым перебором 

Да как уже неоднократно говорили: введение такого оператора нарушает свойства транзитивности для объектов матриц. Этого одного факта уже вполне достаточно чтоб хотя бы призадуматься (а может есть решение более логичное)..

А что это за свойства такие? И как мы их нарушаем? Можно объяснить попроще, а то у Вас все так "официально" 

[m_ax]

А что это за свойства такие? И как мы их нарушаем? Можно объяснить попроще, а то у Вас все так "официально" 

Да очень просто: У Вас нет никаких гарантий что если a < b и b < c, то и a < c.
И как следствие, если у Вас, например, имеется некая последовательность: a1, a2, a3, a4, .. an, то отсортированная последовательность (с помощью этого оператора<) будет зависеть от исходной. Это плохо, я бы сказал - это костыль..

Во-вторых это плохо ещё и от того, что у Вас реализация класса CMatrix начинает обрастать зависимостями от способа реализации каких то частных задач.. Такие зависимости - это практически всегда следствие корявой архитектуры..

Ну и в-третьих: Вы уверены, что Вас правильно поймут те, кто, возможно будет в будущем работать с Вашим кодом?
   

[Fat-Zer]

И это всем понятно? Или не очень - но лучше промолчать?  Почему напр не просто так

про то, что транзитивность ( a<b & b<c => a<c ) не выполняется уже сказали.
с такой штукой std::map просто будет не корректно работать... в частности может добавлять одинаковые элементы или не находить уже имеющиеся. может будут и другие глюки при повороте дерева например...

одним словом тут точно придётся воять какой-то особый контейнет... есть одна идея, правда, быть может, бредовая, основанная на том, что для скалярного double аналогичный отношение с epsilon будет задавать строгий порядок... потом, может быть, расскажу, когда и если оно более детально обрисуется в голове...