А вы знали что у bc есть нативное возведение в степень?

Не знал. Может когда-нибудь пригодится.

У awk тоже:

rain@walkbook:~$ echo | awk '{print 5^5}'
3125
rain@walkbook:~$ echo | awk '{print 5**5}'
3125

Так вот чем вдохновлялся автор XLibre! (я про этот случай)

^

Не только там, это даже более распространенный оператор возведения в степень, чем ** или pow()

В разных языках символы разное значат, можно и запутаться.
В Си ^ это XOR, а в Луа ^ это POW, но в Луа ~ это XOR, а в Си ~ это NOT и в Lua ~ это NOT, и как ~ в Си, и как !.

Это можно прочитать как рэп

Я пользуюсь Питоном.

Всегда знал. Даже специально не смотрел — это стандартный «интуитивно понятный» значок для возведения в степень, он почти везде такой. А XOR он только в сях, которые тут как-то даже и ни к чему.

Я, правда, bc только в скриптах юзаю, а в скриптах редко бывает нужно возведение в степень. В качестве непосредственно калькулятора (когда мне надо что-то посчитать, а не в шелл-скрипте) юзаю в основном numbat, реже python. numbat понимает все три вида записи, и правильный (yˣ), и привычный в пределах ASCII (y^x), и питоний (y**x).

bash:

echo $((3**5)) $((3^5))
243 6

Лично я успел повидать некоторое^W уже достаточно систем. И если вижу, что где-то 2^3 == 1, просто пробую 2**3. И уж оно равно восьми примерно во всех остальных случаях. Но конкретно с bc в незапамятные времена случилось так, что сначала я прочитал man.

Это все гадкие сишные влияния. Всегда ^ должен быть степенью.

Емнип, в фортране **, а он постарше будет.

А направление тока в металлах должно обозначаться от минуса к плюсу. А ЛЮДИ ВО ВСЁМ МИРЕ ПРИДУРКИ! ТУПО ПРИВЫКЛИ РИСОВАТЬ НАОБОРОТ! РЕДИСКИИИИИИ, УУУУ :)

А ты хочешь чтобы договорились об значениях символов левых. Стоит сказать всем спасибо и поклон лбом в пол что + это сложить, а не вычесть, что // это целочисленное деление, а не комментарий, что… ой…

Уже давно в качестве калькулятора пользуюсь питоном. Там возведение в степень нормальное. bc раньше использовал, но какой-то он слишком ограниченный на мой вкус.

Всегда ^ должен быть степенью.

Только потому, что в техе так сделали? Или есть какие-то более глубинные исторические корни у такой нотации?

но в Луа ~ это XOR, а в Си ~ это NOT и в Lua ~ это NOT

Получается, что ~ в Луа - это и XOR, и NOT? :)

Эээ, y**x это не питоний, это фортрановский! Питон (и остальные) позаимствовал.

Унарные и бинарные операции могут использовать общие значки, вероятно дело в этом.

В техе это разве именно степень, а не типографский оператор верхнего регистра?

Ага

• x ~= y логическое NOT
• ~y побитовое NOT
• y ~ z побитовое XOR

Не замечал этого. Теперь мне известны целых три вида проблем с символами:

1. Неочевидные сами по себе: !, ~, %, ^, ?:.

2. Необходимость придумывать абра-кадабру для нестандартных операторов вроде >>= в Хаскелле.

3. Разночтение одних и тех же символов — только сейчас это заметил.

По сути, проблемы те же самые, как если бы использовались эмоджи.

В чём-то Паскаль Вирт был прав.

В техе это разве именно степень, а не типографский оператор верхнего регистра?

В техе это, конечно, типографский оператор. Ведь тех это система набора текста, а не калькулятор. Но в математической нотации степень обозначается оператором верхнего регистра, поэтому человек, который набирает формулы в техе, будет писать что-то вроде x^y

Не знаю, есть ли это в твоём списке или нет. Но меня раздражает использование общеизвестных символов вроде + для каких-то несвязанных вещей. Например для соединения строк. Или использование всем известных операторов побитового сдвига << и >> для стандартной библиотеки ввода-вывода в C++. Это просто жесть какая-то. Слава богу, после C++ кажется больше никто такого не делал.

