text:
Question

# A block A of mass 45 kg is placed on another block B of mass 123 kg. Now block B is displaced by external agent by 50 cm horizontally towards right. During the same time block A just reaches to the left end of block B. Initial and final positions are shown in figures. The work done on block A in ground frame is

A
-18 J
B
18 J
C
36 J
D
-36 J

Solution

## The correct option is C 18 JAs there is relative motion so kinetic friction will act on A in the direction of motion of B (or towards right).$$f=\mu mg=0.2\times 45\times 10=90 N$$$$S=50-30=20 cm=0.2 m$$$$\therefore W=fS=18 \ J$$Physics

Suggest Corrections

0

Similar questions
View More

People also searched for
View More


text:
# Efficiency of the prime generating constant $2.920050977316 \dots$ for the purpose of compressing a list of primes.

The constant $$c \approx 2.920050977316 \dots$$ has the property that if $$\{a_n\}$$ is the sequence defined by $$a_1 = c, a_{n+1} = \lfloor a_n \rfloor (a_n - \lfloor a_n \rfloor + 1),$$ then $$\lfloor a_n \rfloor$$ is the $$n$$th prime.

We need to calculate primes in order to calculate the constant rather than the other way around, so this does not yield a method of generating new primes. However, we might be able to use the constant to compress an already known list of primes. The question then becomes, how many digits of $$c$$ are needed to generate the first $$n$$ primes? Note that it takes $$\sim n \log n$$ digits to store the first $$n$$ primes naively and $$\sim n \log \log n$$ digits by storing the differences between consecutive primes.

• Upvoted because that's a cool fact. What's the reference you got it from? (Perhaps its bibliography could answer your question?) Dec 6 '20 at 5:20
• @JakeMirra Added a link to the paper. Dec 6 '20 at 5:21
• While the paper is behind a paywall, it looks to me that every integer sequence with the property that $s_n \leq s_{n+1} < 2s_n$ can be represented by that recurrence on the correct starting value - which would suggest that this is probably not an effective method of compression. (At least no better than storing, says, the differences between consecutive primes) Dec 6 '20 at 5:28
• @MiloBrandt That's correct, you can see the paper for yourself here: arxiv.org/pdf/2010.15882.pdf. Even then, anything less than $n\log \log n$ (linear for example) is interesting. Dec 6 '20 at 5:31
• Dec 6 '20 at 5:50

We can refine the result of the paper as follows, where we will use $$\lfloor x\rfloor$$ for the floor function and $$\{x\}=x-\lfloor x\rfloor$$ to be the fractional part function.

Let $$s_0,s_1,s_2,\ldots,s_n$$ be a finite sequence of integers such that $$s_k \leq s_{k+1} < 2s_k$$ for every $$k$$. Let $$I$$ be the set of $$c$$ for which the sequence inductively defined by $$a_1=c$$ and $$a_{n+1}=\lfloor a_n\rfloor(1+\{a_n\})$$ has the property that $$\lfloor a_k\rfloor = s_k$$ for each $$k$$. There is some $$z$$ such that $$I=\left[z, z + \frac{1}{\prod_{i=0}^{n-1}s_i}\right).$$

This tells us that we need to choose the starting value in an interval of length $$\frac{1}{\prod_{i=0}^{n-1}s_i}$$, which generically takes $$\log_{10}\left(\prod_{i=0}^{n-1}s_i\right)$$ digits of precision. However, just writing out all the terms in the sequence would require writing about the same number of digits since $$\log_{10}(\prod s_i) = \sum \log_{10}(s_i)$$. Representing sequences this way doesn't have any advantage at least asymptotically - and this is not surprising, since this method is a fairly literal transcription of sequences satisfying the given inequalities - and this inequality alone is not a very helpful way to single out the sequence of primes.

Let's define $$f(x)=\lfloor x\rfloor (1+\{x\})$$. Note that $$f$$ is just a linear function of slope $$n$$ on each interval $$[n,n+1)$$. Define its iterates as $$f^0(x)=x$$ and $$f^{n+1}(x)=f(f^{n}(x))$$. Let's say that a given constant $$c$$ represents a sequence $$s_0,\ldots,s_n$$ if $$\lfloor f^k(x) \rfloor = s_k$$ for each $$k$$. Let me give two inductive proofs of the claimed theorem using this terminology.

Proof 1: We prove the statement directly by induction on $$n$$. The statement is trivial if $$n=0$$. Suppose that we wish to represent $$s_0,s_1,s_2,\ldots,s_{n+1}$$. By the inductive hypothesis, the set of representations of $$s_1,s_2,\ldots,s_{n+1}$$ is an interval $$I$$ of the prescribed length. A representation of $$s_0,s_1,s_2,\ldots,s_{n+1}$$ is just some $$x$$ such that $$\lfloor x\rfloor = s_0$$ and $$f(x) \in I$$. The second part of this condition simplifies to saying $$s_0(x-s_0+1) \in I$$, since we know that floor of $$x$$. Note that, since $$I$$ is a subset of $$[s_1,s_1+1) \subseteq [s_0,2s_0)$$, the condition that $$s_0(x-s_0+1) \in I$$ implies $$\lfloor x\rfloor = s_0$$. The set of representations of $$s_0,s_1,s_2,\ldots, s_{n+1}$$ therefore is the preimage of $$I$$ under a linear function of slope $$s_0$$, hence has length $$\frac{1}{s_0}$$ times the length of $$I$$. This immediately proves the desired statement.

Proof 2: For this proof, we use an inductive argument that builds up the sequence from the end rather than from the start, which enables somewhat clearer computation of the interval itself. We need to prove an additional statement as part of the inductive hypothesis, however:

If $$I$$ is the interval of representations for $$s_0,s_1,s_2,\ldots,s_n$$, then $$f^n$$ is linear when restricted to $$I$$ and has image $$[s_n,s_n+1)$$.

Essentially, we need that $$f$$ behaves well when we know what it represents and that it hits every possible terminating value. Clearly, if $$n=0$$, the sequence has only one term and is represented exactly on the interval $$[s_0,s_0+1)$$, on which $$f^0$$ is the identity function.

Next, let $$I$$ be the interval of $$x$$ representing the sequence $$s_0,s_1,\ldots,s_{n-1}$$. Note that $$f^{n-1}$$ restricted to $$I$$ is, by hypothesis, some linear function taking $$I$$ to $$[s_{n-1},s_{n-1}+1)$$. However, $$f$$ restricted to the interval $$[s_{n-1},s_{n-1}+1)$$ is also linear, satisfying $$f(x)=s_{n-1}(x-s_{n-1}+1)$$. The composition $$f^n$$ is therefore also linear on the interval $$I$$ - and, by calculation, takes $$I$$ to the interval $$[s_{n-1},2s_{n-1})$$. Note that, by hypothesis, the interval $$[s_n,s_n+1)$$ is contained within $$[s_{n-1},2s_{n-1})$$ and, in fact, is a proportion of exactly $$\frac{1}{s_{n-1}}$$ of that interval, hence its preimage under $$f^n$$ within $$I$$ - which is the set of sequences representing $$s_0,s_1,\ldots,s_{n-1},s_n$$ is the same proportion of $$I$$. In particular, since $$I$$ had length $$\frac{1}{\prod_{i=0}^{n-2}s_i}$$, it must be that this preimage has length $$\frac{1}{\prod_{i=0}^{n-1}s_i}$$, as was desired. Moreover, observe that we have already established the refinement we used for the inductive hypothesis.

If we work out the details of the calculation implied here, we end up determining that $$z=s_0+\sum_{k=0}^{n-1} \frac{s_{k+1}-s_k}{\prod_{i=0}^k s_k}$$ which also extends to finding the (unique) $$c$$ that generates an infinite sequences satisfying the condition that $$s_k \leq s_{k+1}<2s_k$$ for every $$k$$ and the additional condition that $$s_{k+1}<2s_k-1$$ for infinitely many $$k$$.

format: plain


text:
Thank you for visiting nature.com. You are using a browser version with limited support for CSS. To obtain the best experience, we recommend you use a more up to date browser (or turn off compatibility mode in Internet Explorer). In the meantime, to ensure continued support, we are displaying the site without styles and JavaScript.

Information-to-work conversion by Maxwell’s demon in a superconducting circuit quantum electrodynamical system

Abstract

Information thermodynamics bridges information theory and statistical physics by connecting information content and entropy production through measurement and feedback control. Maxwell’s demon is a hypothetical character that uses information about a system to reduce its entropy. Here we realize a Maxwell’s demon acting on a superconducting quantum circuit. We implement quantum non-demolition projective measurement and feedback operation of a qubit and verify the generalized integral fluctuation theorem. We also evaluate the conversion efficiency from information gain to work in the feedback protocol. Our experiment constitutes a step toward experimental studies of quantum information thermodynamics in artificially made quantum machines.

Introduction

The gedanken experiment of Maxwell’s demon has led to the studies concerning the foundations of thermodynamics and statistical mechanics1. The demon measures fluctuations of a system’s observable and converts the information gain into work via feedback control2. Recent developments in information thermodynamics have elucidated the relationship between the acquired information and the entropy production and generalized the second law of thermodynamics and the fluctuation theorems3,4,5,6. Here we extend the scope to a system subject to quantum fluctuations by exploiting techniques in superconducting circuit quantum electrodynamics7. We implement Maxwell’s demon equipped with coherent control and quantum non-demolition (QND) projective measurements on a superconducting qubit, thereby verifying the generalized integral fluctuation theorems8, 9 and the information-to-work conversion. This demonstrates the potential of superconducting circuits as a versatile platform for investigating quantum information thermodynamics under feedback control, which may find applications to quantum error correction10 for computation11 and metrology12.

The fluctuation theorem is valid in systems far from equilibrium and can be regarded as a generalization of the second law of thermodynamics and the fluctuation–dissipation theorem13, 14. In particular, the generalized integral fluctuation theorem, which incorporates the information content on equal footing with the entropy production, bridges information theory and statistical mechanics15, and has been extended to quantum systems9, 16. Experimentally, Maxwell’s demons were implemented in classical systems using colloidal particles4, a single electron box5, and a photodetector6. More recently, the integral quantum fluctuation theorem in the absence of feedback control was tested with a trapped ion17. Maxwell’s demon and the generalized second law in a quantum system were studied in spin ensembles with nuclear magnetic resonance spectroscopy18. However, experimental demonstrations of the fluctuation theorems that directly address the statistics of single quantum trajectories under feedback control are still elusive. Toward this goal, recent progress in superconducting quantum circuits offers a QND projective measurement of a qubit7 and a sufficiently long coherence time19, which altogether enable high-fidelity feedback operations. For example, stabilization of Rabi oscillations using coherent feedback20, 21, fast initialization of a qubit22, and deterministic generation of an entangled state between two qubits23 have been achieved.

