Is this a BUG??? - comp.soft-sys.sas

Hi, ALL, I am using LIBNAME to read the EXCEL data into SAS. after that, I want to conditionaly delete some rows. However, it didn't give me the correct number of OBS. It seems to me that WHERE statement filtered out the variables with missing value by default. it dosen't make any sense!! Am I missing something here or it is a BUG. Thanks! data test; input id a b; cards; 1 . . 2 3 4 3 4 5 4 99 99 5 . . ; run; proc export data=test outfile='c:\test.xls' dbms=excel replace; sheet=test; run; libname try excel 'c:\test.xls'; data test1; set try.test; where a ~=99 and b ~=99; run; proc print; run;

I think it must a "chicken and egg" thing, but I can't explain it.. Sub setting if does work properly. On 8/17/07, Yu Zhang <zhangyu05@gmail.com> wrote: > Hi, ALL, > > I am using LIBNAME to read the EXCEL data into SAS. after that, I want to > conditionaly delete some rows. However, it didn't give me the correct number > of OBS. It seems to me that WHERE statement filtered out the variables with > missing value by default. > > it dosen't make any sense!! > > > Am I missing something here or it is a BUG. > > Thanks! > > data test; > input id a b; > cards; > 1 . . > 2 3 4 > 3 4 5 > 4 99 99 > 5 . . > ; > run; > > proc export data=test > outfile='c:\test.xls' > dbms=excel replace; > sheet=test; > run; > > libname try excel 'c:\test.xls'; > data test1; > set try.test; > where a ~=99 and b ~=99; > run; > proc print; > run; >

However, when you get the data in another dataset, then do the subsetting, it works. What is going on?? it implies that we have to be very carefull when we subset the data read in with libname EXCEL engine. Anyone has some idea about this? data test1; set try.test; *where a ~=99 and b ~=99; run; data test2; set test1; where a ~=99 and b ~=99; run; On 8/17/07, data _null_; <datanull@gmail.com> wrote: > > I think it must a "chicken and egg" thing, but I can't explain it.. > > Sub setting if does work properly. > > On 8/17/07, Yu Zhang <zhangyu05@gmail.com> wrote: > > Hi, ALL, > > > > I am using LIBNAME to read the EXCEL data into SAS. after that, I want > to > > conditionaly delete some rows. However, it didn't give me the correct > number > > of OBS. It seems to me that WHERE statement filtered out the variables > with > > missing value by default. > > > > it dosen't make any sense!! > > > > > > Am I missing something here or it is a BUG. > > > > Thanks! > > > > data test; > > input id a b; > > cards; > > 1 . . > > 2 3 4 > > 3 4 5 > > 4 99 99 > > 5 . . > > ; > > run; > > > > proc export data=test > > outfile='c:\test.xls' > > dbms=excel replace; > > sheet=test; > > run; > > > > libname try excel 'c:\test.xls'; > > data test1; > > set try.test; > > where a ~=99 and b ~=99; > > run; > > proc print; > > run; > > >

What happens if you change your WHERE to an IF? Any difference? -----Original Message----- From: SAS(r) Discussion [mailto:SAS-L@LISTSERV.UGA.EDU] On Behalf Of Yu Zhang Sent: Friday, August 17, 2007 2:11 PM To: SAS-L@LISTSERV.UGA.EDU Subject: Re: Is this a BUG??? However, when you get the data in another dataset, then do the subsetting, it works. What is going on?? it implies that we have to be very carefull when we subset the data read in with libname EXCEL engine. Anyone has some idea about this? data test1; set try.test; *where a ~=99 and b ~=99; run; data test2; set test1; where a ~=99 and b ~=99; run; On 8/17/07, data _null_; <datanull@gmail.com> wrote: > > I think it must a "chicken and egg" thing, but I can't explain it.. > > Sub setting if does work properly. > > On 8/17/07, Yu Zhang <zhangyu05@gmail.com> wrote: > > Hi, ALL, > > > > I am using LIBNAME to read the EXCEL data into SAS. after that, I > > want > to > > conditionaly delete some rows. However, it didn't give me the > > correct > number > > of OBS. It seems to me that WHERE statement filtered out the > > variables > with > > missing value by default. > > > > it dosen't make any sense!! > > > > > > Am I missing something here or it is a BUG. > > > > Thanks! > > > > data test; > > input id a b; > > cards; > > 1 . . > > 2 3 4 > > 3 4 5 > > 4 99 99 > > 5 . . > > ; > > run; > > > > proc export data=test > > outfile='c:\test.xls' > > dbms=excel replace; > > sheet=test; > > run; > > > > libname try excel 'c:\test.xls'; > > data test1; > > set try.test; > > where a ~=99 and b ~=99; > > run; > > proc print; > > run; > > >

