STRANGE STUFF: Addition in interations have wrong results after few iterations

[Lukas_Doubek]

Hello, i got some strange behaviour while comparing values, so i created simple script to test what i was doing in my script working with channels. so i made small script with no channels, just to test it.

dValue 	= CDbl(0)
dStep 	= CDbl(0.05)
For i=1 to 200
	dValue = CDbl(dValue + dStep)
	LogfileWrite dValue
Next

This is the output, can you please explain me, why it after the value "3.6", it counts wrong results?

The next value should be "3.65" and not "3.649999999999"

The output:

0.05
0.1
0.15
0.2
0.25
0.3
0.35
0.4
0.45
0.5
0.55
0.6
0.65
0.7
0.75
0.8
0.85
0.9
0.95
1
1.05
1.1
1.15
1.2
1.25
1.3
1.35
1.4
1.45
1.5
1.55
1.6
1.65
1.7
1.75
1.8
1.85
1.9
1.95
2
2.05
2.1
2.15
2.2
2.25
2.3
2.35
2.4
2.45
2.5
2.55
2.6
2.65
2.7
2.75
2.8
2.85
2.9
2.95
3
3.05
3.1
3.15
3.2
3.25
3.3
3.35
3.4
3.45
3.5
3.55
3.6
3.64999999999999
3.69999999999999
3.74999999999999
3.79999999999999
3.84999999999999
3.89999999999999

......

8.94999999999999
8.99999999999999
9.04999999999999
9.09999999999999
9.14999999999999
9.2
9.25
9.3
9.35
9.4
9.45
9.5
9.55
9.6
9.65
9.7
9.75
9.8
9.85000000000001
9.90000000000001
9.95000000000001
10

Windows 10, Diadem 2017 64bit

[markwkiehl]

What you see written to the LogFile doesn't specify any string formatting for the number.  And what is written isn't a full representation of the data stored internally.  Use the Str() function as shown below to format the output as a string to the LogFile.  3.64999999999999 is close enough to 3.65 in my mind.  And the output of the value 9.95000000000001 later on reflects that the increment is correct.  

You mentioned "comparing" values, but you didn't show a comparison.  In many cases, if you are comparing real (floating point) numbers, you should use the DIAdem functions ValEqualGT(), ValEqual(), ValEqualGT()...   Look them up in the DIAdem help.   This link to my website may help:  http://www.savvydiademsolutions.com/analysis.php?topic=analysis-channel-event-detection-commands

Dim dValue, dStep, i
dValue = CDbl(0)
dStep = CDbl(0.05)
For i=1 to 200
  dValue = CDbl(dValue + dStep)
  LogfileWrite Str(dValue,"d.dd")
Next

[Lukas_Doubek]

Hi thanks for this answer, the comparison is made of each value from channel and variable.

If CDbl(chTime.Values(iRowTime)) <> CDbl(dValue) Then

I got some channels with not equidistant time channel, so im trying to repair it by checking each value with the variable im incrementing.

I will definitely check the functions to check if they are equal, thanks for that.

I use the str() fucntion to format number when i want to print it/output it. But if i want to check if the number is bigger or smaller, i need to retype cast the variable to some number format, so STR() is not usefull. or i can check it by MaxV or MinV. With the str function, i will have to get the format for each different channel, for example one time i would use d,dd and next time d,dddd

[gsklyr]

Very interesting issue... thanks for sharing.

Whenever I have issues with equidistant time channels I use "Generate numeric/time channel" with the equidistant option

Set ChnResult = ChnLinGen("/LinearGenerated2", 0.05, 10, 200, "s")

[Lukas_Doubek]

Yes i use that function as well on different places of my program, but i wanted to know if its just me with this strange results. With integers it works fine.

I dont know if im the only one, but i would expect if i make 1 + 0,5, it will output 1.5 and not 1.49999999999999 without retyping it to string with str().

[gsklyr]

Yeah that is bs... rounding could help instead of STR()

dim dValue, dStep, i
dValue = CDbl(0)
dStep = CDbl(0.05)
For i=1 to 200
  dValue = Round(dValue + dStep, 2)
  LogfileWrite dValue
Next

[Walter_Rick]

ease check also this:

dValue 	= val(0.0)
dStep 	= val(0.05)
For i=1 to 200
	dValue = val(dValue + dStep)
	LogfileWrite dValue
Next

Greetings

Walter