Syntax 第二部分和第二部分：这有什么理由不起作用吗？

这是一个设计问题，而不是现有功能的问题

我想使用：

{1, 2, 3, 4, 5}[[{1 ;; 3, 2 ;; 5}]]

我期望：

{{1, 2, 3}, {2, 3, 4, 5}}

但这是无效的：

During evaluation of In[1]:= Part::pspec: Part specification {1;;3,2;;5} is neither an integer nor a list of integers. >>

我不是在问为什么这不起作用（很简单：它不受支持）

相反，有没有理由认为它不应该起作用？也就是说，是否存在不支持此操作的逻辑原因

---

顺便说一下，我没有特别询问嵌套列表语法，例如：

{1, 2, 3, 4, 5}[[{{1, 2, 3}, {2, 3, 4, 5}}]]

---

因为我相信这是不太“常规”和更不稳定的，而

Span

则更具定义性和控制性。

我想你真正要问的问题是为什么这不起作用：

In[15]:= {1,2,3,4,5}[[{{1,2,3},{2,3,4,5}}]]

During evaluation of In[15]:= Part::pspec: Part specification 
{{1,2,3},{2,3,4,5}} is neither an integer nor a list of integers. >>

Out[15]= {1,2,3,4,5}[[{{1,2,3},{2,3,4,5}}]]

因为

Span

似乎是在

部分

之上实现的更高级的包装器（这是一个猜测）。最近，MathGroup也提出了同样的问题。没有令人满意的答案，我的感觉是，从用户的角度来看，这只是一个遗漏——我看不出这不起作用的根本原因。此外，在某些情况下，此功能将使生活更加轻松

从技术/实施的角度来看，我可以推测这将与扩展的

部分

分配功能不一致。具体地说，我们知道，

Part

不仅可以用于元素提取，还可以用于高效的元素分配，其中可以同时分配整个规则结构（矩形子矩阵），如

In[18]:= 
a = Table[i+j,{i,2},{j,4}]

Out[18]= {{2,3,4,5},{3,4,5,6}}

In[21]:= 
a[[All,{2,3}]] = {{7,8},{9,10}};
a

Out[22]= {{2,7,8,5},{3,9,10,6}}

如果

Part

允许位置的嵌套列表规范，则应立即为非矩形子结构提供赋值功能，否则使用起来会变得不那么直观（因为会出现角情况等）。我怀疑后者不容易实现，因为扩展的

Part

分配功能可能直接基于阵列内存布局。这也会给压缩数组带来问题（出于同样的原因-它们不能参差不齐，必须是矩形）。也许，Mathematica应该内置非常有效的不规则数组结构（如链表），这是可以解决的

---

因此，总而言之：从实现的角度来看，这样的新功能将引入几个棘手的问题，这也许可以解释为什么还没有做到这一点（同样，这是一个猜测）。另外请注意，对于元素提取，可以使用

Extract

和准备好的位置列表来提取任意子结构，这几乎与使用

Part

一样有效，谢谢，Leonid。另外，我更新了我的问题，问我为什么问

Span

@Mr.Wizard我明白你的意思，但是一旦你允许传递

Span

-s列表，个体

Span

的规则性就变得无关紧要了-你得到的子结构通常仍然是不规则的。我明白你的意思，但是我仍然认为它更容易控制，因为你不能用

Span

@Mr.Wizard输入像

a[[{{1，{2}，3，{4}}]

这样的东西，如果你允许

Span

-s的简单列表，那么没有理由不允许它们的嵌套列表（从一般设计的观点来看）。然后，我们开始（与您的表达式不完全相同，但相似）：

a[[{{1；；1，{2；；2}}，3；；3，{4；；4}]

@Mr.Wizard是的，你可以限制-但这会产生一些小问题，而且不是一个优雅的设计，而且，这仍然不能解决我提到的实现问题。哦，如果这些问题得到解决，一般形式可能也会被允许。我不反对

Span

在许多情况下是一个更直接的习惯用法，只是答：这里有一个更一般的设计问题。这是我非常错过的一个功能。我总是做

{1,2,3,4,5}[#]&/{1；；3,2；；5}

，如果内置的话会更好。Part甚至不允许列表中有一个

Span

。例如

部分[list[1,2,3,4,5]，{Span[3,4]]

。奇怪。