non-concrete fields in `struct`s are considered harmful

[jlapeyre]

epsilon here should be a concrete type

QuanEstimation.jl/src/Algorithm/Algorithm.jl

Lines 5 to 8 in 5ab636a

	struct GRAPE <: AbstractGRAPE
	max_episode::Int
	epsilon::Number
	end

There are many other similar structs in the code. See the doc on this.

Something like this is better

 struct GRAPE{T<:Number} <: AbstractGRAPE 
     max_episode::Int  
     epsilon::T
 end 

This allows the compiler to infer types in more situations. It also makes a more efficient layout.

The following line is in a tight loop and the type of epsilon is not known to the compiler. (I'm fairly sure, but could be missing something.) This means the code is probably not optimized for, say Float64.

QuanEstimation.jl/src/Algorithm/GRAPE.jl

Line 202 in 5ab636a

dynamics.data.ctrl[cm][tm] = dynamics.data.ctrl[cm][tm] + alg.epsilon*δF

[hmyuuu]

I think you are correct, and thanks for the comments!
We will recheck our codes and replace all the abstract types that may be harmful to the performance with concrete ones using the parametric constructor layout.