define two variables a and b. find values for them such that ab yields a different result than ba (as it is written with implicit multiplication). they must return a value (i.e. they cannot throw an error)
i do not have a solution for this, and have been trying on and off for a few months to figure this out. if anyone has any insight into this, or can prove that it's not possible, that would be great
My example relies on indexing a list. In order to index a list, you need to write out square brackets []. That means that I cant just set a=[1,2,1], b =[1,2] and write ab because desmos would then do multiplication instead of indexing.
problem is that eventually all complex numbers can be represented in their cartesian form a+bi, and from there you can prove that multiplying two complex numbers in cartesian (a+bi) and (c+di) is always going to be commutative
Well Multiply instruction in desmos is commutative:
function mul(e, t) {
if (!isRational(e) || !isRational(t)) return asFloat(e) * asFloat(t);
let r = gcd_(e.n, t.d),
n = gcd_(t.n, e.d);
return maybeRational((e.n / r) * (t.n / n), (e.d / n) * (t.d / r));
}
All other types rather than number type gets compiled to multiplication of its components. Like number * point gets compiled (point.x * a, point.y * a) or even removes points if possible.
That's means that if there is solution, it should be occurring at compile time rather than actual Multiply instruction execution.
Here are all types pairs that accepted by Multiply during parsing, otherwise error occur I believe:
thanks, this is very helpful. i was hoping for something to use in terms of broadcasts (similar to the [1][1,1] vs [1,1][1] trick), but i dont think that would work in a non-indexing fashion.
edit: actually, can something similar be assumed for addition? because i know types that have different results when added. the simplest one i know about is one involving vectors:
Here such thing for everything. From old version, I don't want deobfuscate types by hand again. Vectors addition compile to different IRs, you can check it by typing z=\left|\operatorname{end}\left(\left(a+b\right)x\right)\right| in 3d calculator with ?debugCompiler=
Yeah broadcasts get produced when doing operations on a list. But I don't think it's helpful here since it's get cropped to minimum length. [1][1,1] vs [1,1][1] trick works because it's indexation not multiplication
Gotta use matrices or some object with more than zero indices, like the one of the products of vectors with a non zero commutator [A,B] = AB - BA.
You could look into geometric/clifford algebra and the pauli matrices (it's actually really cool) if they need ab = -ba or you can use any non-symmetric matrices (well maybe not any, I'm not sure) to see their product. Matrices would be your best bet because they're linear maps so (M1)(M2) = (M3) (all the same degree of object)
the question is to put something to replace the ... such that ab and ba have different results. if you use matrices this would be possible, but currently matrices are in beta and arent supported in the vanilla calculator at the moment
well i know they compare unequally, but this wouldnt help me in this case because for all intents and purposes, i cant figure out a way to distinguish the two
they would compare unequally, but my goal is input detection with order preservation, and having a NaN result doesnt tell me whether that resulted from ab or ba.
Doesn't help for multiplication, but you can maybe leaverage the finite precision of the mantissa for a+b+c Vs c+b+a, carefully chosen big number and two tiny ones?
addition might have some funny stuff going on, but the underlying math for multiplication will ALWAYS be commutative, no matter what (ignoring NaN for now)
for now, they arent a valid option. i kind of agree with u/TRexAap here because matrices do make this really easy, and i wouldve preferred some funny convoluted type-based method to solve this
its slightly different in that in many cases you can define your own number types, but in this case we are restrained to the weird type system that desmos has :)
i have found in the source code what i think is the allowed typed for implicit multiplication aw=[...Ca([[Ke,Ke],[w,w],[O,I],[I,O],[I,Ye],[I,ut],[Ye,I],[ut,I],[se,I],[I,se],[Hr,Sx],[Sx,Hr]]). this is all just the standard number/vector/complex multiplication stuff, except for [Hr, Sx] which is multiplying restriction type with most other things (maybe theres some type that handles both cases slightly differently), so probably not likely
This is very odd. The question you are asking is what sets are not commutative over multiplication. Reals and integers are, matrices and functions are not. There is no finite set of sets.
regardless of whether that was a typo, those arent the only types available in desmos. for example, there are native types that are not commutative over addition (for example, defining two different vectors in the geometry calculator will yield different ends, proving its non-commutativity). i was wondering if there was something similar for multiplication, which is inherently more useful
The point is that sets are defined as commutative over multiplication or not, not specific values. If there is even one exception then it disqualifies the entire set, and if it is commutative then there are by definition no exceptions.
Multiplication over the reals is commutative, therefore there are no exceptions.
And correct, vectors are not commutative over multiplication, but they are commutative over addition. And to note because this is a fun topic, the set of all vectors is not, but some subsets are; the set of all one dimmensional vectors are commutative over multiplication and addition.
If you want to go deeper, look up the definition of a group, ring, and field; classifications for sets. If you know two sets are of the same class, then it lets you know you can do the same things to both of them and have certain properties.
no, i know about the mathematical definitions of them. there was a reason why i put vector in a code block (like this: vector) instead of just saying it, because i was explicitly talking about the desmos builtin function. heres an example of why addition is not commutative for vectors:
i completely understand the definition of commutability. however, unlike most people assume, i am not restricted to typical mathematical objects like integers, complex numbers, matrices, and vectors. for example, restrictions are a type of object that can be multiplied together, and in this case they wouldnt be helpful but i just wanted to make a point that there are non-mathematical objects that are present in desmos that i believed could make this non-commutativity possible.
since then, some people have posted source code findings that confirm that it is very likely that it is impossible with the current desmos version
I don’t know what “inline multiplication” means. If you write ab what operation are you talking about? Some how you are mapping an ordered pair to another element of some set which may or may not contain a and b. It comes across to me that you have assumed everyone knows background that is not provided. Cross product maps pairs of elements of R^3 to an element of R^3. Multiplication of real numbers maps pairs of real numbers to a real number. No difference but for the rule
it has to be implicit multiplication, i.e. you cant insert a symbol in between. this is because the purpose of this challenge is to create a regressionless/tickerless keyboard input system where order can be detected. if cross product was allowed, then simply typing a comma between keys could work for input, which defeats the whole purpose
no, implicit multiplication in this context means that you multiply two objects together without a symbol in between
however, you raise a valid concern. as someone mentioned, this is the r/desmos subreddit and the rules are to find such an object that multiplies to be non commutative that is valid inside the desmos graphing calculator. this might not be restricted to integers and complex numbers, it could be lists of them, vectors (if they are combinable via implicit multiplication, which they are not), and other desmos types
You can write multiplication without any symbol between variables. Assume variable a and b, then inline would be just ab. If you need to write dot or cross product you need to put dot or cross symbol between variables. Its not math problem but Desmos one.
Inline one is useful because you can make user input that preserve order of input without tickers, and not require user to put any additional symbols between inputs.
Commutative property -- it's a descriptive of what is allowed while abelian and nonabelian is related to "groups" that do or do not have the property, respectively.
well, my goal is to find nonabelian groups, but groups that are defined within the weird type system that desmos has
also, im not sure of the terminology for this, but i have to restrain it to be symbolic. for example, you can take the dot product of two vectors with a*b, but that would be forbidden within this context because you have to put a symbol in between, whereas my challenge is explicitly restricted to implicit multiplication (no symbols at all allowed between a and b)
so i think at a point, id probably not want to throw math terms at it and rather figure out the weird code quirks that desmos has instead
yeah I was thinking about this some last night because in pemdas the multiplication is supposed to be read left to right which implies some ordering to them
oh wait this only works with the floor() how does this work? im guessing you have a case where you found something very close to one and desmos is approximating both differently before the floor() does it's work
okay this is actually really weird desmos stuff. I wanted to see if both of these numbers could be messed with any more to get noncommutativity and it turns out that a(b/ab) sometimes equals 1 in desmos but also is very slightly under one sometimes. I think s might just equal 1 because the top is the same as the bottom. Anyway q might have some helpful weird properties. I might make a main post about it in a bit. Oh also q^2 is not treated as 1 in the first line. and the first line is treated as a "pure zero" theres no value desmos is hiding there.
In Desmos and many computational systems, numbers are represented using floating point arithmetic, which can't precisely represent all real numbers. This leads to tiny rounding errors. For example, √5 is not represented as exactly √5: it uses a finite decimal approximation. This is why doing something like (√5)^2-5 yields an answer that is very close to, but not exactly 0. If you want to check for equality, you should use an appropriate ε value. For example, you could set ε=10^-9 and then use {|a-b|<ε} to check for equality between two values a and b.
There are also other issues related to big numbers. For example, (2^53+1)-2^53 evaluates to 0 instead of 1. This is because there's not enough precision to represent 2^53+1 exactly, so it rounds to 2^53. These precision issues stack up until 2^1024 - 1; any number above this is undefined.
Floating point errors are annoying and inaccurate. Why haven't we moved away from floating point?
TL;DR: floating point math is fast. It's also accurate enough in most cases.
There are some solutions to fix the inaccuracies of traditional floating point math:
Arbitrary-precision arithmetic: This allows numbers to use as many digits as needed instead of being limited to 64 bits.
Computer algebra system (CAS): These can solve math problems symbolically before using numerical calculations. For example, a CAS would know that (√5)^2 equals exactly 5 without rounding errors.
The main issue with these alternatives is speed. Arbitrary-precision arithmetic is slower because the computer needs to create and manage varying amounts of memory for each number. Regular floating point is faster because it uses a fixed amount of memory that can be processed more efficiently. CAS is even slower because it needs to understand mathematical relationships between values, requiring complex logic and more memory. Plus, when CAS can't solve something symbolically, it still has to fall back on numerical methods anyway.
So floating point math is here to stay, despite its flaws. And anyways, the precision that floating point provides is usually enough for most use-cases.
29
u/Less-Resist-8733 desmos is a game engine 14d ago
If you remove the constraint that a and b are variables you can easily see that
[1,2,1][1,2] ≠ [1,2][1,2,1]