Harbor Manifest Planner Log
In Harbor Manifest Planner Log, each entry is a string with three parts joined by #, such as "PierA#cocoa#2". You should read that as berth # cargo # sequence.
The task is to sort the full list using those parts. The cargo label is the main key and should be compared alphabetically without caring about letter case, so "Amber" and "amber" belong in the same part of the order. If two entries have the same cargo label, compare their sequence numbers as numbers, not as text. That means 2 should come before 10. If a tie still remains, the berth name can be used to break it.
For example, entries = ["Dock9#tea#12","Dock2#linen#3","Dock5#tea#1"] should become ["Dock2#linen#3","Dock5#tea#1","Dock9#tea#12"]. The linen cargo comes before tea, and inside the tea group the smaller sequence number comes first. Another example is entries = ["PierA#cocoa#2","PierB#algae#7","PierB#algae#5","PierA#cocoa#1"], which should become ["PierB#algae#5","PierB#algae#7","PierA#cocoa#1","PierA#cocoa#2"].
So the task is to split each manifest string into parts, compare them with the right priority, and return the original strings in that sorted order.
Example Input & Output
The linen cargo comes first, and the two tea entries are ordered by their numeric sequence.
Cargo order puts algae before cocoa, and each cargo group is then sorted by sequence number.
Cargo comparison ignores case, so both amber entries come before Quartz, and sequence 1 comes before sequence 2.
Algorithm Flow
Solution Approach
A good solution is to sort the manifest entries with a custom comparison key built from the three pieces inside each string. Every entry follows the same pattern, berth#cargo#sequence, so the job naturally breaks into two parts: parse each entry into its components, then sort by the problem rules.
The first comparison key is the cargo label, but it should be handled case-insensitively. That means "Amber" and "amber" should be treated as the same word for ordering. The second key is the sequence value, and that must be converted to a number before comparing. This is important because text comparison would put "10" before "2", which is wrong for numeric order. If two entries still tie after cargo and sequence, the berth name can break the tie to keep the order deterministic.
In JavaScript, one straightforward version looks like this:
This matches the examples closely. In the list with algae and cocoa, the algae entries come first because "algae" sorts before "cocoa". Inside the algae group, sequence 5 comes before sequence 7. In the example ["A#X#1", "A#X#10", "A#X#2"], converting the sequence to a number is what makes the final order 1, 2, 10 instead of the incorrect text order 1, 10, 2.
The time complexity is O(n log n) because sorting dominates the work. The extra space depends on the sorting implementation, though the parsing inside the comparator is still reasonable for a small easy problem like this. If you want, you can pre-parse each entry once into helper records and then sort those records, but the main idea stays the same.
So the strategy is: split each string by #, compare cargo case-insensitively, compare sequence numerically, use berth as a final tie-breaker, and return the entries in that order.
Best Answers
import java.util.*;
class Solution {
public Object organize_manifest(Object input) {
String[] items;
if (input instanceof String[]) {
items = (String[]) input;
} else {
return "";
}
if (items.length == 0) return "";
String[] sorted = items.clone();
Arrays.sort(sorted);
StringBuilder sb = new StringBuilder();
for (int i = 0; i < sorted.length; i++) {
sb.append(sorted[i]);
if (i < sorted.length - 1) sb.append(" | ");
}
return sb.toString();
}
}Comments (0)
Join the Discussion
Share your thoughts, ask questions, or help others with this Challenge.