11
$\begingroup$

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.

|improve this question
$\endgroup$
  • $\begingroup$ And how do you suppose to use Part on Graph? There is a Subgraph for subgraphs. $\endgroup$ – m0nhawk Sep 29 '16 at 15:37
  • $\begingroup$ 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. $\endgroup$ – m_goldberg Sep 29 '16 at 21:42
  • 2
    $\begingroup$ @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. $\endgroup$ – Artem Sep 29 '16 at 23:53
  • 2
    $\begingroup$ @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 $\endgroup$ – Jason B. Sep 30 '16 at 1:20
  • 6
    $\begingroup$ 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. $\endgroup$ – Kuba♦ Sep 30 '16 at 8:02
11
$\begingroup$

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.

|improve this answer
$\endgroup$
  • $\begingroup$ Thank you, but do not you think that similar explanation would work for many other objects (say, RandomFunction), which, however, are not atomic? $\endgroup$ – Artem Sep 30 '16 at 23:49
  • 1
    $\begingroup$ @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. $\endgroup$ – Mr.Wizard♦ Oct 2 '16 at 10:47
10
$\begingroup$

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.

|improve this answer
$\endgroup$
  • $\begingroup$ 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. $\endgroup$ – Mr.Wizard♦ Oct 2 '16 at 10:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.