Announcement

Collapse
No announcement yet.
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • -project, replicate- and .ster files.

    Dear Statalist.

    I use Robert Picard 's incredibly useful -project- command frequently. My workflow usually goes from datasets, to .ster files with estimation results, to tables and figures.

    I use -project, replicate- to check that my projects can be replicated from start to end. This basically runs the projects twice and checks the files for differences. I have noticed that the .ster files are always different between replications, even if the results have not changed. The files are checked for differences with the -checksum- command.

    Why would this be the case? Do .ster files include time-specific information? Robert Picard Is there a way to make -project- to compare .ster files the same way it compares log files, ignoring time-specific information?

    Thanks,
    Jorge Eduardo Pérez Pérez
    www.jorgeperezperez.com

  • #2
    Stata's .ster files indeed contain time stamps:

    Code:
    . sysuse auto, clear
    (1978 Automobile Data)
    
    . quietly regress mpg weight displ if foreign
    
    . estimates save myreg.ster
    file myreg.ster saved
    
    . type myreg.ster, starbang
    *! Stata(R) 015.10 Binary File Header_version 0010
    *! Date 07may2019 09:16:17                                      
    *! Byteorder LOHI
    *! Filetype estimates                        Version 0006
    *! <end_of_header>
    *! Date 07may2019 09:16:17                                      
    *! Byteorder LOHI
    *! Filetype estimates                        Version 0001
    *! <end_of_header>
    
    .
    Obviously, these files will differ at every replication build. I'm not particularly interested in making additional exceptions in project for files that Stata chooses to bless with a file stamp. I guess that one option is to just ignore lines in the replication report that indicate a change if they relate to .ster files. Another is to not declare dependencies for these files. These files are not results so for the purpose of a replication build, it should not matter.

    A more sophisticated approach is to set a global flag that you would use to indicate that you are performing a replication build. At the top level of the project's directory, you create a text file that contains:
    Code:
    local replicate 1
    if you are about to perform a replication build or
    Code:
    local replicate 0
    if not. Say this text file is called "replicate.txt". You can then, in any do-file, have commands run conditionally:
    Code:
    * top of do-file
    project, doinfo
    local pdir "`r(pdir)'"                            // the project's main dir.
    local dofile "`r(dofile)'"                        // do-file's stub name
    project, original("`pdir'/replicate.txt")
    include "`pdir'/replicate.txt"
    
    * eventually save one or more estimates
    estimates save "myreg1.ster"
    if !`replicate' project, creates("myreg1.ster")
    I use this technique when I use timers in my do-files. Since the timings change slightly at each run, I list them conditionally:
    Code:
    if !`replicate' timer list

    Comment


    • #3
      This is very useful, thanks. I'll probably just ignore the lines associated with .ster files in the replication report for my existing projects.

      Jorge Eduardo Pérez Pérez
      www.jorgeperezperez.com

      Comment

      Working...
      X