Т.е. неуместная перегрузка операторов какими-то несвязанными с исходным значением операциями.

Очевидная альтернатива - использовать стандартный синтаксис функций. pow(x, y) вместо x^y, например. Кто-то может сказать, что так можно и до add докатиться. А я скажу - можно и ничего страшного. В Java есть такие типы вроде BigDecimal. А перегрузки операторов нет. И люди вполне себе пишут математические формулы и очень даже нетривиальные, просто используя буквенные методы. Да, конкретно тут я всё же сторонник перегрузки операторов, но даже и без них жить можно, как показывает практика. Если бы нельзя было - за 25 лет сделали бы. Но - не сделали и даже на горизонте не видно.

Символ + нормально, а вот >> и << это да, это жесть.

Строки образуют моноид относительно конкатенции. Математики операции обозначают + или *. Так что тут всё в традиции.

В мире много всякой чуши, которая образует моноиды. При том, что в моноиде операция вообще обычно умножением обозначается. Так что такой себе аргумент, если честно. Как минимум - сложение у обычного человека обычно коммутативно, а сложение строк - нет.

Как минимум - сложение у обычного человека обычно коммутативно,

гм, а если в язык кватернионы встроить, то как быть?

В качестве калькулятора давно использую ipython. Автодополнение, история, возможность писать многострочники, например, с циклами, возможность читать исходные данные из файла и записывать в файл.

Короче, не знаю, зачем сейчас нужен bc. Он всегда воспринимался сильно ограниченным. Наверное, в 70-80 годах был полезный инструмент, в последние же 30 лет смысла в нём нет.

Вот сразу понятно, человек никогда на бейсике не писал. Там как раз степень – крышка.

Если нет ограничений на использование GUI, есть ещё speedcrunch.

Вот сразу понятно, человек никогда на бейсике не писал.

Ну не факт же. Можно же просто не ожидать бейсик-совместимости в любом калькуляторе.

x**y - это, очевидно, наследие Фортрана. x^y - скорее всего идет от нотации TeXа, хотя в нем самом подобных вычислений нет. Применяется в системах компьютерной алгебры и еще много где.

А что с кватернионами не так? Сложение там определено, как сложение компонентов. Коммутативное.

Умножение некоммутативно.

А причём тут вообще умножение? Я же не предлагал умножать строки. Речь шла про то, что знак «+» неуместен для операции соединения строк.

Для кватернионов надо использовать те символы, которые традиционно используются в математике. «+», «*» и т.д, с этим никаких проблем я не вижу.

Может быть в 2026 году для программистов сложение строк уже стало традиционной операцией. Не знаю. Вроде бы пока ещё в разных языках оно всё сильно по-разному. .. в lua, || в SQL. Лично мне вообще симпатична идея полного отказа от выделенного синтаксиса для сложения строк, а вместо этого дать синтаксис для интерполирования строк. Т.е. вместо a := b + c пишем a := "${b}${c}". Для простейшего случая вроде мороки много, но в реальности там часто и пробелы и форматирование добавляются, и оно быстро начнет выглядеть пристойней.

Вот сразу понятно, человек никогда на бейсике не писал. Там как раз степень – крышка.

Ну не факт, что никогда. Я когда-то давно писал на бейсике, но сегодня я не помню, какой символ там используется для возведения в степень. Я даже не уверен, что в принципе что-то на бейсике в степень возводил, честно говоря — это не то чтобы прям самая частая операция в программах.

Я даже не уверен, что в принципе что-то на бейсике в степень возводил, честно говоря

Я тоже не уверен, что возводил в моём мультике :-D.

Короче, не знаю, зачем сейчас нужен bc.

Чтобы использовать его в шелл-скриптах, которые запустятся на любой (ну или почти любой) POSIX-совместимой системе. Включая даже «систему» тупо из ядра и busybox (в нём есть своя реализация в том числе bc).

Автодополнение

А что там автодополнять, “sin”?

история, возможность писать многострочники, например, с циклами

Можно прикрутить хоть в /bin/mysql, хоть в /bin/bc, хоть в любой другой шелл через “REPL-плагин” к текстовому редактору.

А чистый ipython — это, скорее всего, всё та же парадигма работы с последней строкой.

Циклы в bc имеются.

читать исходные данные из файла и записывать в файл.

bc <in >out