The IF statement would more likely work as expected. The WHERE statement in a Data step works more like a SQL WHERE, and, in SQL, the NOT EQUALS operator does not return a True value when one of the operands has a MISSING or NULL value. Known trap for the unwary ... Try the condition .... WHERE (a ~= 99 OR a IS NULL) AND (b ~= 99 OR b IS NULL) or more concisely, .... WHERE NOT (a=99 OR b=99) [equivalent by deMorgan's law]. In the trinary logic of SQL, NULL or MISSING means undefined, and in that logic one does not know whether a variable isn't equal to another if that value is undefined. I avoid using NOT EQUALS for other reasons as well. S -----Original Message----- From: owner-sas-l@listserv.uga.edu [mailto:owner-sas-l@listserv.uga.edu] On Behalf Of Pardee, Roy Sent: Friday, August 17, 2007 5:25 PM To: Yu Zhang; SAS-L@LISTSERV.UGA.EDU Subject: RE: Re: Is this a BUG??? What happens if you change your WHERE to an IF? Any difference? -----Original Message----- From: SAS(r) Discussion [mailto:SAS-L@LISTSERV.UGA.EDU] On Behalf Of Yu Zhang Sent: Friday, August 17, 2007 2:11 PM To: SAS-L@LISTSERV.UGA.EDU Subject: Re: Is this a BUG??? However, when you get the data in another dataset, then do the subsetting, it works. What is going on?? it implies that we have to be very carefull when we subset the data read in with libname EXCEL engine. Anyone has some idea about this? data test1; set try.test; *where a ~=99 and b ~=99; run; data test2; set test1; where a ~=99 and b ~=99; run; On 8/17/07, data _null_; <datanull@gmail.com> wrote: > > I think it must a "chicken and egg" thing, but I can't explain it.. > > Sub setting if does work properly. > > On 8/17/07, Yu Zhang <zhangyu05@gmail.com> wrote: > > Hi, ALL, > > > > I am using LIBNAME to read the EXCEL data into SAS. after that, I > > want > to > > conditionaly delete some rows. However, it didn't give me the > > correct > number > > of OBS. It seems to me that WHERE statement filtered out the > > variables > with > > missing value by default. > > > > it dosen't make any sense!! > > > > > > Am I missing something here or it is a BUG. > > > > Thanks! > > > > data test; > > input id a b; > > cards; > > 1 . . > > 2 3 4 > > 3 4 5 > > 4 99 99 > > 5 . . > > ; > > run; > > > > proc export data=test > > outfile='c:\test.xls' > > dbms=excel replace; > > sheet=test; > > run; > > > > libname try excel 'c:\test.xls'; > > data test1; > > set try.test; > > where a ~=99 and b ~=99; > > run; > > proc print; > > run; > > >

The more concise version works the same way as the original posted by Yu. SAS is echoing it to the log as WHERE (a not = 99) and (b not = 99); 19 data test1; 20 set try.test; 21 /*where a ne '99' and b ne '99';*/ 22 /*WHERE (a ~= 99 OR a IS NULL) AND (b ~= 99 OR b IS NULL);*/ 23 WHERE NOT (a=99 OR b=99); NOTE: There were 2 observations read from the data set TRY.test. WHERE (a not = 99) and (b not = 99); NOTE: The data set WORK.TEST1 has 2 observations and 3 variables. On 8/17/07, Sigurd Hermansen <HERMANS1@westat.com> wrote: > The IF statement would more likely work as expected. The WHERE statement > in a Data step works more like a SQL WHERE, and, in SQL, the NOT EQUALS > operator does not return a True value when one of the operands has a > MISSING or NULL value. Known trap for the unwary ... Try the condition > > ... WHERE (a ~= 99 OR a IS NULL) AND (b ~= 99 OR b IS NULL) > > or more concisely, > > ... WHERE NOT (a=99 OR b=99) [equivalent by deMorgan's law]. > > In the trinary logic of SQL, NULL or MISSING means undefined, and in > that logic one does not know whether a variable isn't equal to another > if that value is undefined. I avoid using NOT EQUALS for other reasons > as well. > S > > -----Original Message----- > From: owner-sas-l@listserv.uga.edu [mailto:owner-sas-l@listserv.uga.edu] > On Behalf Of Pardee, Roy > Sent: Friday, August 17, 2007 5:25 PM > To: Yu Zhang; SAS-L@LISTSERV.UGA.EDU > Subject: RE: Re: Is this a BUG??? > > > What happens if you change your WHERE to an IF? Any difference? > > -----Original Message----- > From: SAS(r) Discussion [mailto:SAS-L@LISTSERV.UGA.EDU] On Behalf Of Yu > Zhang > Sent: Friday, August 17, 2007 2:11 PM > To: SAS-L@LISTSERV.UGA.EDU > Subject: Re: Is this a BUG??? > > However, when you get the data in another dataset, then do the > subsetting, it works. > > What is going on?? it implies that we have to be very carefull when we > subset the data read in with libname EXCEL engine. > > Anyone has some idea about this? > > > data test1; > set try.test; > *where a ~=99 and b ~=99; > run; > > data test2; > set test1; > where a ~=99 and b ~=99; > run; > > > On 8/17/07, data _null_; <datanull@gmail.com> wrote: > > > > I think it must a "chicken and egg" thing, but I can't explain it.. > > > > Sub setting if does work properly. > > > > On 8/17/07, Yu Zhang <zhangyu05@gmail.com> wrote: > > > Hi, ALL, > > > > > > I am using LIBNAME to read the EXCEL data into SAS. after that, I > > > want > > to > > > conditionaly delete some rows. However, it didn't give me the > > > correct > > number > > > of OBS. It seems to me that WHERE statement filtered out the > > > variables > > with > > > missing value by default. > > > > > > it dosen't make any sense!! > > > > > > > > > Am I missing something here or it is a BUG. > > > > > > Thanks! > > > > > > data test; > > > input id a b; > > > cards; > > > 1 . . > > > 2 3 4 > > > 3 4 5 > > > 4 99 99 > > > 5 . . > > > ; > > > run; > > > > > > proc export data=test > > > outfile='c:\test.xls' > > > dbms=excel replace; > > > sheet=test; > > > run; > > > > > > libname try excel 'c:\test.xls'; > > > data test1; > > > set try.test; > > > where a ~=99 and b ~=99; > > > run; > > > proc print; > > > run; > > > > > >

Yes, I see that now. x=99 resolves to NULL when x is NULL, and (NULL OR NULL) remains undefined for the same reasons as before. On Friday afternoon's my logic tends to wander about a bit. Thanks, S -----Original Message----- From: data _null_; [mailto:datanull@gmail.com] Sent: Friday, August 17, 2007 5:55 PM To: Sigurd Hermansen Cc: SAS-L@listserv.uga.edu Subject: Re: Is this a BUG??? The more concise version works the same way as the original posted by Yu. SAS is echoing it to the log as WHERE (a not = 99) and (b not = 99); 19 data test1; 20 set try.test; 21 /*where a ne '99' and b ne '99';*/ 22 /*WHERE (a ~= 99 OR a IS NULL) AND (b ~= 99 OR b IS NULL);*/ 23 WHERE NOT (a=99 OR b=99); NOTE: There were 2 observations read from the data set TRY.test. WHERE (a not = 99) and (b not = 99); NOTE: The data set WORK.TEST1 has 2 observations and 3 variables. On 8/17/07, Sigurd Hermansen <HERMANS1@westat.com> wrote: > The IF statement would more likely work as expected. The WHERE > statement in a Data step works more like a SQL WHERE, and, in SQL, the > NOT EQUALS operator does not return a True value when one of the > operands has a MISSING or NULL value. Known trap for the unwary ... > Try the condition > > ... WHERE (a ~= 99 OR a IS NULL) AND (b ~= 99 OR b IS NULL) > > or more concisely, > > ... WHERE NOT (a=99 OR b=99) [equivalent by deMorgan's law]. > > In the trinary logic of SQL, NULL or MISSING means undefined, and in > that logic one does not know whether a variable isn't equal to another > if that value is undefined. I avoid using NOT EQUALS for other reasons > as well. S > > -----Original Message----- > From: owner-sas-l@listserv.uga.edu > [mailto:owner-sas-l@listserv.uga.edu] > On Behalf Of Pardee, Roy > Sent: Friday, August 17, 2007 5:25 PM > To: Yu Zhang; SAS-L@LISTSERV.UGA.EDU > Subject: RE: Re: Is this a BUG??? > > > What happens if you change your WHERE to an IF? Any difference? > > -----Original Message----- > From: SAS(r) Discussion [mailto:SAS-L@LISTSERV.UGA.EDU] On Behalf Of > Yu Zhang > Sent: Friday, August 17, 2007 2:11 PM > To: SAS-L@LISTSERV.UGA.EDU > Subject: Re: Is this a BUG??? > > However, when you get the data in another dataset, then do the > subsetting, it works. > > What is going on?? it implies that we have to be very carefull when we > subset the data read in with libname EXCEL engine. > > Anyone has some idea about this? > > > data test1; > set try.test; > *where a ~=99 and b ~=99; > run; > > data test2; > set test1; > where a ~=99 and b ~=99; > run; > > > On 8/17/07, data _null_; <datanull@gmail.com> wrote: > > > > I think it must a "chicken and egg" thing, but I can't explain it.. > > > > Sub setting if does work properly. > > > > On 8/17/07, Yu Zhang <zhangyu05@gmail.com> wrote: > > > Hi, ALL, > > > > > > I am using LIBNAME to read the EXCEL data into SAS. after that, I > > > want > > to > > > conditionaly delete some rows. However, it didn't give me the > > > correct > > number > > > of OBS. It seems to me that WHERE statement filtered out the > > > variables > > with > > > missing value by default. > > > > > > it dosen't make any sense!! > > > > > > > > > Am I missing something here or it is a BUG. > > > > > > Thanks! > > > > > > data test; > > > input id a b; > > > cards; > > > 1 . . > > > 2 3 4 > > > 3 4 5 > > > 4 99 99 > > > 5 . . > > > ; > > > run; > > > > > > proc export data=test > > > outfile='c:\test.xls' > > > dbms=excel replace; > > > sheet=test; > > > run; > > > > > > libname try excel 'c:\test.xls'; > > > data test1; > > > set try.test; > > > where a ~=99 and b ~=99; > > > run; > > > proc print; > > > run; > > > > > >

As Roy suspected, the data are processed correctly when the WHERE is replaced by the subsetting IF. 25 data test1; 26 set try.test; 27 if a ~=99 and b ~=99; 28 run; NOTE: There were 5 observations read from the data set TRY.test. NOTE: The data set WORK.TEST1 has 4 observations and 3 variables. Bug or feature? It looks like WHERE is the term to be avoided when working with this engine. -Tom On Fri, 17 Aug 2007 18:04:54 -0400, Sigurd Hermansen <HERMANS1@WESTAT.COM> wrote: >Yes, I see that now. x=99 resolves to NULL when x is NULL, and (NULL OR >NULL) remains undefined for the same reasons as before. On Friday >afternoon's my logic tends to wander about a bit. >Thanks, >S > >-----Original Message----- >From: data _null_; [mailto:datanull@gmail.com] >Sent: Friday, August 17, 2007 5:55 PM >To: Sigurd Hermansen >Cc: SAS-L@listserv.uga.edu >Subject: Re: Is this a BUG??? > > >The more concise version works the same way as the original posted by >Yu. SAS is echoing it to the log as WHERE (a not = 99) and (b >not = 99); > >19 data test1; >20 set try.test; >21 /*where a ne '99' and b ne '99';*/ >22 /*WHERE (a ~= 99 OR a IS NULL) AND (b ~= 99 OR b IS NULL);*/ >23 WHERE NOT (a=99 OR b=99); > >NOTE: There were 2 observations read from the data set TRY.test. > WHERE (a not = 99) and (b not = 99); >NOTE: The data set WORK.TEST1 has 2 observations and 3 variables. > >On 8/17/07, Sigurd Hermansen <HERMANS1@westat.com> wrote: >> The IF statement would more likely work as expected. The WHERE >> statement in a Data step works more like a SQL WHERE, and, in SQL, the > >> NOT EQUALS operator does not return a True value when one of the >> operands has a MISSING or NULL value. Known trap for the unwary ... >> Try the condition >> >> ... WHERE (a ~= 99 OR a IS NULL) AND (b ~= 99 OR b IS NULL) >> >> or more concisely, >> >> ... WHERE NOT (a=99 OR b=99) [equivalent by deMorgan's law]. >> >> In the trinary logic of SQL, NULL or MISSING means undefined, and in >> that logic one does not know whether a variable isn't equal to another > >> if that value is undefined. I avoid using NOT EQUALS for other reasons > >> as well. S >> >> -----Original Message----- >> From: owner-sas-l@listserv.uga.edu >> [mailto:owner-sas-l@listserv.uga.edu] >> On Behalf Of Pardee, Roy >> Sent: Friday, August 17, 2007 5:25 PM >> To: Yu Zhang; SAS-L@LISTSERV.UGA.EDU >> Subject: RE: Re: Is this a BUG??? >> >> >> What happens if you change your WHERE to an IF? Any difference? >> >> -----Original Message----- >> From: SAS(r) Discussion [mailto:SAS-L@LISTSERV.UGA.EDU] On Behalf Of >> Yu Zhang >> Sent: Friday, August 17, 2007 2:11 PM >> To: SAS-L@LISTSERV.UGA.EDU >> Subject: Re: Is this a BUG??? >> >> However, when you get the data in another dataset, then do the >> subsetting, it works. >> >> What is going on?? it implies that we have to be very carefull when we > >> subset the data read in with libname EXCEL engine. >> >> Anyone has some idea about this? >> >> >> data test1; >> set try.test; >> *where a ~=99 and b ~=99; >> run; >> >> data test2; >> set test1; >> where a ~=99 and b ~=99; >> run; >> >> >> On 8/17/07, data _null_; <datanull@gmail.com> wrote: >> > >> > I think it must a "chicken and egg" thing, but I can't explain it.. >> > >> > Sub setting if does work properly. >> > >> > On 8/17/07, Yu Zhang <zhangyu05@gmail.com> wrote: >> > > Hi, ALL, >> > > >> > > I am using LIBNAME to read the EXCEL data into SAS. after that, I > >> > > want >> > to >> > > conditionaly delete some rows. However, it didn't give me the >> > > correct >> > number >> > > of OBS. It seems to me that WHERE statement filtered out the >> > > variables >> > with >> > > missing value by default. >> > > >> > > it dosen't make any sense!! >> > > >> > > >> > > Am I missing something here or it is a BUG. >> > > >> > > Thanks! >> > > >> > > data test; >> > > input id a b; >> > > cards; >> > > 1 . . >> > > 2 3 4 >> > > 3 4 5 >> > > 4 99 99 >> > > 5 . . >> > > ; >> > > run; >> > > >> > > proc export data=test >> > > outfile='c:\test.xls' >> > > dbms=excel replace; >> > > sheet=test; >> > > run; >> > > >> > > libname try excel 'c:\test.xls'; >> > > data test1; >> > > set try.test; >> > > where a ~=99 and b ~=99; >> > > run; >> > > proc print; >> > > run; >> > > >> > >>

