Skip to content

Conversation

mhucka
Copy link
Contributor

@mhucka mhucka commented Aug 25, 2025

The double_factorize method in the DFABKpointIntegrals class had an inconsistent return. It was type-hinted to return None, but had a code path that returned a value. This early return also caused a caching issue where the method would incorrectly return a cached result even when called with a new thresh value, preventing re-computation.

This commit removes the premature return statement. This allows the thresh parameter to take effect as intended and makes the method's behavior consistent with its type hint.

The `double_factorize` method in the `DFABKpointIntegrals` class had an inconsistent return. It was type-hinted to return `None`, but had a code path that returned a value. This early return also caused a caching issue where the method would incorrectly return a cached result even when called with a new `thresh` value, preventing re-computation.

This commit removes the premature return statement, ensuring that the computation is always performed when the method is called. This allows the `thresh` parameter to take effect as intended and makes the method's behavior consistent with its type hint.
@mhucka mhucka self-assigned this Aug 25, 2025
@mhucka mhucka added the area/health Involves code and/or project health label Aug 25, 2025
@mhucka mhucka marked this pull request as ready for review August 25, 2025 18:02
mhucka added 3 commits August 27, 2025 20:29
…alue (quantumlib#1112)

When adding a new term to a `SymbolicOperator` with a sympy coefficient,
the coefficient was being cast to a float. This was because the default
value for a new term was `0.0`, which is a float. This commit changes
the default value to `0`, which is an integer. This ensures that the
type of the coefficient is preserved when adding new terms.
@fdmalone
Copy link
Collaborator

I think the actual issue here is that df_factors doesn't seem to be used anywhere...

@mhucka
Copy link
Contributor Author

mhucka commented Aug 29, 2025

I think the actual issue here is that df_factors doesn't seem to be used anywhere...

I did some searching in the code base, and it looks like you're right. In that case, I propose to change this PR to remove this property from the class – unless you think that we've stumbled on a deeper problem (e.g., that something should be setting the value, but isn't)?

@mhucka mhucka force-pushed the master branch 2 times, most recently from 68c920e to 5fcc1d8 Compare September 1, 2025 02:23
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/health Involves code and/or project health
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants