Здравствуйте, Nik_1, Вы писали:

N_>Здравствуйте, gandjustas, Вы писали:
G>>Этот разговор уже миллионы раз поднимался. Если быстродействия для миллионов пользователей достаточно, то не нужно тратить эти самые месяцы. Но чтобы узнать это — надо сначала выпустить программу, а потом уже тратить время на оптимизацию. В этом как раз более высокоуровневые языки помогают.
N_>Ага, только если программа написана на чемнить типа шарпа, то когда упрутся в то что производительность недостаточная, придется выкинуть все написанное и переписать программу с нуля на плюсах. Так что зарание подумать тоже не лишне
Если так хочется в это верить, то пожалуйста. На деле оказывается что оптимизация требуется максимум 20% программы, причем в основном не за счет "пидарасинья тактов" на низкоуровневом языке, а за счет выбора правильного алгоритма. Поэтому даже при подходе "выкинуть и переписать на ассемблере" придется 10% программы. Это гораздо лучше чем пытаться сразу писать все на ассемблере.

Здравствуйте, gandjustas, Вы писали:

M>>>>Это очень важно для HPC при активной работе с памятью. Есть у меня бааальшой массив данных,только-только в память влезает, И мне нужно часто менять значения случайных его элементов (точнее случайных цепочек элементов). Причём из нескольких потоков. Как это сделать, если у меня неизменяемая память?
G>>>А ты придумай скачала адекватную задачу для чего такое понадобится.
M>>Это собственно и есть задача. Модель Изинга называется. Есть множество более сложных модификаций, но геморрой там один — вероятностное изменение большой структуры данных в малопредсказуемых местах. Реализуешь на Хаскеле?
G>Сходу нет, но ничего невозможного не вижу. Нету там смысле пересоздавать огромный массив каждый раз.

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

M>>>>Также нет средств для явного ограничения выделения памяти. Я хочу явно выделять память, а не гадать как себя поведёт GC или механизм отвечающий за работу со списками. Та же быстрая сортировка — как мне на Хаскеле выполнить её in-place, без дополнительных выделений памяти?
G>>>Если ты будешь писать на хаскеле, то тебе не понадобится inplace сортировка.
M>>Ну вот есть у меня большущий набор структур типа "пользователь", едва влезающий в память (контейнер любой, лишь бы памяти требовал не сильно больше массива). Он прилетает из сети цельным куском и отдать его надо цельным куском. Как мне его упорядочить по какому-нибудь компаратору?
G>Индексная сортировка.
Пример на любом ЯФП есть?

G>>>Ты себя загоняешь в рамки императивных алгоритмов, а потом пытаешься эти алгоритмы на чистые языки натянуть.
M>>Я себя загоняю в рамки той архитектуры ЭВМ которой располагаю. И я хочу использовать эту архитектуру на всю катушку. А алгоритмы пишутся не для языков, а для компьютеров. А чистые языки почему-то упорно не хотят использовать весь потенциал имеющегося железа.
G>Функциональные языки пытаются использовать весь потенциал программиста, а железо при необходимости докупить можно.
Ну да. То есть для HPC и вообще для задач, где железо реально является ограничивающим фактором, функциональные языки пока не подходят.
И что понимается под потенциалом программиста?

Здравствуйте, gandjustas, Вы писали:

M>>>>Неявное управление памятью помогает, потому что оно упрощает работу и делает её безопасной. Явное управление побочными эффектами усложняет работу и я не вижу, каким образом монада может избавить меня от неправильного формата выходных данных.
G>>>Явные побочные эффекты сильно упрощают композицию кода и отладку.
G>>>От неправильно написанных побочных эффектов не спасет компилятор, но он вполне может спасти от побочных эффектов написанных не в том месте.

M>>>>Кроме того, иногда явное управление памятью необходимо, так почему в большинстве ФЯП нет средств для этого?
G>>>Явное управление памятью почти во всех языках доступно через вызов низкоуровневых функций ОС.
G>>>Запрещено только ручное управление managed-памятью.
M>>То есть если мне понадобилось вручную выровнять одну структуру данных, то весь код, который от неё зависит, становится неуправляемым?
G>Конечно нет.
Да ну? Вот мне нужен непрерывный кусок данных, в котором лежат выровненые на 64 байта подмассивы. Мне изредка надо менять, и часто читать данные из этих подмассивов. Крайне желательно, чтобы всё это хозйство кучно легло в 4 метра процессорного кэша и в 256 KB кэша ядра и не растягивалось в списки по всей памяти при модификации. Я могу гвоздями прибить такое поведение рантайма или остаётся только надеятся что рантайм сам до этого догадается? Я примерно представляю как это можно сделать в C#, но как это организовать в F# и при этом сохранить возможность работать со структурой в функциональном стиле?

