fix incorrect comment in StructuredDot.grad

[arpanjha234]

Description

This PR resolves #1871 by correcting outdated and misleading comments in the StructuredDot.grad method.

Changes:

• Fixed the comment for ga. It previously described a standard dense dot product ($g_{out} \times B^T$), but the implementation uses structured_dot_grad to maintain the sparsity pattern of a.
• Removed the incorrect claim that b and g_out must be dense.
• Added a note specifying that sparse inputs are supported in the Python and Numba backends (referencing the work in Implement StructuredDotGradCSR and StructuredDotGradCSC in numba backend #1860) but are not yet supported by the C backend.

Related Issue

• Closes Comment in StructuredDot.grad is not correct #1871
• Related to #

Checklist

• Checked that the pre-commit linting/style checks pass
• Included tests that prove the fix is effective or that the new feature works
• Added necessary documentation (docstrings and/or example notebooks)
• If you are a pro: each commit corresponds to a relevant logical change

Type of change

• New feature / enhancement
• Bug fix
• Documentation
• Maintenance
• Other (please specify):

[ricardoV94]

I don't have the context of why that FIXME was added. I'll let @tomicapretto handle it (if he wants to)

[tomicapretto]

I don't have the context of why that FIXME was added. I'll let @tomicapretto handle it (if he wants to)

@ricardoV94 the new comments reflect the state of things, but I think the real question is whether we want different backends to support different input types.

[ricardoV94]

@ricardoV94 the new comments reflect the state of things, but I think the real question is whether we want different backends to support different input types.

The alternative is for all the backends to support everything? That's WIP but why must such note live in this method? Is the implementation trying to change things because of this? It won't know which backend will be ultimately used...

[tomicapretto]

The alternative is for all the backends to support everything?

I think so, although I don't know if there's appetite to update the C code.

That's WIP but why must such note live in this method?

The origin of this is there was a note, in the exact same place, saying b and g_out where dense.
I noticed it was wrong for Python and Numba backends, so I added a FIXME in tomicapretto@026202a

Is the implementation trying to change things because of this? It won't know which backend will be ultimately used..

Nope, but the original comment was wrong and I've noticed so they are the parameter names in structured_dot_grad are wrong too.