Menu

#213 Enable exponentiation of simple operators

0.3.4
done
nobody
None
nobody
2021-12-28
2021-06-21
Ulf Lorenz
No
What and Why

For [#139], [#112], we need to exponentiate operators, at least in simple cases (no coupling of electronic states). Furthermore, to determine if composite operators can be exponentiated, we need to check if the components commute, so this functionality may also be needed.

It may help to introduce additional traits / interface classes to merge multiple elementary operators under one umbrella. But then again, the number of base classes may be small enough that a simple tabular approach is appropriate.

Acceptance criteria
  • Implement exponentiation for the operators
    • Potential1D, PotentialND
    • Constant
    • TransformationOperator1D
    • Compositions (sums, products, sums of products etc.), as long as the composing operators commute

Instead of the grand scheme outlined above, which allows widespread operator algebra, I only went for the "small" solution. Here, only specific operators allow exponentiation at all, and I only did a simplistic implementation. More complex operations have been delayed to [#218]

Related

Tickets: #112
Tickets: #139
Tickets: #214
Tickets: #218

Discussion

  • Ulf Lorenz

    Ulf Lorenz - 2021-06-21
    • Description has changed:

    Diff:

    --- old
    +++ new
    @@ -4,7 +4,7 @@
    
     #####Acceptance criteria#####
    
    -* Implement commutation for the following operators:
    +* Implement commutation checks for the following operators:
         * Potential1D, PotentialND
         * Constant
         * TransformationOperator1D
    
     
  • Ulf Lorenz

    Ulf Lorenz - 2021-06-21
    • Description has changed:

    Diff:

    --- old
    +++ new
    @@ -1,6 +1,8 @@
     #####What and Why#####
    
     For [#139], [#112], we need to exponentiate operators, at least in simple cases (no coupling of electronic states). Furthermore, to determine if operators can be exponentiated, we need to check if they commute, so this functionality is also needed. 
    +
    +It may help to introduce additional traits / interface classes to merge multiple elementary operators under one umbrella. But then again, the number of base classes may be small enough that a simple tabular approach is appropriate.
    
     #####Acceptance criteria#####
    
     

    Related

    Tickets: #112
    Tickets: #139

  • Ulf Lorenz

    Ulf Lorenz - 2021-08-08
    • Milestone: 0.4 goal --> 0.3.4
     
  • Ulf Lorenz

    Ulf Lorenz - 2021-08-15
    • Description has changed:

    Diff:

    --- old
    +++ new
    @@ -1,6 +1,6 @@
     #####What and Why#####
    
    -For [#139], [#112], we need to exponentiate operators, at least in simple cases (no coupling of electronic states). Furthermore, to determine if operators can be exponentiated, we need to check if they commute, so this functionality is also needed. 
    +For [#139], [#112], we need to exponentiate operators, at least in simple cases (no coupling of electronic states). Furthermore, to determine if composite operators can be exponentiated, we need to check if the components commute, so this functionality is also needed. 
    
     It may help to introduce additional traits / interface classes to merge multiple elementary operators under one umbrella. But then again, the number of base classes may be small enough that a simple tabular approach is appropriate.
    
     

    Related

    Tickets: #112
    Tickets: #139

  • Ulf Lorenz

    Ulf Lorenz - 2021-12-26
    • Description has changed:

    Diff:

    --- old
    +++ new
    @@ -1,14 +1,13 @@
     #####What and Why#####
    
    -For [#139], [#112], we need to exponentiate operators, at least in simple cases (no coupling of electronic states). Furthermore, to determine if composite operators can be exponentiated, we need to check if the components commute, so this functionality is also needed. 
    +For [#139], [#112], we need to exponentiate operators, at least in simple cases (no coupling of electronic states). Furthermore, to determine if composite operators can be exponentiated, we need to check if the components commute, so this functionality may also be needed. 
    
     It may help to introduce additional traits / interface classes to merge multiple elementary operators under one umbrella. But then again, the number of base classes may be small enough that a simple tabular approach is appropriate.
    
     #####Acceptance criteria#####
    
    -* Implement commutation checks for the following operators:
    +* Implement exponentiation for the operators
         * Potential1D, PotentialND
         * Constant
         * TransformationOperator1D
         * Compositions (sums, products, sums of products etc.), as long as the composing operators commute
    -* Implement exponentiation for the same operators
    
    • status: open --> assigned
    • assigned_to: Ulf Lorenz
     

    Related

    Tickets: #112
    Tickets: #139

  • Ulf Lorenz

    Ulf Lorenz - 2021-12-28
    • Description has changed:

    Diff:

    --- old
    +++ new
    @@ -11,3 +11,7 @@
         * Constant
         * TransformationOperator1D
         * Compositions (sums, products, sums of products etc.), as long as the composing operators commute
    +
    +----
    +
    +Instead of the grand scheme outlined above, which allows widespread operator algebra, I only went for the "small" solution. Here, only specific operators allow exponentiation at all, and I only did a simplistic implementation. More complex operations have been delayed to [#218]
    
     

    Related

    Tickets: #218

  • Ulf Lorenz

    Ulf Lorenz - 2021-12-28
    • status: assigned --> done
    • assigned_to: Ulf Lorenz --> nobody
     

Log in to post a comment.

Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.