Path: csiph.com!newsfeed.hal-mli.net!feeder3.hal-mli.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!newsfeed.xs4all.nl!newsfeed6.news.xs4all.nl!xs4all!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail Return-Path: X-Original-To: python-list@python.org Delivered-To: python-list@mail.python.org X-Spam-Status: OK 0.009 X-Spam-Evidence: '*H*': 0.98; '*S*': 0.00; 'ascii': 0.07; 'padding': 0.07; 'bytes)': 0.09; 'cc:addr:python-list': 0.10; 'stored': 0.10; '-tkc': 0.16; '[*]': 0.16; 'from:addr:python.list': 0.16; 'from:addr:tim.thechases.com': 0.16; 'from:name:tim chase': 0.16; 'guessing': 0.16; 'inputs': 0.16; 'message-id:@tim.thechases.com': 0.16; 'processed.': 0.16; 'received:70.251': 0.16; 'received:dsl.rcsntx.swbell.net': 0.16; 'received:rcsntx.swbell.net': 0.16; 'received:swbell.net': 0.16; 'sequential': 0.16; 'written.': 0.16; 'wrote:': 0.17; 'variables': 0.17; 'input': 0.18; 'otherwise,': 0.20; 'written': 0.20; 'finally,': 0.22; 'cc:2**0': 0.23; 'external': 0.24; 'least': 0.25; 'cc:addr:python.org': 0.25; 'header:In-Reply-To:1': 0.25; 'header:User-Agent:1': 0.26; '---': 0.26; '(e.g.': 0.27; 'question': 0.27; 'smart': 0.29; 'thus,': 0.29; 'performing': 0.30; 'file': 0.32; 'ram': 0.33; 'utility': 0.33; 'handle': 0.33; 'saved': 0.35; 'data.': 0.36; 'problems': 0.36; 'subject: (': 0.36; 'being': 0.37; 'rather': 0.37; 'data': 0.37; 'subject:: ': 0.38; 'perform': 0.38; 'files': 0.38; 'some': 0.38; 'several': 0.39; 'subject:-': 0.40; 'save': 0.61; 'first': 0.61; 'series': 0.63; 'skip:n 10': 0.63; 'total': 0.65; 'reverse': 0.65; 'forward': 0.66; 'manner.': 0.66; 'manner': 0.74; 'disappointed': 0.84; 'received:50.22': 0.84; 'subject:Fast': 0.84; 'subject:read': 0.84; 'subject:write': 0.84; 'same,': 0.91 Date: Tue, 23 Oct 2012 11:09:58 -0500 From: Tim Chase User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111120 Icedove/3.1.16 MIME-Version: 1.0 To: Virgil Stokes Subject: Re: Fast forward-backward (write-read) References: <5086AA35.4000509@it.uu.se> In-Reply-To: <5086AA35.4000509@it.uu.se> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - boston.accountservergroup.com X-AntiAbuse: Original Domain - python.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - tim.thechases.com X-Source: X-Source-Args: X-Source-Dir: Cc: "python-list@python.org" X-BeenThere: python-list@python.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion list for the Python programming language List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Newsgroups: comp.lang.python Message-ID: Lines: 31 NNTP-Posting-Host: 2001:888:2000:d::a6 X-Trace: 1351008547 news.xs4all.nl 6914 [2001:888:2000:d::a6]:51485 X-Complaints-To: abuse@xs4all.nl Xref: csiph.com comp.lang.python:31936 On 10/23/12 09:31, Virgil Stokes wrote: > I am working with some rather large data files (>100GB) that contain time series > data. The data (t_k,y(t_k)), k = 0,1,...,N are stored in ASCII format. I perform > various types of processing on these data (e.g. moving median, moving average, > and Kalman-filter, Kalman-smoother) in a sequential manner and only a small > number of these data need be stored in RAM when being processed. When performing > Kalman-filtering (forward in time pass, k = 0,1,...,N) I need to save to an > external file several variables (e.g. 11*32 bytes) for each (t_k, y(t_k)). These > are inputs to the Kalman-smoother (backward in time pass, k = N,N-1,...,0). > Thus, I will need to input these variables saved to an external file from the > forward pass, in reverse order --- from last written to first written. > > Finally, to my question --- What is a fast way to write these variables to an > external file and then read them in backwards? Am I missing something, or would the fairly-standard "tac" utility do the reversal you want? It should[*] be optimized to handle on-disk files in a smart manner. Otherwise, if you can pad the record-lengths so they're all the same, and you know the total number of records, you can seek to Total-(RecSize*OneBasedOffset) and write the record,optionally padding if you need/can. At least on *nix-like OSes, you can seek into a sparse-file with no problems (untested on Win32). -tkc [*] Just guessing here. Would be disappointed if it *wasn't*.