# Visual Basic > Visual Basic 6 and Earlier >  Math with literals when defining "Optional" default values

## Elroy

I just discovered something (by accident) that I didn't know.

When defining the "default" value for an "Optional" argument, you can do math with the literals that define the default:



```

Sub Test(Optional i As Integer = 123 + 456)
    MsgBox i
End Sub

```

One might ask why you'd do this, but I can think of a couple of reasons:

For one, I'm sure this is all resolved by the compiler, so we might want to be clear about how we derived at some default.

And two, the way I accidentally found this.  For the Currency type, there's an Intellisense bug whereby you can't create a literal for the smallest negative value.  Intellisense won't let the following clear syntax checking, even though it's a legitimate value:



```

Const cSmallest = -922337203685477.5808@

```

However, the following does clear syntax checking just fine:



```

Const cSmallest = -922337203685477.5807@ - 0.0001@

```

And here's where I found this "Optional" argument literal math trick:



```

Function Random( _
   Optional ByVal llMin As Currency = 0@, _
   Optional ByVal llMax As Currency = -922337203685477.5807@ - 0.0001@) As Currency

```

IDK, I thought it was interesting.

----------


## dilettante

Literal expressions are pretty much always evaluated ahead for native compilation.  I'm not so sure about p-code in IDE runs though, and compiling to p-code may be a 3rd case.

That Currency case might have more to do with decimal to binary conversion errors than anything else.

----------


## georgekar

The smallest currency is this: -922337203685477.5808
The problem with the evaluator of VB6 is the precedence of the minus sign. Look this: ? -2^2 return -4 because  VB6 first keep the minus sign as unary sign, and then evaluate the characters to number. So this value 922337203685477.5808 (without the -) not exist for Currency (and this for long Long 9223372036854775808 not exist also)
To prove my claim just do this:
? typename(-922337203685477.58@ -0.0008@) you get currency.
? Abs(-922337203685477.58@ -0.0008@) ' overflow - can't convert to positive (exist only as negative).

So the supposed bug who you describe is the only way to place literals which the system can't get with ordinary evaluation.




Using the CCur() you can get the right conversion, but remember to change the decimal point character using this function:  GetDeflocaleString(LOCALE_SDECIMAL).

? ccur("-922337203685477,5808") ' my PC
? ccur("-922337203685477.5808")



```
Public Declare Function GetLocaleInfoW Lib "kernel32" (ByVal Locale As Long, ByVal LCType As Long, ByVal lpLCData As Long, ByVal cchData As Long) As Long


Public Const LOCALE_SDECIMAL = &HE&
Public Function GetDeflocaleString(ByVal this As Long) As String
    On Error GoTo 1234
    Dim Buffer As String, ret&, R&
    Buffer = String$(514, 0)
    ret = GetLocaleInfoW(0, this, StrPtr(Buffer), Len(Buffer))
    GetDeflocaleString = Left$(Buffer, ret - 1)
1234:
End Function
```

----------


## Elroy

> That Currency case might have more to do with decimal to binary conversion errors than anything else.


I'm not sure that's the case or it seems like the following would fail, which it doesn't.  It correctly reports.



```
Option Explicit

Private Sub Form_Load()
    Dim c As Currency
    
    c = CCur(CDec("-922337203685477.5808"))
    Debug.Print c
    
End Sub
```

Or maybe you meant "decimal" in the lower-case sense (as you had it), and not the Decimal type.

----------


## The trick

I suppose the VB-parser just processes the number without sign so it can't cast 922337203685477.5808 to a currency value. The same behaviour you get with -32768%, -2147483648&

----------


## Elroy

> I suppose the VB-parser just processes the number without sign so it can't cast 922337203685477.5808 to a currency value. The same behaviour you get with -32768%, -2147483648&


Oh WOW, I didn't realize the same bug existed for all 2s complement types.  But, at least with Integer and/or Long, you can specify it with hex, which you can't do with Currency.

----------


## georgekar

