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

Let channels be just variables everywhere #236

Open
loreloc opened this issue Jul 9, 2024 · 2 comments
Open

Let channels be just variables everywhere #236

loreloc opened this issue Jul 9, 2024 · 2 comments
Labels
enhancement New feature or request question Further information is requested

Comments

@loreloc
Copy link
Member

loreloc commented Jul 9, 2024

Is there any reason to not merge the channel and variables dimension in input layers and tensors?

@loreloc loreloc added enhancement New feature or request low-priority Low priority issues question Further information is requested labels Jul 9, 2024
@lkct
Copy link
Member

lkct commented Sep 25, 2024

I guess it's originally because of the structure in data, e.g. images, channel and width/height are treated differently, e.g. in QuadTree we only split the spatial dimensions, and make "variables" only refer to the pixels makes it easy. (Nevertheless it complicates things in other places.)

I'm also in favour of removing channel and using just variable, and I don't see a reason we should not do so.

@andreasgrv
Copy link
Collaborator

+1, when trying to understand input layers I was confused about the role of num_channels, as I was unsure if this is another way of overparametrising. Keeping some notes below in case useful in future.

It seems like num_channels and num_inputs belong together conceptually - e.g. could be grouped in a variable "input_shape".
Or even more generally, maybe num_inputs and num_outputs could be grouped into a shape variable, where the last dimension is the number of outputs.

Caveat: I do not know how this is used deeper in the lib, I assume it probably would break a lot of things, mentioning here in case helpful when considering alternatives.

@loreloc loreloc removed the low-priority Low priority issues label Oct 25, 2024
@loreloc loreloc added this to the cirkit 0.3.0 (reckoning) milestone Oct 28, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request question Further information is requested
Projects
None yet
Development

No branches or pull requests

3 participants