M>>>>На OCaml можно будет кивать, когда у него появятся нормальные библиотеки, средства для работы с shared-memory и когда он станет быстрым не только при императивном стиле программирования.
G>>>Тот же .NET умудряется выделять-освобождать память быстрее стандартных аллокаторов для неуправляемых языков.
M>>Во-первых я не про .NET, а про ФП.
G>А тема то про f#
Ну а F# не функциональный что-ли? И вообще — не перебивай

M>>Во-вторых, дело не в "быстрее". Быстроту всегда можно обеспечить ручной аллокацией там где укажет профилировщик. Дело в локальности данных.
G>Как раз сборщиком мусора типа .NETовского локальность данных получается идеальная. Блоки памяти в основном хипе выделяются строго последовательно.
G>И от языка это вообще говоря не зависит.
Знать бы ещё, что такое идеальная локальность . Ну вот если я набиваю список в F#, у меня разве есть гарантии, что элементы будут лежать последовательно в памяти? А если я заменил последний элемент и продолжил набивать список?


M>>AFAIK с этим в .NET как-то можно работать, я, опять же, говорю про ФП.
G>Тема то про f#
Как мне в F# вручную задать размещение объектов "в памяти с требуемым выравниванием и в требуемом порядке" (3-й раз уже повторяю)?

Здравствуйте, Mazay, Вы писали:

M>Как мне в F# вручную задать размещение объектов "в памяти с требуемым выравниванием и в требуемом порядке" (3-й раз уже повторяю)?

module CInterop =
    [<Struct; StructLayout(LayoutKind.Sequential)>]
    type Complex =
        val mutable re:double
        val mutable im:double
        new(r,i) = { re = r; im = i; }

Здравствуйте, gandjustas, Вы писали:
G>Если так хочется в это верить, то пожалуйста.
Эт увас суждения на вере основываются, а уменя многочисленный опыт.
G>На деле оказывается что оптимизация требуется максимум 20% программы, причем в основном не за счет "пидарасинья тактов" на низкоуровневом языке,
Ага, тока когда эти 20% размазаны по всему проекту, посмотрим как ты задолбаешься выносить их в отдельные модули написанные на другом языке, придумывать им адекватный интерфейс и стыковать с остальным приложением. А всегото требовалось в высокооровневый язык добавить возможность при необходимости обращаться к низкоуровневым средствам куча гимороя с этим разделением на модули на раздных языках как рукой снимет.
G> а за счет выбора правильного алгоритма.
Только вот некоторые высокоуровневые языки, включая сабжевый, не имеют требуемых низкоуровневых инструментов для реализации этого "правильного алгоритма".
G> Поэтому даже при подходе "выкинуть и переписать на ассемблере" придется 10% программы.
Зачем асемблер? Что привычка делить все на черное и белое Есть с++, который весьма высокоуровневый, но в все низкоуровневые средства остаются полностью открыты и ты в любой момент можешь кним обратиться при необходимости.

Здравствуйте, Mazay, Вы писали:

M>Здравствуйте, gandjustas, Вы писали:

M>>>>>Это очень важно для HPC при активной работе с памятью. Есть у меня бааальшой массив данных,только-только в память влезает, И мне нужно часто менять значения случайных его элементов (точнее случайных цепочек элементов). Причём из нескольких потоков. Как это сделать, если у меня неизменяемая память?
G>>>>А ты придумай скачала адекватную задачу для чего такое понадобится.
M>>>Это собственно и есть задача. Модель Изинга называется. Есть множество более сложных модификаций, но геморрой там один — вероятностное изменение большой структуры данных в малопредсказуемых местах. Реализуешь на Хаскеле?
G>>Сходу нет, но ничего невозможного не вижу. Нету там смысле пересоздавать огромный массив каждый раз.

