Совершенно верно. Поэтому фундаментальные математические константы должны быть нетипизированными и представлять соответствующие числа (Пи, Е и т.д.) как математические абстракции, а не как литералы конкретного типа. А это можно сделать только путем введения ключевых слов языка (возможно контекстных, видимых лишь в каком-то пространстве имен, не важно).
То есть, допустим, есть у нас "длинная арифметика" типа GMP - ОК, константа Pi и там будет константой той длины, которая используется в данный момент. Хоть килобайтной длины:)
Причем эту концепцию можно распространить и на все остальные литералы. Допустим, число 42: что это - int32, int64, uint8, float, double? Может вообще какой нибудь экзотический fixed point формат? Это должен решать компилятор с помощью автовывода типа. У литерала нет специальных суффиксов типа, но в большинстве существующих языков тип все равно прибит к литералу.
Аналогично, строковый литерал может быть однобайтовым (в одной из множества кодировок), utf8, utf16. utf32 и т.д. Конкретный тип пусть выводит компилятор.
Если мы хотим сделать литерал конкретного типа - используем явные суффиксы, конструкторы или приведение типов. В большинстве же случаев тип можно извлечь из контекста и опций компиляции.
Я задумывался о том, как лучше в языке программирования реализовать фундаментальные математические константы, так чтобы пользоваться ими было и быстро, и удобно, и интуитивно понятно. Предлагаемый вариант со знаками вопроса имеет проблему: в ASCII (а именно это множество берется за основу для алфавита языков) доступных спецсимволов всего 32, и они крайне дефицитны (отсюда и всевозможные составные операторы, и несколько функций у одного оператора в зависимости от контекста). В общем, жалко. Знак вопроса гораздо лучше подходит для реализации нуллабельности и опционалов.
В С/С++ математические константы определены в math.h (что конечно не совсем хорошо, учитывая, что во многих процессорах есть встроенные константы). И даже если использовать math.h - еще есть некий костыль в виде _USE_MATH_DEFINES, который тоже нужно писать каждый раз.
Хорошо бы сделать их просто ключевыми словами языка. И если с Pi это еще прокатит, то вот число E... ну нехорошо делать одну букву ключевым словом. Чисто эстетически нехорошо.
Использовать префиксы как в С++ (M_PI, M_2PI, M_E)? Вариант, но выглядит кривовато, не слишком эстетично.
Использовать пространства имен (Math.Pi, Math.E)? Тоже вариант, но по идее в том же Math должны содержаться и всякие синусы с косинусами; и если в некотором файле открыть это пространство имен (не писать же каждый раз Math.sin(x) и Math.cos(x)), то опять же однобуквенные имена типа E окажутся в области видимости.
В Go самый правильный (с моей точки зрения разумеется) синтаксис функций
начинаются с ключевого слова (кажется после С++ уже все поняли что так лучше)
ничего лишнего (двоеточия, стрелочки и прочий мусор)
обычные функции и лямбды имеют единый синтаксис (опять же никакой стремной экзотики с палками и стрелками); таким образом нет необходимости выделять лямбды в отдельную концепцию, это просто функции
Обожаю такие истории:) Вообще хорошо быть подростком, когда энергия прет через край, когда всё интересно, когда ты мог быть "в потоке" хоть часами напролет каждый день, и кодить, кодить, кодить...
Это все какая-то жуткая привязка к возможностям современного человечества и человеческим представлениям о мире. Как в эпоху космонавтики газеты наводнили всякие истории про пришельцев и НЛО, так и здесь - появились достаточно мощные компьютеры, и вот кому-то приходит в голову мысль "а не симуляция ли мы".
Нет, мы разумеется не симуляция в таком примитивном смысле этого слова. Но думаю, на фундаментальном уровне, физическая реальность имеет тесную связь с математикой и информатикой, то есть где-то там, на очень глубоком уровне понимания природы, нет принципиальной разницы между "реальностью" и "симуляцией". Задумайтесь например, что обеспечивает одинаковость масс покоя и зарядов всех электронов во Вселенной? Или постоянство скорости света? Есть некие правила, по которым Вселенная работает. И эти правила, сам факт их наличия, говорит о многом. Это верный признак наличия достаточно компактной информационной структуры, лежащей в основе всей этой немыслимо огромной Вселенной. При желании, это можно рассматривать как признак "симуляции", но разумеется не в примитивно-человеческом смысле этого слова.
А современные браузеры вообще поддерживают тег object и встраивание com-объектов в веб-страницы? Или это давно и окончательно выпилили?
Просто эта фишка в принципе могла бы быть полезна для локальных применений. Например у меня видеоархив, в котором есть какие-то древние форматы типа flv, и есть идея написать что-то вроде локального веб-приложения для каталогизации и просмотра всего этого. Официальный тег video их точно не поймет (что с моей точки зрения странно - ИМХО, должно проигрываться всё, для чего в системе установлены кодеки... но разаботчики стандарта решили иначе).
Я примерно так и сделал, скачал некую подборку maven offline, сделал как у них по инструкции. Но увы, все равно кто-то лезет в инет. Причем особенность там в том, что инет (там где я хочу все это поставить) есть, но специфический - пропускает запросы только с определенным user-agent. Я и с подменой заголовков играл - натыкаюсь на другие особенности, уже с https сертификатами и их подменой, версиями tls и прочим.
В общем, я к тому, что современный мир слишком завязан на инет. Исчезли те времена, когда можно было купить (или скачать) cd/dvd с полной оффлайн версией продукта (в том числе среды разработки) и спокойно пользоваться несколько лет, до выхода следующей верси. И это плохо еще тем, что вот такое самопроизвольно-непрерывное обновление всего и вся потенциально может что-то сломать в проекте. Программисты пакетов - тоже люди, и им тоже свойственно ошибаться.
Все-таки это скорее не перечисления, а вариантные типы или тегированные объединения. Еще названия - "алгебраический тип" (так и не понял смысл названия) или "тип-сумма" (в противоположность "типу-произведению" - обычной структуре).
Мне в этом вопросе интересна скорее сама математическая суть данного процесса. Как будет выглядеть логическая схема для синуса, будет ли она простой и элегантной или бессистемным нагромождением и мешаниной элементов, будут ли в ней какие-то закономерности, позволяющие ее масштабировать на большие разрядности и т.д.
Идея интересная. На питании и правда можно сэкономить, кому не нравится от смартфона - наверняка можно запитаться от power банка. Плюс, у кого-то это может быть приставка не к телефону, а к ноутбуку или компьютеру.
Что касается функционала... а что сейчас еще осталось в эфире незашифрованного сильной криптографией, что можно достаточно легко послушать или даже воспроизвести? Возможно в подобное устройство можно добавить какой-то более-менее универсальный радиосканнер? Или это уже резко повышает стоимость?
А вот интересно, есть ли достаточно эффективный (но не табличный) способ вычисления синуса и косинуса для чисел с фиксированной точкой (т.е. обычный целочисленный тип, где INT_MAX принят за 1)? Для простоты пусть будет даже обычный int8.
Интересно в том числе на аппаратном уровне: наверное можно составить таблицу истинности, по ней провести оптимизацию через карты Карно и попытаться вывести битовую формулу, из которой уже можно составить схему некоего синусатора на логических элементах, преобразующего int8 значение угла в int8 значение синуса.
Самый кринж это выступления "идеологов" типа Дугина. Вот несколько цитат
«В России живут люди, а на Западе - нелюди. Потому что пост-человек - это уже не людь». «Западную цивилизацию нужно вынести за скобки дальнейшего развития РФ». «К 2040 году долларов в мире вообще не останется». «После гей-прайда на Западе вот-вот появятся робот-прайд - права роботов, права пчёл».
И вот это вот... (даже не знаю какой эпитет подобрать) определяет политику правящих элит в стране.
Вообще удивительно куда мы прикатились. Но вот интересно: это "свернули не туда" или большинство именно туда и двигалось, целенаправленно и с самого начала? Ведь результаты выборов, пока они еще были выборами, нам всем хорошо известны начиная с 90-х... Так что вопрос - а не закономерный ли это результат? Глядя назад, кажется что большинству никогда особо и не нужна была свобода. Сначала им нужна была колбаса, затем - имперское величие (помните насчет солдат, которые будут омывать сапоги в индийском океане... это в каком году было?).
Числа с фиксированной точкой на уровне железа - это обычные целые числа. Но вот удерживать в памяти и постоянно писать в комментариях, что "вот в этой переменной с такого-то разряда начинается дробная часть" - крайне неудобно.
А еще бы хорошо иметь числа с фиксированной точкой. Может быть сейчас их и можно сделать на шаблонах и пользовательских литералах, не знаю. Для разных малых микроконтроллеров, где нет FPU, такие числа были бы весьма удобны.
Идею с INT_NAN поддерживаю.
Еще есть понятие обработки переполнения. Есть понятие режим насыщения, когда 255+1==255, а не 0, но не знаю в каких языках оно поддерживается. Зато в C# есть checked и unchecked. В общем, эти фундаментальные вещи хорошо бы иметь на уровне языка.
И еще конечно числа неограниченной длины на уровне числовых литералов (а не строковых, как делается во всяких GMP).
На самом деле, нам даже не нужно сложное описание "массив чисел и законы" — всё это можно просто склеить в одно очень-очень большое число. И тогда ваша симуляция — просто упорядоченный массив очень больших чисел.
Все мы - лишь очень большие числа. И сама наша Вселенная - просто очень большое число. А раз так, то на множестве чисел возможна функция, которая для каждого числа возвращает другое число, характеризующее уровень сознания своего аргумента. Скажем, для нуля это скорее всего будет ноль. А для числа, соответствующего конкретному человеку в конкретный момент времени - некоторое ненулевое значение.
Совершенно верно. Поэтому фундаментальные математические константы должны быть нетипизированными и представлять соответствующие числа (Пи, Е и т.д.) как математические абстракции, а не как литералы конкретного типа. А это можно сделать только путем введения ключевых слов языка (возможно контекстных, видимых лишь в каком-то пространстве имен, не важно).
То есть, допустим, есть у нас "длинная арифметика" типа GMP - ОК, константа Pi и там будет константой той длины, которая используется в данный момент. Хоть килобайтной длины:)
Причем эту концепцию можно распространить и на все остальные литералы. Допустим, число 42: что это - int32, int64, uint8, float, double? Может вообще какой нибудь экзотический fixed point формат? Это должен решать компилятор с помощью автовывода типа. У литерала нет специальных суффиксов типа, но в большинстве существующих языков тип все равно прибит к литералу.
Аналогично, строковый литерал может быть однобайтовым (в одной из множества кодировок), utf8, utf16. utf32 и т.д. Конкретный тип пусть выводит компилятор.
Если мы хотим сделать литерал конкретного типа - используем явные суффиксы, конструкторы или приведение типов. В большинстве же случаев тип можно извлечь из контекста и опций компиляции.
Я задумывался о том, как лучше в языке программирования реализовать фундаментальные математические константы, так чтобы пользоваться ими было и быстро, и удобно, и интуитивно понятно. Предлагаемый вариант со знаками вопроса имеет проблему: в ASCII (а именно это множество берется за основу для алфавита языков) доступных спецсимволов всего 32, и они крайне дефицитны (отсюда и всевозможные составные операторы, и несколько функций у одного оператора в зависимости от контекста). В общем, жалко. Знак вопроса гораздо лучше подходит для реализации нуллабельности и опционалов.
В С/С++ математические константы определены в math.h (что конечно не совсем хорошо, учитывая, что во многих процессорах есть встроенные константы). И даже если использовать math.h - еще есть некий костыль в виде _USE_MATH_DEFINES, который тоже нужно писать каждый раз.
Хорошо бы сделать их просто ключевыми словами языка. И если с Pi это еще прокатит, то вот число E... ну нехорошо делать одну букву ключевым словом. Чисто эстетически нехорошо.
Использовать префиксы как в С++ (M_PI, M_2PI, M_E)? Вариант, но выглядит кривовато, не слишком эстетично.
Использовать пространства имен (Math.Pi, Math.E)? Тоже вариант, но по идее в том же Math должны содержаться и всякие синусы с косинусами; и если в некотором файле открыть это пространство имен (не писать же каждый раз Math.sin(x) и Math.cos(x)), то опять же однобуквенные имена типа E окажутся в области видимости.
В Go самый правильный (с моей точки зрения разумеется) синтаксис функций
начинаются с ключевого слова (кажется после С++ уже все поняли что так лучше)
ничего лишнего (двоеточия, стрелочки и прочий мусор)
обычные функции и лямбды имеют единый синтаксис (опять же никакой стремной экзотики с палками и стрелками); таким образом нет необходимости выделять лямбды в отдельную концепцию, это просто функции
Думаю, не опаснее чем на Солнце.
Обожаю такие истории:) Вообще хорошо быть подростком, когда энергия прет через край, когда всё интересно, когда ты мог быть "в потоке" хоть часами напролет каждый день, и кодить, кодить, кодить...
Это все какая-то жуткая привязка к возможностям современного человечества и человеческим представлениям о мире. Как в эпоху космонавтики газеты наводнили всякие истории про пришельцев и НЛО, так и здесь - появились достаточно мощные компьютеры, и вот кому-то приходит в голову мысль "а не симуляция ли мы".
Нет, мы разумеется не симуляция в таком примитивном смысле этого слова. Но думаю, на фундаментальном уровне, физическая реальность имеет тесную связь с математикой и информатикой, то есть где-то там, на очень глубоком уровне понимания природы, нет принципиальной разницы между "реальностью" и "симуляцией". Задумайтесь например, что обеспечивает одинаковость масс покоя и зарядов всех электронов во Вселенной? Или постоянство скорости света? Есть некие правила, по которым Вселенная работает. И эти правила, сам факт их наличия, говорит о многом. Это верный признак наличия достаточно компактной информационной структуры, лежащей в основе всей этой немыслимо огромной Вселенной. При желании, это можно рассматривать как признак "симуляции", но разумеется не в примитивно-человеческом смысле этого слова.
А современные браузеры вообще поддерживают тег object и встраивание com-объектов в веб-страницы? Или это давно и окончательно выпилили?
Просто эта фишка в принципе могла бы быть полезна для локальных применений. Например у меня видеоархив, в котором есть какие-то древние форматы типа flv, и есть идея написать что-то вроде локального веб-приложения для каталогизации и просмотра всего этого. Официальный тег video их точно не поймет (что с моей точки зрения странно - ИМХО, должно проигрываться всё, для чего в системе установлены кодеки... но разаботчики стандарта решили иначе).
Эх, вот было бы оно заочное и бесплатное)))
Я примерно так и сделал, скачал некую подборку maven offline, сделал как у них по инструкции. Но увы, все равно кто-то лезет в инет. Причем особенность там в том, что инет (там где я хочу все это поставить) есть, но специфический - пропускает запросы только с определенным user-agent. Я и с подменой заголовков играл - натыкаюсь на другие особенности, уже с https сертификатами и их подменой, версиями tls и прочим.
В общем, я к тому, что современный мир слишком завязан на инет. Исчезли те времена, когда можно было купить (или скачать) cd/dvd с полной оффлайн версией продукта (в том числе среды разработки) и спокойно пользоваться несколько лет, до выхода следующей верси. И это плохо еще тем, что вот такое самопроизвольно-непрерывное обновление всего и вся потенциально может что-то сломать в проекте. Программисты пакетов - тоже люди, и им тоже свойственно ошибаться.
А есть вообще способ заставить работать этот gradle без доступа к интернету? Даже простейший hello world для андроида - и то лезет что-то скачивать.
Все-таки это скорее не перечисления, а вариантные типы или тегированные объединения. Еще названия - "алгебраический тип" (так и не понял смысл названия) или "тип-сумма" (в противоположность "типу-произведению" - обычной структуре).
Мне в этом вопросе интересна скорее сама математическая суть данного процесса. Как будет выглядеть логическая схема для синуса, будет ли она простой и элегантной или бессистемным нагромождением и мешаниной элементов, будут ли в ней какие-то закономерности, позволяющие ее масштабировать на большие разрядности и т.д.
Идея интересная. На питании и правда можно сэкономить, кому не нравится от смартфона - наверняка можно запитаться от power банка. Плюс, у кого-то это может быть приставка не к телефону, а к ноутбуку или компьютеру.
Что касается функционала... а что сейчас еще осталось в эфире незашифрованного сильной криптографией, что можно достаточно легко послушать или даже воспроизвести? Возможно в подобное устройство можно добавить какой-то более-менее универсальный радиосканнер? Или это уже резко повышает стоимость?
А вот интересно, есть ли достаточно эффективный (но не табличный) способ вычисления синуса и косинуса для чисел с фиксированной точкой (т.е. обычный целочисленный тип, где INT_MAX принят за 1)? Для простоты пусть будет даже обычный int8.
Интересно в том числе на аппаратном уровне: наверное можно составить таблицу истинности, по ней провести оптимизацию через карты Карно и попытаться вывести битовую формулу, из которой уже можно составить схему некоего синусатора на логических элементах, преобразующего int8 значение угла в int8 значение синуса.
Самый кринж это выступления "идеологов" типа Дугина. Вот несколько цитат
И вот это вот... (даже не знаю какой эпитет подобрать) определяет политику правящих элит в стране.
Вообще удивительно куда мы прикатились. Но вот интересно: это "свернули не туда" или большинство именно туда и двигалось, целенаправленно и с самого начала? Ведь результаты выборов, пока они еще были выборами, нам всем хорошо известны начиная с 90-х... Так что вопрос - а не закономерный ли это результат? Глядя назад, кажется что большинству никогда особо и не нужна была свобода. Сначала им нужна была колбаса, затем - имперское величие (помните насчет солдат, которые будут омывать сапоги в индийском океане... это в каком году было?).
Числа с фиксированной точкой на уровне железа - это обычные целые числа. Но вот удерживать в памяти и постоянно писать в комментариях, что "вот в этой переменной с такого-то разряда начинается дробная часть" - крайне неудобно.
А еще бы хорошо иметь числа с фиксированной точкой. Может быть сейчас их и можно сделать на шаблонах и пользовательских литералах, не знаю. Для разных малых микроконтроллеров, где нет FPU, такие числа были бы весьма удобны.
Идею с INT_NAN поддерживаю.
Еще есть понятие обработки переполнения. Есть понятие режим насыщения, когда 255+1==255, а не 0, но не знаю в каких языках оно поддерживается. Зато в C# есть checked и unchecked. В общем, эти фундаментальные вещи хорошо бы иметь на уровне языка.
И еще конечно числа неограниченной длины на уровне числовых литералов (а не строковых, как делается во всяких GMP).
Да, определенно нужна хорошая статья (а лучше серия статей) по трейтам в Rust. Желательно с точки зрения программиста С++ :)
Все мы - лишь очень большие числа. И сама наша Вселенная - просто очень большое число. А раз так, то на множестве чисел возможна функция, которая для каждого числа возвращает другое число, характеризующее уровень сознания своего аргумента. Скажем, для нуля это скорее всего будет ноль. А для числа, соответствующего конкретному человеку в конкретный момент времени - некоторое ненулевое значение.