Thanks Tamas! To summarize, yes, the data is loaded only once, and it stays alive. :)
Gabor On Fri, May 9, 2014 at 5:47 AM, Tamás Nepusz <[email protected]> wrote: > Tom, > > As far as I understand, the Rdata structure loaded from the file stays > “alive”. The reason is as follows. > > When you run the command that defines get_graph, everything within the > outermost curly brackets runs immediately. The code within the brackets > constructs a new environment, and then asks load() to load the contents of > the entire Rdata file into the environment - thus, the environment holds a > reference to the Rdata file and the contents of the file will stay alive as > long as the environment is alive. Next, we declare an inner function that > _references_ the environment, so the environment (and thus the Rdata > structure) will stay alive as long as someone has a reference to the inner > function. Finally, this inner function is returned to the top level and > stored in get_graph. The net result is that as long as get_graph is not > redeclared, it will be bound to a function, which holds a reference to > ‘env’, which holds a reference to the data loaded from the Rdata file. > That’s why get_graph() will not load the data file every time it is > invoked. When you invoke get_graph(), it will simply look up the graph you > need (since when you call get_graph, you are essentially calling the > innermost function). > > All the best, > -- > T. > > From: Tom Backer Johnsen [email protected] > Reply: Help for igraph users [email protected] > Date: 9 May 2014 at 08:20:07 > To: Help for igraph users [email protected] > Subject: Re: [igraph] Need for advice > > Gabor > > At the moment I have somewhat limited resources at hand, I am on vacation > in Spain and will be back in Norway this weekend. The I will have all the > normal resources of mine at hand. In any case, and as far as I understand, > the “load” operation is placed inside the function, which means that the > entire structure loaded from the RData file is eliminated by exit, right? > While only the desired structure is returned by the get_graph function. > Everything else is dead. > > I was somewhat stumped to begin with by the loading of the the entire > structure for each of the desired structures, but I think I see the > pattern. I am looking forward to test it! > > Tom > > On 8. May 2014, at 22:50 , Gábor Csárdi <[email protected]> wrote: > > > The good thing of Rdata is that it is super quick to read it. (Although > your data set is probably smallish. Many graphs, but they are individually > small.) The good thing of get_graph() is that you can change the actual > representation later, if it turns out to be bad. But I am probably just > repeating myself..... > > > > Gabor > > > > > > On Thu, May 8, 2014 at 4:44 PM, Tom Backer Johnsen <[email protected]> > wrote: > > Gabor > > > > Thanks for your suggestion. I’ll have to do some thinking about the > implications, both in respect to the use of a hierarchical and nested list > structure as well as saving the data in a separate RData file. Hmm. > Definitely interesting. Thanks! > > > > Tom > > > > On 8. May 2014, at 17:24 , Gábor Csárdi <[email protected]> wrote: > > > > > Hi Tom, > > > > > > I would create an Rdata file that contains all the data, and a > function that you can use to retrieve the graph you want. The graphs can be > in some nested named list, grouped by the groups, type of question, etc., > in an organization that is most logical for you. The retrieving function > could be created with something like this: > > > > > > get_graph <- (function() { > > > env <- new.env() > > > load("my-data-file-with-all-graphs.Rdata", envir=env) > > > function(group, at, question) { > env[["allgraphs"]][[group]][[at]][[question]] } > > > })() > > > > > > and then you can get your desired graph via get_graph(group="foo", > at=1, question="advice"). > > > > > > The advantage of not using the list directly is that if you change the > data format, file name, etc. you don't need to update the code. You can > also make the retrieving function more flexible, e.g. to retrieve all time > points for a question and group, etc. > > > > > > The advantage of the closure trick (i.e. to return a function that > will return the data, and then call it immediately) will make sure that you > only load the file once from the disk, and that the object itself is > hidden. > > > > > > Best, > > > Gabor > > > > > > > > > On Thu, May 8, 2014 at 5:44 AM, Tom Backer Johnsen < > [email protected]> wrote: > > > Gentlepersons. > > > > > > I need some advice on handling a relatively large number of graphs in > R. What I have is 128 graphs representing eight groups (each with 8 to 11 > members) at four times (repeats) where each subject was asked four types of > questions. In addition there are 20 groups which based on the same sample, > each with from 3 to 6 members, tested at four points in time with the same > set of questions. So, there are 448 different graphs. > > > > > > It was a fairly complex matter of entering the data from the original > forms (the data are old, collected in 1967), so I have written a program in > Lazarus (a Pascal GUI interface) which takes care of checking and > anonymization, where the end product is (at present) a long text file > containing the graphs in iGraph matrix format. Other formats are possible, > that is a minor matter. Each graph has a short descriptive name. > > > > > > I would prefer to use parts of iGraph (possibly other SNA packages as > well) to analyse the structures using the R / RStudio interface. I am quite > used to handle R, but have very limited experience with iGraph. > > > > > > So: Having to operate with 448 different files seems to be cumbersome, > but of course possible. I would however prefer to have all the graphs in > one database/file. I seem to remember having seen a reference to SQLite in > this list, but are there better/simpler alternatives? How does one extract > single graphs from the database? It would also be an advantage if the data > base could be generated by the program written in Lazarus / Free Pascal and > then accessed by R, but that transfer could be handled in several ways. > > > > > > Any suggestions? > > > > > > I am using a Mac OS X computer, where something like Wine may be > installed to be able to run Windows programs. > > > > > > Tom Backer Johnsen > > > Email: backer(at)psych.uib.no > > > > > > > > > _______________________________________________ > > > igraph-help mailing list > > > [email protected] > > > https://lists.nongnu.org/mailman/listinfo/igraph-help > > > > > > _______________________________________________ > > > igraph-help mailing list > > > [email protected] > > > https://lists.nongnu.org/mailman/listinfo/igraph-help > > > > Tom Backer Johnsen > > Søndre Steinkjellersmauet 7 > > 5003 Bergen > > Mobil: +47 9169 3346 > > Email: backer(at)psych.uib.no > > > > > > _______________________________________________ > > igraph-help mailing list > > [email protected] > > https://lists.nongnu.org/mailman/listinfo/igraph-help > > > > _______________________________________________ > > igraph-help mailing list > > [email protected] > > https://lists.nongnu.org/mailman/listinfo/igraph-help > > Tom Backer Johnsen > Søndre Steinkjellersmauet 7 > 5003 Bergen > Mobil: +47 9169 3346 > Email: backer(at)psych.uib.no > > > _______________________________________________ > igraph-help mailing list > [email protected] > https://lists.nongnu.org/mailman/listinfo/igraph-help > > > _______________________________________________ > igraph-help mailing list > [email protected] > https://lists.nongnu.org/mailman/listinfo/igraph-help > >
_______________________________________________ igraph-help mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/igraph-help
