Advertisements

Andrew Thompson wrote:
> wrote:
> ...
>> I have eight variables : var1, var2... var 8. All types String.
>> How to check that each variables has unique values ?
>
> One way would be to create a Map, iterate the
> var's and if not present in the map, add the value
> as a key, else return false.
>
> Andrew T.
>

Any particular reason for Map, rather than Set?

Note that the result of a Set add call is true if, and only if, the
value is not already in the Set.

Patricia Shanahan wrote:
> Andrew Thompson wrote:
> > wrote:
> > ...
> >> I have eight variables : var1, var2... var 8. All types String.
> >> How to check that each variables has unique values ?
> >
> > One way would be to create a Map, iterate the
> > var's and if not present in the map, add the value
> > as a key, else return false.
....
> Any particular reason for Map, rather than Set?

You mean besides, 'lack of enough consultation
of the relevant docs.'? ;-)
> Note that the result of a Set add call is true if, and only if, the
> value is not already in the Set.

Andrew Thompson wrote:
> Patricia Shanahan wrote:
>
>>Andrew Thompson wrote:
>>
>>> wrote:
>>>...
>>>
>>>>I have eight variables : var1, var2... var 8. All types String.
>>>>How to check that each variables has unique values ?
>>>
>>>One way would be to create a Map, iterate the
>>>var's and if not present in the map, add the value
>>>as a key, else return false.
>
> ...
>
>>Any particular reason for Map, rather than Set?
>
>
> You mean besides, 'lack of enough consultation
> of the relevant docs.'? ;-)
>
>
>>Note that the result of a Set add call is true if, and only if, the
>>value is not already in the Set.
>
>
> A Set sounds the go - it is just right for this task.

If you actually need to identify the specific duplicate pairs, you need
to compare them one by one -- 1 with all the others, 2 with all the
higher-numbered ones, and so on up to 7 and 8, using equals().

John Ersatznom wrote:
> Andrew Thompson wrote:
>> Patricia Shanahan wrote:
>>
>>> Andrew Thompson wrote:
>>>
>>>> wrote:
>>>> ...
>>>>
>>>>> I have eight variables : var1, var2... var 8. All types String.
>>>>> How to check that each variables has unique values ?
>>>>
>>>> One way would be to create a Map, iterate the
>>>> var's and if not present in the map, add the value
>>>> as a key, else return false.
>>
>> ...
>>
>>> Any particular reason for Map, rather than Set?
>>
>>
>> You mean besides, 'lack of enough consultation
>> of the relevant docs.'? ;-)
>>
>>
>>> Note that the result of a Set add call is true if, and only if, the
>>> value is not already in the Set.
>>
>>
>> A Set sounds the go - it is just right for this task.
>
> HashSet<String> foo = new HashSet<String>();
> foo.add(var1);
> foo.add(var2);
> foo.add(var3);
> foo.add(var4);
> foo.add(var5);
> foo.add(var6);
> foo.add(var7);
> foo.add(var8);
> if (foo.size() < 8)
> duplicateExists();
> else
> duplicateDoesNotExist();
>
> If you actually need to identify the specific duplicate pairs, you need
> to compare them one by one -- 1 with all the others, 2 with all the
> higher-numbered ones, and so on up to 7 and 8, using equals().

To save repititious writing, I'm going to assume the strings are in an
array. The equivalent of your code would be:

The nested loop is only needed to allow reporting of a specific duplicate
pair. I cannot think of many practical examples where that is required
rather than simply reporting that the element to be added is a duplicate. If
it is required then I'd say you're right, using a List does result is
slightly more readable code.

That said, if the collection must not contain duplicate elements then at
least from a design and correctness perspective you should use a Set. I'd
personally do so even if that decision would result in a few extra lines of
code here and there.

Note that I did NOT write that.
>
> It will, but will be a lot more expensive. Use can use a
> Map<String,Integer> to both avoid nested loop and report indexes. Yes,
> it will take more memory.
>
> [....]
>

and the ability to pass these to collection constructors to use, the way
those that use order comparison can already be handed a custom comparator.

Problems caused by comparators not consitent with an object's equals
method could be avoided by supplying an Equalizer that is consistent
with the comparator, as well as it obviating the need you perceive to
wrap the String class. (Either way, by the way, you need to replace
hashCode() with a case-insensitive version too, or you'll have strings
that compare equal and have different hash codes, at least potentially.
That at least can't happen if you use add(var.toFooCase()) or similar.)

Yeah, and assert "Color".toLowerCase().equals("Colour".toLowerCase()).
Whenever there's multiple legitimate spellings for the same word,
there's going to be trouble if you try to make the computer "smart
enough" to treat them as equal.

Mind you, there ARE lexicographical "distance" measures that are useful
for "fuzzy-matching", such as spell-checker "suggestions" use. (Google
now suggests an alternate if it thinks you've misspelled a query term,
for example.) But you can't use those as an equality test, since they
don't define an equivalence relation -- they aren't transitive, since
you can have a.isCloseTo(b), a.isCloseTo(c), and !b.isCloseTo(c) (e.g.
where the distance is 1 from c to a, 1 from a to b, and 2 from c to b,
and 1 is the threshold). Even a threshold of 1 is too high if the result
is not only to equate "color" with "colour" but also with "colon".

Best to treat distinct spellings as distinct, and perhaps use a
fuzzy-match "suggested alternative" if users enter a query with no
results, e.g. if a search for "beissen" comes up empty.

Of course, if you really want to drive yourself mad, try to program the
computer to identify when two different input strings identify the same
thing in general. Good luck having it compare e.g. "Carrie-Anne Moss"
and "Lead actress in The Matrix" as equal. Sure, go ahead, you'll even
solve the NLP while you're at it so you should become rich and famous.
If you succeed.

Of course, all this arose in the context of "foo.equalsIgnoreCase(bar)"
vs. "foo.toLowerCase().equals(bar.toLowerCase())". Those *should* be
equal; both should be transforming words into a canonical
representation. Or else there should be another toFoo() method that
returns a canonical representation that compares equal for words that
compare equalsIgnoreCase, because the usefulness of having such a
representation to use as a key in a hashmap is obvious.

Share This Page

Welcome to The Coding Forums!

Welcome to the Coding Forums, the place to chat about anything related to programming and coding languages.

Please join our friendly community by clicking the button below - it only takes a few seconds and is totally free. You'll be able to ask questions about coding or chat with the community and help others.
Sign up now!