M>Разумеется нету смысла, можно даже сказать нету возможности. Зато есть смысл править по одной ячейке памяти на каждом шаге. Как это реализовать без побочных эффектов?
Есть immutable hashtable, можно создать immutable структуру, где хранить большие объем поблочно и пересоздавать отдельные блоки, еще раз говорю — концептуальных проблем нету.

M>>>>>Также нет средств для явного ограничения выделения памяти. Я хочу явно выделять память, а не гадать как себя поведёт GC или механизм отвечающий за работу со списками. Та же быстрая сортировка — как мне на Хаскеле выполнить её in-place, без дополнительных выделений памяти?
G>>>>Если ты будешь писать на хаскеле, то тебе не понадобится inplace сортировка.
M>>>Ну вот есть у меня большущий набор структур типа "пользователь", едва влезающий в память (контейнер любой, лишь бы памяти требовал не сильно больше массива). Он прилетает из сети цельным куском и отдать его надо цельным куском. Как мне его упорядочить по какому-нибудь компаратору?
G>>Индексная сортировка.
M>Пример на любом ЯФП есть?
Вообще любая сортировка объектов в куче именно так работает, ибо перемещаются ссылки.

G>>>>Ты себя загоняешь в рамки императивных алгоритмов, а потом пытаешься эти алгоритмы на чистые языки натянуть.
M>>>Я себя загоняю в рамки той архитектуры ЭВМ которой располагаю. И я хочу использовать эту архитектуру на всю катушку. А алгоритмы пишутся не для языков, а для компьютеров. А чистые языки почему-то упорно не хотят использовать весь потенциал имеющегося железа.
G>>Функциональные языки пытаются использовать весь потенциал программиста, а железо при необходимости докупить можно.
M> Ну да. То есть для HPC и вообще для задач, где железо реально является ограничивающим фактором, функциональные языки пока не подходят.
M>И что понимается под потенциалом программиста?

Способность писать корректный код с максимальной скоростью.

Здравствуйте, Mazay, Вы писали:

M>Здравствуйте, gandjustas, Вы писали:

M>>>>>Неявное управление памятью помогает, потому что оно упрощает работу и делает её безопасной. Явное управление побочными эффектами усложняет работу и я не вижу, каким образом монада может избавить меня от неправильного формата выходных данных.
G>>>>Явные побочные эффекты сильно упрощают композицию кода и отладку.
G>>>>От неправильно написанных побочных эффектов не спасет компилятор, но он вполне может спасти от побочных эффектов написанных не в том месте.

M>>>>>Кроме того, иногда явное управление памятью необходимо, так почему в большинстве ФЯП нет средств для этого?
G>>>>Явное управление памятью почти во всех языках доступно через вызов низкоуровневых функций ОС.
G>>>>Запрещено только ручное управление managed-памятью.
M>>>То есть если мне понадобилось вручную выровнять одну структуру данных, то весь код, который от неё зависит, становится неуправляемым?
G>>Конечно нет.
M>Да ну? Вот мне нужен непрерывный кусок данных...
Пока ты так думаешь, то выше уровня С не поднимишься.
Хотя может тебе и не надо, но такие задачи далеко не у всех и со временем их становится меньше.

M>>>>>На OCaml можно будет кивать, когда у него появятся нормальные библиотеки, средства для работы с shared-memory и когда он станет быстрым не только при императивном стиле программирования.
G>>>>Тот же .NET умудряется выделять-освобождать память быстрее стандартных аллокаторов для неуправляемых языков.
M>>>Во-первых я не про .NET, а про ФП.
G>>А тема то про f#
M>Ну а F# не функциональный что-ли? И вообще — не перебивай
Именно функциональный и на .NET. Так что в нем доступно то самое выравнивание структур.

M>>>Во-вторых, дело не в "быстрее". Быстроту всегда можно обеспечить ручной аллокацией там где укажет профилировщик. Дело в локальности данных.
G>>Как раз сборщиком мусора типа .NETовского локальность данных получается идеальная. Блоки памяти в основном хипе выделяются строго последовательно.
G>>И от языка это вообще говоря не зависит.
M>Знать бы ещё, что такое идеальная локальность . Ну вот если я набиваю список в F#, у меня разве есть гарантии, что элементы будут лежать последовательно в памяти? А если я заменил последний элемент и продолжил набивать список?
Блоки памяти в .NET выделяются последовательно. Хотя что тебе это даст? Ты все равно не сможешь писать на F#, C# и другом .NET языке как на С.


