this post was submitted on 02 Jan 2025
434 points (98.4% liked)

Science Memes

11516 readers
2712 users here now

Welcome to c/science_memes @ Mander.xyz!

A place for majestic STEMLORD peacocking, as well as memes about the realities of working in a lab.



Rules

  1. Don't throw mud. Behave like an intellectual and remember the human.
  2. Keep it rooted (on topic).
  3. No spam.
  4. Infographics welcome, get schooled.

This is a science community. We use the Dawkins definition of meme.



Research Committee

Other Mander Communities

Science and Research

Biology and Life Sciences

Physical Sciences

Humanities and Social Sciences

Practical and Applied Sciences

Memes

Miscellaneous

founded 2 years ago
MODERATORS
 

cross-posted from: https://lemmy.ml/post/24332731

~~Stolen~~ Cross-posted from here: https://fosstodon.org/@foo/113731569632505985

top 36 comments
sorted by: hot top controversial new old
[–] [email protected] 20 points 4 days ago (1 children)
[–] [email protected] 17 points 4 days ago (1 children)

Well, duh. All fractions are real.

[–] [email protected] 8 points 4 days ago (2 children)

except for the imaginary ones

[–] TempermentalAnomaly 3 points 3 days ago

Until you construct a square with them.

[–] [email protected] 1 points 3 days ago* (last edited 2 days ago)

ℚ ⊂ ℝ ⊂ ℂ, at least that’s how I was taught.

[–] [email protected] 17 points 4 days ago (8 children)

LOL! Man I learned that in college and never used it ever again. I never came across any scenarios in my professional career as a software engineer where knowing this was useful at all outside of our labs/homework.

Anyone got any example where this knowledge became useful?

[–] [email protected] 43 points 4 days ago (1 children)

It’s useful to know that floats don’t have unlimited precision, and why adding a very large number with a very small number isn’t going to work well.

[–] [email protected] 2 points 3 days ago (1 children)

Yeah but you don't really have to think about how it works in the background ever time you deal with that. You just know.

You learn how once and then you just remember not to do that and that's it.

[–] [email protected] 2 points 2 days ago

I agree we don’t generally need think about the technical details. It’s just good to be aware of the exponent and mantissa parts to better understand where the inaccuracies of floating point numbers come from.

[–] [email protected] 6 points 3 days ago

Accumulation of floating point precision errors is so common, we have an entire page about why unit tests need to account for it.

[–] [email protected] 5 points 3 days ago (1 children)

In game dev it’s pretty common. Lots of stuff is built on floating point and balancing quality and performance, so we can’t just switch to double when things start getting janky as we can’t afford the cost, so instead we actually have to think and work out the limits of 32 bit floats.

[–] [email protected] 1 points 3 days ago (1 children)

So you have to remember how it's represented in the system with how the bits are used? Or you just have to remember some general rules that "if you do that, it'll fuck up."

[–] [email protected] 2 points 3 days ago

Well, rules like “all integers can be represented up to 2^24” and “10^-38 is where denormalisation happens” are helpful, but I often have to figure out why I got a dodgy value from first principles, floating point is too complicated to solve every problem with 3 general rules.

I wrote a float from string function once which obviously requires the details (intentionally low quality and limited but faster variant since the standard version was way too slow).

[–] [email protected] 12 points 4 days ago (2 children)

If you’re doing any work with accounting, or writing test cases with floating point values.

[–] tdawg 16 points 4 days ago (4 children)

Please tell me you aren't using floating points with money

[–] [email protected] 37 points 4 days ago

Knowing not to use floating point with money is good use of that knowledge.

[–] [email protected] 5 points 4 days ago

You'd be dismayed to find out how often I've seen people do that.

[–] [email protected] 4 points 4 days ago (2 children)

Yeah I shudder when I see floats and currency.

[–] Womble 3 points 3 days ago* (last edited 3 days ago)

Eh, if you use doubles and you add 0.000314 (just over 0.03 cents) to ten billion dollars you have an error of 1/10000 of a cent, and thats a deliberately perverse transaction. Its not ideal but its not the waiting disaster that using single precision is.

[–] [email protected] 2 points 4 days ago* (last edited 4 days ago)

That sounds like an explosive duo

[–] [email protected] 2 points 4 days ago (1 children)

How do you do money? Especially with stuff like some prices having three or four decimals

[–] [email protected] 10 points 3 days ago (1 children)

Instead of representing $1.102 as 1.102 your store it as 1012 (or whatever precision you need) and divide by 1000 only for displaying it.

[–] [email protected] 1 points 3 days ago (2 children)

So if you handle different precisions you also need to store the precision/exponent explicitly for every value. Or would you sanitise this at input and throw an exception if someone wants more precision than the program is made for?

[–] [email protected] 6 points 3 days ago (1 children)

It depends on the requirements of your app and what programming language you use. Sometimes you can get away with using a fixed precision that you can assume everywhere, but most common programming languages will have some implementation of a decimal type with variable precision if needed, so you won't need to implement it on your own outside of university exercises.

[–] [email protected] 2 points 3 days ago

Okay thank you. I was wondering because for stuff like buying electricity, gas or certain resources, parts etc. there is prices with higher precision in cents, but the precision would not be identical over all use cases in a large company.

[–] [email protected] 5 points 3 days ago

No exponent, or at least a common fixed exponent. The technique is called "fixed point" as opposed to "floating point". The rationale is always to have a known level of precision.

[–] [email protected] 1 points 3 days ago

No. I don't have to remember that.

I just have to remember the limits and how you can break the system. You don't have to think about the representation.

[–] okwhateverdude 4 points 4 days ago (2 children)

How long has this career been? What languages? And in what industries? Knowing how floats are represented at the bit level is important for all sorts of things including serialization and math (that isn't accounting).

[–] [email protected] 1 points 3 days ago

Since 2008.

I've worked as a build engineer, application developer, web developer, product support, DevOps, etc.

I only ever had to worry about the limits, but never how it works in the background.

[–] [email protected] 2 points 3 days ago

More than a surface level understanding is not necessary. The level of detail in the meme is sufficient for 99,9% of jobs.

No, that's not all just accounting, it's pretty much everyone who isn't working on very low level libraries.

What in turn is important for all sorts of things is knowing how irrelevant most things are for most cases. Bit level is not important, if you're operating 20 layers above it, just as business logic details are not important if you're optimizing a general math library.

[–] [email protected] 1 points 3 days ago

To not be surprised when 0.1 + 0.1 != 0.2

[–] [email protected] 1 points 3 days ago (1 children)

Writing floating point emulation code?

I'd pretty much avoided learning about floating point until we decided to refactor the softfloat code in QEMU to support additional formats.

[–] [email protected] 1 points 3 days ago

The very wide majority of IT professionals don't work on emulation or even system kernels. Most of us are doing simple applications, or working on supporting these applications, or their deployment and maintenance.

[–] pyre 9 points 4 days ago

finally a clever user of the meme

[–] marcos 1 points 4 days ago

It's not mimicry.