Prev: ScheduledExecutorService very inaccurate?
Next: Threads reading a file at the same time
From: Peter Duniho on 29 Jul 2010 15:13
Fencer wrote:
> [...]
> but apparently I can't handle duplicates the way I try handle them,
> because I get following runtime error:
> Input array contained duplicates.
> Exception in thread "main" java.lang.ClassCastException:
> [Ljava.lang.Object; cannot be cast to [Ljava.lang.String;
> at utility.MiscUtils.findCombinations(MiscUtils.java:23)
> at utility.MiscUtils.main(MiscUtils.java:13)
>
> This line strings = (String[])set.toArray(); is what the runtime system
> is unhappy with.

Of course it is unhappy with it. You can't do that. You need to copy
each string individually to a new array of the desired type (String[]),
or use the array returned by toArray() directly by always casting the
objects in it to String when you want to do something with them.

As far as your other changes, I think you are really barking up the
wrong tree. I don't see any compelling reason to try to avoid the Pair
class you wrote before, but certainly storing the pairs as a
LinkedHashMap doesn't seem like that would address whatever concern you
have. That's a less efficient way to store pairs of strings than just
having your own Pair class, assuming you don't need rapid retrieval of
the second string in a pair given _only_ the first string (which was not
part of your original problem description).

If you're looking to minimize the storage requirements for the pairs,
you might just keep two parallel arrays. The length is known in advance
(sum of the series), so it's just a matter of filling the array as the
loops proceed. One array stores the first string in the pair, the other
array stores the second in the pair.

Otherwise, just use an array of Pair objects.

Pete
From: Fencer on 29 Jul 2010 15:32
On 2010-07-29 21:13, Peter Duniho wrote:
> Fencer wrote:
>> [...]
>> but apparently I can't handle duplicates the way I try handle them,
>> because I get following runtime error:
>> Input array contained duplicates.
>> Exception in thread "main" java.lang.ClassCastException:
>> [Ljava.lang.Object; cannot be cast to [Ljava.lang.String;
>> at utility.MiscUtils.findCombinations(MiscUtils.java:23)
>> at utility.MiscUtils.main(MiscUtils.java:13)
>>
>> This line strings = (String[])set.toArray(); is what the runtime
>> system is unhappy with.
>
> Of course it is unhappy with it. You can't do that. You need to copy
> each string individually to a new array of the desired type (String[]),
> or use the array returned by toArray() directly by always casting the
> objects in it to String when you want to do something with them.
>
> As far as your other changes, I think you are really barking up the
> wrong tree. I don't see any compelling reason to try to avoid the Pair
> class you wrote before, but certainly storing the pairs as a
> LinkedHashMap doesn't seem like that would address whatever concern you
> have. That's a less efficient way to store pairs of strings than just
> having your own Pair class, assuming you don't need rapid retrieval of
> the second string in a pair given _only_ the first string (which was not
> part of your original problem description).
>
> If you're looking to minimize the storage requirements for the pairs,
> you might just keep two parallel arrays. The length is known in advance
> (sum of the series), so it's just a matter of filling the array as the
> loops proceed. One array stores the first string in the pair, the other
> array stores the second in the pair.
>
> Otherwise, just use an array of Pair objects.
>
> Pete

Ok, thanks Pete!

- fencer
From: Fencer on 29 Jul 2010 18:26
On 2010-07-29 20:07, Peter Duniho wrote:

>
> for (int i = 0; i < strings.length; i++)
> {
> for (int j = i + 1; j < strings.length; j++)
> {
> combinations.add(new Pair(strings[i], strings[j]));
> }
> }
>
> The above does not account for the possibility of duplicate strings in
> the input. In that case, you would still get a duplicated pair. That can
> be resolved by removing the duplicates in the input before generating
> the pairs.
>

Hmm, that loop correct doesn't seem correct (or I did as mistake
explaining the desired behavior). For the input a, b, c, and d it
generates the three combinations a:d, b:d, and c:d, but it should be six
combinations:
a b c d =>
a b
a c
a d
b c
b d
c d

- Fencer
From: Fencer on 29 Jul 2010 18:36
On 2010-07-30 00:26, Fencer wrote:
> On 2010-07-29 20:07, Peter Duniho wrote:
>
>>
>> for (int i = 0; i < strings.length; i++)
>> {
>> for (int j = i + 1; j < strings.length; j++)
>> {
>> combinations.add(new Pair(strings[i], strings[j]));
>> }
>> }
>>
>> The above does not account for the possibility of duplicate strings in
>> the input. In that case, you would still get a duplicated pair. That can
>> be resolved by removing the duplicates in the input before generating
>> the pairs.
>>
>
> Hmm, that loop correct doesn't seem correct (or I did as mistake
> explaining the desired behavior). For the input a, b, c, and d it
> generates the three combinations a:d, b:d, and c:d, but it should be six
> combinations:
> a b c d =>
> a b
> a c
> a d
> b c
> b d
> c d
>
> - Fencer

Lol nevermind that, I had introduced another error. Sorry for the noise!
First  |  Prev  | 
Pages: 1 2
Prev: ScheduledExecutorService very inaccurate?
Next: Threads reading a file at the same time