Здравствуйте, Ikemefula, Вы писали:
I>Вот это и есть ошибка. Скорее всего вы создали для GC проблемы в другом месте и ему стало проблематично рабоать даже с нулевым поколением.
Нету нулевого поколения. Сообщения принципиально должны обрабатываться после линии задержки. Длительность линии я тебя чуть приврал, на самом деле она плавающая, зависит от результата мониторинга разброса интервалов м/у пакетами в сети, но примерную верхнуюю границу указал верно. В нормальном режиме задержка порядка 100ms, но меня интересует худший случай, ес-но.
I>Такое бывает в некоторых вырожденых сценариях, когда даже какой нибудь EventArgs создать не получается и GC педалит минутами.
Вооот, а у нас реалтайм, мы не можем позволить GC педалить более ~50ms. Собственно, с этим борьба.
V>>Гы-гы два раза. Дешевле всего избегать лишних ветвлений, каждый раз дополнительно проверяя объект на null. Но это дешевле без new, ес-но, поэтому, если кол-во полей в пришедшем сообщении =0, то цепляется статический пустой список полей. Фигли там всей инфраструктуры на 3 строчки в проекте-полумиллионнике...
I>Количество ветвлений ты не уменьшаешь, оно полностью сохраняется. Уменьшается количество инстанцирований, смотри внимательно: I>
I>return list ?? new ArrayList<T>();
I>return list ?? Static<ArrayList<T>>.Instance;
I>
Эта операция однократна, я тебе уже про пулы сказал... в отличие от операции обращения к полям.
I>Соответсвенно экономия в перформансе за счет инстанцирований и GC, на тех цифрах, что ты показал, оно вообще не заметно. Экономию по памяти — это исправление ошибки дизайна низкоуровневой техникой.
Я пока не увидел никакой указанной тобой ошибки дизайна. Неужели, опять это началось? )))
I>Если от тебя примера не будет — не надо ничего писать, идёт ?
Тебе от меня чего-то потребовать просто так захотелось? Я ведь могу и показать куда сходить и где поискать..
Кароч, ты упомянул свой уже готовый тест — давай его сюда. Я над ним поработаю на досуге для доведения до похожих условий. Т.е. если тебе реально интересно — без проблем. (просто, помня твой стиль, вовсе не факт, что сие именно так, уж не обессудь )
Здравствуйте, vdimas, Вы писали:
V>В модели графы объектов многих типов. Модель-то адекватна, но за 10 мин не возпроизведешь. Затраты на уборку мусора зависят не только от кол-ва объектов, но и от разнообразия их типов.
То есть, от тебя таки жостких данных не поступало ? Ну-ка, подробнее про зависимость затрат на уробрку мусора от количества типов.
V>>>Не только. Проблемы от того, что мы храним сами сообщения. I>>После упоминания интрузивных списков я еще больеш уверен, что никакой экономии твоя статика не даёт, разве что пустой список у тебя не весит в 100кб
V>Т.е. ты уже замерил эффективность интрузивной очереди vs стандартной очереди?
Вообще это не надо, потому что даже стандартная очередь дает цыфры на порядок выше тобою указаных и никакого "падения навзничь" не обнаруживается.
Скромный подсчет, 1500 очередей, в 100 месаг в сек,длина очереди 500мс, дает следующий расклад — в каждой очереди 50 элементов * 1500 = всего 75 тыс элементов. У меня, для сравнения, десятки миллионов и то издержки на GC как то не впечатляют.
V>Не верю! (С)
Не льсти себе, эти замеры сделаны примерно три месяца назад для выяснения как раз таких издержек, самых разных, на новой версии дотнета в новых условиях и тд и тд и тд. Последние три месяца я занимаюсь оптимизацией по перформансу, чисто на всякий, что бы ты был в курсе, что у меня много каких замеров прямо под рукой.
>>>Проблемы от того, что сами сообщения тоже представляли из себя "унутре" граф объектов.
I>>И это еще больше усиливает уверенность, что экономия на пустом списке как мертвому припарка, дальше я скипнул.
V>Ты скипнул аргумент о лишнем ветвлении в алгоритмах.
Не я, а ты. ты не в состоянии сравнить количество ветвлений в двух строчках кода.
Покажи тут разницу в количетсве ветвлений
return list ?? new ArrayList<T>();
return list ?? Static<ArrayList<T>>.Instance;
>Похоже, ты не понимаешь, за какой порядок цифр идет борьба. Кол-во сообщений в сек уже дал. Вычти отсюда порядка 3us на сообщение
Ты не в состоянии выдать жосткие данные.
>забираемое сетью, еще порядка 1us на межпотоковую передачу сообщений. Все, что осталось — твоё.
Если ты внимательно читал,то у меня самая плохая реализация выдаёт в 10 раз больше того, чем тебе хочется.
>Затраты на GC — не только на выделение объектов 0-го поколения. Размазывай все его затраты на все его операции со всеми поколениями. Ты в своем тесте создавал одно сообщение и помещал его в очередь? А ты создавал к этому сообщению пустой список полей так же по new каждый раз? Если не создавал, то создай и прогони тест опять. Вычти затраты из остатка на сообщение.
Зачем заранее создавать и хранить пустой список полей ? Это по требованию нужно делать. О чем я тебе и говорю уже в который раз.
V>Ну и дело было 5 лет назад, никаких 4 или 8 ядер не было. Сейчас одно ядро в среднем в 3 раза быстрее, и кол-во ядер в 2-3 раза больше. Если ты получил всего на порядок быстрее, то ты, выходит, всё быстродействие тех машин занял одним GC.
Нет, все быстродействие съедает неэффективная очередь, а не GC. Профайлер показывает что издержки на GC ничтожные.
Здравствуйте, Klapaucius, Вы писали:
AVK>>Одна проблема — формальное описание интересно в основном только математикам и любителям CS.
K>Так вы же сами писали K>
Соответствоенно, любая технология, пригодная для создания сложных программных продуктов, должна содержать удобные средства для:
K>1) Создания абстракций с формальным описанием внешних свойств
K>А теперь, когда оказалось, что с формальными описаниями у ООП все совсем не радужно — формальное описание стало вдруг никому не интересным?
Да что ж такое то — неужели так увлекательно заниматься подтасовками? Я писал про формальное описание сущностей решаемой задачи, ты же писал про формальное описание самого ООП.
K>Все, без чего объем писанины вырастает — это подпорка? Т.е. "подпорка" никаких отрицательных коннотаций не имеет? А если вы таки говорили "подпорка" так, как будто это что-то плохое — объясните что же плохо в карринге?
Какие то у вас приемчики все одинаковые. Я нигде ни разу не писал, что карринг это плохо. Это ты все плохое в ООП выискиваешь.
... << RSDN@Home 1.2.0 alpha 5 rev. 61 on Windows 7 6.1.7601.65536>>
Здравствуйте, vdimas, Вы писали:
V>Нету нулевого поколения. Сообщения принципиально должны обрабатываться после линии задержки.
Для для чего инстанцировать на момент попадания в очередь, если обработка будет после выхода из неё ?
>Длительность линии я тебя чуть приврал, на самом деле она плавающая, зависит от результата мониторинга разброса интервалов м/у пакетами в сети, но примерную верхнуюю границу указал верно. В нормальном режиме задержка порядка 100ms, но меня интересует худший случай, ес-но.
У меня в тесте тоже нет нулевого поколения. Так ты выдашь внятный тест или будешь и дальше сочинять ?
I>>Такое бывает в некоторых вырожденых сценариях, когда даже какой нибудь EventArgs создать не получается и GC педалит минутами. V>Вооот, а у нас реалтайм, мы не можем позволить GC педалить более ~50ms. Собственно, с этим борьба.
Ну так вы этот вырожденый сценарий сами же и заимплементили, ищите проблемы в управлении памятью, а не в пустых списках.
I>>Количество ветвлений ты не уменьшаешь, оно полностью сохраняется. Уменьшается количество инстанцирований, смотри внимательно: I>>
I>>return list ?? new ArrayList<T>();
I>>return list ?? Static<ArrayList<T>>.Instance;
I>>
V>Эта операция однократна, я тебе уже про пулы сказал... в отличие от операции обращения к полям.
То есть, про количество ветвлений был пустой прогон ?
I>>Соответсвенно экономия в перформансе за счет инстанцирований и GC, на тех цифрах, что ты показал, оно вообще не заметно. Экономию по памяти — это исправление ошибки дизайна низкоуровневой техникой.
V>Я пока не увидел никакой указанной тобой ошибки дизайна. Неужели, опять это началось? )))
Ну с тем, что ты чего то не видишь, никто и не спорит. см самое первое сообщение.
I>>Если от тебя примера не будет — не надо ничего писать, идёт ? V>Тебе от меня чего-то потребовать просто так захотелось? Я ведь могу и показать куда сходить и где поискать..
Будем считать что ты знаешь куда тебе идти, ок ?
V>Кароч, ты упомянул свой уже готовый тест — давай его сюда. Я над ним поработаю на досуге для доведения до похожих условий. Т.е. если тебе реально интересно — без проблем. (просто, помня твой стиль, вовсе не факт, что сие именно так, уж не обессудь )
У меня стиль простой — пока ты не выложишь внятную модель или жосткие данные я ничего выкладывать от себя не собираюсь.
>>> Про воссоздание образа очень занятно, проблема только в том, что ты описал воображение а не мышление. > > G>Это общий механизм мышления. > > Это общий механизм воссоздания образов, то есть воображения. Назвать это мышлением слишком сильно, нужно какое то подтверждение.
Вы оба почему-то думаете, что образное мышление и логическое это разные вещи, разные механизмы. Открою вам маленький не секрет — высшее логическое мышление это и есть образное. Физический механизм один и тот же. Нет у человека в голове специальной шишки мозга производящей числовые вычисления. Хотя некоторые структуры мозга бывают специализированными, но вот логической нет. Подтверждение? Легко. Вспомни как ты учил таблицу умножения. 2+2=4, 12^2=144 — ассоциативная выборка из памяти результата. Вот тебе и "высшая нервная деятельность" или "абстрактное мышление". То есть условно говоря, считаем деньги мы почти тем же местом, что и смотрим кино. В отдельной шишке не было необходимости, мы еще в позапрошлом веке все поголовно неграмотные были и считать почти не умели, все по памяти.
>>Мозг это ассоциативная память, любое мышление это последовательность снимков, наборов образов. > > Даже образное мышление трудно назвать набором образов, а есть еще понятийное, сиречь абстрактное мышление.
Понятийное мышление это полный синоним образного. Просто сложное понятие состоит из множества образов и связей.
>>Вообще добиться того, что бы следующий снимок не накладывался на предыдущий и не разрушал его, а это требуется для логического мышления, > > Не совсем ясно откуда следует что какой то снимок накладывается на предыдущий ? Это имеется ввиду какая то конкретная модель мышления ? Честно, в книгах по когнитивной психологии такого не встречал.
Скорее всего встречал, но в других формулировках или проявлениях. Не накладывается на предыдущий, а правильнее сказать образы интерферируют друг с другом. В силу разных вещей — мощность структур выборки образов меньше мощности всей памяти, место проявления образа задано физической структурой нейронов и плюс еще сам механизм ассоциативных связей дает эффект.
Здравствуйте, Ikemefula, Вы писали:
K>>Ну да. И K>>
Кто бы сомневался — с твоим то подходок к ФП как к серебряной пуле.
K>>тоже, наверное, я сам написал, залогинившись под вашим именем, ага?
I>Покажи где в процитированом ты увидел "неадекватность"
Я тут не первый день пишу и знаю, что утверждение "имярек относится к иксу как к серебряной пуле" здесь используется для того, чтоб сказать, что у собеседника закатились шарики за ролики, но без нарушений правил форума. Других применений у него нет. Рассуждения при этом следующие:
1) Серебряной пули нет. Не важно, о чем написано в статье Брукса, в ее критике, в ответе на критику. Выражение прошло через "меметическую мутацию" и сейчас обозначает "панацея, которой нет".
2) Человек, который считает, что нечто несуществующее существует — неадекватен. Поэтому его аргументы можно игнорировать.
Я с удовольствием прослушаю другие интерпретации этого выражения, но и из контекста его употребления следует то же толкование. Потому, что рядом же и поясняется, что экспертиза у меня слабая, а никаких других обоснований этого кроме того, что я якобы считаю что-то "серебряной пулей" не приводится.
Поясню сразу, что заострил я на этом внимание не потому что обиделся — просто воспользовался тем, что мой оппонент подставился и начал ответ в технической дискуссии с такого слабого аргумента как "а ты кто такой?".
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Здравствуйте, AndrewVK, Вы писали:
K>>Так вы же сами писали K>>
Соответствоенно, любая технология, пригодная для создания сложных программных продуктов, должна содержать удобные средства для:
K>>1) Создания абстракций с формальным описанием внешних свойств
K>>А теперь, когда оказалось, что с формальными описаниями у ООП все совсем не радужно — формальное описание стало вдруг никому не интересным?
AVK>Да что ж такое то — неужели так увлекательно заниматься подтасовками? Я писал про формальное описание сущностей решаемой задачи, ты же писал про формальное описание самого ООП.
Какие подтасовки? Вы собираетесь что-то формально описывать на языке, формальное описание которого при этом не собираетесь использовать? Это тоже такое "удобство", да? Каким вообще образом это можно осуществить?
И почему "формальное описание сущностей решаемой задачи" нужно и полезно, а "формальное описание сущностей используемых инструментов" наоборот — ненужно и не интересно?
AVK>Я нигде ни разу не писал, что карринг это плохо.
Ну вот вы пишете:
Сигнатура функции слишком примитивна, приходится даже на нижнем уровне вводить всякие подпорки типа карринга
Причем в качестве возражения на то, что дела в ФП получше обстоят. Извините, но я так понял, что указывается на что-то плохое. Выясняется, что подпорка — хорошо. Карринг — хорошо. ОК. Но тогда не могли бы вы в двух словах пояснить, в чем же упомянутая вами проблема заключается? Или нет никакой проблемы?
По поводу композиции и АлгТД возражений больше, как я понял, нет?
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Здравствуйте, Sinclair, Вы писали:
S>Поэтому в бухгалтерии гораздо полезнее модель, в которой счёт — это просто номер; даже не число, а идентификатор.
Тем не менее справочник счетов есть почти в любой реальной бухгалтерии. И там есть определенные данные. К примеру, во вполне реальной парусовой бухгалтерии у объекта Account есть такие свойства:
IAccountAnalyticDescriptorDetailCollection AnalyticDescriptors
Parus.Business.Bool Balance
Parus.Business.Bool InCurrency
AccountCode Code
Parus.Business.Note Note
IAccount Link
IAccountingKind AccountingKind
Parus.Net.Server.ISystemCatalog Catalog
IAccountCollection Children
IOperationJournal OperationJournal
Как видишь, довольно много состояния у объекта Account таки.
... << RSDN@Home 1.2.0 alpha 5 rev. 61 on Windows 7 6.1.7601.65536>>
S>В зависимости от реализации S>И идентичность у него может быть тоже совершенно разной. То, что тебе кажется одним и тем же объектом, окажется принципиально разными пятью, когда ты придёшь в банк.
и почему в границах моей системы меня должны волновать, как это устроено внутри банка? для меня это уже деталь реализации.
в границах моей системы есть объект — счет, у него есть идентификатор: z1tr5/bis, поэтому идентификатору я могу получить объект-счет хоть через инет-банк, хоть через банкомат, хоть через операциониста.
чего здесь не хватает?
DG>>во-первых, какое отношение определенность(или неопределенность) границы объекта имеет к идентичности? S>Очень простое — идентичность должна всегда давать однозначный результат. Для неё должны сохраняться требования транзитивности и симметричности. S>А "нечёткая" идентичность этому не будет соответствовать.
Вернемся к верёвке:
var rope = new Rope();
class Rope
{
public Rope()
{
this.Points = new double[100];
}
public double[] Points;
public RopeEnd Start
{
get { return new RopeEnd(this, 0); }
}
public RopeEnd End
{
get { return new RopeEnd(this, 1); }
}
}
class RopeEnd
{
public RopeEnd(Rope rope, int endNumber)
{
this.Rope = rope;
this.EndNumber = endNumber;
}
public readonly Rope Rope;
public readonly int EndNumber;
public override bool Equals(object obj)
{
var ropeEnd = obj as RopeEnd;
return object.Equals(this.Rope, ropeEnd != null ? ropeEnd.Rope : null)
&& EndNumber == (ropeEnd != null ? ropeEnd.EndNumber : (int?)null);
}
public override int GetHashCode()
{
return this.Rope.GetHashCode() ^ this.EndNumber;
}
static Random rnd = new Random();
public void Change(double x)
{
var points = this.Rope.Points;
if (EndNumber != 0)
points = points.Reverse().ToArray();
var len = rnd.Next(30);
points = points.Select((v, i) => {var r = len - i; return r > 0 ? v + x * r / len : v;}).ToArray();
if (EndNumber != 0)
points = points.Reverse().ToArray();
this.Rope.Points = points;
}
}
rope.Start и rope.End являются объектами? идентичность у них есть?
граница RopeEnd относительно Rope задана однозначно или задана нечетко?
Здравствуйте, DarkGray, Вы писали:
DG>вот, например, счет Xxx при доступе через инет-банк, банкомат и операциониста — это один и тот же счет или разный?
Вы говорите о разных вещах. Синклер о бухгалтерском счете, ты о банковском. Это совсем не одно и тоже. В случае бухгалтерского счета в реальных системах действительно, никто не хранит в этом счете операции. Операции между счетами, проводки, это независимые сущности, которые всегда ссылаются на два счета в справочнике счетов — дебетовый и кредитный. Поведения у самого счета никакого нет, это просто маркер. Формируют проводки как правило специальные процедуры (методы сервисов), в особо запущенных случаях (1С) проводки формирует бухгалтерский документ. В результате хребет всех бухгалтерских данных это журнал проводок, большая часть остального навешивается на него по ссылкам, а счет это просто запись в справочнике с некоторым набором метаданных.
... << RSDN@Home 1.2.0 alpha 5 rev. 61 on Windows 7 6.1.7601.65536>>
AVK>Вы говорите о разных вещах. Синклер о бухгалтерском счете, ты о банковском. Это совсем не одно и тоже.
Согласен, но при этом бух. счет все равно есть ООП-объект.
AVK> В случае бухгалтерского счета в реальных системах действительно, никто не хранит в этом счете операции.
какая разница где хранится состояние объекта? это деталь реализации
AVK> Операции между счетами, проводки, это независимые сущности, которые всегда ссылаются на два счета в справочнике счетов — дебетовый и кредитный. Поведения у самого счета никакого нет, это просто маркер.
Скорее ты хочешь сказать, что у бух. счета нет атомарного поведения, все его поведение композитное и выражается через поведение других объектов, но при этом не правильно утверждать, что у счета нет поведения.
композитная операция следующего вида у счета никуда не девается:
и во многих случаях — эта операция удобнее, чем напрямую лезть в журнал счетов
Нал.Провести(-20000, Основные_Фонды, "Компьютер для Васи Пупкина");
AVK> Формируют проводки как правило специальные процедуры (методы сервисов), в особо запущенных случаях (1С) проводки формирует бухгалтерский документ. В результате хребет всех бухгалтерских данных это журнал проводок, большая часть остального навешивается на него по ссылкам, а счет это просто запись в справочнике с некоторым набором метаданных.
здесь ты также про детали реализации, и о том, как можно построить "скелет" бух. системы, используя минимальное кол-во сущностей и минимальное кол-во кода.
Здравствуйте, DarkGray, Вы писали:
AVK>> В случае бухгалтерского счета в реальных системах действительно, никто не хранит в этом счете операции.
DG>какая разница где хранится состояние объекта? это деталь реализации
При чем тут реализация? Даже на уровне дизайна системы никаких отношений принадлежности между проводкой и счетом нет. Тебе уже несколько раз сказали — проводка ссылается минимум на два счета. К какому из них она относится?
DG>Скорее ты хочешь сказать, что у бух. счета нет атомарного поведения, все его поведение композитное и выражается через поведение других объектов
Нет, я хочу сказать ровно то что сказал.
DG>композитная операция следующего вида у счета никуда не девается: DG>
Нет такого, я же явно написал. В реальности есть такое:
class DocTxService
{
public Tx[] MakeDocTx(Document doc) {...}
}
// Или в стиле 1Cclass Document
{
public Tx[] MakeTx();
}
DG>и во многих случаях — эта операция удобнее, чем напрямую лезть в журнал счетов
Что значит лезть? В бухгалтерии любые проводки делаются исключительно на основании документов. Нельзя просто взять, и сделать проводку без основания (в 1С можно, но это бред). Таким образом, документ есть всегда. А вот конкретные счета вычисляются на основании все того же документа в методе формировапния проводки.
DG>здесь ты также про детали реализации
Нет, здесь лично я — исключительно про дизайн.
... << RSDN@Home 1.2.0 alpha 5 rev. 61 on Windows 7 6.1.7601.65536>>
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, samius, Вы писали:
S>>Ветвление в рассуждениях оставь при себе. Оно не интересует в обсуждаемом аспекте.
V>Какое мне дело, что именно тебя не интересует?
если нет дела, то пиши, пиши. А я буду скипать, скипать. Только без обид.
S>>Еще раз. Речь идет об ветвлении исполнения стейтментов,
V>Речь идёт о ветвлении как таковом. Остальное — твои личные фантазии и неуклюжие попытки ограничить меня уютными тебе рамками.
Давай заглянем в http://en.wikipedia.org/wiki/Structured_program_theorem
там написано очень конкретно что требуется не ветвление, а выполнение.
In other words, any algorithm can be expressed using only three control structures. They are
1 Executing one subprogram, and then another subprogram (sequence)
2 Executing one of two subprograms according to the value of a boolean expression (selection)
3 Executing a subprogram until a boolean expression is true (iteration)
видишь ли, под пунктом 2 управляющая структура, которая выполняет подпрограммы. хаскель-if их не выполняет, а лишь выбирает ветку. У нас есть гарантия что выбранная ветка будет вычислена хоть когда-нибудь?
По другим пунктам тоже можно поглядеть.
1. — сиквенсинг в хаскеле нужен лишь для организации побочных эффектов. Никакое вычисление в нем не нуждается. А Бём-Якопини говорили именно о вычислении функций. Вобщем первый пункт пролетает.
3. Выполнение подпрограммы пока ...уже бессмыслица в хаскеле, т.к. подпрограмма это выражение, которое сколько не выполняй, результат будет тот же самый ... пока булево выражение является true — тоже бессмысленно, т.к. в хаскеле выражение чему равно, тому и равно, сколько его не вычисляй, и выполнение подпрограммы на результат выражения не влияет.
В итоге, все 3 пункта не о хаскеле.
S>>В программе на хаскеле изменяемые состояния не описываются. Пока не продемонстрируешь побочный эффект If-а на хаскеле, говорить дальше не о чем.
V>Я про возможность применения его в IO без каких-либо доработок вроде бы сказал сразу, не? Тебе это сколько еще повторять? Побочный эффект возникает ПОСЛЕ применения if, ес-но, как результат выполнения хвоста в цепочке IO-вычислений.
Так это побочный эффект не от if-а, конечно же. Это побочный эффект от выполнения действия, вернувшегося в качестве результата вычисления ветки. Если внимательно, то if тебе вернул ветку, результатом которой когда-то будет являться действие. Так вот, когда это действие получит мир, оно его испортит. Только причем тут if?
Да и что ты носишься с этим IO? Побочные эффекты на вычислимость функций не влияют и для вычислений не требуются.
V>Ес-но не в момент вычисления предиката при if, а в момент прохождения потока вычисления только по одной из двух веток, описанных в исходнике.
Еще раз. В момент прохождения потока вычисления по ветке мы получим лишь IO a, которое само по себе чисто. А грязь будет только когда мы IO a скормим мир.
V>Это явное переключение потока исполнения. И ты мне так и не показал принципиальное отличие от императива для такого случая применения if. ИМХО, там всей разницы, что в императиве мы переводим стрелки непосредственно перед поездом, а в Хаскеле — немного раньше, а поезд пускаем затем по уже сформированному пути. Но кроме бла-бла я так и не услышал от тебя внятных пояснений, почему ты эти два сценария считаешь принципиально различными? Сможешь без юления четко сформулировать свою мысль?
выше две мысли. Одна — if не выполняет ветки, вторая — (*)побочные эффекты не влияют на вычислимость функций, о которой писали авторы теоремы.
Если ты хочешь притянуть за уши ФП к СП, то тебе придется обойтись без IO. Потому что (*). А так же потому что имея IO, мы можем на ФП спародировать любую императивную программу. Но ведь ФП Тьюринг-полна вовсе не потому что IO, так ведь?
Здравствуйте, grosborn, Вы писали:
>>>> Про воссоздание образа очень занятно, проблема только в том, что ты описал воображение а не мышление. >> >> G>Это общий механизм мышления. >> >> Это общий механизм воссоздания образов, то есть воображения. Назвать это мышлением слишком сильно, нужно какое то подтверждение.
G>Вы оба почему-то думаете, что образное мышление и логическое это разные вещи, разные механизмы. Открою вам маленький не секрет — высшее логическое мышление это и есть образное.
Пруф.
>Физический механизм один и тот же. Нет у человека в голове специальной шишки мозга производящей числовые вычисления. Хотя некоторые структуры мозга бывают специализированными, но вот логической нет. Подтверждение? Легко. Вспомни как ты учил таблицу умножения. 2+2=4, 12^2=144 — ассоциативная выборка из памяти результата. Вот тебе и "высшая нервная деятельность" или "абстрактное мышление".
Это просто память а не абстрактное мышление. Абстрактное это возмжность представлять одно и то же разными способами.
>То есть условно говоря, считаем деньги мы почти тем же местом, что и смотрим кино. В отдельной шишке не было необходимости, мы еще в позапрошлом веке все поголовно неграмотные были и считать почти не умели, все по памяти.
А тесты показывают, что кровоток в мозгу выглядит совершенно по разному.
>> Даже образное мышление трудно назвать набором образов, а есть еще понятийное, сиречь абстрактное мышление.
G>Понятийное мышление это полный синоним образного. Просто сложное понятие состоит из множества образов и связей.
Нет, это дихотомия.
>> Не совсем ясно откуда следует что какой то снимок накладывается на предыдущий ? Это имеется ввиду какая то конкретная модель мышления ? Честно, в книгах по когнитивной психологии такого не встречал.
G>Скорее всего встречал, но в других формулировках или проявлениях. Не накладывается на предыдущий, а правильнее сказать образы интерферируют друг с другом. В силу разных вещей — мощность структур выборки образов меньше мощности всей памяти, место проявления образа задано физической структурой нейронов и плюс еще сам механизм ассоциативных связей дает эффект.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, samius, Вы писали:
S>>Пока не продемонстрируешь побочный эффект If-а на хаскеле, говорить дальше не о чем.
V>Кстате, хотел бы я увидеть побочный эффект на операторе if для императивного языка. Будем считать, что ветвимся по уже вычисленной переменной. Дерзай.
AVK>Тебе уже несколько раз сказали — проводка ссылается минимум на два счета. К какому из них она относится?
ты мне сейчас рассказываешь про SRP. SRP никакого отношения к объектной оболочке отношения не имеет, а имеет отношение лишь к процессу хранения состояния.
SRP никак не мешает иметь два метода, которые делают похожую работу:
class БухСчет
{
public Tx[] Оплатить(БухСчет target, Товарный_Чек чек)
{
return DocTxService.MakeDocTx(CreateDocument(this, target, чек));
}
public Tx[] ОплатитьИз(БухСчет source, Товарный_Чек чек)
{
return DocTxService.MakeDocTx(CreateDocument(source, this, чек));
}
}
и соответственно, обе следующие операции равноправны:
[c#]
Нал.Оплатить(Основные_Фонды, new Товарный_Чек("Компьютер Pentium", 20000, "ИП Пупкин и сыновья", ...));
//или
Основные_Фонды.Оплатить_Из(Нал, new Товарный_Чек("Компьютер Pentium", 20000, "ИП Пупкин и сыновья", ...));