M>>>AFAIK с этим в .NET как-то можно работать, я, опять же, говорю про ФП.
G>>Тема то про f#
M>Как мне в F# вручную задать размещение объектов "в памяти с требуемым выравниванием и в требуемом порядке" (3-й раз уже повторяю)?
На F# не знаю, я таким не занимался, на C# — берешь unsafe и указателем бегаешь как захочется.
Хотя я твой вопрос могу понять так "как мне на <любой ФЯП> писать как на C" — в общем случае ответ "НИКАК". И пока ты этого не поймешь, ты не сможешь получить преимуществ от функциональных языков, да и вообще от managed языков.

Очень мало современных языков позволяют писать как на С, и это их преимущество, а не недостаток.

Здравствуйте, Nik_1, Вы писали:

N_>Здравствуйте, gandjustas, Вы писали:
G>>Если так хочется в это верить, то пожалуйста.
N_>Эт увас суждения на вере основываются, а уменя многочисленный опыт.
Какой опыт, переписывания с управляемого языка на С?

G>>На деле оказывается что оптимизация требуется максимум 20% программы, причем в основном не за счет "пидарасинья тактов" на низкоуровневом языке,
N_>Ага, тока когда эти 20% размазаны по всему проекту, посмотрим как ты задолбаешься выносить их в отдельные модули написанные на другом языке, придумывать им адекватный интерфейс и стыковать с остальным приложением. А всегото требовалось в высокооровневый язык добавить возможность при необходимости обращаться к низкоуровневым средствам куча гимороя с этим разделением на модули на раздных языках как рукой снимет.
Это многочисленный опыт подсказывает? А мне постоянно профайлер подсказывает что тормоза по большей части сосредоточены в одном месте.

G>> а за счет выбора правильного алгоритма.
N_>Только вот некоторые высокоуровневые языки, включая сабжевый, не имеют требуемых низкоуровневых инструментов для реализации этого "правильного алгоритма".

Вот именно именно сабжевый имеет все необходимые средства.

G>> Поэтому даже при подходе "выкинуть и переписать на ассемблере" придется 10% программы.
N_>Зачем асемблер? Что привычка делить все на черное и белое Есть с++, который весьма высокоуровневый, но в все низкоуровневые средства остаются полностью открыты и ты в любой момент можешь кним обратиться при необходимости.
"Высокоуровневый С++" оказывается медленнее (часто) и гораздо менее надежным (всегда) того же .NET или java. Холивар на эту тему уже был в КСВ, повторяться не будем.
"Высокоуровневый С++" стоит применять как "C с классами" для ограниченного набора задач.

Ты до сих пор не понял что "все низкоуровневые средства остаются полностью открыты и ты в любой момент можешь кним обратиться при необходимости" — это связывание компилятора по рукам и ногам, потому что он не способен доказать ни одно утверждение в твоей программе. Именно отказ от многих низкоуровневых средств повышает не только безопасность, но и быстродействие.

Здравствуйте, gandjustas, Вы писали:
G>"Высокоуровневый С++" оказывается медленнее (часто)

G>и гораздо менее надежным (всегда) того же .NET или java.
Ага, "к унитазу не подходи, утонешь". Жизнь вообще опастная штука. Они безопастны лишь за счет полного обрубания всех возможностей у программиста и помещения его в весьма аграниченную песочницу. Это как с вирусами бороться полностью отрубив сеть и выламав дисководы и юсб порты. От вирусов конечно хорошо защещен, тока вот нафиг не нужен такой комп потому что защита отрезала 99% его функционала.

G>Холивар на эту тему уже был в КСВ, повторяться не будем.
Да да, помним, плюсы там раз в 10 всех обогнали, это повашиму "медленнее (часто) "
G>Ты до сих пор не понял что "все низкоуровневые средства остаются полностью открыты и ты в любой момент можешь кним обратиться при необходимости"
это где они в шарпе открыты?

Здравствуйте, gandjustas, Вы писали:

G>>>>>А ты придумай скачала адекватную задачу для чего такое понадобится.
M>>>>Это собственно и есть задача. Модель Изинга называется. Есть множество более сложных модификаций, но геморрой там один — вероятностное изменение большой структуры данных в малопредсказуемых местах. Реализуешь на Хаскеле?
G>>>Сходу нет, но ничего невозможного не вижу. Нету там смысле пересоздавать огромный массив каждый раз.

