Skip to main content

Timeline for List of atomic expressions

Current License: CC BY-SA 4.0

39 events
when toggle format what by license comment
Apr 8, 2024 at 16:22 history edited Greg Hurst CC BY-SA 4.0
added 11 characters in body
Apr 8, 2024 at 16:15 history edited Greg Hurst CC BY-SA 4.0
added 11 characters in body
Nov 17, 2017 at 15:34 vote accept Greg Hurst
Nov 17, 2017 at 15:29 history edited Greg Hurst CC BY-SA 3.0
added 14 characters in body
Nov 17, 2017 at 15:23 history edited Greg Hurst CC BY-SA 3.0
added 14 characters in body
Jun 4, 2016 at 17:08 history edited J. M.'s missing motivation
edited tags
Mar 10, 2016 at 0:13 comment added Vladimir Reshetnikov You also can create an atomic list if you want: {AtomQ[Raw[List, ""]], Head[Raw[List, ""]]}. But I suppose it counts as cheating.
Mar 8, 2016 at 19:50 comment added Vladimir Reshetnikov Also, it may seem surprising that both AtomQ[Infinity] and AtomQ[ComplexInfinity] are False. Both symbols are converted to expessions with DirectedInfinity head when evaluated, but it remains hidden both in StandardForm and InputForm.
Mar 8, 2016 at 19:44 comment added Vladimir Reshetnikov Another word of caution: Hold[1/2], Hold[2^-1], Hold[Evaluate[1/2]] and Hold[Rational[1,2]] are all different expressions despite that some of them have the same FullForm and reported as identical by SameQ. Among them, Rational is atomic only in Hold[Evaluate[1/2]]. Also, it is not atomic in Rational[1, 2] &. So, Rational is not necessarily atomic, but only after it has had an opportunity to be evaluated. The same applies to other heads. The exact structure and atomicity of expressions may be not always preserved by Uncompress[Compress[…]]].
Mar 8, 2016 at 19:34 comment added Vladimir Reshetnikov Let me also note, that AtomQ[Underflow[]] is True. Underflow[][[0]] is Real, but Hold[Underflow[]][[1,0]] is Underflow. But Hold[Evaluate[Underflow[]]][[1, 0]] is Real again, despite that Hold[Underflow[]] and Hold[Evaluate[Underflow[]]] look identical in FullForm. The same note applies to Overflow[].
Sep 23, 2015 at 22:21 comment added Greg Hurst @Xavier Graphics objects are not atomic. Try running AtomQ[Graphics[{Circle[]}]] or First[Graphics[{Circle[]}]].
Sep 23, 2015 at 18:13 answer added yode timeline score: 17
Apr 30, 2015 at 6:37 history edited Greg Hurst CC BY-SA 3.0
Adds new atomic symbols introduced in 10.1
Oct 8, 2014 at 15:00 comment added ybeltukov Raw is outdated, but it is still atomic.
Oct 8, 2014 at 14:21 history edited Greg Hurst CC BY-SA 3.0
Adds Language`ArrayObject to the list
Aug 5, 2014 at 19:59 comment added Greg Hurst @Rojo Thank you!
Aug 5, 2014 at 19:59 history edited Greg Hurst CC BY-SA 3.0
added 13 characters in body
Aug 5, 2014 at 19:18 comment added Rojo Dataset is atomic
Aug 5, 2014 at 14:39 comment added Szabolcs @TaliesinBeynon ... or backwards compatibility, and has the potential to cause a lot of confusion. Of course the decision is up to you, I'm just trying to explain why Association is indeed AtomQ according to my mental model of what is atomic. It is definitely true that it is not as simple as "an expression which cannot be divided into subexpressions", but the real question is not whether AtomQ follows this definition. It is: which kind of AtomQ is a practically useful function? The actual one or the one that would be based on this simple definition?
Aug 5, 2014 at 14:39 comment added Szabolcs @TaliesinBeynon ... With[{a = Association[1 -> 2]}, Hold[a]]. But it doesn't, there are differences (again, part extraction, pattern matching). Also consider SparseArray, which also has parts, but again doesn't behave identically to its FullForm. SparseArray is also marked as AtomQ for this reason. Perhaps you could consider changing the description of AtomQ in the documentation instead of letting AtomQ return False for associations. What AtomQ really means is a bit complicated, but it's valuable to have it, and changing it would break either consistency ...
Aug 5, 2014 at 14:36 comment added Szabolcs @TaliesinBeynon I would find it confusing if Associations were not AtomQ. If an expression is compound (not atomic) that usually implies that it always behaves as one would expect based on its full form, including for the purposes of pattern matching, part extraction, etc. This is a simple and predictable model, so I think that there's value in preserving it. Also consider that Hold[Association[1->2]] is a true compound expression. If Association is not considered atomic any more, then Hold[Association[1->2]] should behave precisely the same way as ...
Jul 17, 2014 at 18:20 comment added Taliesin Beynon @ChipHurst AtomQ is defined as "an expression which cannot be divided into subexpressions", and has notes such as "You can use AtomQ in a recursive procedure to tell when you have reached the bottom of the tree corresponding to an expression." and "AtomQ gives True for any object whose subparts cannot be accessed using functions like Map". Clearly Association should not be AtomQ by these measures. But as you point out, it is also not NormalQ (which would mean that it behaves like its FullForm), if we had such a thing. AtomQ and NormalQ are currently "mixed together", we should separate them.
Jul 17, 2014 at 18:00 comment added Greg Hurst @TaliesinBeynon but on the other hand since <|a -> 1, b -> 2|>[[1]] does not equal a -> 1 as seen in FullForm[<|a -> 1, b -> 2|>], shouldn't it be considered atomic?
Jul 14, 2014 at 20:24 comment added Taliesin Beynon Associations should not be Atomic, based on the documented definition we currently use for what atomic means (doesn't have arbitrary subparts, can't be Mapped, etc). I hope we'll be taking that flag off in the next few point releases.
Jul 14, 2014 at 19:18 history edited Greg Hurst CC BY-SA 3.0
deleted 24 characters in body
Jul 14, 2014 at 15:42 history edited Szabolcs CC BY-SA 3.0
added 33 characters in body
Jul 14, 2014 at 14:34 history edited Greg Hurst CC BY-SA 3.0
added 14 characters in body
Apr 29, 2014 at 16:54 comment added Szabolcs What is atomic and what isn't changes with versions. Image isn't atomic in v7 and v8.
Apr 29, 2014 at 15:53 history edited Greg Hurst CC BY-SA 3.0
added 133 characters in body
Apr 28, 2014 at 19:22 answer added Mr.Wizard timeline score: 6
Apr 28, 2014 at 19:19 comment added Mr.Wizard The same question on Stack Overflow: (5964469)
Apr 28, 2014 at 18:05 history edited Greg Hurst CC BY-SA 3.0
added 19 characters in body
Apr 28, 2014 at 17:50 history edited Greg Hurst CC BY-SA 3.0
added 84 characters in body
Apr 27, 2014 at 17:10 comment added Oleksandr R. @Wouter the definition of an atomic object is one that "cannot be divided into subexpressions" (although I would argue that a better definition is that its structure does not correspond to its FullForm). SparseArray clearly can be, regardless of whether AtomQ is true or false. Further down the documentation page for AtomQ we see some discussion about this, which shows the contradiction inherent in considering SparseArrays as atomic. Now, it may be that SparseArray truly is atomic in terms of its underlying implementation, but unlike other atoms it has a meaningful FullForm.
Apr 27, 2014 at 15:55 comment added Wouter @OleksandrR. : see help file on AtomQ : like Complexand Rational numbers, SparseArray is atomic. List 'm using Cases[ Names["System*"], _?AtomQ]`
Apr 27, 2014 at 8:36 history tweeted twitter.com/#!/StackMma/status/460336565303394304
Apr 27, 2014 at 6:05 history edited Greg Hurst CC BY-SA 3.0
added 2 characters in body
Apr 27, 2014 at 3:38 comment added Oleksandr R. Strangely, SparseArrays are actually not atomic, but just treated for most purposes as if they were. They are the only non-atomic atoms, though, as far as I know. And in addition to your list, there are several other undocumented atomic objects as well, such as the Internal`Bag, the System`Utilities`HashTable, the System`RawArray, and probably others besides. Several objects that should be atomic (by the standards of the SparseArray) aren't, such as CompiledFunction and LibraryFunction.
Apr 27, 2014 at 2:56 history asked Greg Hurst CC BY-SA 3.0