Сиплюсплюсное

[spamsink]

Мы, чай, не графья, поэтому пишем по-простому, vector<map<set<int>, int> >.
А в структуре, конечно, графья. Лучше так, чем наоборот.

Comments

[fatoff.livejournal.com]

Намек недопонят, может, шаблоны параметризуются как-то косноязычно? Что за map, который индексирует int значения по ключу set? Операция сравнения между set предусмотрена?

[spamsink]

В данном случае это map из superedges в узлы, сводящие эти superedges в одно ребро, но это не суть. Суть в том, что ничего вручную писать не надо, everything just works. Но выглядит устрашающе; интересно как бы подобное выглядело не на "ассемблере с макропроцессором", а на труъ языке высокого уровня.

[fatoff.livejournal.com]

На Скале, вестимо.

[spamsink]

Parse my question again.

[fatoff.livejournal.com]

There is 3 question marks on this page yet and all mine. What question do you imply? How it looks, should it be written in higher level language? I would probably try to compose something like that with database-related language, like Clipper which I have not used for years but still, can be used to reflect relations between sets of data, etc. One statement to definite the table, another to index it... combination of those.

[spamsink]

A question doesn't have to be explicitly marked by punctuation, it can be implied in a dependent clause. :) Is there a way to do it without invoking the Database demon?

[fatoff.livejournal.com]

Yes, with arrays and dictionaries, I guess. Most of higher level languages have those, though the code would be much less declarative and scary as hell. And those people try to prevent us from inserting index finger to our noses. :-p

[spamsink]

That's right, "from picking our noses".

[dvv.livejournal.com]

"Операция сравнения между set предусмотрена?" is an RTFM question.

[ygam.livejournal.com]

Сосчитать ребра у графа - это не математика, а революция.

(© не помню, кто)

[spamsink]

Кстати о связи математики и революции, вспомнил

А потом наступил тысяча девятьсот семнадцатый год.

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

[juan-gandhi.livejournal.com]

Эх.

Боюсь, у нас тут не все так оптимистично.

[spamsink]

Может, в этом и есть сермяжная правда: пусть болтаются сто языков?

[cema.livejournal.com]

на труъ языке высокого уровня

На труъ языке, может, и типы не обязательно явно указывать.

[fatoff.livejournal.com]

А что, при помощи generics это разве сложно в Java решается?

[cema.livejournal.com]

Язык инструмент (точнее ящик с инструментами, но неважно). У всякой профессии свой ящик. Слесарь супротив столяра, C++ супротив Scala супротив Clojure и т.д.

[cema.livejournal.com]

Ну да. И чем нам будет памятен 2014 год?

[fatoff.livejournal.com]

Меня до сих пор интригует вот эта часть: map

[Error: Irreparable invalid markup ('<set<int>') in entry. Owner must fix manually. Raw contents below.]

Меня до сих пор интригует вот эта часть: map<set<int>, int>.

Тут весь код представлен? Поиск в сете, как таковой, не важен? Итерируем сет? А чего он тогда не list? Просто в векторе сверху ищем по индексам, которые значения в векторе? Это ж для Дийкстры.

[spamsink]

Java в том же классе, что и С++, она не считается.

[some41.livejournal.com]

set -- это набор элементов без повторов. list без особой нужды использовать не надо.

[some41.livejournal.com]

на языке высокого уровня именно так и выглядит, но не устрашает.

[fatoff.livejournal.com]

Если поиск от set не нужен, то он много сложнее list без основания.

[some41.livejournal.com]

для того, чтобы не было дубликатов, очевидно, нужно делать поиск перед вставкой.
list же вообще признак конца 70ых. the default container is vector.

[some41.livejournal.com]

Ну и на "тру языке" не будет копирования сетов, а то здесь не понятно, остался ли от них толк.

[spamsink]

В map они всяко уникальные.

[spamsink]

Не знаю, он еще не кончился.

[spamsink]

Notionally По идее, ребра, входящие в узел, образуют множество (или мультимножество, если допускаются кратные ребра), так зачем какие-то подозрительные представления для множества без нужды выдумывать?

[some41.livejournal.com]

При вставке в map происходит копирование сета. В зависимости от того, как он был получен, оно может быть не нужное. Например, если у вас один сет, который вы модифицируете и временами вставляете, то все хорошо. А если для создания сета его уже пришлось скопировать перед модификацией, то второе копирование не нужно.
Плюс, если set сделан как persistent data structure (такие есть в clojure и Scala), то разные сеты разделяют не измененные части, так что нигде не требуется O(N) копирование.

[spamsink]

В С++ ради избежания копирования можно помочь компилятору, использовав std::move. Надеюсь, что вскоре компиляторы станут умнее, и в этом отпадет необходимость.

[juan-gandhi.livejournal.com]

Если я сознаюсь, что и в джаве, и в скале с дженериками тут каюк...

[fatoff.livejournal.com]

Все читали относительно свежего Страустрапа. Но он не пытался отрицать полезность list для своих применений. В данном случае, точно, вместо set и list, и тем более, vector, скорее, лучше.

[fatoff.livejournal.com]

После зачёркнутого долго думал. Таки там надо похитрее конструкцию, если не только notionally.

[spamsink]

Может, и надо, но это будет premature optimization.