ok i understand float issues. it makes sense. after i had converted everything to double the query works. next thing, why do the sum/max/min/avg functions fail? ibis -d test2 -q "select max(x)"
tableSelect:: select(max(x), ) failed on table T-test2 On Jan 10, 2013, at 3:01 PM, [email protected] wrote: > Send FastBit-users mailing list submissions to > [email protected] > > To subscribe or unsubscribe via the World Wide Web, visit > https://hpcrdm.lbl.gov/cgi-bin/mailman/listinfo/fastbit-users > or, via email, send a message with subject or body 'help' to > [email protected] > > You can reach the person managing the list at > [email protected] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of FastBit-users digest..." > > > Today's Topics: > > 1. fastbit questions (Stanislav Seltser) > 2. Re: fastbit questions (Stanislav Seltser) > 3. Re: fastbit questions (K. John Wu) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 9 Jan 2013 23:54:56 -0500 > From: Stanislav Seltser <[email protected]> > Subject: [FastBit-users] fastbit questions > To: [email protected] > Message-ID: <[email protected]> > Content-Type: text/plain; charset="us-ascii" > > Question 1. ardea parsing > i have the following small dataset that i store in file data1.csv > x,y,color > 0.652,673.114,blue > 0.255,797.098,green > 0.541,173.007,green > 0.231,168.145,red > 0.233,34.526,red > 0.219,34.526,red > 0.722,520.938,blue > 0.541,438.962,green > 0.381,797.098,green > > i run the following command on it to build index directory > ardea -b "," -d test2 -b "," -t data1.csv -m x:float,y:float,color:key > > > ardea -d "test2" -v 0 > Will attempt to parse 1 CSV file > data1.csv > with the following column names and types > x:float,y:float,color:key > > > ardea to read CSV file data1.csv ... > ardea read 9 rows from data1.csv > > now i run ibis query tool > ibis -d test2 -q "select color" > > "blu" > "gree" > "re" > > what happen to last character?? > > Question #2 > why the exact match query does not work?? > ibis -d test2 -q "select color where x=0.652" > > doQuaere -- "SELECT color WHERE x=0.652" produced a table with 0 row and 0 > column > doQuaere -- the result table (0 x 0) for "SELECT color WHERE x=0.652" > > but the range query works just fine > ibis -d test2 -q "select x,color where x <0.66 and x>0.65" > > doQuaere -- "SELECT x,color WHERE x <0.66 and x>0.65" produced a table with > 12 rows and 2 columns > doQuaere -- the first row (of 12) from the result table for "SELECT x,color > WHERE x <0.66 and x>0.65" > 0.652, "blu" > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > http://hpcrdm.lbl.gov/pipermail/fastbit-users/attachments/20130109/c8708dbf/attachment-0001.htm > > > ------------------------------ > > Message: 2 > Date: Thu, 10 Jan 2013 00:02:02 -0500 > From: Stanislav Seltser <[email protected]> > Subject: Re: [FastBit-users] fastbit questions > To: [email protected] > Message-ID: <[email protected]> > Content-Type: text/plain; charset="us-ascii" > > so i was to trace the first issue to dos line endings. once i had convert the > file to unix endings the first question gets resolved. > the second is still a problem. > On Jan 9, 2013, at 11:54 PM, Stanislav Seltser <[email protected]> wrote: > >> Question 1. ardea parsing >> i have the following small dataset that i store in file data1.csv >> x,y,color >> 0.652,673.114,blue >> 0.255,797.098,green >> 0.541,173.007,green >> 0.231,168.145,red >> 0.233,34.526,red >> 0.219,34.526,red >> 0.722,520.938,blue >> 0.541,438.962,green >> 0.381,797.098,green >> >> i run the following command on it to build index directory >> ardea -b "," -d test2 -b "," -t data1.csv -m x:float,y:float,color:key >> >> >> ardea -d "test2" -v 0 >> Will attempt to parse 1 CSV file >> data1.csv >> with the following column names and types >> x:float,y:float,color:key >> >> >> ardea to read CSV file data1.csv ... >> ardea read 9 rows from data1.csv >> >> now i run ibis query tool >> ibis -d test2 -q "select color" >> >> "blu" >> "gree" >> "re" >> >> what happen to last character?? >> >> Question #2 >> why the exact match query does not work?? >> ibis -d test2 -q "select color where x=0.652" >> >> doQuaere -- "SELECT color WHERE x=0.652" produced a table with 0 row and 0 >> column >> doQuaere -- the result table (0 x 0) for "SELECT color WHERE x=0.652" >> >> but the range query works just fine >> ibis -d test2 -q "select x,color where x <0.66 and x>0.65" >> >> doQuaere -- "SELECT x,color WHERE x <0.66 and x>0.65" produced a table with >> 12 rows and 2 columns >> doQuaere -- the first row (of 12) from the result table for "SELECT x,color >> WHERE x <0.66 and x>0.65" >> 0.652, "blu" >> > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > http://hpcrdm.lbl.gov/pipermail/fastbit-users/attachments/20130110/72705015/attachment-0001.htm > > > ------------------------------ > > Message: 3 > Date: Wed, 09 Jan 2013 21:28:55 -0800 > From: "K. John Wu" <[email protected]> > Subject: Re: [FastBit-users] fastbit questions > To: FastBit Users <[email protected]> > Cc: Stanislav Seltser <[email protected]> > Message-ID: <[email protected]> > Content-Type: text/plain; charset=ISO-8859-1 > > Hi, Stanislav, > > The problem with equality on floating-point number is a known problem > with the design of the floating-point number scheme. More > specifically, when you write 0.652 as text, you get three decimal > digits after the decimal point, however, depending on whether it is > represented as float or double, you will get different values in the > computer's memory. In your case, you happen to declare x as float, > but the value 0.652 in the query expression is represented as a > double, therefore the in-memory representation of these two values are > not the same. > > In general, one is discourage from perform floating-point value > equality comparisons in SQL statement - most DBMS systems have the > issue you are experiencing. If you really need equality comparison, > convert the number to integer. If you have to keep the values as > floating-point values, then use a range expression instead. > > John > > > On 1/9/13 9:02 PM, Stanislav Seltser wrote: >> so i was to trace the first issue to dos line endings. once i had >> convert the file to unix endings the first question gets resolved. >> the second is still a problem. >> On Jan 9, 2013, at 11:54 PM, Stanislav Seltser <[email protected] >> <mailto:[email protected]>> wrote: >> >>> Question 1. ardea parsing >>> i have the following small dataset that i store in file data1.csv >>> x,y,color >>> 0.652,673.114,blue >>> 0.255,797.098,green >>> 0.541,173.007,green >>> 0.231,168.145,red >>> 0.233,34.526,red >>> 0.219,34.526,red >>> 0.722,520.938,blue >>> 0.541,438.962,green >>> 0.381,797.098,green >>> >>> i run the following command on it to build index directory >>> ardea -b "," -d test2 -b "," -t data1.csv -m x:float,y:float,color:key >>> >>> / >>> / >>> /ardea -d "test2" -v 0/ >>> /Will attempt to parse 1 CSV file/ >>> /data1.csv/ >>> / with the following column names and types/ >>> /x:float,y:float,color:key/ >>> >>> >>> ardea to read CSV file data1.csv ... >>> ardea read 9 rows from data1.csv >>> >>> now i run ibis query tool >>> ibis -d test2 -q "select color" >>> / >>> / >>> /"blu"/ >>> /"gree"/ >>> /"re"/ >>> / >>> / >>> /what happen to last character??/ >>> / >>> / >>> /Question #2/ >>> /why the exact match query does not work??/ >>> / >>> ibis -d test2 -q "select color where x=0.652" >>> >>> doQuaere -- "SELECT color WHERE x=0.652" produced a table with 0 row >>> and 0 column >>> doQuaere -- the result table (0 x 0) for "SELECT color WHERE x=0.652" >>> / >>> >>> but the range query works just fine >>> ibis -d test2 -q "select x,color where x <0.66 and x>0.65" >>> >>> doQuaere -- "SELECT x,color WHERE x <0.66 and x>0.65" produced a >>> table with 12 rows and 2 columns >>> doQuaere -- the first row (of 12) from the result table for "SELECT >>> x,color WHERE x <0.66 and x>0.65" >>> 0.652, "blu" >>> >> >> >> >> _______________________________________________ >> FastBit-users mailing list >> [email protected] >> https://hpcrdm.lbl.gov/cgi-bin/mailman/listinfo/fastbit-users >> > > > ------------------------------ > > _______________________________________________ > FastBit-users mailing list > [email protected] > https://hpcrdm.lbl.gov/cgi-bin/mailman/listinfo/fastbit-users > > > End of FastBit-users Digest, Vol 65, Issue 4 > ******************************************** _______________________________________________ FastBit-users mailing list [email protected] https://hpcrdm.lbl.gov/cgi-bin/mailman/listinfo/fastbit-users
