With Visual Studio 2019, I just noticed that Windows Forms Designer now names event methods in upper-case. Previously, it was lower-case, which the source code analyzer would complain about. So, I guess it makes me...happy? Sometimes its the little things in life :)

OK, this is sadly nearing obsessional :( I've gone through the effort of decoding every dang bit in the IEEE 754 formats. Near as I can tell, the float->double conversion is doing absolutely what I would expect of it. Though, it is still yielding a result that has the appearance of being worse. I'm currently baffled...maybe double.ToString() is the culprit? Maybe its something else entirely? I'm going to give this a whole lot more thought tomorrow...at a decent hour. Though, since it has no practical impact on anything I'm actually doing, I should probably let it go. Regrettably, intellectual curiosity has a firm hold of me at this point :) Below you'll find the output from my latest program, where I enter the text "123.456". "Single" / "Double" are conversions from the results of decimal.Parse. "Single (direct)" / "Double (direct)" are the results of float.Parse/double.Parse. The remainder are the indicated conversions of the results of a float.Parse.

Single: Sign=0, Exponent=6 (10000101), Significand=7793017 (11101101110100101111001)
123.456
Single (direct): Sign=0, Exponent=6 (10000101), Significand=7793017 (11101101110100101111001)
123.456
Double: Sign=0, Exponent=6 (10000000101), Significand=4183844053827191 (1110110111010010111100011010100111111011111001110111)
123.456
Double (direct): Sign=0, Exponent=6 (10000000101), Significand=4183844144021504 (1110110111010010111100100000000000000000000000000000)
123.456001281738
float->double: Sign=0, Exponent=6 (10000000101), Significand=4183844144021504 (1110110111010010111100100000000000000000000000000000)
123.456001281738
float->decimal->double: Sign=0, Exponent=6 (10000000101), Significand=4183844053827191 (1110110111010010111100011010100111111011111001110111)
123.456

After this much effort, I guess I'll eventually be forced to write an article on every useless bit of trivia I can find about all of these formats :)

I conducted some more rigorous experiments. This explanation doesn't match the experimental evidence. I now feel somewhat certain, based on evidence from a million randomly generated numbers, that there is something uniquely, and inexplicably, terrible about float->double conversions. I qualify it with "somewhat", because I refuse to be completely wrong, about the same thing, twice in a single day :)

I finished my new tests and updated my original post to include the results. I stand by my original premise. There is something uniquely, and inexplicably, terrible about float->double conversions. The test randomly generated 1 million numbers with between one and six digits of precision. Of the six possible floating-point conversions, only the ToString for float->double ever differed from the "expected" text. It did so a whopping 750,741 times. I beleive this is what they call "statistically significant" :)

Yeah, we cross-posted. I had already retracted my...I'll call it "point"? Regrettably, I misinterpreted the IEEE 754 specification. I can only wish that I realized my mistake before posting :) That said, I still suspect there is something less than ideal ocurring with the float->double conversion. I'm working on some code to more rigorously explore the issue. I'll either prove or disprove my suspicions. I'll come back later and post whatever I find.

Based on my misinterpretation of the IEEE 754 specification, which I foolishly shared in a response to Richard, it seems today is a day full of surprises for me :) That said, I would not expect converting from IEEE 754 binary32 to binary64 would make things apparently worse. I tried a bunch of different values. Of the six possible floating point conversions this one consistently yields the worst apparent outcome. If anything, I would have expected converting binary64 to binary32 to have the worst apparent outcome.

UPDATE: Seems I'm simply wrong on my point below. I was misled by some less than clear wording in one part of the specification. That said, I still find it odd that float->double is the only one of the six possible C# floating-point conversions that is consistently less accurate in its apparent result. I tried a bunch of different values with this same consistent outcome. Something seems wrong to me. I do understand your point. It is a great generalized warning for those unwilling to learn the specifics of the precise floating-point data type they are using. If I were using something other than an IEEE 754 binary32 data type (float), or using more than six significant decimal digits, I would completely agree with you. However, since neither of these are the case here, I respectfully and completely disagree. The behavior is simply inconsistent with the IEEE 754 specification. The specification of binary32 provides 23 explicit bits for the significand. This provides accuracy for a minimum of six significant decimal digits. The specification explicitly details that the representation of this number of significant decimal digits (six or less) must be exactly accurate. In the case of binary64, which has 52 explicit bits for the significand, the specification requires accuracy to a minimum of 15 significant decimal digits.

UPDATE #2: After going back to my original test number, and decoding it (literally) bit-by-bit, in each of the formats, before and after conversion, I'm baffled. The float->double conversion does exactly what I would do. This makes it even more difficult to explain the outcome of my earlier test programs. The conversion itself seems accurate, but I'm clearly missing something. So, for now, I'm abandoning this post. I'll come back and update it when I answer my own question. Though, that will probably be after I write an article explaining the ridiculous trivia of exactly what C# does with each of the floating-point formats. After which, I've really got to get a life :) UPDATE #1: After further consideration, I reassert that there is something uniquely, and inexplicably, terrible about the float->double conversion! Some have suggested that this was something inherent with how floating point numbers are stored and not something uniquely terrible about float->double conversions. After a little bit of convincing, I concede that my original description did not exclude this possibility. While I intentionally chose a number with six decimal digits of precision (the limits of IEEE 754 binary32), perhaps unintentional bias led me to choose numbers that were particularly susceptible to this issue. So, to disprove my original premise, I wrote a new test program (included at the end of this post). This program generated random numbers with between one and six digits of precision. To avoid bias towards any one of the three floating-point formats, it calculates the "ideal" text from an integral value using only string manipulation to format it as floating-point. It then counts the number of times the ToString for the assigned values (decimal, double, and float) and converted values (decimal->double, decimal->float, double->decimal, double->float, float->decimal, and float->double) differ from this ideal value. After running the program for 1 million cycles, the results were as follows: decimal: 0 double: 0 float: 0 decimal->double: 0 decimal->float: 0 double->decimal: 0 double->float: 0 float->decimal: 0 float->double: 750741 I reassert that there is something uniquely, and inexplicably, terribl

