Каналы не обобщение фьюч/промисов. Это сигнальная система из акторной модели, чтобы объекты могли общаться друг с другом. Это относится к многопоточности, а не асинхронности. А сделали их такими из-за области применения языка - микросервисы в инфраструктуре гугла.
ООП нужен, чтобы цепочку асинхронных вызовов нормально написать, а не лапшой колбеков, без них было бы ужасно
Это вы кладёте слова в мой рот. Нет, ООП нужен чтобы не писать лапшу в принципе, а не только в асинхронном коде. Особенно, если дефолты языка неудачные. Тот пример просто показывает, как ООП помогает с этим. Особенно если учесть, что в таком виде есть поддержка асинхронности есть в большом количестве языков и да ровно потому что по-другому тогда не могли.
Видите, ну это никак нельзя нормально сделать без классов, инкапсуляции и полиморфизма. Для этого и нужен ООП!
Опять же - тьюринг полнота гарантированно даёт возможность выражать любые программы. Поэтому "никак нельзя" - совершенно точно не применим. Кстати, вот эта позиция очень напоминает мне борьбу с Rust в Linux.
ты не будешь городить тут никакие интерфейсы, а просто передашь замыкание.
Да, потому что всё, что нужно уже написали за вас, только сиди своих дровишек подкидывай, и следи чтобы UB не случилось. Go в этом плане несколько уникален ибо предоставляет некоторые новые механизмы на уровне языка, а не библиотек. Но он очень молод. ООП решало проблему за десятки лет до этого.
Но на самом деле - это не какое-то замечательное применение ООП.
Вот любите вы всякие эпитеты. А какое тогда замечательно или блистательное? Разные подходы - это всё компромисы, позволяющие разруливать сложность кода не снижая продуктивность программиста. Пойти путём go в JS не могли из-за легаси, поэтому сделали как сделали. У Python похожая история. В Rust попробовали - не понравилось, сделали как в JS (почти). В С++ посмотрели на остальных и пошли как обычно своим путём. Всякие Java/C# изначально плясали с ООП, так что у них закономерно ничего неожиданного.
Учитывая, что большинство мейнстримных языков это не поддерживает да и топик за (не)мёрвый ООП не знаю чего вы к тем монадам/нотациям пристали.
Покажите мне промисы и фьючеры в го)
этого я возможно с кем-то спутал. не силён в го. первая попавшаяся библиотека для них выглядит не сильно лучше си.
При этом, асинхронщина/коррутины не обязаны быть прибиты гвоздями к этим классам.
вот они в си и не прибиты, ибо там в принципе нет этого на уровне синтаксиса. В современном C++ c co_yield/co_await у вас уже появляются промисы/футуры. В несовременном либо что-то аналогичное изобреталось обычно, либо как в Си. Можно по теме посмотреть Антона Полухина, он там рассказывает как они в userver stackfull корутины делали.
Мой изначальный поинт был про то что без ООП мой псевдокод выше вгылядел бы как лапша из тыщ колбэков и двузначной цикломатической сложностью, как это происходит в Си. То что асинхронный код можно реализовать без ООП никто вроде и не оспаривал - полнота по Тьюрингу это вроде как гарантирует. async/await это синтаксический сахар, который работает вокруг классов Future/Promise, инкапсулируя часть поведения и позволяя оборачивать в них колбэки с произвольной сигнатурой, то бишь реализуя полиморфический интерфейс, который, в зависимости от языка, в том числе может быть реализован через наследование.
В математике задача вычисления инволюции и идемпотентов кольца не решена
Если она не решена, то откуда вам известно, что это именно инволюция/индепотент без скармливания её в некоторую функцию?
Номера строк идемпотентов
откуда они появились?
Для N =629 нетр. инволюция лежит в строке 29-го слоя окаймления (снизу) центральной строки (хо = 157).
Меня абсолютно не интересует где они лежат, меня интересует как вы получили значение 157 или 29, 186, 102 и тп. Почему 102 подошла, а 177 нет? Половина этих строки находят дальше N/2 и для больших чисел и если у нас число в тысячах бит, то мы не можем ожидать, что мы пробежим эту половину с каким-то фильтром как вы их выбрали для произвольного N?
То, что вы это можете с ними написать — не означает, что не написать без них.
именно поэтому и привёл код на си, который показывает, как оно выглядит в мире, где ООП пишут от руки, ибо его нет на уровне языка - поллинг руками запускается, соединить в цепочку нельзя без изобретения какого-нибудь ещё механизма, это не говоря уже о ситуации, когда хочется отменять цепочки. callback hell во всей красе. js тоже когда-то выглядел так, пока не завели специализированный класс/объект, инкапсулировавший весь этот ахтунг за минималистичным интерфейсом.
Вопрос был как пользоваться тем что вы описываете, а не какой ответ. Мы можем взять произвольное число до корня из N и получить полный квадрат из тривиальной области, только как это помогает находить факторы? Вы буквально четвёртым шагом дорисовываете остатки совы.
Рисуем круг: Берём x1 * x1 mod N == k * k
Рисуем второй круг: Смотрим в столбец 5
???
Дорисовываем остатки совы: Фактор p = число1, q = число2, в строке число3 - индепотент, инволюция
PROFIT
Конечно может вы савант и как-то из рукава все эти числа спавните, но нам-то калькуляторам как это обходить?
есть инкапсуляция, есть полиморфизм, что вам ещё для ооп класса надо? да и мой псевдокод явно не подразумевал какой-нибудь Idris/Haskell, а что-нибудь вроде js/ts/rust/kotlin/zig/go
В работе показано направление моделирования числа, отличное от известных, и его возможности решать задачу факторизации составного числа, рассматриваемого как модуль приведения кольца.
решать задачу факторизации с предположением о том что мы знаем это разложение как-то странно.
Пусть A1 будет предположением, что мы не знаем факторов.
Следствием С1 будет то, что мы не можем раскрашивать что-то, кроме квадратов и смежных сомножителей, которые имеют тривиальную проверку.
Алгоритма нахождения любого из центров решающих интервалов за пределами тривиальной области при истинности A1 не описано.
Алгоритма нахождение секции "четверки" при истинности A1 не описано.
Доказательств, что область четверок всегда существует нет.
Как помогают инволюции и индепотенты искать факторы не описано. Форма инволюции никогда не была представлена в явном виде.
Алгоритма нахождения индепотентов при истинности A1 не описано.
Алгоритма нахождения секвенций, которые суммируются в N при истинности A1 не описано.
Попытка найти любое из этих значений при помощи таблицы пока что сводится к брутфорсу значений до меньшего из факторов, либо использование вышеупомянутых способов продвинутой факторизации.
Да хоть бы и на русском, оставили б хотя бы на нём. У людей гуглотранслейт думаю найдётся. И ладно б оно с habr.com/docs/authors/useful редиректило на активную локальhabr.com/<setting-lang>/authors/useful, так оно и с соседних локалей зачем-то тоже редиректит на текующую активную локаль. То бишь чтобы посмотреть придётся в настройках хабра явно переключать язык. А если смотреть без регистрации, то и вовсе системную локаль менять. Сомнительный UX.
Не бывает научных публикаций без списка литературы
Ну, кстати неоднократно видел как люди делали списки литературы и источников. Не сказать, чтобы это сильно помогало статье и было как-то полезно. Часто много референсов на внешние материалы делается, но это довольно редкая история ибо не всегда это требуется (по крайней мере из того что я читаю).
Собственно потому оно и min(p,q) т.к. вам достаточно досчитать до минимального делителя N, второй делительно получается тривиально. Более продвинутые алгоритмы брутфорса не рассматривал в контексте темы статьи ибо они там сильно непростые и никак не связаны (вроде).
Сглазил. Теперь уже и два дня как и топы полегли.
Каналы не обобщение фьюч/промисов. Это сигнальная система из акторной модели, чтобы объекты могли общаться друг с другом. Это относится к многопоточности, а не асинхронности. А сделали их такими из-за области применения языка - микросервисы в инфраструктуре гугла.
Это вы кладёте слова в мой рот. Нет, ООП нужен чтобы не писать лапшу в принципе, а не только в асинхронном коде. Особенно, если дефолты языка неудачные. Тот пример просто показывает, как ООП помогает с этим. Особенно если учесть, что в таком виде есть поддержка асинхронности есть в большом количестве языков и да ровно потому что по-другому тогда не могли.
Опять же - тьюринг полнота гарантированно даёт возможность выражать любые программы. Поэтому "никак нельзя" - совершенно точно не применим. Кстати, вот эта позиция очень напоминает мне борьбу с Rust в Linux.
Да, потому что всё, что нужно уже написали за вас, только сиди своих дровишек подкидывай, и следи чтобы UB не случилось. Go в этом плане несколько уникален ибо предоставляет некоторые новые механизмы на уровне языка, а не библиотек. Но он очень молод. ООП решало проблему за десятки лет до этого.
Вот любите вы всякие эпитеты. А какое тогда замечательно или блистательное? Разные подходы - это всё компромисы, позволяющие разруливать сложность кода не снижая продуктивность программиста. Пойти путём go в JS не могли из-за легаси, поэтому сделали как сделали. У Python похожая история. В Rust попробовали - не понравилось, сделали как в JS (почти). В С++ посмотрели на остальных и пошли как обычно своим путём. Всякие Java/C# изначально плясали с ООП, так что у них закономерно ничего неожиданного.
Учитывая, что большинство мейнстримных языков это не поддерживает да и топик за (не)мёрвый ООП не знаю чего вы к тем монадам/нотациям пристали.
этого я возможно с кем-то спутал. не силён в го. первая попавшаяся библиотека для них выглядит не сильно лучше си.
вот они в си и не прибиты, ибо там в принципе нет этого на уровне синтаксиса. В современном C++ c co_yield/co_await у вас уже появляются промисы/футуры. В несовременном либо что-то аналогичное изобреталось обычно, либо как в Си. Можно по теме посмотреть Антона Полухина, он там рассказывает как они в userver stackfull корутины делали.
Мой изначальный поинт был про то что без ООП мой псевдокод выше вгылядел бы как лапша из тыщ колбэков и двузначной цикломатической сложностью, как это происходит в Си. То что асинхронный код можно реализовать без ООП никто вроде и не оспаривал - полнота по Тьюрингу это вроде как гарантирует. async/await это синтаксический сахар, который работает вокруг классов Future/Promise, инкапсулируя часть поведения и позволяя оборачивать в них колбэки с произвольной сигнатурой, то бишь реализуя полиморфический интерфейс, который, в зависимости от языка, в том числе может быть реализован через наследование.
То есть примерно min(p,q) значений
это все по mod N?
Если она не решена, то откуда вам известно, что это именно инволюция/индепотент без скармливания её в некоторую функцию?
откуда они появились?
Меня абсолютно не интересует где они лежат, меня интересует как вы получили значение 157 или 29, 186, 102 и тп. Почему 102 подошла, а 177 нет? Половина этих строки находят дальше N/2 и для больших чисел и если у нас число в тысячах бит, то мы не можем ожидать, что мы пробежим эту половину с каким-то фильтром как вы их выбрали для произвольного N?
именно поэтому и привёл код на си, который показывает, как оно выглядит в мире, где ООП пишут от руки, ибо его нет на уровне языка - поллинг руками запускается, соединить в цепочку нельзя без изобретения какого-нибудь ещё механизма, это не говоря уже о ситуации, когда хочется отменять цепочки. callback hell во всей красе. js тоже когда-то выглядел так, пока не завели специализированный класс/объект, инкапсулировавший весь этот ахтунг за минималистичным интерфейсом.
Вопрос был как пользоваться тем что вы описываете, а не какой ответ. Мы можем взять произвольное число до корня из N и получить полный квадрат из тривиальной области, только как это помогает находить факторы? Вы буквально четвёртым шагом дорисовываете остатки совы.
Конечно может вы савант и как-то из рукава все эти числа спавните, но нам-то калькуляторам как это обходить?
есть инкапсуляция, есть полиморфизм, что вам ещё для ооп класса надо? да и мой псевдокод явно не подразумевал какой-нибудь Idris/Haskell, а что-нибудь вроде js/ts/rust/kotlin/zig/go
Ну и было бы неплохо взять пример побольше. Как например факторизовать 1000175531675759323?
решать задачу факторизации с предположением о том что мы знаем это разложение как-то странно.
Пусть A1 будет предположением, что мы не знаем факторов.
Следствием С1 будет то, что мы не можем раскрашивать что-то, кроме квадратов и смежных сомножителей, которые имеют тривиальную проверку.
Алгоритма нахождения любого из центров решающих интервалов за пределами тривиальной области при истинности A1 не описано.
Алгоритма нахождение секции "четверки" при истинности A1 не описано.
Доказательств, что область четверок всегда существует нет.
Как помогают инволюции и индепотенты искать факторы не описано. Форма инволюции никогда не была представлена в явном виде.
Алгоритма нахождения индепотентов при истинности A1 не описано.
Алгоритма нахождения секвенций, которые суммируются в N при истинности A1 не описано.
Попытка найти любое из этих значений при помощи таблицы пока что сводится к брутфорсу значений до меньшего из факторов, либо использование вышеупомянутых способов продвинутой факторизации.
Да хоть бы и на русском, оставили б хотя бы на нём. У людей гуглотранслейт думаю найдётся. И ладно б оно с
habr.com/docs/authors/usefulредиректило на активную локальhabr.com/<setting-lang>/authors/useful, так оно и с соседних локалей зачем-то тоже редиректит на текующую активную локаль. То бишь чтобы посмотреть придётся в настройках хабра явно переключать язык. А если смотреть без регистрации, то и вовсе системную локаль менять. Сомнительный UX.Была б табличка со списком фич.
"рыба в воде" заигралаа новыми красками
Ну, кстати неоднократно видел как люди делали списки литературы и источников. Не сказать, чтобы это сильно помогало статье и было как-то полезно. Часто много референсов на внешние материалы делается, но это довольно редкая история ибо не всегда это требуется (по крайней мере из того что я читаю).
можно будет сослаться в случае чего. тоже неплохо
bruh
fzf
Собственно потому оно и min(p,q) т.к. вам достаточно досчитать до минимального делителя N, второй делительно получается тривиально. Более продвинутые алгоритмы брутфорса не рассматривал в контексте темы статьи ибо они там сильно непростые и никак не связаны (вроде).