Part and Span: есть ли причина, по которой это * не * не должно работать? - PullRequest
Новая
       19

Part and Span: есть ли причина, по которой это * не * не должно работать?

4 голосов
/ 30 мая 2011

Это вопрос дизайна, а не существующей функциональности.

Я хотел бы использовать: 

{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 более определенно и контролируется.

1 Ответ

7 голосов
/ 30 мая 2011

Я думаю, что реальный вопрос, который вы задаете, заключается в том, почему это не работает: 

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.Не было удовлетворительного ответа, и я чувствую, что с точки зрения пользователя это просто упущение - я не вижу фундаментальной причины, почему это не должно работать.Более того, в некоторых случаях эта функция значительно облегчит жизнь.

С технической точки зрения / с точки зрения реализации я могу предположить, что это будет идти вразрез с расширенной функциональностью назначения Part.В частности, мы знаем, что 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.

...