Tom, Based on Sig's comment, I was going to respond to your post indicating that it isn't engine specific. However, fortunately I tested it first and, indeed, it IS engine specific. data test; input id a b; cards; 1 . . 2 3 4 3 4 5 4 99 99 5 . . ; run; data want; set test; where a ~=99 and b ~=99; run; works the same as subsetting if statements. I would call this one a bug and now wonder if it is limited to the excel engine. Art ---------- On Fri, 17 Aug 2007 19:50:13 -0400, Tom Cross <tom.cross@KP.ORG> wrote: >As Roy suspected, the data are processed correctly when the WHERE is >replaced by the subsetting IF. > >25 data test1; >26 set try.test; >27 if a ~=99 and b ~=99; >28 run; > >NOTE: There were 5 observations read from the data set TRY.test. >NOTE: The data set WORK.TEST1 has 4 observations and 3 variables. > >Bug or feature? It looks like WHERE is the term to be avoided when working >with this engine. >-Tom > >On Fri, 17 Aug 2007 18:04:54 -0400, Sigurd Hermansen <HERMANS1@WESTAT.COM> >wrote: > >>Yes, I see that now. x=99 resolves to NULL when x is NULL, and (NULL OR >>NULL) remains undefined for the same reasons as before. On Friday >>afternoon's my logic tends to wander about a bit. >>Thanks, >>S >> >>-----Original Message----- >>From: data _null_; [mailto:datanull@gmail.com] >>Sent: Friday, August 17, 2007 5:55 PM >>To: Sigurd Hermansen >>Cc: SAS-L@listserv.uga.edu >>Subject: Re: Is this a BUG??? >> >> >>The more concise version works the same way as the original posted by >>Yu. SAS is echoing it to the log as WHERE (a not = 99) and (b >>not = 99); >> >>19 data test1; >>20 set try.test; >>21 /*where a ne '99' and b ne '99';*/ >>22 /*WHERE (a ~= 99 OR a IS NULL) AND (b ~= 99 OR b IS NULL);*/ >>23 WHERE NOT (a=99 OR b=99); >> >>NOTE: There were 2 observations read from the data set TRY.test. >> WHERE (a not = 99) and (b not = 99); >>NOTE: The data set WORK.TEST1 has 2 observations and 3 variables. >> >>On 8/17/07, Sigurd Hermansen <HERMANS1@westat.com> wrote: >>> The IF statement would more likely work as expected. The WHERE >>> statement in a Data step works more like a SQL WHERE, and, in SQL, the >> >>> NOT EQUALS operator does not return a True value when one of the >>> operands has a MISSING or NULL value. Known trap for the unwary ... >>> Try the condition >>> >>> ... WHERE (a ~= 99 OR a IS NULL) AND (b ~= 99 OR b IS NULL) >>> >>> or more concisely, >>> >>> ... WHERE NOT (a=99 OR b=99) [equivalent by deMorgan's law]. >>> >>> In the trinary logic of SQL, NULL or MISSING means undefined, and in >>> that logic one does not know whether a variable isn't equal to another >> >>> if that value is undefined. I avoid using NOT EQUALS for other reasons >> >>> as well. S >>> >>> -----Original Message----- >>> From: owner-sas-l@listserv.uga.edu >>> [mailto:owner-sas-l@listserv.uga.edu] >>> On Behalf Of Pardee, Roy >>> Sent: Friday, August 17, 2007 5:25 PM >>> To: Yu Zhang; SAS-L@LISTSERV.UGA.EDU >>> Subject: RE: Re: Is this a BUG??? >>> >>> >>> What happens if you change your WHERE to an IF? Any difference? >>> >>> -----Original Message----- >>> From: SAS(r) Discussion [mailto:SAS-L@LISTSERV.UGA.EDU] On Behalf Of >>> Yu Zhang >>> Sent: Friday, August 17, 2007 2:11 PM >>> To: SAS-L@LISTSERV.UGA.EDU >>> Subject: Re: Is this a BUG??? >>> >>> However, when you get the data in another dataset, then do the >>> subsetting, it works. >>> >>> What is going on?? it implies that we have to be very carefull when we >> >>> subset the data read in with libname EXCEL engine. >>> >>> Anyone has some idea about this? >>> >>> >>> data test1; >>> set try.test; >>> *where a ~=99 and b ~=99; >>> run; >>> >>> data test2; >>> set test1; >>> where a ~=99 and b ~=99; >>> run; >>> >>> >>> On 8/17/07, data _null_; <datanull@gmail.com> wrote: >>> > >>> > I think it must a "chicken and egg" thing, but I can't explain it.. >>> > >>> > Sub setting if does work properly. >>> > >>> > On 8/17/07, Yu Zhang <zhangyu05@gmail.com> wrote: >>> > > Hi, ALL, >>> > > >>> > > I am using LIBNAME to read the EXCEL data into SAS. after that, I >> >>> > > want >>> > to >>> > > conditionaly delete some rows. However, it didn't give me the >>> > > correct >>> > number >>> > > of OBS. It seems to me that WHERE statement filtered out the >>> > > variables >>> > with >>> > > missing value by default. >>> > > >>> > > it dosen't make any sense!! >>> > > >>> > > >>> > > Am I missing something here or it is a BUG. >>> > > >>> > > Thanks! >>> > > >>> > > data test; >>> > > input id a b; >>> > > cards; >>> > > 1 . . >>> > > 2 3 4 >>> > > 3 4 5 >>> > > 4 99 99 >>> > > 5 . . >>> > > ; >>> > > run; >>> > > >>> > > proc export data=test >>> > > outfile='c:\test.xls' >>> > > dbms=excel replace; >>> > > sheet=test; >>> > > run; >>> > > >>> > > libname try excel 'c:\test.xls'; >>> > > data test1; >>> > > set try.test; >>> > > where a ~=99 and b ~=99; >>> > > run; >>> > > proc print; >>> > > run; >>> > > >>> > >>>

