А тут действительно может быть подвох что более длинное решение не обязательно станет оптимальным. По регулярному выражению строится конечный автомат и всё зависит насколько он станет оптимальным, с учётом что при разборе могут случаться бектрекинги
Да получается забавно, что исходной задаче, если ее реализовать в лоб на каком нибудь языке простым автоматом состояний, то ей не нужны никакие ни бектрекинги ни рекурсии, Надо просто идти по графу и определить на какой ноде поток цифр закончится. Но после всех этих преобразований из машины состояний в регулярку и обратно могут рождаться какие то монстры.
Если решить исходную задачу деления на 7, то откроется список решений других пользователей и среди них можно найти решение более общей задачи - для любого делителя. Оно оказалось совсем не большое, но код правда на Haskell
Рекурсия может потребовать стек для хранения переходов, а стек в свою очередь может быть overflow в запущенных случаях. Как минимум от этой проблемы избавимся, так как на выходе получили дерево разбора уложенное в плоскую строку, требующее хранение только текущей позиции в регулярке. Хотя может и ошибаюсь и выполнение простой регулярки без рекурсий тоже хранит стеки
Get App Сколько букв «r» в слове «strawberry»? Хм, мне нужно определить, сколько раз буква "r" встречается в слове "strawberry". Давайте начнем с того, что правильно напишу это слово по буквам, чтобы не ошибиться. Слово "strawberry" на английском языке пишется как S-T-R-A-W-B-E-R-R-Y. Теперь мне нужно внимательно пройтись по каждой букве и посчитать количество "r".
Первым делом, разобью слово на отдельные буквы:
S
T
R
A
W
B
E
R
R
Y
Теперь посмотрю, на каких позициях стоит буква "R". С третьей позиции начинается первая R. Затем проверяю дальше: после A, W, B, E идут две R подряд на 8 и 9 позициях, а затем Y. То есть, получается, что буква R встречается три раза? Подожду, нет, вроде бы после E идут две R, значит третья R — это на третьей позиции. Итого: 1 (позиция 3) + 2 (позиции 8 и 9) = 3? Но мне кажется, что в слове "strawberry" обычно две R. Может, я ошибся при разбиении букв?
Давайте проверим еще раз. Слово "strawberry" правильно пишется как S-T-R-A-W-B-E-R-R-Y. Посчитаем буквы:
S (1)
T (2)
R (3)
A (4)
W (5)
B (6)
E (7)
R (8)
R (9)
Y (10)
Итак, на позициях 3, 8 и 9 стоят буквы R. То есть всего три буквы R. Но почему тогда я думаю, что их должно быть две? Возможно, я путаю с произношением. В слове "strawberry" иногда произносят одну R, но написание требует двух R после E. То есть, после E идут две R: E-R-R. Поэтому в написании их две. Но тогда почему в моем разборе три R? Потому что первая R стоит в начале слова, в третьей позиции. Получается, в слове три R: одна в начале и две подряд в конце. Но тогда общее количество — три. Но это противоречит моим предыдущим представлениям. Надо проверить правильность написания.
Проверю в словаре или через поиск. Слово "strawberry" пишется S-T-R-A-W-B-E-R-R-Y. То есть после E идут две R, а также есть R в начале слова. Итого три R. Но обычно в этом слове считается две R? Или я что-то путаю. Возможно, ошибка в том, как я разбиваю буквы. Давайте еще раз внимательно: S, T, R, A, W, B, E, R, R, Y. То есть R на 3, 8 и 9 позициях — три буквы. Но, возможно, я неправильно разбиваю слово. Например, может быть, после W идет B, а не две R. Нет, W идет после A, затем B, E, а потом две R. То есть точно три R. Получается, правильный ответ — три. Но я, кажется, где-то ошибся, потому что в некоторых источниках пишут, что в "strawberry" две R. Нужно уточнить.
Проверю написание "strawberry" в интернете. Поиск показывает, что правильное написание: S-T-R-A-W-B-E-R-R-Y. То есть после E идут две R, и одна R в начале слова. Таким образом, всего три R. Возможно, это ошибка в моем предыдущем понимании. Значит, правильный ответ — три буквы R. Но я должен быть уверен. Может, я неправильно считаю буквы? Давайте пересчитаю:
S
T
R
A
W
B
E
R
R
Y
Да, три R на позициях 3, 8, 9. Тогда ответ 3. Но почему тогда некоторые думают, что две? Может, путаница из-за произношения, где двойная R произносится как одна. Но в написании их две подряд после E, плюс одна в начале. Итого три. Тогда ответ — 3.
Это 100% не будете именно вы. Это будет другое существо с вашими воспоминаниями.
Я про перенос сознания, а не про копирование. Вы утвреждаете что перенести сознание в принципе невозможно?
В компьютере есть только биты на транзисторах, никаких квантовых эффектов там нет.
Ну есть еще квантовые компьютеры.
Нет такой гарантии. Вообще, в принципе. Копия никак не связана с оригиналом.
Если копию вообще в принципе можно создать. В квантовом мире квантовое состояние уже не копируется, а только переносится. На этом можно построить защищенный от прослушки канал передачи.
А с чего вы взяли, что она вам что-то дает? Это пока еще не доказано.
Что именно не доказано? Принцип неопределенности, запутанности, квантовая телепортация или что то другое?
Тут даже вопрос не в точности копии, а в гарантии идентичности - как единственности и неповторимости меня любимого, которую мне дает квантовая механика и не дает химия.
Зачем вам именно перенос для стопроцентной идентичности?
Для того чтобы быть уверенным, что это буду именно я. Например если я захочу продлить себе жизнь и скопировать свое сознание на другой более долговечный носитель. Вдруг я очнусь в неправильной копии, какая мне тогда будет разница что мой клон будет радоваться жизни.
Если мы говорим о примерной копии и допускаем что клонированное сознание все же будет немного отличаться от оригинала, то возможно опускаться на квантовый уровень не понадобится. Но это скорее клонирование а не перенос. А если нам нужен именно перенос и полная стопроцентная идентичность, то думаю без квантового уровня как основы законов существования материи нам не обойтись. И на квантовом уровне вопрос идентичности решается полностью - никаких полных копий, только путем уничтожения оригинала.
Согласно квантовой механике невозможно полностью скопировать какой либо объект, так как для этого надо его полностью измерить, а любое измерение изменит его квантовое состояние. То есть копия в любом случае не будет стопроцентно точной. Но с другой стороны возможна квантовая телепортация, когда объект разрушается в одном месте и воссоздается в другом сохраняя свое квантовое состояние. Так что если для переноса сознания понадобится полная квантовая копия, то ее можно будет сдалать только путем разрушения оригинала.
Не совсем все выкинуть, а просто не думать о тех из них, про которые думает компилятор. Пока о них думает компилятор например проверяя типы — все хорошо. Ну вот допустим написали хитрый fold, а потом выяснилось что с ним ассоциативность не работает за которой компилятор не следит — что результат будет зависеть от того в каком порядке фолдить. И узнаем об этом на проде где много ядер и потоков, где возникли кейсы, в которых он стал меняться.
Все абстракции текут, тут ничего не поделать. С другой стороны если нам не нужен какой то из законов, то почему бы его не выкинуть? Если выяснили что для композиции достаточно быть просто моноидом и не нужно ограничивать функтор до эндо, то давайте его выкинем вместе с ненужными нам свойствами типа join. Мат законы кажутся ненужными, так как мы начинаем думать о них как о само собой разумеющимся и не требующим доказательств. А потом когда встречаем случай где он не соблюдается и вся наша логика ломается — то сильно удивляемся.
Мне кажется вы путаете монады с побочным эффектом, ассоциативность которых всего лишь фикция, так как используется фиктивный параметр world и их нельзя схлопнуть, пока его не получишь. А получить его можно только через точку входа. По типу свободных монад они откладывают все вычисления напотом. И обычные чистые монады, ассоциативность для которых означает, что мы можем начинать схлопывать с любого места. Или я ошибаюсь и есть примеры чистых монад, которые нельзя схлопывать с середины?
Это как раз хороший пример того, что чтобы быть монадой в смысле «интерфейс блаблабла» и нормально это в качестве монады использовать — совсем не требуется быть монадой математически
Думаю не совсем так. Если надо последовательно в один поток пройтись по цепочке композированных элементов, то достаточно Bind. Если надо распараллелить проход, то надо чтобы соблюдалась ассоциативность, то есть надо быть полугруппой. Если есть вероятность, что кто то из частей цепочек окажется пустым, то пригодится единичный элемент из моноида. Если это не линейная цепочка, а дерево, то пригодится свойство эндофунктора.
Мне кажется null ввели не потому что так в джаве, а потому что так во всех императивных языках. Мы заранее объявили переменную, хранящую какое то состояние, но использовать будем где то в другом месте, но пока неизвестно когда и где — типичный императивный кейс. А раз так, то ее нужно заполнить чем то дефолтным. Для маленького значимого типа так уж и быть выделим немного памяти для дефолта. А для большого класса с неизвестным заранее размером как то хочется отложить на потом этот вопрос, поэтому пусть будет null. Хотя тут целая статья habr.com/ru/post/309462
А в ФП мире у тебя все состояние в параметрах, поэтому нет необходимости забивать что то по дефолту на будущее.
Если я правильно понял всю эту ветку: Nullable выполняет законы моноида, но не эндофунктора и следовательно не монады, так как конструктор типа Nullable принимает только значимые типы, а возращает только ссылочные, поэтому не допускает вложенность контейнеров. Но возможно ограничение эндо- не такое и нужное и никак не мешает использовать композицию. То есть 1 уровень вложенности хватит для большинства кейсов. А так сложилось просто потому что в Haskell проще не ограничивать, а в C# оказалось проще ограничить.
Кроссплатформенность — хорошо, но что там с зависимыми типами и другими ребрами лямбда куба? Есть большие сомнения. Но сам язык Pascal был в свое время не плох. Остались только хорошие воспоминания о нем со школы.
А тут действительно может быть подвох что более длинное решение не обязательно станет оптимальным. По регулярному выражению строится конечный автомат и всё зависит насколько он станет оптимальным, с учётом что при разборе могут случаться бектрекинги
А сколько тут Integer вернет digits ? А то у to_integer может случится too large or too small for an Int64. Хорошо у Haskell есть теоретически бесконечный Integer (пишут может доходить до 16 ГБ в зависимости от реализации) https://www.reddit.com/r/haskell/comments/1gg3i8/can_haskell_handle_integers_of_any_size_or_is/?rdt=50739
Да получается забавно, что исходной задаче, если ее реализовать в лоб на каком нибудь языке простым автоматом состояний, то ей не нужны никакие ни бектрекинги ни рекурсии, Надо просто идти по графу и определить на какой ноде поток цифр закончится. Но после всех этих преобразований из машины состояний в регулярку и обратно могут рождаться какие то монстры.
Если решить исходную задачу деления на 7, то откроется список решений других пользователей и среди них можно найти решение более общей задачи - для любого делителя. Оно оказалось совсем не большое, но код правда на Haskell
Рекурсия может потребовать стек для хранения переходов, а стек в свою очередь может быть overflow в запущенных случаях. Как минимум от этой проблемы избавимся, так как на выходе получили дерево разбора уложенное в плоскую строку, требующее хранение только текущей позиции в регулярке. Хотя может и ошибаюсь и выполнение простой регулярки без рекурсий тоже хранит стеки
Get App
Сколько букв «r» в слове «strawberry»?
Хм, мне нужно определить, сколько раз буква "r" встречается в слове "strawberry". Давайте начнем с того, что правильно напишу это слово по буквам, чтобы не ошибиться. Слово "strawberry" на английском языке пишется как S-T-R-A-W-B-E-R-R-Y. Теперь мне нужно внимательно пройтись по каждой букве и посчитать количество "r".
Первым делом, разобью слово на отдельные буквы:
S
T
R
A
W
B
E
R
R
Y
Теперь посмотрю, на каких позициях стоит буква "R". С третьей позиции начинается первая R. Затем проверяю дальше: после A, W, B, E идут две R подряд на 8 и 9 позициях, а затем Y. То есть, получается, что буква R встречается три раза? Подожду, нет, вроде бы после E идут две R, значит третья R — это на третьей позиции. Итого: 1 (позиция 3) + 2 (позиции 8 и 9) = 3? Но мне кажется, что в слове "strawberry" обычно две R. Может, я ошибся при разбиении букв?
Давайте проверим еще раз. Слово "strawberry" правильно пишется как S-T-R-A-W-B-E-R-R-Y. Посчитаем буквы:
S (1)
T (2)
R (3)
A (4)
W (5)
B (6)
E (7)
R (8)
R (9)
Y (10)
Итак, на позициях 3, 8 и 9 стоят буквы R. То есть всего три буквы R. Но почему тогда я думаю, что их должно быть две? Возможно, я путаю с произношением. В слове "strawberry" иногда произносят одну R, но написание требует двух R после E. То есть, после E идут две R: E-R-R. Поэтому в написании их две. Но тогда почему в моем разборе три R? Потому что первая R стоит в начале слова, в третьей позиции. Получается, в слове три R: одна в начале и две подряд в конце. Но тогда общее количество — три. Но это противоречит моим предыдущим представлениям. Надо проверить правильность написания.
Проверю в словаре или через поиск. Слово "strawberry" пишется S-T-R-A-W-B-E-R-R-Y. То есть после E идут две R, а также есть R в начале слова. Итого три R. Но обычно в этом слове считается две R? Или я что-то путаю. Возможно, ошибка в том, как я разбиваю буквы. Давайте еще раз внимательно: S, T, R, A, W, B, E, R, R, Y. То есть R на 3, 8 и 9 позициях — три буквы. Но, возможно, я неправильно разбиваю слово. Например, может быть, после W идет B, а не две R. Нет, W идет после A, затем B, E, а потом две R. То есть точно три R. Получается, правильный ответ — три. Но я, кажется, где-то ошибся, потому что в некоторых источниках пишут, что в "strawberry" две R. Нужно уточнить.
Проверю написание "strawberry" в интернете. Поиск показывает, что правильное написание: S-T-R-A-W-B-E-R-R-Y. То есть после E идут две R, и одна R в начале слова. Таким образом, всего три R. Возможно, это ошибка в моем предыдущем понимании. Значит, правильный ответ — три буквы R. Но я должен быть уверен. Может, я неправильно считаю буквы? Давайте пересчитаю:
S
T
R
A
W
B
E
R
R
Y
Да, три R на позициях 3, 8, 9. Тогда ответ 3. Но почему тогда некоторые думают, что две? Может, путаница из-за произношения, где двойная R произносится как одна. Но в написании их две подряд после E, плюс одна в начале. Итого три. Тогда ответ — 3.
Я про перенос сознания, а не про копирование. Вы утвреждаете что перенести сознание в принципе невозможно?
Ну есть еще квантовые компьютеры.
Если копию вообще в принципе можно создать. В квантовом мире квантовое состояние уже не копируется, а только переносится. На этом можно построить защищенный от прослушки канал передачи.
Что именно не доказано? Принцип неопределенности, запутанности, квантовая телепортация или что то другое?
Тут даже вопрос не в точности копии, а в гарантии идентичности - как единственности и неповторимости меня любимого, которую мне дает квантовая механика и не дает химия.
Для того чтобы быть уверенным, что это буду именно я. Например если я захочу продлить себе жизнь и скопировать свое сознание на другой более долговечный носитель. Вдруг я очнусь в неправильной копии, какая мне тогда будет разница что мой клон будет радоваться жизни.
Если мы говорим о примерной копии и допускаем что клонированное сознание все же будет немного отличаться от оригинала, то возможно опускаться на квантовый уровень не понадобится. Но это скорее клонирование а не перенос. А если нам нужен именно перенос и полная стопроцентная идентичность, то думаю без квантового уровня как основы законов существования материи нам не обойтись. И на квантовом уровне вопрос идентичности решается полностью - никаких полных копий, только путем уничтожения оригинала.
Согласно квантовой механике невозможно полностью скопировать какой либо объект, так как для этого надо его полностью измерить, а любое измерение изменит его квантовое состояние. То есть копия в любом случае не будет стопроцентно точной. Но с другой стороны возможна квантовая телепортация, когда объект разрушается в одном месте и воссоздается в другом сохраняя свое квантовое состояние. Так что если для переноса сознания понадобится полная квантовая копия, то ее можно будет сдалать только путем разрушения оригинала.
Не совсем все выкинуть, а просто не думать о тех из них, про которые думает компилятор. Пока о них думает компилятор например проверяя типы — все хорошо. Ну вот допустим написали хитрый fold, а потом выяснилось что с ним ассоциативность не работает за которой компилятор не следит — что результат будет зависеть от того в каком порядке фолдить. И узнаем об этом на проде где много ядер и потоков, где возникли кейсы, в которых он стал меняться.
Думаю не совсем так. Если надо последовательно в один поток пройтись по цепочке композированных элементов, то достаточно Bind. Если надо распараллелить проход, то надо чтобы соблюдалась ассоциативность, то есть надо быть полугруппой. Если есть вероятность, что кто то из частей цепочек окажется пустым, то пригодится единичный элемент из моноида. Если это не линейная цепочка, а дерево, то пригодится свойство эндофунктора.
А в ФП мире у тебя все состояние в параметрах, поэтому нет необходимости забивать что то по дефолту на будущее.