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]

From |
"Liao, Junlin" <junlin-liao@uiowa.edu> |

To |
"statalist@hsphsun2.harvard.edu" <statalist@hsphsun2.harvard.edu> |

Subject |
RE: st: best practice for dates and times |

Date |
Mon, 21 Feb 2011 18:21:27 +0000 |

Nick, Please note in previous code I had intentionally set type to float. -replace- still choose double for results of -clock-. Suppose I do another calculation, -replace- will choose float. Therefore, -replace- must know about -clock-. Junlin -----Original Message----- From: owner-statalist@hsphsun2.harvard.edu [mailto:owner-statalist@hsphsun2.harvard.edu] On Behalf Of Nick Cox Sent: Monday, February 21, 2011 12:09 PM To: 'statalist@hsphsun2.harvard.edu' Subject: RE: st: best practice for dates and times True. But it remains the case that -replace- knows nothing about -clock()-. It looks at the values and works out what the type should be, within limits. The inhibition about promoting from -float- to -double- I think follows from the rest of what Stata does here, as otherwise many if not most -float-s would morph into -double-s sooner or later, which, modulo views expressed earlier, would not match most intentions. Nick n.j.cox@durham.ac.uk Liao, Junlin If I understand Nick correctly, the functions will always do what they do, with double precision. It's the -gen- command finally did the trick to record numbers inaccurately. I expanded on Joseph's findings: set type float clear set obs 1 gen byte x=1 replace x=clock("1may2001 12:34","DMY hm") Interestingly, -replace- does convert the variable from byte (you can try any other numeric types other than float) to double, not float. However, if the variable is float to begin with, it will not be promoted to double. -replace- command is much smarter than -gen-. If you operate with date, it started with byte, it will figure out the most efficient way to store the data: when int is sufficient, it will not choose long, or if the date is large, it will choose long, not float or double. Nick Cox I note these evident inconsistencies as questions for StataCorp. Otherwise, we need to be clear here about the difference between functions such as -clock()- and commands such as -generate-. I don't think this request matches the way functions work. They just take inputs (in most cases) and produce outputs. I don't think that there is any sense in which they know about any wider context, as for example being part of a -generate- or -replace- command. Part of the magic of computing follows from very strong division of labour like this. I think what you and Junlin are asking is that -generate- (and -replace-) be smarter when the expression they are fed contains a call to e.g. -clock()-. That's a different request. My only bet is that this is much trickier than it seems, in principle as well as in practice. For example, even if -clock()- is part of the expression, it doesn't always follow that the user wants a -double- variable as a result. The spirit of the request is understandable, but I think there is a slippery slope ahead. Joseph Coveney I'm inclined to agree with Junlin on this. The user has to supply a mask for the date-time data as the second argument. It seems to me that the function should be able to determine from that information whether double-precision is needed, whether single-precision will be adequate, and even when integer will suffice. Stata is not entirely consistent in automatically detecting and setting the proper storage type. For example, back on the earlier thread, typing -generate y = 83085733- won't set the data type to the necessary precision, but opening the data editor and pasting 83085733 into the first cell and closing *does* set the data type to long. And, typing -generate float y = 1- and then -replace y = 83085733- won't automatically promote the data type to accommodate the larger value. On the other hand, first entering -generate byte y = 1- and then -replace y = 83085733- does. Junlin Liao wrote: . . . I thought -clock- or -Clock- would be smart enough to figure it out by itself. . . . I think there again is a chance for Stata to get smart. * * For searches and help try: * http://www.stata.com/help.cgi?search * http://www.stata.com/support/statalist/faq * http://www.ats.ucla.edu/stat/stata/ ________________________________ Notice: This UI Health Care e-mail (including attachments) is covered by the Electronic Communications Privacy Act, 18 U.S.C. 2510-2521, is confidential and may be legally privileged. If you are not the intended recipient, you are hereby notified that any retention, dissemination, distribution, or copying of this communication is strictly prohibited. Please reply to the sender that you have received the message in error, then delete it. Thank you. ________________________________ * * For searches and help try: * http://www.stata.com/help.cgi?search * http://www.stata.com/support/statalist/faq * http://www.ats.ucla.edu/stat/stata/

**Follow-Ups**:**RE: st: best practice for dates and times***From:*Nick Cox <n.j.cox@durham.ac.uk>

**References**:**st: best practice for dates and times***From:*"Liao, Junlin" <junlin-liao@uiowa.edu>

**Re: st: best practice for dates and times***From:*Nick Cox <njcoxstata@gmail.com>

**Re: st: best practice for dates and times***From:*Nick Cox <njcoxstata@gmail.com>

**RE: st: best practice for dates and times***From:*"Liao, Junlin" <junlin-liao@uiowa.edu>

**RE: st: best practice for dates and times***From:*Nick Cox <n.j.cox@durham.ac.uk>

**RE: st: best practice for dates and times***From:*"Liao, Junlin" <junlin-liao@uiowa.edu>

**Re: st: best practice for dates and times***From:*"Joseph Coveney" <jcoveney@bigplanet.com>

**RE: st: best practice for dates and times***From:*Nick Cox <n.j.cox@durham.ac.uk>

**RE: st: best practice for dates and times***From:*"Liao, Junlin" <junlin-liao@uiowa.edu>

**RE: st: best practice for dates and times***From:*Nick Cox <n.j.cox@durham.ac.uk>

- Prev by Date:
**RE: st: construct a loop** - Next by Date:
**RE: st: RE: RE: AW: Search for string values in dataset??** - Previous by thread:
**RE: st: best practice for dates and times** - Next by thread:
**RE: st: best practice for dates and times** - Index(es):