Этот код не полон. Перед тем, как параллелить, сначала типы поправьте: результат должен быть числом, что делать с OptionalLong, почему и зачем?
Был код, который решал задачу, вы его сломали и спрашиваете как починить? Не знаю, что может быть лучше, чем откатить коммит :) Вы хорошо разбираетесь в вопросе — ваш первый комментарий это показал. Уверен, вы правы, только я не понимаю постановку задачи, которую вы решаете — она у вас в голове. Ветка дискуссии разрослась, поэтому прошу в личку.
К сожалению, только читать бесполезно, хоть 5, хоть 1000 раз. В том посте ошибка — "определение" надо переназывать "понятиями" — сам только недавно научился различать. Прочитав множество имён снега, вы не научитесь ими пользоваться. Попробуйте написать для детей простой туториал езды на велосипеде. Мы можем понять друг друга только в деятельности.
Человеку вот понравилось описание функторов и монад, но думаю только потому, что он уже достаточно попрактиковался, наработал понятие и прочувствовал несколько примеров монад, чтобы их сравнить и найти между ними что-то общее.
А если считать действительно сумму, без инициализации аккумулятора нулем?
Без примера кода точный смысл этого высказывания мне не ясен: инициализировать его чем-то другим, чтобы что сделать? Какой тезис обсуждаем?
Знаю только, что в неотрицательной сумме нет отрицательных чисел ни в начальном балансе S, ни в промежуточном балансе (в том числе в S⊞a), ни даже в названии :) А из ложной посылки (S отрицательно) можно вывести всё, что угодно, так что заранее согласен.
Пример с x=-2 понятен, действительно, в этом случае будут проблемы, но не у grosum. Дальше зависит от договорённостей, что такое общий случай :) Я предполагаю fall и grow неотрицательными, как у Гротендика, соответственно, x не может быть -2. В посте я ухожу даже от плавающей точки, чтобы не касаться неассоциативности при округлении. Опущены даже вопросы переполнения long. Множество других вопросов остаются на совести разработчика приложения.
Но алгоритм из поста, grosum [-2, 1, 2] = 3 = grosum [1, 2] = grosum [3]. Алгоритм, который вернёт 2 или 1 — это некий другой, модифицированный алгоритм. Прежде чем рассуждать о нём, сначала необходимо зафиксировать его код.
Возможно, @mayorovp меня поправит, что он имел в виду. Я за круглым плюсом ⊕ вижу 2 смысла. Чтобы их не путать, введём квадратный плюс ⊞.
⊖fall отрицательный морфизм;
⊕grow положительный морфизм;
a ⊞ b = max(0, a + b) = relu(a + b), неудобная неассоциативная бинарная операция;
кусок истории ((((x ⊞ a) ⊞ b) ⊞ c) ⊞ …) представим смесью морфизмов, парой (⊖fall, ⊕grow).
Да, считаем (((0 ⊞ a) ⊞ b) ⊞ c) ⊞ …, как будто начинаем с пустого склада. Не забываем про неявные скобочки левой свёртки.
В общем случае верны оба:
(x ⊞ 1) ⊞ 2 = x ⊞ 3. Но неассоциативно.
(⊕1)∘(⊕2) = (⊕3). Ассоциативно и в длинных скобки можно выражениях скобки можно опускать ⊕a∘⊕b∘⊕c = ⊕(a+b+c). Но представление не полно, нужны ещё отрицательные морфизмы ⊖, для записи произвольной истории нужна пара (⊖fall, ⊕grow).
Очень правильный вопрос. Подобрать подходящий инструмент под задачу и наоборот — полдела к успеху в любом начинании. Могу предложить варианты для grosum:
Кладовщик ограничен максимальной пропускной способностью — на входе потенциальный расход, а не фактический, который меньше.
Банкомат выдаёт максимум, сколько может.
Глязные данные, которые нужно почистить online или offline.
Запоздалые транзакции оформлены задним числом. Нужно быстро инкрементально за O(ln n) пересчитать хвост журнала.
Есть два подхода к программированию. Первый — сделать программу настолько простой, чтобы в ней очевидно не было ошибок. А второй — сделать её настолько сложной, чтобы в ней не было очевидных ошибок.
Зависит от целей, а не от того, что это склад. У нас, например, оптимизационная NP задача составления расписаний сотрудников, в том числе на складе. А быстрый инкрементальный пересчёт позволил считать на ноутбуке, а не на кластере.
Абстракция отличается от реальности и выбирать нужно подходящую под действия. grosum ничем не лучше и не хуже sum — ещё один кирпичик конструктора приложений.
Кстати, в поле fall накопится сумма, которую нужно сторнировать, чтобы баланс сошёлся. Тоже может быть кому-нибудь полезно.
Историческая справка. Перевод trait как "типаж" возник при чтении первой книги по Scala и был выбран при следующих ограничениях в порядке приоритета: он должен был быть
ассоциирован с дословным переводом (черта)
и функциональной нагрузкой (тип),
не перерегруженным,
желательно кратким (2 слога)
и в чём-то созвучным с оригиналом (первая буква "т").
Этот перевод выиграл у конкурента "черта", который обладал только пунктами 1, 3 и 4.
Поэтому не надо пытаться дать общее определение ООП (если вы не можете этого сделать).
Я могу и дал и думаю, никто не сможет дать определение, в котором будет больше полезной информации. Хоть какое-то определение лучше, чем никакого. Возможно, кому-то оно окажется полезно потому, что он не станет вкладывать в ООП какой-то сакральный смысл.
Вторая круговая диаграмма "Программные изделия с большой длительностью эксплуатации".
Вот именно, что свои. В ситуации быстрого выхода на рынок будет 70/30, дальше понятно, что будет?
Открою секрет, для вашего проекта и формула будет другой. Считать в любом случае вам. Но лучше знать о большем числе вариантов.
Да ну? Я вот точно знаю, что это далеко не маленькая проблема, потому что реальных цифр для конкретного проекта нет.
Я говорил, что риски — ещё большая проблема. Проблем много. Другой инструмент даёт другой баланс. Ещё раз, считать и принимать решение все равно вам.
Дадада, именно: "Эти термины не являются однозначно трактуемыми, и чаще всего используются для указания на достоинства и недостатки конкретного языка".
Неоднозначность в этих определениях не влияет на ошибки в продакшн, в отличие от NullPointerException, поэтому меня не сильно беспокоит. Зато это размытое определение направляет меня выбрать инструмент, который уменьшит ошибки на продакшн.
Основной код в функциях: в моём пруфе 1 строка объявления пользовательских данных из 30. Комментариев и пустых строк обычно больше. Это типичный код. И эта строка сэкономила ещё 30+ строк на тестах.
"… class-based inheritance… is when… class is based on another… class, using the same implementation"
Больше похоже на тавтологию. А что такое "based, using the same implementation". Делегирование тоже подходит: мы использует ту же реализацию.
Я скептически отношусь к определениям на человеческом языке и считаю, что нет смысла их оттачивать до бесконечности, как нет смысла стремиться к 100% покрытию кода тестами: всегда останутся непокрытые ветки и зыбкие аксиомы. Стремиться к 100% корректности имеет смысл только в формальных языках, Coq какой-нибудь.
P.S. Лимит времени на обсуждение у меня вышел. Ещё раз спасибо.
Ну так "плюс" же. Одним кортежем обойтись не удалось.
Кортеж здесь только для облегчения восприятия, синтаксический сахар для кодировки Чёрча, выражающей все конструкции через функции. Но это уже за границами данного поста. Функция по умолчанию подразумевается в ФП, как следует из названия.
(и это мы еще в тонкие вопросы инкапсуляции не вдавались)
Инкапсуляция, модульная система реализуется на замыканиях, за примером обратитесь к JavaScript.
Но это же не значит, что просто переменные — это аналог кортежа?
Даже больше, машинные инструкции аналогичны бизнес требованиям: бизнес формулирует условия на своём языке, вы строите ООП или ФП абстракции в голове и кодируете их на своём любимом языке, компилятор убирает все ваши абстракции. Но в итоге готовый бинарник — изоморфен бизнес требованиям. И доказывает это приёмочное тестирование.
А вы не знаете, есть у него состояние, или нет. Вы знаете только то, что у него есть такие-то методы, которые то-то делают.
Слово "заменить" означает, например, что я разрабатываю этот класс или провожу рефакторинг и обязан знать внутренности.
Я что-то не помню, чтобы ООП в целом требовало какого-то equals(Object), и не понимаю, где здесь косяк.
В этом и есть моя претензия к ООП, как "набору идей без единого центрального стержня". Оно скользкое, как угорь и многоглавое, как гидра. Оно не требует ничего конкретного и не даёт никакой статической информации, соответственно о нём невозможно рассуждать и выводить полезные свойства.
А вот я в вас верю. Не держите в себе, пишите, улучшайте!
Этот код не полон. Перед тем, как параллелить, сначала типы поправьте: результат должен быть числом, что делать с
OptionalLong, почему и зачем?Был код, который решал задачу, вы его сломали и спрашиваете как починить? Не знаю, что может быть лучше, чем откатить коммит :) Вы хорошо разбираетесь в вопросе — ваш первый комментарий это показал. Уверен, вы правы, только я не понимаю постановку задачи, которую вы решаете — она у вас в голове. Ветка дискуссии разрослась, поэтому прошу в личку.
К сожалению, только читать бесполезно, хоть 5, хоть 1000 раз. В том посте ошибка — "определение" надо переназывать "понятиями" — сам только недавно научился различать. Прочитав множество имён снега, вы не научитесь ими пользоваться. Попробуйте написать для детей простой туториал езды на велосипеде. Мы можем понять друг друга только в деятельности.
Человеку вот понравилось описание функторов и монад, но думаю только потому, что он уже достаточно попрактиковался, наработал понятие и прочувствовал несколько примеров монад, чтобы их сравнить и найти между ними что-то общее.
Без примера кода точный смысл этого высказывания мне не ясен: инициализировать его чем-то другим, чтобы что сделать? Какой тезис обсуждаем?
Знаю только, что в неотрицательной сумме нет отрицательных чисел ни в начальном балансе
S, ни в промежуточном балансе (в том числе вS⊞a), ни даже в названии :) А из ложной посылки (Sотрицательно) можно вывести всё, что угодно, так что заранее согласен.Пример с
x=-2понятен, действительно, в этом случае будут проблемы, но не уgrosum. Дальше зависит от договорённостей, что такое общий случай :) Я предполагаюfallиgrowнеотрицательными, как у Гротендика, соответственно,xне может быть-2. В посте я ухожу даже от плавающей точки, чтобы не касаться неассоциативности при округлении. Опущены даже вопросы переполненияlong. Множество других вопросов остаются на совести разработчика приложения.Но алгоритм из поста,
grosum [-2, 1, 2] = 3 = grosum [1, 2] = grosum [3]. Алгоритм, который вернёт2или1— это некий другой, модифицированный алгоритм. Прежде чем рассуждать о нём, сначала необходимо зафиксировать его код.Возможно, @mayorovp меня поправит, что он имел в виду. Я за круглым плюсом ⊕ вижу 2 смысла. Чтобы их не путать, введём квадратный плюс ⊞.
⊖fall отрицательный морфизм;
⊕grow положительный морфизм;
a ⊞ b = max(0, a + b) = relu(a + b), неудобная неассоциативная бинарная операция;кусок истории ((((x ⊞ a) ⊞ b) ⊞ c) ⊞ …) представим смесью морфизмов, парой
(⊖fall, ⊕grow).Да, считаем (((0 ⊞ a) ⊞ b) ⊞ c) ⊞ …, как будто начинаем с пустого склада. Не забываем про неявные скобочки левой свёртки.
В общем случае верны оба:
(x ⊞ 1) ⊞ 2 = x ⊞ 3. Но неассоциативно.(⊕1)∘(⊕2) = (⊕3). Ассоциативно и в длинных скобки можно выражениях скобки можно опускать⊕a∘⊕b∘⊕c = ⊕(a+b+c). Но представление не полно, нужны ещё отрицательные морфизмы⊖, для записи произвольной истории нужна пара(⊖fall, ⊕grow).Фух! Сложно объяснить простой код :(
ФП не так далеко от ООП, как принято считать. Хотя одни и те же вещи называют разными именами.
Очень правильный вопрос. Подобрать подходящий инструмент под задачу и наоборот — полдела к успеху в любом начинании. Могу предложить варианты для
grosum:Кладовщик ограничен максимальной пропускной способностью — на входе потенциальный расход, а не фактический, который меньше.
Банкомат выдаёт максимум, сколько может.
Глязные данные, которые нужно почистить online или offline.
Запоздалые транзакции оформлены задним числом. Нужно быстро инкрементально за O(ln n) пересчитать хвост журнала.
Tony Hoare
Зависит от целей, а не от того, что это склад. У нас, например, оптимизационная NP задача составления расписаний сотрудников, в том числе на складе. А быстрый инкрементальный пересчёт позволил считать на ноутбуке, а не на кластере.
Абстракция отличается от реальности и выбирать нужно подходящую под действия.
grosumничем не лучше и не хужеsum— ещё один кирпичик конструктора приложений.Кстати, в поле
fallнакопится сумма, которую нужно сторнировать, чтобы баланс сошёлся. Тоже может быть кому-нибудь полезно.? в копилку объяснений
Стехнопорно, предупреждал же, уберите домочадцев от экрана с клавиатурой )
Историческая справка. Перевод trait как "типаж" возник при чтении первой книги по Scala и был выбран при следующих ограничениях в порядке приоритета: он должен был быть
Этот перевод выиграл у конкурента "черта", который обладал только пунктами 1, 3 и 4.
Я могу и дал и думаю, никто не сможет дать определение, в котором будет больше полезной информации. Хоть какое-то определение лучше, чем никакого. Возможно, кому-то оно окажется полезно потому, что он не станет вкладывать в ООП какой-то сакральный смысл.
Вторая круговая диаграмма "Программные изделия с большой длительностью эксплуатации".
Открою секрет, для вашего проекта и формула будет другой. Считать в любом случае вам. Но лучше знать о большем числе вариантов.
Я говорил, что риски — ещё большая проблема. Проблем много. Другой инструмент даёт другой баланс. Ещё раз, считать и принимать решение все равно вам.
Неоднозначность в этих определениях не влияет на ошибки в продакшн, в отличие от NullPointerException, поэтому меня не сильно беспокоит. Зато это размытое определение направляет меня выбрать инструмент, который уменьшит ошибки на продакшн.
Основной код в функциях: в моём пруфе 1 строка объявления пользовательских данных из 30. Комментариев и пустых строк обычно больше. Это типичный код. И эта строка сэкономила ещё 30+ строк на тестах.
"… class-based inheritance… is when… class is based on another… class, using the same implementation"
Больше похоже на тавтологию. А что такое "based, using the same implementation". Делегирование тоже подходит: мы использует ту же реализацию.
Я скептически отношусь к определениям на человеческом языке и считаю, что нет смысла их оттачивать до бесконечности, как нет смысла стремиться к 100% покрытию кода тестами: всегда останутся непокрытые ветки и зыбкие аксиомы. Стремиться к 100% корректности имеет смысл только в формальных языках, Coq какой-нибудь.
P.S. Лимит времени на обсуждение у меня вышел. Ещё раз спасибо.
Кортеж здесь только для облегчения восприятия, синтаксический сахар для кодировки Чёрча, выражающей все конструкции через функции. Но это уже за границами данного поста. Функция по умолчанию подразумевается в ФП, как следует из названия.
Инкапсуляция, модульная система реализуется на замыканиях, за примером обратитесь к JavaScript.
Даже больше, машинные инструкции аналогичны бизнес требованиям: бизнес формулирует условия на своём языке, вы строите ООП или ФП абстракции в голове и кодируете их на своём любимом языке, компилятор убирает все ваши абстракции. Но в итоге готовый бинарник — изоморфен бизнес требованиям. И доказывает это приёмочное тестирование.
Слово "заменить" означает, например, что я разрабатываю этот класс или провожу рефакторинг и обязан знать внутренности.
В этом и есть моя претензия к ООП, как "набору идей без единого центрального стержня". Оно скользкое, как угорь и многоглавое, как гидра. Оно не требует ничего конкретного и не даёт никакой статической информации, соответственно о нём невозможно рассуждать и выводить полезные свойства.