Это чисто учебный проект? Есть же GMP и Boost.Multiprecision который ее использует (хотя в бусте есть и собственная реализация).
А вообще конечно поддержка длинных чисел должна быть встроена в язык на уровне литералов.
Честно — глубоко не вникал, это нужно брать карандаш с бумагой и вдумчиво рисовать все структуры и связи. Но думаю, идея хорошая, надо будет разобраться.
Где-то в комментариях я уже упоминал, что вот такие штуки было бы очень неплохо использовать для создания метаописаний расшаренных объектов в децентрализованных сетях. Фильмы, книги, музыка, картинки… Что-то вроде torrent файла, но с человекоориентированной метаинформацией внутри. Например, для книги — автор, название, издательство, год выпуска, количество страниц, оглавление, аннотация. Для видео — название, актеры/режиссеры и т.п., разрешение, длительность, информация о кодеке, субтитры. И конечно различные хеши, по которым контент можно находить в сети.
Одно из возможных применений — подписка на контент от друзей и сообществ в децентрализованной соцсети. Допустим, у вас есть друг или вы состоите в сообществе, и у друга/сообщества появляется некий контент. Скачивать этот контент автоматически неразумно (совсем не факт что он вам нужен, да и если скачивать все подряд то сеть загнется и диски забьются моментально). Но вот скачать «метаинформацию» в пару килобайт — вполне приемлемо. Такая метаинформация попадает вам в «ленту» (и фактически она сама по себе участвует в децентрализованном поддержании доступности страниц ваших друзей и сообществ, в которых вы состоите), и вы решаете скачивать сам контент (тем самым присоединяясь к раздаче уже непосредственно контента, а не только метаинформации о нем) или нет.
Второе возможное применение — поиск контента по ключевым словам/тегам. Откуда взяться тегам у фильма? Только из дополнительной метаинформации, одобренной консенсусом в децентрализованной сети.
Отлично! Твиттер постепенно вбирает лучшие функции соцсетей.
Когда-то твиттер казался мне «несерьезной» соцсетью — в самом деле, что осмысленного можно уместить в SMS-сообщение? Но на самом деле сейчас это пожалуй самая либеральная соцсеть в мире. А если учесть, что основной контент современных соцсетей — фото и видео, то ограничение в 140 или 260 символов не кажется чем-то существенным.
В остальном все замечательно. Гораздо более свободное отношение к контенту, чем у многих. Регистрация там по прежнему возможна без мобильного телефона, только через email. Для 2021 года это уникальная ситуация. Особенно чувствуется контраст с фейсбуком, которому непременно нужна настоящая фотка лица, да еще чуть ли не паспорт требуют.
Вообще вот эти цифры, показывающее время, как раз выглядят как-то не очень матрично и потому слегка чужеродно. Есть же матричные шрифты хотя-бы, например всем известный OCR_OneCTT. А тут как будто взяли первый попавшийся виндовский шрифт и по-быстрому сделали что-то трехмерно-пластиковое.
Считаю что объектный формат хранения и линковка вообще устаревшие концепции, т.к. они не позволяют хранить метапрограммы (например шаблоны C++), в результате в том же C++ шаблоны могут существовать только в *.h-файлах. Хранить нужно частично скомпилированные синтаксические деревья, а вместо линковки применять процесс «окончательной компиляции».
Я не то чтобы предлагаю, я размышляю. Вот например, можно ли закорючку от буквы 'й' присоединить к иероглифу, цифре или знаку препинания? Что получится?
Если идти по пути универсальности, то почему бы и нет? А если закорючку присоединить к другой закорючке?
С одной стороны это конечно хорошо, что можно генерировать некоторые новые символы таким образом. А с другой… как-то бессистемно. Ну ввели бы тогда специальный код «escape» для специальных escape-последовательностей — и вот туда можно было бы добавить элементы форматирования. В том числе жирный/курсив/подчеркивание, капитель, верхний и нижний индекс, надстрочные и подстрочные символы (Ruby character), геометрические преобразования (поворот символа на 90/180/270 градусов или даже повороты с каким-то шагом типа 5°, отражение по горизонтали и вертикали), цвет символов (для всяких эмодзи вполне актуально, и сейчас это уже как-то делают) и т.п. Это было бы хотя-бы системно. Но тогда бы это была уже не таблица символов, а нечто большее. А сейчас оно застряло где-то на полпути…
Не знаком с немецким, но почитал — занимательно, получается что это как раз тот случай, когда Unicode повлиял на язык (введение заглавной буквы в Unicode раньше чем она появилась в языке).
Unicode — это прежде всего набор символов и соответствующих им кодов. Как их использовать — дело софта. И наверное, если разные модификации (декорации) одного смыслового символа значительно отличаются и не могут быть сгенерированы программно (как в случае underline, subscript, superscript — просто подчеркиванием или уменьшением размеров), то нужно эти символы вводить отдельно…
Одинаковые символы с разными кодами (как например латинское 'A' и русское 'А') введены просто для удобства группировки, чтобы символы одного языка не были разбросаны по всему диапазону. Для европейских языков большая часть символов общая, и лишь некоторые (2..4 штуки в каждом алфавите) свои собственные — поэтому не имеет смысла вводить отдельно коды для «немецких», «французских» и «итальянских» букв 'A', а проще сформировать единый общеевропейский метаалфавит, что и было сделано. В русском большая часть символов отличается, поэтому сделали отдельный набор.
В общем понятно, что Unicode несет на себе бремя обратной совместимости не только с ASCII, но и с историей письменности как таковой:) И идеального решения не найти. Может быть нужно было радикальное решение в виде разделения абстракций — отдельно слой сопоставления символов и «кодов символов» (в этом слое все буквы, выглядящие как 'A', будут иметь единый код), и отдельно слой сопоставления «кодов символов» и «смысловых кодов» (здесь уже разделение по алфавитам). В результате было бы две кодировки — графическая и семантическая. Понятно, что это кардинально повлияло бы на все ОС и на весь софт, и мы бы жили в совсем другом мире:)
Дизайн Unicode по большому счету содержит множество ошибок. Из за желания угодить всем нагородили вот это всё, и это при том что Unicode создавался во времена «однополярного мира», когда США и американские корпорации, будучи практически монополистами в сфере IT-стандартов и технологий, вполне могли продавить более простую концепцию.
Зачем например в Unicode «направление письма»? Unicode это просто набор символов. Как их вводить, выводить и интерпретировать — дело софта. Вот в Китае и Японии направление письма вообще «сверху вниз», но ведь Unicode такое не поддерживает? И кстати, китайцы и японцы с появлением компьютеров вполне адаптировались к направлению «слева направо», может и арабы бы также адаптировались?
Далее, регистр символов — это особенность исключительно европейских языков, унаследованная из ASCII (который создавался в условиях гораздо более жесткой экономии оперативной памяти). Понятно что старались сделать обратную совместимость, но по большому счету регистр должен был стать «декорацией» (как bold, italic, subscript или superscript), а не отдельными кодовыми точками. Символы 'a' и 'a' (курсивом) — как-бы один символ, хотя они совершенно отличаются визуально. Символы 'a' и 'A' при этом — разные. Логика?
Из-за той же обратной совместимости осталась незадействованной большая часть символов в самом начале кодовой таблицы, с 0x00 до 0x1F. А между тем их стоило бы задействовать для наиболее употребительных спецсимволов (таких например как стрелки, дополнительные знаки пунктуации, некоторые математические символы и т.п.). Размещение этих символов в однобайтовой части важно, так как именно однобайтовая часть Unicode по очевидным причинам нанесена на все клавиатуры мира. Оставить в этой области можно было бы только нулевой код и код новой строки, и заодно провести редизайн концепции переноса строки, т.к. в основных системах (Win, Mac, Linux) перенос строки устроен по-разному (0x0D, 0x0A или оба сразу).
Ну и наверное можно еще накопать таких вот нелогичностей.
Почему-то до сих пор в язык не ввели встроенные геттеры и сеттеры. Хотя например уже очень давно такое было в C++Builder (__property), у Microsoft (__declspec(property)). А вот в GCC такой возможности нет, хотя казалось бы — именно GCC как никакой другой компилятор богат на языковые расширения.
Воспроизведение связи между матерью и ребенком, с точно рассчитанным высвобождением нужных гормонов в течение всего периода, находится за пределами досягаемости современных биотехнологий.
Интересно почему? Неужели этот процесс не изучить простым взятием анализов с каким-то периодом (пусть даже каждый день) у подопытных животных?
Компьютерные игры — это отличный способ уберечь детей от влияния улицы и подворотни. От сбивания в уличные шайки, от мордобоя и уличного криминала. В общем, игры вносят вклад в снижение уровня насилия на планете. 3dnews.ru/1035263/igri-spasut-mir-feature
Фактор снижения насилия
Большинство экспертов с уверенностью заявляют: игры не имеют никакого отношения к насилию в мире. Но есть и другая позиция — интерактивные виды досуга снижают уровень преступности на планете. Среди них есть и российские общественные деятели, например политолог Екатерина Шульман, известная игровому сообществу в первую очередь благодаря интервью радио Sputnik. Там она произнесла удивительную вещь: «Есть обывательская логика: игры с насилием провоцируют реальное насилие. В реальности происходит ровно противоположное…»
Социологи подтверждают — уровень насилия и преступности на нашей планете неуклонно снижается. Тут, конечно, важно понимать, что говорим мы о плавном и постепенном процессе в развитых странах, а не о сиюминутном искоренении всех злодеяний на земном шаре. Тем не менее осязаемый процесс идёт, и это обнадёживает. Естественно, это заслуга множества факторов — развития гражданского общества, укрепления роли человеческой жизни как основополагающей ценности, усиления эмпатии у превалирующей части жителей мира и прочего. Но и видеоигры оказывают, как выяснилось, заметное влияние.
Согласно исследованиям, интерактивные развлечения способны уменьшать уровень преступности. А точнее, самый распространённый её подвид — уличную преступность, в которую вовлечены молодые люди. Наиболее подробно этот вопрос раскрывает исследование Understanding the Effects of Violent Video Games on Violent Crime («Понимание воздействия жестоких видеоигр на насильственные преступления»), проведённое Скоттом Канингемом, Бенджамином Энгельштеттером и Майклом Р. Уордом. Группа учёных смогла определить корреляцию между популярностью интерактивных развлечений и снижением уровня преступности среди молодёжи.
В своём исследовании они отмечают: взаимосвязь между склонностью конкретного человека к насилию и предпочтением им игр с элементами жестокости (заметьте, не наоборот) наблюдается. Но позже подводят к очевидной мысли: если такой человек проводит время за играми, сублимируя антисоциальный пыл на NPC, а не ходит по улицам в поисках утоления своих низменных порывов, то это — однозначно позитивная тенденция. Удерживая внимание человека дома у экрана, игра буквально уничтожает интерес, например, к перспективе вступления в уличную банду, к праздному вандализму или, что страшнее, грабежу, разбою или убийству. Да и времени с энергией на противоправные действия просто не останется…
Для цветных экранов с как минимум 256 цветами дополнительно можно добавить сглаживание (4 или 16 бит на пиксель). Я такое делал, надписи получаются гораздо приятнее.
Ну и сам способ организации массива может быть разным Иногда удобнее сплошным массивом, а иногда — когда не нужны все символы из диапазона — удобнее таблица указателей на отдельные массивы для каждого символа.
Возможно, в технологической гонке упустили несколько промежуточных этапов и скакнули слишком далеко, в результате что-то потеряли и не поняли. Например, кроме «простого текста» могло бы появиться еще несколько «простых» форматов, которые бы стали стандартами де факто и получили бы повсеместное распространение. Или мог бы появиться совсем другой принцип запуска программ, и как следствие — другой способ передачи им аргументов.
Впрочем, тут можно углубляться очень глубоко. Возможно, дело в текстовой клавиатуре и изначально текстовых интерфейсах пользователя. Или в изначально последовательном командном способе взаимодействия с компьютером. Или еще в чем-то.
Это несущественно, там xml, который вы руками править точно не будете. Вполне можно было использовать какой-нибудь бинарный аналог. В конечном итоге «текстовость» и «бинарность» — лишь ограничение на множество байт, которые могут быть использованы в файле.
Дело ведь не в формате, а в том, что всё связывание программ и организация потоков данных осуществляется через командную строку консоли. Когда-то у Microsoft была задумка — COM-объекты, ActiveX, встраивание одних документов и программ в другие… Но в конечном итоге оно пошло куда-то не туда, возможно технология была слишком сложной, или ей чего-то не хватало.
Идея Unix-way хорошая, но как ее соотнести со сложнейшим современным софтом? Да с тем же Офисом, Фотошопом, различными средами разработки, проектирования, конструирования и т.п.?
Насколько имеет смысл ограничиваться консолью и текстовым форматом (пусть и в JSON)? Не имеет ли смысл пересмотреть концепцию на более глубоком уровне, допустив, что у программ могут быть не только текстовые входы и выходы?
А вообще конечно поддержка длинных чисел должна быть встроена в язык на уровне литералов.
Где-то в комментариях я уже упоминал, что вот такие штуки было бы очень неплохо использовать для создания метаописаний расшаренных объектов в децентрализованных сетях. Фильмы, книги, музыка, картинки… Что-то вроде torrent файла, но с человекоориентированной метаинформацией внутри. Например, для книги — автор, название, издательство, год выпуска, количество страниц, оглавление, аннотация. Для видео — название, актеры/режиссеры и т.п., разрешение, длительность, информация о кодеке, субтитры. И конечно различные хеши, по которым контент можно находить в сети.
Одно из возможных применений — подписка на контент от друзей и сообществ в децентрализованной соцсети. Допустим, у вас есть друг или вы состоите в сообществе, и у друга/сообщества появляется некий контент. Скачивать этот контент автоматически неразумно (совсем не факт что он вам нужен, да и если скачивать все подряд то сеть загнется и диски забьются моментально). Но вот скачать «метаинформацию» в пару килобайт — вполне приемлемо. Такая метаинформация попадает вам в «ленту» (и фактически она сама по себе участвует в децентрализованном поддержании доступности страниц ваших друзей и сообществ, в которых вы состоите), и вы решаете скачивать сам контент (тем самым присоединяясь к раздаче уже непосредственно контента, а не только метаинформации о нем) или нет.
Второе возможное применение — поиск контента по ключевым словам/тегам. Откуда взяться тегам у фильма? Только из дополнительной метаинформации, одобренной консенсусом в децентрализованной сети.
А почему вы думаете что в криптоинтернете не будет ботов?
Когда-то твиттер казался мне «несерьезной» соцсетью — в самом деле, что осмысленного можно уместить в SMS-сообщение? Но на самом деле сейчас это пожалуй самая либеральная соцсеть в мире. А если учесть, что основной контент современных соцсетей — фото и видео, то ограничение в 140 или 260 символов не кажется чем-то существенным.
В остальном все замечательно. Гораздо более свободное отношение к контенту, чем у многих. Регистрация там по прежнему возможна без мобильного телефона, только через email. Для 2021 года это уникальная ситуация. Особенно чувствуется контраст с фейсбуком, которому непременно нужна настоящая фотка лица, да еще чуть ли не паспорт требуют.
ew.com/movies/the-matrix-4-footage-fan-website-poster
www.reddit.com/r/matrix/comments/pjt33g/i_compiled_all_the_scenes_in_one_video_for_yall
www.reddit.com/r/matrix/comments/pjtnot/stitched_together_as_much_of_the_teaser_footage_i
Если идти по пути универсальности, то почему бы и нет? А если закорючку присоединить к другой закорючке?
С одной стороны это конечно хорошо, что можно генерировать некоторые новые символы таким образом. А с другой… как-то бессистемно. Ну ввели бы тогда специальный код «escape» для специальных escape-последовательностей — и вот туда можно было бы добавить элементы форматирования. В том числе жирный/курсив/подчеркивание, капитель, верхний и нижний индекс, надстрочные и подстрочные символы (Ruby character), геометрические преобразования (поворот символа на 90/180/270 градусов или даже повороты с каким-то шагом типа 5°, отражение по горизонтали и вертикали), цвет символов (для всяких эмодзи вполне актуально, и сейчас это уже как-то делают) и т.п. Это было бы хотя-бы системно. Но тогда бы это была уже не таблица символов, а нечто большее. А сейчас оно застряло где-то на полпути…
Unicode — это прежде всего набор символов и соответствующих им кодов. Как их использовать — дело софта. И наверное, если разные модификации (декорации) одного смыслового символа значительно отличаются и не могут быть сгенерированы программно (как в случае underline, subscript, superscript — просто подчеркиванием или уменьшением размеров), то нужно эти символы вводить отдельно…
Одинаковые символы с разными кодами (как например латинское 'A' и русское 'А') введены просто для удобства группировки, чтобы символы одного языка не были разбросаны по всему диапазону. Для европейских языков большая часть символов общая, и лишь некоторые (2..4 штуки в каждом алфавите) свои собственные — поэтому не имеет смысла вводить отдельно коды для «немецких», «французских» и «итальянских» букв 'A', а проще сформировать единый общеевропейский метаалфавит, что и было сделано. В русском большая часть символов отличается, поэтому сделали отдельный набор.
В общем понятно, что Unicode несет на себе бремя обратной совместимости не только с ASCII, но и с историей письменности как таковой:) И идеального решения не найти. Может быть нужно было радикальное решение в виде разделения абстракций — отдельно слой сопоставления символов и «кодов символов» (в этом слое все буквы, выглядящие как 'A', будут иметь единый код), и отдельно слой сопоставления «кодов символов» и «смысловых кодов» (здесь уже разделение по алфавитам). В результате было бы две кодировки — графическая и семантическая. Понятно, что это кардинально повлияло бы на все ОС и на весь софт, и мы бы жили в совсем другом мире:)
Зачем например в Unicode «направление письма»? Unicode это просто набор символов. Как их вводить, выводить и интерпретировать — дело софта. Вот в Китае и Японии направление письма вообще «сверху вниз», но ведь Unicode такое не поддерживает? И кстати, китайцы и японцы с появлением компьютеров вполне адаптировались к направлению «слева направо», может и арабы бы также адаптировались?
Далее, регистр символов — это особенность исключительно европейских языков, унаследованная из ASCII (который создавался в условиях гораздо более жесткой экономии оперативной памяти). Понятно что старались сделать обратную совместимость, но по большому счету регистр должен был стать «декорацией» (как bold, italic, subscript или superscript), а не отдельными кодовыми точками. Символы 'a' и 'a' (курсивом) — как-бы один символ, хотя они совершенно отличаются визуально. Символы 'a' и 'A' при этом — разные. Логика?
Из-за той же обратной совместимости осталась незадействованной большая часть символов в самом начале кодовой таблицы, с 0x00 до 0x1F. А между тем их стоило бы задействовать для наиболее употребительных спецсимволов (таких например как стрелки, дополнительные знаки пунктуации, некоторые математические символы и т.п.). Размещение этих символов в однобайтовой части важно, так как именно однобайтовая часть Unicode по очевидным причинам нанесена на все клавиатуры мира. Оставить в этой области можно было бы только нулевой код и код новой строки, и заодно провести редизайн концепции переноса строки, т.к. в основных системах (Win, Mac, Linux) перенос строки устроен по-разному (0x0D, 0x0A или оба сразу).
Ну и наверное можно еще накопать таких вот нелогичностей.
Интересно почему? Неужели этот процесс не изучить простым взятием анализов с каким-то периодом (пусть даже каждый день) у подопытных животных?
3dnews.ru/1035263/igri-spasut-mir-feature
Ну и сам способ организации массива может быть разным Иногда удобнее сплошным массивом, а иногда — когда не нужны все символы из диапазона — удобнее таблица указателей на отдельные массивы для каждого символа.
Впрочем, тут можно углубляться очень глубоко. Возможно, дело в текстовой клавиатуре и изначально текстовых интерфейсах пользователя. Или в изначально последовательном командном способе взаимодействия с компьютером. Или еще в чем-то.
Дело ведь не в формате, а в том, что всё связывание программ и организация потоков данных осуществляется через командную строку консоли. Когда-то у Microsoft была задумка — COM-объекты, ActiveX, встраивание одних документов и программ в другие… Но в конечном итоге оно пошло куда-то не туда, возможно технология была слишком сложной, или ей чего-то не хватало.
Насколько имеет смысл ограничиваться консолью и текстовым форматом (пусть и в JSON)? Не имеет ли смысл пересмотреть концепцию на более глубоком уровне, допустив, что у программ могут быть не только текстовые входы и выходы?