12

Actually, the title says it all. I am a little confused why such a complicated object as Graph, with many different parts, was designed to be atomic in Mathematica language such that, for example, function Part cannot be used on it.

J. M.'s missing motivation
  • 124,525
  • 11
  • 401
  • 574
Artem
  • 1,037
  • 10
  • 19
  • And how do you suppose to use Part on Graph? There is a Subgraph for subgraphs. – m0nhawk Sep 29 '16 at 15:37
  • I'm voting to close this question as off-topic because the question seems to be rhetorical -- merely a rant. It might be an acceptable question if it asked about extracting some property of a graph. – m_goldberg Sep 29 '16 at 21:42
  • 2
    @m_goldberg Rhetorical questions do not require any answers, whereas I am genuinely interested in the reasons why introduced in version 8 object Graph was decided to be atomic. – Artem Sep 29 '16 at 23:53
  • 2
    @Artem right, but the only ones who can answer that are the developers of the Graph functions. You could rephrase the question to be on topic. What do you want to get out of a Graph by using Part? You can get the vertices and edges through other means – Jason B. Sep 30 '16 at 01:20
  • 6
    I don't agree with closing. In MMA you can do whatever you want with expressions so if some of them get serious limitations there is clearly a reason. And while at the end only developers know, they are around as well as people who think alike and possibly have very plausible explanations. I'm not one of them but my guess is: may be that some of graph related functions are handled by low level code which requires a valid Graph structure one could destroy if they weren't atomic. – Kuba Sep 30 '16 at 08:02
  • The question of why Part does not work on Graph is different from why it is atomic. Packed arrays are also atomic, but none of the functionality lets you see this. This is because they assume the interface to packed arrays (mainly Part and Extract and arithmetic operations with other packed arrays) to remain stable. However, I think it would be foolish to pretend Graph is also just an ordinary expression with Parts that can be Extracted. IMO this doesn't make sense for any data structure consisting of parts of different types of data. – masterxilo Sep 30 '16 at 17:47
  • @masterxilo Try First@Plot[x, {x, -2, 2}] - Graphics is not atomic, but its parts are of wildly different types. I can understand the motivation for wanting Graph to be non-atomic, I have often wished to get the coordinates list from a MeshRegion using First. But I can get all the data I need from a MeshRegion using MeshCoordinates, MeshPrimitives, MeshCells, etc. – Jason B. Sep 30 '16 at 18:37
  • Likewise, you can access many parts of a Graph using built in functions, like VertexList, GraphEmbedding, etc. So if there is a particular property of a Graph that OP can't access, then that would be an on-topic question, IMO. – Jason B. Sep 30 '16 at 18:38
  • @JasonB The question is not about the functionality but about the underlying principles of Mathematica. Say, when I am teaching any math course, I can give very convincing reasons why we choose one or another definition. Now, if I teach Mathematica course and introduce atomic expressions, it is an extremely natural question to ask why, along with numbers, symbols and strings, Graphs are atomic. And I have no idea what to answer to such a question. – Artem Oct 01 '16 at 00:06

2 Answers2

11

Graph may be atomic to allow an optimized internal form. Graph operations are often computationally intensive and it makes sense to keep Graph data in a form that can be operated upon quickly, perhaps by external libraries, without the overhead of converting from a plain Mathematica expression every time. This is the case with Image I believe, which also is atomic.

Mr.Wizard
  • 271,378
  • 34
  • 587
  • 1,371
  • Thank you, but do not you think that similar explanation would work for many other objects (say, RandomFunction), which, however, are not atomic? – Artem Sep 30 '16 at 23:49
  • 1
    @Artem by RandomFunction do you mean the TemporalData expression it returns? If so I believe most of the processing that is done on TemporalData expressions is top-level Mathematica code, not C library level as I think a fair amount of the Graph functionality is. – Mr.Wizard Oct 02 '16 at 10:47
10

Graph being AtomQ has about the same implications as doing lots of overloadings of the type Part[_Graph,___] := Error[]; Replace[_Graph,___] := Error[]; .... It signifies that it is an "abstract data type" whose API (in the form of functions like VertexList) shall be the only way to interface with its contents. It would actually be nice to be able to do this type of thing automatically for user-defined "types" (heads of data structures), to ensure no-one relies on the current representation of the data as an expression.

Things are AtomQ for the same reason as internal data is declared private in the OO-world: Information hiding.

masterxilo
  • 5,739
  • 17
  • 39
  • Following the logic of Artem's comment under my answer above if this were the primary reason I would expect a number of other expressions like TemportalData, InterpolatingFunction, and TimeSeries to also be atomic as these have API's of this sort as well, but these are not atomic. Perhaps this is nothing more than inconsistency but I favor a different explanation. – Mr.Wizard Oct 02 '16 at 10:54