LatticeData里的An的矩阵好像给成了Bn
E6 E7没有数据
是不是bug

c[x_] = Sum[x^2^i, {i, 0, Infinity}]
N[ResidueSum[{c[x], Abs[x] < 0.1}, x]]
\:6B63\:5728\:8BA1\:7B97In[5]:= ResidueSum::ncsol: 无法求出在 \!\(\*UnderoverscriptBox[\(\[Sum]\), \(i = 0\), \(\[Infinity]\)]\*SuperscriptBox[\(x\), SuperscriptBox[\(2\), \(i\)]]\) 在解集 Abs[x]<0.1 中的的残差和.
\:6B63\:5728\:8BA1\:7B97In[5]:= NSum::nsnum: 被加数（或者它的导数）x^2^i 在点 i = 46661 不是数值的.
\:6B63\:5728\:8BA1\:7B97In[5]:= NSum::nsnum: 被加数（或者它的导数）x^2^i 在点 i = 46661 不是数值的.
\:6B63\:5728\:8BA1\:7B97In[5]:= NSum::nsnum: 被加数（或者它的导数）x^2^i 在点 i = 46661 不是数值的.
\:6B63\:5728\:8BA1\:7B97In[5]:= General::stop: 在本次计算中，NSum::nsnum 的进一步输出将被抑制.
\:6B63\:5728\:8BA1\:7B97In[5]:= ResidueSum::ncsol: 无法求出在 NSum[x^2^i,{i,0,\[Infinity]}] 在解集 Abs[x]<0.1 中的的残差和.
\:6B63\:5728\:8BA1\:7B97In[5]:= ResidueSum::ncsol: 无法求出在 NSum[x^2^i,{i,0,\[Infinity]}] 在解集 Abs[x]<0.1 中的的残差和.
\:6B63\:5728\:8BA1\:7B97In[5]:= General::stop: 在本次计算中，ResidueSum::ncsol 的进一步输出将被抑制.
Out[5]= ResidueSum[{NSum[x^2^i, {i, 0, \[Infinity]}], Abs[x] < 0.1},
x]

In[7]:= FunctionPoles[{c[x], Abs[x] < 0.1}, x]
\:6B63\:5728\:8BA1\:7B97In[7]:= FunctionPoles::ncsol: 无法在 Abs[x]<0.1 的解集内求出 \!\(\*UnderoverscriptBox[\(\[Sum]\), \(i = 0\), \(\[Infinity]\)]\*SuperscriptBox[\(x\), SuperscriptBox[\(2\), \(i\)]]\) 的极点.
Out[7]= FunctionPoles[{\!\(
\*UnderoverscriptBox[\(\[Sum]\), \(i = 0\), \(\[Infinity]\)]
\*SuperscriptBox[\(x\),
SuperscriptBox[\(2\), \(i\)]]\), Abs[x] < 0.1}, x]

这个没有极点 但就是求不出来

1楼的问题太模糊，而且我也不懂晶体学，就不发表意见了。
关于2楼和3楼：算不出来一般不认为是bug，就我所知，目前Mathematica里应该没有哪个代数变换函数可以对
未计算的合式进行符号分析。（至少文档里没有相关例子。）——当然了，实践中确实发现过个别孤例，比如SE帖子《Backslide of Limit》（mathematica.stackexchange.com/q/64633/1871）下面的这个例子（注意，在较新的版本里这个现象已经无法重现）：
但这个例子没有推广价值。

LatticeData["A3", "GeneratorMatrix"] // Normal
输出的是B3的
和英文维基百科写的不一样(Root System)

还有个问题 给2f那个函数在单位圆内绘图(把求和上限改成24~36)时内存占用极大

还有，不相关的问题请尽量别挤一个帖里，你这样搞，今后别人想搜相关内容可能会出现麻烦。

虽然7楼说得不清楚，但我好像猜出来LZ指的是啥了。这个问题或许该算是对极端情形的优化不足。总之，下面这样是没问题的：
但是，如果把c的定义中的 2. 改成 2 （注意这里的区别！）就会出现内存狂飙的问题，这似乎和Plot系函数的符号预处理机制有关——使用Echo包裹x，会发现ComplexPlot直接使用了边界值-1-I（注意，是准确值，不是机器精度的-1. - 1. I）去试探c[z]的取值，而c[z]在-1-I处的
准确取值嘛……
上面所说的应该不是唯一的原因，因为把ComplexPlot的第二参数改成{z, -1. - I, 1. + I}虽然也可以回避内存问题，但代码需要执行12秒左右。原因一时搞不清。

Sum[x^f[i],{i,0,Infinity}] 其中f:N->N 为严格递增函数
在单位圆内必定解析
mma还是不够强 不能判断级数的收敛半径

一个点就能改变巨大的内存 离谱

为什么时间变长了?(12700H)

看样子13.1版以降（也许是13.0开始的？）ComplexPlot出现了严重的性能退化。这似乎依旧是试探导致的问题。（可是明明都设了RegionFunction，ComplexPlot还在域外疯狂试探是想干嘛呢……）总之，还能抢救一下：
Clear[c];
c[x_] := Total@Table[x^2.^i, {i, 0, 36}]
ComplexPlot[If[Abs[z] < 1, c[z], 7.2 10^284], {z, -1 - I, 1 + I},
RegionFunction -> Function[{z}, Abs[z] <= 1], Exclusions -> None,
PlotLegends -> Automatic] // AbsoluteTiming

刚检查了一下，这个直接试探左边界的奇怪机制在版本9时代不存在。具体哪版引入的不明。
可以使用以下代码进行检查：
Plot[Sin[Echo@x], {x, 123/457, 7}, MaxRecursion -> 0, PlotPoints -> 2]