Все содержательные математических вопросы как раз и проверяются экспериментально. Ставится эксперимент по поиску доказательства либо утверждения, либо его отрицания. Если в результате эксперимента удалось найти доказательство утверждения, значит оно верно. Если удалось найти доказательство отрицания утверждения, значит оно неверно.
Я не «отрицаю вероятность для ребёнка моряка». Я говорю, что задача недоформулирована, потому что не задан ансамбль. Если задать корректный вопрос — такой, чтобы ответ можно было бы проверить экспериментально, то ответ становится однозначным. А такое уточнение равносильно заданию ансамбля.
В любой хорошей игре так. Чит-коды, плагины, тем или иным путём перебалансирующие игру, добровольный отказ от некоторых читерских способов прокачки/прохождения, и всё что можно придумать — незаменимый арсенал ролеплейщика.
Как это не меняет? Если вы не понимаете, что такое вероятность, то непонятно на чём основывается ваше утверждение, что вероятность одиночного события имеет смысл.
Можете дать ссылку на Вики или рассказать своими словами, откуда взялись ещё 9 таких же дней.
Могу, но не хочу. Знание, доставшееся слишком легко, не ценится.
Естественно. Вот вы пишете "вероятность осадков в Москве 6 апреля 2019 года — 20%". А что эта цифра означает, как она расшифровывается, вы понимаете? Исходя из какого определения она рассчитывается?
По условию задачи C могло произойти либо когда A', либо когда одновременно A и B.
Нет, по условию C происходит всегда, P(C) = 1.
Впрочем, на самом деле двусмысленных трактовок я тоже не вижу, и вообще не вижу поставленной задачи. О физических вероятностях имеет смысл говорить, только если задан ансамбль. В "задаче" один-единственный моряк один-единственный раз производит определённые действия. В таких условиях ни о каких вероятностях говорить не имеет смысла. Если же взять ансамбль моряков/ансамбль детей, то ответ очевиден. В любом случае проблемы не наблюдается.
У меня обратная проблема — имеется специально купленный дисковод 5.25 с пачкой дискет и желание подключить его к современному компьютеру. Готовых решений не нашёл, так что лежит, ждёт пока будет место, время и желание разобраться.
Неоправданное сужение* значения общеизвестного и общеиспользуемого термина. И то, что не удалось выразить результат такого сужения в терминах C++ (и, видимо, и C#/Java), ясно об этом свидетельствует.
* Это в лучшем случае, потому что есть подозрение, что описываемый приём вообще делегированию ортогонален.
Клетку построил, коня подвёл на g7, но букву T построить никак не получается.
(Третий разряд — это ведь, если не ошибаюсь, где-то 1600 — 1900 рейтинга? У меня «четвёртый разряд», хочу доказать, что и нам — не Магнусам, не Карлсенам — а с точки зрения четверазрядника любой третьеразрядник играет столь же хорошо, как чемпион мира — тоже доступно ставить мат слном и конём, но вот что-то не получается.)
Наша цивилизация до сих пор жива только благодаря неотвратимости атомного возмездия.
Вообще, существуют ли какие-то серьёзные обоснования или опровержения этого тезиса? Как я понимаю, наука до рассмотрения таки вопросов пока не доросла. Или всё же есть какая-то научная отрасль, претендующая на способность хотя бы ставить такие вопросы, если уж не давать на них ответы?
На всякий случай я подчеркну ещё раз (а то может показаться, что вы пытаетесь меня в чём-то убедить). Я не исхожу из рациональных соображений. Я иррационально считаю, что делать по-Unix-овски — это хорошо, а отступление от Unix несёт в себе зло. Поэтому попытки меня переубедить, используя рациональные аргументы, заведомо бесполезны.
40 файлов в bin — это 40 приложений*, и каждое из них "состоит из одного файла". 150 файлов в lib — это 150 библиотек. Чтобы узнать с каким пакетом поставилось какой-то приложение или библиотека надо подать соответствующую команду менеджеру пакетов.
*Бывают исполняемые файлы, не являющиеся приложениями, но они ставятся не в bin, а в libexec или вроде того.
То есть в первом случае помойка сильно меньше, и вы выбрали очень удачную запись, при которой это бросается в глаза: в первом случае доллар только один, а во-втором — уже два (а на самом деле их там может быть и больше). Количество нефиксированных элементов пути = величина помойки.
Кроме того, в первом случае вам не надо заботиться о переменной PATH и её значение выглядит вменяемо. Во втором же случае PATH превращается в непотребство и вам надо менять её при каждой установке/удалении программы.
Unix — это добро, не Unix — это зло. В Unix программы ставятся определённым образом (бинарный файл — в /usr/bin или /usr/local/bin, конфиги — в /etc или /usr/local/etc и т. д.). Значит, если где-то происходит не так и программы ставятся каждая в свой каталог — это увеличивает общее количество зла, и нет разницы где рождается зло — на моём компьютере или на компьютере соседа: это всё равно зло.
Все содержательные математических вопросы как раз и проверяются экспериментально. Ставится эксперимент по поиску доказательства либо утверждения, либо его отрицания. Если в результате эксперимента удалось найти доказательство утверждения, значит оно верно. Если удалось найти доказательство отрицания утверждения, значит оно неверно.
Как это не меняет? Если вы не понимаете, что такое вероятность, то непонятно на чём основывается ваше утверждение, что вероятность одиночного события имеет смысл.
Могу, но не хочу. Знание, доставшееся слишком легко, не ценится.
Естественно. Вот вы пишете "вероятность осадков в Москве 6 апреля 2019 года — 20%". А что эта цифра означает, как она расшифровывается, вы понимаете? Исходя из какого определения она рассчитывается?
Нет, не один. Это очевидно, если расписать, что эта самая вероятность дождя значит, каков её смысл.
Нет, по условию C происходит всегда,
P(C) = 1.Впрочем, на самом деле двусмысленных трактовок я тоже не вижу, и вообще не вижу поставленной задачи. О физических вероятностях имеет смысл говорить, только если задан ансамбль. В "задаче" один-единственный моряк один-единственный раз производит определённые действия. В таких условиях ни о каких вероятностях говорить не имеет смысла. Если же взять ансамбль моряков/ансамбль детей, то ответ очевиден. В любом случае проблемы не наблюдается.
Просто он продуманнее. Интеловский более хаотичен — где-то нужно явно указывать размер операндов, где-то не нужно и т. д.
Но я сомневаюсь, что найдётся хотя бы один человек, предпочитающий одно другому по объективным (рациональным) причинам. Привычка/идеология и не более.
Были б мы на ЛОРе, я б знал как это прокомментировать. Здесь придётся ограничиться многозначительным молчанием.
* Это в лучшем случае, потому что есть подозрение, что описываемый приём вообще делегированию ортогонален.
(Третий разряд — это ведь, если не ошибаюсь, где-то 1600 — 1900 рейтинга? У меня «четвёртый разряд», хочу доказать, что и нам — не Магнусам, не Карлсенам — а с точки зрения четверазрядника любой третьеразрядник играет столь же хорошо, как чемпион мира — тоже доступно ставить мат слном и конём, но вот что-то не получается.)
Вообще, существуют ли какие-то серьёзные обоснования или опровержения этого тезиса? Как я понимаю, наука до рассмотрения таки вопросов пока не доросла. Или всё же есть какая-то научная отрасль, претендующая на способность хотя бы ставить такие вопросы, если уж не давать на них ответы?
На всякий случай я подчеркну ещё раз (а то может показаться, что вы пытаетесь меня в чём-то убедить). Я не исхожу из рациональных соображений. Я иррационально считаю, что делать по-Unix-овски — это хорошо, а отступление от Unix несёт в себе зло. Поэтому попытки меня переубедить, используя рациональные аргументы, заведомо бесполезны.
Никак. (А следовательно, это ненужная и вредная операция.)
40 файлов в bin — это 40 приложений*, и каждое из них "состоит из одного файла". 150 файлов в lib — это 150 библиотек. Чтобы узнать с каким пакетом поставилось какой-то приложение или библиотека надо подать соответствующую команду менеджеру пакетов.
*Бывают исполняемые файлы, не являющиеся приложениями, но они ставятся не в bin, а в libexec или вроде того.
Кроме того, в первом случае вам не надо заботиться о переменной PATH и её значение выглядит вменяемо. Во втором же случае PATH превращается в непотребство и вам надо менять её при каждой установке/удалении программы.