How can extended public keys generate child public keys without generating the child private key in HD wallets? According to the documentation on bitcoin.org and the Mastering Bitcoin book, you can use an extended public key to create child public keys in HD wallets by combining the lefthand side of the hash output of the parent chain code + parent public key + index:


  The seemingly-random 256 bits on the lefthand side of the hash output are used as the integer value to be combined with either the parent private key or parent public key to, respectively, create either a child private key or child public key


I understand how this lefthand side output can be combined with the parent private key to generate the child private key, which in turn can be used to generate a valid child public key. 

How is it possible that the child public key generated by combining the hash output with the parent public key corresponds to the child private key generated separately by combining the same hash output with the parent private key?

I thought that in was impossible to generate a public key without knowing exactly what the private key was. How is the relationship between child private and public keys (K = k*G) maintained when they are generated separately in this way?.
Upon a bit more searching, I found the derivation for getting the child public key without the private key here:

child_private_key == (parent_private_key + lefthand_hash_output) % G
child_public_key == point( (parent_private_key + lefthand_hash_output) % G )
child_public_key == point(child_private_key) == parent_public_key + point(lefthand_hash_output)


In terms of K, k and G where prime denotes the child and h denotes the left-hand hash output:

k' = (k + h) % G
K' = point ( (k + h) % G)
K' = point (k')
K' = K + point(h)


Here are the exact implementation details from the BIP 32 documentation