Help save net neutrality! Learn more.
Close

#377 \\\'Bag\\\' setlike methods

3.2.0
closed
nobody
Classes (182)
5
2012-08-14
2007-08-06
No

The 'Bag' class setlike methods 'difference', 'interSection', 'subSet', 'union',
and 'xor' yield wrong results, if the argument 'other' is of type 'MapCollection'.

Example with 'subSet':

----------- cut here -------------
t=.table~new
t[11]="eleven"
t[22]="twenty-two"

b=.bag~of(11)

say "b~subset(t):" b~subset(t) / yields: 0 /
----------- cut here -------------

The reason is that the current implementation uses 'allItems' from
'other', if 'other' is a 'Collection'. For MapCollections 'allIndexes'
should be used.

The respective code sections could be simplified in the course of fixing
this.

(I could take over this item.)

Discussion

  • Rick McGuire

    Rick McGuire - 2007-10-02

    Logged In: YES
    user_id=1125291
    Originator: NO

    Committed revision 857.

    This was a problem in the documentation. Any set operation where the receiver is a collection where the index is not a significant part of the value tuple and the argument is a Map collection needs to be using the items for the matching, not the indexes. The documentation has been updated to make this clearer.

     
  • Rony G. Flatscher

    Logged In: YES
    user_id=662126
    Originator: YES

    Unfortunately, this is a bug!

    A MapCollection defines a functional dependency (FD) between index and item (index->item), therefore "allIndexes" is the significant part of it and needs to get used. (For that very same reason "makeArray" for "MapCollection" is defined to return "allIndexes".)

    E.g. consider the following example and its output:

    ------------------- cut here --------------------
    parse version v
    say v
    / SetCollection /
    s=.set~of("Anton", "Berta", "Caesar")
    b=.bag~of("Anton", "Anton", "Berta", "Caesar")

    / OrderedCollection /
    l=.list~of("Caesar", "Anton", "Anton", "Berta", "Berta")

    / MapCollection /
    t=.table~new
    t["Anton"]="Austria"
    t["Berta"]="Belgium"
    t["Caesar"]="California"

    call dump "s~makeArray", s~makeArray
    call dump "l~makeArray", l~makeArray
    call dump "t~makeArray", t~makeArray
    say "----------------------"

    call dump "b~union(l)", b~union(l)
    call dump "b~union(t)", b~union(t)
    say "----------------------"

    ::routine dump
    use arg title, coll
    say title":"
    do o over coll
    say " " o
    end
    say "---"
    ------------------- cut here --------------------

    [Using "makeArray" on the "other" argument would always return the significant part of the "other" collection, i.e. "allIndexes" with a "MapCollection" (and "allItems" else).]

     
  • Rick McGuire

    Rick McGuire - 2007-10-03

    Logged In: YES
    user_id=1125291
    Originator: NO

    The original answer stands. The issue here what portion of the information from the source collection makes sense when applied to the receiver collection when only portion can be retained. This is the items, not the indexes, that are the important pieces of information.

     
  • Rony G. Flatscher

    Logged In: YES
    user_id=662126
    Originator: YES

    As you may recall my original implementation (cf. around rev. 619) of "makeArray" was located at "Collection" and returned "allIndexes". Reasoning: a collection is a mapping from an index to an item (index->item, a functional dependency, FD). Clearly this was meant therefore as the default behaviour.

    To cater for the "OrderedCollection" speciality (index does not functionally determine the item), I defined a "makeArray" that returns "allItems" there.


    Now, you changed that such, that the "Collection" (default) implementation of "makeArray" returns "allItems", whereas now the "MapCollection" got considered as a special case such that it gained a "makeArray" of its own which returns "allIndexes". This may mislead readers of the documentation that the default for Collections would be that there are no FDs (functional dependencies), because "allItems" will be returned by default.

    But even so, the "makeArray" method would return "allIndexes" where there are FDs, and "allItems" where there are not ("OrderedCollection"; but also for "SetCollection", which does not matter as index and item are the same object there, although that may be quite misleading).

    In the context of these methods the question is what array is returned by the "argument" collection for processing it. If one sends the "makeArray" message to the argument collection, then the receiver object will return the array that is appropriate for its type: it will be the "allIndexes" array in the case of a "MapCollection", and it will be "allItems" else.

    If the current implementation would employ the "makeArray" method, everything would work correctly.


    As you may recall, We have discussed the collection classes a few months ago, and in that context I supplied the links to the discussions within the ANSI REXX committee of how the collection classes are defined for IBM's Object REXX and why. [The central concepts to apply are the "functional dependency" (FD) and in the case of Relation "multivalued dependencies" (MVD), which themselves are FDs.]

    The resulting RFEs and my initial implementation of the Collection methods attempted to follow that.


    The current implementation of 3.2.0 (rev. 860) causes existing Object REXX/ooRexx programs to break as the results of the setlike operations, are wrong.

    It is also therefore that I think that this is a bug which needs to be resolved for the release version.

     
  • David Ashley

    David Ashley - 2007-10-03

    Logged In: YES
    user_id=931756
    Originator: NO

    Rick has rejected this bug and no further discussion will be responded to. If you still feel you are correct then please contact the appeals committee.

     


Anonymous

Cancel  Add attachments