К вопросу о парадигмах (ссылка на статью)
Комментарии:
2023-06-12 alextretyak
Во втором случае больше проглядывается одинаковость действий, замаскированная в первом случае использованием операции сдвига, хотя именно сдвиг по смыслу самой задачи и не требуется. Эта одинаковость является косвенным признаком того, что данную задачу удается все-таки яснее выразить, используя парадигмы PL/1, а не Си. ...понятие битовых строк и их фрагментов могут оказаться понятнее.Соглашусь с таким утверждением. Поэтому решил добавить в 11l метод bits() для целочисленных типов, который принимает аргумент-диапазон, которые [диапазоны] в 11l бывают на любой вкус:
var i = 1234'ABCD // шестнадцатеричное число (0x1234ABCD в Си) print(hex(i.bits(24..))) // выведет биты, начиная с 24-го (выведет 12), биты нумеруются справа [начиная с 0] print(hex(i.bits(4..11))) // выведет биты с 4-го по 11-й включительно (выведет BC) print(hex(i.bits(4.<12))) // выведет биты с 4-го до 12-го не включая последний (вывод такой же: BC) print(hex(i.bits(4.+8))) // выведет 8 бит начиная с 4-го (вывод такой же)
В связи с этим, если у уважаемого kt найдутся ещё какие-то стоящие "фишки"/полезные возможности PL/1, о которых мало кто знает и/или которых нет в C/C++/Rust/Python, буду рад о них услышать, дабы утащить их в свой язык. :)(:
2023-06-12 kt
Уже давно была написана сводка всяких мелких исправлений в PL/1. Вы её не видели?
2023-06-12 Автор сайта
если у уважаемого kt найдутся ещё какие-то стоящие "фишки"/полезные возможности PL/1, о которых мало кто знает и/или которых нет в C/C++/Rust/Python, буду рад о них услышать, дабы утащить их в свой язык.Хотя спрашивали не меня, попробую назвать то, на чём остановилось внимание.
- Типы в инженерных задачах. Но я не созрел, чтобы это как-то применить у себя.
- Почему в PL/1 не зарезервированы ключевые слова — польза в том, что при развитии языка новые ключевые слова не вступают в противоречия с идентификаторами в старых программах. Это накладывает некоторые ограничения на язык, и мне пришлось выбирать — то ли это, то ли что-то другое. Язык — это всегда компромиссы. У Вас же нет цикла с проверкой условия внизу из-за питоновского синтаксиса?
- Насчёт «утащить»: битность чисел почти как в PL/1.
2023-06-15 alextretyak
Уже давно была написано сводка всяких мелких исправлений в PL/1. Вы её не видели?Возможно видел, но внимательно не читал. Сейчас прочитал более вдумчиво, но, увы, не нашёл ничего соответствующего моему запросу.
Типы в инженерных задачах. Но я не созрел, чтобы это как-то применить у себя.Я тоже.
Хотя вот в C++14 появились единицы измерения для интервалов времени, чтобы можно было писать 3h + 20min + 45s, но тут я решил пойти по пути Python и в 11l запись получается длиннее: TimeDelta(hours' 3, minutes' 20, seconds' 45), но зачастую последняя запись более наглядна: TimeDelta(hours' h) хоть и длиннее, но выглядит лучше, чем h * 1h.
Почему в PL/1 не зарезервированы ключевые слова — польза в том, что при развитии языка новые ключевые слова не вступают в противоречия с идентификаторами в старых программах.В современных языках программирования эта проблема решается контекстными ключевыми словами (см. документацию C#) или по-другому soft keywords (документация Kotlin).
В том же Python новые ключевые слова match и case являются soft keywords.
Впрочем, незарезервированные ключевые слова могут быть полезны для программ, которые являются переводом с других языков программирования (и в которых [в программах] встречаются идентификаторы, являющиеся ключевыми словами в целевом языке). И если бы я только начинал работу над реализацией языка сейчас [либо, если бы я раньше [до начала реализации] знал о такой особенности PL/1], вполне вероятно, что я бы подумал о том, как сделать [если и не все, то почти все] ключевые слова языка контекстными (т.е. незарезервированными), но на данном этапе проводить рефакторинг синтаксического анализатора как-то неохота.
Насчёт «утащить»: битность чисел почти как в PL/1.Да, я думал на тему того, чтобы разрешить типы вроде Int24 или даже Int23, но пока не могу определиться с реализацией. А вообще, подход Си мне нравится больше [чем подход PL/1]: битовые поля, хотя и довольно неуклюжи, но хорошо ложатся на реальную аппаратуру и понятно как реализуются.
2023-06-24 Бурановский дедушка
в финансовых расчетах важны проценты, сложные проценты и т.д. Именно поэтому так важны десятичные дроби и их поддержка.Простой пример. У человека оклад 100 000 рублей, но в этом месяце он отработал не 168 часов, а 167. Тогда ему должно быть начислено 99404,7619047619 рубля. А после вычета подоходного (умножить на 0,87) на руки он должен получить 86482,1428571429. рубля. Простой пример того, как десятичные дроби накапливают ошибки вычислений. Один из способов их избежать — это иметь отдельные числитель и знаменатель (например, m/n), а операции с ними проводить по правилам арифметики:
m/n * x/y = m*x / n*y m/n + x/y = (m*y + x*n) / n*yа перевод к привычной десятичной дроби проводить в последний момент, когда надо выдать «итого».
2023-06-27 alextretyak
Один из способов их избежать — это иметь отдельные числитель и знаменатель (например, m/n), а операции с ними проводить по правилам арифметикиСпособ хороший, вот только например при начислении процентов на остаток на счёте числитель и знаменатель будут всё время расти до бесконечности, и число, хранимое в такой форме, будет требовать всё большего и большего объёма памяти.
Вот простая программка на Python, иллюстрирующая эту проблему:
import fractions x = 1000 for i in range(20): print(x) x *= (1 + fractions.Fraction(1, 100)) # x *= (1 + 1/100)Если процент на остаток начисляется один раз в год, то это, конечно, не настолько критично. Но что если потребуется начислять процент каждый день?
И я не вижу, чем двоично-десятичное представление принципиально лучше обычного float двойной точности [т.е. double в терминах Си] для хранения денег и проведения финансовых расчётов. А чтобы не выводить числа вроде 1.68999999999999E-001, достаточно просто округлять выводимое число до 6 знаков после точки/запятой (используя round(x, 6) в Python, sprintf(s, "%.6f", x) в Си или аналоги).