CodeSOD collection

homoBalkanus

@BernieTheBernie said in CodeSOD collection:

@Zecc That was the solution. At 21 occurences...

The Codeless Code: Case 43 Holes

Bulb

@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 property location, 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.

BernieTheBernie

@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.)

izzion

@BernieTheBernie
If you don’t know your job duties, be sure to know your boss.

Arantor

@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.

BernieTheBernie

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.

TheCPUWizard

@BernieTheBernie said in CodeSOD collection:

MyClass x = MyClass.Create();

This allows for many options that direct "new" does not.

TheCPUWizard

@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").

Gribnit

@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.

BernieTheBernie

@Gribnit said in CodeSOD collection:

they know

Gribnit

@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)).

BernieTheBernie

Bernie opened a web page and an element showed "Loading...". And stayed at "Loading...".
is happening here? Use the Inspect context menu of Firefox. Aha, a JavaScript. It starts with:

if ('true' == "true")

Really?

Bulb

@BernieTheBernie Does the web page look like it's generating that javascript?

LaoC

@BernieTheBernie said in CodeSOD collection:

Bernie opened a web page and an element showed "Loading...". And stayed at "Loading...".
is happening here? Use the Inspect 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.

Zecc

@BernieTheBernie said in CodeSOD collection:

if ('true' == "true")

Really?

That seems like code generated by a tool.

Vault_Dweller

@Zecc

BernieTheBernie

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 than 19?
All those values are float.
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 like 19.000000213 if it was actually more than 19 (the latter was configured to that number without any decimals).

BernieTheBernie

@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

@BernieTheBernie
When printed with 50 decimals, both numbers show up as 19,00000000000000000000000000000000000000000000000000.

But when you calculate their difference with float diff = line3 - top; and print that at 50 digits, it yields 0,00000190734900000000000000000000000000000000000000.

dkf

@BernieTheBernie The problem is probably that there is rounding in printing of the values. Doing the computation interactively (with doubles, in Python) produces comprehensible answers (line3 is about a small number of ULPs lower than top).

dkf

@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).

BernieTheBernie

@dkf When I debug the test code, line3 is 19.0000019 in the "Locals" window.
But does a format provider in the message (i.e. {line3:n50}) cause rounding to something else?

dkf

@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.)

Applied Mediocrity

@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)

BernieTheBernie

@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.

Applied Mediocrity

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.

Bulb

@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.

topspin

@Applied-Mediocrity said in CodeSOD collection:

because it compiles to 8087 instructions

things should use the SSE/AVX/whatever instructions nowadays.

dkf

@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.

BernieTheBernie

@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

BernieTheBernie

@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.

dkf

@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.

Bulb

@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.

dkf

@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.

BernieTheBernie

@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.

Gribnit

@BernieTheBernie BFYTW

robo2

@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

dkf

@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.

robo2

@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...

BernieTheBernie

And there's the "round trip" format specifier:

adegeo

Standard numeric format strings - .NET

In this article, learn to use standard numeric format strings to format common numeric types into text representations in .NET.

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.

dkf

@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.

robo2

@dkf Yes.
I did a side-by-side comparison, and this is the shit you get depending on the .net runtime environment

Oh, and double.NaN.ToString() is just "NaN".

Bulb

@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…

dkf

@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.)

robo2

@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...

BernieTheBernie

C# 11 welcomes us. Wow! A Great New Version of C#.
I must use it now! It's unbelievably great!

Mads Torgersen / Nov 8, 2022

Welcome to C# 11 - .NET Blog

C# 11 is here! Bringing with it some highly anticipated features including string literals, generic math, required members, and much more.

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!

Zecc

@BernieTheBernie

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.

BernieTheBernie

@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

@BernieTheBernie said in CodeSOD collection:

generic math

Ah fuck me.

Wait, no, I use Java.

Applied Mediocrity

@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?