1. no input file specified.，matlab自动生成的矩阵如何命名？
eval([strcat(name,'=yy');]);
其中eval函数用来执行字符命令
eval Execute string with MATLAB expression.
eval(EXPRESSION) evaluates the MATLAB code in the string EXPRESSION.
[OUTPUT1,...,OUTPUTN] = eval(EXPRESSION) returns output from EXPRESSION
in the specified variables.
Example: Interactively request the name of a matrix to plot.
expression = input('Enter the name of a matrix: ','s');
if (exist(expression,'var'))
plot(eval(expression))
end
2. 5G标准会议联想投票事件的真相是怎样的？
真相只有一个，本来这件事我也是看的云里雾里的，后来实在忍不住自己当了一回侦探，给你们还原一下推理破案现场：
名词说明：
1、长码：information block size of eMBB data> X（X值待定，128 <= X <=1024 bits）。
2、短码：information block size of eMBB data <= X。
3、FFS：有待决定的意思。
4、WF：Way-forward ，是3GPP在技术讨论完之后的提案。
5、Turbo code (turbo码，以欧洲公司为主)
6、LDPC code（低密度奇偶校验码，以高通为主)
7、Polar code (极化码，以华为为主)
8、TBCC (咬尾卷集码，以欧洲公司为主)
9、Possible Agreements（会议打算通过的决议）
10、 Agreements（会议通过的决议，一般不会改）
11、NR（应该是“新表决”的意思）
第一节、技术说明Polar code被采用为控制信道的编码，但这个既不是长码也不是短码，因为长短码只属于数据信道编码的讨论范畴，有的人说控制信道编码也分长码和短码，这是错误的说法。
数据和控制信道的区别和联系：
所谓数据信道（也就是有长短码区别的）：传输的是用户所要传递的数据，视频浏览，微信短信，电话服务等等。
所谓控制信道（这个没有长短码之分）：传输的是有关数据信道的信息，譬如，数据在哪里传，数据块的大小，等一些控制信息。
通常来说，数据信道编码所需要的码长范围远远大于控制信道，且数据信道编码需要支持高速率数据传输，相对控制信道而言有更高的硬件要求。下面表格1总结了数据信道和控制信道比较常见的码块信息比特长度。
表格1：数据信道和控制信道码块信息比特长度的通常范围
数据信道 ：Info Bit K From 40 to 6,000~8,000
控制信道 ：Info Bit K 20~100 (一般场景)
控制信道 ：Info Bit K Up to 300 bits (极端场景)
这个表格的例子列举了常见的数据信道和控制信道所要支持的信道编码码块长度。一个数据信道码块长度从40-bit到6,000～8,000-bit。一个数据信道的传输块可以包含几十甚至成百上千的码块，换而言之，数据信道的数据量可以比控制信道高几个数量级。而控制信道的码长一般在100以内便可以覆盖大部分应用场景（此处数据参照4G LTE，5G的控制信道设计尚未完成，具体范围是否变化还待定）。这并不意味着控制信道编码不如数据信道编码重要（而只是说明两种信道需要的码长范围不同），事实上恰恰相反，控制信道编码解码对5G整个的延时，功耗等都有着深远的影响。
控制信道的码长虽短，但却并不隶属于“长码”和“短码”中的任何一类。
其实3GPP标准中本无所谓长码短码的概念，报道中常见的长码短码来自于2016年10月里斯本（3GPP RAN1）会议关于“增强型移动宽带（eMBB）的数据码”的讨论。
2016年10月里斯本RAN1的决议[2]摘录见附录1。四点决定非常清楚：
a. 数据信道长码(informationblock size > X)用LDPC
b. 数据信道短码(informationblock size ≤ X)用Turbo, LDPC或者是Polar 有待3GPP 2016年11月份雷诺会议上再做决定
c. 长码短码载荷分界线 X 在128到1024 bit之间, X的具体值有待3GPP十一月雷诺会议决定。
d. 控制信道和URLLC（超可靠低时延通信）和mMTC（大规模物联网）的编码有待研究.
原文：
-------------------------------------------------------------
Agreement:
a、“The channel coding scheme for eMBB datais LDPC, at least for informationblock size > X
b、FFS until RAN1#87 one of Polar, LDPC, Turbo is supportedfor information block size ofeMBB data <= X
c、The value of X is FFS until RAN1#87, 128 <= X <=1024 bits, taking complexity into account
d、The channel coding scheme(s) for URLLC, mMTC and control channels are FFS”
-------------------------------------------------------------
由此可见，长码短码指的都是数据信道编码（a和b）。
控制编码的讨论是另外的研究课题（包含在d里面）。
也就是说Polar code最终被采用的是控制信道的编码，既不是数据码中的“长码”也不是“短码”。
而且控制信道编码，主要的争夺其实是在TBCC和Polar之间展开，具体的技术讨论也只是在2016年11月雷诺会议上才展开。控制信道编码本来不必在雷诺会议上决定，但作为数据控制信道编码一揽子妥协方案的一部分，最终决定以Polar code取代4G采用的TBCC。
第二节、Polar与LDPC之争对于大多数公司来说，LDPC用于长码，几乎是无可争议，也是为了达到高吞吐率和硬件的高效率所必需的。绝大多数公司都认可即便短码有其他选择，长码都必须要用LDPC。
争议的地方在于短码，也就是最终的数据信道编码到底采用LDPC+LDPC、LDPC+Turbo还是LDPC+Polar？这也是这次联想投票的主要焦点！
一、长短码投票（2016年10月10日-14日 里斯本会议）：原文：
-------------------------------------------------------------
Question: How many channel coding schemes should be specified for the NR eMBB data channel:
1、（单一编码方案）:
① LDPC（长码和短码都用LDPC，LDPC+LDPC）: Ericsson, Sony, Sharp, Nokia, ASB, Samsung, Intel, QC, VzW, KT, IITH, IITM, Fujitsu, MotM（摩托罗拉移动部门）, Lenovo（联想）, KDDI
② Polar（长码和短码都用Polar，Polar+Polar）: HW（HUAWEI）
2、（组合编码方案）:
①T+L（长码用LDPC，短码用Turbo，LDPC+Turbo） Accelercomm, IMT, LG, NEC, Fujitsu, Orange
②L+P （长码用LDPC，短码用Polar，LDPC+Polar）ZTE, Etisalat, Mediatek, Nubia, Xiaomi, Coolpad, Neul, HW devices, OPPO, CATR, TDTech, Spreadtrum, Potevio, ITRI, IDC, DT, NTU
Note that the above questions give an approximate picture, though not necessarily complete.
Possible Agreements（打算通过，也就是初步的决定，这里Polar+Polar就出局了）:
Alt 1（LDPC+LDPC）:
- The channel coding scheme for eMBB data is LDPC（长短编码都为LDPC）
No（反对票24票）: HW, IDC, HiSi, DT, NEC, CMCC, LG, Spreadtrum, Neul, CATR, Xinwei, TDTech, OPPO, Coolpad, Xiaomi, HW Devices, ITRI, Mediatek, Accelercom, Nubia, IMT, Orange, ZTE, ZTE Microelectronics
Alt 2（LDPC+Polar）:
- The channel coding scheme for eMBB data is LDPC, at least for blocks larger than X（长码方案为LDPC）
- Polar coding is supported for eMBB data for blocks smaller than X （短码编码为Polar）
No（反对票27票）: Sams, NEC, Intel, QC, LG, Nokia, ASB, MotM（摩托罗拉移动部门）, Lenovo（联想）, KT, Ericsson, CableLabs, ITL, Sequans, Acorn, Asustek, Mitsubishi, KDDI, Wilus, Accelercom, IMT, Orange, Sony, Sharp, Fujitsu, VzW, Docomo
Alt 3（LDPC+Turbo）:
- The channel coding scheme for eMBB data is LDPC, at least for blocks larger than X（长码编码为LDPC）
- Turbo coding is supported for eMBB data for blocks smaller than X（短码编码为Tubor）
No（反对票33票）: HW, IDC, HiSi, Sams, Nok, ASB, KT, QC, Asustek, Spreadtrum, Mitusbishi, CATR, Xinwei, TDTech, OPPO, Intel, Coolpad, Neul, Wilus, Xiaomi, ITRI, Mediatek, Nubia, ZTE, ZTE Microelectronics, HW Devices, CableLabs, ITL, DT, VzW, KDDI, Acorn, Docomo
-----------------------------------------------------------
里斯本会议最终结果：原文：
Agreement:（最终通过）
①、The channel coding scheme for eMBB data is LDPC, at least for information block size > X（长码编码最终选用LDPC，这个无异议）
·②、 FFS until RAN1#87 one of Polar, LDPC, Turbo is supported for information block size of eMBB data <= X（短码编码待定，决定在2016年11月14日-18日的雷诺会议上再从Polar，LDPC和Turbo中挑一个作为最终的短码编码）
③、The selection will focus on all categories of observation, including overall implementation complexity, regardless of the number of coding schemes in the resulting solution (except if other factors are generally roughly equal)
·④、The value of X is FFS until RAN1#87, 128 <= X <= 1024 bits, taking complexity into account
⑤、The channel coding scheme(s) for URLLC, mMTC and control channels are FFS
-------------------------------------------------------------
这里可以看到，联想在选长短码的时候确实选了高通的方案，而且明确反对了华为的方案。
二、短码投票（2016年11月14日-18日 雷诺会议）很遗憾，翻遍里斯本和雷诺会议记录，我并没有找到相关投票记录，也就是说短码可能是直接讨论就通过了，反正我找不到短码的投票记录。
这也意味着联想关于短码投票这种说法，可能并不存在，他仅有的两次关于数据信道长短码的投票，一次将赞成票投给了高通的LDPC+LDPC，一次将反对票投给了华为LDPC+Polar。
（以上是2018年5月12日我的观点，之前是用关键词eMBB data channels（eMBB是5G的一个应用场景，这里可以简单看做是5G移动通讯信道编码）查找，并没有找到短码投票。2018年5月16日柳总发表声明后，我重新阅读了一下雷诺会议全文，发现确实有第二轮短码的投票，这是新的发现，补充一下）
1、第二轮短码投票，Turbo争取短码编码的投票：
原文：
---------------------------------------------------------------
R1-1613347 （这是第二轮Turbo争取短码编码的投票的提案）WF on channel codes for NR short block length eMBB data AccelerComm, Ericsson, Orange, IMT, LG Electronics, NEC
Proposal（建议）:
- Turbo code is adopted for information block size of eMBB data <= 1024（提议Turbo作为短码编码方案。奇怪的一点是，这里关于长短码设定的X值是1024bits，但后来X值好像变成了256bits，这些会议记录真是看的人头疼）
- Note: if some system design constraints are found during the work item, it may be desirable to revisit the value of 1024
---------------------------------------------------------------
2、第二轮短码投票，Polar争取短码编码的投票：
原文：
---------------------------------------------------------------
R1-1613307 （这是第二轮Polar争取短码编码的投票，我之前看错了，把它当做控制信道的编码投票了。这里联想确实投了Polar作为短码编码的赞成票，我之前说没有第二轮短码投票的说法是错误的！）WF on channel coding Huawei, HiSilicon, Acer, ADI, Aeroflex, Alibaba, Bell Mobility, Broadcom, CATR, CATT, Coolpad, Coherent Logix, CHTTL, CMCC, China Telecom, China Unicom, Dish Network, ETISALAT, Fiberhome, Hytera, IAESI, III, Infineon, InterDigital, ITRI, Irdeto, Lenovo（联想）, Marvell, MediaTek, Motorola Mobility（摩托罗拉移动部门）, National Taiwan University, Netas, Neul, Nubia Technology, OOREDOO, OPPO, Potevio, SGS Wireless, Skyworks, Sporton, Spreadtrum, SRTC, Starpoint, STMicroelectronics, TD-Tech, Telekom Research & Development Sdn. Bhd, Telus, Toshiba, Turk Telekom, Union Telephone, Vivo, Xiaomi, Xilinx, Xinwei, ZTE, ZTE Microelectronics
Bureau Veritas withdrew their support.
Proposal（建议）:
• Polar is supported as the channel coding scheme for DL and UL eMBB data with information block up to 1024 bits（提议Polar作为短码编码方案，这里界定长短码的X值还是1024bits）
Objections（反对票）: Ericsson, Qualcomm, Nokia, ASB, Samsung, LG, ETRI, KT, VzW, Intel, Docomo, IMT, KDDI, NEC
Proposal（建议）:
• Polar is supported as the channel coding scheme for DL and UL eMBB data with information block up to 255 bits（提议Polar作为短码编码方案，这里界定长短码的X值应该变成256bits了，≥256bits应该为长码，≤255bits应该为短码。）
---------------------------------------------------------------
3、第二轮短码投票，LDPC争取短码编码的投票：
原文：
R1-1613342（这是第二轮LDPC争取长短码的投票，这一轮应该确定了信道编码长短码都采用LDPC了） WF on channel coding for eMBB data Samsung, Acorn Technologies, Alcatel-Lucent Shanghai Bell, Ceragon Networks, Cohere Technologies, Ericsson, ETRI, European Space Agency, HCL Technologies limited, IAESI, Intel Corporation, ITL, KDDI, KT Corporation, Mitsubishi Electric, Motorola Solutions, NextNav, NEC, Nokia, Nomor Research, NTT Docomo, Prisma telecom testing, Qualcomm Incorporated, Reliance Jio, Sharp, SK Telecom, Sony, Straight Path Communications, T-Mobile USA, Verizon Wireless, WILUS Inc
Proposal（建议）:
• Adopt LDPC code as the single code for eMBB data channels
Proposal（建议）:
• Adopt LDPC code as the single code for eMBB data channels at least for blocks >=256 bits
Proposal（建议）:
• Adopt LDPC code as the single code for eMBB data channels
• It is not precluded to adopt Polar code as an additional code for small eMBB data blocks if the concerns on IR HARQ are resolved（不排除接受Polar作为替补短码编码，前提是IR HARQ的问题得到解决。）
Proposal（建议）:
• Adopt LDPC code as the single code for eMBB data channels（接受LDPC作为唯一的信道编码，包括长码和短码）
• Adopt Polar code for a physical layer control channels（接受Polar编码作为物理层的控制信道编码）
-------------------------------------------------------------
这里可以看到华为的Polar编码可能还是存在一定缺陷的。
三、控制信道编码提案（主要是Polar和TBCC竞争，并没有看到LDPC）：1、Polar作为控制信道编码的提案：
原文：
-------------------------------------------------------------
R1-1613211（这应该是Polar的主要提案，我之前以为是推动Polar的提案，现在看来应该是主要提案，再吐槽一下3GPP的会议记录真难看懂。） WF on Channel Coding Huawei, HiSilicon, Acer, ADI, Aeroflex, Alibaba, Bell Mobility, Broadcom, CATR, CATT, Coolpad, Coherent Logix, CHTTL, CMCC, China Telecom, China Unicom, Dish Network, ETISALAT, Fiberhome, Hytera, IAESI, III, Infineon, InterDigital, ITRI, Irdeto, Lenovo（联想）, Marvell, MediaTek, Motorola Mobility（摩托罗拉移动部门）, National Taiwan University, Netas, Neul, Nubia Technology, OOREDOO, OPPO, Potevio, SGS Wireless, Skyworks, Sporton, Spreadtrum, SRTC, Starpoint, STMicroelectronics, TD-Tech, Telekom Research & Development Sdn Bhd, Telus, Toshiba, Turk Telekom, Union Telephone, Vivo, Xiaomi, Xinwei, ZTE, ZTE Microelectronics
Bureau Veritas and CGC withdrew their support（Bureau Veritas和CGC撤回赞成票）.
Proposal（建议）:
• Polar is supported as the channel coding scheme for DL and UL control channels for eMBB (except FFS for very small payloads)（提议Polar作为信道控制编码）
------------------------------------------------------------
2、TBCC作为控制信道编码的提案：
原文：
R1-1613577（TBCC的提案） WF on coding technique for control channel for eMBB LGE, AT&T, Ericsson, NEC, Qualcomm
Proposal:
• For DCI, tail-biting convolutional code (TBCC) is adopted as a channel coding technique for NR
• For UCI with encoder input size [16]<=K<=100 bits, TBCC is adopted as a channel coding technique for NR
• FFS: enhancements to LTE TBCC including generator polynomials with larger constraint length, lower native code rate
--------------------------------------------------------------
3、一个建议上行控制信道编码采用Polar，下行控制信道编码采用TBCC的提案，就是和稀泥的：
原文：
R1-1613248 （这个感觉像和稀泥的提案） WF on NR channel coding Verizon Wireless, AT&T, CGC, ETRI, Fujitsu, HTC, KDDI, KT, Mitsubishi Electric, NextNav, Nokia, Alcatel-Lucent Shanghai Bell, NTT, NTT DOCOMO, Samsung, Sierra Wireless, T-Mobile USA
Proposal（建议）:
• Adopt LDPC as the single channel code for uplink and downlink eMBB data channels for all relevant info block sizes（接受LDPC成为唯一的数据信道编码，包括长码和短码）
• Adopt Polar as the channel code for the uplink control information（接受Polar作为上行信道控制编码）
– FFS for very small block lengths where repetition/block coding may be preferred
Adopt TBCC as the channel code for the downlink control information（接受TBCC作为下行信道控制编码）
--------------------------------------------------------------
4、雷诺会议最终结果：原文：
--------------------------------------------------------------
Agreement:
①UL eMBB data channels（上行数据信道编码最终采用LDPC，包括长码和短码）:
a、 Working Assumption to adopt flexible LDPC as the single channel coding scheme for small block sizes (to be confirmed unless significant issues are identified by the RAN1 Jan adhoc in relation to performance, implementation complexity and flexibility)
b、 (Note that it is already agreed to adopt LDPC for large block sizes)
②、DL eMBB data channels（下行数据信道编码最终采用LDPC，包括长码和短码）:
a、 Adopt flexible LDPC as the single channel coding scheme for all block sizes
③、UL control information for eMBB（上行信道控制编码采用Polar）
a、 Adopt Polar Coding (except FFS for very small block lengths where repetition/block coding may be preferred)
④、DL control information for eMBB（下行信道控制编码采用Polar）
a、 Working Assumption to adopt Polar Coding (except FFS for very small block lengths where repetition/block coding may be preferred)
§ To be confirmed unless significant issues are identified by the RAN1 Jan adhoc in relation to performance, latency, power consumption and implementation complexity
第三节、总结综上，里斯本会议记录和雷诺会议记录里都没有出现短码的投票结果，也就是所谓的联想在短码上弃权导致华为输掉编码之争的说法，很可能是以讹传讹（2018年5月16日，特来说明一下，这里有误，确实有第二轮投票，联想也确实投了Polar）。
联想在第一次长短码编码上有过两次投票，一次是长短码编码方案的选择上投了高通LDPC+LDPC的赞成票；另外一次是在华为的LDPC+Polar上投了反对票，两次投票对华为都不利。
不过华为这边，也存在着Polar编码本质上的一些问题，说是IR HARQ的问题没有得到解决，这也是3GPP没有选用Polar作为短码编码方案的原因之一。
联想在信道控制编码上倒是投了华为的Polar，但这个确实对Polar最终赢得信道控制编码的结果影响不大。
下面贴出两次会议记录文件下载地址（主要看Report）：
1、里斯本会议（2016年10月）：http://www.3gpp.org/ftp/tsg_ran/WG1_RL1/TSGR1_86b/
2、雷诺会议（2016年11月）：http://www.3gpp.org/ftp/tsg_ran/WG1_RL1/TSGR1_87/
3. matlab如何保留五位小数？
1.数值型 roundn—任意位位置四舍五入
>>a=123.4567890;
>>a=roundn(a,-4)
a = 123.4568
其中roundn函数功能如下：
y = ROUNDN(x) rounds the input data x to the nearest hundredth. %不指定n，精确到百分位 y = ROUNDN(x,n) rounds the input data x at the specified power %精确到小数点后指定位数n
2.符号型
digits(4)
vpa(....)
必须说明:vpa命令不能识别整数与小数,只算总位数,因此对它来说小数整数无论哪个都占一位,例如对9.3154保留两位小数时就得写成:
>>a=9.3154;
>>digits(3)
>>b=vpa(a)
b= 9.32
其中b为符号型变量；
3.字符型
>>a=12.34567;
>>b = sprintf('%8.2f',a)
b = 12.35 其中b为字符型变量。