Кстати, дополню аргумент про шелл-скрипты: в некоторых шеллах нет математических операций. Шелл — изначально не ЯП общего назначения и точно не TMTOWTDI, а запуск программ. Использование сторонней программы для арифметики подходит под эту роль.

Ну вот на моём арче нет bc. В base он не входит. Отдельно я его тоже не ставил, нужды не было. Возможно ты преувеличиваешь его распространённость.

Чтобы использовать его в шелл-скриптах, которые запустятся на любой (ну или почти любой) POSIX-совместимой системе.

Оно мне понадобилось в жизни… Ну вот вообще ни разу в жизни. Хотя я в мире Unix/Linux уже 30 лет, и в т.ч. работал и над дистрибутивами, и над другими сложными системами, обвязанными bash лапшой.

Чтобы использовать его в шелл-скриптах, которые запустятся на любой (ну или почти любой) POSIX-совместимой системе.

А bc везде есть из коробки? Ну я удалил, т.к. не пользуюсь.

bc просто запускается, если нужно просто посчитать какую-то арифметику - ввёл выражение, получил ответ, всё просто, почему нет?

Если нужны циклы, что-то длинное, итд то удобнее конечно скрипт на обычном скриптовом языке писать (я на пхп), и не в интерактивном режиме а именно написав и сохранив его в виде файла, положенного в нужную директорию, возможно прокомментированного итд, т.к. рыться в «истории» интерактивного шелла, выискивая среди потока набранных формул нужное, весьма неудобно.

Оно мне понадобилось в жизни… Ну вот вообще ни разу в жизни.

Я очень рад за тебя. Но утверждение звучало не «не знаю, зачем мне нужен bc», а «не знаю, зачем сегодня нужен bc». Я привёл пример, для чего он кому-то (в данном случае мне, хотя и далеко не только) нужен.

А bc везде есть из коробки?

Практически. Это требование POSIX, вроде. Удалить (или в арче не ставить), наверное можно. Только многие скрипты работать перестанут, потому что именно bc обычно подразумевается как определённо имеющийся в системе, если в скрипте надо что-то посчитать. Если у тебя все скрипты самописные или из реп, то пофиг — то что из реп, притянет bc в зависимостях. Если не только, то лучше всё же иметь этот стандартный набор из grep, sed, awk, bc и прочего «стандартного».

По-моему expr обычно в скриптах для арифметики.

Отдельно я его тоже не ставил, нужды не было.

Ну это реально редкий случай. Он по зависимостям много чем тянется, например profile-cleaner или screenfetch. Да, не всем оно надо. Но вероятность, что не будет прям ни одного скрипта с bc стремится к нулю. Ну и если арчеводу или гентоводу попадётся скрипт с bc, он просто поставит bc из реп — это не проблема. В остальных дистрибутивах bc вроде бы из коробки, причём далеко не только в GNU/Linux. Опять же, даже в минимальных системах с busybox он есть (в моём случае именно этот вариант имеет значение).

Так-то понятно, что чего угодно может не оказаться — юникс-лайк системы пользователь может кастомизировать и урезать как ему вздумается. Но всё же других вариантов нет. Что не окажется bash, python, perl, numbat, или geenie (или чем ещё предлагается считать в скрипте?), всё же выше, чем что не окажется bc.

upd: Выше вон expr советуют. Это в принципе тоже вариант, да. Хотелось бы теперь узнать, есть ли в данном случае какие-то подводные камни

Я его скорее всего удалил, т.к. от него никакие пакеты не зависили. Ну раз он болтается без дела, значит и не нужен.

$ grep 'removed\sbc' /var/log/pacman.log      
[2025-01-17T19:19:20+0300] [ALPM] removed bc (1.07.1-5)

По-моему expr обычно в скриптах для арифметики.

Cледующий тред — «А вы знали что у expr нет нативного возведения в степень?».

Cледующий тред — «А вы знали что у expr нет нативного возведения в степень?».

По моему для этого такие операторы не нужны

$ (gcm iex).ResolvedCommand.Name
Invoke-Expression

$ iex "$('2*' * 5) + '1'"
32

$ [math]::pow(2,5)              
32

такие операторы не нужны

А powershell тем более.

А powershell тем более.

Мне нужно, а как вам мне без разницы.