"ONE(?) or more consecutive groups of zeros can be eliminated" - this is confusing, if we trying "return the same address reformatted to the shortest possible length", but the actual requirement is not eliminating one group of zeroes ("a single group of zero should be left as-is"), we need better instruction
So "contraction" also means expanding in this problem
When the length of the consecutive 16-bit 0 fields
are equal (i.e., 2001:db8:0:0:1:0:0:1), the first sequence of zero
bits MUST be shortened. For example, 2001:db8::1:0:0:1 is [the] correct
representation.
Yes, I mean the latter. Many solutions only perform a singular assertion check for that specific fixed test only.
Also, random tests should generate such cases, if possible shuffle and mix with other grouping of cases in which zeros appear in the middle (see below).
The case with single group of zeroes appearing in the middle (instead of the ends) of a IPv6 address is missing in the fixed tests (when everything else is included in the fixed tests). It's only in the random tests.
"Javascript's array.splice() function is terrible"? Really? I was quite happy, finding out it can do exactly what I was looking for :-) Thumbs up for the comments!
"ONE(?) or more consecutive groups of zeros can be eliminated" - this is confusing, if we trying "return the same address reformatted to the shortest possible length", but the actual requirement is not eliminating one group of zeroes ("a single group of zero should be left as-is"), we need better instruction
So "contraction" also means expanding in this problem
Input
2a03:2880:2130:cf05:face:b00c::1
Expected:
2a03:2880:2130:cf05:face:b00c:0:1
the description does not specify which group of consecutive zeroes to compress when there are several groups tied for the longest sequence
RFC 5952 does say:
Yes, I mean the latter. Many solutions only perform a singular assertion check for that specific fixed test only.
Also, random tests should generate such cases, if possible shuffle and mix with other grouping of cases in which zeros appear in the middle (see below).
AFAIK a contracted IPv6 form has no
:::, the only contracted form is two colons, isnt it?https://en.wikipedia.org/wiki/IPv6_address#Representation
Unless you mean the validation part and using
:::as invalid input?Description should be language-agnostic
Missing sample and fixed tests for consecutive colons of longer than 3, i.e,
0101::::::::::::0:1:0:10A0B:0C0d::::28c1:1:2etc...
The case with single group of zeroes appearing in the middle (instead of the ends) of a IPv6 address is missing in the fixed tests (when everything else is included in the fixed tests). It's only in the random tests.
The kata is stuck at Node 8.
IPv4 address component in IPv6 isn't tested.
Every IPv6 kata kinda expects incorrectly contracted IPv6 address as input to be treated as valid, so...
"Javascript's array.splice() function is terrible"? Really? I was quite happy, finding out it can do exactly what I was looking for :-) Thumbs up for the comments!
Great!
awesome solution
Yes there are, but they are already compressed. Note the "::" in the inputs.
B090:2985:9000::6F39:00 -> expected 'b090:2985:9000::6f39:0'
A01C:BA::140C:D:0640:002D -> expected 'a01c:ba::140c:d:640:2d'
There aren't two consecutive groups of just 0 in either of these inputs, why are they valid?
Loading more items...