M>>Разумеется нету смысла, можно даже сказать нету возможности. Зато есть смысл править по одной ячейке памяти на каждом шаге. Как это реализовать без побочных эффектов?
G>Есть immutable hashtable, можно создать immutable структуру, где хранить большие объем поблочно и пересоздавать отдельные блоки, еще раз говорю — концептуальных проблем нету.
Бгыг. Ну так покажи как их нету. На любом императивном языке этот алгоритм занимает полэкрана текста. А у immutable hashtable какой пенальти по памяти? Это при условии, что каждый элемент в массиве — один байт (ну 4 байта). И "пересоздавать отдельные блоки" это однозначно перебор. Каков размер блока? Хотя ты сейчас опять скажешь что у меня мышление императивное. Давай код уже.

G>>>>>Если ты будешь писать на хаскеле, то тебе не понадобится inplace сортировка.
M>>>>Ну вот есть у меня большущий набор структур типа "пользователь", едва влезающий в память (контейнер любой, лишь бы памяти требовал не сильно больше массива). Он прилетает из сети цельным куском и отдать его надо цельным куском. Как мне его упорядочить по какому-нибудь компаратору?
G>>>Индексная сортировка.
M>>Пример на любом ЯФП есть?
G>Вообще любая сортировка объектов в куче именно так работает, ибо перемещаются ссылки.
Это я понял. Покажи функциональный код.

M>>>> А алгоритмы пишутся не для языков, а для компьютеров. А чистые языки почему-то упорно не хотят использовать весь потенциал имеющегося железа.
G>>>Функциональные языки пытаются использовать весь потенциал программиста, а железо при необходимости докупить можно.
M>> Ну да. То есть для HPC и вообще для задач, где железо реально является ограничивающим фактором, функциональные языки пока не подходят.
Ну то есть про HPC возражений нет?

M>>И что понимается под потенциалом программиста?
G>Способность писать корректный код с максимальной скоростью.
А если код завершает работу уже после того, как был нужен результат (например прогноз погоды)?

Здравствуйте, Nik_1, Вы писали:

N_>Ага, "к унитазу не подходи, утонешь". Жизнь вообще опастная штука. Они безопастны лишь за счет полного обрубания всех возможностей у программиста и помещения его в весьма аграниченную песочницу.
"аграниченная песочница" позволяет мне возвращать ссылку из метода и совершенно не париться над временем жизни объекта.
"аграниченная песочница" позволяет не использовать блокировки и свободно передавать объекты между потоками.
"аграниченная песочница" банально уменьшает затраты на отладку приложений.
Поменьше эмоций и придет просветление, настоящий джедай должен быть спокоен.

N_>Это как с вирусами бороться полностью отрубив сеть и выламав дисководы и юсб порты. От вирусов конечно хорошо защещен, тока вот нафиг не нужен такой комп потому что защита отрезала 99% его функционала.
Необоснованные аналогии как всегда идут лесом.

Здравствуйте, gandjustas, Вы писали:
N_>>Ага, "к унитазу не подходи, утонешь". Жизнь вообще опастная штука. Они безопастны лишь за счет полного обрубания всех возможностей у программиста и помещения его в весьма аграниченную песочницу.
G>"аграниченная песочница" позволяет мне возвращать ссылку из метода и совершенно не париться над временем жизни объекта.
смартпоинтер?
G>"аграниченная песочница" позволяет не использовать блокировки и свободно передавать объекты между потоками.
смартпоинтер со встроенной потоковой защитой?
G>"аграниченная песочница" банально уменьшает затраты на отладку приложений.
Так как ничего по существу тут не написал, додумаем сами : наверно тем что ущербный не поддерживает шаблоны

G>Поменьше эмоций и придет просветление, настоящий джедай должен быть спокоен.
G>Необоснованные аналогии как всегда идут лесом.
А по существу опять таки есть что сказать? Иль тролим?

Здравствуйте, Mazay, Вы писали:

M>Здравствуйте, gandjustas, Вы писали:

