Продолжение. Предыдущая (вторая) часть https://www.9111.ru/questions/7777777772180978/
-------------------------------
И так. Хотел наскоком сразу же перейти к операциям над многознаковыми числами, но... в очередной раз обломался. Поскольку выяснилось, что прежде всего надо очень четко и строго дать определение тому, что это такое многознаковое число. И если такой тип существует, то однозначно определить его. Начал разбираться с этим, и,.. тут вылезла одна очень потенциально-нехорошая ситуация, связанная со знаковыми преобразованиями и последующей нестрогостью получаемых результатов. Замечание Здесь и далее под преобразованием знаков понимается (+)* (+)= (+), (-)* (-)= (+), (+)* (-)= (-), (-)* (+)= (-).
Но сначала необходимо небольшое "лирическое отступление", непосредственно связанное с нестрогостью определений и операций и к чему это в итоге приводит.
Ранее я уже вскользь затронул вопрос нестрогости в выражениях и определениях при разработке ПО, когда принимается некое "по умолчанию". И вот пример того что, в итоге получилось. Специалисты-программисты одной достаточно серьезной компании, для стыковки с ихней системой, решили использовать защиту посылки 16-разрядной контрольной суммой. И дабы избежать недопонимания, приложили исходный текст на базовом "С", эту операцию выполняющую.
Спрашивается, код есть, вставляй в свое ПО и пользуй. Только "фигвам" получился. И если бы всегда все верно считалось, ан нет, где-то в 5-7 процентах случаев откровенная лажа вылезала. Не то значение получалось. И воспринималось системой все это как сбой обмена... Хотя никакого сбоя и в помине не было. Вылечилось все очень просто - перед каждой переменной надо было ее тип и знаковость явным образом указать. Но лень было лишние "буковки" на клаве кому-то набирать. Списали с аналитического выражения - и вперед.
Вроде как все одинаково, ан нет. Поскольку "умолчания" у каждого компилятора свои как правило получились. И те же "стандартизаторы" не озаботились вопросом о том, как тот же int по умолчанию определять, знаковый или просто положительный... И добавлю - скрытые проблемы этой знаковой нестрогости многим неприятности обеспечили. И я тоже столкнулся, и только полное недоверие всему и вся с контролем везде, где это можно, позволили избежать мне совсем не нужных проблем, буквально на пустом месте.
Ну и еще один пример неоднозначности. Уже из аналитических выражений. Это хорошо известное от Задорнова: "Два плюс два умножить на два". Что примерно соответствует "Казнить нельзя помиловать". И тут достаточно поставить запятую, и все хоть как-то встанет на свое место. Или слово "умножить" заменить на "умноженное". Т.е., если написано "Два плюс два, умножить на два" то это 8, а если "Два, плюс два умноженное на два" - это 6, а если "Два плюс два, умноженные на два " - то 8. Где-то так. Поскольку про _скобки_ в выражениях не стоит забывать никогда. Лучше уж пусть будет "масло-маслянное", чем неопределенность.
Или еще аналогичный и сильно поучительный пример, сейчас нашедший широкое распространение в инете:
А все это во многом из-за того, что очередная лень, лень скобки поставить, типа, по умолчанию и так сойдет. В итоге как-то часто "мимо тазика с оркестром".
К чему это все я. А к тому, что если что-то строго не определено, не объявлено и идут ссылки на то, что ну типа "так всегда было", это же "общепринято" и тому подобное, на выходе может быть все что угодно, как правильный, так и неверный результат.
Спрашивается, а какое все это отношение имеет к этому самому пресловутому квадратному корню из минус одЫн? Да непосредственное. Поскольку в данном случае сразу рассматривается "обратная" операция, на при этом не определена "прямая". Иными словами, четко не определив, что есть квадрат числа, невозможно дать ответ и на вопрос о корне, в данном конкретном случае для "минус один".
В этом случае, ничего иного, как только сказать, что "пусть корень квадратный из минус один будет называться мнимой единицей "i"", ничего не остается. Да и не может быть. Из чего следует, что как бы "корень квадратный из минус один" не возводить в квадрат, всегда будет "i" в квадрате, а не "1" или еще что-то из вещественной части.
Иными словами, такая Модель основывается на том, что квадратом считается только (+1)* (+1) и второй вариант (-1)* (-1). И ничто иное не предусмотрено, не рассматривается и не допускается.
Повторюсь - для данной Модели корень квадратный из минус 1 - это всеми признанное "i". И, главное, никакому "раскрытию" "i" не подлежит и никуда деться и ни во что превратиться не может. И уж тем более в вещественное число преобразованию никоим образом НЕ подлежит.
Потому и комплЕксное число в рамках данной Модели состоит из двух "непересекающихся" частей. Нельзя установить "связь" между ними. И никогда из мнимого числа не получить вещественное и наоборот. Повторюсь - это результат того, что данная Модель этого НЕ предусматривает этого на уровне исходных данных. Для удобства рассмотрения назовем это Моделью с парадигмой v.1.0
Но возможна и Модель с парадигмой v.2.0. Главное отличие ее от предыдущей в том, что в ней квадратом также считается и такое выражение, как (+1)* (-1), и (-1)* (+1), в результате которого и получается "-1". Но возникает закономерный вопрос - а это "-1" и их исходные данные являются вещественными числами в полном их понимании? Или это те же самые мнимые, или это какие-то "другие" числа? И если другие, то какие?
Чтобы это понять, необходимо опять вернуться к картинке с площадями из второй части.
Кратко напомню, что получается, если не преобразовывать знаки:
S1 = ++a2
S2 = +-a2
S3 = --a2
S4 =-+a2
И, соответственно:
S1 = ++S
S2 = +-S
S3 = --S
S4 =-+S
где S - значение квадрата по модулю
А если применить стандартное преобразование знаков, то получим:
S1 = S3 = +S
S2 = S4 =-S
Такое странным не кажется? И как это правильно и корректно трактовать? Что, допускается рассматривать только два "верхних" квадранта, а нижнюю пару спустить в "утиль", и при этом искренне верить, что никакая инфа при знаковом преобразовании не потеряна?
Взяли это на заметку и вернемся к этому "знаковому" вопросу чуть позже, а сейчас рассмотрим парадигму v.3.0, в которой, в отличии от предыдущей версии знаковое преобразования не выполняется.
В этом случае получаем, что
S1 = ++S
S2 = +-S
S3 = --S
S4 =-+S
И, при этом, в отличии от парадигмы v. 2.0, S1!= S3 и S2!= S4, что вообще-то соответствует реальности, показанной на картинке. Но спрашивается, и что со всем этим делать, как трактовать и называть? И чтобы разобраться с этим, можно вспомнить, что квадрат может быть однозначно определен не только параметром "а", но и вектором, проходящим из точки с координатами 0.0 в противоположный угол, который в свою очередь однозначно определяется его длиной и углом наклона.
Но как только вектор нарисован, сразу же возникает соблазн "крутануть" его и посмотреть, что при этом произойдет. Но крутануть его таким образом, чтобы постоянной осталась не его длина, а та площадь, которую он совместно с углом наклона определяет. Да, при этом квадрат превращается в прямоугольник, но подчеркну еще раз - все той же площади "S".
Как это выглядит и что получится, если вектор "повернуть" - на картинке ниже
И вот что получилось. Хотя, честно сказать ничего особенно нового. Но самое интересное происходит в тот момент, когда вектор переходит с одной стороны оси "Х" на другую. В момент перехода с одной стороны на другую сторону его "длина" становится равной бесконечности. Так сказать некая "особая точка". А далее все то же самое происходит при пересечении оси "Y" в ее отрицательной области, затем оси "Х" в области отрицательных значений, оси "Y" в области положительных и... вернулись обратно в первый квадрант. На рисунке ниже это показано.
А если рассмотреть Модель v.2.0 (со знаковыми преобразованиями), то получим следующее.
Нижняя часть (ниже оси "Х") "просто" исчезнет, а вектор, после "бесконечность по оси Х+", появится на той же оси Х, но только в ее отрицательном значении. Вот так, ни много ни мало, да еще в добавок заполучили "пресловутый разрыв", что ну совсем не дело.
Получается, что либо знаковое преобразование в данном случае использовать нельзя, либо доказать, что не смотря ни на что потери информации нет. Вообще то, если первое, то это, как бы помягче сказать... Ну и так понятно, что плохо. Вопрос только, на сколько. Т.е. это только частный случай, и не более того. А ежели "того"? Но вопрос встал, и на него придется рано или поздно давать аргументированный ответ.
Ну а теперь пришла пора определиться с названием этих "новых" чисел, их возможным представлением и операциях над ними. Начнем с названий.
Прежде всего надо четко и однозначно определить, что используемый термин "мнимое число" относится исключительно к Модели v.1.0, и на другие модели распространяться не может. Просто по своему определению. Ранее еще были термины "Полумнимые", "Многознаковые". А может просто "Потусторонние"? Причем надо сразу четко и ясно понять, что это термин не имеет никакого отношения к ведьменьщине, чертовщине и прочему подобному. Просто эти числа лежат по разные стороны от осей координат. По ту сторону и по эту сторону. И не более того. Причем, этот термин "потусторонние", имеет более широкое значение, чем "многознаковые", и вот почему.
Связано это с их представлением. Просматривается три варианта их представления. Первый - в качестве сомножителей "ах" и "аy" с обязательным сохранением их знаков. Второй - это значение площади "S" с указанием (умножением на) весовые коэффициенты "кх" и "ку" так же с сохранением знаков по соответствующим осям и третий - в виде векторного представления.
Для удобства назовем первое представление v. 3.1, второе представление v. 3.2 и третье представление v. 3.3. Понятно, что все три версии представления позволяют однозначно определить параметр "S". Но вот какое представление лучше, а какое хуже - определяется тем, на сколько удобно можно будет выполнять операции над данными числами. Поэтому рассмотрим их (в смысле операций) подробнее.
Но это будет сделано уже в четвертой части. Поскольку это тема отдельная и большая... А еще остался вопрос о знаковых преобразованиях и их последствиях... Но это уже совсем другая история.
--------------------
Самая последняя (актуальная) версия материала (все части) доступна по ссылке http://aab57.ru/erkm/html/kv_kr.htm
55.4к
