[TEST] add DualConv Module for testing of multi node outputs

[advikasinha]

No description provided.

[AGAMPANDEYY]

could've added bit detailed description of the PR :) nvm i'll go through the codes once

[advikasinha]

This PR added support for multi-output nodes in the DL-Playground diagram editor and code generator. A sample DualOutputConv node is included as a proof-of-concept/testing implementation that can be used for testing how to:

• Define multiple output handles on a single node
• Compute per-handle output shapes independently
• Generate correct PyTorch code with multiple outputs

Changes

1. New Node: DualOutputConv (src/nodes/vision/blocks/DualOutputConv.tsx)

A multi-output demonstration layer that applies Conv2d and emits two outputs:

• conv_out: Raw convolution result [B, out_channels, H_out, W_out]
• flat_out: Flattened projection [B, out_channels * H_out * W_out]

Key features:

• Configurable in_channels, out_channels, and kernel_size
• Custom shapeVerifier to validate 4D input [B, C, H, W]
• Per-handle shapeCompute that returns output shapes keyed by handle ID
• PyTorch init/forward code generation for both outputs
• UI handle metadata via createLayerComponent

Use case: Testing multi-output wiring in the diagram and validating shape propagation through branching paths.

---

2. Handle Type System (src/types/handleTypes.ts)

Formalized type definitions for first-class handle support:

export interface HandleDefinition<D = any> {
  id: string;
  type: "input" | "output";
  defaultLabel?: string;
  position: number;
  shapeCompute?: HandleShapeCompute<D>;
  edgeLabel?: string;  // User customization
}

export interface HandleSchema<D = any> {
  inputs: HandleDefinition<D>[];
  outputs: HandleDefinition<D>[];
}

export type HandleSchemaFactory<D = any> = (data: D) => HandleSchema<D>;

Enables:

• Explicit multi-handle node definitions
• Per-handle shape computation
• Future edge labeling and custom port metadata

---

3. Handle Resolution Utilities (src/utils/handleSchema.ts)

Backward-compatible helpers for working with handle schemas:

• resolveHandleSchema(layer, data)
  Intelligently selects between:

  1. New handleSchema system (static or factory)
  2. Legacy handles spec (for gradual migration)
  3. Default single input/output fallback

  Ensures existing nodes continue working without changes.

• getHandleLabelInfo(layer, data, handleId, direction)
  Retrieves both user-set and default labels for a specific handle, supporting edge annotations.

Backward compatibility: All existing layers default to single in/out; no breaking changes.

---

4. Registry Update (src/nodes/registry.ts)

• Added DualOutputConvNode import and registered as dualconv_layer in the Vision → Convolution group
• New node now appears in the UI palette under the appropriate category

Related Issues

• for functionality essential in issue#8

hadn't added because at the time i had discussed it with manjot in person

[AGAMPANDEYY]

test-comment

[AGAMPANDEYY]

how are we deciding when to use conv_out or flat_out shape, is it based on the target node type?

[AGAMPANDEYY]

will this shapeCompute each time calculate both flat_out and conv_out and in future if we extend to other nodes , isn't this a suboptimal approach, can we use something like based on the targetNode type decide what shape to compute?

[AGAMPANDEYY]

Did you make changes in shape_verifier.ts are we making sure that shapeVerifier passes correct shapes byHandle to inputShapes it seems we are only passing defaultShape?

Line 80 in shape_verifier.ts

const inputShapes = inputIds.map(src => shapes[src]?.defaultShape || []);

[AGAMPANDEYY]

are we not checking in_channel, out_channel and things like stride validation for shape? right now we are just checking 2 conditions it seems

1. Length!=0 (empty)
2. shape has to be 4D

am i missing something or is it fine?

Missing maybe:

1. kernel and stride check
2. in_channels and input channel matching check

You can refer to how we have done in conv2d.tsx