G>>>>>>А ты придумай скачала адекватную задачу для чего такое понадобится.
M>>>>>Это собственно и есть задача. Модель Изинга называется. Есть множество более сложных модификаций, но геморрой там один — вероятностное изменение большой структуры данных в малопредсказуемых местах. Реализуешь на Хаскеле?
G>>>>Сходу нет, но ничего невозможного не вижу. Нету там смысле пересоздавать огромный массив каждый раз.

M>>>Разумеется нету смысла, можно даже сказать нету возможности. Зато есть смысл править по одной ячейке памяти на каждом шаге. Как это реализовать без побочных эффектов?
G>>Есть immutable hashtable, можно создать immutable структуру, где хранить большие объем поблочно и пересоздавать отдельные блоки, еще раз говорю — концептуальных проблем нету.
M>Бгыг. Ну так покажи как их нету. На любом императивном языке этот алгоритм занимает полэкрана текста. А у immutable hashtable какой пенальти по памяти? Это при условии, что каждый элемент в массиве — один байт (ну 4 байта). И "пересоздавать отдельные блоки" это однозначно перебор. Каков размер блока? Хотя ты сейчас опять скажешь что у меня мышление императивное. Давай код уже.
Ну так приведи эти "полэкрана", напишем тебе аналог на чем-нить функциональном. А то я пока и задачу с трудом себе представляю.

G>>>>>>Если ты будешь писать на хаскеле, то тебе не понадобится inplace сортировка.
M>>>>>Ну вот есть у меня большущий набор структур типа "пользователь", едва влезающий в память (контейнер любой, лишь бы памяти требовал не сильно больше массива). Он прилетает из сети цельным куском и отдать его надо цельным куском. Как мне его упорядочить по какому-нибудь компаратору?
G>>>>Индексная сортировка.
M>>>Пример на любом ЯФП есть?
G>>Вообще любая сортировка объектов в куче именно так работает, ибо перемещаются ссылки.
M>Это я понял. Покажи функциональный код.
sort xs, что тебе еще надо?

M>>>>> А алгоритмы пишутся не для языков, а для компьютеров. А чистые языки почему-то упорно не хотят использовать весь потенциал имеющегося железа.
G>>>>Функциональные языки пытаются использовать весь потенциал программиста, а железо при необходимости докупить можно.
M>>> Ну да. То есть для HPC и вообще для задач, где железо реально является ограничивающим фактором, функциональные языки пока не подходят.
M>Ну то есть про HPC возражений нет?
Про HPC как раз есть, оно вполне успешно делается и на функциональных языках, ибо параллелить проще. А вот там где надо "пидарасить такты\байты" нужен именно инструмент, который позволяет это делать, без этого никуда. Но таких задач предельно мало и все меньше становится.

M>>>И что понимается под потенциалом программиста?
G>>Способность писать корректный код с максимальной скоростью.
M>А если код завершает работу уже после того, как был нужен результат (например прогноз погоды)?
Код, написанный на высокоуровневом языке завершает работу до того как будет дописан код на низкоуровневом

Здравствуйте, Nik_1, Вы писали:

N_>Здравствуйте, gandjustas, Вы писали:
N_>>>Ага, "к унитазу не подходи, утонешь". Жизнь вообще опастная штука. Они безопастны лишь за счет полного обрубания всех возможностей у программиста и помещения его в весьма аграниченную песочницу.
G>>"аграниченная песочница" позволяет мне возвращать ссылку из метода и совершенно не париться над временем жизни объекта.
N_>смартпоинтер?
Ага, подсчет ссылок, блокировки при многопоточном доступе... и все это начинает в разы медленее "аграниченной песочницы" работать.

G>>"аграниченная песочница" позволяет не использовать блокировки и свободно передавать объекты между потоками.
N_>смартпоинтер со встроенной потоковой защитой?
А как это поможет передавать объекты между потоками?

G>>"аграниченная песочница" банально уменьшает затраты на отладку приложений.
N_>Так как ничего по существу тут не написал, додумаем сами : наверно тем что ущербный не поддерживает шаблоны
Кто не поддерживает? На F# есть compile-time duck typing, есть Template Haskell, есть Nemerle с макросами.

Здравствуйте, gandjustas, Вы писали:

