Здравствуйте, Pavel Dvorkin, Вы писали: PD>А можно поинтересоваться, откуда это ? Я вроде о том, как хранить при этом символы, вообще не говорил.
А как еще ты их будешь хранить, миль пардон? Ты же на уровень железа только что троичное основание запихал.
Пока что обойтись без представления строк в виде цепочек символов мало кому удалось. Ну а символ традиционно изображается некоторым числом, которое эквивалентно индексу в некоторой таблице.
Свои соображения по поводу чисел ты уже привел.
PD>триты и все. Массив (не С#, а C++) из tbool значений. Каждый трит есть одно значение PD>packed tbool t[8] ;// sizeof(t) == 1 tbyte (байт из тритов)
Гм. У тебя "внутри" и так всё уже состоит из тритов. Естественно, "упакованных" (я что-то не помню зазоров между битами в int32).
Не обязательно "трайт" будет длиной 8 трит — восьмерка как-то плохо представима в троичной системе тогда уж 6 или 9 трит...
Но дело не в этом. Дело в том, что как только ты выбрал такое представление для своих чисел, ты сразу убил предположение, что N используется только для null.
Это как раз естественная схема для троичной арифметики; но она, естественно, не даёт совсем-совсем никакого выигрыша по поводу null. Опять получится так, что в точности все значения, представимые любой комбинацией тритов в трайте, соответствуют какому-то целому числу. Упс.
PD>Ты же сам согласился, что есть случаи, когда это неверно.
Где?
PD>С этим соглашусь. Хотя... А не является ли это следствием того, что до Явы мы просто не умели их описывать и шли на всякие трюки. Отсюда наша непривычка к ним. Пример с бесконечностью я приводил. Пример с NULL тоже. Можно и еще найти
Наша непривычка к ним связана строго с маловостребованностью. Я еще раз напомню, что в SQL трёхзначная логика была с самого начала — задолго до явы и шарпа. И никаких "выкручиваний" на уровне языка для этого не потребовалось — просто в спецификации четко прописаны таблицы истинности для всех операций.
S>>Для вещественных переменных всё давно уже обозначили. PD>Да, но как ? Исключили некоторые комбинации из числа тех, что могли бы изображать число, из чисел, обозначив ими бесконечность. Подход верный, но искусственный.
Ну ты же ведь предлагаешь именно его, не так ли? Взял достаточно большое количество комбинаций из числа тех, что могли бы изображать число, и исключил их, заставив изображать непонятно что — то ли нулл, то ли бесконечность, то ли НАН.
PD>Глупо. О личности здесь вообще речи нет. А пойти оно не могло — оно пробовало реально. Но не приняло.
И с чем ты тогда споришь? Ты же только что опровергал предположение о том, что двоичная арифметика и логика являются естественной базой для вычислительной техники.
PD>. Антон, ну неужели ты не понимаешь, что никаким способом нельзя описать специальное значение и специальный адрес, если допустить , что все битовые комбинации могут изображать адрес или число.
Как раз я-то это понимаю. А вот ты — нет. Потому что это утверждение остается справедливым для арифметики по любому основанию! Попробуй записать null в десятичной системе — уж в ней-то дигитов хватит
PD>Странно. В C# пошли на Nullable. В С++ вообще ничего делать не стали, для чисел там нет null, а для адреса махнули рукой и решили, что 0 и есть NULL.
В С++ ничего делать и не надо — там же нет боксинга. Поэтому написать аналог Nullable<T> там пара минут.
PD>В Win32 эта проблема решается на уровне ОС, а в ДОС никак не решалась — тебе не приходилось вешать компьютер из-за записи по NULL и порчи т.о. таблицы векторов прерываний ?
Естественно приходилось. И что?
Как эта проблема должна решиться при помощи расширения основания арифметики?
PD>Ладно. Предложи язык. в котором это возможно. Есть целая переменная, 32 бит (двоичная система). Какую комбинацию битов ты присвоишь, чтобы обозначить null ?
О байт! Предлагаю: язык SQL. Показываю, следи за руками:
declare @a integer
Всё. После объявления все переменные инициализируются значением NULL.
Понятие "null" не связано с 32 битами. Это языковое понятие. Отображение в биты зависит от реализации. Можно реализовать SQL и поверх троичной арифметики, и поверх десятичной — какая проблема-то? Павел, учись разделять разные уровни абстракций.
PD>треть трита тогда уж
Один трит — это 1.58 бита. Из них ты предлагаешь использовать 0.58 на запись нуллов.
PD>>Логика, правда, усложнится
PD>Нет, не удастся тебе. Я уже 100 раз тебе говорил — увы, но ты хороший специалист только в том, что реально существует.
А ты, значит, мнишь себя хорошим специалистом в том, что не существует? Павел, хорошие программисты такими штуками, как ты вот конкретно здесь, переболевают в детском возрасте. Во взрослом возрасте они уже могут прикинуть последствия тех или иных конструктивных решений.
А ты мало того, что не успеваешь прикинуть последствия выбора троичной логики в качестве основания перед тем как написать, но и городишь всяческую чушь вроде того, что это бы повлияло на удобство применения тех или иных конструкций в языках программирования.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Pavel Dvorkin, Вы писали: PD>А ты уверен, что минимальным основанием системы счисления является двойка ? А не 1 ?
Павел, я же советовал тебе пойти и перечитать Кнута. Ты, похоже, плотно забыл начало второго тома. Не надо мне сейчас цитировать википедию.
А по поводу минимальности для цифровой схемотехники — да, уверен. Потому что тебе один хрен потребуется отличать единицу от следующей единицы, и обнаруживать терминатор
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>И не только она. Вот как, по-твоему, понятие байт есть фундаментальное понятие или нет ? Именно тот байт, который == 8 бит, никакой троичной системы. Я подозреваю, что если бы компьютер изобрели китайтцы, то байт был бы == 16 бит, а то и 32.
AFAIR, байт стал восьмибитным далеко не сразу. Боюсь соврать, но только с появлением IBM-360.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Pavel Dvorkin, Вы писали: PD>>А можно поинтересоваться, откуда это ? Я вроде о том, как хранить при этом символы, вообще не говорил. S>А как еще ты их будешь хранить, миль пардон? Ты же на уровень железа только что троичное основание запихал. S>Пока что обойтись без представления строк в виде цепочек символов мало кому удалось. Ну а символ традиционно изображается некоторым числом, которое эквивалентно индексу в некоторой таблице. S>Свои соображения по поводу чисел ты уже привел.
Я привел и изменение, которое ты упорно игнорируешь.
PD>>триты и все. Массив (не С#, а C++) из tbool значений. Каждый трит есть одно значение PD>>packed tbool t[8] ;// sizeof(t) == 1 tbyte (байт из тритов) S>Гм. У тебя "внутри" и так всё уже состоит из тритов. Естественно, "упакованных" (я что-то не помню зазоров между битами в int32).
Либо ты не понимаешь действительно, либо прикидываешься. Посмотри Виртовский паскаль и там есть packed array of char. Это когда 8-бит char занимает не слово (которое может быть >8 бит), а байт в этом слове, и символы упакованы в слово по несколько штук. По аналогии я привел массив из тритов. Впрочем, Turbo Pascal set и есть массив из битов. Ни о каких зазорах там речи нет.
S>Не обязательно "трайт" будет длиной 8 трит — восьмерка как-то плохо представима в троичной системе тогда уж 6 или 9 трит...
мб.
S>Но дело не в этом. Дело в том, что как только ты выбрал такое представление для своих чисел, ты сразу убил предположение, что N используется только для null. S>Это как раз естественная схема для троичной арифметики; но она, естественно, не даёт совсем-совсем никакого выигрыша по поводу null. Опять получится так, что в точности все значения, представимые любой комбинацией тритов в трайте, соответствуют какому-то целому числу. Упс.
Еще раз прочти изменение. Это раз. А во-вторых, даже без него будет,хотя да, неэффективно. Ограничусь двумя тритами, чтобы таблицы не писать
Если тритов 27 , то потеря на одном трите несущественна.
То же для адреса.
PD>>Ты же сам согласился, что есть случаи, когда это неверно. S>Где?
Ты же признал, что для int будет меньше.
PD>>С этим соглашусь. Хотя... А не является ли это следствием того, что до Явы мы просто не умели их описывать и шли на всякие трюки. Отсюда наша непривычка к ним. Пример с бесконечностью я приводил. Пример с NULL тоже. Можно и еще найти S>Наша непривычка к ним связана строго с маловостребованностью. Я еще раз напомню, что в SQL трёхзначная логика была с самого начала — задолго до явы и шарпа. И никаких "выкручиваний" на уровне языка для этого не потребовалось — просто в спецификации четко прописаны таблицы истинности для всех операций.
Ты разные вещи смешиваешь — реализацию на языке и аппаратуру. Я могу в языке хоть с переменной системой счисления арифметику реализовать или любую логику.
S>>>Для вещественных переменных всё давно уже обозначили. PD>>Да, но как ? Исключили некоторые комбинации из числа тех, что могли бы изображать число, из чисел, обозначив ими бесконечность. Подход верный, но искусственный. S>Ну ты же ведь предлагаешь именно его, не так ли? Взял достаточно большое количество комбинаций из числа тех, что могли бы изображать число, и исключил их, заставив изображать непонятно что — то ли нулл, то ли бесконечность, то ли НАН.
Да, но не искусственную комбинацию, а вполне логично сделанную.
PD>>Глупо. О личности здесь вообще речи нет. А пойти оно не могло — оно пробовало реально. Но не приняло. S>И с чем ты тогда споришь? Ты же только что опровергал предположение о том, что двоичная арифметика и логика являются естественной базой для вычислительной техники.
Я не опровергал. Я сказал, что не уверен.
PD>>. Антон, ну неужели ты не понимаешь, что никаким способом нельзя описать специальное значение и специальный адрес, если допустить , что все битовые комбинации могут изображать адрес или число. S>Как раз я-то это понимаю. А вот ты — нет. Потому что это утверждение остается справедливым для арифметики по любому основанию! Попробуй записать null в десятичной системе — уж в ней-то дигитов хватит
Никак ты понять не хочешь, что если есть выбранная комбинация, которая может аппаратно расцениваться как нечисло или неадрес, то это неверно.
PD>>Странно. В C# пошли на Nullable. В С++ вообще ничего делать не стали, для чисел там нет null, а для адреса махнули рукой и решили, что 0 и есть NULL. S>В С++ ничего делать и не надо — там же нет боксинга. Поэтому написать аналог Nullable<T> там пара минут.
Нет уж, обойдемся, как и до сих пор обходились
PD>>В Win32 эта проблема решается на уровне ОС, а в ДОС никак не решалась — тебе не приходилось вешать компьютер из-за записи по NULL и порчи т.о. таблицы векторов прерываний ? S>Естественно приходилось. И что? S>Как эта проблема должна решиться при помощи расширения основания арифметики?
А вот возьми мои значения выше и рассмотри как адрес. И тогда любой 2x адрес генерирует прерывание. Потому что он NULL. Не 0, а NULL. В ДОС запись по нулевому адресу есть корректное действие
// MS-DOS
long * p = NULL;
*p = // корректное значение для вектора 0
и хоть так писать не рекомендуется, но прямой ошибки здесь нет. А вот если бы NULL... см выше.
PD>>Ладно. Предложи язык. в котором это возможно. Есть целая переменная, 32 бит (двоичная система). Какую комбинацию битов ты присвоишь, чтобы обозначить null ? S>О байт! Предлагаю: язык SQL. Показываю, следи за руками: S>
S>declare @a integer
S>
S>Всё. После объявления все переменные инициализируются значением NULL.
Прекрасно. Переведи, пожалуйста, на ассемблер. Меня не устраивают среды, когда за каждой строчкой стоит исполняющая система. Интерпретаторы любого рода, иными словами, или даже JIT compiler
S>Понятие "null" не связано с 32 битами. Это языковое понятие.
Сейчас да. Но могло бы быть аппаратным.
Ответь на маленький вопрос. Зачем в C есть NULL ? Это же не C#, NULL — это просто 0, самый обычный, 32 нулевых бита. Зачем же он есть, зачем лишнее понятие ? Ответ прост — авторы заложили возможность иной реализации NULL на некоей иной архитектуре. Эта архитектура так и не появилась, NULL везде 0. Но авторы С понимали, что жестко привязывать не надо — кто его знает, что еще может появиться.
PD>>треть трита тогда уж S>Один трит — это 1.58 бита. Из них ты предлагаешь использовать 0.58 на запись нуллов.
PD>>>Логика, правда, усложнится
PD>>Нет, не удастся тебе. Я уже 100 раз тебе говорил — увы, но ты хороший специалист только в том, что реально существует. S>А ты, значит, мнишь себя хорошим специалистом в том, что не существует?
Нет, просто я позволяю себе иногда оторваться от действительности и посмотреть, что еще могло бы быть. Альтернативы поизучать. Ты на это неспособен.
>Павел, хорошие программисты такими штуками, как ты вот конкретно здесь, переболевают в детском возрасте. Во взрослом возрасте они уже могут прикинуть последствия тех или иных конструктивных решений.
S>А ты мало того, что не успеваешь прикинуть последствия выбора троичной логики в качестве основания перед тем как написать, но и городишь всяческую чушь вроде того, что это бы повлияло на удобство применения тех или иных конструкций в языках программирования.
Ничего ты так и не понял. Не может хороший паровозник понять, что возможна тяга не только на дровах или угле.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Pavel Dvorkin, Вы писали: PD>>А ты уверен, что минимальным основанием системы счисления является двойка ? А не 1 ? S>Павел, я же советовал тебе пойти и перечитать Кнута. Ты, похоже, плотно забыл начало второго тома. Не надо мне сейчас цитировать википедию.
Лучше вернись в первый класс и повтори палочки .
S>А по поводу минимальности для цифровой схемотехники — да, уверен.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Еще раз прочти изменение. Это раз. А во-вторых, даже без него будет,хотя да, неэффективно. Ограничусь двумя тритами, чтобы таблицы не писать
PD>00 — 0 PD>01 — 1 PD>02 — null PD>10 — 2 PD>11 — 3 PD>12 — null PD>2x — null
Воот. Итак, у нас на 9 комбинаций получилось 5 различных. Верной дорогой идете, товарищи
Поскольку возможных значений N-тритного числа 3^N, а используется только 2^N, то потери составляют (3^N-2^N-1)/3^N. (Единичка — это "нужный" нулл, ради которого всё и затевалось.
Теперь про "упрощение": Как будут представляться знаковые числа? Табличку истинности для сложения двух тритов нарисуешь? Как будет выглядеть схема полусумматора для такой таблицы истинности?
PD>00 — 0 PD>01 — 1 PD>02 — 2 PD>10 — 3 PD>11 — 4 PD>12 — 5 PD>2x — null
Отлично. Теперь мы выбрасываем значительно меньше. Всего лишь 1/3 значений — это существенное улучшение по сравнению с 99%
Но мы продолжаем пытку: в чем существенная разница этого подхода с двоичным:
000 - 0
001 - 1
010 - 2
011 - 3
1xx - Null
? PD>Если тритов 27 , то потеря на одном трите несущественна.
Ну да. Если битов 64, то потеря на одном несущественна.
PD>Ты же признал, что для int будет меньше.
Это, Павел, если отводить целых 32 бит для признака null. А ведь никто не запрещает отвести ровно один — так же, как и в твоём подходе №2. Кстати, в нём ты столкнешься ровно с теми же проблемами (если понятие null не вшито напрямую в АЛУ) — либо у тебя будет потеря части диапазона целых чисел, либо придется отдать сразу целое слово под этот "один трит" — потому, что проблемы с выравниванием будут точно такими же, как и на двоичной платформе.
PD>Ты разные вещи смешиваешь — реализацию на языке и аппаратуру. Я могу в языке хоть с переменной системой счисления арифметику реализовать или любую логику.
Правильно, можешь. Тогда зачем кривляешься? Зачем изобретать аппаратные решения лингвистических проблем? Это сейчас немодно.
PD>Да, но не искусственную комбинацию, а вполне логично сделанную.
Павел, она такая же искусственная.
PD>Я не опровергал. Я сказал, что не уверен.
PD>Никак ты понять не хочешь, что если есть выбранная комбинация, которая может аппаратно расцениваться как нечисло или неадрес, то это неверно.
Что "это"? "Аппаратный выбор комбинации" совершенно произволен — лишь бы были осмысленными операции с этой комбинацией.
PD>Нет уж, обойдемся, как и до сих пор обходились
Отлично. То есть в языке тебе это не нужно, зато добавить в железку — самое оно.
PD>А вот возьми мои значения выше и рассмотри как адрес. И тогда любой 2x адрес генерирует прерывание. Потому что он NULL.
Ой как здорово. В win32 почти то же самое. Попытка писать в адреса ядра генерирует прерывание. Потому что там пользовательских данных быть не может PD>Не 0, а NULL. В ДОС запись по нулевому адресу есть корректное действие
Зато в винде — нет. PD>и хоть так писать не рекомендуется, но прямой ошибки здесь нет. А вот если бы NULL... см выше.
Меня потрясает твое умение мечтать о давно реализованном.
PD>Прекрасно. Переведи, пожалуйста, на ассемблер. Меня не устраивают среды, когда за каждой строчкой стоит исполняющая система. Интерпретаторы любого рода, иными словами, или даже JIT compiler
Это сильно зависит от того, какой там внутри ассемблер. S>>Понятие "null" не связано с 32 битами. Это языковое понятие. PD>Сейчас да. Но могло бы быть аппаратным.
И сейчас оно вполне может быть аппаратным. Ты почему-то связал два совершенно ортогональных понятия — разрядность системы счисления и наличие аппаратного null. Это демонстрирует полнейшую кашу, которая творится в твоей голове.
Аппаратный нулл реализуется исключительно специальной веткой логики, которая его обрабатывает. Вот и всё — см. таблицы истинности для операций.
PD>Ответь на маленький вопрос. Зачем в C есть NULL?
Да, по легенде была задумана архитектура, на которой NULL задавался неким специальным значением, при обращении по которому происходила специальная ошибка.
Однако в тот момент, когда такая аппаратура появилась, оказалось, что проще потребовать чтобы это специальное значение было всегда равно 0 — потому что на ней начало адресного пространства не было привязано ни к каким магическим штукам навроде векторов прерываний.
PD>Нет, просто я позволяю себе иногда оторваться от действительности и посмотреть, что еще могло бы быть. Альтернативы поизучать. Ты на это неспособен.
Нет, Павел, я просто быстрее рассматриваю эти альтернативы. И быстро сравниваю их с другими вариантами. Поэтому обо всём, что ты тут мучительно соображаешь второй день, я подумал еще в тот момент, как прочитал вот эту бессмыслицу:
Кстати, если бы сейчас была на машине троичная система, то все ваши проблемы и решения с nullable решались бы без всякого труда и без каких=то хитростей.
И все эти варианты с троичной сбалансированной системой, с выделением целого трита, а также одной трети трита, под признак нулл, были очевидны с самого начала. Ну, кроме идеи использовать триты в двоичном режиме — это мне в голову как-то не пришло. Инстинктивно выбираю более экономные решения
PD>Ничего ты так и не понял. Не может хороший паровозник понять, что возможна тяга не только на дровах или угле.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Лучше вернись в первый класс и повтори палочки .
Ок, слив засчитан. PD>А, теперь уже только для схемотехники
А что, компьютеры ты предлагаешь делать без неё?
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Ответь на маленький вопрос. Зачем в C есть NULL ? Это же не C#, NULL — это просто 0, самый обычный, 32 нулевых бита. Зачем же он есть, зачем лишнее понятие ? Ответ прост — авторы заложили возможность иной реализации NULL на некоей иной архитектуре. Эта архитектура так и не появилась, NULL везде 0. Но авторы С понимали, что жестко привязывать не надо — кто его знает, что еще может появиться.
Извиняюсь, что встреваю, но про null есть интересная цитатка Тони Хоара:
...I was designing the first comprehensive type system for references in an object oriented language (ALGOL W). My goal was to ensure that all use of references should be absolutely safe, with checking performed automatically by the compiler. But I couldn't resist the temptation to put in a null reference, simply because it was so easy to implement. This has led to innumerable errors, vulnerabilities, and system crashes, which have probably caused a billion dollars of pain and damage in the last forty years.
Здравствуйте, Qbit86, Вы писали:
Q>Здравствуйте, Шахтер, Вы писали:
Ш>>Законы механики могут быть сформулированы в разных формах. Как уравнения движения, как уравнения Лагранжа, в форме Гамильтона...
Q>Все три формулировки механики — Ньютонова, Лагранжева и Гамильтонова — по своему важны, и каждая из них может быть предпочтительнее других в разных задачах.
Безусловно.
Q>Вряд ли, пойди человечество по альтернативному пути, оно не дошло бы до осознания необходимости этих трёх формулировок.
Вполне может быть. Просто не открыть один из вариантов. Ведь эти варианты не возникли одновременно. Кроме того, а вдруг есть ещё не открытый вариант?
Во всяком случае, пример классической механики показывает, что не существует "единственно правильной" механики.
Ш>>есть ещё вариационнный принцип.
Q>Зачем его выделять отдельно? Как раз на его основе строится Лагранжева механика.
А можно сразу уравнения Лагранжа постулировать. На самом деле, выбор между уравнениями Лагранжа или вариационнным принципом -- это как выбор между двумя эквивалентными системами аксиом.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>>Закон всемирного тяготения несомненнно, был бы открыт и имел тот же вид.
Ш>>Тоже неверно. Законы физики имеют вид, зависящий от выбранного представления физической реальности.
PD>Может, я чего-то не понимаю, но ИМХО формула закона всемирного тяготения ни от чего не зависит.
Не понимаешь. Зависит от того, как ты описываешь механику.
Если по Ньютону, то будет одна формула. Если по Гамильтону -- то совсем другая.
В механике Ньютона сила есть первичное понятие и закон всемирного тяготения описывает силу гравитационного притяжения между двумя массами.
В механике Гамильтона первично понятие гамильтониана, полной энергии системы, и закон всемироного тяготения здесь описывает потенциальную энергию гравитации.
PD>>>Законы механики — тоже.
Ш>>Законы механики могут быть сформулированы в разных формах. Как уравнения движения, как уравнения Лагранжа, в форме Гамильтона, есть ещё вариационнный принцип.
PD>На здоровье. От этого физические законы не зависят, а излагать их можешь даже с помощью иероглифов.
Зависят.
PD>>>Если бы Менделеев и Мейер померли в младенчестве — трудно предположить, что мы бы до сих пор не знали бы периодической таблицы. Имя она носила бы другое, а вид — тот же.
Ш>>Тоже не факт. В конце концов, траспонируй -- уже альтернативный вариант получится.
PD>Ну не смеши хоть. Что изменится от транспонирования ?
Внешний вид таблицы.
PD>Периодический закон — это отнюдь не внешний вид той таблицы, которая в каждом школьном кабинете висит.
Ты писал, цитирую "что мы бы до сих пор не знали бы периодической таблицы. Имя она носила бы другое, а вид — тот же". Не надо вилять, это не красиво.
PD>Ее внешний вид вообще малосущественен. Периодический закон — это правила заполнения орбиталей в соответствии с принципом Паули. Его не транспонируешь
Во-первых, существеннен. Поскольку таблица -- это рабочий инструмент и от того, насколько удобно для работы она сделана, зависит её полезность как инструмента.
Во-вторых, вынужден тебе напомнить, что во времена Менделеева никаких орбиталей и принципа Паули ещё не было, и периодический закон формулировался совсем иначе.
Ш>>В науке происходит эволюция знаний. При этом теории не только рождаются, но и умирают.
PD>Приведи пример умерших теорий. Только научных, а не ошибочных. Флогистон, теплород и жизненная сила не пойдут.
Анализ Ньютона и Лейбница, например. Теория меры Жордана и.т.д. В математике полно мертвых теорий. Они мертвы не оттого, что неверны, а оттого, что на смену им пришли лучшие теории.
PD>Теории не умирают, если они верные. Просто со временем обнаруживается их ограниченность и неприменимость в определенных условиях. Ньютонова механика не померла от того, что не смогла работать при субсветовых скоростях. И электродинамика Максвелла тоже, от того, что не смогла объяснить квантовые эффекты.
>>Та форма, которую научные теории имеют на данный момент есть результат исторического развития. При другом историческом развитии всё выглядело бы по-другому.
PD>Нет. Теория относительности или классическая механика есть отражение физической реальности ...
НЕТ одной классической механики. Их есть несколько штук. От того, что они отражают одну и ту же физическую реальность, не следует, что теории тождественны (или "изоморфны").
PD>>>Возьмем технологии. Если бы Дизель не родился, дизели все равно бы появились.
Ш>>Ниоткуда не следует.
PD>Так без них бы и жили, не придумали бы ?
Не а.
PD>>>Ракеты в СССР построили бы и без Королева, и они были бы такими же.
Ш>>Неверно. Ракеты в СССР, в США и во Франции разные. НЕкоролев тоже скорее всего придумал бы свою конструкцию.
PD>Конструкцию — да. А принципы остались бы.
Не а.
PD>Реактивная тяга.
А может, из пушки на Луну?
PD>Жидкие или твердые топлива.
Так жидкое, или твердое? В зависимости от выбора, конструкция ракета и всей инфраструктуры существенно меняется.
PD>Аэродинамические характеристики. И т.д.
А это что за принцип?
PD>>>Ядерное оружие было бы создано без Курчатова и Сахарова, и оно выглядело бы так же и работало так же.
Ш>>Тоже неверно. Уже в момент рождения было предложено два варианта кострукции ядерного боеприпаса.
PD>Опять ты сбиваешься на мелочи.
Это не мелочи. Это две принципиально разные конструкции.
PD>>>Иными словами, в науке и в технологии от личности немногое зависит.
Ш>>Бред. И наука и техника несут на себе яркий отпечаток тех личностей, которые их творили.
PD>Тебе не кажется , что использование таких аргументов не есть корректный спосбо дискутирования ? Отпечаток несут, но потом все неизбежно сглаживается при участии других ярких и не очень личностей, а в итоге получается то, что называется вектором развития.
Не вектор, а итог. В каждый конкретный момент времени он разный.
PD>>>Да, возможно, без Эйнштейна ОТО была бы создана лет на 20 позже. Но все равно была бы создана.
Ш>>То же самое. Только вариативность больше. Просто потому, что больший простор для творчества.
PD>
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Pavel Dvorkin, Вы писали:
< перед прочтением сожжено>
Я решил закончить со своей стороны эту дискуссию. Дело в том, что твоей целью давно уже не является поиск истины, а только стремление доказать, что я неправ, чего-то не понимаю и не знаю и т.д. Мне, в общем, это давно ясно, но окончательным камешком стало вот это. С одной стороны, ты утверждаешь, что null — это чисто элемент языка, и отношения к аппаратуре не имеет. В то же время, когда WFrag вот здесь
предлагает для этой цели использовать один из битов (не выходя из двоичной системы), то ты ему ставишь плюс. А он предлагает чисто аппаратное решение. Иными словами, ты готов использовать даже взаимоисключающие аргументы, чтобы доказать свою правоту или мою неправоту.
Извини, Антон, но мне все это надоело. Я трачу непропорционально много времени на ответы в этой дискуссии с тобой, которое я могу потратить на дискуссию с теми, кто со мной, может, и не согласен, но хочет обсуждать именно идеи, и возражать, если надо, а не занимается софистикой и не задается единственной целью доказать, что я неправ или не знаю и т.д.
Так что, как говорил в старину (с небольшой модификацией)
Здравствуйте, alpha21264, Вы писали:
A>Утверждаешь, что если бы Королев не родился, то мы все равно имели бы тот же самый "Восток-Союз"?!!! A>А ты "Шаттл" видел? Ну ладно, не Шаттл, хотя бы "Сатурн-5" (подсказка — на топливо посмотри)? A>Ага, ага Сахаровская многослойкка была бы такая же. Что-ж ее у американцев до сих пор нет? A>Если сию аналогию притягивать к языкам программирования, то все языки состоят из одного и того-же — циклов и условий.
Что же, попробуем обсудить. В общем-то, серьезное возражение.
Вот есть колесо. Изобретатель неизвестен, но нет сомнения. что без него колесо все равно изобрели бы. Разные бывают колеса — со спицами и сплошные, с шинами и без и т.д. А все равно колесо. Не гусеница и не шагающий агрегат.
А теперь допустим. что K&R занялись бы в детстве орнитологией и никакой язык не создали. Одно из двух — либо место С занял бы Паскаль (Модула ?), либо появился бы новый язык. Но этот новый язык не был бы по синтаксису похож на С — второй раз такой чудовищный синтаксис не придумаешь. Да и никаких, по существу, новых идей, в С не было, разве что адресная арифметика, так она — явно родимое пятно архитектуры PDP-11. Она, кстати, без труда была имплементирована с Turbo Pascal, так что если она была нужна — ее бы и без них придумали и куда-то вписали.
Не было бы С — не было бы C++, Java и C# в том виде, как они сейчас есть. Да еще и PHP не было бы. Может, было бы царствие Object Pascal, может, другого языка. Да, с теми же циклами и условиями, да, императивного.
А теперь вопрос.
Ты готов признать, что замена C++, Java и C# на нечто иное есть столь же малосущественное различие, как различие между колесом со спицами и колесом без него. Или как отличие термоядерной бомбы американского и советского варианта ? Или Шаттла от Энергии ?
Здравствуйте, Шахтер, Вы писали:
Ш>В механике Ньютона сила есть первичное понятие и закон всемирного тяготения описывает силу гравитационного притяжения между двумя массами. Ш>В механике Гамильтона первично понятие гамильтониана, полной энергии системы, и закон всемироного тяготения здесь описывает потенциальную энергию гравитации.
Я не физик, этого не знаю. Но вопрос — в системе Гамильтона, при том. что мне неважно, что первично и что вторично, сила притяжения пропорциональна массам и обратно пропорциональна квадрату расстояния или же нет ? Еще раз — мне не важно как это выводилось, меня только результат интересует.
PD>>>>Если бы Менделеев и Мейер померли в младенчестве — трудно предположить, что мы бы до сих пор не знали бы периодической таблицы. Имя она носила бы другое, а вид — тот же.
Ш>>>Тоже не факт. В конце концов, траспонируй -- уже альтернативный вариант получится.
PD>>Ну не смеши хоть. Что изменится от транспонирования ?
Ш>Внешний вид таблицы.
Физику ты знаешь лучше меня, а в химии позволь уж мне. еще раз — внешний вид таблицы вообще не имеет никакого значения. Это только икона для тех, кто не в состоянии представить себе бога без нее. См. ниже.
PD>>Периодический закон — это отнюдь не внешний вид той таблицы, которая в каждом школьном кабинете висит.
Ш>Ты писал, цитирую "что мы бы до сих пор не знали бы периодической таблицы. Имя она носила бы другое, а вид — тот же". Не надо вилять, это не красиво.
PD>>Ее внешний вид вообще малосущественен. Периодический закон — это правила заполнения орбиталей в соответствии с принципом Паули. Его не транспонируешь
Ш>Во-первых, существеннен. Поскольку таблица -- это рабочий инструмент и от того, насколько удобно для работы она сделана, зависит её полезность как инструмента.
Это не рабочий инструмент. Это просто подпорка. Мне как химику совсем не обязательно смотреть на таблицу, разве что вспомнить, как элементы называются, если забыл (не забыл . Это такой же рабочий инструмент, как скажем, картинка с адресным пространством и заштриховаными там регионами, которую я полчаса назад на лекции нарисовал на доске, является рабочим инструментом при описании виртуальной памяти. С картинкой понятнее, без нее тоже понятно.
Ш>Во-вторых, вынужден тебе напомнить, что во времена Менделеева никаких орбиталей и принципа Паули ещё не было, и периодический закон формулировался совсем иначе.
Да, конечно, но из этого вовсе не следует, что сейчас для меня периодический закон определяется видом таблицы
Ш>Анализ Ньютона и Лейбница, например. Теория меры Жордана и.т.д. В математике полно мертвых теорий. Они мертвы не оттого, что неверны, а оттого, что на смену им пришли лучшие теории.
Хм. Может, в математике это и так, поскольку математика — это все же игра ума, несколько оторванная от реальности. К тому же я не математик, судить мне сложно. Можешь примеры в области естественных наук привести ? Здесь я себя намного увереннее чувствую, и я такого не помню. Впрочем, я об этом уже писал.
PD>>Теории не умирают, если они верные. Просто со временем обнаруживается их ограниченность и неприменимость в определенных условиях. Ньютонова механика не померла от того, что не смогла работать при субсветовых скоростях. И электродинамика Максвелла тоже, от того, что не смогла объяснить квантовые эффекты.
Ш>НЕТ одной классической механики. Их есть несколько штук. От того, что они отражают одну и ту же физическую реальность, не следует, что теории тождественны (или "изоморфны").
Не берусь судить.
PD>>>>Возьмем технологии. Если бы Дизель не родился, дизели все равно бы появились.
Ш>>>Ниоткуда не следует.
PD>>Так без них бы и жили, не придумали бы ?
Ш>Не а.
Ш>>>Неверно. Ракеты в СССР, в США и во Франции разные. НЕкоролев тоже скорее всего придумал бы свою конструкцию.
PD>>Конструкцию — да. А принципы остались бы.
Ш>Не а.
PD>>Реактивная тяга.
Ш>А может, из пушки на Луну?
Не ерничай.
PD>>Жидкие или твердые топлива.
Ш>Так жидкое, или твердое? В зависимости от выбора, конструкция ракета и всей инфраструктуры существенно меняется.
И то и другое есть.
PD>>Аэродинамические характеристики. И т.д.
Ш>А это что за принцип?
Я имел в виду аэродинамические характеристики ракеты на период выхода из атмосферы.
PD>>Опять ты сбиваешься на мелочи.
Ш>Это не мелочи. Это две принципиально разные конструкции.
Хм. Реакция одна и та же. Принцип поджига атомным взрывом тот же. Технологические отличия есть. Колесо со спицами и колесо без спиц.
PD>>Тебе не кажется , что использование таких аргументов не есть корректный спосбо дискутирования ? Отпечаток несут, но потом все неизбежно сглаживается при участии других ярких и не очень личностей, а в итоге получается то, что называется вектором развития.
Ш>Не вектор, а итог. В каждый конкретный момент времени он разный.
Да, он разный в каждый момент времени, но по прошествию времени все же определяется вектор (или итог, если хочешь) предыдущего развития, и он не разный.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>С одной стороны, ты утверждаешь, что null — это чисто элемент языка, и отношения к аппаратуре не имеет. В то же время, когда WFrag вот здесь
PD>http://rsdn.ru/forum/message/3342789.1.aspx
PD>предлагает для этой цели использовать один из битов (не выходя из двоичной системы), то ты ему ставишь плюс. А он предлагает чисто аппаратное решение.
Вообще-то, когда я это писал, я думал именно о программном решении. Я честно говоря не вижу смысла на аппаратном уровне явно выделять такую конструкцию, и тем более ограничиваться лишь nullable.
Для JVM есть идея использовать эту технику для хранения врапперов для примитивных типов (часто они как раз из-за их способности быть null используются) прямо на стеке (без лишней ссылки и объекта), в тех самых 32/64 битах. Причём в этом случае отделяются не только null от чисел, а на самом деле ссылки от чисел. Т.е числа, которые «не влазят» из-за отрезания бита можно хранить в куче.
Pavel Dvorkin wrote:
> Здравствуйте, vnp, Вы писали: > > vnp>Здравствуйте, Pavel Dvorkin, Вы писали: > > vnp>Почему же не 3? > > Почему бы и не 2 ? То-то Синклер был бы рад! > > > > А можно и 1
Здравствуйте, Pavel Dvorkin, Вы писали: PD>предлагает для этой цели использовать один из битов (не выходя из двоичной системы), то ты ему ставишь плюс. А он предлагает чисто аппаратное решение. Иными словами, ты готов использовать даже взаимоисключающие аргументы, чтобы доказать свою правоту или мою неправоту.
Это не взаимоисключающие аргументы.
Просто ты всё время передергиваешь. Сначала ты дал расплывчатое утверждение о том, что троичная система сделает проще поддержку null для value-типов. (Если быть точным, то не проще, а "безо всякого труда и хитростей". Которые потом уточнились до "выкручиваний", якобы связанных с моделированием троичной логики на двоичных элементах.
Я стал уточнять, что ты понимаешь под выкручиваниями.
Сначала ты пытался рассуждать на уровне языка программирования — "создавать не экземпляры классов, а value".
На что я безуспешно пытался тебе объяснить, что языку программирования всё равно, какая там внутри механика. Пример с SQL тебя ничуть не убедил, хотя там нет никаких "отдельных" структур для nullable int.
Далее ты перешел на уровень аппаратного представления целых чисел и начал предлагать всякие хитровывернутые решения. А я безуспешно пытался тебе объяснить еще два простых, но, по-видимому, недоступных тебе факта:
Во-первых, эти решения таки по-прежнему требуют труда и хитростей. Либо это усложнение схемы сумматора (в случае использования трит в двоичном режиме), либо организация дополнительного кода по проверке на null перед выполнением каждой операции (в случае резервирования трита).
Во-вторых, точно такие же решения можно сделать и в рамках двоичной логики.
В итоге, никакой экономии троичный режим не даёт. Ни на уровне языка, ни на уровне аппаратуры.
Я вообще не понимаю, почему такие элементарные вещи нужно объяснять ажно преподавателю программирования. Почему тупой поклонник управляемых сред вроде меня вынужден рассказывать всё это такому поклоннику низкоуровневых оптимизаций, как ты? Это же твой хлеб — битовыжимание.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
PD>Вот есть колесо. Изобретатель неизвестен, но нет сомнения. что без него колесо все равно изобрели бы. Разные бывают колеса — со спицами и сплошные, с шинами и без и т.д. А все равно колесо. Не гусеница и не шагающий агрегат.
Индейцы тысячи лет жили без колеса, и ничего. Может ещё десятки лет прожили бы. Придумали бы шагающий агрегат
тогда уж 6 или 9 трит...
. Антон, ну неужели ты не понимаешь, что никаким способом нельзя описать специальное значение и специальный адрес, если допустить , что все битовые комбинации могут изображать адрес или число. 
