2

A very strange, presumably meant to be helpfull behaviour of Visual Studio 2012. When I enter a double in vb.net like:

Dim myD as Double = 1.4

When I hit enter of move my focus another way, the formatting kicks in and changes the above to:

Dim myD as Double = 1.39999999999999998

or 1.6 as

Dim myD as Double = 1.6000000000000001

This behaviour does not appear to happen for all doubles. 1.3, 1.5, 1.7 and 1.8 See this youtube movie for the behaviour in action: http://youtu.be/afw4jg58-aU

Why, and more important, how can I prevent this?

Edit:

Extensions installed are: enter image description here

Second Edit

The behaviour seems to have gone away. I do not know what has caused this so for future reference this is useless to anyone, but for now, I'm happy that I don't have to go troubleshooting as suggested.

Daniël Tulp
  • 1,745
  • 2
  • 22
  • 51
  • What extensions/addins do you have running? – Dan Puzey Mar 05 '14 at 16:21
  • see edit, or is that not what you meant? – Daniël Tulp Mar 05 '14 at 16:30
  • That's the extensions - do you have any Addins (under Tools/Addin manager)? – Dan Puzey Mar 05 '14 at 16:36
  • no, no addins installed – Daniël Tulp Mar 05 '14 at 16:41
  • 1
    I'm not sure why VS is changing the values when it reformats the code. I've not seen that before. Perhaps it is a setting that you can change in the options. However, the explanation is that the value 1.4 cannot be stored exactly in binary floating point. Since it cannot represent that value exactly, it uses the closest approximation which is 1.399999999999999911182158029987476766109466552734375 when stored as a double. – Chris Dunaway Mar 06 '14 at 16:32
  • Thanks Chris Dunaway, that explains it. Now to find a solution to this annoying behaviour. – Daniël Tulp Mar 10 '14 at 07:13
  • Is it possible to use a Decimal (fixed point) rather than Double (floating point)? See [this post](http://stackoverflow.com/questions/22203184/visual-studio-2012-adds-numbers-to-my-double-values-if-i-enter-them-in-vb-net) – Jim Wooley Mar 11 '14 at 14:23
  • @JimWooley the link is pointing to this question – Daniël Tulp Mar 12 '14 at 11:32
  • 1
    @DaniëlTulp thanks, it should have pointed to the [question on picking between Decimal and Double](http://stackoverflow.com/questions/1165761/decimal-vs-double-which-one-should-i-use-and-when). – Jim Wooley Mar 12 '14 at 13:28
  • @JimWooley a very useful link, thank you – Daniël Tulp Mar 13 '14 at 12:17

2 Answers2

5

The exact same issue is also reported in this question. Which applied to VS2010, otherwise without a usable answer.

This is an environmental problem, code is getting loaded into Visual Studio that messes with the FPU control word on your machine. It is a processor register that determines how floating point operations work, it looks like this:

enter image description here

The Rounding Control bits are a good source of trouble like this, they determine how the internal 80-bits precision floating point value is truncated to 64-bits. Options are round-up, round-down and round-to-nearest. The Precision Control bits are also a good candidate, options are full 64-bit precision, 53 and 24 bits.

Both VS2012 and the .NET Framework rely on the operating system default, with the expectation that this will not change afterwards. Pretty hard to diagnose trouble arises when code actually does change it, your observation strongly fits the pattern. The most common troublemakers are:

  • code that uses DirectX without the D3DCREATE_FPU_PRESERVE option. DirectX reprograms the precision and rounding control bits to squeeze out a bit more perf.

  • code that was written in an older Borland language product. Its runtime library initializes the FPU control word in a non-standard way. Otherwise a generic problem with software that relies on old runtime library or an old legacy initialization that was carried through in later releases.

  • in general, any code that uses a media codec or media api. Such code tends to reprogram the FPU to squeeze out perf for the same reasons that DirectX does. Especially notorious in a product I worked on which uses such codecs heavily. The codebase was peppered with calls that reset the FPU control word after making a call into external code.

Finding and eliminating such code can be very difficult. DLLs get injected into another process by a large variety of well-intended malware. The SysInternals' Autoruns utility can be very useful, it shows all the possible ways code can be injected with an easy way to disable it. Be prepared to be shocked at what you see and readily disable stuff that doesn't carry a Microsoft copyright.

For dynamic injection, you'll need a debugger to see what is loaded into VS. Start VS again and use Tools + Attach to Process to attach to the first one, selecting the unmanaged debugger. Debug + Windows + Modules shows you what DLLs are loaded. Do beware that the DLL can be transient, a shell dialog like File + Open + File will dynamically load shell extensions into VS and unload them again afterwards. Good luck with it, you'll need it and sometimes the only fix is a rather drastic one.

Community
  • 1
  • 1
Hans Passant
  • 922,412
  • 146
  • 1,693
  • 2,536
  • Wow, great explanation. Unfortunately for future reference, the problem seems to have resolved itself, see my second edit. – Daniël Tulp Mar 12 '14 at 11:33
  • Not sure what to do with acceptance and bounty though. The bounty you deserve for such an elaborate and presumably correct answer (the theory is beyond my skills to comprehend). But do I accept your answer if I award you the bounty? – Daniël Tulp Mar 12 '14 at 11:38
  • Well, clearly it is too late to verify the answer so don't accept it. What you do with the bounty is entirely up to you. – Hans Passant Mar 12 '14 at 12:09
0

I had the exact same issue with Visual Studio 2012.

The "solution" if it happens to you is:

  • write your number in your code

  • let VS screw it up, e.g. when you move to another line

  • CTRL-Z to revert VS mess

  • continue writing your code

Pragmateek
  • 13,174
  • 9
  • 74
  • 108
  • this indeed works, but for me, on reopening the document after closing VS or the solution, the numbers got messed up again – Daniël Tulp Nov 11 '14 at 08:49
  • @DaniëlTulp Strange I can't reproduce this. When reopening the file the value is OK. Only when I edit it, e.g. by creating a new line, I have the problem as expected, and CTRL-Z again fixes it. – Pragmateek Nov 11 '14 at 12:34
  • it has been a while since this problem occurred for me, perhaps updating your system will help – Daniël Tulp Nov 11 '14 at 13:35