Wrong result return in specific calculation

[dimnik]

Hi, I have the following code, at which I give thought some textboxes the starting and ending values and I do a repeating simple calculation like x=x*10 and then i convert the results in string and break them in single number which I display them in different labels. No when the calculation start from 0 at the point it goes from 0,9 to 1 instead of getting 1 and 0 to two label, I get 0 and one, but with many experiment I have done this occurs only at the specific point. Has anyone got any idea what might be wrong.
Here is the code:

'input of data
x_arx = TextBox1.Text
x_tel = TextBox3.Text
y_arx = TextBox2.Text
y_tel = TextBox4.Text
'calculation of some constants
a = (y_tel - y_arx) / (x_tel - x_arx)
y0 = y_arx - (a * x_arx)
length_x = Math.Abs((x_tel - x_arx) / stp) 'stp is given from the user
For i = 0 To length_x
y = (a * x) + y0
x = x + stp
y_serial = y * 10
x_serial = x * 10

x_serial = Math.Round(x_serial, 0)
x_serial = Convert.ToString(x_serial)
y_serial = Math.Round(y_serial, 0)
y_serial = Convert.ToString(y_serial)
Label23.Text = x_serial
Label28.Text = y_serial
'check the length of the string to avoid error, and fill the remaining number with 0
If x_serial.ToString.Length = 1 Then
Label34.Text = GetChar(x_serial, 1)
Label33.Text = "0"
Label32.Text = "0"
Label31.Text = "0"
ElseIf x_serial.ToString.Length = 2 Then
Label34.Text = GetChar(x_serial, 1)
Label33.Text = GetChar(x_serial, 2)
Label32.Text = "0"
Label31.Text = "0"
ElseIf x_serial.ToString.Length = 3 Then
Label34.Text = GetChar(x_serial, 1)
Label33.Text = GetChar(x_serial, 2)
Label32.Text = GetChar(x_serial, 3)
Label31.Text = "0"
ElseIf x_serial.ToString.Length = 2 Then
Label34.Text = GetChar(x_serial, 1)
Label33.Text = GetChar(x_serial, 2)
Label32.Text = GetChar(x_serial, 3)
Label31.Text = GetChar(x_serial, 4)
End If

If y_serial.ToString.Length = 1 Then
Label38.Text = GetChar(y_serial, 1)
Label37.Text = "0"
Label36.Text = "0"
Label35.Text = "0"
ElseIf y_serial.ToString.Length = 2 Then
Label38.Text = GetChar(y_serial, 1)
Label37.Text = GetChar(y_serial, 2)
Label36.Text = "0"
Label35.Text = "0"
ElseIf y_serial.ToString.Length = 3 Then
Label38.Text = GetChar(y_serial, 1)
Label37.Text = GetChar(y_serial, 2)
Label36.Text = GetChar(y_serial, 3)
Label35.Text = "0"
ElseIf y_serial.ToString.Length = 2 Then
Label38.Text = GetChar(y_serial, 1)
Label37.Text = GetChar(y_serial, 2)
Label36.Text = GetChar(y_serial, 3)
Label35.Text = GetChar(y_serial, 4)
End If

Next

[kareninstructor]

Set a break-point starting at the beginning, step thru each line and inspect the outcome via hovering your mouse over a line of code that has already executed.

[Shaggy Hiker]

Also, turn Option Strict ON and fix all the resulting problems. You didn't include the declarations of the variables, so there are lots of possibilities due to variables being the wrong type and causing some strange implicit conversion issues. Option Strict will force you to use explicit conversions, which are not only faster, but will also be more correct.

[dimnik]

Here are the variables, all are declared as single and x_serial and y_serial are then converted to strings
Dim x As Single
Dim y As Single
Dim x_arx As Single
Dim x_tel As Single
Dim y_arx As Single
Dim y_tel As Single
Dim y0 As Single
Dim a As Single
Dim length_x As Single
Dim stp As Single
Dim i As Single
Dim y_serial As Single
Dim x_serial As Single
I don't think it has to do with the variables because, if you see the code, I also display the result before I break it in to individual numbers, and also the problem only results only in x_serial, that I forgot to mention, and only when it goes form 9 to 10. It doesn't occur ant any other point. Also, even the x_serial is displayed wrong, the result of y_serial is correct...
Additionally, if turn on the strict option won;t it forbid be to convert variables ?