G>>>>>>>А ты придумай скачала адекватную задачу для чего такое понадобится.
M>>>>>>Это собственно и есть задача. Модель Изинга называется. Есть множество более сложных модификаций, но геморрой там один — вероятностное изменение большой структуры данных в малопредсказуемых местах. Реализуешь на Хаскеле?
G>>>>>Сходу нет, но ничего невозможного не вижу. Нету там смысле пересоздавать огромный массив каждый раз.
M>>>>Разумеется нету смысла, можно даже сказать нету возможности. Зато есть смысл править по одной ячейке памяти на каждом шаге. Как это реализовать без побочных эффектов?
G>>>Есть immutable hashtable, можно создать immutable структуру, где хранить большие объем поблочно и пересоздавать отдельные блоки, еще раз говорю — концептуальных проблем нету.
M>>Бгыг. Ну так покажи как их нету. На любом императивном языке этот алгоритм занимает полэкрана текста. А у immutable hashtable какой пенальти по памяти? Это при условии, что каждый элемент в массиве — один байт (ну 4 байта). И "пересоздавать отдельные блоки" это однозначно перебор. Каков размер блока? Хотя ты сейчас опять скажешь что у меня мышление императивное. Давай код уже.
G>Ну так приведи эти "полэкрана", напишем тебе аналог на чем-нить функциональном. А то я пока и задачу с трудом себе представляю.

Ладно, чуть больше чем полэкрана, но всё равно тривиально.

#include <cmath>
#include <iostream>
#include <boost/array.hpp>
#include <boost/random.hpp>

using std::cout;
using std::endl;
using boost::array;

const int N = 40;    // field size
const double J = 0.1;    //interaction energy
const double beta = 6; // try values 6, 4, 2. Higher value corresponds to lower temperature.

boost::array<boost::array<char, N>, N > S;

boost::minstd_rand generator(time(0));
boost::uniform_01<> uni_1;
boost::uniform_int<> uni_N(0,N-1);

int cycl(int x)    // cyclyc boundary conditions
{
    if (x < 0)
        return x + N;
    if (x >= N)
        return x - N;
    return x;
}

double energy(int x, int y)    //evaluate energy of one element
{
    int s = S[cycl(x-1)][y] + S[cycl(x+1)][y]
        + S[x][cycl(y-1)] + S[x][cycl(y+1)];
    return (-J) * s * S[x][y];
}

void init()    // random init S
{
    for (int x = 0; x < N; ++x)
    {
        for (int y = 0; y < N; ++y)
        {
            S[x][y] = (uni_1(generator) > 0.5) ? -1 : 1;
        }
    }
}

bool check(double dE)    // Gibbs distribution
{
    return  exp(-dE*beta) > uni_1(generator);
}

void print()
{
    for (int x = 0; x < N; ++x)
    {
        for (int y = 0; y < N; ++y)
        {
            cout<< ((S[x][y] > 0) ? '|' : '-') << ' ';
        }
        cout<<endl;
    }
}

int main()
{
    init();
    print();    // initial S
    for (int i = 0 ; i < 999999; ++i)
    {
        int x = uni_N(generator);
        int y = uni_N(generator);

        double E_o = energy(x, y); // old Energy
        S[x][y] =  - S[x][y];        // trial step
        double E_n = energy(x, y); // new Energy
        if (!check(E_n-E_o))    // accept or decline trial step according to Gibbs
        {
            S[x][y] =  - S[x][y]; // trial step declined, rollback the change
        }
        else
        {
            // trial step accepted, keep the change
        }

    }
    cout<<endl;
    print(); // equlibrium S
    return 0;
}

Вот была бы возможность использовать нормальный функциональный язык вместо init() и print() а остальное можно оставить как есть А так получается на Хаскеле не напишешь (?), а на плюсах только с boost::lambda извращаться.

Здравствуйте, gandjustas, Вы писали:
G>Ты до сих пор не понял что "все низкоуровневые средства остаются полностью открыты и ты в любой момент можешь кним обратиться при необходимости" — это связывание компилятора по рукам и ногам, потому что он не способен доказать ни одно утверждение в твоей программе.
Ой бида-бида!!

Здравствуйте, Mazay, Вы писали:

M>Здравствуйте, gandjustas, Вы писали:

