[Feature] Add backend, diff mode etc to config constructor

[smitchaudhary]

• [x] Update documentation with an example of passing diffmode and backend to QNN.from_configs

[dominikandreasseitz]

hey @smitchaudhary , @Roland-djee will take over the review here !

[smitchaudhary]

@Roland-djee

I'd be inclined to default it to 0 features, check for it and skip adding an empty block.

Though forcing a default behavior for the fm_config, and thus, moving it after observable_config would be potentially confusing to the user I am afraid.

Or do you mean, make it a non-optional argument, thus preserving the FM->ansatz->Observable order, and force the user to provide a FeatureMapConfig object (which could then default to 0 features), even in cases where they don't want a FM?

[RolandMacDoland]

@Roland-djee

I'd be inclined to default it to 0 features, check for it and skip adding an empty block.

Though forcing a default behavior for the fm_config, and thus, moving it after observable_config would be potentially confusing to the user I am afraid.

Or do you mean, make it a non-optional argument, thus preserving the FM->ansatz->Observable order, and force the user to provide a FeatureMapConfig object (which could then default to 0 features), even in cases where they don't want a FM?

Yes, that's the solution I see. Then we can check the number of features and skip the empty block in the full_fm creation.

[RolandMacDoland]

@Roland-djee

I'd be inclined to default it to 0 features, check for it and skip adding an empty block.

Though forcing a default behavior for the fm_config, and thus, moving it after observable_config would be potentially confusing to the user I am afraid. Or do you mean, make it a non-optional argument, thus preserving the FM->ansatz->Observable order, and force the user to provide a FeatureMapConfig object (which could then default to 0 features), even in cases where they don't want a FM?

Yes, that's the solution I see. Then we can check the number of features and skip the empty block in the full_fm creation.

Maybe a suggestion would be to use a datastructure for handling configs ? Could be an overkill though.

[smitchaudhary]

Thanks @awennersteen and @Roland-djee for the comments.

I have made the following changes:

1. FeatureMapConfig now defaults to num_features=0 and if a user does not want an FM, they can pass FeatureMapConfig. The downside being that a user who wants to have a single feature, will actively have to specify num_features=1 (which is good practice already :P )
2. The default behavior of the AnsatzConfig is to have depth=1 (all other ansatz constructors have this default, thus made the most sense).
3. Removed the ad-hoc block that changed the initial state in case of RYDBERG strategy being used. This was there due to the issue I raised in qadence-libs here. But I think, it is a lot more transparent to have the user specify the state when calling forward.
4. Modified tests to account for this changes.
5. Some other stylistic changes + fixing typos.

[RolandMacDoland]

@smitchaudhary Feel free to request a review.

[smitchaudhary]

Re-requested his review for now.

[smitchaudhary]

I will merge it today and bump the version to 1.7.1 with all the changes made in the last 3 weeks.