部分和跨度:是否有理由 * 不应该* 工作? [英] Part and Span: is there a reason this *should* not work?

问题描述

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

This is a question of design, not of existing functionality.

我想使用:

{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. >>

我不是问为什么这不起作用(简单:不支持).

I am not asking why this does not work (simple: it's not supported).

相反，它有什么理由不起作用?也就是说，是否有不支持的逻辑原因?

Rather, is there a reason it should not work? That is, is there a logical reason this is not supported?

顺便说一句，我并没有特别询问嵌套列表的语法，例如:

By the way, I specifically did not ask about the nested list syntax like:

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

因为我认为它不那么常规"且更不稳定，而 Span 更明确和可控.

because I believe that is less "regular" and more volatile, while Span is more defined and controlled.

推荐答案

我认为您要问的真正问题是为什么这不起作用:

I think the real question that you are asking is why this does not work:

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 似乎是在 Part 之上实现的更高级的包装器(这是一个猜测).同样的问题有人问过 最近在 MathGroup 上.没有一个令人满意的答案，我的感觉是，从用户的角度来看，这只是一个遗漏——我没有看到这不应该起作用的根本原因.此外，在某些情况下，此功能会让生活更轻松.

because Span seems to be a more high-level wrapper implemented on top of Part (this is a guess). This same question has been asked very recently on MathGroup. There wasn't a satisfactory answer, and my feeling is that from the user's viewpoint, this is just an omission - I don't see a fundamental reason why this should not work. Moreover, this feature would make life a lot easier in some cases.

从技术/实施的角度来看，我可以推测这将与扩展的Part 分配功能不一致.具体来说，我们知道 Part 不仅可以用于元素提取，还可以用于有效的元素分配，其中可以同时分配整个规则结构(矩形子矩阵)，如

From the technical/implementation viewpoint, I can speculate that this will go at odds with the extended Part assignment functionality. Specifically, we know that Part can be used not just for element extraction but for efficient element assignments, where whole regular structures (rectangular sub-matrices) can be assigned simultaneously, like

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 是否应该内置非常有效的参差不齐的数组结构(如链表)，这可以解决.

Should Part allow nested lists specification for positions, it should immediately provide assignment functionality for the non-rectangular sub-structures, or it will become much less intuitive to use (since there will be corner cases, etc). And I suspect that the latter is not easy to implement, because extended Part assignment functionality is probably based directly on the array memory layout. This will also create problems with packed arrays (for the same reason - they can not be ragged, must be rectangular). Perhaps, should Mathematica have very efficient ragged array structure (like linked lists) built-in, and this could be solved.

所以，总结一下:从实现的角度来看，这样的新功能似乎会带来几个棘手的问题，这可以解释为什么还没有这样做(再次，这是一个猜测).另请注意，对于元素提取，可以使用带有准备好的位置列表的 Extract 来提取任意子结构，这几乎与使用 Part 一样有效.

So, to summarize: it looks like, from the implementation viewpoint, such new functionality will introduce several tough problems, which may explain why this has not been done yet (again, this is a guess). Note also, that for element extraction, one can use Extract with prepared list of positions, to extract arbitrary substructures, and that will be almost as efficient as with using Part.

这篇关于部分和跨度:是否有理由 * 不应该* 工作?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！