scrubbles

joined 2 years ago
MODERATOR OF

It feels weird at first, but it really is the best safest way to store the auditable amount, and really most of the time with currency you don't need to ever mutate it at the DB level, so why introduce the possibility at all of a precision error. One thing that is common is that you do a order by of your transactions, which is why the imprecise is useful, but then you display the string version to the user. It also keeps the precision rather than truncating the precision off (with money the .00 is important, most banks require exact precision to know that you didn't accidentally have a rounding/truncation error)

Right now I'm using proton. I tried Zoho for a while, but somehow magically I was subscribed to a ton of spam, and they were just overall shady. I may switch, but right now I'm happy

I've heard it's good. I saw the preview and it made it look terrible, but reviews both from critica and audiences seem to like it. I'll be checking it out soon.

I'm sure it'll be a standard romcoms, but romcoms can be fun imo

[–] scrubbles@poptalk.scrubbles.tech 12 points 3 weeks ago (3 children)

Double is not perfectly precise. It is quite literally a function that calculates what the value should be. There are converters to show the drift: https://www.h-schmidt.net/FloatConverter/IEEE754.html

$40.01 is literally stored as 01000010001000000000101000111101 in a float type, which is literally stored as 40.009998321533203125. The margin of error goes up the larger the number.

Either you're just trolling, or incredibly arrogant. I have been coding in the FinTech space for over a decade and can tell you firsthand that these are real issues, and have real consequences.

But hey, don't take my word for it:

There have been some famous disasters thanks to floating point math

As for rounding, I can't even think of a way to describe what a terrible idea that is. I'd suggest reading those articles and asking the stock exchange why they don't "just round it" when dealing with millions of transactions that deal with fractions of pennies. "Just round it"

[–] scrubbles@poptalk.scrubbles.tech 7 points 3 weeks ago (2 children)

I got my own domain and registered it with an email service. I figured that companies come and go, but my domain will stay the same and I could just swap it to another.

Yes holy shit Jesus fuck yes I know this. Read again the second part where I said that there's no way to do this in reality.

[–] scrubbles@poptalk.scrubbles.tech 3 points 3 weeks ago (1 children)

Thank you for getting what I was trying to say. Spot on, I don't think the idea is wrong. It would be nice if there was a test to say "hey are you able to vote on these topics, have you researched, are you voting with your brain or with emotions?" - which is why I say the idea is fine. There isn't though. There isn't a single way to do that fairly or equitably.

Thank god the commenters immediately jumped down my throat to tell me what I already knew.

[–] scrubbles@poptalk.scrubbles.tech 16 points 3 weeks ago* (last edited 3 weeks ago) (8 children)

Wow uh, nope. A f64 is a double, floating point precision type, aka not precise. You should never store currency values in that, otherwise you, well you just recreated the exact bug we see in the image above.

Bud, like I said, the problem comes off as "lol it's so easy", but unless you have literally worked with money before - real actual dollars and cents, it is much more complex than you give it credit for.

Your approach may appear fine, it may look fine, but with money precision matters. Floating points are not precise, they are an exponential representation of a function that will give you a pretty good estimation of the value you want - but they are not precise. In money, you must be precise. You fuck up that value, you get customers calling in, you get banks rejecting your transfers, you get governments closing you down because your code is shit and they don't trust you to manage people's money.

Now, I'm not a jerk, I'll tell you the correct answer, we should all learn. The correct format to store money in? A string. Immutable, perfectly precise to whatever precision you want, and whatever the customer types in is exactly what you can store. You parse that string to make sure it's valid, you use your currency enum as you said (which I wouldn't btw, currencies actually change more often than you would expect), to make sure it passes to a correct numerical value that fits within the bounds of that currency. If you need to mutate that value, in the same language you go to a precise type, mutate, and then return it back as a string value. Storing in a database then you store the value as string, and best practice is to store the "imprecise" amount next to it as whatever the database supports. That way, you have the auditable real value ($4.00) stored for use on reports and taxes, and the imprecise ($3.99999999898998888181) that you can use for sorting, filtering, and regular database options.

Strings also should be used over the wire, aka in json payloads in rest apis. This is because JavaScript and other languages parse the number types as floats, which again are imprecise. String is the only safe way to translate money between languages and data stores.

For Rust, as I assume that's what you're referring to, you should use something like rust_decimal - crates.io: Rust Package Registry https://crates.io/crates/rust_decimal a precision based crate for handling money.

Oh I'm not surprised used it's slowed down at all. Vegas is second only to Florida where more rural (and poorer) Midwestern and southern people go in the US, it's no surprise they aren't traveling as much. Less about Vegas and more about how people are doing as a whole.

Completely agree with you, this is just engagement bait

[–] scrubbles@poptalk.scrubbles.tech 9 points 3 weeks ago* (last edited 3 weeks ago) (17 children)

I won't call out of or the drawer for bad idea. The idea is fine. There's just zero ways to ever implement it. It's nice to dream though

Thank you, definitely showing my age there!

 

One of my favorites, just remembered it, and this article is from the AU's perspective.

I like that they have to explain it to Aussies because they don't understand why there would be a need for massive parking lots.

Not all US cities have reliable or widespread public transport networks, so it's likely that a similar number of Americans drive to and from concerts. As such, most stadiums in the US are surrounded by vast parking lots to accommodate all the vehicles - but not in Australia.

 
 
 

cross-posted from: https://lemmy.one/post/11673394

Every movement to oppose Christianity had its place. In the 80s they called themselves Satanists, even though they didn't believe in a literal Satan. In the 2000s we saw the introduction of "militant" atheism, externally dubbed the "new atheists." Now we have a new generation of ex-Christians who can speak to conservative Christian beliefs because they were able to get out. And they can remind everyone that it wasn't easy.

I am still a "militant atheist" in that I'm willing to speak my mind. I don't bring up my atheism unless someone makes their religion my business. The same for these people.

 

Let's see who's subbed to this /c/...

All of a sudden everyone was gone and moved over to tenforward@lemmy.world, what happened?

 

Wife said to me this morning "Running Windows games like that seems unnatural" So of course immediately generated this meme.

 

Hey all, I'm looking to build a couple dashboards out around my house. I've done this before with rokchip boards and they are... fine, but not great. Is rpi the best option right now? Are there alternatives you really like? I'd like to keep it a single board to easily mount behind things where it doesn't take up a lot of space, and I won't lie I like the DIY feeling of it over something like a thin client.

 

Just a few shots of my continuing work in Grassy Fields. Right now we're building out 48 assemblers of motors, and all of the dependencies for that.

When that is done, building the first of turbomotors

view more: ‹ prev next ›