Here we verify the generalized integral fluctuation theorem under feedback control by using a superconducting transmon qubit as a quantum system and taking statistics over repeated single-shot measurements on individual quantum trajectories. It is noteworthy that Naghiloo et al.24 recently reported a related experiment with continuous weak measurement and feedback. We first investigate the role of absolute irreversibility associated with a projective measurement and feedback control8, and then study the effect of imperfect projection.

Results

Absolute irreversibility

The fluctuation theorem is formulated by considering a pair of processes, the original forward process and its time-reversed reference process, both of which are assumed to start with the canonical distribution at the same temperature T. Figure 1a illustrates an example of such processes. If we consider an ideal projective measurement and ignore relaxation of the qubit, the fluctuation theorem reads8 (see also Supplementary Note 1)

$$\left\langle {{\mathrm{e}}^{ - \sigma - I_{{\mathrm{Sh}}}}} \right\rangle _{{\mathrm{PM}}} = 1 - \lambda _{{\mathrm{fb}}},$$
(1)

where ISh is the stochastic Shannon entropy the demon acquires in the projective measurement, σ =−β(WF) is the entropy production, β is the inverse temperature 1/(kBT) of the initial state of the qubit, W is the work extracted from the qubit via the feedback operation $$\hat U$$, and ΔF is the change in the equilibrium free energy of the system. The angle brackets $$\left\langle \cdot \right\rangle _{{\mathrm{PM}}}$$ indicate the statistical average obtained with a protocol using a projective measurement for the feedback control. Below we focus on the case with ΔF = 0, i.e., on the process with the same system Hamiltonian at the beginning and the end, for simplicity of discussions.

The constant λfb on the right-hand side of Eq. (1) gives the total probability of those events in the time-reversed process, whose counterparts in the original process do not exist. Such events, which we call absolutely irreversible events, involve a formal divergence of the entropy production and should therefore be treated separately8 (see also Supplementary Note 1). Here, the absolute irreversibility is caused by the combination of the projective measurement that restricts possible forward events and the non-ideal property of the feedback operation that makes the backward events random. For example, in the process shown in Fig. 1a, the projective measurement and the feedback operation, $$\hat U_{\mathrm{g}}$$ or $$\hat U_{\mathrm{e}}$$, always bring the system to the ground state. Therefore, the evolution of the excited state in the reverse process via the operation $$\hat U_{\mathrm{g}}^\dagger$$ or $$\hat U_{\mathrm{e}}^\dagger$$ does not have a counterpart in the forward process. The probability λfb of such events in the present protocol is given by $${\mathrm{e}}^{ - \beta \hbar \omega _{\mathrm{q}}}{\mathrm{/}}\left( {1 + {\mathrm{e}}^{ - \beta \hbar \omega _{\mathrm{q}}}} \right)$$, i.e., the excited state occupation probability in $$\hat \rho _{\mathrm{r}}$$.

The absolute irreversibility makes a significant contribution to the generalized second law of thermodynamics including the effect of the feedback control. For achieving the ultimate bound on the extracted work $$\left\langle W \right\rangle _{{\mathrm{PM}}} = k_{\mathrm{B}}T\left\langle {I_{{\mathrm{Sh}}}} \right\rangle _{{\mathrm{PM}}}$$, the final state distribution $$\hat \rho _{{\mathrm{fin}}}$$ of the system has to be the same as $$\hat \rho _{{\mathrm{ini}}}$$3, 8. However, the projective measurement together with the unoptimized feedback operation prevents it and limits the amount of the extractable work (see Eq. (4) below).

In our experiment, a superconducting transmon qubit (i.e., the system) is placed at the center of an aluminum-made superconducting cavity resonator (Fig. 1b). The qubit state is controlled with a resonant microwave pulse, which induces Rabi rotation. Owing to the interaction between the qubit and the detuned resonator, the resonance frequency of the resonator varies depending on the qubit state. We utilize this property for the QND readout of the qubit; the ground and excited states are distinguished in the phase shift of a readout microwave pulse reflected by the resonator7.

Protocol with projective measurements

Figure 2a shows the sequence of the experiment corresponding to Fig. 1a. The qubit is initialized with a projective measurement and postselection, followed by a resonant pulse excitation, which prepares as an input a superposition state $$\alpha _{\mathrm{g}}\left| {\mathrm{g}} \right\rangle + \alpha _{\mathrm{e}}\left| {\mathrm{e}} \right\rangle$$ $$\left( {\left| {\alpha _{\mathrm{g}}} \right|^2 + \left| {\alpha _{\mathrm{e}}} \right|^2 = 1} \right)$$ of the ground $$\left( {\left| {\mathrm{g}} \right\rangle } \right)$$ and excited $$\left( {\left| {\mathrm{e}} \right\rangle } \right)$$ states of the qubit. As the qubit is subject to the subsequent projective measurement, the coherence in the input state does not have any essential role here, and the coefficients of the superposition define the effective temperature of the system $$T = \left( {\hbar \omega _{\mathrm{q}}{\mathrm{/}}k_{\mathrm{B}}} \right)$$/$${\mathrm{ln}}\left( {\left| {\alpha _{\mathrm{g}}} \right|^2{\mathrm{/}}\left| {\alpha _{\mathrm{e}}} \right|^2} \right)$$ after the projection, where ωq is the qubit excitation energy.

We evaluate the work W(x, z) = E(x) − E(z) extracted from the system by employing the two-point measurement protocol (TPM), in which QND projective measurements on the energy eigenbasis with outcomes x( = g or e) and z( = g or e) are applied respectively to the initial and final states of the system14. Here E(g) and E(e) denotes the energies of the qubit in the ground and excited states, respectively. Depending on the measurement outcome x for the feedback control, the feedback operation does or does not flip the state of the qubit with a π-pulse. A positive amount of the work (W > 0) implies that the energy is extracted from the system via the stimulated emission of a single photon induced by a π-pulse, which flips the qubit state. The probability p(x) of the state x being found gives ISh(x) = − ln p(x).

In Fig. 2b we compare the experimentally obtained statistical average $$\left\langle {{\mathrm{e}}^{\beta W - I_{{\mathrm{Sh}}}}} \right\rangle _{{\mathrm{PM}}}$$ = $$\mathop {\sum}\nolimits_{x,z} {\kern 1pt} p(x,z){\kern 1pt} {\mathrm{e}}^{\beta W(x,z) - I_{{\mathrm{Sh}}}(x)}$$ (blue circles) with the theoretical value of 1 − λfb (blue solid curve), where p(x, z) is the joint probability of observing a particular combination of the outcomes x and z (Supplementary Note 1). We also plot the normalized average work, $$\left\langle W \right\rangle _{{\mathrm{PM}}}{\mathrm{/}}\hbar \omega _{\mathrm{q}}$$ (magenta circles), extracted in the protocol. Depending on the effective temperature of the qubit initial state, the probability of the absolutely irreversible events varies. The excellent agreement between theory and experiment confirms the generalized integral fluctuation theorem under feedback control. Furthermore, the relation in Eq. (1) is proven to hold for any initial effective temperature of the qubit, even at negative temperatures. The smaller the inverse temperature β is, the larger the contribution of absolute irreversibility.

Effect of imperfect projection

Next, we investigate the effects of imperfect projection in the readout. With a weak readout pulse, the state of the qubit is not completely projected. It also gives less information gain for the feedback control. To evaluate the influence of the weak measurement, we add two more readout pulses to the pulse sequence (Fig. 3a). The TPM again starts with a projective readout with outcome x, but now the feedback control is performed based on the subsequent variable-strength measurement with outcome k( = g or e). Then, to project the qubit state before the feedback control, we apply another strong measurement to obtain outcome y( = g or e). Using these measurement outcomes, we calculate the stochastic QC-mutual information IQC(x, k, y) = ln p(y|k) − ln p(x)9. Here, QC indicates that the measured system is quantum and the measurement output is classical2, and p(y|k) is the probability of outcome y being obtained conditioned on the preceding measurement outcome k. The first term in IQC quantifies the correction to ISh because of the imperfect projection. If the measurement for the feedback control is a QND projective measurement and there is no relaxation of the qubit, p(y|k) becomes unity and IQC reduces to ISh. On the other hand, for the measurement with imperfect projection, the absolute irreversibility disappears, because such measurement no longer gives restriction on forward events. Therefore, we obtain λfb = 0. In this case, the generalized integral fluctuation theorem is reformulated as9 (see also Supplementary Note 1)

$$\left\langle {{\mathrm{e}}^{\beta W - I_{{\mathrm{QC}}}}} \right\rangle = 1.$$
(2)

Figure 3b plots the statistical averages, $$\left\langle {{\mathrm{e}}^{\beta W - I_{{\mathrm{QC}}}}} \right\rangle$$ and $$\left\langle {{\mathrm{e}}^{\beta W}} \right\rangle$$, evaluated from the measurement outcomes of the pulse sequence shown in Fig. 3a. For example, $$\left\langle {{\mathrm{e}}^{\beta W - I_{{\mathrm{QC}}}}} \right\rangle$$ is experimentally obtained as $$\mathop {\sum}\nolimits_{x,k,y,z} {\kern 1pt} p\left( {x,k,y,z} \right)$$ $${\mathrm{e}}^{\beta W(x,z) - I_{{\mathrm{QC}}}(x,k,y)}$$, where p(x, k, y, z) is the joint probability of observing a combination of the outcomes. By changing the amplitude of the readout pulse, which measures k, it is possible to continuously vary the post-measurement state from the projected state to a weakly disturbed state. Accordingly, the feedback error probability $$\epsilon _{{\mathrm{fb}}}$$ increases with decreasing the readout pulse amplitude. (See the Supplementary Note 2 for details.) We see that $$\left\langle {{\mathrm{e}}^{\beta W - I_{{\mathrm{QC}}}}} \right\rangle$$ (blue circles), which involves the information gain due to the measurement, is almost unity regardless of the feedback error probability. The small deviation from unity is understood as the effect of the qubit relaxation during the TPM as indicated by the simulated result (black dots and gray lines interpolating them)25 (see Supplementary Note 2). In contrast, the value $$\left\langle {{\mathrm{e}}^{\beta W}} \right\rangle$$ (red squares), which discards the information used in the feedback operation, clearly deviates from unity. For the weaker readout amplitude, however, the amount of information gain becomes less, and thus $$\left\langle {{\mathrm{e}}^{\beta W}} \right\rangle$$ becomes closer to unity. This situation corresponds to the integral fluctuation theorem in the absence of feedback control.

