最近因为疫情的原因一直呆在家里，然后突然一个师兄找我要了个bed文件，然后我就从服务器上down下来给了他。但很快师兄就反馈说这个bed文件加载不到IGV里面去。一直出现这个报错。
然后我心里想，不应该啊，我之前明明从服务器上down到我的台式机上，然后成功用IGV加载了的，虽然里面的数据可能不太一样了，但应该都是一样的bed。为啥到他电脑就不行了，于是我强行启动我笔记本的IGV，结果也出现了报错。面对这种报错，我的第一反应是可能是IGV的版本不对，于是我重新下了最新的IGV，发现还是一样的错误。
然后我就懵逼了，只能去上网搜，网上只有有限几个类似的报错
- BED Parsing errors are more cryptic than they should be
- Error parsing line at byte position when uploading bed file
其中只有第二个是成功解决了的，他里面说
I figured out what was wrong. In one of the bed line, the address was written in scientific form. That's why IGV is throwing out an error.
对于 scientific form，我还是不太懂……所以我只能祭出最后一招，逐行逐行地去看bed文件（开玩笑的：））。我按顺序大块大块地部分复制了我原来那个bed文件，形成新的bed，载入IGV中，终于被我发现了有问题的那一行
Chr5 4e+05 400206 peak_19737 . .
然后终于跟之前对起来了，原来是科学计数法惹的祸。因为R会对一些大数字运用科学计数法，从而导致了40000变成了4e+05。而之前我一直没报错是因为我之前的bed文件很幸运地没有大的整数。
至于怎么解决这个问题，上网搜下就行。比如说你可以在输出bed的时候，设置下格式
write.table(format(merge_peak,scientific=FALSE),
file = "result/processed_result/merge_peak.bed",
quote = F,sep = "\t",
row.names = F,col.names = F,
)
也可以一开始就options下，比如说下面的意思就是在200个位以内不要使用科学计数法
options(scipen = 200)
最好还是用第二种方法，因为我发现第一种方法好像输出的不是一个正常的tab分割的文件
# 第一种输出的格式会变成这样 Chr1 30 875 Chr1 1392 1953 Chr1 2164 3625 Chr1 8268 8966 Chr1 13654 14698 Chr1 16512 16931 Chr1 20391 21655 Chr1 22671 23272 Chr1 33104 33997