[kareninstructor]

Here are the variables, all are declared as single and x_serial and y_serial are then converted to strings
Dim x As Single
Dim y As Single
Dim x_arx As Single
Dim x_tel As Single
Dim y_arx As Single
Dim y_tel As Single
Dim y0 As Single
Dim a As Single
Dim length_x As Single
Dim stp As Single
Dim i As Single
Dim y_serial As Single
Dim x_serial As Single
I don't think it has to do with the variables because, if you see the code, I also display the result before I break it in to individual numbers, and also the problem only results only in x_serial, that I forgot to mention, and only when it goes form 9 to 10. It doesn't occur ant any other point. Also, even the x_serial is displayed wrong, the result of y_serial is correct...
Additionally, if turn on the strict option won;t it forbid be to convert variables ?

First off when posting code, post all code together and use the code button in the editor above.

Second: Nothing prevents you from converting anything. You need to use appropriate methods and assertion. The example below shows using assertion and convert method on string to integer.

    Private Sub Demo()
        Dim Rate As Integer = 5
        Dim Value As Integer = 0
        Dim Total As Integer = 0

        If Integer.TryParse(TextBox1.Text, Value) Then
            Total = Value * Rate
        Else
            MessageBox.Show("Please enter a numeric value")
        End If
    End Sub

Third did you run thru the code with the debugger?

[Shaggy Hiker]

Option Strict will forbid the implicit conversion of variables, and will therefore force you to use explicit conversions. That's what you want to do, because implicit conversions means that you are leaving it up to the compiler to get it right. Leaving Option Strict OFF also allows you to make mistakes, like this one:

x_serial = Convert.ToString(x_serial)

I'm not sure what you were thinking this would do, but what it actually does is this: It takes the Single value x_serial, explicitly converts it to a string, but then it puts it back into x_serial. The variable itself doesn't change type, so x_serial is STILL a Single. Therefore, Convert.ToString will explicitly turn x_serial into a string, then will implicitly convert it back to a single. The net result is that no change will have been made and the line will take time while doing absolutely nothing.

You probably want to use Double, anyways, rather than Single.

[dimnik]

First off when posting code, post all code together and use the code button in the editor above.

Second: Nothing prevents you from converting anything. You need to use appropriate methods and assertion. The example below shows using assertion and convert method on string to integer.

    Private Sub Demo()
        Dim Rate As Integer = 5
        Dim Value As Integer = 0
        Dim Total As Integer = 0

        If Integer.TryParse(TextBox1.Text, Value) Then
            Total = Value * Rate
        Else
            MessageBox.Show("Please enter a numeric value")
        End If
    End Sub

Third did you run thru the code with the debugger?

First, sorry for writing in wrong way, I am not really familiar, so please accept my apologies
Second, I don't have that much of knowledge of visual basic, just the knowledge I got in my university fro VB6, so unfortunately some "simple" techniques aren't common to me. I am more experience with PICs micro controllers assembly so sometimes high level programming languages get me confuse with all that options and
Third, I tried with the debugger and it seems to get the correct values, but in the end I get the wrong...

[dimnik]

Option Strict will forbid the implicit conversion of variables, and will therefore force you to use explicit conversions. That's what you want to do, because implicit conversions means that you are leaving it up to the compiler to get it right. Leaving Option Strict OFF also allows you to make mistakes, like this one:

x_serial = Convert.ToString(x_serial)

I'm not sure what you were thinking this would do, but what it actually does is this: It takes the Single value x_serial, explicitly converts it to a string, but then it puts it back into x_serial. The variable itself doesn't change type, so x_serial is STILL a Single. Therefore, Convert.ToString will explicitly turn x_serial into a string, then will implicitly convert it back to a single. The net result is that no change will have been made and the line will take time while doing absolutely nothing.

You probably want to use Double, anyways, rather than Single.

Is it definite that the variable is not converted to string but it gets back to single, if so, in case it is back to single, it would allow me to extract a specific character from the whole number, isn't that correct? I think that you get an error if you use getchar to numbers.
The reason I use single, is because I won't use numbers above 60.000 so I guesses it saves memory that way

[kareninstructor]

