Судя по описанию того случая — «рабочий» является единственным преимуществом над бюрократией. И даже вы хотели бы посмотреть на утвержденную документацию по функциональности — это бесполезно, потому что разработчики на нее забили.
Совершенно техническое — у меня на Хабре постоянно появляется «Ошибка при установлении защищённого соединения» в Firefox. С чем это может быть связано, может кто знает?
Может быть стоит. Но насколько я знаю, в хаскеле класс это по сути способ задания полиморфной функции, а не изменения существующих. Атрибуты .net — это просто метаданные. И вы конечно можете создать аттрибут, который будет говорить сгенерировать версию данной функции, принимающую данный изоморфизм, но это ничего не изменит.
Неа. unlazy (точнее, fromLazy) это (() -> a) -> a, как вы сами записали. И это морфизм из ()->a в a, который соответственно не является эндоморфизмом, а следовательно и автоморфизмом.
И закапывание в матаппарат не отменяет практической части вопроса.
Автоморфизм — это изоморфизм из множества в то же самое множество. В частности вот id — автоморфизм. А curry\uncurry и lazy\unlazy — нет. Ровно так же add и add' принадлежат к разным множествам функций. И компилятор совершенно прав с точки зрения компилятора. И имелось в виду, что хотя вам очевидно, что add и add' выполняют одинаковую задачу, компилятор такого вывода сделать не может. Но это всё теория.
Переходя к практике — во всех языках программирования есть такая абстракция как «вызов функции». Так вот, в add 2 2 вы получаете результат за 1 вызов, а в add' 2 2 — за 2 вызова. И это объективно разница с точки зрения компилятора, потому что между этими двумя вызовами может быть всё что угодно.
Слегка ошибся. Биекция, но не автоморфизм.
Проще говоря, хотя эти функции являются обертками над '+', они отличаются. И компилятор совершенно прав, что не даёт одно подставить на место другого. Он не имеет права считать, что если вы имеете a и a->b и хотите получить b, вы сделаете эти именно путем вызова a->b с параметром a.
Это биекция, но не изоморфизм. Потому что множества функций — разные. You're not my kind, так сказать.
Ну и как вы перешли к критике ООП, на самом деле тоже непонятно.
Если вас не смущает оверхед, то выделяем память кусками степени 2. Если у нас нет сейчас достаточно маленького куска, делим один из имеющихся на половины. Соответственно если обе половины какого-то куска свободны, мы их объединяем обратно.
Это даже как-то называется, но я не помню как)
В таком решении вы мешаете чисто клиентскую декоративную логику — анимацию — с серверной бизнес-логикой — зачислением денег. А это может привести к проблемам.
Например, если вы командой запускаете катсцену при убийстве босса, и в конце её зачисляете награду за убийство. А другой человек реализует функциональность пропуска катсцен — отменой команды. Или же игрок босса добил, а анимацию решил не смотреть и перезагрузил страничку, скажем. И в результате игрок не получает награду.
Не знаю, насколько вероятен такой пример в реальности, но предложение автора — отдельные события «обновить деньги на сервере» и «показать обновление денег клиенту» мне нравится больше.
Без алгоритма — не могу вам помочь, я его уже придумал и написал. ))
А касательно ограничений, тут у нас имеется главное ограничение «мы можем налить в клетку воды до уровня n, если нет путей по другим клеткам с высотой не больше n-1 от данной клетки до края». И при этом высоты жидкости не зависят друг от друга, можно последовательно подбирать.
Осталось придумать, как выразить такое на Прологе?
Давайте будем перебирать клетки в порядке возрастания высоты.
Если от клетки, которую мы рассматриваем сейчас, нет пути до края по уже рассмотренным клеткам — мы можем налить в неё сколько-то воды сверх её высоты.
Соответственно, если мы рассмотрели какую-то клетку и при этом от другой рассмотренной появился путь до края(через рассмотренную сейчас клетку) — значит, мы в эту другую можем налить воды до уровня рассмотренной сейчас.
Чтобы сделать это быстро, объединим находящиеся рядом рассмотренные клетки в множества, и для каждого множества будем хранить количество клеток в нём, общую высоту и есть ли сейчас путь из клеток этого множества к краю. Соответственно, множества нужно уметь соединять и быстро вычислять, к какому множеству относится клетка. И обновлять ответ, когда объединяем множество с путем к краю и множество без пути.
Такое называется «система непересекающихся множеств» и есть алгоритм, который обе операции делает почти за константное время.
Простите, «быстро»? Тут у вас максимальный тест — 10*10. А пробовали ли вы сгенерировать тест хотя бы 110*110, как написано в условии, и запустить на нем?
Хорошее решение такой задачи вообще должно выполняться до одной секунды при m*n около 200000, и высотах до 10^9 (дабы не требовалась длинная арифметика). И то потому что я пока не вижу, как выбросить сортировку. Без неё можно и до миллиона добраться.
Так что универсальный решатель зачастую не сможет эффективно найти решение, несмотря на ограничения. Конечно, можно попробовать решить им задачу, для которой вы уже сформировали хорошие ограничения, но не можете придумать эффективный алгоритм решения. Но такое работает только на маленьких данных.
Так если бы локальную. Про неё в описании бага ничего не сказано.
Тут похоже разработчик ожидал, что доменное имя строго на английском, и адрес @емейл.рф считает невалидным.
И закапывание в матаппарат не отменяет практической части вопроса.
Переходя к практике — во всех языках программирования есть такая абстракция как «вызов функции». Так вот, в add 2 2 вы получаете результат за 1 вызов, а в add' 2 2 — за 2 вызова. И это объективно разница с точки зрения компилятора, потому что между этими двумя вызовами может быть всё что угодно.
Проще говоря, хотя эти функции являются обертками над '+', они отличаются. И компилятор совершенно прав, что не даёт одно подставить на место другого. Он не имеет права считать, что если вы имеете a и a->b и хотите получить b, вы сделаете эти именно путем вызова a->b с параметром a.
Ну и как вы перешли к критике ООП, на самом деле тоже непонятно.
Это даже как-то называется, но я не помню как)
Например, если вы командой запускаете катсцену при убийстве босса, и в конце её зачисляете награду за убийство. А другой человек реализует функциональность пропуска катсцен — отменой команды. Или же игрок босса добил, а анимацию решил не смотреть и перезагрузил страничку, скажем. И в результате игрок не получает награду.
Не знаю, насколько вероятен такой пример в реальности, но предложение автора — отдельные события «обновить деньги на сервере» и «показать обновление денег клиенту» мне нравится больше.
А касательно ограничений, тут у нас имеется главное ограничение «мы можем налить в клетку воды до уровня n, если нет путей по другим клеткам с высотой не больше n-1 от данной клетки до края». И при этом высоты жидкости не зависят друг от друга, можно последовательно подбирать.
Осталось придумать, как выразить такое на Прологе?
Если от клетки, которую мы рассматриваем сейчас, нет пути до края по уже рассмотренным клеткам — мы можем налить в неё сколько-то воды сверх её высоты.
Соответственно, если мы рассмотрели какую-то клетку и при этом от другой рассмотренной появился путь до края(через рассмотренную сейчас клетку) — значит, мы в эту другую можем налить воды до уровня рассмотренной сейчас.
Чтобы сделать это быстро, объединим находящиеся рядом рассмотренные клетки в множества, и для каждого множества будем хранить количество клеток в нём, общую высоту и есть ли сейчас путь из клеток этого множества к краю. Соответственно, множества нужно уметь соединять и быстро вычислять, к какому множеству относится клетка. И обновлять ответ, когда объединяем множество с путем к краю и множество без пути.
Такое называется «система непересекающихся множеств» и есть алгоритм, который обе операции делает почти за константное время.
Хорошее решение такой задачи вообще должно выполняться до одной секунды при m*n около 200000, и высотах до 10^9 (дабы не требовалась длинная арифметика). И то потому что я пока не вижу, как выбросить сортировку. Без неё можно и до миллиона добраться.
Так что универсальный решатель зачастую не сможет эффективно найти решение, несмотря на ограничения. Конечно, можно попробовать решить им задачу, для которой вы уже сформировали хорошие ограничения, но не можете придумать эффективный алгоритм решения. Но такое работает только на маленьких данных.
Тут похоже разработчик ожидал, что доменное имя строго на английском, и адрес @емейл.рф считает невалидным.