I would say for whether or not your vote really counts it doesn't matter if the party has 20.5% or 0.5%. Each vote counts the same towards the next seat, which may be the first or the twentieth. So I would encourage everyone to vote small parties (except for the crazy ones).
Yup, we are experiencing more extreme weather situations. Until 2022 it was unusually dry, now 2023 and 2024 had relatively more rain, sometimes in a very short timespan causing flooding.
IEEE 754 is the standard to which basically all computer systems implement floating point numbers. It specifically distinguishes between +0 and -0 among other weird quirks.
I don't think I've ever seen a game on Steam with "Overwhelmingly Negative" reviews before. Usually "Mixed" is already a good indicator to leave your hands off a game.
That's wrong, it calculates the surface distance not the distance through the earth, while claiming otherwise. From the geopy.distance.great_circle documentation:
Use spherical geometry to calculate the surface distance between points.
This would be a correct calculation, using the formula for the chord length from here:
python
from math import *
# Coordinates for Atlanta, West Georgia
atlanta_coords = (33.7490, -84.3880)
# Coordinates for Tbilisi, Georgia
tbilisi_coords = (41.7151, 44.8271)
# Convert from degrees to radians
phi = (radians(atlanta_coords[0]), radians(tbilisi_coords[0]))
lambd = (radians(atlanta_coords[1]), radians(tbilisi_coords[1]))
# Spherical law of cosines
central_angle = acos(sin(phi[0]) * sin(phi[1]) + cos(phi[0]) * cos(phi[1]) * cos(lambd[1] - lambd[0]))
chord_length = 2 * sin(central_angle/2)
earth_radius = 6335.439 #km
print(f"Tunnel length: {chord_length * earth_radius:.3f}km")
A straight tunnel from Atlanta to Tbilisi would be 9060.898km long.
Ever since I've understood that it accepts objectively wrong answers as long as it somehow seems as if you gave it some thought, I've made sure to hinder the accuracy of models that try to use my data.
When you import circles in the test file (even if you only select circles_area) the circles file basically gets executed from top to bottom to run all definitions at the point of the import statement. This executes your for loop which fails, and the actual tests are never run. Just remove that loop in the circles module, and it should work.
I must say I like the idea of having changes to files be bound to just the current branch, not the entire worktree (section 6.4.2), but other than that the points that are brought up don't really seem too compelling. It certainly didn't convince me that git has an inherently flawed design.
For example, eliminating the staging area is a tempting point for simplifying git, but the authors already admit that it has some legitimate use cases.
But of course it is always nice to see some experimentation done in this space. I think the main reason why git sometimes is confusing, is because distributed version control really is a complex task, and git already does a very good job at making it tractable.
While there certainly is some overlap, Python is a scripting language and not a shell language. Some tasks that involve calling lots of different programs and juggling input and output streams are much easier done in bash than in Python.
This blog post goes into some specifics of Rust reusing Vec allocations and some of the consequences. I think it's really worth a read to better understand Vecs. From what I understand, it is possible that Rust will reuse the allocation of vec_a in your case, but it ultimately is quite complicated.
THE MORE YOU SAVE