Art: As I understand the post, Yu Zhang has reported in one of the parallel threads that the WHERE statement behaves differently under the SAS/Access engine than when applied to a SAS dataset. Now it appears that we have Data step - SAS dataset, Data step - SAS/Access to ????, and SQL rules for comparisons of missing and NULL values in WHERE clauses and statements. I haven't tested whether the IF statement works consistently in the first two contexts. To paraphrase one of my colleagues, 'All I know about SAS I've learned on SAS-L'. Most of the finer points, I know. SAS-L once again confirms the old adage that two heads work better than one. Only on the 'L we have thousands of head cases working better than one. All for free. Who could ask for more. S -----Original Message----- From: owner-sas-l@listserv.uga.edu [mailto:owner-sas-l@listserv.uga.edu] On Behalf Of Arthur Tabachneck Sent: Friday, August 17, 2007 8:56 PM To: SAS-L@LISTSERV.UGA.EDU; Tom Cross Subject: Re: Is this a BUG??? Tom, Based on Sig's comment, I was going to respond to your post indicating that it isn't engine specific. However, fortunately I tested it first and, indeed, it IS engine specific. data test; input id a b; cards; 1 . . 2 3 4 3 4 5 4 99 99 5 . . ; run; data want; set test; where a ~=99 and b ~=99; run; works the same as subsetting if statements. I would call this one a bug and now wonder if it is limited to the excel engine. Art ---------- On Fri, 17 Aug 2007 19:50:13 -0400, Tom Cross <tom.cross@KP.ORG> wrote: >As Roy suspected, the data are processed correctly when the WHERE is >replaced by the subsetting IF. > >25 data test1; >26 set try.test; >27 if a ~=99 and b ~=99; >28 run; > >NOTE: There were 5 observations read from the data set TRY.test. >NOTE: The data set WORK.TEST1 has 4 observations and 3 variables. > >Bug or feature? It looks like WHERE is the term to be avoided when >working with this engine. -Tom > >On Fri, 17 Aug 2007 18:04:54 -0400, Sigurd Hermansen ><HERMANS1@WESTAT.COM> >wrote: > >>Yes, I see that now. x=99 resolves to NULL when x is NULL, and (NULL >>OR >>NULL) remains undefined for the same reasons as before. On Friday >>afternoon's my logic tends to wander about a bit. >>Thanks, >>S >> >>-----Original Message----- >>From: data _null_; [mailto:datanull@gmail.com] >>Sent: Friday, August 17, 2007 5:55 PM >>To: Sigurd Hermansen >>Cc: SAS-L@listserv.uga.edu >>Subject: Re: Is this a BUG??? >> >> >>The more concise version works the same way as the original posted by >>Yu. SAS is echoing it to the log as WHERE (a not = 99) and (b >>not = 99); >> >>19 data test1; >>20 set try.test; >>21 /*where a ne '99' and b ne '99';*/ >>22 /*WHERE (a ~= 99 OR a IS NULL) AND (b ~= 99 OR b IS NULL);*/ >>23 WHERE NOT (a=99 OR b=99); >> >>NOTE: There were 2 observations read from the data set TRY.test. >> WHERE (a not = 99) and (b not = 99); >>NOTE: The data set WORK.TEST1 has 2 observations and 3 variables. >> >>On 8/17/07, Sigurd Hermansen <HERMANS1@westat.com> wrote: >>> The IF statement would more likely work as expected. The WHERE >>> statement in a Data step works more like a SQL WHERE, and, in SQL, >>> the >> >>> NOT EQUALS operator does not return a True value when one of the >>> operands has a MISSING or NULL value. Known trap for the unwary ... >>> Try the condition >>> >>> ... WHERE (a ~= 99 OR a IS NULL) AND (b ~= 99 OR b IS NULL) >>> >>> or more concisely, >>> >>> ... WHERE NOT (a=99 OR b=99) [equivalent by deMorgan's law]. >>> >>> In the trinary logic of SQL, NULL or MISSING means undefined, and in >>> that logic one does not know whether a variable isn't equal to >>> another >> >>> if that value is undefined. I avoid using NOT EQUALS for other >>> reasons >> >>> as well. S >>> >>> -----Original Message----- >>> From: owner-sas-l@listserv.uga.edu >>> [mailto:owner-sas-l@listserv.uga.edu] >>> On Behalf Of Pardee, Roy >>> Sent: Friday, August 17, 2007 5:25 PM >>> To: Yu Zhang; SAS-L@LISTSERV.UGA.EDU >>> Subject: RE: Re: Is this a BUG??? >>> >>> >>> What happens if you change your WHERE to an IF? Any difference? >>> >>> -----Original Message----- >>> From: SAS(r) Discussion [mailto:SAS-L@LISTSERV.UGA.EDU] On Behalf Of >>> Yu Zhang >>> Sent: Friday, August 17, 2007 2:11 PM >>> To: SAS-L@LISTSERV.UGA.EDU >>> Subject: Re: Is this a BUG??? >>> >>> However, when you get the data in another dataset, then do the >>> subsetting, it works. >>> >>> What is going on?? it implies that we have to be very carefull when >>> we >> >>> subset the data read in with libname EXCEL engine. >>> >>> Anyone has some idea about this? >>> >>> >>> data test1; >>> set try.test; >>> *where a ~=99 and b ~=99; >>> run; >>> >>> data test2; >>> set test1; >>> where a ~=99 and b ~=99; >>> run; >>> >>> >>> On 8/17/07, data _null_; <datanull@gmail.com> wrote: >>> > >>> > I think it must a "chicken and egg" thing, but I can't explain >>> > it.. >>> > >>> > Sub setting if does work properly. >>> > >>> > On 8/17/07, Yu Zhang <zhangyu05@gmail.com> wrote: >>> > > Hi, ALL, >>> > > >>> > > I am using LIBNAME to read the EXCEL data into SAS. after that, >>> > > I >> >>> > > want >>> > to >>> > > conditionaly delete some rows. However, it didn't give me the >>> > > correct >>> > number >>> > > of OBS. It seems to me that WHERE statement filtered out the >>> > > variables >>> > with >>> > > missing value by default. >>> > > >>> > > it dosen't make any sense!! >>> > > >>> > > >>> > > Am I missing something here or it is a BUG. >>> > > >>> > > Thanks! >>> > > >>> > > data test; >>> > > input id a b; >>> > > cards; >>> > > 1 . . >>> > > 2 3 4 >>> > > 3 4 5 >>> > > 4 99 99 >>> > > 5 . . >>> > > ; >>> > > run; >>> > > >>> > > proc export data=test >>> > > outfile='c:\test.xls' >>> > > dbms=excel replace; >>> > > sheet=test; >>> > > run; >>> > > >>> > > libname try excel 'c:\test.xls'; >>> > > data test1; >>> > > set try.test; >>> > > where a ~=99 and b ~=99; >>> > > run; >>> > > proc print; >>> > > run; >>> > > >>> > >>>

Hi, Sigurd, I think I see your point now. Can we explain this behavior like this: When Where clause is applied directly on the external data source( EXCEL tables and ALL other DB tables), we have to test the NULL OR missing explicitly. however, once the data is imported into SAS as a SAS dataset, we don't have to test NULL or Missing any more. I think the sample code I provided can prove it. In a summary, it is a TIMING issue. THIS Is NOT A BUG. If i am still wrong, please correct me. Thank you so much for your professional comments. Yu On 8/19/07, Sigurd Hermansen <HERMANS1@westat.com> wrote: > > Art: > As I understand the post, Yu Zhang has reported in one of the parallel > threads that the WHERE statement behaves differently under the > SAS/Access engine than when applied to a SAS dataset. Now it appears > that we have Data step - SAS dataset, Data step - SAS/Access to ????, > and SQL rules for comparisons of missing and NULL values in WHERE > clauses and statements. I haven't tested whether the IF statement works > consistently in the first two contexts. > > To paraphrase one of my colleagues, 'All I know about SAS I've learned > on SAS-L'. Most of the finer points, I know. > > SAS-L once again confirms the old adage that two heads work better than > one. Only on the 'L we have thousands of head cases working better than > one. All for free. Who could ask for more. > S > > -----Original Message----- > From: owner-sas-l@listserv.uga.edu [mailto:owner-sas-l@listserv.uga.edu] > On Behalf Of Arthur Tabachneck > Sent: Friday, August 17, 2007 8:56 PM > To: SAS-L@LISTSERV.UGA.EDU; Tom Cross > Subject: Re: Is this a BUG??? > > > Tom, > > Based on Sig's comment, I was going to respond to your post indicating > that it isn't engine specific. > > However, fortunately I tested it first and, indeed, it IS engine > specific. > > data test; > input id a b; > cards; > 1 . . > 2 3 4 > 3 4 5 > 4 99 99 > 5 . . > ; > run; > > data want; > set test; > where a ~=99 and b ~=99; > run; > > works the same as subsetting if statements. I would call this one a bug > and now wonder if it is limited to the excel engine. > > Art > ---------- > On Fri, 17 Aug 2007 19:50:13 -0400, Tom Cross <tom.cross@KP.ORG> wrote: > > >As Roy suspected, the data are processed correctly when the WHERE is > >replaced by the subsetting IF. > > > >25 data test1; > >26 set try.test; > >27 if a ~=99 and b ~=99; > >28 run; > > > >NOTE: There were 5 observations read from the data set TRY.test. > >NOTE: The data set WORK.TEST1 has 4 observations and 3 variables. > > > >Bug or feature? It looks like WHERE is the term to be avoided when > >working with this engine. -Tom > > > >On Fri, 17 Aug 2007 18:04:54 -0400, Sigurd Hermansen > ><HERMANS1@WESTAT.COM> > >wrote: > > > >>Yes, I see that now. x=99 resolves to NULL when x is NULL, and (NULL > >>OR > >>NULL) remains undefined for the same reasons as before. On Friday > >>afternoon's my logic tends to wander about a bit. > >>Thanks, > >>S > >> > >>-----Original Message----- > >>From: data _null_; [mailto:datanull@gmail.com] > >>Sent: Friday, August 17, 2007 5:55 PM > >>To: Sigurd Hermansen > >>Cc: SAS-L@listserv.uga.edu > >>Subject: Re: Is this a BUG??? > >> > >> > >>The more concise version works the same way as the original posted by > >>Yu. SAS is echoing it to the log as WHERE (a not = 99) and (b > >>not = 99); > >> > >>19 data test1; > >>20 set try.test; > >>21 /*where a ne '99' and b ne '99';*/ > >>22 /*WHERE (a ~= 99 OR a IS NULL) AND (b ~= 99 OR b IS > NULL);*/ > >>23 WHERE NOT (a=99 OR b=99); > >> > >>NOTE: There were 2 observations read from the data set TRY.test. > >> WHERE (a not = 99) and (b not = 99); > >>NOTE: The data set WORK.TEST1 has 2 observations and 3 variables. > >> > >>On 8/17/07, Sigurd Hermansen <HERMANS1@westat.com> wrote: > >>> The IF statement would more likely work as expected. The WHERE > >>> statement in a Data step works more like a SQL WHERE, and, in SQL, > >>> the > >> > >>> NOT EQUALS operator does not return a True value when one of the > >>> operands has a MISSING or NULL value. Known trap for the unwary ... > >>> Try the condition > >>> > >>> ... WHERE (a ~= 99 OR a IS NULL) AND (b ~= 99 OR b IS NULL) > >>> > >>> or more concisely, > >>> > >>> ... WHERE NOT (a=99 OR b=99) [equivalent by deMorgan's law]. > >>> > >>> In the trinary logic of SQL, NULL or MISSING means undefined, and in > > >>> that logic one does not know whether a variable isn't equal to > >>> another > >> > >>> if that value is undefined. I avoid using NOT EQUALS for other > >>> reasons > >> > >>> as well. S > >>> > >>> -----Original Message----- > >>> From: owner-sas-l@listserv.uga.edu > >>> [mailto:owner-sas-l@listserv.uga.edu] > >>> On Behalf Of Pardee, Roy > >>> Sent: Friday, August 17, 2007 5:25 PM > >>> To: Yu Zhang; SAS-L@LISTSERV.UGA.EDU > >>> Subject: RE: Re: Is this a BUG??? > >>> > >>> > >>> What happens if you change your WHERE to an IF? Any difference? > >>> > >>> -----Original Message----- > >>> From: SAS(r) Discussion [mailto:SAS-L@LISTSERV.UGA.EDU] On Behalf Of > > >>> Yu Zhang > >>> Sent: Friday, August 17, 2007 2:11 PM > >>> To: SAS-L@LISTSERV.UGA.EDU > >>> Subject: Re: Is this a BUG??? > >>> > >>> However, when you get the data in another dataset, then do the > >>> subsetting, it works. > >>> > >>> What is going on?? it implies that we have to be very carefull when > >>> we > >> > >>> subset the data read in with libname EXCEL engine. > >>> > >>> Anyone has some idea about this? > >>> > >>> > >>> data test1; > >>> set try.test; > >>> *where a ~=99 and b ~=99; > >>> run; > >>> > >>> data test2; > >>> set test1; > >>> where a ~=99 and b ~=99; > >>> run; > >>> > >>> > >>> On 8/17/07, data _null_; <datanull@gmail.com> wrote: > >>> > > >>> > I think it must a "chicken and egg" thing, but I can't explain > >>> > it.. > >>> > > >>> > Sub setting if does work properly. > >>> > > >>> > On 8/17/07, Yu Zhang <zhangyu05@gmail.com> wrote: > >>> > > Hi, ALL, > >>> > > > >>> > > I am using LIBNAME to read the EXCEL data into SAS. after that, > > >>> > > I > >> > >>> > > want > >>> > to > >>> > > conditionaly delete some rows. However, it didn't give me the > >>> > > correct > >>> > number > >>> > > of OBS. It seems to me that WHERE statement filtered out the > >>> > > variables > >>> > with > >>> > > missing value by default. > >>> > > > >>> > > it dosen't make any sense!! > >>> > > > >>> > > > >>> > > Am I missing something here or it is a BUG. > >>> > > > >>> > > Thanks! > >>> > > > >>> > > data test; > >>> > > input id a b; > >>> > > cards; > >>> > > 1 . . > >>> > > 2 3 4 > >>> > > 3 4 5 > >>> > > 4 99 99 > >>> > > 5 . . > >>> > > ; > >>> > > run; > >>> > > > >>> > > proc export data=test > >>> > > outfile='c:\test.xls' > >>> > > dbms=excel replace; > >>> > > sheet=test; > >>> > > run; > >>> > > > >>> > > libname try excel 'c:\test.xls'; > >>> > > data test1; > >>> > > set try.test; > >>> > > where a ~=99 and b ~=99; > >>> > > run; > >>> > > proc print; > >>> > > run; > >>> > > > >>> > > >>> >

