You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It took me a while to grasp how to implement the continuous version, aka Integral Kernel Operator, so I'll also put down what I've done.
The general form of NO is
$$(\mathcal{K}_t(v_t))(x) = \int_{D_t} \kappa^{(t)}(x,y) v_t(y) dy \quad \forall x \in D_t$$
$\mathcal{P}$ and $\mathcal{Q}$ are local operators that lift and project. $W_t$ works similarly. Ignoring bias for now, for the continuous variant we'd want to be able to take inputs at any arbitrary points rather than fixed discretization, generally required by neural operators.
The role of $\mathcal{P}$ is to lift the input discretization to a higher-dimension space. For point functions, this would just be another function, approximated by a network. It'd thus give $\mathcal{P}(a(x))$ as output where $a(x)$ is the input. For a 1D input and a 1D output, the input should be just a single node. $\mathcal{Q}_t \text{ and } W_t$ would also be constructed similarly, all three being networks that take input at one point and give an output at one point. As an example, they'd be Chain(Dense(1 => 16), Dense(16 => 16), Dense(16 => 1))
Constructing the kernel $\mathcal{K}_t$ requires some efforts, but has been implemented by a network approximating $\kappa^{(t)}$ that takes in 2 inputs, one of them being the input point and the other that will be used to compute the integral. Since the integral is computed on the domain $D_t$, we'd also need to compute the domains to evaluate $\mathcal{K}_t$. Though not the best way, right now, I'm passing the boundary points of the domain through the previous layers and sort them to get the next domains. This should work fine if the activation functions are monotonically increasing/ decreasing, and and the maps $\mathcal{P}_t, \mathcal{Q}_t$ and $W_t$ being linear transformation. Though I am doubtful how well this'd hold for $\mathcal{K}_t$.
I thought for a while if we should use ExplicitLayers or ExplicitContainerLayers and settled for the later because we want to have the flexibility of using any network. These are implemented as CompactLuxLayers having the same functionality as ContainerLayers but concisely.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This still has a lot to be done, but here is a working code. Here's a TODO list:
[ ] GPU compatibility:Integrals.jlquadratures provide limited gpu capabilities@inferredand@jet: Again, the issue seems to be because of someIntegralsimplementationFloat32: For some reason, it takes infinitely long when the inputs areFloat32Luxlayers. Not really implemented in most works though would be good to add it