First, congrats on finding a place you're happy! And no, its not just you. I think anyone who lasts long enough in this industry eventually encounters one of those jobs. My advice, when its good cherish it! That's a rare thing nowadays. When it gets bad enough to negatively impact your life, flee immediately! The tricky part is recognizing when its bad enough. Often, you get a honeymoon period with a new job. Other times, you start with great management, but they leave...only to be replaced by terrible management. In either case, inertia usually casts you in role of the "frog" in that Boiling frog[^] metaphor :) Despite being around the block more than a few times, I've never quite learned how to avoid that. At best, I've reduced the lag time between its onset and my departure to about a year.

Unfortunately, it causes quite a bit of grief. The example I provided was the shortest code I could write to share my pain. Thank you for your thought, but not hoping for an actual solution here...simply ranting :) Regrettably, the actual problem is a lot more complex. It also involves collection initializers, method signature ambiguity, and the entire zoo of built-in numeric data types. I'm helping consumers of a framework avoid the detritus added by explicit casts / constructor invocations. I already have a solution...a separate method signature for each data type (in my code). Its not a huge deal, simply repellant to look at. It also snowballs a bit, to a few places, and forces me to carry test cases for each one. If C# had a different precedence for implicit/explicit, a far more elegant solution would be possible. That, and honestly, it annoys me that it favors an implicit convenience over something I've told it explicitly NOT to do.

Usually, I'm a big fan of C#. Today it's irritating me a little bit :( I have a case where I would like to perform an implicit conversion for my class when a double is assigned to it, but not do one for an int. Yeah, I know, its an odd requirement! Suffice to say, it would make my life a little simpler, if I could get away with it. Initially, it seems like C# should allow me to do it. If I mark the operator for int as explicit, I get the error I want. Regrettably, when I then add the operator for double, which is implicit, the error goes away. I do understand why, and understand that C# "is-what-it-is", which is usually a good thing. However, today, I truly wish the explicit operator took precedence over the implicit operator! Oh well, there are plenty of work-arounds, but they end up being far less elegant in this particular code base. For your consideration, here's a code snippet that demonstrates the behavior. Comment out the line with the implicit operator and you get the error I want. Without it, the integer gets implicitly converted to a double and uses that operator, so no error.

namespace ExplicitOperator
{
public class Program
{
public static void Main(string[] args)
{
int value = 5;
Test test = value;
}

public class Test
{
  public Test(double value) => Value = value;
  public Test(int value) => Value = value;
  public double Value { get; }
  public static explicit operator Test(int value) => new Test(value);
  public static implicit operator Test(double value) => new Test(value);
}

}
}

Its undoubtedly an alien's social media post sharing the details of a recent snack.

Aye, 'twas pirated from a bot :)

I'm lucky, no matter what I do, I never reduce the number of naked international fashion models surrounding me. So far, that number has held steadily at zero. I've never experienced even the slightest reduction :)

The true Turing or simply someone pretending to be him? :)

Awesome signature, Okie :)

It's a journey, not a destination :)

Extra credit for using both "grok" and "xyzzy" in a sentence. Mr. Peabody apparently fired up the Wayback Machine for you! :) Fun game, back in the day. I spent countless hours lost in those twisty little passages. As a result, xyzzy.txt remains one of my go-to names for a temporary/junk file.

Marc, you do have a true talent for understatement...a "little closer"...still chuckling over that one :)

I don’t think the average person, myself included, can ever fully understand the magnitude of this accomplishment. In fact, the quantities involved are so far beyond the human experience, I suspect even the mission scientists and engineers struggle to truly visualize them. First, consider the distance. Assume you wanted to emulate this trip. So, you decide to continually fly round-trip from New York to Sydney, until you equal the distance. Bad news here. It would take over 200,000 round-trip flights. Assuming you fly one leg of this round-trip, every single day, you would be flying for a bit over a thousand years. The good news is that, if you’re willing to wait that long, you’ll save a bit on the trip. At around $200M for the commercial flights, you’d beat the $700M price tag for New Horizons :) Next, consider the navigation. Imagine you fire a bullet moving about 20 times as fast as the average rifle round. Your target is a different fast-moving bullet. Finally, make the problem a bit more difficult by requiring that you ricochet off two other fast-moving bullets on the way. Oh, and don’t forget that distance we talked about earlier. Simple right? Then, consider the engineering. You decide to build a contraption that can accomplish almost all of these goals. Though, at that point you’re “only” aiming at that second bullet. You haven’t decided you’ll ricochet off of it yet. So, you plan and lobby, lobby and plan…for a couple of decades. Then, you get permission (and funding) to actually build the thing. A few years later its built and launched. Yeah! Success, right? Nope, you get to wait, and watch it travel, and wait…for an additional decade. Along the way, you decide that second ricochet would be really cool! You even find another bullet to hit. Finally, decades later, if you’ve got the patience, and are still around, you get to enjoy the payoff. All done right? Maybe. They’re talking about another ricochet and another bullet :) Personally, I am in awe of this accomplishment. And, more, as an engineer myself, the patience it must require to begin a project that might not be completed until after you’re gone. Kudos, NASA! Home run on this one! Now, can we talk about that Lunar Orbital Platform-Gateway? Are you sure about it? Can I talk you out of it, please? :)