Non fungible numbers
Multiplication and addition that is no longer commutative
Imagine a world where added numbers are identical but not equivalent.
So 4 apples + 3 oranges = 4 apples then 3 oranges
This is identical to 7 but not equivalent.
I am thinking of potential use in government accounting and algebraic programming with numbers.
Rather than all taxes going into a single taxable account and then spread out to different funding initiatives, you track the income of each area and track the costs of each taxraising and each funding. So roads should be self funding.
When I have a configuration for a web server I want to add to it a particular behaviour and have it slot into the right place automatically. So the data structure is a polynomial and I add a polynomial confifuration that "fits" the shape of the polynomial that is already there.
Usually in Kubernetes configuration there is few places that can accept my configuration fragment. I should be capable of "adding" to a particular YAML key. There is only small subset where it is valid. The polynomials aren't compatible except for certain areas.
Ну, вы можете найти или придумать много колец чисел, которые некоммутативны, либо по умножению, либо по сложению, либо по тому и другому. А почему только умножение и сложение? У нас много операторов. Кольцо матриц некоммутативно относительно умножения и т.д.
Итак, я думаю, это не новинка, за исключением именования. Зачем использовать слово «заменимый» для «коммутативного»? На самом деле это то, как вы определяете знак равенства «=», в биткойнах 1 BTC не должен быть равен другому 1 BTC по вычислительной сложности или энергии, необходимой для его майнинга (или каждого составляющего блока, составляющего этот 1 BTC), но «равенство», определенное биткойн-кодом, искусственно делает их «равными». На самом деле, в базовой реальности, возможно, нет ничего действительно идентичного, и равенства конструируются как циклы процессов (т. /wiki/Equivalence_class) в разделе операции).
Я имею в виду, что процессы часто некоммутативны, поэтому вам приходится иметь дело с ними, ища пути в пространствах состояний (скажем, пространство состояний машины или облачной инфраструктуры не всегда может быть обратимо одной и той же операцией, но применяются разные операции или операторы к ним (= программам) необходимо применить, чтобы достичь того же состояния назад и вперед), чтобы перейти и вернуться в исходное состояние.
Помимо естественных явлений, вы также можете установить значение сложения, выбрав свойства кольца аксиоматически. Например, если мы определим «сложение» как сложение числительных, а не чисел, мы получим, что умножение и сложение не коммутативны:
4 3 = "43", что не совпадает с 3 4 = "34"
4 * 3 = "3333", что не равно 3 * 4 = "444"
В конечном счете, числа — это инструменты вычислений, а инструменты по своей природе прагматичны — я бы сказал «да» — идите вперед, определяйте новые системы счисления там, где это удобно.
Well, you can find or come up with many rings of numbers, that are non-commutative, either under multiplication, or addition, or both. And, why just multiplication and addition? We have lots of operators. Ring of matrices are non-commutative under multiplication, etc.
So, I guess this is not a new thing, except for naming. Why use the word "fungible" for "commutative"? In reality, it's how you define the equality sign "=", in bitcoin, 1 BTC should not be equal to another 1 BTC under computational complexity or energy needed to mine it (or each constituent block making up that 1 BTC), but the "equality" defined by bitcoin code artificially makes them be "equal". In fact, at the base reality, perhaps nothing is really identical, and equalities get constructed as process loops (i.e., programs, that reverse other programs, forming state loops, or equivalence classes under operations).
I mean, processes are often non-commutative, so you have to deal with them by searching paths in state spaces (let's say a state space of a machine or cloud infrastructure can not always be reversible by the same operation but different operations or operators applied to them (=programs) need to be applied to reach the same state backward vs forward) to go and come back to the original state.
Apart from natural occurrences, you can also set the meaning of addition by choosing ring properties axiomatically. For example, if we define "addition" as adding up numerals, rather than numbers, we get that multiplication and addition are not commutative:
4 + 3 = "43", which is not the same as 3 + 4 = "34"
4 * 3 = "3333", which is not equal 3 * 4 = "444"
Ultimately, numbers are tools of computation, and tools are pragmatic in nature -- I'd say yes -- go forward, define new number systems, where it is convenient.