Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Result --> SingleResult #155

Closed
loriab opened this issue Oct 30, 2019 · 14 comments
Closed

Result --> SingleResult #155

loriab opened this issue Oct 30, 2019 · 14 comments

Comments

@loriab
Copy link
Collaborator

loriab commented Oct 30, 2019

So we've got

  • OptimizationInput/Optimization
  • ResultInput/Result

And in another project, I've got the potential for

  • FindifResultInput/FindifResult
  • CBSResultInput/CBSResult

etc. The optimization pair doesn't particularly signal "schema" to me. And it might be convenient to distinguish between the set of *ResultInput/*Result pairs and the particular energy/gradient/hessian calc that ResultInput/Result now represents.

It is suggested that the two first items above become the below so that the * of *ResultInput/*Result is never the empty string.

  • OptimizationResultInput/OptimizationResult
  • SingleResultInput/SingleResult (AnalyticResult?)

Please weigh in on this change, even if it's just an up/down emoji response.

@mattwelborn
Copy link
Collaborator

@dgasmith Does this proposal interact at all with plans to make optimization a service?

@dgasmith
Copy link
Collaborator

dgasmith commented Oct 30, 2019

@mattwelborn No, doesn't effect those plans.

Another option is to do:

  • OptimizationInput / OptimizationResult
  • SingleInput / SingleResult
  • FindifInput/FindifResult
  • CBSInput/CBSResult

Since these names are going to be typed many times I would be hesitant to make them too long where Resultinput seems a bit duplicitous.

It seems that the main blocker is that Result / ResultInput is odd name. Is there a better name for the atomic unit of a component framework?

Worth poking @dotsdl @Lnaden @jchodera @bennybp.

@jchodera
Copy link

I'm with @dgasmith here: It's clearer to use XInput/XResult, or perhaps even XInput/XOutput. ResultInput is syntactically painful.

@loriab
Copy link
Collaborator Author

loriab commented Oct 30, 2019

I've thought ResultInput a pleasing quirk because you could search for CBSResult and hit both input and output stages. But sure, I don't mind XInput/XResult. It's searchable and predictable (latter not the case at present).

So any votes among the below? I'm plenty happy with SingleResult. It's distinctive but with a vague enough definition to not feel wrong stretching it.

  • SingleResult
  • AnalyticResult
  • PrimaryResult
  • AtomicResult

@dgasmith
Copy link
Collaborator

QuantumResult for the word play, both a quantum unit and a quantum chemistry one. I will see myself out...

@dgasmith
Copy link
Collaborator

QuantaResult?

@loriab
Copy link
Collaborator Author

loriab commented Nov 3, 2019

Going with SingleResult/SingleInput and OptimizationResult/OptimizationInput? I get the feeling ResultInput is not well loved. My second-favorite for SingleResult is AtomicResult, which also makes a nice play on words, so long as it's not mistaken for single-atom result.

To drum up opinions, i'll query on a few more alternatives:

  • CBSResult (currently) or CompositeResult
  • FinDifResult (currently) or FDMResult or FiniteDifferenceResult or StencilResult
  • NBodyResult (currently) or MBEResult or ManyBodyResult or FragmentResult

@dotsdl
Copy link
Contributor

dotsdl commented Nov 3, 2019

I'm in favor of syntactic simplicity where it can be found, so something like XInput / XResult as a convention is something I can get behind. As a relative newcomer to the project wrapping his head around a rapidly-evolving set of tooling, it helps if the names of things give a sense for their structural purpose and place within the landscape.

ResultInput, for example, feels like a sign with one label pointing in two directions. It might get you to where you want to go, but you might also scratch your head every time before you get there.

@dgasmith
Copy link
Collaborator

dgasmith commented Nov 4, 2019

@dotsdl Any thoughts on AtomicInput/AtomicOutput?

@mattwelborn Can you weigh in here?

@leeping @j-wags Any thoughts here? I think your comments here would be quite valuable as you are not too deep into the ecosystem.

@dgasmith
Copy link
Collaborator

dgasmith commented Nov 8, 2019

Last round of pinging, I am up for making the change this release with a deprecation warning.

@bennybp @twindus @lothian

@leeping
Copy link

leeping commented Nov 8, 2019

Thanks for asking; after reading this discussion I think XInput / XResult or XInput/XOutput is the more intuitive choice. :)

@loriab
Copy link
Collaborator Author

loriab commented Nov 8, 2019

I strongly favor XInput/XResult over XInput/XOutput.
I'm for

  • AtomicResult
  • CBSResult
  • FDMResult
  • MBEResult
  • OptimizationResult

with second choice

  • SingleResult
  • CompositeResult
  • StencilResult
  • ManyBodyResult
  • OptimizationResult

(or any combination thereof)

@dgasmith
Copy link
Collaborator

dgasmith commented Nov 8, 2019

It seems XInput/XResult has the day overall, nobody has yet to object to Atomic either.

For the others:

  • CompositeResult
  • FiniteDifferenceResult
  • ManyBodyResult

FDMResult and MBEResult are hard to understand. CBSResult would be an oddity, but is a well known literature description.

@dgasmith
Copy link
Collaborator

Closed by #167, thank you everyone for the comments and feedback.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants