Yeah, who would have thought…

> I used it to see what happens with lhm’s suggestion. Clearly VBA does “keep”
> the additional digits around and they appear after the first and second set
> of subtractions in the below code. Then, the third set of subtractions shows
> errors in the least significant digits in the significand.
>
> Public Const AA As Double = “1.7976931348623157E308″

Yes, that does seem to allow you to pump in more precision, but the reason I wrote my comment that started with “Interestingly enough…” was that you cannot do this directly (it produces an overflow error)…

Public Const DoubleMax As Double = “1.79769313486232E308″

I used it to see what happens with lhm’s suggestion. Clearly VBA does “keep” the additional digits around and they appear after the first and second set of subtractions in the below code. Then, the third set of subtractions shows errors in the least significant digits in the significand.

Option Explicit
Public Const AA As Double = “1.7976931348623157E308″

Sub doShow()
Debug.Print “1.7976931348623157E308″ & vbNewLine _
& AA & vbNewLine _
& (AA – 1E+308) & vbNewLine _
& (AA – 1E+308 – 7E+307) & vbNewLine _
& (AA – 1E+308 – 7E+307 – 9E+306)
End Sub

The results are
1.7976931348623157E308
1.79769313486232E+308
7.97693134862316E+307
9.76931348623157E+306
7.69313486231567E+305

Oh, you are going to love this. After I posted my last message, I got to thinking about the way VB coerces values as the need arises. Well, as it turns out, it will coerce a String value to a Currency data type with on trouble. Check this out…

Interestingly enough, the above String method did not work for the Double data type and the value discussed earlier.

The fact that Public Const XX As Currency =-922337203685477.5808@ resulted in a Compile Error really surprises me. However, as is usually the case in VB, there is a way to do this with public constants. Put the following in a Standard Module and run the Test subroutine…

Of course, I have no idea what this should work and using the number directly does not… that one has me scratching my head. Also, the code was tested on XL2003 and XL2007 (which contain VBA Versions 6), but I do not have XL2010 install on my computer, so I do not know if it works in that versions VBA Version 7.

Oh, by the way, the @ symbol at the end of the 0.0001 number is not needed as the code works fine without it, but if I was doing it this way, I would feel more comfortable using it so that I did not have to rely on VB to coerce the value from a double (which is how I think VB sees it) to a Currency data type behind the scenes.

Apparently, the VBE folks also don’t much use it (much). {grin}

As you indicated it works for the maximum currency value. But with the minimum value

Public Const XX As Currency =-922337203685477.5808@

the result is “Compile error: Expected: expression” and the editor selects the part after the minus sign, i.e., 922337203685477.5808@

So, apparently, the editor/compiler is written to first evaluate 922337203685477.5808@ and then get the negative of that value. Unfortunately, the first step yields an unacceptable number.

You can use the @ postfix character to force the assigned number to remain a Currency value…

Public Const xx As Currency = 922337203685477.5807@

The definition of the currency data type is a 64 bit integer scaled by 10,000. Hence, the integer data type classification.

Precision, according to wikipedia (http://en.wikipedia.org/wiki/Significand) is the number of bits in the number. Consequently, for a double it is 53. Maybe, what I called ‘smallest’ might be better called ‘resolution?’ It might fit better with what Nigel describes.

fzz:

Yes, that’s possible. I took some of the initial functions from a class module and VBA does not allow public constants in a class module.

Another problem with the use of a const is that VBE does unexpected and unnecessary rounding (VBA7, Office 2010 32bit). E.g.,

public const xx as currency=922337203685477.5807

becomes

Public Const XX As Currency = 922337203685478#

lhm:

Thanks for the explanation of what could be. Of course, from a practical perspective, since 1.79769313486232E308 in a VBA double raises an overflow error, there’s little choice but to consider the largest value that one can have in a VBA double as 1.79769313486231E308.

…Actually the documentation is correct but the result is rounded to 15sf, The maximum value is ?[2^1023*(2-2^-52)]. This highlights the need for more than 15sf in specifying values, in this case: 1.7976931348623157E308. Note also that VBA uses subnormal numbers for the lower limits but Excel rounds these to zero.