OberonCore

Ведь SHORTREAL - это 32 бита, а LONGINT - 64. Значит, SHORTREAL не позволяет различать всевозможные LONGINT, некоторые сольются. Пример:


В стандарте написано:

Ну, "включение касается значений" - это весьма правильно написано. Включение не обязывает значения различаться. В этом смысле /dev/null способен вместить всё Но уважения такой абзац, прямо скажем, большого не вызывает. Т.е. конечно, понятно, что имелся в виду диапазон. Но тогда так и надо было написать. И в этом случае нет никакой иерархии, т.к. SHORTREAL не старше, чем LONGINT. Понятие подтипа и иерархии типов описано Лисковой. Конкретное число LONGINT не является числом с плавающей точкой - не может быть представлено таковым без потери информации. Я бы даже сказал, что возможность неявного преобразования от LONGINT к SHORTREAL вызывает большое подозрение с точки зрения надёжности.

Тут вопрос, почему SHORTREAL >= LONGINT (r32 >= i64) вызывает вопросы, а REAL >= LONGINT (r64 >= i64), судя по сообщению, не вызывает.
В целом, учёт всех особенностей IEEE 754 в ЯВУ дело непростое, вот и делаются подобные приближения.

> Тут вопрос, почему SHORTREAL >= LONGINT (r32 >= i64) вызывает вопросы, а REAL >= LONGINT (r64 >= i64), судя по сообщению, не вызывает.
И так хорошо.

Видимо, речь идёт о диапазонном включении. От наименьшего до наибольшего на числовой прямой.

Если рассуждать строго, то SHORTREAL в представлении IEEE 754 конечно нельзя сравнивать с LONGINT. Чем выше показатель экспоненты -- тем больше "дырки" между двумя близлежащими точными значениями у вещественных. Если построить график представимости чисел, то он будет похож на расчёску с зубьями, причём зубья будут всё реже в сторону увеличения длины такой расчёски. А представление целых --будет просто прямая линия.
Но по контексту Илья, конечно, прав. Речь идёт про диапазон охвата чисел.

А в случае DoubleDouble?
См. например https://mrob.com/pub/math/f161.html
107 bits of mantissa не будет ли достаточно? 161 bits?
( Достаточно для DoubleDouble >= LONGINT )

Вопрос не в том, как исправить эту ситуацию. Вопрос в другом. Данное преобразование происходит с потерей информации. Значит, делать его неявным опасно. Из здравого смысла безопасно и допустимо делать неявными только те преобразования, которые тривиальны (расширение области определения, т.е. вложение байта в слово, к примеру). А любые нетривиальные вещи, в т.ч. теряющие информацию, нужно делать явными. В КП они сделаны неявными, это я расцениваю как фактор, снижающий надёжность языка. Если надёжность была целью проектирования, то это ошибка проектирования. И, в общем-то, любой независимый эксперт скорее всего тоже будет так считать. Но в данном сообществе своя правда, каковую мы и наблюдаем в комментариях по этому вопросу.

( Пишу с мобильного, орфографию и т.п. если что завтра отредактирую, смысл - инвариант )

Вообще-то, идея Н.Вирта -- красивая

Если не хватит DoubleDouble, то возмём 4xDouble

Если "силовым путём" наращивания мантисы, всё равно не удастся , то есть ещё интервальная арифметика.

Здравый смысл нам говорит, что если мы используем числа с плавающей точкой, то должны это делать на всем протяжении жизненного цикла. Есть очень небольшое количество задач, когда нужно преобразовывать вещественные к целым, и, в таких случаях, диапазон вполне умещается в оба типа. Например, координаты. К тому же, на современных процессорах разница в производительности операций над вещественными и целыми числами ничтожна, а на некоторых архитектурах вещественные выигрывают.

Сложение вещественных тоже, в общем, происходит с потерей информации.

