Le vendredi 20 février 2015 à 22:26 -0800, Viral Shah a écrit : > You could explore DataArrays. > https://github.com/JuliaStats/DataArrays.jl I guess you mean DataFrames? Indeed, the column names would provide the equivalent of your variables/subfields.
flows.out wouldn't be possible, but you can always create a names like flows_out, flows_in... to keep a mental representation of categories. Is that enough for you? > If you do not need to otherwise manipulate the whole array directly > (like say do an svd on the 100x30 matrix), and only work with the > fields, it would be best to create a composite type with those field > names. OTOH if you need a real array, not a set of columns, you can explore NamedArrays instead of DataFrames. Regards > -viral > > On Saturday, February 21, 2015 at 7:18:24 AM UTC+5:30, Pooya wrote: > Hi there, > > > I am new to Julia, trying to transfer all I do from MATLAB to > Julia. I have a bunch of matrices of numerical data (say > 100x30). In order to keep track of what each column is > representing, I defined different variables (say flows) whose > values were the associated column number in MATLAB. Now I can > use data(:,flows) instead of data(:,X), so I don't need to > worry about the column orders and numbers every time I need to > use the data. In order to avoid mistakes I was using "struct" > in MATLAB to avoid introducing many new variables into each > code that I have. Then all those constant values (column > numbers) were defined in a function (say myconstants) and when > I needed to use them, I would just say C = myconstants, and > then use C.flow for the column number. The problem is that > there are a few categories of these constants, and they all > have subfields with meaningful names and values representing > the column number in each matrix of data. In MATLAB all I > needed to define these was for example, C.flows.out = 5. > > > I am now thinking of the best way to handle this in Julia. I > have learnt a bit about immutable composite types. But first, > because they do not accept default values, the code will be > very messy with a lot of different fields. I am also not sure > if you can define the fields of an immutable to be an > immutable type itself. Is that possible? Any ideas on better > ways to handle this situation? In addition, if I use composite > types it seems that I am using a very powerful thing > (composite types) for a very basic application! Any thoughts > are greatly appreciated. > > > Thanks, > Pooya
