If I set 175% scaling in Gnome Settings, the value is saved as 1.7518248558044434 in ~/.config/monitors.xml:
<monitors version="2">
<configuration>
<logicalmonitor>...
TBF the error can become that big if you do a bunch of unstable operations (i.e. operations that continue to increase the relative error), though that’s probably not what is happening here.
To get to 0.01 error, you’d need to add up trillions of trillions of floating point errors. It will not happen solely because of floating point unless you’re doing such crazy math that you shouldn’t be using primitives in the first place.
As the answer in the link explains, it’s adjustment of your scaling factor to the nearest whole pixel, plus a loss of precision rounding to/from single/double floating point values.
So I’m not really sure of the point of this post. It’s not a question, as the link quite effectively answers it. It’s more just “here’s why your scaling factor looks weird in your gnome config file”, and it’s primarily the first reason - rounding to whole pixels.
Gnome is coded with JavaScript (lmao 🤣) so yeah, I Think you are right.
EDIT: Actually, even if JavaScript and other languages have this issue, the value 1.7518248558044434 has not this issue. There is another reply that explains it and makes totally sense. But still pretty lame to know the desktop runs with JavaScript. (Yeah, I hate Gnome)
It’s not a “language” issue it’s a “computer” issue. This math is being done on the CPU.
IEEE 754
Some languages do provide for “arbitrary precision math” (Java’s BigDecimal for example) but it’s slower to do that. Not what you want if you’re multiplying a 4k matrix every millisecond.
Using JavaScript isn’t inherently a bad thing. JavaScript can be very useful when used for scripting. Obviously anything with a new for performance will be done in C.
JavaScript isn’t the best language to make a desktop interface in my opinion, it can be very efficient, but you can see in bugs (at least in the past) how bad performance it had, and they needed to re-factor it to replace to C or improve the JavaScript. I’m just laughing and making fun of it using JavaScript, not saying it is slow, Gnome is pretty fast nowadays.
Javascript was a toy created in the mid 90s to make dumb interactive animations and have some sort of dynamic aspect to a web page. The world starting to code entire desktop programs and servers in it was a giant, horrific, societal mistake.
And Gnome is far from the only desktop that uses JS, KDE Plasma, for example, also uses a lot of JavaScript.
It’s weird when people bash Gnome for using JS, when practically everybody else uses it a lot too. Shows that they’re just regurgitating “Gnome = bad!!!” nonsense.
We get it, you think disliking Gnome is a quirky, edgy personality trait.
Mostly C because you need to type more C code to do the same with JavaScript, so I suppose most of the logics are using JavaScript.
Plasma desktop has 2% JavaScript (https://invent.kde.org/plasma/plasma-desktop), it’s not comparable. 🙂
There’s a lot more to your UX than just the Plasma desktop. And you’re also trying to pass off Gnome’s shell as being Gnome desktop. Pretty disingenuous.
For the same reason a lot of programming languages can’t calculate 0.1+0.2 properly.
There’s a website explaining it: https://0.30000000000000004.com/
Floating point error? Yeaahhh no. No. Just… no. That is NEVER as big as 0.01 unless the number is also insanely massive.
The error is relative in scale. It’s not magically significant fractions off.
TBF the error can become that big if you do a bunch of unstable operations (i.e. operations that continue to increase the relative error), though that’s probably not what is happening here.
To get to 0.01 error, you’d need to add up trillions of trillions of floating point errors. It will not happen solely because of floating point unless you’re doing such crazy math that you shouldn’t be using primitives in the first place.
That’s why I said unstable operations. Addition is considered a stable operation (for values with the same sign)
0.001, but still
As the answer in the link explains, it’s adjustment of your scaling factor to the nearest whole pixel, plus a loss of precision rounding to/from single/double floating point values.
So I’m not really sure of the point of this post. It’s not a question, as the link quite effectively answers it. It’s more just “here’s why your scaling factor looks weird in your gnome config file”, and it’s primarily the first reason - rounding to whole pixels.
True, but it is not that difficult to trucante (or round) the value at the second decimal value.
Gnome is coded with JavaScript (lmao 🤣)
so yeah, I Think you are right.EDIT: Actually, even if JavaScript and other languages have this issue, the value 1.7518248558044434 has not this issue. There is another reply that explains it and makes totally sense. But still pretty lame to know the desktop runs with JavaScript. (Yeah, I hate Gnome)
It’s not a “language” issue it’s a “computer” issue. This math is being done on the CPU.
IEEE 754
Some languages do provide for “arbitrary precision math” (Java’s BigDecimal for example) but it’s slower to do that. Not what you want if you’re multiplying a 4k matrix every millisecond.
I see, thanks for the explanation.
GNOME is primarily written in C
Okay, but still needs JavaScript, they are slowly trying to remove or improve it. But it is a fact that it also runs on JavaScript. 🤣
Using JavaScript isn’t inherently a bad thing. JavaScript can be very useful when used for scripting. Obviously anything with a new for performance will be done in C.
JavaScript isn’t the best language to make a desktop interface in my opinion, it can be very efficient, but you can see in bugs (at least in the past) how bad performance it had, and they needed to re-factor it to replace to C or improve the JavaScript. I’m just laughing and making fun of it using JavaScript, not saying it is slow, Gnome is pretty fast nowadays.
Javascript was a toy created in the mid 90s to make dumb interactive animations and have some sort of dynamic aspect to a web page. The world starting to code entire desktop programs and servers in it was a giant, horrific, societal mistake.
It’s mostly C.
And Gnome is far from the only desktop that uses JS, KDE Plasma, for example, also uses a lot of JavaScript.
It’s weird when people bash Gnome for using JS, when practically everybody else uses it a lot too. Shows that they’re just regurgitating “Gnome = bad!!!” nonsense.
We get it, you think disliking Gnome is a quirky, edgy personality trait.
Mostly C because you need to type more C code to do the same with JavaScript, so I suppose most of the logics are using JavaScript. Plasma desktop has 2% JavaScript (https://invent.kde.org/plasma/plasma-desktop), it’s not comparable. 🙂
There’s a lot more to your UX than just the Plasma desktop. And you’re also trying to pass off Gnome’s shell as being Gnome desktop. Pretty disingenuous.
But at least the desktop itself isn’t using JavaScript that much like Gnome do. Show me the repo with the % to see what are you referring.