LINUX.ORG.RU

[Haskell]Массивы

 


0

0

Мне необходимо оперировать достаточно сложными типами данных (Марковское поле).

В общем получается, что необходимо задавать граф, в вершинах и ребрах которого записаны данные, основанные на опять же массивах.

По сути применяемых алгоритмов, будет удобно работать с матрицей инцидентности графа. То есть получается массив массивов.

И теперь в общем вопрос, можно ли удобно работать с такой вот структурой, не имея двух вариантов типа данных, один немутабельный и один для ST?

★★★★★

будет удобно работать с матрицей инцидентности графа. То есть получается массив массивов

почему именно массив и именно массивов?

jtootf ★★★★★
()
Ответ на: комментарий от jtootf

Хм... честно говоря, я подумал и у меня появились сомнения, что я сморознул глупость =)

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

И есть матрица инцидентности, что опять же есть массив. В каждом ребре записан массив чисел.

Почему именно массив? Потому, что есть алгоритмы, требующие поэлементное обновление данных.

Waterlaz ★★★★★
() автор топика

Да. Есть готовые библиотеки на хаскеле, работающие правда только м маровскими последовательностями. Естественно не подходят.

Waterlaz ★★★★★
() автор топика
Ответ на: комментарий от Waterlaz

хм.. ну как ни крути получается массив массивов. Иначе в голову решения только хуже приходят

Waterlaz ★★★★★
() автор топика

я бы еще как-то понял выбор хаскеля, если бы юзал поверх него суперкомпилятор либо делал распараллеливание по заранее спланированному тобой сценарию

а в противном случае прогиб под хасклевскую немутабельность — мазохизм и ничего больше

www_linux_org_ru ★★★★★
()

> И теперь в общем вопрос, можно ли удобно работать с такой вот структурой, не имея двух вариантов типа данных, один немутабельный и один для ST?

скока страданий, и ради чего?

CL-USER
()
Ответ на: комментарий от CL-USER

>скока страданий, и ради чего?

[troll]что-бы не быть лиспером...[/troll]

А вообще, это как минимум интересно.

Waterlaz ★★★★★
() автор топика
Ответ на: комментарий от CL-USER

> [troll]что-бы не быть лиспером...[/troll]

«Сначала тебя игнорируют, затем над тобой смеются, затем с тобой борются, затем ты побеждаешь» (c) Махатма Ганди

видимо, для лисперов этап-3 уже пройден. Близко к победе уже. ;)

CL-USER
()
Ответ на: комментарий от CL-USER

> «Сначала тебя игнорируют, затем над тобой смеются, затем с тобой борются, затем ты побеждаешь» (c) Махатма Ганди

В случае LISP-а и ЛОР-а эта цитата Махатмы должна выглядеть так:

«Сначала над тобой смеются, затем тебя троллят, затем с тобой борются, затем тебя добавляют в игнор»

anonymous
()
Ответ на: комментарий от Waterlaz

что-бы не быть лиспером...

чтобы

Почитав lor/rsdn пришел к выводу, что хаскель/лисп/иже позиционируются примерно так же, как проблесковые маячки на членовозах.

yaws
()
Ответ на: комментарий от Waterlaz

решения только хуже

http://en.wikibooks.org/wiki/Haskell/Zippers

http://okmij.org/ftp/Computation/Continuations.html#zipper

http://cvs.haskell.org/Hugs/pages/libraries/base/Data-Sequence.html

хотя в чём вопрос, я так и не понял :) можно ли эффективно работать с немутабельной структурой данных? нужно ли с ней работать?

jtootf ★★★★★
()
Ответ на: комментарий от www_linux_org_ru

я бы еще как-то понял

мнения укушенных хаскелистами в расчёт не берём

jtootf ★★★★★
()
Ответ на: комментарий от CL-USER

«быть лиспером»~--- это уже стало чем-то плохим?

в общем случае - нет. однако из-за обилия подобных тебе чучел, вылазящих в никоим образом не относящиеся к лиспу треды, и пыжащихся там, складывается образ в целом неадекватного сообщества

jtootf ★★★★★
()
Ответ на: комментарий от jtootf

> в общем случае - нет. однако из-за обилия подобных тебе чучел, вылазящих в никоим образом не относящиеся к лиспу треды, и пыжащихся там, складывается образ в целом неадекватного сообщества

Не тебе решать, куда мне вылазить, куда нет, чучелко.

CL-USER
()

И теперь в общем вопрос, можно ли удобно работать с такой вот структурой, не имея двух вариантов типа данных, один немутабельный и один для ST?

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

Miguel ★★★★★
()

Можно же сделать thaw, если потребуется немутабельная версия из мутабельной? Вообще не очень понятен смысл вопроса.

AlexVR ★★★★★
()
Ответ на: комментарий от jtootf

Хм... за ссылки спасибо, почитаю.

Проблему попробую выразить точнее.

Waterlaz ★★★★★
() автор топика
Ответ на: комментарий от Miguel

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

Возможно, я и делаюю тут глупость, но в случае немутабельных данных, я бы делал вот так (метами unboxed array, но не суть).

 
data MarkovObject = MarkovObject {
                      states :: Array Int Double,
                      someObjectStuff :: SomeType
                    }

data MarkovEdge = MarkovEdge                    
                      weights :: Array (Int, Int) Double,
                      someEdgeStuff :: SomeType
                  }
                    
data MarkovField = MarkovField {
                      objects :: Array Int MarkovObject,
                      edges :: Array (Int, Int) MarkovEdge,
                      someFieldStuff :: SomeType
                   }

То есть марково поле - это совокупность марковских объектов и марковских ребер, которые сами по себе представлены массивами.

Waterlaz ★★★★★
() автор топика
Ответ на: комментарий от vasily_pupkin

Вырывая фразы из контекста и преподнося эти цитаты, как неопровержимые истины, а потом еще и повторяя одну и ту же глупость по 20 раз в день, кончишь плохо вне зависимости от того, кого ты цитируешь.

balodja ★★★
()

Так есть у кого какие идеи, как быть с такими структурами и мутабельностью?

Waterlaz ★★★★★
() автор топика
Ответ на: комментарий от Waterlaz

Посмотрел, как другие делают. Будет мутабельный тип с монадой как параметр.

Waterlaz ★★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.