Yu: I would call it a 'trap' instead of a bug or a timing issue. I haven't tested different situations as yet, but it appears that the behavior of the Data step WHERE statement depends on the data access engine in play: SQL rules apply when comparing NULL values in at least some database and document tables; SAS Data step rules when applied to missing values in a SAS database. I'll certainly check what rules apply under various conditions. I haven't seen SAS documentation that explains when to expect what. S -----Original Message----- From: owner-sas-l@listserv.uga.edu [mailto:owner-sas-l@listserv.uga.edu] On Behalf Of Yu Zhang Sent: Sunday, August 19, 2007 1:18 PM To: SAS-L@listserv.uga.edu Subject: Re: Is this a BUG??? Hi, Sigurd, I think I see your point now. Can we explain this behavior like this: When Where clause is applied directly on the external data source( EXCEL tables and ALL other DB tables), we have to test the NULL OR missing explicitly. however, once the data is imported into SAS as a SAS dataset, we don't have to test NULL or Missing any more. I think the sample code I provided can prove it. In a summary, it is a TIMING issue. THIS Is NOT A BUG. If i am still wrong, please correct me. Thank you so much for your professional comments. Yu On 8/19/07, Sigurd Hermansen <HERMANS1@westat.com> wrote: > > Art: > As I understand the post, Yu Zhang has reported in one of the parallel > threads that the WHERE statement behaves differently under the > SAS/Access engine than when applied to a SAS dataset. Now it appears > that we have Data step - SAS dataset, Data step - SAS/Access to ????, > and SQL rules for comparisons of missing and NULL values in WHERE > clauses and statements. I haven't tested whether the IF statement > works consistently in the first two contexts. > > To paraphrase one of my colleagues, 'All I know about SAS I've learned > on SAS-L'. Most of the finer points, I know. > > SAS-L once again confirms the old adage that two heads work better > than one. Only on the 'L we have thousands of head cases working > better than one. All for free. Who could ask for more. S > > -----Original Message----- > From: owner-sas-l@listserv.uga.edu > [mailto:owner-sas-l@listserv.uga.edu] > On Behalf Of Arthur Tabachneck > Sent: Friday, August 17, 2007 8:56 PM > To: SAS-L@LISTSERV.UGA.EDU; Tom Cross > Subject: Re: Is this a BUG??? > > > Tom, > > Based on Sig's comment, I was going to respond to your post indicating > that it isn't engine specific. > > However, fortunately I tested it first and, indeed, it IS engine > specific. > > data test; > input id a b; > cards; > 1 . . > 2 3 4 > 3 4 5 > 4 99 99 > 5 . . > ; > run; > > data want; > set test; > where a ~=99 and b ~=99; > run; > > works the same as subsetting if statements. I would call this one a > bug and now wonder if it is limited to the excel engine. > > Art > ---------- > On Fri, 17 Aug 2007 19:50:13 -0400, Tom Cross <tom.cross@KP.ORG> > wrote: > > >As Roy suspected, the data are processed correctly when the WHERE is > >replaced by the subsetting IF. > > > >25 data test1; > >26 set try.test; > >27 if a ~=99 and b ~=99; > >28 run; > > > >NOTE: There were 5 observations read from the data set TRY.test. > >NOTE: The data set WORK.TEST1 has 4 observations and 3 variables. > > > >Bug or feature? It looks like WHERE is the term to be avoided when > >working with this engine. -Tom > > > >On Fri, 17 Aug 2007 18:04:54 -0400, Sigurd Hermansen > ><HERMANS1@WESTAT.COM> > >wrote: > > > >>Yes, I see that now. x=99 resolves to NULL when x is NULL, and (NULL > >>OR > >>NULL) remains undefined for the same reasons as before. On Friday > >>afternoon's my logic tends to wander about a bit. Thanks, > >>S > >> > >>-----Original Message----- > >>From: data _null_; [mailto:datanull@gmail.com] > >>Sent: Friday, August 17, 2007 5:55 PM > >>To: Sigurd Hermansen > >>Cc: SAS-L@listserv.uga.edu > >>Subject: Re: Is this a BUG??? > >> > >> > >>The more concise version works the same way as the original posted by > >>Yu. SAS is echoing it to the log as WHERE (a not = 99) and (b > >>not = 99); > >> > >>19 data test1; > >>20 set try.test; > >>21 /*where a ne '99' and b ne '99';*/ > >>22 /*WHERE (a ~= 99 OR a IS NULL) AND (b ~= 99 OR b IS > NULL);*/ > >>23 WHERE NOT (a=99 OR b=99); > >> > >>NOTE: There were 2 observations read from the data set TRY.test. > >> WHERE (a not = 99) and (b not = 99); > >>NOTE: The data set WORK.TEST1 has 2 observations and 3 variables. > >> > >>On 8/17/07, Sigurd Hermansen <HERMANS1@westat.com> wrote: > >>> The IF statement would more likely work as expected. The WHERE > >>> statement in a Data step works more like a SQL WHERE, and, in SQL, > >>> the > >> > >>> NOT EQUALS operator does not return a True value when one of the > >>> operands has a MISSING or NULL value. Known trap for the unwary > >>> ... Try the condition > >>> > >>> ... WHERE (a ~= 99 OR a IS NULL) AND (b ~= 99 OR b IS NULL) > >>> > >>> or more concisely, > >>> > >>> ... WHERE NOT (a=99 OR b=99) [equivalent by deMorgan's law]. > >>> > >>> In the trinary logic of SQL, NULL or MISSING means undefined, and > >>> in > > >>> that logic one does not know whether a variable isn't equal to > >>> another > >> > >>> if that value is undefined. I avoid using NOT EQUALS for other > >>> reasons > >> > >>> as well. S > >>> > >>> -----Original Message----- > >>> From: owner-sas-l@listserv.uga.edu > >>> [mailto:owner-sas-l@listserv.uga.edu] > >>> On Behalf Of Pardee, Roy > >>> Sent: Friday, August 17, 2007 5:25 PM > >>> To: Yu Zhang; SAS-L@LISTSERV.UGA.EDU > >>> Subject: RE: Re: Is this a BUG??? > >>> > >>> > >>> What happens if you change your WHERE to an IF? Any difference? > >>> > >>> -----Original Message----- > >>> From: SAS(r) Discussion [mailto:SAS-L@LISTSERV.UGA.EDU] On Behalf > >>> Of > > >>> Yu Zhang > >>> Sent: Friday, August 17, 2007 2:11 PM > >>> To: SAS-L@LISTSERV.UGA.EDU > >>> Subject: Re: Is this a BUG??? > >>> > >>> However, when you get the data in another dataset, then do the > >>> subsetting, it works. > >>> > >>> What is going on?? it implies that we have to be very carefull > >>> when we > >> > >>> subset the data read in with libname EXCEL engine. > >>> > >>> Anyone has some idea about this? > >>> > >>> > >>> data test1; > >>> set try.test; > >>> *where a ~=99 and b ~=99; > >>> run; > >>> > >>> data test2; > >>> set test1; > >>> where a ~=99 and b ~=99; > >>> run; > >>> > >>> > >>> On 8/17/07, data _null_; <datanull@gmail.com> wrote: > >>> > > >>> > I think it must a "chicken and egg" thing, but I can't explain > >>> > it.. > >>> > > >>> > Sub setting if does work properly. > >>> > > >>> > On 8/17/07, Yu Zhang <zhangyu05@gmail.com> wrote: > >>> > > Hi, ALL, > >>> > > > >>> > > I am using LIBNAME to read the EXCEL data into SAS. after > >>> > > that, > > >>> > > I > >> > >>> > > want > >>> > to > >>> > > conditionaly delete some rows. However, it didn't give me the > >>> > > correct > >>> > number > >>> > > of OBS. It seems to me that WHERE statement filtered out the > >>> > > variables > >>> > with > >>> > > missing value by default. > >>> > > > >>> > > it dosen't make any sense!! > >>> > > > >>> > > > >>> > > Am I missing something here or it is a BUG. > >>> > > > >>> > > Thanks! > >>> > > > >>> > > data test; > >>> > > input id a b; > >>> > > cards; > >>> > > 1 . . > >>> > > 2 3 4 > >>> > > 3 4 5 > >>> > > 4 99 99 > >>> > > 5 . . > >>> > > ; > >>> > > run; > >>> > > > >>> > > proc export data=test > >>> > > outfile='c:\test.xls' > >>> > > dbms=excel replace; > >>> > > sheet=test; > >>> > > run; > >>> > > > >>> > > libname try excel 'c:\test.xls'; > >>> > > data test1; > >>> > > set try.test; > >>> > > where a ~=99 and b ~=99; > >>> > > run; > >>> > > proc print; > >>> > > run; > >>> > > > >>> > > >>> >

Similiar Articles:

Bug in resource editor? - comp.compilers.lcc
When I have an icon in the resource directory (in the editor, not the file system), and I add a second icon to the "Icon" subdirectory, it overwrite...

Bug? Gettting ghostscript to programmatically convert ps to pdf on ...
Bug? Gettting ghostscript to programmatically convert ps to pdf on ... I've been wrestling with this for an hour or so and thought I'd share my experiences.

Bug in SVM or just bad device path? - comp.unix.solaris
Hello All. I have a software raid 5 partition that has a problem with relocation information: # metadevadm -r -v Invalid device relocation inform...

getaddrinfo() bug ? - comp.unix.solaris
Hello, I'm trying to use postgresql libpq.a on solaris 10 (sparc) in 64 bits mode. libpq.a (9.0.1) is statically linked to my program. This...

BUG: simulink 7.6 (r2010b) and visual c++ 2010 compiler - comp ...
I believe that there is a bug in matlab R2010b. I work with win 7 64bit so I installed Visual C++ 2010 Express and Windows SDK 7.1 as it is suggest...

initializer must be constant error bug? - comp.compilers.lcc ...
Jacob, I sent this once, not sure if it went through? I'm getting the error " initializer must be constant" from code such as: void foo(int x, int ...

Bug in proccgi - comp.unix.programmer
I am looking at proccgi.c by Frank Pilhofer. There appears to be a bug in the ParseString function. If I provide an input field "mouse sign. The res...

addtodate bug? - comp.soft-sys.matlab
I don't see why the output of this code should change as shown below. clc dv_cur = [ 2010 5 12 7 30 0]; dt_cur = datenum(dv_cur); dv_end = [...

bug in eps terminal 'Can't find PostScript prologue' - comp ...
I get this as soon as I use the eps terminal: gnuplot> load 'gnuplot.plt' Can't find PostScript prologue file C:\Program Files\gnuplot\\share/Po...

Bug or wrong configuration? - comp.unix.solaris
Hallo everyone. I was searching for unowned files on my system (solaris 10 6/06) and i found that all the onwned files on my system was from compresse...

Token Type bug - help? - comp.text.pdf
I've been distributing a PDF that's quite important to me. But of several hundred people to receive it, a handful have told me they get problems on ...

bug with MATLAB example avifile - comp.soft-sys.matlab
hi I tried to run the code from the matlab help in the section of avifile. t = linspace(0,2.5*pi,40); fact = 10*sin(t); fig=figure; aviobj = av...

Async IO bug - comp.databases.oracle.server
Hi, After the installation of patch set 10.2.0.5, we seem to be hitting bug 9949948: "Linux: Process spin under ksfdrwat0 if OS Async IO not conf...

undefined references in MikTex 2.9 --- bug? - comp.text.tex ...
Hi, I recently upgraded to MikTex 2.9 and find that my documents do not process properly any more. There are tons of undefined references to entr...

Wildcard bug in matlab (linux version) - comp.soft-sys.matlab ...
In matlab 2010a I am running into a problem with the use of wildcards ( ?) in the dir command on linux operating systems (but not on windows). I run ...

BUG - Own It On DVD September 25
A lonely waitress with a tragic past, Agnes rooms in a run-down motel, living in fear of her abusive, recently paroled ex-husband. But when Agnes begins a tentative ...

Insect - Wikipedia, the free encyclopedia
Insects (from Latin insectum, a calque of Greek ἔντομον [éntomon], "cut into sections") are a class of living creatures within the arthropods that have a ...

7/18/2012 2:31:53 AM