Tables with empty cells: unexpected results from a loop search for a string
Posted: Thu Jun 25, 2026 4:41 am
Using Eviews 14 Dec 26 2024 build
Tables with empty cells behave unexpectedly in a loop search for a string.
The search would unexpectedly stop once the loop reaches an empty cell, see code below.
Tables with empty cells behave unexpectedly in a loop search for a string.
The search would unexpectedly stop once the loop reaches an empty cell, see code below.
Code: Select all
wfcreate u 1
' create table with four rows and one column
table(4,1) tab
' Filling the table, but leaving the 2nd row empty
tab(1,1)="a"
tab(3,1)="c"
tab(4,1)="d"
!nrows=tab.@rows
' Loop stops unexpectedly when the empty 2nd row is reached, and !i ends up with 2 rather than 3.
!i=1
while tab(!i,1) <> "c" and !i<!nrows
!i=!i+1
wend
scalar i1=!i
show i1
' Work around which lets !i end up with the correct result 3
!i=1
while tab(!i,1) <> "c" or tab(!i,1)="" and !i<!nrows
!i=!i+1
wend
scalar i2=!i
show i2
' Filling the second row...
tab(2,1)="b"
' .. lets !i end up correctly with 3
!i=1
while tab(!i,1) <> "c" and !i<!nrows
!i=!i+1
wend
scalar i3=!i
show i3
). Your basic comparison expression, tab(!i,1) <> "c", is one in which an empty table cell will be treated as a missing value rather than an empty string, and thus the result of the comparison is not what you expect. Your extended comparison expression, tab(!i,1) <> "c" or tab(!i,1)="", adds a test in which an empty table cell will be treated as an empty string. Alternatively, you could have written: tab(!i,1) <> "c" or @isempty(tab(!i,1)). The moral of the story is, because empty strings serve double duty as representing both empty strings and missing values in EViews, extra attention must be paid to how they're involved in comparisons.