Feat/week4 density api

[kir943]

Hi @msricher,

Summary

This PR implements the Week 4 milestone of the Winter of Code project by adding the density API layer built on top of the arbitrary-order overlap engine.

Specifically:

• Added new module gbasis.integrals.density
• Implemented compute_intracule and compute_extracule functions
• Integrated these APIs with the existing arbitrary_order_overlap sparse tensor engine
• Added dedicated unit tests (test_integrals_density.py)

Validation

• All existing tests pass successfully (304 passed)
• New density API tests added and passing

Scope

This PR introduces the density API interface and does not modify existing overlap engine functionality.
Please let me know if any refinements are needed. I will proceed with Week 5 tasks next.

Thank you!

[msricher]

I cannot find anything wrong here. I think this is in line with what sort of interface we want. @marco-2023 are you more familiar with this?

[msricher]

I'd check the performance in practice, but sometimes it's faster to use something that just queries the original array A, like max(A.min(), A.max(), key=abs), instead of actually computing np.abs(A).

[kir943]

Thank you @msricher for the suggestion and for pointing out the performance aspect.

I agree that avoiding the intermediate allocation from np.abs can be a cleaner and potentially more efficient approach. This could be updated to:

coeff_bound *= max(abs(shell.coeffs.min()), abs(shell.coeffs.max()))

This avoids allocating a temporary array, which may improve performance and reduce memory usage, especially for larger coefficient arrays. On the other hand, the current implementation using np.max(np.abs(...)) is slightly more explicit and consistent with common NumPy idioms.

Please let me know if you would like me to incorporate this change in the current PR.

[msricher]

I think overall it won't matter, it's not inside a heavy loop and I don't think the array will ever be big enough to make this significant. Probably for such small arrays, your way is still faster anyway.

…

On Tue, Feb 24, 2026, 13:03 KIRAN JADHAV ***@***.***> wrote: ***@***.**** commented on this pull request. ------------------------------ In gbasis/integrals/overlap_n.py <#233 (comment)>: > + N = len(shells) + + for i in range(N): + for j in range(i + 1, N): + Rij = centers[i] - centers[j] + Rij2 = np.dot(Rij, Rij) + decay_sum += alpha_mins[i] * alpha_mins[j] * Rij2 + + D = decay_sum / alpha_tot + + # Contraction-level magnitude bound + coeff_bound = 1.0 + norm_bound = 1.0 + + for shell in shells: + coeff_bound *= np.max(np.abs(shell.coeffs)) Thank you @msricher <https://github.com/msricher> for the suggestion and for pointing out the performance aspect. I agree that avoiding the intermediate allocation from np.abs can be a cleaner and potentially more efficient approach. This could be updated to: coeff_bound *= max(abs(shell.coeffs.min()), abs(shell.coeffs.max())) This avoids allocating a temporary array, which may improve performance and reduce memory usage, especially for larger coefficient arrays. On the other hand, the current implementation using np.max(np.abs(...)) is slightly more explicit and consistent with common NumPy idioms. Please let me know if you would like me to incorporate this change in the current PR. — Reply to this email directly, view it on GitHub <#233 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADLODOR6RYHT2FLDTEVRHOT4NSG77AVCNFSM6AAAAACV6IBDLSVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZTQNBZGY4DKOBXGY> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[kir943]

Hi @msricher,

Thank you for the clarification!

Since the Week 4 work is complete and all checks are passing, I have opened a separate PR for the Week 5 tasks, which includes tests, benchmarks, and real-basis validation for the density API.

Please let me know if you would like any changes or improvements. I’ll be happy to update it accordingly.

Thank you!

[msricher]

@kir943 I think the code is good enough to merge. Could you run your code through the black formatter with arguments black -l 100 -t py39 <FILES>, and then open a new PR with the entire WoC project weeks 1-5, with organized commits (i.e. just do a git rebase and merge/organize stuff if necessary, or maybe it's already nice enough...)? Then I can make sure one of the main maintainers reviews the whole thing, and then we'll merge it all together.

[kir943]

Hi @msricher,

Thank you for your guidance.

I have now run the code through the black formatter as requested and opened a new pull request that combines the complete WoC implementation for Weeks 1–5 into a single branch with organized commits:

• PR WoC: Final combined implementation (Weeks 1–5) #236

All checks are passing successfully.Please let me know if any further changes or refinements are needed. I’d be happy to update it accordingly.
Thank you!