In Stata this is implemented by reshape long A, i(ID) j(Year). This is pretty common in panel data sets that are organized as wide. I think it’s on the radar since David opened an issue to look into this functionality: https://github.com/queryverse/Query.jl/issues/256.
It is simply untrue that the tidyverse is the only option for how to deal with data in R. I learned R before any of that existed and all of the stuff I used still exists and is used by many people. So if you think there is one true way to do it in R, that is only because you happen to be listening to just one predominant but relatively recent group of R developers. If there was one way to deal with data in R dictated by the core team, then the tidyverse wouldn’t exist at all.
Queryverse (this is a better link than the one posted before) is a collection of packages, and you can pick and chose which of those you want to use or not. Everything should entirely interop with pretty much every other data package on julia, so it certainly in no way is a “closed” ecosystem. The package Queryverse.jl is a meta-package that pulls in all the packages that make up the Queryverse. It loads a lot of stuff. For some folks that is convenient, but I for example typically use the individual packages individually.
AFAIU I would need to melt for each set separately, change the values of Year from (A2018,A2019) to (2018,2019) and then merge each melted DataFrame over (:ID,:Year).
Working on sets of variables is a very recent feature of tidyr and hasn’t been released in the stable version yet AFAIK. My point was not that Julia is years behind, but rather that OP can use RCall as an intermediate step for things that haven’t been implemented yet or it’s not clear how to implement them in Julia.
@B.Vangod This is a live demonstration of my workflow, using RCall until I learn how to do things in pure Julia and eventually get rid of R. But don’t hijack other people’s threads like I do
I guess you have some concerns about investing time in learning a package and then (i) the package being abandoned or is not very well maintained with accumulating bugs and (ii) doesn’t receive a lot of attention from the community and falls behind in terms of features. It’s very hard to predict what is going to happen to individual packages but since Julia 1.0 was released the ecosystem is maturing so at the very least you shouldn’t expect packages to break. DataFrames, DataFramesMeta, Plots and the Queryverse have many contributors, have been very reliable for years and you can easily get answers here and on Slack for anything that you are not sure how to implement.
For out-of-memory data you can use JuliaDB, JuliaDBMeta and Query from Queryverse (it works with both DataFrames and JuliaDB). This used to be my choice even for small datasets that fit in memory because I liked the syntax better. However, the transition from Julia 0.6 to Julia 1.0 was a bit tricky and slow and I switched to DataFrames in the meantime. I think now all the issues are resolved so you can also check this package out to see if you like it better that the DataFrames ecosystem. These packages play nice with each other so if you use JuliaDB but want to use a package that accepts DataFrames as an argument you can easily convert back and forth between a DataFrame and a JuliaDB table.
Yes - this is what would have to be done right now. If this feature would be useful then please open an issue on DataFrames.jl and we can think how to implement it. Alternatively you can stack and then unstack to get what you want:
