Thanks again :)
On Wed, Apr 10, 2013 at 1:53 PM, Anthony Scopatz wrote:
> On Wed, Apr 10, 2013 at 11:40 AM, Julio Trevisan
> wrote:
>
>> Hi Anthony
>>
>> Thanks again.* *If it is a problem related to floating-point precision,
>> I might use an Int64Col instead, since I don't need the timestamp
On Wed, Apr 10, 2013 at 11:40 AM, Julio Trevisan wrote:
> Hi Anthony
>
> Thanks again.* *If it is a problem related to floating-point precision, I
> might use an Int64Col instead, since I don't need the timestamp miliseconds.
>
Another good plan since integers are exact ;)
>
>
> Julio
>
>
>
>
>
Hi Anthony
Thanks again.* *If it is a problem related to floating-point precision, I
might use an Int64Col instead, since I don't need the timestamp miliseconds.
Julio
On Wed, Apr 10, 2013 at 1:17 PM, Anthony Scopatz wrote:
> On Wed, Apr 10, 2013 at 7:44 AM, Julio Trevisan
> wrote:
>
>> Hi
On Wed, Apr 10, 2013 at 7:44 AM, Julio Trevisan wrote:
> Hi,
>
> I am using a Time64Col called "timestamp" in a condition, and I noticed
> that the condition does not work (i.e., no rows are selected) if I write
> something as:
>
> for row in node.where("timestamp == %f" % t):
> ...
>
> Howeve
Hi,
I am using a Time64Col called "timestamp" in a condition, and I noticed
that the condition does not work (i.e., no rows are selected) if I write
something as:
for row in node.where("timestamp == %f" % t):
...
However, I had this idea of dividing the values by, say 1000, and it does
work:
