.NET | Ira Lukhezo's blog

Presently, I am working on a scientific application, and have been creating some data tables. A request was made to me to ensure that some data columns be rounded to 3 significant figures e.g.

10.1234 becomes 10.1

10.7335 becomes 10.7

1.1003 becomes 1.10

I thought through this request with nonchalance at first, but was surprised just how difficult and time consuming it turned out to be to fulfil. After trying out many examples on the interwebs, including some lengthy code libraries, the solution was simplicity itself, using the .NET string format modifier G0 where the number after G is the number of significant figures desired, so

Console.WriteLine((10.12345).ToString(“G3”));

Will give you a result of 10.1

This works fine and as expected, but the bug is when you have 10.0, what is output to screen is 10

After traipsing through numerous articles, the result was that this behaviour was “by design”. After communicating this “by design” feature to my boss (and numerous scientists), their retort was that it was a bug and ought to be corrected. The reason why they were so annoyed was because the missing trailing zero indicates a level of accuracy that is an unacceptable omission in their field, thus I was advised to prefer two decimal places instead.

One of the first rules you are taught as a new programmer, is that numbers in computer programs are zero based i.e. you start counting at zero because zero is a number, so why in this case are the .NET framework designers ignoring the zero? One must say that one concurs with this being a bug, and wish the framework library team could correct this behaviour, to save developers polluting their codebases with conversions to strings and back to numbers, just so one can present data in a way that is meaningful to mathematically based users.

Update 21 July 2009

All of a sudden, traffic to this post in my blog has leapt up again, so I was curious as to why so? If you are running Windows Vista, and have upgraded to SP2, then debugging the .NET source no longer works, full update in this post (jump to today’s date of course).

Update 4 September 2008

The .NET 3.5 SP1 source code has now been made available. The best place to subscribe henceforth and forthwith is the new Reference Source Code Center.

They have also changed the way that symbols are loaded, a tutorial is available here.
Update 20 August 2008 (Original article beneath)

I have just received an Email back from Shawn Burke. This was the question I put to him;

Hello Shawn,

I would like to know if you have any concrete plans for a .NET 3.5 SP1 release that allows us reference to this new update?

Warmest regards,

Ira

And this was his response

Hi Ira –

It’s being worked on, hopefully by the end of the week.

Thanks,

Shawn

Original Article

After wasting an hour or so I have bumped into an annoying limitation of the new Visual Studio.NET 2008 Service Pack 1. When one attempts to load the Symbols you get a messagebox dialogue saying "There is no source code available for the current location"

The reason why is because Microsoft have not posted the correct .pdb files for the .NET 3.5 SP1 release. Don’t waste your time trying to install the Visual Studio QFE which was required when the initial .NET source was released as this does not work – as I’ve just found out. The only place to get information has been Shawn Burke’s blog, but he appears to have turned off comments after someone identified this anomaly. I certainly hope the source will be available soon, because I really needed it today. I will probably install .NET 3.5 on a virtual machine and access the code I need to that way.

There have been some changes to the debugging options like the flat check boxes. This is prior to SP1