我在Linux Mint v12上运行Matlab R2011b和R版本2.13.1,内存为16 GB.
我有一个csv文件.前5行(和标题)是:
#RIC,Date[G],Time[G],GMT Offset,Type,Price,Volume
DAEG.OQ,07-JUL-2011,15:10:03.424,-4,Trade,1.68,1008
DAEG.OQ,07-JUL-2011,15:10:03.424,-4,Trade,1.68,1008
DAEG.OQ,07-JUL-2011,15:10:03.424,-4,Trade,1.66,300
DAEG.OQ,07-JUL-2011,15:10:03.424,-4,Trade,1.65,1000
DAEG.OQ,07-JUL-2011,15:10:03.464,-4,Trade,1.65,3180
文件很大(约900MB).鉴于字符和数字数据的组合,可以将此文件读入matlab,如下所示:
fid1 = fopen('/home/MyUserName/Temp/X.csv');
D = textscan(fid1, '%s%s%s%f%s%f%f', 'Delimiter', ',', 'HeaderLines', 1);
fclose(fid1);
虽然文件是900MB,但在运行上面的代码时,系统监视器表明我的RAM使用率从大约2GB跳到10GB.更糟糕的是,如果我尝试使用稍微大一点的csv文件(大约1.2 GB)进行相同的操作,我的RAM最大值为16GB,而Matlab从未设法读完数据(它只是停留在"忙碌"模式).
如果我想将相同的文件读入R,我可能会使用:
D <- read.csv("/home/MyUserName/Temp/X.csv", stringsAsFactors=FALSE)
这比Matlab要长一些,但系统监视器表明我的RAM使用率仅从2GB跳到3.3GB(考虑到原始文件大小,更合理).
我的问题有两个部分:
1)为什么textscan在这种情况下会出现这样的记忆？
2)我是否可以使用另一种方法在我的系统上将这种类型的1.2GB csv文件放入Matlab而不会超出RAM？
编辑:只是为了澄清,我很好奇是否存在一个仅限matlab的解决方案,即我对使用不同语言将csv文件分解为更小块的解决方案不感兴趣(因为这是什么我已经在做了).对不起Trav1s,我应该从一开始就明白这一点.
我想基于其包含的值来可视化矩阵.我有一个单元格,其中包含11个矩阵,每个矩阵有4列,分别是x,y,z(坐标)及其值.我想用位置x,y,z可视化这个值,并根据这些值定义我自己的色彩图,然后显示色条.我想用jet作为colormap.我想使用Blue来描述最大值,使用Red作为colormap上的最小值.最大值和最小值之间的值具有红色到蓝色之间的颜色.
这是我已经尝试过的代码:
figure;
hold on
for i=1:length(diameter_lca)
L2 = diameter_lca{i};
dl1 = find(L2(:,4) > minimal_lca & L2(:,4)<2);%diameter 0-2
dl2 = find(L2(:,4) >= 2 & L2(:,4) <= maksimal_lca);%diameter>2-maksimal
x=L2(:,1);
y=L2(:,2);
z=L2(:,3);
plot3(y(dl1),x(dl1),z(dl1),'*','Color','r');
plot3(y(dl2),x(dl2),z(dl2),'*','Color','b');
end
daspect([0.488281 0.488281 0.625000]);
view(3); axis tight
camlight
在上面的代码中,我所做的是从每个矩阵可视化第4列的值,然后我做了一个条件,如果值在0-2之间,我给了红色,当它在2 - 最大值之间时第四栏,我给了蓝色.
现在,我需要显示colormap jet中每个矩阵的第4列中的每个值,没有任何条件.
我必须做一些愚蠢的事,但我似乎无法使用Julia检索当前的用户名.最接近的函数Base似乎是gethostname(),但它返回计算机名称,而不是用户名.我尝试过系统调用但由于插值字符而遇到麻烦$.具体来说,尽管echo $USER在终端中返回相应的用户名,但当我在Julia中尝试以下内容时,我会收到各种错误或错误答案:
run(`echo $USER`)
run(`echo "$USER"`)
run(`echo '$USER'`)
run(`echo '$'USER`)
run(`echo \$USER`)
我想这个问题是Julia误解$为插值,但我不知道如何解决这个问题.
有任何想法吗？
设置:假设我有一个相当详细的软件(在Julia中),涉及几个模块的交互.我觉得它运行速度比应该慢.通常,要检查的第一个罪魁祸首是类型不稳定的函数,即编译器无法提前确定输出类型是什么的函数.
问题:如何检测这些类型不稳定的功能？
我目前所做的:我使用分析工具,例如@tholy的ProfileView.jl包来检测瓶颈,假设类型不稳定的函数将在这里显示(由于它们的运行时间过长).但是真正好的是某种调试工具,在运行例程之后,会吐出一个函数列表,其中编译器无法提前确定输出类型.这可能吗？
问题:如何使用Julia 检查变量的大小(以字节为单位)？
我试过的:在Matlab中,whos()函数提供了这个信息,但在Julia中只提供了变量名和模块.在Julia手册中浏览标准库sizeof()看起来很有希望,但它似乎只提供规范二进制表示的大小,而不是当前变量.
我打开一些文件：
myfilepath = "/home/colin/somefile.csv"
fid = open(myfilepath, "r")
我想从fid. 我可以用：
fid.name
这将返回如下内容：
"<file /home/colin/somefile.csv>
然而，据我所知，这并没有记录在案，所以我不能保证这个解决方案是面向未来的。
所以，我的问题是，是否有一种安全的方法可以IOStream从IOStream自身检索打开的文件路径？
为了生成随机矩阵,我使用了以下内容:
x =兰迪([ - 3,3],4)
但是我不希望输出矩阵中有任何零.我怎样才能做到这一点？
设置:我在Julia中有一个函数,它有两个输入,x和y.两个输入都是相同类型的数组,其中该类型可以是任何数字类型,Date,DateTime或String.注意,无论输入数组的上述任何元素类型如何,函数的内容都是相同的,所以我不想多次编写该函数.目前,我有这样定义的功能:
function MyFunc{T<:Number}(x::Array{T, 1}, y::Array{T, 1})
显然,这会处理数字大小写,但不会处理Date,DateTime或String.
问题:在Julia编写函数的第一行以适应其他类型时,最佳做法是什么？注意,性能很重要.
我的尝试:我可以尝试类似的东西:
function MyFunc{T<:Number}(x::Union(Array{T, 1}, Array{Date, 1}, Array{DateTime, 1}, Array{String, 1}) y::Union(Array{T, 1}, Array{Date, 1}, Array{DateTime, 1}, Array{String, 1}))
但这感觉很笨拙(或者可能不是？).
链接:我想这与我在Julia上的另一个Stack Overflow问题密切相关,可以在这里找到.
问题: Julia是否有严格的子类型运算符？
注意:操作员<:是不是一个严格的亚型运营商,因为Number <: Number计算结果为true.我感兴趣的运营商,将评估为false为Number <: Number,但true对Int <: Number.
可能的用例:考虑定义的函数:
MyFunc{T<:Union(Int, String)}(x::Array{T, 1}, y::Array{T, 1)})
目前,函数约束着x并y为相同的类型,其中该类型是阵列Int,String或Union(Int, String).但是使用严格的子类型运算符,我可以强制输入数组为类型Int或String,并消除(相当奇怪的)Union(Int, String)场景.
我在julia中建立了一个参数类型：
type MyType{T}
x::T
end
为了简单起见，我为以下对象构建类型别名Float64：
typealias MT MyType{Float64}
我现在故意造成涉及的错误MT。例如：
y1 = MyType(1.0)
y2 = MyType(2.0)
y1 + y2
会引发错误，因为+未为定义MyType。错误消息显示：
`+` has no method matching +(::MyType{Float64}, ::MyType{Float64})
我想说：
`+` has no method matching +(::MT, ::MT)
为什么？因为现实世界中的示例有时会比这个玩具示例复杂得多，并且类型别名的一个目的是使参数类型的复杂特定实例易于识别。因此，也很容易使它在错误消息中易于识别。
我尝试了什么？我最好的猜测是，错误函数string通过a 调用该函数DataType，以便在错误消息中生成适当的字符串。因此，对于我来说，可以string通过多次分派扩展功能以专门研究类型别名不是很明显，因此我对从何处去很困惑。