Bookmark and Share

Notice: On April 23, 2014, Statalist moved from an email list to a forum, based at statalist.org.


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: st: duplicated datetime variable differs from original datetime variable it was derived from


From   Milena Przheska <[email protected]>
To   [email protected]
Subject   Re: st: duplicated datetime variable differs from original datetime variable it was derived from
Date   Tue, 12 Nov 2013 15:18:02 +0100

Dear Statalist members,

Thank you all for taking the time to help me with this situation, your
suggestions, lead me to the source of the problem (which I am
embarrassed to admit) was a clumsy typing mistake.

The thing was, I created a double variable time1 following Phil's
advice, but then, when breaking ties between the values of the
variable, instead of adding 1000 (the equivalent of 1 sec) I have
added 100, which I think created the problem with the type of the
variable, which was formatted as %9.0g. So I reformatted the variable
to %12.0g and added 1000 for breaking ties, and now the model is
running without errors (so far).

I am really sorry for the confusion and once I again thank you all for
your help.

Regards,
Milena

On Tue, Nov 12, 2013 at 2:45 PM, Nick Cox <[email protected]> wrote:
> We are collectively and individually pretty confused about your
> situation. Your original post implied clearly that -time1- was a
> float; now you say it's a double.
>
> To make progress, we need one and ideally all of the following:
>
> 1. A more complete statement of your code.
>
> 2. A more complete description of your data.
>
> 3. Code that can be replicated by others.
>
> Nick
> [email protected]
>
>
> On 12 November 2013 13:12, Sergiy Radyakin <[email protected]> wrote:
>> Milena, you have shown us your syntax
>> gen time1=time
>>
>> Contrary to your expectation you are not creating a duplicate
>> variable. You are creating a new variable of type FLOAT which would
>> hold the result of the computation, which happens to be just value of
>> another variable. Whatever that variable is, byte or double, Stata
>> would compute the result and store into a float, and in your case
>> loose precision.
>>
>> To create a proper duplicate, use -clonevar-.
>>
>> To confirm the types of the variables, use -describe-.
>>
>> Best, Sergiy Radyakin
>>
>> On Tue, Nov 12, 2013 at 7:34 AM, Milena Przheska
>> <[email protected]> wrote:
>>> I don't think so.
>>> The original time variable was obtained with the MySQL function
>>> FROM_UNIXTIME() and Stata automatically read it as a double.
>>> The reason I duplicated the variable is so I break ties between events
>>> that had same time stamp, without altering the original data.
>>> Maybe something in this process created the problem, but I did not use
>>> -float- type at all.
>>>
>>> On Tue, Nov 12, 2013 at 1:26 PM, Nick Cox <[email protected]> wrote:
>>>> My guess: you copied a -float- into a -double-. Doing that won't
>>>> restore the precision lost in using a -float- in the first place. It's
>>>> blown away in the wind, washed downriver.
>>>> Nick
>>>> [email protected]
>>>>
>>>>
>>>> On 12 November 2013 12:01, Milena Przheska
>>>> <[email protected]> wrote:
>>>>> The problem is that my time1 variable is double, and yet, when using
>>>>> it in the model, it gives that error message
>>>>>
>>>>> On Tue, Nov 12, 2013 at 12:54 PM, Nick Cox <[email protected]> wrote:
>>>>>> Same answer. Use a -double-.
>>>>>>
>>>>>> Nick
>>>>>> [email protected]
>>>>>>
>>>>>>
>>>>>> On 12 November 2013 11:51, Milena Przheska
>>>>>> <[email protected]> wrote:
>>>>>>> When I try to fit a mixed effects model with the time1 variable as
>>>>>>> defined above, I get an error message "time variable must be
>>>>>>> integer-valued".
>>>>>>>
>>>>>>> I do need the time variable to be by the second, otherwise I will have
>>>>>>> duplicate values for the time variable.
>>>>>>>
>>>>>>> If you have any suggestions, I would very much appreciate it.
>>>>>>>
>>>>>>> Thank you,
>>>>>>> Milena
>>>>>>>
>>>>>>> On Tue, Nov 12, 2013 at 12:41 PM, Nick Cox <[email protected]> wrote:
>>>>>>>> Phil has the answer in one. Unfortunately, you do have to keep
>>>>>>>> remembering that a date-time to Stata is just an integer, usually
>>>>>>>> large, giving time in milliseconds.
>>>>>>>>
>>>>>>>> . di %14.0f clock("07jun2012 03:11:48", "DMYhms")
>>>>>>>>  1654657908000
>>>>>>>>
>>>>>>>> Numbers that big have to be stored as -double-s.
>>>>>>>> Nick
>>>>>>>> [email protected]
>>>>>>>>
>>>>>>>>
>>>>>>>> On 12 November 2013 11:33, Phil Clayton <[email protected]> wrote:
>>>>>>>>> Dates with times need to be stored in double precision. Try:
>>>>>>>>> gen double time1=time
>>>>>>>>>
>>>>>>>>> See -help datetime-
>>>>>>>>>
>>>>>>>>> Phil
>>>>>>>>>
>>>>>>>>> On 12 Nov 2013, at 10:25 pm, Milena Przheska <[email protected]> wrote:
>>>>>>>>>
>>>>>>>>>> Dear Statalist members,
>>>>>>>>>>
>>>>>>>>>> When duplicating a time variable by typing
>>>>>>>>>>
>>>>>>>>>> gen time1 =time
>>>>>>>>>>
>>>>>>>>>> the new variable time1 is off by several seconds from the variable time, so
>>>>>>>>>>
>>>>>>>>>> time
>>>>>>>>>> 06jun2012 22:44:51
>>>>>>>>>> 06jun2012 22:44:54
>>>>>>>>>> 06jun2012 22:44:56
>>>>>>>>>> 07jun2012 01:39:58
>>>>>>>>>> 07jun2012 01:40:05
>>>>>>>>>> 07jun2012 01:40:45
>>>>>>>>>> 07jun2012 03:09:48
>>>>>>>>>> 07jun2012 03:09:48
>>>>>>>>>> 07jun2012 03:11:06
>>>>>>>>>>
>>>>>>>>>> becomes
>>>>>>>>>>
>>>>>>>>>> time1
>>>>>>>>>> 06jun2012 22:45:17
>>>>>>>>>> 06jun2012 22:45:17
>>>>>>>>>> 06jun2012 22:45:17
>>>>>>>>>> 07jun2012 01:40:03
>>>>>>>>>> 07jun2012 01:40:03
>>>>>>>>>> 07jun2012 01:40:03
>>>>>>>>>> 07jun2012 03:09:37
>>>>>>>>>> 07jun2012 03:09:37
>>>>>>>>>> 07jun2012 03:11:48
> *
> *   For searches and help try:
> *   http://www.stata.com/help.cgi?search
> *   http://www.stata.com/support/faqs/resources/statalist-faq/
> *   http://www.ats.ucla.edu/stat/stata/
*
*   For searches and help try:
*   http://www.stata.com/help.cgi?search
*   http://www.stata.com/support/faqs/resources/statalist-faq/
*   http://www.ats.ucla.edu/stat/stata/


© Copyright 1996–2018 StataCorp LLC   |   Terms of use   |   Privacy   |   Contact us   |   Site index