Hi,

So the way the select() puts things into a List (i.e. Path.get()), currently, 
is good:

gremlin> g.V().as('a').out('created').as('a').select('a')
==>[v[1], v[3]]
==>[v[4], v[5]]
==>[v[4], v[3]]
==>[v[6], v[3]]

In the first result, the "tail/start/initial" is v[1] and the 
"head/end/terminal" is v[3]. That lines up with the tail/head terminology in 
graph theory. However, what is off is that Pop.head/tail is wrong:

gremlin> g.V().as('a').out('created').as('a').select(head,'a')
==>v[1]
==>v[4]
==>v[4]
==>v[6]

Pop.head should return v[3] (for the first result). This is a simple fix of 
just reversing the meaning of Pop.head/tail (2 line fix).

However, the reason you flipped Pop.head/tail to begin with is because you 
wanted it to align with unfold().tail(). So lets look at unfold().

gremlin> g.V().as('a').out('created').as('a').select('a').limit(1).unfold()
==>v[1]
==>v[3]
gremlin> 
g.V().as('a').out('created').as('a').select('a').limit(1).unfold().tail(1)
==>v[3]

This should emit v[1]. Bumskies! However, this is about how the "unfolded" 
Iterable is iterated.

gremlin> [1,2,3,4].iterator()
==>1
==>2
==>3
==>4

Unfortunately, when you do List.iterator(), it emits values left-to-right (tail 
to head). Not right-to-left (head to tail). So, we can make unfold() behave 
differently by:

gremlin> [1,2,3,4].reverse().iterator()
==>4
==>3
==>2
==>1

…but that is no bueno from a memory conservation standpoint. I would argue that 
unfold() has nothing to do with path-semantics, but instead, list semantics. 
Therefore, we can argue (in debate) that "unfold().tail()" is not an anomaly of 
tail(), but one of unfold().

Thus, to be consistent throughout, all we need to do is flip Pop.head to 
Pop.tail and vice versa (i.e. as it was originally).

Thoughts?,
Marko.

http://markorodriguez.com

On Jun 12, 2015, at 12:56 PM, Matt Frantz <[email protected]> wrote:

