CodeSOD collection
-
@BernieTheBernie said in CodeSOD collection:
@Zecc That was the solution. At 21 occurences...
-
@BernieTheBernie said in CodeSOD collection:
@Bulb Only one. Imagine there were 2 parameters...
Or ... oh I do not want to imagine ...POST
@Gribnit said in CodeSOD collection:
But if the ID isn't on the URL, how will the intermediate servers cache it?
The code appears to be client-side code as global object named
window
, with a propertylocation
, is most commonly found in the in-browser javascript host.So … the ID would have to go to some actually appropriate place like a cookie or the text of the page, oh, horrors!
If it actually is a server-side code, there is a lot more wrong with it.
-
@izzion said in CodeSOD collection:
@BernieTheBernie said in CodeSOD collection:
@Zecc That was the solution. At 21 occurences...
So Jim's "Practical Functions 101" course is scheduled for next semester?
: "But, Bernie, look: JavaScript is just hardly ever used in our product. Why would you want to waste such a lot of time for some training?"
(Nota bene, Jim prevented with such argumentation some WPF/MVVM training, and voilĂ , it was exactly that part which delayed shipping of our software, and is still the crappiest part of our software. Consequences: none. Because he is 's buddy since they were at university.)
-
@BernieTheBernie
If you don’t know your job duties, be sure to know your boss.
-
@Bulb for context, window.location is how client side code asks for the current page URL as in the location bar. So it’s asking for the bare URL as in the browser and hoping for the ID as the first parameter. Which has a fair chance of being correct because users don’t generally type in URLs like that.
-
Wednesday started greatly. As usual, Bernie run the UnitTests (including integration tests) locally before writing the first line of code: get a baseline on the number of failed tests. Not all tests are run on Jenkins, some because they were once thought to be run on a nightly build only (which does not exist - a project idea failed in early 2018 due to Fritz), others are malconfigured that they won't run there but still can be run with ReSharper's TestRunner locally.
OK. 25 failures.
are they so many today after 3 failures on Monday evening?
Ah, Jim checked some fresh code in, he added 22 failures in one batch.What's the situation on Jenkins?
The project is ... disabled. Since yesterday noon. After a failure.Instead, there is a new Jenkins project replacing it:
Sic:NoTests
.By the way, failing tests won't cause a failed build - only "UNSTABLE".
Consequently, the failure was not in the tests.
We have one project which must be built against an old .Net framework version, but which uses code from the current solution. So, again some version incompatibilty happened in that part. The Jenkins log file tells that.Obviously, also this legacy build is excluded from the "NoTests" build...
Since my cow-orkers except Fritz hardly ever touch Jenkins, I guess it was Fritz to do that change. He is the Head of Software and Quality Departments.
Well done, Fritz: that's how we maintain quality.
-
@BernieTheBernie said in CodeSOD collection:
MyClass x = MyClass.Create();
This allows for many options that direct "new" does not.
-
@BernieTheBernie said in CodeSOD collection:
WPF/MVVM training
Utilized FULLY, WPF is a complete mind/paradigm shift. When the rright people (with the right training) utilize it, the results can be amazing. Alas the ability to totally FuBar it is very high if a person has not adopted the proper approach. (and yes, I did use a singular "The").
-
@TheCPUWizard said in CodeSOD collection:
@BernieTheBernie said in CodeSOD collection:
MyClass x = MyClass.Create();
This allows for many options that direct "new" does not.
It does - this also means the caller has no real guarantees as to object uniqueness, let alone its concrete class. But as long as they know what they can expect that usually doesn't matter.
-
@Gribnit said in CodeSOD collection:
they know
-
@BernieTheBernie said in CodeSOD collection:
@Gribnit said in CodeSOD collection:
they know
All
(Integer) 2
in Java are the same instance (for instance (of an instance (which shows how rarely it matters to know)).
-
Bernie opened a web page and an element showed "Loading...". And stayed at "Loading...".
is happening here? Use theInspect
context menu of Firefox. Aha, a JavaScript. It starts with:if ('true' == "true")
Really?
-
@BernieTheBernie Does the web page look like it's generating that javascript?
-
@BernieTheBernie said in CodeSOD collection:
Bernie opened a web page and an element showed "Loading...". And stayed at "Loading...".
is happening here? Use theInspect
context menu of Firefox. Aha, a JavaScript. It starts with:if ('true' == "true")
Really?
I guess something that tried to fingerprint the JS engine would do shit like that.
OK, that and morons.
-
@BernieTheBernie said in CodeSOD collection:
if ('true' == "true")
Really?
That seems like code generated by a tool.
-
-
What a funny C# quirk!
float targetY = _currentY + m_ScanParameters.RowHeight; if (targetY > m_ScanParameters.Top) { Logger.LogInfo(Name, $"Cut-off at top of panorama: tried to drive to {targetY}, will cut off to {m_ScanParameters.Top}."); targetY = m_ScanParameters.Top;
results in many log entries:
Cut-off at top of panorama: tried to drive to 19, will cut off to 19.
19
is greater than19
?
All those values arefloat
.
Where are they floating along?The operator is
>
, it is not==
which is known to have some near-miss issues with floating point numbers.And note that there are no format specifiers given - so
targetY
should be shown as something like19.000000213
if it was actually more than19
(the latter was configured to that number without any decimals).
-
@BernieTheBernie Oh, let me just write a UnitTest:
[TestMethod] public void WtfTest() { float bottom = -51; float top = 19; float rowHeight = (float) ((top - bottom) / 3.0); float line1 = bottom + rowHeight; float line2 = line1 + rowHeight; float line3 = line2 + rowHeight; Assert.IsFalse(line3>top, $"WTF: line3={line3} is greater than top={top}."); }
Guess what.
It fails.
Message:
Assert.IsFalse failed. WTF: line3=19 is greater than top=19.
-
@BernieTheBernie
When printed with 50 decimals, both numbers show up as19,00000000000000000000000000000000000000000000000000
.But when you calculate their difference with
float diff = line3 - top;
and print that at 50 digits, it yields0,00000190734900000000000000000000000000000000000000
.
-
@BernieTheBernie The problem is probably that there is rounding in printing of the values. Doing the computation interactively (with
double
s, in Python) produces comprehensible answers (line3
is about a small number of ULPs lower thantop
).
-
@BernieTheBernie said in CodeSOD collection:
The operator is
>
, it is not==
which is known to have some near-miss issues with floating point numbers.All of those operators have the same problem when the two sides are very close to each other, because floating point numbers are properly uncertain (each value actually represents a range, with the true value within that range, and some operations to combine them can compound the error in the range wrongly if you're not careful).
-
@dkf When I debug the test code,
line3
is19.0000019
in the "Locals" window.
But does a format provider in the message (i.e.{line3:n50}
) cause rounding to something else?
-
@BernieTheBernie said in CodeSOD collection:
But does a format provider in the message (i.e.
{line3:n50}
) cause rounding to something else?It's float printing. It's best assumed to be hokey by default. (There are a few good float printing algorithms out there, but I've no idea if .NET uses any of them. It's a much harder problem than it appears at first glance.)
-
@BernieTheBernie said in CodeSOD collection:
What a funny C# quirk!
Not a C# quirk. As @dkf rightly says, it's a floating point quirk.
Also, all documented:
(https://learn.microsoft.com/en-us/dotnet/api/system.single.equals)
(https://learn.microsoft.com/en-us/dotnet/api/system.double.equals)
-
@Applied-Mediocrity Not completely. Because
When printed with 50 decimals, both numbers show up as 19,00000000000000000000000000000000000000000000000000.
and
When I debug the test code, line3 is 19.0000019 in the "Locals" window.
You see: sometimes, C# (or at least VS?) can do these things right.
-
It can't be a C# quirk, because it compiles to 8087 instructions that are supposed to comply with the standard.
BitConverter.GetBytes()
and compare. Either they're not equal or you've discovered FDIV 2: Floating Boogaloo.What it prints is irrelevant. Do not ever compare floating point numbers using the built-in operators.
-
@Applied-Mediocrity said in CodeSOD collection:
What it prints is irrelevant.
What it prints is the quirk here. In fact it looks like a bug.
@Applied-Mediocrity said in CodeSOD collection:
Do not ever compare floating point numbers using the built-in operators.
For inequality it is perfectly fine to compare floating point numbers using the built-in operators. Including in this specific case. The code is doing what it is supposed to do. It is the message that is a problem. It shouldn't be printing 19 when the value is actually 19.0000019.
-
@Applied-Mediocrity said in CodeSOD collection:
because it compiles to 8087 instructions
things should use the SSE/AVX/whatever instructions nowadays.
-
@topspin said in CodeSOD collection:
@Applied-Mediocrity said in CodeSOD collection:
because it compiles to 8087 instructions
things should use the SSE/AVX/whatever instructions nowadays.
It compiles to whatever instructions implement the virtual machine model required. I would tend to trust that it is handling
+
,-
and>
correctly, since doing the right thing is much easier than doing the wrong one in this case. Printing being wrong is so common it's almost axiomatic.
-
@dkf said in CodeSOD collection:
Printing being wrong is so common it's almost axiomatic.
But no printer device was involved - that would go to a different thread
-
@Applied-Mediocrity said in CodeSOD collection:
BitConverter.GetBytes() and compare.
top
: 0-0-152-65
line3
:1-0-152-65
Yes, there's a difference in the frist byte.
-
@BernieTheBernie So it's one ULP different; it's off by the least amount that the type can measure. This is unsurprising, and part of why people say to beware of floating point errors.
-
@dkf said in CodeSOD collection:
@BernieTheBernie said in CodeSOD collection:
But does a format provider in the message (i.e.
{line3:n50}
) cause rounding to something else?It's float printing. It's best assumed to be hokey by default. (There are a few good float printing algorithms out there, but I've no idea if .NET uses any of them. It's a much harder problem than it appears at first glance.)
Python is a very notable exception for trying to print the correct value—where correct means shortest decimal representation that will parse back as the same binary value. It is quite a difficult algorithm indeed.
-
@Bulb said in CodeSOD collection:
Python is a very notable exception for trying to print the correct value
There are a few languages/runtimes that do it. Python was not the first (I've checked the chronologies; Python's fix was in about 2009 and Tcl had the fix for this in production releases several years earlier as it was in 8.5 which initially released in 2007). I remember there being fun () with values in this area that sent the code to serialize them into an infinite loop, and being very happy to find out that Tcl already had them as test cases!
I've got this feeling that someone told me that glibc gets it right nowadays. I'm not enough of a FP expert to even know how to test it properly.
-
@Bulb said in CodeSOD collection:
Python is a very notable exception for trying to print the correct value—where correct means shortest decimal representation that will parse back as the same binary value. It is quite a difficult algorithm indeed.
And Microsoft seems to have an implementation of that algorithm: when the value is shown in the "Locals" window of the VisualStudio debugger.
But it "forgets" that algorithm in different contexts.
-
@BernieTheBernie BFYTW
-
@BernieTheBernie c# (.Net framework) used to round after a 16 or so digits (on doubles), but they changed that in dotnet core 3+ so that it now roundtrips: parsing the ToString of a double results the same bytes.
Lots of fun, fixing unittests that compared the ToString value of a double, when suddenly 0.999999999999999997 is not printed as "1" anymore
-
@robo2 said in CodeSOD collection:
they changed that in dotnet core 3+ so that it now roundtrips: parsing the ToString of a double results the same bytes.
But does it produce the minimal representation? It's minimality that's difficult.
-
@dkf said in CodeSOD collection:
But does it produce the minimal representation? It's minimality that's difficult.
I don't know of the top of my head, and the is too strong in me, else I would have dug up the issue/pr on the dotnet github repo where they discussed the algorithm used...
-
And there's the "round trip" format specifier:
In some cases, Double values formatted with the "R" standard numeric format string do not successfully round-trip if compiled using the /platform:x64 or /platform:anycpu switches and run on 64-bit systems. See the following paragraph for more information.
-
@BernieTheBernie said in CodeSOD collection:
In some cases, Double values formatted with the "R" standard numeric format string do not successfully round-trip if compiled using the /platform:x64 or /platform:anycpu switches and run on 64-bit systems. See the following paragraph for more information.
The only cases that I'd forgive them having that sort of BS for are anything to do with NaN, because that stuff's bizarre at best. For any other value, that sort of thing is a really nasty gotcha.
-
@dkf Yes.
I did a side-by-side comparison, and this is the shit you get depending on the .net runtime environment
Oh, anddouble.NaN.ToString()
is just"NaN"
.
-
@robo2 It looks fairly sensible. core 3.1 blindly keeps running the algorithm for 99 significant digits, framework 4.8 stops after printing more digits than there is actual accuracy. Inconsistent, but I wouldn't call either wrong.
How the 0x1.300002p+4 (19.0000019) got rounded to 19, even though it's 2 units away from actual 19 though…
-
@robo2 I can live with the stupid
G99
result; you asked for something dumb, you got something dumb. It's just GIGO. The best check is whether counting from from 0 to 10 by steps of 0.1 produces apparently correct results. (It's definitely wrong to do that because of cumulative error, but it is one of the easiest ways to make float printing errors show up.) I found the actual evil test case problem, but it isn't a help as it is somewhere in about a thousand test cases and I'm not going through all that.NaN
is a different type of ghastly because it has processor-specific internal structure. Some processors — including x86 and its successors — don't use that. Others do. (They are, naturally, all not equal to each other or even themselves.)
-
@Bulb dotnet core is doing the same thing as python3 with
format(..., '.99g')
, so if python is doing it right (quoting @dkf), then apparently dotnet core is doing it right as well.
All I actually care about is that with dotnet there is a difference based on the dotnet runtime, which is very annoying if you need support both...
-
C# 11 welcomes us. Wow! A Great New Version of C#.
I must use it now! It's unbelievably great!
Just look at this small excerpt:
var raw2 = """""I can do ", "", """ or even """" double quotes!""""";
Any old VB6 or Windows shell programmer will become envious of such amounts of
"
.
I need it! URGENTZ! I can no more live without that!
-
Yeah, I'm not sure I can justify that one other than pure laziness escaping quotes.
required
members seems nice though. Glad to see it's a contextual keyword, so it probably isn't going to cause much havoc on existing code.
-
@Zecc said in CodeSOD collection:
required members seems nice though.
I agree. In conclusion, you get a ton of shit shipped with 1 good item. Business as usual.
-
-
@Gribnit said in CodeSOD collection:
Wait, no, I use Java.
- We're looking for a programmer on Java
- What's the salary?
- Good. Starting 100 thou.
- Whoa!
- But why on a motorbike?