Figure 3c depicts the statistical averages $$\left\langle {I_{{\mathrm{QC}}}} \right\rangle$$ (blue circles) and $$\left\langle {\beta W} \right\rangle$$ (red squares) as functions of the feedback error probability $$\epsilon _{{\mathrm{fb}}}$$. Here, $$\left\langle {I_{{\mathrm{QC}}}} \right\rangle$$ is always larger than $$\left\langle {\beta W} \right\rangle$$ in accordance with the inequality, $$\left\langle {\beta W} \right\rangle \le \left\langle {I_{{\mathrm{QC}}}} \right\rangle$$, derived from the fluctuation theorem Eq. (2). The QC-mutual information $$\left\langle {I_{{\mathrm{QC}}}} \right\rangle$$ decreases to zero with increasing $$\epsilon _{{\mathrm{fb}}}$$. On the other hand, for $$\epsilon _{{\mathrm{fb}}}$$ → 0, $$\left\langle {I_{{\mathrm{QC}}}} \right\rangle$$ approaches $$\left\langle {I_{{\mathrm{Sh}}}} \right\rangle _{{\mathrm{PM}}} = - \mathop {\sum}\nolimits_x {\kern 1pt} p(x){\mathrm{ln}}{\kern 1pt} p(x)$$ (black dashed line). The remaining difference between $$\left\langle {I_{{\mathrm{QC}}}} \right\rangle$$ and $$\left\langle {I_{{\mathrm{Sh}}}} \right\rangle$$ is due to the qubit relaxation between the two readouts for k and y.

Conversion efficiency

The conversion efficiency from the QC-mutual information $$\left\langle {I_{{\mathrm{QC}}}} \right\rangle$$ to the work $$\left\langle W \right\rangle$$ is defined for T > 0 as4, 5

$$\eta = \frac{{\left\langle W \right\rangle }}{{k_{\mathrm{B}}T\left\langle {I_{{\mathrm{QC}}}} \right\rangle }},$$
(3)

where we omit the contribution from the free-energy change by assuming ΔF = 0. As shown in the inset of Fig. 3c, η is 0.65 in the limit of $$\epsilon _{{\mathrm{fb}}}$$ → 0 corresponding to the case with the projective measurement shown in Fig. 2.

The efficiency obtained with the projective measurement is to be compared with the following inequalities:

$$\left\langle W \right\rangle \le \left\langle W \right\rangle _{{\mathrm{PM}}} \le k_{\mathrm{B}}T\left\langle {I_{{\mathrm{Sh}}}} \right\rangle _{{\mathrm{PM}}} + k_{\mathrm{B}}T{\kern 1pt} {\mathrm{ln}}\left( {1 - \lambda _{{\mathrm{fb}}}} \right).$$
(4)

The first inequality describes the fact that for a given protocol the extracted work with a proper projective measurement is superior to that obtained with an imperfect projection, which is demonstrated in Fig. 3c. On the other hand, the second inequality derived for T > 0 from the fluctuation theorem Eq. (1) represents the generalized second law of information thermodynamics (Supplementary Note 1). We find that the contribution from the absolute irreversibility sets the limit of the efficiency, given by η = 1 − |ln(1 − λfb)|/$$\left\langle {I_{{\mathrm{Sh}}}} \right\rangle _{{\mathrm{PM}}}$$, which is indicated by the dashed line in the inset of Fig. 3c. The experimental result demonstrates that our feedback scheme achieves the equality condition in Eq. (4) and is optimal (though not ideal) in this sense.

Discussion

We have successfully implemented Maxwell’s demon in a setup based on superconducting circuit quantum electrodynamics and verified the generalized integral fluctuation theorem in a single qubit. In the present work, the measurement outcome obtained by the demon was analyzed in terms of the Shannon and the QC-mutual information. On the other hand, the effect of the coherence can be investigated in a similar setup26. By implementing the memory of the demon with a qubit27, or a quantum resonator as demonstrated recently28, one can characterize the energy cost for the measurement29 or study feedback schemes maintaining the coherence between the system and the memory to improve the energy efficiency of the feedback. Superconducting quantum circuits further allow us to extend the study of information thermodynamics to larger and more complex quantum systems. It will lead to an estimation of the lower bound of the thermodynamic cost for quantum information processing.

Methods

Sample

The transmon qubit has the resonance frequency ωq/2π = 6.6296 GHz, the energy relaxation time T1 = 24 μs, and the phase relaxation time $$T_2^ \ast = 16$$ μs at the base temperature ~ 10 mK of a dilution refrigerator. The cavity has the resonance frequency ωcav/2π = 10.6180 GHz, largely detuned from the qubit, and the relaxation time 1/κ = 0.076 μs. The coupling strength between the qubit and the resonator is estimated to be g/2π = 0.14 GHz.

Pulse sequences

The pulse sequences for the experiments in Figs. 2 and 3 take about 2.5 and 4 μs, respectively. Each readout pulse has the width of 500 ns. The qubit excitation pulse and the feedback control pulse are both 20 ns wide. See the Supplementary Note 2 for details. We take the statistics of the outcomes by repeating the pulse sequence about 8 × 104 times, with a repetition interval 300 μs, which is much longer than the qubit relaxation time.

Data availability

All the data used in this study are available from the corresponding author upon reasonable request.

References

1. 1.

Leff, H. & Rex, A. Maxwell’s Demon 2 Entropy, Classical and Quantum Information, Computing (CRC Press, Boca Raton, 2002).

2. 2.

Sagawa, T. & Ueda, M. Second law of thermodynamics with discrete quantum feedback control. Phys. Rev. Lett. 100, 080403 (2008).

3. 3.

Parrondo, J. M., Horowitz, J. M. & Sagawa, T. Thermodynamics of information. Nat. Phys. 11, 131–139 (2015).

4. 4.

Toyabe, S., Sagawa, T., Ueda, M., Muneyuki, E. & Sano, M. Experimental demonstration of information-to-energy conversion and validation of the generalized Jarzynski equality. Nat. Phys. 6, 988–992 (2010).

5. 5.

Koski, J. V., Maisi, V. F., Sagawa, T. & Pekola, J. P. Experimental observation of the role of mutual information in the nonequilibrium dynamics of a Maxwell demon. Phys. Rev. Lett. 113, 030601 (2014).

6. 6.

Vidrighin, M. D. et al. Photonic Maxwell’s demon. Phys. Rev. Lett. 116, 050401 (2016).

7. 7.

Blais, A., Huang, R.-S., Wallraff, A., Girvin, S. M. & Schoelkopf, R. J. Cavity quantum electrodynamics for superconducting electrical circuits: An architecture for quantum computation. Phys. Rev. A. 69, 062320 (2004).

8. 8.

Funo, K., Murashita, Y. & Ueda, M. Quantum nonequilibrium equalities with absolute irreversibility. New. J. Phys. 17, 075005 (2015).

9. 9.

Funo, K., Watanabe, Y. & Ueda, M. Integral quantum fluctuation theorems under measurement and feedback control. Phys. Rev. E 88, 052121 (2013).

10. 10.

Terhal, B. M. Quantum error correction for quantum memories. Rev. Mod. Phys. 87, 307–346 (2015).

11. 11.

Kelly, J. et al. State preservation by repetitive error detection in a superconducting quantum circuit. Nature 519, 66–69 (2015).

12. 12.

Unden, T. et al. Quantum metrology enhanced by repetitive quantum error correction. Phys. Rev. Lett. 116, 230502 (2016).

13. 13.

Jarzynski, C. Equalities and inequalities: irreversibility and the second law of thermodynamics at the nanoscale. Annu. Rev. Condens. Matter Phys. 2, 329–351 (2010).

14. 14.

Campisi, M., Hänggi, P. & Talkner, P. Quantum fluctuation relations: foundations and applications. Rev. Mod. Phys. 83, 771–791 (2011).

15. 15.

Sagawa, T. & Ueda, M. Generalized Jarzynski equality under nonequilibrium feedback control. Phys. Rev. Lett. 104, 090602 (2010).

16. 16.

Morikuni, Y. & Tasaki, H. Quantum Jarzynski-Sagawa-Ueda relations. J. Stat. Phys. 143, 1–10 (2011).

17. 17.

An, S. et al. Experimental test of the quantum Jarzynski equality with a trapped-ion system. Nat. Phys. 11, 193–199 (2014).

18. 18.

Camati, P. A. et al. Experimental rectification of entropy production by Maxwell’s demon in a quantum system. Phys. Rev. Lett. 117, 240502 (2016).

19. 19.

Oliver, W. D. & Welander, P. B. Materials in superconducting quantum bits. MRS Bull. 38, 816–825 (2013).

20. 20.

Vijay, R. et al. Stabilizing Rabi oscillations in a superconducting qubit using quantum feedback. Nature 490, 77–80 (2012).

21. 21.

Campagne-Ibarcq, P. et al. Persistent control of a superconducting qubit by stroboscopic measurement feedback. Phys. Rev. X 3, 021008 (2013).

22. 22.

Ristè, D., Bultink, C. C., Lehnert, K. W. & DiCarlo, L. Feedback control of a solid-state qubit using high-fidelity projective measurement. Phys. Rev. Lett. 109, 240502 (2012).

23. 23.

Ristè, D. et al. Deterministic entanglement of superconducting qubits by parity measurement and feedback. Nature 502, 350–354 (2013).

24. 24.

Naghiloo, M. et al. Thermodynamics along individual trajectories of a quantum bit. Preprint at http://arxiv.org/abs/1703.05885 (2017).

25. 25.

Pekola, J. P., Masuyama, Y., Nakamura, Y., Bergli, J. & Galperin, Y. M. Dephasing and dissipation in qubit thermodynamics. Phys. Rev. E 91, 062109 (2015).

26. 26.

Elouard, C., Herrera-Martí, D., Huard, B., Auffèves, A. Extracting work from quantum measurement in Maxwell’s demon engines. Phys. Rev. Lett. 118, 260603 (2017).

27. 27.

Quan, H. T., Wang, Y. D., Liu, Y.-x, Sun, C. P. & Nori, F. Maxwell’s demon assisted thermodynamic cycle in superconducting quantum circuits. Phys. Rev. Lett. 97, 180402 (2006).

28. 28.

Cottet, N. et al. Observing a quantum Maxwell demon at work. Proc. Natl Acad. Sci. USA 114, 7561–7564 (2017).

29. 29.

Sagawa, T. & Ueda, M. Minimal energy cost for thermodynamic information processing: Measurement and information erasure. Phys. Rev. Lett. 102, 250602 (2009).

Acknowledgements

We acknowledge T. Sagawa for useful discussions and W.D. Oliver for providing the transmon qubit. This work was partly supported by JSPS KAKENHI (Grant Number 26220601), NICT, and JST ERATO (Grant Number JPMJER1601). Y. Murashita was supported by JSPS through the Program for leading Graduate School (MERIT) and JSPS Fellowship (Grant Number JP15J00410). K.F. acknowledges supports from the National Science Foundation of China (grants 11375012 and 11534002).

Author information

Authors

Contributions

Y. Masuyama, K.F., and Y. Murashita designed the experiments. Y. Masuyama conducted the experiments. S.K. and Y.T. assisted in setting up the measurement system. K.F., Y. Murashita, and M.U. provided theoretical supports. A.N., Y.T., and R.Y. participated in discussions on the analysis. Y. Masuyama and Y.N. wrote the manuscript with feedback from all authors. M.U. and Y.N. supervised the project.

Corresponding author

Correspondence to Y. Nakamura.

Ethics declarations

Competing interests

The authors declare no competing interests.

Publisher's note: Springer Nature remains neutral with regard to jurisdictional claims in published maps and institutional affiliations.

Electronic supplementary material

41467_2018_3686_MOESM1_ESM.pdf

Supplementary Information(PDF 853 kb)

41467_2018_3686_MOESM2_ESM.pdf

Peer Review File(PDF 316 kb)

Rights and permissions

Reprints and Permissions

Masuyama, Y., Funo, K., Murashita, Y. et al. Information-to-work conversion by Maxwell’s demon in a superconducting circuit quantum electrodynamical system. Nat Commun 9, 1291 (2018). https://doi.org/10.1038/s41467-018-03686-y

• Accepted:

• Published:

• Maximizing power and velocity of an information engine

• Tushar K. Saha
• , Joseph N. E. Lucero
• , Jannik Ehrich
• , David A. Sivak
•  & John Bechhoefer

Proceedings of the National Academy of Sciences (2021)

• Dissipative state transfer and Maxwell's demon in single quantum trajectories: Excitation transfer between two noninteracting qubits via unbalanced dissipation rates

• Fabrizio Minganti
• , Vincenzo Macrì
• , Alessio Settineri
• , Salvatore Savasta
•  & Franco Nori

Physical Review A (2021)

• Efficiency estimation for an equilibrium version of the Maxwell refrigerator

• Toby Joseph
•  & Kiran V.

Physical Review E (2021)

• Gate-based superconducting quantum computing

• Sangil Kwon
• , Akiyoshi Tomonaga
• , Gopika Lakshmi Bhai
• , Simon J. Devitt
•  & Jaw-Shen Tsai

Journal of Applied Physics (2021)

• Entropy and information flow in quantum systems strongly coupled to baths

•  & Michael Galperin

Physical Review B (2021)


text:
# x64 Development

#### jangofett287

##### Heat shield 'tester'
For what it's worth, I've generally found GitKraken to be the least worst GUI for git.

That works fine as long as that repository is only used by one person
Once "the source" (I think 'upstream' is the right term) of that copy is changed by another developer things get complicated in my head.
Another level of abstraction is the "fork" (github thing)...
So 1st I make a fork of martins repository - easy, one click,
Then I 'clone' (possibly wrong lingo) a local copy from my github repository...
while developing I like to "update" (possibly wrong lingo) my local copy with changes martin has made in the "original" repository...
That's where the 'remote' and 'upstream' things get confusing at first.

I would love to have a thread (single post) that would describe these steps for contributing to Orbiter[*].

[*] "How to provide a pull request to Orbiter"

I'll try and explain:
"remote" is just a git server with a copy of the repo.
"fork" is GitHub's term for a copy of an existing repo on to a different account. This makes a new repo. GitHub keeps note of the connection and makes it visible in the "network" tab and also when creating pull requests.
"clone" is making a copy of a repo on your local machine
"origin" is usually the remote you cloned from
"upstream" is usually the remote you forked from. You may have to add this manually.

The recommended workflow is fork, clone, branch, commit, push (to origin, ie: your fork), pull request.

#### martins

##### Orbiter Founder
Orbiter Founder
Speaking of git hell, I may just have run into a slight snag.
I renamed my trunk branch from master to main to comply with current github convention.
(If you have cloned the repository you may need to update your local repository accordingly, but you will get a warning from github on your next pull with instructions).

However, I wonder if there are some unpleasant side effects with respect to other github forks. I was just trying to merge Face's pull request, but the CI build failed. It looks like the merge doesn't just try to update the two files in the pull request, but changes a lot of other files, essentially reverting my 64-bit edits. I wonder if the branch name change got things out of sync (despite github claiming that it should be transparent).

@Face : sorry to be a pain, but just to check if that is the problem: could you update your local repository to reflect the name change and then push it to your gitub repo. I'll then try to merge again. If that also doesn't work I'll apply the changes manually, and hope that things will sync again in future pull requests.

Edit: never mind, I fixed my problem by first merging the pull request into a separate branch, and then merging into main from there.

Last edited:

#### GLS

##### Well-known member
Orbiter Contributor
Well, the point is: git is not easy. Far from it. It is THE most complex and unnecessarily complicated tool of all the DVCS systems that came out around 2005. And I agree: Github is not making the situation any better.
I knew the git part. I just created a Github account and... yeah, "not making the situation any better" is an understatement.

ATM, my opinion of this is such that I'll probably not move my SSV repo to there. The best part (<- irony) is where they show in the user homepage everything the user does... probably somewhere in there is also the last time the user went to the bathroom.

#### Urwumpe

##### Not funny anymore
Donator
Well, the point is: git is not easy. Far from it. It is THE most complex and unnecessarily complicated tool of all the DVCS systems that came out around 2005. And I agree: Github is not making the situation any better.

I would mildly disagree there:

• It is complex, but not the most complex (That is TFVC - also from 2005, BTW).
• It is complex, but not unnecessarily. The sophistication of the tool serves a purpose, sometimes sadly an historic one.
But yeah, it isn't easy, like any distributed system. If it would be, I would have one job less. But it can be done and even beginners can learn quickly how to use it - even on the command line. Or maybe especially on the command line. Teaching old subversion users, that its really better to commit things, even if they might be wrong, is the hardest work. A commit on git is done in less than a second for a big project. On subversion, this was often the time for doing your weekend shopping, while your computer was busy.

And of course, learning to use git is not the same as learning to use Github. While I understand this fork-thing from a business perspective of them, its not a part of git , it just adds an additional layer into the repository tree, a new layer of complexity.

#### n72.75

Tutorial Publisher
Donator
I really like git. Github is definitely its own flavor though.

The way we approach it with NASSP:

There is a branch on the orbiternassp account called Orbiter2016 (orbiternassp/Orbiter2016 ). This is what we push new features/fixes to when an update comes out.

Each developer has their own fork. On our own forks we have the Orbiter2016 branch (I know these release target R90, it's just a name), as well as as many other branches as we like. Here is an example of mine: https://github.com/n7275/NASSP/branches. I keep my Orbiter2016 branch even with the orbiternassp/Orbiter2016 so that if I need to test another users scenario on the current build, or just fly a mission, all I have to do is check out my Orbiter2016 branch. Github even has a feature now that let's you fetch and merge from the upstream branch (for our purposes, the repo you forked from).

The big advantage with git is that I can also checkout other developer's branches, and I can even make commits and pull requests to their repositories and branches as well (they have to pull my changes hence I make a pull "request" in github lingo, and they "approve the request").

Most of the committing and pushing of code I do within visual studio.

VS/git also has its own diff viewer for each commit, that you can use before you commit.

Some times, like in the case of my fuel cell project this ran for many months and, while I made commits and added features to it I also pulled changes from the main repo so that could avoid, or at lease immediately address merge conflicts.

If you really mess your "main" branch up, you can always checkout main, fetch upstream, and reset --hard. This will force your "main" branch to be exactly the same as the upstream's.

I really recommend the workflow of: If you want to implement a new feature, work on it in a branch of your fork. When it's done and you've tested it, make a pull request from:

orbitersim/orbiter <--- yourUser/myNewFeatureBranchThatIveTestedRealGoodAndHasNoBugsThatIKnowOf

#### jedidia

##### shoemaker without legs
There is no easy way around that, recipes don't work in my experience. You can't teach people to fly a plane by handing them the checklist, either.
The thing is, contributing to an existing project is more complicated than managing your own repo... The basic workflow with git is pretty simple. Pretty much all you need working in your own repo is pull, commit, push, and the occasional stash and merge.
When you're contributing to a project with lots of other contributers... yeah things can get messsy pretty quickly. You have to at least learn about rebase, pull requests and resolving merge conflicts. And while an IDE can make the later one a lot less painful, I have no idea how VisualStudio express performs in that regard...

#### Urwumpe

##### Not funny anymore
Donator
The thing is, contributing to an existing project is more complicated than managing your own repo... The basic workflow with git is pretty simple. Pretty much all you need working in your own repo is pull, commit, push, and the occasional stash and merge.
When you're contributing to a project with lots of other contributers... yeah things can get messsy pretty quickly. You have to at least learn about rebase, pull requests and resolving merge conflicts. And while an IDE can make the later one a lot less painful, I have no idea how VisualStudio express performs in that regard...

Well, I think you can ignore the rebase. It is not needed for the actual workflow at all, it only helps making the version history easier to read. And merges are way easier in git than in Subversion or Mercurial. And don't get me started on old CVS there.

#### Face

##### Well-known member
Orbiter Contributor
Beta Tester
The thing is, contributing to an existing project is more complicated than managing your own repo... The basic workflow with git is pretty simple. Pretty much all you need working in your own repo is pull, commit, push, and the occasional stash and merge.
When you're contributing to a project with lots of other contributers... yeah things can get messsy pretty quickly. You have to at least learn about rebase, pull requests and resolving merge conflicts. And while an IDE can make the later one a lot less painful, I have no idea how VisualStudio express performs in that regard...

Well, git was created specifically for collaboration. And as you pointed out, it needs a lot more outside of the single-user workflow. Besides that, the single-user workflow is already more complicated than necessary and far from being simple. No other tool exposes the index that much, or even apply the divide of commit and push/pull on the user in this freaky way (pull is practically auto-merging). Heck, even a local repo you want to have as push/pull target needs that weird "bare repo" configuration.

And I disagree with the notion that git is so complicated because the features are so powerful. Mercurial is as good as git in this regards (it even has more features), but with a much better interface.

But as I wrote before: git won the popularity game. As a consequence, it is ubiquitous, is integrated everywhere, offers a broad palette of helper tools, has incredible support in the internet. All that despite its arcane syntax, obscure terminology and freaky design decisions. It may be a foreign language to speak, but one you will have to learn as good as possible if you want to live in the open source community.

And now I stop my DVCS talk again. I have done my fair share of it here years ago already, and got a bit tired of the topic.

#### Urwumpe

##### Not funny anymore
Donator
Oh well, before we get a Mercurial vs git flamewar here. ?

Maybe I should write a short git tutorial for the interested beginners.

#### jedidia

##### shoemaker without legs
Mercurial is as good as git in this regards (it even has more features), but with a much better interface.
I have never used Mercurial, but I will certainly not disagree that Gits interface is... unfortunate.
Maybe I should write a short git tutorial for the interested beginners.
There's plenty of those to go around. The major stumbling block for me in the beginning was that I just didn't get how the thing works, so I kept messing up ( I mean, something as innocent as amending a local commit because you spotted a typo in the commit message while already having it pushed to the remote can really ruin your day when you're new to Git!). A tutorial that covers all those little mishaps you tend to make at the start, how to fix them, and why exactly it is that what you did was wrong, inevitably becomes a curriculum...

#### JDat

##### Active member
Git was made by linux kernel developers for linux kerner development. Somehow linux is working, so, blame to git sounds like lack of understanding and knowledge how to use it.

#### JDat

##### Active member
Not the most important thing, but MFD template and AscentMFD won't compile for x64.
I am far away from my VS2019 machine and git, so, please check, fix and compile if you have spare time.
Looks like there are problems with MsgProc return value.
Need to be LPARAM (???) instead of int.
Affected files and lines:
MFDTemplate.h : 26
MFDTemplate.cpp : 107
AscentMFD.h : 23
AscentMFD.cpp : 170

#### jedidia

##### shoemaker without legs
blame to git sounds like lack of understanding and knowledge how to use it.
I don't think anybody here said anything different. The trouble we're having is that for collaboration on the source code, a lot of people have to start using it that in fact don't know how to use it. And if your memory is intact, you will probably remember how painful the learning process was...

#### Urwumpe

##### Not funny anymore
Donator
I don't think anybody here said anything different. The trouble we're having is that for collaboration on the source code, a lot of people have to start using it that in fact don't know how to use it. And if your memory is intact, you will probably remember how painful the learning process was...

I will likely be going to teach people how to use git in a few weeks (Will be the first time I do that outside my department and the first time as a classic trainer instead of the usual mentoring). I know the pains - and even I still feel like a terrible noob there sometimes. Despite using it for years, I still feel insecure if I really remember the less often used commands correctly and really hope to be more competent when needed, as I perceive myself.

#### kuddel

##### Donator
Donator
@DarkWanderer : Since you seem to have "created" the CI, I have noticed something:
The library Orbitersdk\lib\Orbiter_server.lib usually was named just Orbitersdk\lib\Orbiter.lib, shouldn't we keep it that way?
Possibly a rename in martins build-scripts did this, or the project files should be unified to do this consitently in all Configurations (win32/x64 Debug/Release)

#### martins

##### Orbiter Founder
Orbiter Founder
This is probably my fault. The two orbiter.exe targets (.\orbiter.exe and .\Modules\Server\orbiter.exe) are known to cmake by their target IDs "Orbiter" and "Orbiter_server" (since you can't have two targets with the same name). Usually orbiter.lib is generated by building .\orbiter.exe, but in the x64 version that target isn't built, so the input library has to be generated from building .\Modules\Server\orbiter.exe. The generated binaries derive their names from the target IDs unless explicitly modified. I did modify the name for the exe (so it generates .\Modules\Server\Orbiter.exe instead of .\Modules\Server\Orbiter_server.exe), but apparently that didn't carry over to the input library. I'll see if I can fix that.

#### martins

##### Orbiter Founder
Orbiter Founder
Should be fixed now. Please let me know if there are still issues with this.

#### jarmonik

##### Well-known member
Orbiter Contributor
Beta Tester
If you change this:
Code:
set_target_properties(Orbiter
PROPERTIES
RUNTIME_OUTPUT_DIRECTORY ${ORBITER_BINARY_ROOT_DIR} COMPILE_DEFINITIONS INLINEGRAPHICS ENABLE_EXPORTS 1 FOLDER Core ) To This: Code: set_target_properties(Orbiter PROPERTIES LINK_FLAGS "/SUBSYSTEM:WINDOWS" RUNTIME_OUTPUT_DIRECTORY_DEBUG${ORBITER_BINARY_ROOT_DIR}
RUNTIME_OUTPUT_DIRECTORY_RELEASE \${ORBITER_BINARY_ROOT_DIR}
COMPILE_DEFINITIONS INLINEGRAPHICS
ENABLE_EXPORTS 1
FOLDER Core
)

It "should" fix the problem with binaries ending up in "Debug" "Release" sub-folders

#### jarmonik

##### Well-known member
Orbiter Contributor
Beta Tester
When migrating the D3D9Client into the Orbiter repository what's gonna happen for the project history. For me it really doesn't matter. I am just asking if I should import the project history from SVN to Git or Not ?

Replies
101
Views
7K
Replies
74
Views
5K
Replies
13
Views
3K
Replies
10
Views
272
Replies
36
Views
4K


text:
# Mapbox Visual Center Algorithm: arcpy (attempt #2)

Yesterday, I attempted to replicate the Mapbox Visual Center algorithm using ArcGIS arcpy (Python). Today, I actually looked at the source code (code, license) and attempted to fully port it over from JavaScript. I think it works properly, but you tell me.

def polylabel(polygon, centroid, precision, debug):
cells = []
precision = precision or 1.0
extent = polygon.extent
minX, minY, maxX, maxY = (extent.XMin, extent.YMin, extent.XMax, extent.YMax)
width = extent.width
height = extent.height
cellSize = min([width, height])
h = cellSize / 2
cellQueue = []
x = minX
while x < maxX:
y = minY
while y < maxY:             cell = Cell(x+h, y+h, h, polygon)             cells.append(cell.geom)             cellQueue.append(cell)             y += cellSize         x += cellSize     bestCell = Cell(centroid[0], centroid[1], 0, polygon)     numProbes = len(cellQueue)     while len(cellQueue):         cellQueue.sort(key=lambda cell: cell.d)         cell = cellQueue.pop()         cells.append(cell.geom)         if cell.d > bestCell.d:
bestCell = cell
if cell.max - bestCell.d <= precision:
continue
h = cell.h/2
cellQueue.append(Cell(cell.x-h, cell.y-h, h, polygon))
cellQueue.append(Cell(cell.x+h, cell.y-h, h, polygon))
cellQueue.append(Cell(cell.x-h, cell.y+h, h, polygon))
cellQueue.append(Cell(cell.x+h, cell.y+h, h, polygon))
numProbes += 4
return [bestCell.x, bestCell.y, cells]
class Cell():
def __init__(self, x, y, h, polygon):
self.x = x
self.y = y
self.h = h
self.d = pointToPolygonDist(x, y, polygon)
self.max = self.d + self.h * math.sqrt(2)
self.geom = arcpy.Polygon(arcpy.Array([arcpy.Point(x-h,y-h),arcpy.Point(x+h,y-h),arcpy.Point(x+h,y+h),arcpy.Point(x-h,y+h)]))
def pointToPolygonDist(x, y, polygon):
point_geom = arcpy.PointGeometry(arcpy.Point(x, y),sr)
polygon_outline = polygon.boundary()
min_dist = polygon_outline.queryPointAndDistance(point_geom)
sign_dist = min_dist[2] * ((min_dist[3]-0.5)*2)
return sign_dist
fc = 'BEC_POLY selection'
sr = arcpy.Describe(fc).spatialReference
centroids = []
label_points = []
cells = []
with arcpy.da.SearchCursor(fc,['SHAPE@','SHAPE@XY']) as cursor:
for row in cursor:
best_point = polylabel(row[0],row[1],.75,'#')
centroids.append(arcpy.PointGeometry(row[0].centroid,sr))
label_points.append(arcpy.PointGeometry(arcpy.Point(best_point[0], best_point[1]),sr))
for cell in best_point[2]:
cells.append(cell)
arcpy.CopyFeatures_management(centroids,r'in_memory\centroids')
arcpy.CopyFeatures_management(label_points, r'in_memory\label_points')
arcpy.CopyFeatures_management(cells, r'in_memory\cells')

# Mapbox Visual Center Algorithm: arcpy

On Monday, Mapbox published a JavaScript implementation of a fast algorithm for finding the visual center of a polygon using quadtrees (blog, code). I took a stab at it using Python/arcpy in ArcGIS:

def quadify(poly): # split polygon into quads
ext = poly.extent
TM = arcpy.Point((ext.XMin+ext.XMax)/2,ext.YMax)
LM = arcpy.Point(ext.XMin,(ext.YMin+ext.YMax)/2)
BM = arcpy.Point((ext.XMin+ext.XMax)/2,ext.YMin)
RM = arcpy.Point(ext.XMax,(ext.YMin+ext.YMax)/2)
TL = arcpy.Polygon(arcpy.Array([ext.upperLeft,LM,poly.centroid,TM]),sr)
TR = arcpy.Polygon(arcpy.Array([TM,poly.centroid,RM,ext.upperRight]),sr)
BL = arcpy.Polygon(arcpy.Array([LM,ext.lowerLeft,BM,poly.centroid]),sr)
BR = arcpy.Polygon(arcpy.Array([poly.centroid,BM,ext.lowerRight,RM]),sr)
return [TL,TR,BL,BR]
poly_boundary = poly.boundary()
dist = q_dist[2] if q_dist[3] else -q_dist[2]
max_dist = 0
dists = {}
max_dist = cur_dist if cur_dist > max_dist else max_dist
for k,v in dists.iteritems():
if k > max_dist * 0.90: # precision = 90%
fc = 'wetlands_select' # feature class/layer
sr = arcpy.Describe(fc).spatialReference # spatial reference
out_polys = []
out_points = []
with arcpy.da.SearchCursor(fc,'SHAPE@',spatial_reference=sr) as cursor: # loop polygons
for row in cursor:
ext = row[0].extent
center = arcpy.PointGeometry(arcpy.Point((ext.XMin+ext.XMax)/2,(ext.YMin+ext.YMax)/2),sr)
for i in range(10): # quadify 10x
arcpy.CopyFeatures_management(out_polys,r'in_memory\polys')
arcpy.CopyFeatures_management(out_points,r'in_memory\points')

Notes:

I’m not 100% sure that this emulates the base Mapbox algorithm, and I didn’t attempt to implement the “priority queue” enhancement.

The results are somewhat sensitive to the precision factor, but I suppose that’s the be expected with a speed algorithm.

I realize that you can calculate a label point much easier within ArcGIS using out-of-the-box tools. This was just me exploring the algorithm.

# GCHQ Quiz Grinch: 2

***Contains spoilers, obviously.***

As I mentioned previously, the GCHQ (Government Communications Headquarters) released a hilariously infuriating Christmas card, which consisted of a logic puzzle, which once solved, led to more puzzles, which led to more puzzles, and so on. I cheated to complete Part 2. And, here’s how you can cheat to complete Part 4.

Part 4 consists of three series of numbers. These numbers, back to back, create an IP address to access Part 5. Three numbers to make one IP address. Hmmm, an IP address contains four numbers. One of the numbers must be a decimal. So, I’m looking for two integers and one float, but I’m not sure which.

If you look at the source code, there is a hash function that is used to verify that the answers are correct. Basically, it concatenates the three inputs, performs some one-way computations, returns two answers, and checks if they match two other, known numbers. So, you could work out the correct answers (if you’re smart enough), ooooooooor you could try all possible answers (which is what I did).

There are a few ways to constrain the list of possible answers, which will cut down on the computation time. All IP address components are integers between 0 and 255. Also, I took a guess that the first component was between 0-128 – a Class A IP address. The hash function takes 3 inputs, separated by null characters (“\0”). That means I need to separate 4 integers by two null characters and one period (representing a decimal), but I don’t know in which place the decimal should be. There are three possibilities for that.

So, in all, there are 128 * 256 * 256 * 256 * 3 possibilities (first, second, third, fourth IP components, and decimal placements) to inspect. That’s a grand total of 6,442,450,944 combinations to evaluate. Even for Python, that’s a lot of comparisons, but it can be done. It takes about 0.115s to run 128*3 comparisons, about 29.5s to run 128*256*3 comparisons. To complete our six billion comparisons, it will take approximately 22.5 days. Luckily, the final answer is located fairly early in the sequence, so the final run time is about 8.7 days.

Here’s the script I used:

import ctypes, sys, cProfile

def hsh(dat):
resultA = 3141592654
resultB = 1234567890
for i in range(2):
initA = resultA
initB = resultB
for j in range(len(dat)):
resultA += ord(dat.lower()[j])
resultB = ctypes.c_int((resultA * 31) ^ resultB).value
tmp = resultA & resultA
resultA = resultB & resultB
resultB = tmp
resultA = ctypes.c_int(resultA ^ initA).value
resultB = ctypes.c_int(resultB ^ initB).value
return [resultA, resultB]

dot_config = [['.','\0','\0'],['\0','.','\0'],['\0','\0','.']]

def findIP():
for x in range(128):
for y in range(256):
for z in range(256):
for a in range(256):
for dots in dot_config:
res = hsh("".join([str(x), dots[0], str(y), dots[1], str(z), dots[2], str(a)]))
if (res[0]==1824745082) and (res[1]==560037081):
print ([str(x), dots[0], str(y), dots[1], str(z), dots[2], str(a)])
sys.exit()
print (x, y, z, a, res[0], res[1])

cProfile.runctx('findIP()',None,locals())

And, the final answers: 52, 30.87, 208

The quiz is for charity, so don’t forget to donate here.

# GCHQ Quiz Grinch: 1

***Contains spoilers, obviously.***

The GCHQ (Government Communications Headquarters) released a hilariously infuriating Christmas card, which consisted of a logic puzzle, which once solved, led to more puzzles, which led to more puzzles, and so on.

I solved the first puzzle no problem. That revealed Part 2, a series of 6 multiple choice questions, all of which required a correct answer to move on. I got two of them, but was left at a loss for the other four. I gave it an honest try, but really wanted to see what Part 3 had in store. So, I turned to cheating. And, here’s how.

Clicking through the answers, you may notice that the URL contains the previous answer letter. For example, if your answers were A, B, C, D, E, and F, the final webpage (telling you that you were wrong) would have the URL: http://s3-eu-west-1.amazonaws.com/puzzleinabucket/ABCDEF.html

If you had enough time, you could type in each combination and see if that led to a “correct” URL. Obviously, that would be fairly time-consuming. Each of 6 questions had 6 possible answers, which means 6 ^ 6 = 46656 possibilities. You could save some time by including known correct answers. In my case, I had two answers of which I was confident. That left me with 6 ^ 4 = 1296 possibilities, still too many to inspect manually.

However, a simple Python script could load the pages fairly quickly (about once per second, or a maximum of 21.6 minutes), inspect the resulting webpage, and determine if it contains a message indicating that the combination was incorrect. If so, move onto next combination. If not, stop and print the correct combination.

Here’s the script:

import requests, time, sys
from lxml import html

opts = ['A','B','C','D','E','F'] # possible answers
for i in opts:
for j in opts:
for k in opts:
for l in opts:
url = i + j + k + 'A' + l + 'E' # 4 unknown, 2 known
time.sleep(1) # provide rest in between calls

r = requests.get('http://s3-eu-west-1.amazonaws.com/puzzleinabucket/' + url + '.html') # make call
tree = html.fromstring(r.text) # store page html

if tree.xpath('//div[contains(., "Sorry - you did not get all the questions correct.")]/p//text()'):
pass
else:
print "SUCCESS " + url
sys.exit() # quit script once correct combination is found

The quiz is for charity, so don’t forget to donate here.

ESRI runs a biannual contest to encourage participation on their help forum, GeoNet. Prizes go to the top ten point-getters. I found out during the last contest that it takes a great deal of time and persistence to keep up with the top of the pack (I ended up 5th). There are several tips for optimizing your effort (some of which I outlined, somewhat sarcastically, here).

One such tip is: get on GeoNet during times when there are the greatest number of fresh, unanswered questions. If you’ve spent any time on GeoNet, you have likely noticed that questions are generally asked during North American working hours, when people are struggling to get through their work-related GIS tasks. I wanted to put some better numbers to this idea, so I set about gathering the data myself.

All the information is there: each post has the date/time it was asked written right there in the posting. You could click on each post and record that date/time into an Excel and be done with it, but that would be awfully tedious. This is where screen scraping comes in. Screen scraping is the direct equivalent of having your computer control your web browser: click here, find this part of the HTML code, read it, and do something with it.Luckily, your computer doesn’t care if it has to spend all day doing the same thing over and over and over…

I chose to use Python, but you can do this in other languages, as well. Useful libraries to download are Requests and lxml. I use Requests for making the, you guessed it, “requests”, which are similar to typing a URL in the address bar of your browser. I use lxml for parsing and traversing the returned HTML code, which you can look at on any web page by pressing Ctrl+u (at least, in Chrome).

from lxml import html
import requests, time, csv

with open('C:/junk/geonet.csv', 'w') as csvfile: # create and/or open a CSV file
csvWriter = csv.writer(csvfile, delimiter=" ", quoting=csv.QUOTE_MINIMAL) # writer
dateList = []
baseUrl = 'https://geonet.esri.com/content' # store the URL prefix

for i in range(10): # loop through the first 10 'Content' pages
page = requests.get(baseUrl + '?start=' + str(i*20)) # navigate to page
tree = html.fromstring(page.text) # retrieve the HTML

threadBase = 'https://geonet.esri.com' # store the URL prefix
tree = html.fromstring(page.text) # retrieve the HTML
dates = tree.find_class('j-post-author') # retrieve the date
dateList.append(dates[0].text_content().strip()) # write to list
csvWriter.writerow(dates[0].text_content().strip()) # write to CSV
time.sleep(5) # wait 5s to give server a chance to handle someone else's requests

Anyhow, the graph at the start of this post shows pretty much what I expected: people on the East Coast get confused, then people on the West Coast get confused, then everyone goes home.

# Word tables to Excel: Python

Question: I’ve got a folder of 100+ Word documents, each containing a table or two. Can you format that into an Excel spreadsheet for me?

Using the Python for Windows Extension (specifically the win32com.client library), you can drive both Word and Excel with Python. Knowing that this functionality exists is half the battle.

# import libraries
import win32com.client as win32
import os

myDir = r'C:\Projects\ProjectX'

# open invisible Excel app
XL = win32.Dispatch('Excel.Application')
XL.Visible = 0
# navigate to first worksheet
XLsheet = XLbook.Worksheets(1)
# counter to keep track of Excel row
XLrow = 2

# loop through files in directory
for myFile in os.listdir(myDir):
filepath = os.path.join(myDir,myFile)
filename = os.path.splitext(myFile)[0]
ext = os.path.splitext(myFile)[1]

# check if *.docx {optional}
if ext == '.docx':
# open invisible Word app
word = win32.Dispatch('Word.Application')
word.Visible = 0
# open Word doc to read
word.Documents.Open(filepath)
doc = word.ActiveDocument

# access first table in Word doc. For subsequent tables, increase index.
table = doc.Tables(1)

# get (Word) and set (Excel) some data
XLsheet.Cells(XLrow,1).Value = table.Cell(Row=1, Column=1).Range.Text

# get (Word) and set (Excel) some more data
XLsheet.Cells(XLrow,2).Value = table.Cell(Row=2, Column=3).Range.Text

# move to next row
XLrow = XLrow + 1
# close the current Word doc
doc.Close()

# exit the Word app
word.Quit()
del word
# save and close Excel app
XLbook.Close(True)
XL.Quit()
del XL

# Arcpy: Polygons to Centroids (within Polygons, and with all Attributes)

Here’s a fairly simple python script that creates centroid points (constrained to fall within polygons) and attaches all the attributes (plus a link field, “ORIG_ID”) from the polygons to the centroids. Notably, it uses cursors to read raw geometry objects – no geoprocessing tools (except CreateFeatureclass). Also, while Advanced licensees may use the Feature to Point tool for this procedure, the method presented here is completely free, using no extensions or non-basic licensing – I don’t know of another free way to achieve this in ArcGIS. Wouldn’t it be easier to run a spatial join on the points to attach the attributes? Yes, but spatial join is slow. In my test of 1000 polygons, the cursor method completed in about 2 seconds, while adding a spatial join call extended the run time to more than 10 seconds. This could mean big savings on large datasets.

1. # import libraries
2. import arcpy, os
3. # set input/output parameters
4. polyFC = arcpy.GetParameterAsText(0)
5. outCentroids = arcpy.GetParameterAsText(1)
6. # set overwrite environment
7. arcpy.env.overwriteOutput = True
8. # if the output file does not exist, create it. Add “ORIG_ID” field.
9. if not arcpy.Exists(outCentroids):
10.     arcpy.CreateFeatureclass_management(os.path.dirname(outCentroids),
11.                                     os.path.basename(outCentroids),
12.                                     “POINT”,
13.                                     polyFC,
14.                                     “”,
15.                                     “”,
16.                                     polyFC)
18. # create an InsertCursor containing all the fields in ourCentroids, which are all the fields in polyFC plus “ORIG_ID”
19. iCursor = arcpy.da.InsertCursor(outCentroids, [‘*’])
20. # read all features in polyFC
21. with arcpy.da.SearchCursor(polyFC, [“SHAPE@”,‘*’,‘OID@’]) as sCursor:
22.     for row in sCursor:
23.          # create an array to hold a new, modified row
24.         rowArray = []
25.          # read all the fields except “SHAPE@”
26.         for fieldnum in range(1,len(row)):
27.             # if this is the 2nd field [i.e. SHAPE], replace it with the centroid coordinates
28.             if fieldnum == 2:
29.                 rowArray.append(row[0].centroid)
30.             else:
31.                 rowArray.append(row[fieldnum])
32.         # write the new row to the cursor
33.         iCursor.insertRow(rowArray)
34. del iCursor

Looping through the fields in this way (lines 29 – 36) feels cumbersome – if anyone knows a better way to do this, please let me know!

————————————————-

EDIT (January 19, 2016): Following some discussion on LinkedIn’s GIS and Geography group regarding this post, here is an example of why you must use the SHAPE@ token (and Polygon.centroid) rather than either the SHAPE@XY or SHAPE@TRUECENTROID tokens to guarantee that the point falls inside the given polygon:

… points = []
… with arcpy.da.SearchCursor(“MY_FEATURE_LAYER”,[‘SHAPE@’,’Shape@XY’,’SHAPE@TRUECENTROID’]) as cursor:
…   for row in cursor:
…     points.append(arcpy.PointGeometry(row[0].centroid)) # SHAPE@
…     points.append(arcpy.PointGeometry(arcpy.Point(row[1][0],row[1][1]))) # SHAPE@XY
…     points.append(arcpy.PointGeometry(arcpy.Point(row[2][0],row[2][1]))) # SHAPE@TRUECENTROID
… arcpy.CopyFeatures_management(points, r’in_memory\mypoints’)


text:
# Research

### Molecular Dynamics.

Much of our work has been on the foundations of numerical methods for simulating the dynamics of molecules. We usually assume the that the model can be described in terms of the motions of the nuclei of the system. It turns out that this is the natural starting point in many cases. So essentially we have a large system of atoms, they interact through forces that are described by potential energy functions, and the goal is to figure out how the molecules move and arrange themselves over time. For example, the images below show two conformational states of a certain molecule.

These would represent more or less likely states, and it is important that we observe simulated states with a likelihood that is similar to that with which they would be observed in reality; that is, we would wish to have an accurate approximation of the natural distribution of different states.

In the simplest setting one solves equations defined by Newton’s 2nd law (F=MA), but more commonly one has to include additional constraints on the system or make the model relevant for a laboratory environment (where temperature and pressure come into play) or include some additional contributions to the forces from a noisy environment or an auxiliary quantum computation. So things get more complicated, but the basic idea is straightforward: We start with a conformation and approximate the motion after a brief instant, then take another step, and another and so eventually construct a series of snapshots that describe the motion of the system. Ultimately we might be interested in how the molecule arranges itself after a (relatively) long time–the so-called “invariant distribution”.

As examples of our recent successes in this area, I would highlight the understanding of theoretical foundations and the development of numerical methods for Langevin dynamics. In Langevin dynamics, the Newtonian dynamics model is supplemented by dissipative and random perturbations which capture the interactions with suppressed degrees of freedom or compensate for other limitations of the conservative description. The system of interest is thus a set of stochastic differential equations. We have consider the formulation of the equations of motion, the properties of those equations (e.g. questions of ergodicity), and the design of accurate and efficient numerical discretisation methods. Some of our work in this area is described in the textbook I have written with Charles Matthews (Molecular Dynamics, Springer 2015).

More recent work has generalised the algorithms to constrained systems and systems with memory (generalised Langevin), or looked at the redesign of the stochastic-dynamical model to enhance exploration in the presence of extreme metastability due to energetic or entropic barriers. We also have an important stream of research on mesoscale particle models such as dissipative particle dynamics.

### Bayesian Models for Data Analysis

We have also been progressively exploring algorithms that can be used for Bayesian parameterisation of complex models. The model can be a neural network or a traditional mathematical model. Let us denote the model by $\Phi$ and suppose that it takes input $X$ to output $Y$, given parameters $\theta$:
$Y = \Phi(X,\theta).$
Now in a common setup, one assumes there is stochastic uncertainty in the relationship and so it is natural to consider a model in which the in puts and outputs are interpreted as random variables and the strict equality above is replaced by a statistical model, say
$\pi \left (x,y|\theta \right ) = Z^{-1}\exp \left ( \frac{\left [ y-\Phi(x,\theta)\right ]^2}{2\sigma^2} \right ). (*)$
where, for simplicity, we take $\sigma$ fixed. This is just one (elementary) choice for the statistical model, but it will serve for this exposition.

Now given a collection of samples (data) $D=\{(x_{\alpha},y_{\alpha})\}$, we may ask what is the best choice of the parameter vector $\theta$ to fit the given model to the given data. From the Bayesian perspective, the parameters themselves can be viewed as uncertain, with a distribution defined by Bayesian inversion:
$\pi\left (\theta| D \right) \propto \pi(D|\theta)\pi_0(\theta).$
The factors here are all probability densities. $\pi_0$ is an assumed prior’’ for the parameters which might, for example, restrict the parameters to be taken from a specified finite domain (or it may be Gaussian). The usual choice for the conditional distribution, $\pi(D|\theta)$, is based on the likelihood which is defined by the statistical model (*) under the assumption that all the data points are independent:$\pi(D|\theta) = \prod_{\alpha=1}^{|D|} \pi(x_{\alpha},y_{\alpha}|\theta).$

It is now possible to treat the parameterization problem in various ways. The most usual approach is to optimise the parameters by finding the global maximum of the probability density $\pi(\theta|D)$. A more nuanced approach is to embrace the uncertainty in the choice of $\theta$ in the Bayesian perspective, and explore, i.e. sample’’ the parameter distribution. The distribution is normally multimodal and we may attempt to find a number of the modes or to average the parameter values across the distribution. This is the approach we are currently taking in our data analytics work.

Among the specific problems we have looked at/are looking at in this domain, I would mention the following. First, there is a basic problem in the simple technique I mentioned above in the context of large data sets. Every time we compute a new value of the density (or its gradient, as is often needed), we must compute a product of likelihoods across the entire data set which will be very expensive if $|D|$ is large. One way to reduce the computational burden is to replace the full likelihood by an approximation obtained by using a subsampling of the data set. This might just be a small percentage of the full data set, so the properties of the data set, e.g. its concentration, play a critical role in determining when this approach will be successful in practice. Nonetheless it is widely used in the data community, where it goes under the name of “Stochastic Gradients”. A very similar problem arises in multiscale modelling, when the forces are computed by some device which perturbs the conservative structure. This gradient noise creates an additional source of noise in the parameterisation process. It turns out that this noise can be neutralised by use of a thermostat’’ method, something we studied extensively in the context of chemical/physical modelling. This remains very much an open problem and we are currently exploring it as part of other work we are doing.

### Enhanced Sampling

Another important issue is the treatment of multimodality of the probability distribution. In many cases there will be multiple reasonable parameterizations of the model defined by the specific data provided. In such situations it becomes crucial to explore or sample the probability distribution defined by for example the molecular equilibrium state or, in the case of a data analysis, Bayes’ formula. This task is computationally demanding since the standard MCMC schemes will often get stuck in one or the other localised region of the parameter space. In order to enhance exploration one may use innovative sampling strategies. In the case of statistical modelling, a very promising method for this purpose is to employ a collection of coupled ‘walkers’ to enhanced the exploration by providing a means of rescaling the dynamics to increase exploration, using our so-called ensemble quasinewton preconditioned MCMC scheme. Another interesting possibility is to use multiple temperatures to enhance the exploration, as in our infinite swap simulated tempering scheme developed with Eric Vanden-Eijnden and Jianfeng Lu. <p> A third approach is based on a diffusion map analysis of simulated data (the data being parameters, in this case).
In this article we proposed algorithms which use meta-study of the potential energy surface (and canonical distribution) to enhance exploration. The idea is to compute a local diffusion map (a sort unsupervised machine learning) which allows to characterize the slowest dynamical processes and use this knowledge to guide an accelerated process. Effectively this method learns the collective variables adaptively. This combination of local and global exploration is probably the best way forward in large scale molecular modelling. To illustrate what can be gained from this type of analysis, I show two snapshots taken from our paper.

The figures show the states of the molecular model of deca-alanine mapped onto a two-dimensional course graining using some physical variables (radius of gyration and RMSD); the coloring is based on the committor’’ value (obtained using the diffusion map) which colours states according to the likelihood of dynamical transition to one or the other of two most prevalent final states. The difference between the two diagrams shown here is the temperature at which the simulation is performed (the right diagram corresponds to a higher temperature – 485K, the left one to 300K). If we could perform this type of study adaptively for all the primary states of the molecular system we could map out the global dynamics. As you can imagine – this takes quite a bit of computer power. Molecular dynamics at this scale is a potential application for exascale computing!

### Molecular Dynamics Software

On the subject of computing, it is also worth mentioning our recent work on molecular dynamics software. In this domain there are some very large consortia which have produced the most important products, such as OpenMM, CHARMM, NAMD, Gromacs, Amber, Lammps. These packages generally involve combined contributions of dozens of authors from different disciplines. Because all classical molecular dynamics models involve compromises (quantum mechanics would be more accurate, but is computationally astronomically expensive due to the ‘curse of dimensionality’), a lot of work is put into making the force fields as accurate as possible. This means fitting empirical force field models to functions of the pair distances, coordinates of local triples, etc. It’s highly nontrivial. Other substantial work goes into making the codes run fast on the latest hardware, for example GPUs.

When we develop new algorithms, it can take a long time to get them implemented in these codes. There are often development queues and priorities that would delay implementation. We have gotten our methods into some popular code packages though, for example OpenMM implements our Langevin integrator. To speed up the transition from algorithm to software, we joined forces with Iain Bethune (originally at Edinburgh Parallel Computing Centre (EPCC); since moved to a software company ) to create a software interface called MIST (“Molecular Integrator Software Tools”) that allows us to very easily implement our algorithms. The software interface handles all the communication with various molecular simulation software packages such as NAMD, GROMACS, etc. In this way we can take advantage of the optimisations built into those codes while also having the ability to test our algorithms rapidly on “real-world” problems. MIST is freely available and documented here.

### Software for Machine Learning

As we learned more about machine learning and sought to implement our methods in code, we decided to develop a software package to facilitate sampling the posterior distribution of complicated models like neural networks. We also wanted to explore various alternative training methods such as the partitioned methods of this paper. For this reason we have begun to develop software packages that facilitate machine learning computations (e.g. optimization/sampling a Bayesian posterior). One such software package was developed in a project at the Alan Turing Institute, with Frederik Heber acting as the lead software developer. This package is called TATi (it stands for “Thermodynamic Analytics Toolkit”); it is written in TensorFlow and allows ensemble sampling of neural nets. An example of using TATi to train a neural network on the MNIST data set is shown below. Here we used a simplified technique to visualise the loss landscape of the neural net. For details see our JMLR paper which describes TATi.


text:
# [R] random uniform sample of points on an ellipsoid (e.g. WG

Ranjan Maitra maitra at iastate.edu
Sat Feb 24 21:54:33 CET 2007

```Hi,

Sorry for being a late entrant to this thread, but let me see if I understand the problem.

The poster wants to sample from an ellipsoid. Let us call this ellipsoid X'\Gamma X - d^2= 0.

There is no loss in assuming that the center is zero, otherwise the same can be done.

Let us consider the case when Gamma = I first.

Then, let X \sim N_p(0, I) (any radially symmetric distribution will
do here), then d*X/||X|| is uniform on the sphere of radius d.

Let X \sim N_p(0, \Sigma), where \Sigma = \Gamma^{-1} then X restricted to X'\Gamma X = d^2 gives the required uniform density on the ellipsoid.

How do we get this easily? I don't think rejection works or is even necessary.

Isn't d*X / ||\Gamma^{1/2}X|| enough? Here \Gamma^{1/2} is the square root matrix of \Gamma.

Note that any distribution of the kind f(X'\Gamma X) would work, but the multivariate Gaussian is a convenient tool, for which two-lines of R code should be enough.

Many thanks and best wishes,
Ranjan

On Sat, 24 Feb 2007 13:45:56 -0000 (GMT) (Ted Harding) <ted.harding at nessie.mcc.ac.uk> wrote:

> [Apologies if this is a repeated posting for you. Something seems
>  to have gone amiss with my previous attempts to post this reply,
>  as seen from my end]
>
> On 22-Feb-07 Roger Bivand wrote:
> > On 21 Feb 2007, Russell Senior wrote:
> >
> >>
> >> I am interested in making a random sample from a uniform distribution
> >> of points over the surface of the earth, using the WGS84 ellipsoid as
> >> a model for the earth.  I know how to do this for a sphere, but would
> >> like to do better.  I can supply random numbers, want latitude
> >> longitude pairs out.
> >>
> >> Can anyone point me at a solution?  Thanks very much.
> >>
> >
> > http://www.csit.fsu.edu/~burkardt/f_src/random_data/random_data.html
> >
> > looks promising, untried.
>
> Hmmm ... That page didn't seem to be directly useful, since
> on my understanding of the code (and comments) listed under
> "subroutine uniform_on_ellipsoid_map(dim_num, n, a, r, seed, x)"
> "UNIFORM_ON_ELLIPSOID_MAP maps uniform points onto an ellipsoid."
> in
>
> http://www.csit.fsu.edu/~burkardt/f_src/random_data/random_data.f90
>
> it takes points uniformly distributed on a sphere and then
> linearly transforms these onto an ellipsoid. This will not
> give unform density over the surface of the ellipsoid: indeed
> the example graph they show of points on an ellipse generated
> in this way clearly appear to be more dense at the "ends" of
> the ellipse, and less dense on its "sides". See:
>
> http://www.csit.fsu.edu/~burkardt/f_src/random_data/
> uniform_on_ellipsoid_map.png
> [all one line]
>
> Indeed, if I understand their method correctly, in the case
> of a horizontal ellipse it is equivalent (modulo rotating
> the result) to distributing the points uniformly over a circle,
> and then stretching the circle sideways. This will preserve
> the vertical distribution (so at the two ends of the major axis
> it has the same density as on the circle) but diluting the
> horizontal distribution (so that at the two ends of the minor
> axis the density isless than on the circle).
>
> someone would come up with a slick solution -- which hasn't
> happened yet.
>
> For the application you have in hand, uniform distribution
> over a sphere is a fairly close approximation to uniform
> distriobution over the ellipspoid -- but not quite.
>
> But a rejection method, applied to points uniform on the sphere,
> can give you points uniform on the ellipsoid and, because of
> the close approximation of the sphere to the ellipsoid, you
> would not be rejecting many points.
>
> The outline strategy I had in mind (I haven't worked out details)
> is based on the following.
>
> Consider a point X0 on the sphere, at radial distance r0 from
> the centre of the sphere (same as the centre of the ellipsoid).
> Let the radius through that point meet the ellipsoid at a point
> X1, at radial distance R1.
>
> Let dS0 be an element of area at X0 on the sphere, which projects
> radially onto an element of area dS1 on the ellipsoid. You want
> all elements dS1 of equal size to be equally likely to receive
> a random point.
>
> Let the angle between the tangent plane to the ellipsoid at X1,
> and the tangent plane to the sphere at X0, be phi.
>
> The the ratio of areas dS1/dS0 is R(X0), say, where
>
>   R(X0) = dS1/dS0 = r1^2/(r0^2 * cos(phi))
>
> and the smaller this ratio, the less likely you want a point
> u.d. on the sphere to give rise to a point on the ellipsoid.
>
> Now define an acceptance probability P(X0) by
>
>   P(X0) = R(X0)/sup[R(X)]
>
> taking the supremum over X on the sphere. Then sample points X0
> unformly on the sphere, accepting each one with probability
> P(X0), and continue sampling until you have the number of
> points that you need.
>
> Maybe someone has a better idea ... (or code for the above!)
>
> Ted.
>
>
> --------------------------------------------------------------------
> E-Mail: (Ted Harding) <ted.harding at nessie.mcc.ac.uk>
> Fax-to-email: +44 (0)870 094 0861
> Date: 24-Feb-07                                       Time: 13:45:50
> ------------------------------ XFMail ------------------------------
>
> ______________________________________________
> R-help at stat.math.ethz.ch mailing list
> https://stat.ethz.ch/mailman/listinfo/r-help


text:
/podcasts/wbu29.mp3

In this episode of Wrong, But Useful, @reflectivemaths and @icecolbeveridge…:

• Argue about the inferiority of statistics
• Give a number of the podcast: $e^{\frac{\pi}{2}} = i^i \approx 0.20788…$
• Review @standupmaths’s excellent Things to Make and Do in the Fourth Dimension
• Investigate equable shapes in several dimensions, with reference to @tombutton’s MathsJam talk about the radius of a cube
• Point to @samuel_hansen’s (and his collaborators’) work at acmescience.com; the new series of Relatively Prime is due out in January 2016. Colin likes The Other Half.
• Threaten to hold the podcast to ransom
• Plug Big MathsJam! We will both be there all weekend (shout out to @colinthemathmo for organising it!).
• Plug Colin’s talk to Bournemouth Skeptics In The Pub on November 11th
• Take off our hats to @christianp’s clerihew: Terry Tao / The cat’s miaow / Solves a conjecture / Before every lecture
• Celebrate said Terry Tao’s solution to the Erdos Discrepancy Problem and boo Nature’s headline for it
• Decry the lack of good arguments for learning to multiply or subtract
• Thank some people for suggesting puzzles to Dave
• Hand out gold stars to @chrishazell72 and @FennekLyra for work on old puzzles
• Set a puzzle due to @npickup: There is one 3-partition of the number 3: (1,1,1). There are 3 of the number 6: (1,1,4), (1,2,3) and (2,2,2). a) Find a formula for the number of 3-partitions of any number n; b) prove it.

* Edited 2015-10-22 to fix missing audio. Thanks, Eva!


text:
## Friday, January 06, 2006

### Ghost D-branes

Tadashi and Takuya have an interesting proposal to interpret the "fermionic" Chan-Paton factors - those that extend a gauge group from U(N) to a supergroup U(N/M) - as creating "ghost D-branes". All their states violate the spin-statistics relation. Note that the cancellation between these two D-branes may be viewed as perfect in topological string theory but Tadashi and Takuya talk about the full string theory.

When a D-brane coincides with a ghost D-brane, the configuration is equivalent to the closed string vacuum. However, when they are separated, they get a new configuration. Using these rules, I am a bit surprised that you can separate them. If the coincident D-brane and ghost D-brane contain no physical open string excitations, does not it mean that we should not be allowed to give one of them a vev?

They also discuss the heterotic dual. In this case, they extend the fermionic formulation by adding new chiral bosons to the 32 fermions.

#### 1 comment:

1. Ghost D-brane is an object that cancels the effects of an ordinary D-brane. A similar idea can clearly be applied to define ghost M2 and M5-branes in M-theory.

Ghost D-branes replace ordinary Chan-Paton matrices with supermatrices. The supergroups U(N|M) and OSp(N|M) arise as gauge symmetries in the supersymmetric world-volume theory of D-branes and ghost D-branes. This leads to a new type I string theory with gauge group OSp(32 + 2n|2n), type IIB string with gauge group U(n|n) (generalization of the type I/heterotic S-duality by including n ghost D9-branes on the type I side and by considering the heterotic string whose gauge group is OSp(32+2n|2n) and of the type IIB S-duality applied to D9- and ghost D9-branes with gauge group U(n|n)) and supergroup extension of the E8 × E8 heterotic string is E(8+n/2,n/2) × E(8+n/2,n/2) (which has infinitely many massless gauge fields) with any positive integer n. (This fact seems to be consistent with the known mathematical fact: there is no finite dimensional Lie superalgebra which is a counterpart for the En Lie algebra.)

A system with a pair of D-brane and ghost D-brane located at the same location is physically equivalent to the closed string vacuum. When they are separated, the system becomes a new brane configuration.

I suppose that matrix-valued tachyon on the worldline of a collection of n D0-brane and ghost D0-brane represents U-dual root lattice.