First, sorry for writing in wrong way, I am not really familiar, so please accept my apologies
Second, I don't have that much of knowledge of visual basic, just the knowledge I got in my university fro VB6, so unfortunately some "simple" techniques aren't common to me. I am more experience with PICs micro controllers assembly so sometimes high level programming languages get me confuse with all that options and
Third, I tried with the debugger and it seems to get the correct values, but in the end I get the wrong...

No worries.

Have you set Option Strict On ? You can do this under project properties, compile or add Option Strict On as the first line in your form or code module and of course class modules.

[dunfiddlin]

Fascinating as all the math and discussion of Option Strict is, I can't help feeling that the most likely problem given all the labels is that two have somehow become transposed. Your logic of filling labels 31,32,33 etc. becomes completely irrelevant if the labels actually appear in the order 31,33,32 on the form.

[dimnik]

Fascinating as all the math and discussion of Option Strict is, I can't help feeling that the most likely problem given all the labels is that two have somehow become transposed. Your logic of filling labels 31,32,33 etc. becomes completely irrelevant if the labels actually appear in the order 31,33,32 on the form.

I don't really understand your post.
The guys proposed to use the strict option to prevent from doing mistakes.
My problem isn't of getting the wrong or right order of the numbers but getting a specific result at a specific point that doesn't occur in any other situation. Furthermore, my question was exactly what you mention about transposed values, because the result of the calculation is correct, but the individual display of the string's characters is wrong and just in this distinct point, it is correct in all previous loops and all latter loops

[Shaggy Hiker]

As long as you have Option Strict OFF, extracting a specific character from a number may not be a problem at all. I haven't tried it, but leaving Option Strict OFF will probably allow the compiler to do something like this:

I have a number, but I need a string. Since I am allowed to implicitly convert types, I will attempt to implicitly convert the number to a string so that I can use it.

That will work, because the number CAN be comverted to a string. Therefore, the compiler will probably do that and be happy with it. If you turn Option Strict ON, that line should result in an error because the implicit conversion will no longer be allowed. That's actually how implicit conversions can hurt you, too. The most common example is when somebody adds a number to a string. They are expecting the string to be implicitly converted to a number and the two numbers added, but the compiler may choose to implicitly convert the number to a string, in which case the + operator will concatenate the two strings rather than adding the numbers.

As for storage space, I'm not sure that you gain a thing by using Single, and if you do, you won't notice it, because you get the whole .NET framework, so a couple bytes out of tens of millions is not worth a thing. Having said that, there are lots of types that appear to save space, but probably don't. For example, the short integer would be 16 bits, or two bytes. However, it is fairly likely that it is actually stored into a four byte piece of memory simply because that is the size of memory that the CPU will bring into the cache (more than that in most cases, I think, but never less than that). Therefore, it may simply be more efficient for the compiler to stick a two byte value into a four byte space because that will be more efficient to move around in memory.

Similarly, I believe that the floating point unit works with 8-byte values, in which case the single is probably stored in an 8-byte chunk of memory in the CPU, though it may well be stored in something smaller in RAM. Once again, it won't save enough to worry about.

Oddly, it may cause you trouble once you turn Option Strict ON. Most floating point calculations (and you do use several) return type Double. Since a Double being converted to a Single would be a narrowing conversion (information is lost in the process), you would need to explicitly cast the results of the calculation to the narrower Single type, because the compiler would no longer be allowed to implicitly do that for you, as it is currently doing.

Ultimately, however, the solution to this will be to set a breakpoint and step through the code. You have stated that the problem is arising only at certain times, which means that your code is basically correct, but has some odd little edge case that is not being handled right. Staring at the code may solve it, but probably won't, and the only other alternative is stepping through it.

[dimnik]

I've been away for a while. (Job obligations).
I tried adding a breakpoint but although it seems to do the right process, it gives the wrong result.
I am trying to figure out some other way to accomplice the same result...
As for the strict on, I think that enabling it, although it will prevent me from making mistakes, it won't allow me to do the conversion; and I want it since afterwards I am going to send the fractions of the number to the serial port. Except if you have any proposal to do a similar process and will be OK with strict on.
By the way, since you mentioned the single and double; In most cases after consecutive calculation, instead of getting an integer or a decimal with two decimal places, as I should, I get for example 0,9999999 or 1,0000001 instead of 1. Is there any possibility that the use of single where I should use double cause that problem?