mayton2019

Action Script - это как Cobol в наше время. Разработчики отрастили седые бороды и померли.

Проверь что
имя_текстполя.text
не пустое.

Проверь какое числовое значение возвращает
имя_текстполя.text.indexOf(".")

Это и будет скорее всего ответ на твой вопрос

Ассемблер полезен при анализе прошивок на безопасность.
При изучении того как работает софт без исходного кода (обратный инжинеринг)
и при решении задач интеграции разных слоёв софта.

Ассемблер также очень близко стоит к разработке компилляторов. И если у вас нет
соотвествующих знаний то строить свой компиллятор вы не сможете. Или вам нужно
будет изучать готовые back-ends, virtual-machines.

Ассемблер помогает при анализе узких мест в коде. В частности например
векторизация вычислений ставит в первую очередь вопросы на которые ассемблер
отвечает а ЯВУ - нет.

Знания ассемблера помогают сделать бинарник компактнее. Это важно при разработке
встраиваемых систем.

В целом острой необходимости нет. Особенно если ты работаешь с веб-дизайном например.
Я перешел когда мне стало интересно разворачивать Ораклы и Hadoop и прочие вещи
и мне нужна была нативная интеграция bash. Не на уровне виртуалок или докеров или WSL
а мне нужна была истинная система. Делить ресурсы 50 на 50 между гостем и хостом я не хотел.
И задачи я себе придумывал такие которые требовали hardware нагрузить на сто процентов.

Корпоративные ноуты еще долго будут под Windows11. Это стандарт де факто для офиса. И я с ним
вобщем согласен. Я-бы сказал что не звучит вопрос переходить или не переходить. А в современном
мире, в мире где допустим командная строка как способ оперативного решения задач снова возвращается
в руки разработчику (после периода забвения от Windows95) или девопсу, быть неграмотным в этой
строке просто неприлично. Нужно быть грамотным в юниксовой строке независимо от того что у вас
хост-система на декстопе.

Вообще ты сам себе ответил на вопрос

в разных отраслях для личного пользования.

Главный пользователь и заказчик - это ты. И когда ты разрабатываешь свою библиотеку векторной алгебры - то пишешь модульные тесты. И тесты, как-бы документируют твою библиотеку и закрывают все вопросы
с нулями и бесконечностями.

Какие вообще у тебя варианты по отработке неопределенностей? Я вижу такие.
1) Возвращать бесконечность +Inf. Это нормально для floating-point. Но влияние результата на стек
вызовов дальше надо учитывать. Эта бесконечность пойдет в другие формулы порождая новые бесконечности и т.п.

2) Бросать исключение. Это не в духе С++ и не всегда удобно для выскокой производительности. Но языки высокого уровня этим часто пользуются. Здесь мы предполагаем что такой результат - крайне нежелателен и работа стека расчета векторов будет аварийно прервана.

3) Возвращать специальный контейнер с результататом (Optional или Either) или пустой контейнер. Это в духе функционального кодинга. Но весь твой стек должен тоже быть адаптированным к таким Optional параметрам результатов.

И есть еще вариант - просто найти такой базис вычислений в котором нет такой проблемы. Пускай допустим векторы так и остаются основным типом данных но расчеты ты будешь делать в каком-нибудь другом типе где эта операция на уровне математики - безопасна и всегда определена. Грубо говоря как в углах Эйлера. Чтоб не писать всякие проверки условий (if) - можно перейти к кватерниону и там вроде как вращение легче идет.

Он называется guard expressions., и имеет отношение к pattern matching.

Нет. То что ты нарисовал - это просто форматирование.