You will be presented with the full text of a science research paper. Please write an abstract for this paper. Your response should include the abstract and no additional text.

Paper text:
this paper introduces quanfou v1.1 , quanglue v1.1 , quanoracle v1.1 , quanshi v1.1 , four java applications available@xcite for free .
( source code included in the distribution . )    in a previous paper@xcite , we introduced the java applications quantree and quanlin .
these two applications plus the four applications introduced in this paper , are part of a suite of java applications called quansuite .
quansuite applications all depend heavily on a common class library called qwalk .
each quansuite application compiles a different kind of input quantum evolution operator .
the applications output a quantum circuit that equals the input evolution operator .
before reading this paper , the reader should read ref.@xcite .
many explanations in ref.@xcite still apply to this paper .
rather than repeating such explanations in this paper , the reader will be frequently referred to ref.@xcite .
the input evolution operator @xmath0 for a quansuite application can be specified either directly ( e.g. in quanfou , quanshi ) , or by giving a hamiltonian @xmath1 such that @xmath2 ( e.g. in quanglue and quanoracle ) .
the standard definition of the evolution operator in quantum mechanics is @xmath3 , where @xmath4 is time and @xmath1 is a hamiltonian . throughout this paper
, we will set @xmath5
so @xmath2 .
if @xmath1 is proportional to a coupling constant @xmath6 , reference to time can be restored easily by replacing the symbol @xmath6 by @xmath7 , and the symbol @xmath1 by @xmath8 .
the input evolution operator for quanfou is @xmath9 , the discrete fourier transform matrix , defined by :    ( u_dft)_p , q = ^pq = e^i , with @xmath10 .
see ref.@xcite for a review of how to compile @xmath9 exactly .
since we use an exact ( to numerical precision ) compilation of @xmath9 , the order of the suzuki(or other ) approximant and the number of trots are two parameters which do not arise in quanfou ( unlike quantree and quanlin ) .
fig.[fig - qfou - main ] shows the * control panel * for quanfou .
this is the main and only window of the application .        as to the input and output fields in the control panel for quanfou , we ve seen and explained these before in ref.@xcite .    as to the output files ( log , english , picture ) generated when we press the *
write files * button , we ve seen and explained these before in ref.@xcite .
for example , figs.[fig - qfou - log ] , [ fig - qfou - eng ] , [ fig - qfou - pic ] show an instance of these output files that was generated by quanfou .
the input evolution operator for quanglue is @xmath11 , where :    h_glue = g ( + h.c . ) , for some @xmath12 .
ref.@xcite explains our method for compiling @xmath13 exactly .
since we use an exact ( to numerical precision ) compilation of @xmath13 , the order of the suzuki(or other ) approximant and the number of trots are two parameters which do not arise in quanglue ( unlike quantree and quanlin ) .
fig.[fig - qglue - main ] shows the * control panel * for quanglue .
this is the main and only window of the application .        as to the input and output fields in the control panel for quanglue
, we ve seen and explained these before in ref.@xcite , except for the input fields * row 1 * and * row 2*.    row 1 , row 2 : : :    row 1 = @xmath14 and row 2 = @xmath15 or vice versa ,    where @xmath16 are the parameters defined above , the two    states being glued .    as to the output files ( log , english , picture ) generated when we press the * write files * button , we ve seen and explained these before in ref.@xcite .
consider a tree with @xmath17 states , and @xmath18 leaves , with leaf inputs @xmath19 for @xmath20 .
the input evolution operator for quanoracle is @xmath21 , where    h_oracle&= & g .
ref.@xcite , in the appendix for  banded oracles " , explains our method for compiling @xmath22 exactly .
since we use an exact ( to numerical precision ) compilation of @xmath22 , the order of the suzuki(or other ) approximant and the number of trots are two parameters which do not arise in quanoracle ( unlike quantree and quanlin ) .
fig.[fig - qora - main ] shows the * control panel * for quanoracle .
this is the main and only window of the application .        as to the input and output fields in the control panel for quanoracle , we ve seen and explained these before in ref.@xcite , except for the input field *
bands : : :    you must enter here an even number of integers separated by any    non - integer , non - white space symbols .
say you enter    @xmath23 . if    @xmath24 for @xmath25 are as    defined above , then @xmath26 iff @xmath27 .
each set    @xmath28 is a  band " . if @xmath29 , the    band has a single element .
quanoracle checks that    @xmath30 , @xmath31 , and    @xmath32 for all @xmath33 .
it also checks    that @xmath34 .
( if    @xmath35 , bands @xmath36 and    @xmath33 can be merged . if    @xmath37 , bands @xmath36    and @xmath33 overlap . )    as to the output files ( log , english , picture ) generated when we press the * write files * button , we ve seen and explained these before in ref.@xcite .
the input evolution operator for quanshi is the unitary operation @xmath38 that takes :    , where @xmath39 , with @xmath40 for some positive integer @xmath41 .
we call @xmath4 the * state shift*.    @xmath38 can be easily expressed in matrix form .
for example , for @xmath42 and @xmath43 ,    u_shift =    c||c|c|c|c|c|c|c|c| & & & & & & & & + & & & & 1 & & & & + & & & & & 1 & & & + & & & & & & 1 & & + & & & & & & & 1 & + & & & & & & & & 1 + & 1 & & & & & & & + & & 1 & & & & & & + & & & 1 & & & & & +    .
appendix [ app - shift ] explains our method for compiling @xmath38 exactly .
since we use an exact ( to numerical precision ) compilation of @xmath38 , the order of the suzuki(or other ) approximant and the number of trots are two parameters which do not arise in quanshi ( unlike quantree and quanlin ) .
fig.[fig - qshi - main ] shows the * control panel * for quanshi .
this is the main and only window of the application .
as to the input and output fields in the control panel for quanshi , we ve seen and explained these before in ref.@xcite , except for the input field * shift*.    shift : : :    the parameter @xmath4 defined above .
quanshi allows    @xmath44 and interprets a shift by    @xmath45 as the inverse of a shift by @xmath4 .    as to the output files ( log , english , picture ) generated
when we press the * write files * button , we ve seen and explained these before in ref.@xcite .
in this appendix , we will show how to compile the unitary operation @xmath38 that takes                                _ bool^3 ( 2 ^ 2 m_2 + 2 m_1 + m_0)p_&= & _ bool^3 ( 2 ^ 2 m_2p _ ) + 2n(1 ) + n(0 ) + & = & 2 ^ 2p_1 .. + 2n(1 ) + n(0 ) + & = & 2 ^ 2n(2 ) + 2n(1 ) + n(0 ) .
this result can be easily generalized using induction to an arbitrary number of qubits .
an exact compilation of @xmath38 is now readily apparent from eq.([eq - ushi - decomp ] ) .
the matrices @xmath52 and @xmath46 are dfts matrices so we know how to compile them .
the diagonal matrix @xmath53 is also easy to compile .
for example , for @xmath54 ,
this paper introduces quanfou v1.1 , quanglue v1.1 , quanoracle v1.1 , quanshi v1.1 , four java applications available for free . 
 ( source code included in the distribution . ) 
 each application compiles a different kind of input quantum evolution operator . 
 the applications output a quantum circuit that equals the input evolution operator .