> We could do any of the following:
> 
>   - Rename the "tail" step (e.g. "last") so that we can flip Pop back to
>   the way graph theorists presumably expect it to work.
>   - Reverse the way "select" puts things in a List, and flip Pop back.
>   - Rename Pop head/tail to oldest/newest (or first/last)
> 
> 
> On Fri, Jun 12, 2015 at 5:14 AM, Marko Rodriguez <[email protected]>
> wrote:
> 
>> Hm… I see what you are saying. The problem is that in graph theory,
>> head/tail terms are reversed in Path.
>> 
>> Marko.
>> 
>> http://markorodriguez.com
>> 
>> On Jun 11, 2015, at 3:39 PM, Matt Frantz <[email protected]>
>> wrote:
>> 
>>> Another symmetry I was aiming for:
>>> 
>>> ...select(tail, 'a')
>>> ...select('a').by(unfold.tail(1))
>>> 
>>> On Thu, Jun 11, 2015 at 2:16 PM, Matt Frantz <[email protected]
>>> 
>>> wrote:
>>> 
>>>> I was trying to reconcile the way that the range/limit/tail steps
>> operate
>>>> with how Pop is interpreted.  For local scope, the range ordinals are
>>>> congruent with the list index ordinals.  Thus, "limit(1)" means
>>>> "range(0,1)" which means List.get(0).  Since "tail(1)" is the
>> complement of
>>>> "limit(1)", it means "the highest numbered element" or
>>>> List.get(List.size()-1).
>>>> 
>>>> I understand your description of a stream, but I was trying to reconcile
>>>> the terms with Gremlin and not with streams.
>>>> 
>>>> If you compare a stream with a Unix command line, and how the "head" and
>>>> "tail" utilities act, then "head" means "the first lines you see" and
>>>> "tail" means "the last lines you see".
>>>> 
>>>> For global scope, it seems that "limit(1)" means "the first traverser"
>> and
>>>> "tail(1)" means "the last traverser".  For any Traversal, t, t.limit(1)
>>>> produces the same thing as t.toList().get(0).
>>>> 
>>>> Good news on select(pop)!
>>>> 
>>>> On Thu, Jun 11, 2015 at 11:43 AM, Marko Rodriguez <[email protected]
>>> 
>>>> wrote:
>>>> 
>>>>> Hey,
>>>>> 
>>>>> Yes -- "first = tail" and "last = head".
>>>>> 
>>>>> A path grows with its "head growing" .. its tail is static.
>>>>> 
>>>>> a-->b-->c-->d-->e
>>>>> 
>>>>> the tail is always "a"…the head is "a", then "b", then "c", then "d"….
>>>>> 
>>>>> In a list or stream, the tail is the first element.
>>>>>       - get(0) for list
>>>>>       - stream().toList().get(0)
>>>>> In a list or stream, the head is always the most current element.
>>>>>       - get(list.size() - 1) for list
>>>>>       - stream().next()
>>>>> 
>>>>> …..?
>>>>> 
>>>>> I will hide your interface inside ImmutablePath just for my sanity :).
>>>>> 
>>>>> BTW: select(pop) is on its way.
>>>>> 
>>>>> Marko.
>>>>> 
>>>>> http://markorodriguez.com
>>>>> 
>>>>> On Jun 11, 2015, at 12:30 PM, Matt Frantz <[email protected]>
>>>>> wrote:
>>>>> 
>>>>>> limit(1) means "first" and tail(1) means "last" (in both global and
>>>>> local
>>>>>> manifestations).
>>>>>> 
>>>>>> In the Path.get results, you get a list whose first element is the
>>>>>> first/oldest object matching the step label, so that felt like "head"
>> to
>>>>>> me, while the last element is the most recent and thus "tail".
>>>>>> 
>>>>>> get => [a,b,c,d]
>>>>>> getSingle(head) => a
>>>>>> getSingle(tail) => d
>>>>>> 
>>>>>> In other words the following should be equal:
>>>>>> 
>>>>>> ...map{it->it.path().get('foo')}.tail(local, 1)
>>>>>> ...map{it->it.path().getSingle(tail, 'foo')}
>>>>>> 
>>>>>> I used ImmutablePathImpl because I needed HeadPath to have the
>>>>>> getSingleTail/getSingleHead methods, too.  Thus, a common interface
>>>>> between
>>>>>> ImmutablePath and HeadPath was required.  The interface has package
>>>>> scope,
>>>>>> so it is not part of the public API.
>>>>>> 
>>>>>> On Thu, Jun 11, 2015 at 11:12 AM, Marko Rodriguez <
>> [email protected]
>>>>>> 
>>>>>> wrote:
>>>>>> 
>>>>>>> Hi Matt,
>>>>>>> 
>>>>>>> limit(1) means the most recent value.
>>>>>>> tail(1) means the oldest value. ?
>>>>>>> 
>>>>>>> path: [a,b,c,d]
>>>>>>> a = tail
>>>>>>> d = head
>>>>>>> 
>>>>>>> No?
>>>>>>> 
>>>>>>> Also, why did you do ImmutablePathImpl? Seems that can just be
>> private
>>>>>>> methods inside of ImmutablePath?
>>>>>>> 
>>>>>>> Thanks,
>>>>>>> Marko.
>>>>>>> 
>>>>>>> http://markorodriguez.com
>>>>>>> 
>>>>>>> On Jun 11, 2015, at 11:56 AM, mhfrantz <[email protected]> wrote:
>>>>>>> 
>>>>>>>> GitHub user mhfrantz opened a pull request:
>>>>>>>> 
>>>>>>>> https://github.com/apache/incubator-tinkerpop/pull/76
>>>>>>>> 
>>>>>>>> TINKERPOP3-700 Path getSingle/getList improvements
>>>>>>>> 
>>>>>>>> As requested in the comments of TINKERPOP3-700.  I also reversed
>> the
>>>>>>> sense of `Pop` to align with `tail(local)`.  Thus `Pop.tail` now
>> means
>>>>> the
>>>>>>> most recent value.
>>>>>>>> 
>>>>>>>> You can merge this pull request into a Git repository by running:
>>>>>>>> 
>>>>>>>> $ git pull https://github.com/RedSeal-co/incubator-tinkerpop
>>>>>>> TINKERPOP3-700-Path-getSingle
>>>>>>>> 
>>>>>>>> Alternatively you can review and apply these changes as the patch
>> at:
>>>>>>>> 
>>>>>>>> https://github.com/apache/incubator-tinkerpop/pull/76.patch
>>>>>>>> 
>>>>>>>> To close this pull request, make a commit to your master/trunk
>> branch
>>>>>>>> with (at least) the following in the commit message:
>>>>>>>> 
>>>>>>>> This closes #76
>>>>>>>> 
>>>>>>>> ----
>>>>>>>> commit e1e1a40b068ffe6da3d321256d6200dee0504074
>>>>>>>> Author: mhfrantz <[email protected]>
>>>>>>>> Date:   2015-06-11T16:47:41Z
>>>>>>>> 
>>>>>>>> Add javadoc for Path getList/getSingle
>>>>>>>> 
>>>>>>>> commit 4939cf0a22c4fc44a4f86ed3e023fa30e4e872cc
>>>>>>>> Author: mhfrantz <[email protected]>
>>>>>>>> Date:   2015-06-11T17:10:27Z
>>>>>>>> 
>>>>>>>> Reverse sense of Path.getSingle Pop to align with tail(local) step
>>>>>>>> 
>>>>>>>> commit 027d6319f9ff06ca26d785e83bf17b21364c3dca
>>>>>>>> Author: mhfrantz <[email protected]>
>>>>>>>> Date:   2015-06-11T17:51:23Z
>>>>>>>> 
>>>>>>>> Optimize MutablePath.getSingle
>>>>>>>> 
>>>>>>>> commit 5e9ad8d7dff6c63b9746147a1d255cbf7258cea3
>>>>>>>> Author: mhfrantz <[email protected]>
>>>>>>>> Date:   2015-06-11T17:52:43Z
>>>>>>>> 
>>>>>>>> Optimize ImmutablePath getSingle and getList
>>>>>>>> 
>>>>>>>> ----
>>>>>>>> 
>>>>>>>> 
>>>>>>>> ---
>>>>>>>> If your project is set up for it, you can reply to this email and
>> have
>>>>>>> your
>>>>>>>> reply appear on GitHub as well. If your project does not have this
>>>>>>> feature
>>>>>>>> enabled and wishes so, or if the feature is enabled but not working,
>>>>>>> please
>>>>>>>> contact infrastructure at [email protected] or file a JIRA
>>>>>>> ticket
>>>>>>>> with INFRA.
>>>>>>>> ---
>>>>>>> 
>>>>>>> 
>>>>> 
>>>>> 
>>>> 
>> 
>> 

Reply via email to