Also another peculiar thing with Vb6 expression evaluator and the minus sign is this:
A sign after the symbol of power brake the rules;



```
? 2^3^4, 2^+3^4, (2^3)^4, 2^(3^4)
 4096          2,41785163922926E+24        4096          2,41785163922926E+24 
? 2^-3^4, (2^-3)^4, 2^(-3)^4
 4,13590306276514E-25        0,000244140625              0,000244140625
```

----------


## Elroy

> Also another peculiar thing with Vb6 expression evaluator and the minus sign is this:
> A sign after the symbol of power brake the rules;
> 
> 
> 
> ```
> ? 2^3^4, 2^+3^4, (2^3)^4, 2^(3^4)
>  4096          2,41785163922926E+24        4096          2,41785163922926E+24 
> ? 2^-3^4, (2^-3)^4, 2^(-3)^4
> ...


Where are the rules broken?

You're possibly thinking of it in terms of order-of-operation being left-to-right.  However, powers don't work that way.  If you visualize it as superscripts (rather than using the hat symbol), it'll make more sense.  Essentially, when it's only powers, they're executed right-to-left.  Also, negation is a bit different from a negative power.

----------


## wqweto

Power is left associative in VBx contrary to every other language.

----------


## georgekar

> Where are the rules broken?
> 
> You're possibly thinking of it in terms of order-of-operation being left-to-right.  However, powers don't work that way.  If you visualize it as superscripts (rather than using the hat symbol), it'll make more sense.  Essentially, when it's only powers, they're executed right-to-left.  Also, negation is a bit different from a negative power.


Its obvious, because of the unary minus precedence, this line:  ? 2^-3^4, (2^-3)^4, 2^(-3)^4 
The second expression has different result from the first one, but has the same with that: 2^(-3^4)


Here we have right associativity of the exponentiation: 
? 2^-3^4=2^(-3^4)
True
? 2^+3^4=2^(+3^4)
True
?-2^-3^-2^3=(-2^(-3^(-2^3)))
true

Here we have left associativity of the exponentiation (using no signs right after symbol of exponentiation):
? 2^3^4=(2^3)^4
True
? 2^3^2^3=(((2^3)^2)^3)
True
If I am wrong please correct me.

----------


## wqweto

No, you dont have right associativity because there are unary operators in the mix so operator precedence takes place.

The rules in VBx are very simple: for list of same op like val op val op val op val . . . val op val the order is always left to right when op is the same but if you mix operators you get precedence rules applied.

Btw, your experiments show that unary + and - precedence is *lower* than power.

----------


## Elroy

> Btw, your experiments show that unary + and - precedence is *lower* than power.


Isn't that always the case?  I thought powers were higher than negation in the order of operations.  Also, setting aside the negation issue, another way to think about exponents is that they're executed in a top-down fashion (which is essentially right-to-left when using the hat symbol).

Another way to think about negation is to remember that exponents can be fractional.  A fractional exponent of a negative base always takes us into that i (sqrt(-1)) situation.

----------


## georgekar

https://learn.microsoft.com/en-us/do...tor-precedence
Yes, although this is from Net flavor, they keep the same precedence



```
Exponentiation (^)

Unary identity and negation (+, )


Multiplication and floating-point division (*, /)


Integer division (\)


Modular arithmetic (Mod)


Addition and subtraction (+, )
```

----------


## wqweto

From the same link:  Operators with equal precedence are evaluated left to right in the order in which they appear in the expression. so exponentiation is left to right in VB when no parentheses and other operators are mixed which is a simple approach that differs from other languages.

----------


## Elroy

> From the same link:  Operators with equal precedence are evaluated left to right in the order in which they appear in the expression. so exponentiation is left to right in VB when no parentheses and other operators are mixed which is a simple approach that differs from other languages.


Ok, I just tested (egg on my face), and you are correct Wqweto.

And that is *not* the way algebra books say to do it.

----------


## wqweto

No eggs, please :)) Its all good when conundrum is solved.

----------

