Если предположить, что благодаря истинной (квантовой) случайности для каждого момента настоящего возможно множество вариантов будущего, то почему бы не быть и обратному - для каждого момента настоящего возможно множество вариантов прошлого, приводящих к данному настоящему. Но у людей настолько жестко в мозгах зашита концепция "одномерного однонаправленного времени", что отказаться от нее не так уж и просто. Правда, большинству даже многомерное время представить практически невозможно, хотя многомерное (>3) пространство - вполне можно.
Ну если обобщать, то это касается не только C#. Другие современные высокоуровневые компилируемые языки со статической типизацией, такие как Go и Swift, также обладают этими преимуществами - как перед более низкоуровневыми С/С++, так и перед интерпретируемыми динамическими JS/Python.
И то и другое:) Я часто переключаюсь между окнами, часто работаю так чтобы было видно несколько окон сразу. А уж место экономить, на современных мониторах, это смешно))
Окна у которых нет заголовка - это ужасно. Такое окно сложно перетаскивать (каждый раз нужно угадывать за что цеплять мышью), более того, если на экране много окон, то нередко для таких окон даже не определить границу где оно начинается.
К сожалению, сейчас это какой-то тренд. Например у современных браузеров нередко такое поведение по умолчанию; у некоторых в настройках можно вернуть "классический заголовок", но увы - не у всех.
Закос под Мак в виде центрированных значков снизу - зачем?
И вообще, сколько уже можно прибивать интерфейс рабочего стола к версии ОС гвоздями. Ведь по сути это просто программа explorer.exe. Сделали бы на выбор несколько, включая классический, десяточный, маковидный и еще какие нибудь для любителей экзотики.
Все эти нюансы можно и нужно учитывать при формализации и построении онтологий. Вот прямо так - отдельно "физическая бесконечно малая", отдельно "математическая бесконечно малая", для них обобщение "просто бесконечно малая", к этим понятиям уже цепляются еще более неформальные языковые формы, и т.д.
Я лишь говорю о том, что языковая вероятностная модель - самая неудобная для науки, потому что она основана на интернет-болтовне миллиардов людей, и по сути ничего кроме этой болтовни воспроизводить не может. Вместо Сингулярности мы построим совершенную болталку, которая будет писать нам идеальные художественные книги, снимать идеальные художественные фильмы, но ни на шаг не приблизит нас к решению фундаментальных вопросов и задач Физики, Биологии и Всего Такого.
Языковая вероятностная модель разумеется не предназначена для точной математики, там нужна именно математическая модель. Да, наверное какая-то логика в вероятностной языковой нейросети имеется, но она появляется там как побочный продукт огромного объема входных данных и размазана весьма тонким и неравномерным слоем. Это не то, чему можно безоговорочно доверять, как доверяем мы например арифметическим операциям в процессоре.
Вообще, языковая модель в моем представлении - это лишь мостик между несоврешенным человекоориентированным представлением информации и более совершенным AI-ориентированным, существующим в более формальном виде, подобно тому как формулы существуют в системах символьной алгебры. Это очень важный мостик, ибо перегнать вручную весь огромный объем знаний, накопленный человечеством, в машинно-ориентирванную форму, кажется практически невозможным (хотя прецеденты есть: тут на Хабре были статьи о формализация математики, о попытках создания онтологической базы знаний и т.п.). С помошью ИИ мы сделаем это достаточно быстро. И это важнейшая задача на сегодня - формализация знаний. Нельзя останавливаться на языковом уровне, нужно идти дальше, и языковые ИИ в этом деле отличные помощники, но не конечная цель или конечный результат развития ИИ как такового.
Кстати а что следует понимать под "количеством параметром", есть точное определение? Я пытался у ChatGPT выяснить, он тоже точно не знает. Это вроде и не число нейронов, и не число связей, а что же того?
Вы бы рассказали что ваш язык умеет, какие языковые конструкции поддерживает. Например массивы, структуры, перечисления, функции и будут ли функции first-class объектами (т.е. лямбды, замыкания и прочее), кортежи (нетипизированные составные литералы), рефлексия, метапрограммирование и т.д. Какие будут операции? Из того что я понял только совсем стандартные, но если у вас низкоуровневый язык то может имеет смысл подумать о более специфических битовых операциях? Например в системе команд x86 есть битовое вращение, битовое сканирование, есть установка, сброс и получение бита по номеру, эти операции в Си не представлены.
Непарные кавычки и скобки - это уже уровень лексических макросов, т.е. существующий препроцессор С/С++. Я предлагаю только уровень синтаксических макросов, а значит - работа с законченными нодами синтаксического дерева, там непарных скобок и кавычек быть не может. Приведенный вами пример с точки зрения синтаксического анализа совершенно корректен и никаких проблем с ним не будет. Ошибка может выявиться только если передать блок несовместимый с "else", но это будет не бред на десятки строк, как сейчас при метапрограммировании на шаблонах, а вполне конкретная ошибка компиляци - такая же, как если бы вы вручную написали "else" без "if".
Точки останова по данным - классная штука, но почему-то до сих пор в Visual Studio не добавили такую простую возможность, как установка точки по данным из контекстного меню окон просмотра переменных (Locals, Watch). Приходится вбивать выражение с "&" (с адресом переменной) и затем вручную вбивать этот адрес в шестнадцатеричном виде в окно установки точки по изменению данных.
Лямбды это рантайм-механизм, а иногда нужно генерировать именно синтаксические деревья определенного вида для последующей компиляции. "Фрагментом кода" может быть например просто имя (последовательность символов, допустимая для идентификатора), которое где-то в шаблоне будет использовано как имя (или даже часть имени) поля, метода, вложенного класса...
Как по мне, так формат makefiles это абсолютнейший, лютейший бред (также как и bash, и то и другое - продукты одного исторического периода). Как можно вообще с этим ископаемым форматом комфортно работать? Почему нельзя сделать все структурированно, в xml или json. У каждого проекта есть корень, в нем указывается имя проекта, далее могут быть секции с конфигурациями, секции со списками файлов, у каждой секции опять же должно быть имя в корне и структурированное содержимое. Каждая конфигурация должна содержать внутренние секции, отвечающие за разные группы опций компиляции. Если нужны разные компиляторы и прочие инструменты - тоже можно придумать соответствующий тип секции, с явным указанием что это "инструмент сборки" и именем. То есть, формат должен быть такой, чтобы его можно было максимально прозрачно отобразить на GUI окно настроек проекта.
Да уж, глубина глубин... А ведь вы еще даже метапрограммирование на шаблонах не затронули! И самое главное - как удалось породить такое из простой, естественной и очевидной идеи параметризировать классы и функции на этапе компиляции по типу макросов. Универсальный, не зависящий от типа данных код для классов массивов, списков, алгоритмов поиска и сортировки и т.п.... Просто и естественно. И вот во что это вылилось.
Все эти изменения... с одной стороны наверное они нужны и оправданы, но с другой ориентироваться в них все сложнее. Все эти тонкости шаблонного метапрограммирования, порождающие какие-то неоднозначности, требующие для разрешения очередные усложнения языка... В то же время простые вещи, такие как языковые расширения C/C++ https://gcc.gnu.org/onlinedocs/gcc-5.3.0/gcc/C-Extensions.html , в стандарт не попадают. Также я как-то давно предлагал на форуме isocpp расширить шаблоны возможностью использовать обычные фрагменты кода (не функции, а просто код в фигурных скобках) в качестве параметров и в качестве самих шаблонов (получилась бы удобная замена макросам для низкоуровневой кодогенерации), но отклонили.
Доступ только через Edge? Если да, то у меня вопрос - как получить доступ из Win7 или Linux? Они по user-agent определяют браузер? Если да, то какие браузеры сейчас позволяют прописывать user-agent и что прописывать?
Если предположить, что благодаря истинной (квантовой) случайности для каждого момента настоящего возможно множество вариантов будущего, то почему бы не быть и обратному - для каждого момента настоящего возможно множество вариантов прошлого, приводящих к данному настоящему. Но у людей настолько жестко в мозгах зашита концепция "одномерного однонаправленного времени", что отказаться от нее не так уж и просто. Правда, большинству даже многомерное время представить практически невозможно, хотя многомерное (>3) пространство - вполне можно.
Ну если обобщать, то это касается не только C#. Другие современные высокоуровневые компилируемые языки со статической типизацией, такие как Go и Swift, также обладают этими преимуществами - как перед более низкоуровневыми С/С++, так и перед интерпретируемыми динамическими JS/Python.
Ну это понятно почему - без явных релизов очередной версии с очередным номером интерес к продукту падает, что плохо сказывается на продажах.
И то и другое:) Я часто переключаюсь между окнами, часто работаю так чтобы было видно несколько окон сразу. А уж место экономить, на современных мониторах, это смешно))
В сравнении с LLAMA аналогичного размера, лучше или хуже?
Окна у которых нет заголовка - это ужасно. Такое окно сложно перетаскивать (каждый раз нужно угадывать за что цеплять мышью), более того, если на экране много окон, то нередко для таких окон даже не определить границу где оно начинается.
К сожалению, сейчас это какой-то тренд. Например у современных браузеров нередко такое поведение по умолчанию; у некоторых в настройках можно вернуть "классический заголовок", но увы - не у всех.
Закос под Мак в виде центрированных значков снизу - зачем?
И вообще, сколько уже можно прибивать интерфейс рабочего стола к версии ОС гвоздями. Ведь по сути это просто программа explorer.exe. Сделали бы на выбор несколько, включая классический, десяточный, маковидный и еще какие нибудь для любителей экзотики.
Интересно почему LaTeX не приняли в качестве официального средства html для формул, а вместо него придумали громоздкий mathml?
Все эти нюансы можно и нужно учитывать при формализации и построении онтологий. Вот прямо так - отдельно "физическая бесконечно малая", отдельно "математическая бесконечно малая", для них обобщение "просто бесконечно малая", к этим понятиям уже цепляются еще более неформальные языковые формы, и т.д.
Я лишь говорю о том, что языковая вероятностная модель - самая неудобная для науки, потому что она основана на интернет-болтовне миллиардов людей, и по сути ничего кроме этой болтовни воспроизводить не может. Вместо Сингулярности мы построим совершенную болталку, которая будет писать нам идеальные художественные книги, снимать идеальные художественные фильмы, но ни на шаг не приблизит нас к решению фундаментальных вопросов и задач Физики, Биологии и Всего Такого.
Языковая вероятностная модель разумеется не предназначена для точной математики, там нужна именно математическая модель. Да, наверное какая-то логика в вероятностной языковой нейросети имеется, но она появляется там как побочный продукт огромного объема входных данных и размазана весьма тонким и неравномерным слоем. Это не то, чему можно безоговорочно доверять, как доверяем мы например арифметическим операциям в процессоре.
Вообще, языковая модель в моем представлении - это лишь мостик между несоврешенным человекоориентированным представлением информации и более совершенным AI-ориентированным, существующим в более формальном виде, подобно тому как формулы существуют в системах символьной алгебры. Это очень важный мостик, ибо перегнать вручную весь огромный объем знаний, накопленный человечеством, в машинно-ориентирванную форму, кажется практически невозможным (хотя прецеденты есть: тут на Хабре были статьи о формализация математики, о попытках создания онтологической базы знаний и т.п.). С помошью ИИ мы сделаем это достаточно быстро. И это важнейшая задача на сегодня - формализация знаний. Нельзя останавливаться на языковом уровне, нужно идти дальше, и языковые ИИ в этом деле отличные помощники, но не конечная цель или конечный результат развития ИИ как такового.
Кстати а что следует понимать под "количеством параметром", есть точное определение? Я пытался у ChatGPT выяснить, он тоже точно не знает. Это вроде и не число нейронов, и не число связей, а что же того?
Вы бы рассказали что ваш язык умеет, какие языковые конструкции поддерживает. Например массивы, структуры, перечисления, функции и будут ли функции first-class объектами (т.е. лямбды, замыкания и прочее), кортежи (нетипизированные составные литералы), рефлексия, метапрограммирование и т.д. Какие будут операции? Из того что я понял только совсем стандартные, но если у вас низкоуровневый язык то может имеет смысл подумать о более специфических битовых операциях? Например в системе команд x86 есть битовое вращение, битовое сканирование, есть установка, сброс и получение бита по номеру, эти операции в Си не представлены.
Непарные кавычки и скобки - это уже уровень лексических макросов, т.е. существующий препроцессор С/С++. Я предлагаю только уровень синтаксических макросов, а значит - работа с законченными нодами синтаксического дерева, там непарных скобок и кавычек быть не может. Приведенный вами пример с точки зрения синтаксического анализа совершенно корректен и никаких проблем с ним не будет. Ошибка может выявиться только если передать блок несовместимый с "else", но это будет не бред на десятки строк, как сейчас при метапрограммировании на шаблонах, а вполне конкретная ошибка компиляци - такая же, как если бы вы вручную написали "else" без "if".
Точки останова по данным - классная штука, но почему-то до сих пор в Visual Studio не добавили такую простую возможность, как установка точки по данным из контекстного меню окон просмотра переменных (Locals, Watch). Приходится вбивать выражение с "&" (с адресом переменной) и затем вручную вбивать этот адрес в шестнадцатеричном виде в окно установки точки по изменению данных.
Лямбды это рантайм-механизм, а иногда нужно генерировать именно синтаксические деревья определенного вида для последующей компиляции. "Фрагментом кода" может быть например просто имя (последовательность символов, допустимая для идентификатора), которое где-то в шаблоне будет использовано как имя (или даже часть имени) поля, метода, вложенного класса...
Как по мне, так формат makefiles это абсолютнейший, лютейший бред (также как и bash, и то и другое - продукты одного исторического периода). Как можно вообще с этим ископаемым форматом комфортно работать? Почему нельзя сделать все структурированно, в xml или json. У каждого проекта есть корень, в нем указывается имя проекта, далее могут быть секции с конфигурациями, секции со списками файлов, у каждой секции опять же должно быть имя в корне и структурированное содержимое. Каждая конфигурация должна содержать внутренние секции, отвечающие за разные группы опций компиляции. Если нужны разные компиляторы и прочие инструменты - тоже можно придумать соответствующий тип секции, с явным указанием что это "инструмент сборки" и именем. То есть, формат должен быть такой, чтобы его можно было максимально прозрачно отобразить на GUI окно настроек проекта.
Да уж, глубина глубин... А ведь вы еще даже метапрограммирование на шаблонах не затронули! И самое главное - как удалось породить такое из простой, естественной и очевидной идеи параметризировать классы и функции на этапе компиляции по типу макросов. Универсальный, не зависящий от типа данных код для классов массивов, списков, алгоритмов поиска и сортировки и т.п.... Просто и естественно. И вот во что это вылилось.
Все эти изменения... с одной стороны наверное они нужны и оправданы, но с другой ориентироваться в них все сложнее. Все эти тонкости шаблонного метапрограммирования, порождающие какие-то неоднозначности, требующие для разрешения очередные усложнения языка... В то же время простые вещи, такие как языковые расширения C/C++ https://gcc.gnu.org/onlinedocs/gcc-5.3.0/gcc/C-Extensions.html , в стандарт не попадают. Также я как-то давно предлагал на форуме isocpp расширить шаблоны возможностью использовать обычные фрагменты кода (не функции, а просто код в фигурных скобках) в качестве параметров и в качестве самих шаблонов (получилась бы удобная замена макросам для низкоуровневой кодогенерации), но отклонили.
На семерке нет:( Вчера пробовал последние релизы установить - точто не ставятся.
Доступ только через Edge? Если да, то у меня вопрос - как получить доступ из Win7 или Linux? Они по user-agent определяют браузер? Если да, то какие браузеры сейчас позволяют прописывать user-agent и что прописывать?
И в догонку - нужен ли VPN для доступа из РФ?
Сингулярность придет - порядок наведет. А вообще, не блог ли вы свой пиарите? :)