Делайте как хотите, я всё равно не из вашей песочницы. Будь я автором какого-либо языка программирования, я бы так никогда не сделал. Вирт сделал. Хотите жить в идеальной вселенной, где Вирт всегда прав - ваша воля. Но в целом у любой задачи есть более одного решения, поэтому идея о том, что «Вирт всегда прав» уже изначально неадекватна. В любом инженерном деле решение всегда компромиссное, оно может быть выбрано исходя из текущей задачи. Именно поэтому тот же Вирт создал не один язык, а много. При этом, он сам никогда не заявлял, что он всегда прав. Он писал: мы попробовали то-то, но практика показала то-то, поэтому мы сделали ещё один язык, в который вот это добавили, а вот это выкинули. Т.е. была и подгонка под следующую задачу, отличающуюся от предыдущей, и исправление ошибок. В т.ч. и в предложенной статье «от модулы к Оберону» про это есть. Т.е. Вирт сам прямо пишет о том, что он ошибался, и подробно описывает свои неудачи.

А вы сделали из него бога. Это очень глупо и общение с вами вредит мне, честное слово.

Просто посмотреть, как вы юлите и переводите тему, чтобы только не признать, что решение неудачное и чреватое ошибками - мерзко глядеть.
Вот к примеру, я пишу про SHORTREAL и LONGINT, а мне говорят «а почему тогда не написал про DOUBLE?». Или «а сложение тоже плохо». И т.п.

В комп, на котором крутился первый Оберон вещественные были 64 и 32 бита, а целые от 32 бит вниз, и цепочка включения выглядела иначе.

Вирт живой человек. И если Вам интересно, он потом исправился. В Обероне-07 преобразование целого в вещественное уже делается явно — через встроенную функцию FLT. Но Вы, по-видимому, этого не знали и раздули из Вирта монстра. %)

Вот именно, это путь поиска и развития. Эволюции, если угодно.

Я что-то слышал про то, что в других языках было по-другому, но историю не настолько выучил. А не зная, что было до, а что после, нельзя и делать выводы о направлении эволюции. Кроме того, об осознанных выводах можно говорить только в том случае, если об этом явно написано. Не знаю, написано ли такое про Оберон-07.
> Но Вы, по-видимому, этого не знали и раздули из Вирта монстра.
Разве? Если я из кого-то и раздул монстров, то из тех, кто не может признать конкретное решение Вирта ошибкой. Оказывается, сам Вирт это признал, а в данном сообществе это не получается Не так страшен Вирт, как его русский культ.

Кстати, ваш форум не работает. Не могу добавить комментарий.

Хорошо. Вам люди, которые уважают опыт и достижения Вирта, видятся оголтелыми фанатиками, не признающими никаких здравых доводов. Так лучше?

Можно побольше инфы о том, что конкретно не работает? Не могу воспроизвести баг. Что именно Вы пытаетесь сделать?

https://zx.oberon2.ru/forum/viewtopic.php?f=4&t=222&p=3332#p3332

Уважать это одно, а быть оголтелым фанатом - это другое. В упор не видеть ошибок - это ближе ко второму. Про баг см. на том форуме.

Ну и много таких языков назвать можете?

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

В общем, живите, как хотите, как уже было сказано выше Зря я не сдержался и в это полез, только потратили время зря.

budden, ладно, мы все тут оголтелые фанатики, а Вирт не бог и может ошибаться. А те языковые семантические конструкции, которые Вы собирались впилить в Оберон — они там точно нужны? А они вообще нужны для надёжного и качественного программирования? Они достаточно выверены временем? Вы уверены? Оберон с ними станет стройнее, красивее? Или это просто потакание Вашим привычкам из ФП и скрещивание носорога с бульдогом? Я всё-таки не выдержу и скажу. Мне кажутся сумбурными и странными Ваши действия, связанные с Оберон-технологиями. Я не нахожу в них ни пользы, ни смысла. Тон разве что какой-то задаётся, да и тот непонятный) Но я фанатик, ладно. Моё мнение можно не учитывать. А форум я уже вроде бы починил, пользуйтесь)