11–20 of 25 posts
Comparing doubles with == ?
Earlier quoted context omitted.
They look fine to me, but I guess it helps that both Python and Rust use the same interpolation style.
Err... do either python or rust allow this style, in both languages I've always used ("lhs=({}, {}); rhs=({}, {})", lhs.x, lhs.y, rhs.x, rhs.y)
"lhs=({l.x}, {l.y}); rhs=({r.x}, {r.y})".format(l=lhs, r=rhs)Earlier quoted context omitted.
They look fine to me, but I guess it helps that both Python and Rust use the same interpolation style.
Err... do either python or rust allow this style, in both languages I've always used ("lhs=({}, {}); rhs=({}, {})", lhs.x, lhs.y, rhs.x, rhs.y)
> ("lhs=({}, {}); rhs=({}, {})", lhs.x, lhs.y, rhs.x, rhs.y)
Python 3.6 added "natively interpolated" f-strings, just replace C#'s `$` prefix by `f`, and even without f-strings you could write e.g.
"lhs=({lhs.x}, {lhs.y}); rhs=({rhs.x}, {rhx.y})".format(lhs=lhs, rhs=rhs)
Comparing doubles with == ?
I'm not versed in C#, what should you use otherwise?
(I feel a little silly saying "it's not a language thing" and then "in python", but there may (or may not) be various implementation details which other languages might use to get a different result.)
Earlier quoted context omitted.
Err... do either python or rust allow this style, in both languages I've always used ("lhs=({}, {}); rhs=({}, {})", lhs.x, lhs.y, rhs.x, rhs.y)
Python added "f strings" recently (read: in 2015)[1], which look like f"{some_var}" which evaluates "some_var" in the local scope. Sort of like Ruby's "#{...}" (if I'm remembering that syntax correctly). Rust supports named parameters in format strings[2] but that's not quite the same. [1]: https://www.python.org/dev/peps/pep-0498/ [2]: https://doc.rust-lang.org/std/fmt/#named-parameters
some_var = ...
"{some_var}".format(**locals())
Comparing doubles with == ?
[0] https://randomascii.wordpress.com/2012/02/25/comparing-float... [1] https://randomascii.wordpress.com/2017/06/19/sometimes-float...
> Tests that only fail in CI are really annoying. I’ve had this a couple of times, and it’s always taken hours to sort out, because the “try something, get results, think about what they mean” cycle is so slow. To address this, CircleCI has an interesting feature where you can enable SSH access to the build, so one can investigate locally (relative to the build) instead of repeatedly throwing code over the wall and w…
[1]https://docs.travis-ci.com/user/running-build-in-debug-mode/
I traced down the logic, added some debugging print statements, and it magically fixed itself.
Eventually, I figured out the issue that they were comparing floats with == and intel processors have a few extra internal bits that disappear when stored. Macos, which uses floats in its UI layer, defaults to adding -ffloat-store to the compile flags to get around similar issues.
I ended up just adding -ffloat-store to our Linux build of pdftotext. (I briefly thought about fixing the comparisons, but it turned out the code was full of them.)
Comparing doubles with == ?
That's absolutely fine if they are set with explicit values or were assigned with the same double. The main issues used to be with the old x86 80 bit wide floating point registers which meant you could sometimes find x != x depending on whether the number went to memory and back.
If you find some reason to use a NaN inside one of these GeoPoints (at one of the poles, perhaps), and the equality of them depends on the equality of doubles, then you may give your users a bit of a surprise.
Earlier quoted context omitted.
Err... do either python or rust allow this style, in both languages I've always used ("lhs=({}, {}); rhs=({}, {})", lhs.x, lhs.y, rhs.x, rhs.y)
I was mostly talking about the placeholders (hence style ), but > ("lhs=({}, {}); rhs=({}, {})", lhs.x, lhs.y, rhs.x, rhs.y) Python 3.6 added "natively interpolated" f-strings, just replace C#'s `$` prefix by `f`, and even without f-strings you could write e.g. "lhs=({lhs.x}, {lhs.y}); rhs=({rhs.x}, {rhx.y})".format(lhs=lhs, rhs=rhs) Rust supports named parameters but IIRC not attribute access or method calls.