Weird variable behavior that I cannot explain

[hanness]

I have a really odd issue happening with variables. I'm 100% sure that is something lacking in my knowledge and not some sort of bug, but I simply cannot figure this out.

I apologize in advance for not providing a simple code example, but the problem I'm describing happens within a fairly large program and is not something I have a simple short example of, although I will try to reproduce it later in some short form.

Near the start of my program I DIM a few variables. This includes these:

DIM Resolution as Single
DIM Shared LowerValue as Single

I ask the user for a value via an input statement and this gets assigned to to "Resolution". Assume the number input is "32".

I then run this line:

LowerValue = Resolution

If I place a test line after the above statement to print the value of "LowerValue" I see that it is indeed "32".

Now, note that NOWHERE else in the program do I ever change the value of "LowerValue". However, if I inspect the value of "LowerValue" later in my code by simply printing the value, it for some reason has changed value to "16". It's possible that it may change to other things, but in my test run where I input an initial value of 32, it gets changed to 32.

Again, nowhere after the initial assignment is this value ever changed!

After hours, on a hunch, I simply changed my DIM statement to this:

DIM Shared LowerValue as Double

Note that I simply changed the "Single" to "Double".

Problem solved. But why?

I know that without some specific sample code it may be very difficult to provide a root cause, but are there any guesses as to what on earth could account for such odd behavior?

[SpriggsySpriggs]

@hanness Have you done a search in your code to see every usage of the variable?

[Pete]

Like Zach said, but you may also want to check and see if you pass parameters to subs and functions by reference. This is probably the second most common cause of this type of unexpected change in variable values, not made by a specific variable statement. The data type, as Indy pointed out, is probably the most common. Hope you find it soon.

Pete

[FellippeHeitor]

With the actual code in hands it might be more precise to offer help.

[RhoSigma]

Sounds like an argument side effect to me, especially as changing the variable type from SINGLE to DOUBLE does solve the problem.

Are you using SUBs/FUNCTIONs in your program ?? -- If so, do you use "LowerValue" in any of these SUBs/FUNCs or maybe even have it as passing parameter in the function's argument list?

[SMcNeill]

I am betting you’re getting sub/function corruption.

For example, run this:

foo = 3
Example foo
PRINT foo

SUB Example (x)
    x = 0
END SUB

Now, nowhere do we actually change the value of foo itself inside the program — yet, it prints a value of 0.

WHY?

Because it’s passed as a parameter of the same variable type and the value is being changed in SUB Example as x.

From what you’re describing, I’d take a guess that you’re having a similar style issue somewhere.

[hanness]

Firstly, yes, I looked very carefully for every instance of the variable and I'm sure that I'm not changing it directly. However, there's a distinct possibility that what Steve is noting is what is happening. I'll take a closer look at my code to see if that is happening.

Could someone clarify the concept of passing by reference a little bit for me? Tell me if I understand this correctly:

If I am passing a value, then the original variable is unaffected, only the value of the variable gets passed to the subroutine into another variable.
If I'm passing by reference, then whatever variable that value is passed to in the subroutine will affect the original since it's basically just a pointer to the original.

Do I have that correct?

If so, how do I know if I am passing the value or a reference? Is the syntax different?

[FellippeHeitor]

If your variable type matches the parameter type, you're passing by reference *always*, unless you enclose the variable in (parenthesis) when you call the procedure.

If types don't match, it's always by value.

[hanness]

Fantastic. I'll look at my code when I'm back in front of the machine where I have it. Almost certainly my misunderstanding of this will be the issue.

[SMcNeill]

Easiest fix, if it is a parameter problem, is just this one:


SUB Example (tempX)
   x = tempX
   ‘And so on
END SUB

You pass to tempX, assign to x, and thus tempX never changes or gets corrupted.

[SpriggsySpriggs]

Yep, that's what I usually do (unless I actually am trying to modify my arguments). I like to copy the value and then make edits. Only matters when using variables rather than literals.

[hanness]

Thanks, gents. I now have my issues sorted and all is working properly.

[Cobalt]

If your careful and use it wisely this can be a useful thing too. but if you don't think about it or watch what your doing, well you know what happens. So don't shun letting the subs and functions change values like that just use it carefully.

[hanness]

Cobalt, thanks for that.

Indeed, I can see perfectly where that would be extremely useful. I definitely understand the implications and where each case would called for.

The irony here is that I have another program that is well in excess of 10,000 lines. I have a bunch of subroutines in that program, but I'm ALMOST always passing string data to them so I've simply not really had to deal with this. I'll have to go over that program to make sure I have no unexpected logic errors that might bite me in the future due to the manner in which I'm passing data to the subroutines.