Я допустил возможность материализации энергии, поскольку это довольно таки распространённая точка зрения (см. ссылку на Брукхейвенскую национальную лабораторию). Если всё-таки энергия не может материализоваться (я это допускаю), то как объясняется обратный процесс - высвобождение энергии в результате ядерного взрыва? Значит ли это, что "кол-во материи" остаётся неизменным, просто она переходит в более низкоэнергетическое состояние?
ОК, я могу допустить, что энергия не материализуется, а лишь перераспределяется (тут зависит пропадают ли фотоны, порождающие электрон с позитроном, или летят себе дальше). В таком случае ничего не материализуется, ибо существует всегда. Просто энергия перераспределяется, изменяя состояние материи (были фотоны - стали электрон с позитроном). Это не противоречит высказанному мной тезису, что "обычно функции в частицы не превращаются".
Так я и говорю, что не нужно отождествлять средства языка, описывающего явления, с самими явлениями. Функции не материализуются. Они описывают процесс материализации, не более того. Вот я и докопался до "А когда волновая функция (функция вероятности...) превращается в частицу". На мой взгляд, в этом столько же смысла, как и в "а когда зелёное превращается в тёплое". Да, я могу представить себе условия, при которых это возможно, но наблюдаемая мной с детства Вселенная им не соответствует. Но я продолжаю вести наблюдение.
Т.е., вы хотите сказать, что физических явлений не существует в принципе? Что всё есть игра ума? Ну в таком случае - да, функция может препратиться в частицу. И то, и то - абстракции.
Я, по старинке, все-таки пока ещё различаю физические явления и их математическое описание. Для меня электрическое поле - это некая реальность, свойства которой можно описать математически. Математика - это всего лишь язык. Как английский, русский и т.д. Но у вас вполне может быть другой взгляд на эти вещи.
А не наоборот ли? Римская "единичка" даёт мне основание думать, что сначала люди начали записывать количество чего-нибудь, а уже сильно потом начали думать, как записать звуки. Кстати, иероглифы - это не буквы, если что.
Какой шаг следующий после этого, сами догадаетесь, или мне расписать?
Лучше, конечно, помучиться расписать. Судя по приведённой аналогии, ничего единого там не будет. Пойдёт ещё большее разнообразие на элементах предыдущего уровня (человеках). Так что до единого Бога там, как пешком до Африки.
сновное открытие состоит в том, что пары электронов и позитронов — частицы вещества и антивещества — могут быть созданы непосредственно путем столкновения очень энергичных фотонов, которые представляют собой квантовые "пакеты" света.
Вот эта вот формула "E=mc2" является математической функцией и связывает энергию и массу. Массой обладает вещество. Я допускаю, что энергия без вещества не существует. В конце-концов, чтобы получились электрон и позитрон нужны фотоны. Но тем не менее, энергия (фотонов) таки превращается в материю (электрон и позитрон). По крайней мере, чуваки из Брукхейвенской национальной лаборатории в США считают, что они это "убедительно доказали".
"Функция координат и скоростей" - это наше математическое описание физического явления. Причём приближённое, в меру нашего текущего понимания происходящих процессов. Поэтому, когда говорят, что "функция материализуется", для меня это звучит как "зелёное становится мягким".
Поэтому я остаюсь при своём мнении, что обычно "зелёное" (функция, математика) "мягким" (вещество, физика) не становится. "функция вероятности, которая ни с чем не взаимодействует, а лишь определяет потенциал взаимодействия" - это есть чистая математика, описание нашего представления реальных физических процессов.
Я бы сказал, появилась. Потому что частица была и до, но не здесь. Но вы правы, это не диссертация и следить незачем. Хотя на самом деле материализовался я задолго то того, как попал в бар ;)
Так электрон - это материя или нет? Если - да, то может ли материя материализоваться повторно? Если - нет, то что такое электрон?
Насколько я понимаю, "волновая функция" - это вероятность (плотность вероятности) обнаружения чего-то/кого-то в таком-то месте в такое-то время. Когда я в пятницу вечером собираюсь прошвырнуться по барам, для меня ведь тоже можно составить волновую функцию, разве нет? А когда вы меня обнаружите в каком-то баре, то это и будет означать "схлопывание волновой функции", ведь так? Значит ли это, что я материализовался в конкретном баре в момент обнаружения?
Можно. Но вряд ли это будет "обычное использование". Мне, например, сложно представить, как функция, "которая ни чем не взаимодействует, а лишь определяет", превращается в частицу. Обычно функции в частицы не превращаются. Тем более ни с того, ни с сего, без взаимодействия. Допускаю, что в частицу превращается нечто другое, та же энергия, например. Но называть что угодно можно как угодно. Просто с взаимопониманием возникнет напряг.
Поздравляю с отпуском! Отпуск - это прекрасно!! Я ничего не выиграл, просто потратил время на просмотр статьи по диагонали (на первых двух экранах стало понятно, что там не будет того, на что я надеялся по заголовку) и чтение какого-то кол-ва комментов (чтобы понять, был ли у кого-то ещё, кроме меня, рассинхрон между заголовком и содержимым). Наткнулся на ваши "100% прагматизма" вот и не выдержал. Прагматизм во мне помещается в каких-то объёмах, но в не настолько больших, чтобы удержать меня от бессмысленного комментирования чужих комментов :)
Вы считаете, что это невозможно? Или что в таком случае это обязательно будет "код"? Ну, в таком случае я со своей стороны могу сказать, что любой код - это список требований.
На Хабре разный контингент. Что бы вы ни сказали, всегда найдётся кто-нибудь, кто будет чем-то недоволен. Причин масса - "вот только не надо подкалывать", "нечего дурость тут свою демонстрировать", "я слишком ценю своё время, чтобы читать комменты-пустышки" ну и т.д. Слишком большая аудитория слишком разных людей. Я как-то сформулировал и опубликовал тут же свой ответ на вопрос "почему минусуют" - "потому что могут". Забанили на год под предлогом "вас взломали!". Ну, вот так это тут работает. Просто не относитесь серьёзно к минусам и банам :)
Вот что-то мне показалось, что в чём-то автор лукавит. "Если вы не понимаете, как работает Нода, то сядьте и разберитесь в ней." (с) Ага, и с Пайтоном так же? И с JS? И с TS? А есть ещё Java, PHP, C#, Go тот же. RDBMS - сядьте и разберитесь с Oracle/MS SQL/PostgreSQL. Изучите отличия MariaDB от MySQL. А потом разберите отличия всего это многообразия от NoSQL DBs, объектно-ориентированных БД, БД документов и иерархических БД. Чем отличается Tailwind от CSS3. Когда лучше применять React, когда Angular, а когда Vue? Для чего нужен Svelte? Нужен ли вообще $mol? Можно изучить ещё различия PHP'шных фреймворков друг от друга - Laravel, Symfony. Java'вский Spring. Занырнуть в архитектуру и особенности функционирования WordPress, Magento, Joomla, Django, Odoo, 1C, Liferay. Понять чем CMS отличаются от CRM, а всё это от ERP и BPMS.
Мне кажется, что тут зарождается (или уже родилась?) новая религия "Сядь и разберись, если не понятно". Я вас уверяю, что все, кто писал, с точки зрения автора, говно-проекты, именно так и сделали - сели и разобрались. А получилось, что получилось. Кто-то разбирается лучше, кто-то хуже. Автор может всем ответственно заявить, что он уже разобрался с Нодой? Или хотя бы хоть с чем-то разобрался до конца?
"Я знаю только то, что ничего не знаю, но другие не знают и этого" (с) Сократ
Я не пробрасываю типы (вернее, классы/объекты/функции), я использую их напрямую там, где в них есть необходимость. Контейнер знает, каким образом получить доступ к каждому es-модулю проекта и его содержимому (экспорту). Он может напрямую создавать требуемые объекты, без посредников. В данном примере это описано в пункте "7. Карта зависимостей" в виде переменной map, где зависимости между идентификатором зависимости и местом расположения его исходников прописано вручную.
В реальных проектах идентификаторы зависимостей выглядят более кучеряво и, как правило, основаны на полном имени класса, который создаёт нужную для внедрения зависимость (например com.vendor.project.module.BaseClass - в Java или /Vendor/Project/Module/BaseClass в PHP). Так как идентификатор зависимости - это строка, то лишь от фантазии разработчика зависит, какие правила он использует для преобразования строки в:
путь к файлу с исходниками для импорта;
определение нужного экспорта внутри es6-модуля;
флаг создания нового экземпляра зависимости (transient) или передачи уже существующего (singleton);
флаг добавления адаптора (wrapper'а) к создаваемой зависимости;
Зависимость - это не просто тип (уровень исходного кода), это объект, существующий в runtime. Тут не столько в терминах исходного кода нужно мыслить, сколько в терминах работающей программы (те же синглтоны).
Спасибо за вопрос, очень полезный оказался, как минимум для меня.
Я допустил возможность материализации энергии, поскольку это довольно таки распространённая точка зрения (см. ссылку на Брукхейвенскую национальную лабораторию). Если всё-таки энергия не может материализоваться (я это допускаю), то как объясняется обратный процесс - высвобождение энергии в результате ядерного взрыва? Значит ли это, что "кол-во материи" остаётся неизменным, просто она переходит в более низкоэнергетическое состояние?
ОК, я могу допустить, что энергия не материализуется, а лишь перераспределяется (тут зависит пропадают ли фотоны, порождающие электрон с позитроном, или летят себе дальше). В таком случае ничего не материализуется, ибо существует всегда. Просто энергия перераспределяется, изменяя состояние материи (были фотоны - стали электрон с позитроном). Это не противоречит высказанному мной тезису, что "обычно функции в частицы не превращаются".
Так я и говорю, что не нужно отождествлять средства языка, описывающего явления, с самими явлениями. Функции не материализуются. Они описывают процесс материализации, не более того. Вот я и докопался до "А когда волновая функция (функция вероятности...) превращается в частицу". На мой взгляд, в этом столько же смысла, как и в "а когда зелёное превращается в тёплое". Да, я могу представить себе условия, при которых это возможно, но наблюдаемая мной с детства Вселенная им не соответствует. Но я продолжаю вести наблюдение.
Т.е., вы хотите сказать, что физических явлений не существует в принципе? Что всё есть игра ума? Ну в таком случае - да, функция может препратиться в частицу. И то, и то - абстракции.
Я, по старинке, все-таки пока ещё различаю физические явления и их математическое описание. Для меня электрическое поле - это некая реальность, свойства которой можно описать математически. Математика - это всего лишь язык. Как английский, русский и т.д. Но у вас вполне может быть другой взгляд на эти вещи.
А не наоборот ли? Римская "единичка" даёт мне основание думать, что сначала люди начали записывать количество чего-нибудь, а уже сильно потом начали думать, как записать звуки. Кстати, иероглифы - это не буквы, если что.
Лучше, конечно,
помучитьсярасписать. Судя по приведённой аналогии, ничего единого там не будет. Пойдёт ещё большее разнообразие на элементах предыдущего уровня (человеках). Так что до единого Бога там, как пешком до Африки.https://ria.ru/20210730/fotony-1743632531.html
Вот эта вот формула "E=mc2" является математической функцией и связывает энергию и массу. Массой обладает вещество. Я допускаю, что энергия без вещества не существует. В конце-концов, чтобы получились электрон и позитрон нужны фотоны. Но тем не менее, энергия (фотонов) таки превращается в материю (электрон и позитрон). По крайней мере, чуваки из Брукхейвенской национальной лаборатории в США считают, что они это "убедительно доказали".
"Функция координат и скоростей" - это наше математическое описание физического явления. Причём приближённое, в меру нашего текущего понимания происходящих процессов. Поэтому, когда говорят, что "функция материализуется", для меня это звучит как "зелёное становится мягким".
Поэтому я остаюсь при своём мнении, что обычно "зелёное" (функция, математика) "мягким" (вещество, физика) не становится. "функция вероятности, которая ни с чем не взаимодействует, а лишь определяет потенциал взаимодействия" - это есть чистая математика, описание нашего представления реальных физических процессов.
Autoincrement уже не используют. Все только распределённые базы проектируют.
:D (y)
Я бы сказал, появилась. Потому что частица была и до, но не здесь. Но вы правы, это не диссертация и следить незачем. Хотя на самом деле материализовался я задолго то того, как попал в бар ;)
Так электрон - это материя или нет? Если - да, то может ли материя материализоваться повторно? Если - нет, то что такое электрон?
Насколько я понимаю, "волновая функция" - это вероятность (плотность вероятности) обнаружения чего-то/кого-то в таком-то месте в такое-то время. Когда я в пятницу вечером собираюсь прошвырнуться по барам, для меня ведь тоже можно составить волновую функцию, разве нет? А когда вы меня обнаружите в каком-то баре, то это и будет означать "схлопывание волновой функции", ведь так? Значит ли это, что я материализовался в конкретном баре в момент обнаружения?
Можно. Но вряд ли это будет "обычное использование". Мне, например, сложно представить, как функция, "которая ни чем не взаимодействует, а лишь определяет", превращается в частицу. Обычно функции в частицы не превращаются. Тем более ни с того, ни с сего, без взаимодействия. Допускаю, что в частицу превращается нечто другое, та же энергия, например. Но называть что угодно можно как угодно. Просто с взаимопониманием возникнет напряг.
Превращение в материю. Например, энергии.
Поздравляю с отпуском! Отпуск - это прекрасно!! Я ничего не выиграл, просто потратил время на просмотр статьи по диагонали (на первых двух экранах стало понятно, что там не будет того, на что я надеялся по заголовку) и чтение какого-то кол-ва комментов (чтобы понять, был ли у кого-то ещё, кроме меня, рассинхрон между заголовком и содержимым). Наткнулся на ваши "100% прагматизма" вот и не выдержал. Прагматизм во мне помещается в каких-то объёмах, но в не настолько больших, чтобы удержать меня от бессмысленного комментирования чужих комментов :)
А что вы выиграли, комментируя эту статью?
Вы считаете, что это невозможно? Или что в таком случае это обязательно будет "код"? Ну, в таком случае я со своей стороны могу сказать, что любой код - это список требований.
На Хабре разный контингент. Что бы вы ни сказали, всегда найдётся кто-нибудь, кто будет чем-то недоволен. Причин масса - "вот только не надо подкалывать", "нечего дурость тут свою демонстрировать", "я слишком ценю своё время, чтобы читать комменты-пустышки" ну и т.д. Слишком большая аудитория слишком разных людей. Я как-то сформулировал и опубликовал тут же свой ответ на вопрос "почему минусуют" - "потому что могут". Забанили на год под предлогом "вас взломали!". Ну, вот так это тут работает. Просто не относитесь серьёзно к минусам и банам :)
Не всегда. Иногда такое называется "список требований".
Вот что-то мне показалось, что в чём-то автор лукавит. "Если вы не понимаете, как работает Нода, то сядьте и разберитесь в ней." (с) Ага, и с Пайтоном так же? И с JS? И с TS? А есть ещё Java, PHP, C#, Go тот же. RDBMS - сядьте и разберитесь с Oracle/MS SQL/PostgreSQL. Изучите отличия MariaDB от MySQL. А потом разберите отличия всего это многообразия от NoSQL DBs, объектно-ориентированных БД, БД документов и иерархических БД. Чем отличается Tailwind от CSS3. Когда лучше применять React, когда Angular, а когда Vue? Для чего нужен Svelte? Нужен ли вообще $mol? Можно изучить ещё различия PHP'шных фреймворков друг от друга - Laravel, Symfony. Java'вский Spring. Занырнуть в архитектуру и особенности функционирования WordPress, Magento, Joomla, Django, Odoo, 1C, Liferay. Понять чем CMS отличаются от CRM, а всё это от ERP и BPMS.
Мне кажется, что тут зарождается (или уже родилась?) новая религия "Сядь и разберись, если не понятно". Я вас уверяю, что все, кто писал, с точки зрения автора, говно-проекты, именно так и сделали - сели и разобрались. А получилось, что получилось. Кто-то разбирается лучше, кто-то хуже. Автор может всем ответственно заявить, что он уже разобрался с Нодой? Или хотя бы хоть с чем-то разобрался до конца?
"Я знаю только то, что ничего не знаю, но другие не знают и этого" (с) Сократ
Я не пробрасываю типы (вернее, классы/объекты/функции), я использую их напрямую там, где в них есть необходимость. Контейнер знает, каким образом получить доступ к каждому es-модулю проекта и его содержимому (экспорту). Он может напрямую создавать требуемые объекты, без посредников. В данном примере это описано в пункте "7. Карта зависимостей" в виде переменной map, где зависимости между идентификатором зависимости и местом расположения его исходников прописано вручную.
В реальных проектах идентификаторы зависимостей выглядят более кучеряво и, как правило, основаны на полном имени класса, который создаёт нужную для внедрения зависимость (например
com.vendor.project.module.BaseClass- в Java или/Vendor/Project/Module/BaseClassв PHP). Так как идентификатор зависимости - это строка, то лишь от фантазии разработчика зависит, какие правила он использует для преобразования строки в:путь к файлу с исходниками для импорта;
определение нужного экспорта внутри es6-модуля;
флаг создания нового экземпляра зависимости (transient) или передачи уже существующего (singleton);
флаг добавления адаптора (wrapper'а) к создаваемой зависимости;
Зависимость вполне может выглядеть, как URL:
@vendor/package/esmodule.mjs#exportName?singleton&scope=requestЗависимость - это не просто тип (уровень исходного кода), это объект, существующий в runtime. Тут не столько в терминах исходного кода нужно мыслить, сколько в терминах работающей программы (те же синглтоны).
Спасибо за вопрос, очень полезный оказался, как минимум для меня.