G>>>>>>>>А ты придумай скачала адекватную задачу для чего такое понадобится.
M>>>>>>>Это собственно и есть задача. Модель Изинга называется. Есть множество более сложных модификаций, но геморрой там один — вероятностное изменение большой структуры данных в малопредсказуемых местах. Реализуешь на Хаскеле?
G>>>>>>Сходу нет, но ничего невозможного не вижу. Нету там смысле пересоздавать огромный массив каждый раз.
M>>>>>Разумеется нету смысла, можно даже сказать нету возможности. Зато есть смысл править по одной ячейке памяти на каждом шаге. Как это реализовать без побочных эффектов?
G>>>>Есть immutable hashtable, можно создать immutable структуру, где хранить большие объем поблочно и пересоздавать отдельные блоки, еще раз говорю — концептуальных проблем нету.
M>>>Бгыг. Ну так покажи как их нету. На любом императивном языке этот алгоритм занимает полэкрана текста. А у immutable hashtable какой пенальти по памяти? Это при условии, что каждый элемент в массиве — один байт (ну 4 байта). И "пересоздавать отдельные блоки" это однозначно перебор. Каков размер блока? Хотя ты сейчас опять скажешь что у меня мышление императивное. Давай код уже.
G>>Ну так приведи эти "полэкрана", напишем тебе аналог на чем-нить функциональном. А то я пока и задачу с трудом себе представляю.

M>Ладно, чуть больше чем полэкрана, но всё равно тривиально.
M>

M>//skipped
M>

Тупой вариант — не изменять значения в массиве, а хранить их в отдельном Map. Получим дополнительные log(n), где n — количество прошедших.
Чуть более навороченный вариант — при превышении некоторого порога пересоздавать массив с новыми значениями.
Я не особо спец в хаскеле, если время будет — напишу код.

PS. Дополнительные log(n) — стандартная проблема при использовании immutable.

Здравствуйте, gandjustas, Вы писали:

G>Тупой вариант — не изменять значения в массиве, а хранить их в отдельном Map. Получим дополнительные log(n), где n — количество прошедших.
G>Чуть более навороченный вариант — при превышении некоторого порога пересоздавать массив с новыми значениями.
G>Я не особо спец в хаскеле, если время будет — напишу код.
Да ладно. С дополнительным log(n) я и сам напишу.

G>PS. Дополнительные log(n) — стандартная проблема при использовании immutable.
+1

Ну вот собссно и весь разговор. Просто есть задачи, где дополнительные log(n) неприемлемы. У меня подозрение, что многие программисты не переваривают ФП именно из-за того, что не в состоянии принять решение с таким пенальти.

Здравствуйте, Mazay, Вы писали:

M>Здравствуйте, gandjustas, Вы писали:

G>>Тупой вариант — не изменять значения в массиве, а хранить их в отдельном Map. Получим дополнительные log(n), где n — количество прошедших.
G>>Чуть более навороченный вариант — при превышении некоторого порога пересоздавать массив с новыми значениями.
G>>Я не особо спец в хаскеле, если время будет — напишу код.
M>Да ладно. С дополнительным log(n) я и сам напишу.

G>>PS. Дополнительные log(n) — стандартная проблема при использовании immutable.
M>+1

M>Ну вот собссно и весь разговор. Просто есть задачи, где дополнительные log(n) неприемлемы. У меня подозрение, что многие программисты не переваривают ФП именно из-за того, что не в состоянии принять решение с таким пенальти.

Ну тут избрали неверный подход. Если тупо императивный алгоритм переписать с immutable объектами, то он получит дополнительный log(n), если писать алгоритм изначально в функциональном подходе, то можно не только не получать дополнительные множители, но и ускорить программу за счет ленивости, сократив при этом текст программы, к тому же получить простоту распараллеливания.

Здравствуйте, gandjustas, Вы писали:

G>>>PS. Дополнительные log(n) — стандартная проблема при использовании immutable.
M>>+1

M>>Ну вот собссно и весь разговор. Просто есть задачи, где дополнительные log(n) неприемлемы. У меня подозрение, что многие программисты не переваривают ФП именно из-за того, что не в состоянии принять решение с таким пенальти.

G>Ну тут избрали неверный подход. Если тупо императивный алгоритм переписать с immutable объектами, то он получит дополнительный log(n), если писать алгоритм изначально в функциональном подходе, то можно не только не получать дополнительные множители, но и ускорить программу за счет ленивости, сократив при этом текст программы, к тому же получить простоту распараллеливания.

Ну дык покажи класс.