Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Inconsistency in linear interpolation for editing #84

Open
juancprzs opened this issue Aug 22, 2021 · 0 comments
Open

Inconsistency in linear interpolation for editing #84

juancprzs opened this issue Aug 22, 2021 · 0 comments

Comments

@juancprzs
Copy link

Hi there,

Thanks for the great work!

I'm visualizing some samples generated by your approach through the edit.py script, and I have a question. My understanding is that this script generates samples by:

  1. Starting from a latent code, call it z, a direction in that space, refer to it by a unit vector n, starting and finishing magnitudes, call them s and f, respectively, and
  2. Generating a sequence of latent codes by making a linear interpolation from vector v1 = z - s n to vector v2 = z + f n.

I understand this is done in the function linear_interpolate here, that is used here, and whose product is stored in the variable interpolations. From this understanding of the code, I would expect that all the codes saved in the interpolations variable are at an L2 distance of, at most, max(s, f); and, in particular, there should be an interpolation for which the distance is s, and another interpolation for which the distance is f. However, when I check this in the code by running
np.linalg.norm(interpolations - latent_codes[sample_id:sample_id + 1], axis=1), I get other results.

I think this is either because I'm misunderstanding something, or because there is a (small) bug in the code. Such bug would probably be inconsequential, but I thought I should report it. I think the bug itself has to do with this line in particular, in the linear_interpolate function. Specifically, I'm unable to understand why the computation latent_code.dot(boundary.T) is performed. The boundary variable is a direction, rather than an actual boundary, right? As there is no presence of the bias term to determine the actual side of the hyperplane on which latent_code is falling. Further, I see that no such analogous computation is performed for the case of latent codes in the W+ space (see here).

I think that particular line is the root of the problem I observe. This is because, if I simply comment that line and run the code, the results are as expected.

Could you please take a look into my claims?

Thank you!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant