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.

# Localized microwave-heating (LMH) of basalt – Lava, dusty-plasma, and ball-lightning ejection by a “miniature volcano”

## Abstract

This paper presents various phenomena obtained by localized microwave-heating (LMH) of basalt, including effects of inner core melting, lava eruption and flow (from the molten core outside), plasma ejection from basalt (in forms of fire-column and ball-lightning), and effusion of dust (deposited as powder by the plasma). The experiments are conducted by irradiating a basalt stone (~30-cm3 volume, either naturally shaped or cut to a cubic brick) in a microwave cavity, fed by an adaptively-matched magnetron (~1 kW at 2.45 GHz). Effects of LMH and thermal-runaway instability in basalt are observed and compared to theory. Various in- and ex-situ diagnostics are used in order to characterize the dusty-plasma observed and its nanoparticle products. The resemblance of the experimental phenomena obtained in small laboratory scale to gigantic volcanic phenomena in nature is noticed, and its potential relevance to further volcanic studies is discussed. In particular, we show that LMH could be instrumental for laboratory demonstrations and simulations of miniature-volcano effects, such as lava flows, formation of volcanic glass (obsidian), eruption of dusty-plasma and volcanic ash, and ejection of ball lightning. These findings might be significant as well for various applications, such as drilling and mining, microwave-induced breakdown spectroscopy (MIBS), mineral extraction, and powder production directly from basalts.

## Introduction

Microwave heating is unique, compared to other heating techniques, because it may initially generate the thermal energy inside the irradiated object (due to the penetration of the microwave radiation inside, and its absorption and conversion to heat therein)1. Furthermore, localized microwave-heating (LMH) and the consequent formation of hotspots by thermal-runaway instability may cause local melting in various materials (e.g. silicates2), and even plasma ejection outside.

The thermal-runaway instability3, undesired in most microwave applications, may intensify the heat localization effect4,5. It occurs in materials with temperature-dependent properties, which cause the hotter region (typically the core) to become more susceptible to further microwave heating than the outer, cooler parts. This positive-feedback instability localizes the microwave heating and concentrates the thermal energy, and hence eventually leads to creating of a molten hotspot.

Microwave-heating effects in basalts, such as melting, cracking and crushing6,7,8,9,10,11,12, have been studied in various contexts mainly related to mining and construction applications. The thermal-runaway effect in basalt5,9 leads to a hotspot formation and melt inside the stone6,9,10, as illustrated in Fig. 1A. Further irradiation of the basalt stone by a regulated microwave power can stably maintain the molten core inside, in a thermal equilibrium. However, a slight increase in the power may elevate the temperature and increase the pressure inside the stone. Cracks may appear then on the rock surface; the inner melt may erupt outwards and flow as a lava stream over the surface (Fig. 1B), like a “miniature volcano”. Here we have also found that a further irradiation of the basalt heats the hotspot up to a point in which plasma is ejected from its surface, as shown in Fig. 1C13.

Plasmas are usually generated from basalts by various other means, not involving microwaves. The experimental studies reported in the literature include, for instance, plasma generated from basalt by CO2 and Nd:YAG lasers (for laser-induced breakdown spectroscopy, LIBS)14; inductively-coupled plasmas of basalt in various forms (rock, fiber and glass) analyzed by atomic emission spectroscopy15; and a plasma spray of basalt in powder form implemented in a basalt coating technique16.

As observed in the present work13, starting from an LMH hotspot in basalt, the plasma is first ejected and evolves as a fire-column, which is stably maintained by the microwave irradiation. Then, it may also emit a fireball, buoyant in the air atmosphere within the cavity, as shown in Fig. 1D. This basalt-originated fireball is either adjacent to the initiating fire-column or detached from it, tending to hover towards the microwave source (as in refs2,17,18,19).

This paper presents observations of volcano-like phenomena in basalt-LMH experiments, also in comparison to theory; characterizes the dusty-plasma ejected and its nano-powder products; and discusses the LMH potential as a means for experimental laboratory-scale simulations of volcanic effects, and for other material-processing applications.

## Experimental Setup

The LMH experiments presented in this paper have been conducted in the experimental setup illustrated in Fig. 2A,B [Method 1]. The microwave cavity (Fig. 2A) is made of a 10 × 5 cm2 cross-section waveguide, shorted at the end by a microwave reflector. This cage-like structure of the cavity, with wide openings (~22 mm) between the vanes, enables direct access and broad view from various directions into the interaction region (with immediate lines of sight for the various diagnostic means). The cavity is fed by a 2.45-GHz magnetron (regulated up to 1-kW input power).

By applying LMH, the inner core of the basalt is first melted6,8,9,10. Further irradiation leads to the eruption of the molten basalt, from the core to the surface (similarly to lava eruption and flow in volcanoes). The molten basalt cools down and solidifies to a black glass (obsidian). A further irradiation causes the basalt to emit a plume of dusty plasma, which evolves to a confined plasma column, and further to a plasmoid similar to a natural ball-lightning. These fire-column and fireball-like plasmoids are characterized here by various in- and ex-situ means.

The optional use of a movable electrode (as in the microwave-drill device20 and in previous plasma studies2,21) may expedite the eruption process by intensifying the local electric field. However, similar effects may occur in basalt with no electrode as demonstrated here as well (though in a less controllable fashion). The electrode enables reaching the melting temperature more locally and rapidly within a hotspot underneath the surface, which provides a path for lava eruption from the molten core. Here we also examined the use of an electrode array in order to induce multiple hotspots.

## Results

### Core melting and lava eruption

Effects of core melting, followed by lava eruption and flow (and further solidification to obsidian) have been observed in LMH of natural basalt stones in these experiments, as shown in Fig. 3A (with no electrode). As an alternative to the naturally-shaped stones, cubic bricks (of 3-cm side length) cut from natural basalts have also been experimented, since their well-defined geometry enables better comparison with numerical simulations. The LMH experiments with basalt cubes (using electrodes) resulted in similar effects of core melting, and lava eruption and flows, as shown in Fig. 3B. The thermal image in Fig. 3B(e) indicates that the molten lava temperature exceeded ~1,200 K. The lava erupts from the core outwards, and then flows downwards by gravity with a front-flow velocity of ~1 cm/s, while its color varies from luminous white to orange and red [Supplementary Video S1a and S1b]. It eventually cools down and vitrifies to black volcanic glass, namely obsidian. Various other volcano-like phenomena are observed (as also shown in Fig. 3A,B), such as formations of bubbles and domes, fissures and craters, vents, blasts, bursts of lava, and lava tunneling. The latter is observed for instance when two hotspots are simultaneously created by electrodes in two opposite faces of the basalt brick. An inner lava tunneling effect is evolved then, in the core between the two hotspots, as observed via the porous outer surface of the basalt brick [Supplementary Video S2].

The theoretical analysis of the basalt’s LMH interaction ([Method 2] incorporates the thermal-runaway instability and the interactive temperature-dependence of the basalt’s properties9. The numerical simulations presented in Fig. 4A–C show the inner hotspot formation and core melting prior to the lava eruption, in agreement with the experimental results (with no electrode). The additional effect of the sharp geometry on the LMH evolution is demonstrated in Fig. 4C(a–c), by simulations of various shapes such as a sharp stone (a) and single- and multiple-electrode schemes (b, c).

### Dusty-plasma ejection in forms of fire-columns and fireballs

In this study we have found that a further microwave irradiation of the molten basalt causes a plasma ejection from it. In this process, the microwave localization effect continues to evolve and to heat up the melt, and hence plasma is ejected from it as shown in Fig. 5A(a–d) and Supplementary Video S3. Starting from a molten hotspot (a), the plasma is first emitted (b), and then forms a stable fire-column (c). In some cases, another plasmoid is also evolved in a form of a fireball, either alongside the fire-column (d) or detached from it as shown in Fig. 5B(d) and Supplementary Video S4. The detached fireball is typically less stable than the fireball adjacent to a fire-column, and it tends to move towards the magnetron. The fireball disappears within a few seconds, similarly to natural ball-lightning22. Other modes of plasma ejection from basalts observed in this study are a fire-column eruption from a dome made of a thin layer of obsidian (blown up by the lava eruption), and a simultaneous ejection of two plasma columns from two different hotspots, as shown in Fig. 5B(b,c), respectively (both effects are presented in Supplementary Video S5).

### LMH and plasma characterization

Various diagnostic techniques were applied in order to characterize the LMH of basalt, as well as the plasma ejected from it, and its products. These diagnostic means include microwave-scattering analyses, optical spectroscopy, and scanning electron microscopy (SEM). The analyses of the microwaves scattered from the plasmoid results in an estimate of its microwave impedance, which provides a measure for its dielectric and plasma properties. The reflections of the 2.45-GHz microwave input are detected during the various stages of the LMH process. The complex reflection coefficient Γ (Fig. 5C(a)), also presented in a Smith-chart form in Fig. 5C(b), shows that the microwave reflection tends to decrease (from |Γ| ~ 1 to ~0.4) after the plasma ejection, and to further decrease (to |Γ| ~ 0) when a fireball emerges (Supplementary Video S6). At the stable fire-column stage, the reflection coefficient is bouncing around ~0.4, while being attracted by the Smith-chart origin. The corresponding power reflection is smaller than 20% at this stage, hence the plasmoid interacts with its microwave source as an adaptively matched load. At the fireball stage, this self-tuning mechanism tends to maximize the microwave power absorbed by the fireball, by optimizing its intensity, position and size. The estimate of the plasma impedance and dielectric properties is based on a comparison of the reflection measurements with simulation results of a dummy load, with equivalent shape, position and size18,19,23.

The optical spectrum of the light emitted by the basalt plasma-column (Fig. 6A,B) reveals its atomic lines, which are identified using24 as of Fe, P, C, Si, Al, Mg, Ti, and Ca. All these elements are known as ingredients of basalt rocks. The Boltzmann plot technique, implemented on the Fe and Ti lines, results in excitation temperature estimates of Texc ~ 0.3 and ~0.6 eV, respectively (Fig. 6C). The spectral emission of OH radicals is identified by fitting to LifBase data25. The rotational temperature is also roughly estimated in the same range of Trot ~ 0.3–0.6 eV (Fig. 6D).

A Langmuir probe is inserted into the plasma in order to measure its I-V characteristics (Fig. 7A(a)). Valid results are only observed when the melt flows to the grounded chamber floor, and closes the electric circuits to enable a current loop (otherwise, smaller currents are measured due to the high impedance of the powder layer deposited by the plasma on the ceiling) [Supplementary Video S7]. The hysteresis observed in the I-V curve (Fig. 7A(b)) is attributed to the capacitive effect created by the powder deposited on the electrode. A rough estimate of the electron temperature by the curves’ slopes results in Te ~ 0.3 eV and ~0.6 eV, for the voltage rise and fall, respectively. This range coincides with the results estimated by optical spectroscopy.

Microwave scattering measurements are also performed at other frequency ranges, by irradiating the plasmoid by another probing signal at low power. The latter is coupled via additional input and output ports (marked 1 and 2, respectively, in the inset of Fig. 7B(a)). Scattering results for the microwave transmission coefficients (measured and simulated) at a lower frequency band (0.8–1.5 GHz) are shown in Fig. 7B(a), with and without the plasma. The results show that near the anti-node frequency of the coupling between Ports 1 and 2 (~1.25 GHz, corresponding to L ~ λ/2, where L is the coupler arm length), the transmission coefficient S21 is increased by >20 dB in the presence of plasma. Indeed, below the plasma frequency, the fire-column behaves like a conductor, which shorts the coupler arm length by half (~L/2 ~ λ/4) and hence significantly increases the microwave transmission between Ports 1 and 2. A numerical simulation of this coupler, with an equivalent column-shaped load inside, enables us to estimate the plasma dielectric permittivity. As shown in Fig. 7B(b,c), the transmission increase at the anti-node frequency follows the abrupt temperature rise, in which the plasma switches from the decoupled to the coupled state of Ports 1 and 2.

### Dust effusion and ex-situ analyses

A significant amount of dust is produced by the basalt’s plasma, deposited as a white powder on the collector shown in Fig. 2A. The surface morphologies of the particles created by the plasma are characterized by a scanning electron microscope (SEM) [Method 1]. The accumulated particles are observed in various shapes, mostly aggregates in few micro-meter sizes. Figure 8A(a–f) show aggregates of such particles on the collector surface as observed by SEM. Analyses of energy dispersive spectroscopy (EDS) reveal that these aggregates are composed of the elements listed in Table 1, also typical to the original basalt content. In addition, the basalt’s plasma generates larger spherical particles, in sizes of tens of microns and larger, as seen on the collector (Fig. 8A,B(a)). Holes of similar sizes are also noticed on the collector surface (this finding may either hint particle bombardment or a plasma localization effect). Island-like regions are observed upon the white powder deposition on the collector, as seen in Fig. 8A(c). EDS shows that they mostly consist of aluminum, as the collector itself, hence they may indicate an etching effect.

EDS analyses were also conducted on the basalt stone in its original form and its molten state (Fig. 8B(b)), in order to compare the compositions of the vitrified product (obsidian) and the natural stone. Table 1 shows the relative presence of the constitutive elements in the various phases of this process, namely the natural stone, the melt, and the deposited powder. The weight ratios differ between the various phases. However, it seems that the deposited powder consists of elements provided solely by the basalt (e.g. Si and Fe). These ingredients of the powder were most likely extracted from the basalt, and then evolved and transported by the plasma to the collector. Consequently, these elements were also detected within the plasma by optical spectrometry.

X-ray diffraction (XRD) pattern of massive samples of the molten basalt show low intensity of diffraction peaks, suggesting that the great part of the sample consists of glass. From the position of the peaks, it is possible to determine that the two major crystalline phases are an oxide of aluminum, magnesium and iron, and a silicate of magnesium and iron. The diffraction pattern of the white deposition (Fig. 8B(a)) enables to determine the presence of crystalline phases in the powder, including three silicate phases (Enstatite (Mg,Fe)2Si2O6, Augite (Ca,Mg,Fe)2Si2O6 and Mullite 3Al2O3·2SiO2) and two oxides (Periclase MgO and Wustite Fe0.9O). Peak observed are related to a phase with phosphor, possibly in amorphous phase (as confirmed by the modulated background).

A simplified model of microwave interaction with dusty plasma26 [Method 3] yields an estimate for the electron density in the basalt-originated plasma as ne ~ 1017–1018 m−3, assuming an electron temperature of Te ~ 0.3–0.6 eV (estimated by the various measurements above), and dust number density of nd ~ 1016 m−3, as measured by small-angle X-ray scattering (SAXS) of similar elemental dusty plasmas18,23,27,28. Therefore, this plasma is characterized as a weakly-ionized, low-density dusty plasma, which contains components of the original basalt stone (e.g. silicon and iron oxides).

## Discussion

Modeling capabilities of volcanic phenomena are essential for both field- and laboratory-based studies. The contemporary research of volcanic processes incorporates a variety of theoretical and experimental models in an interdisciplinary approach, including thermodynamics, solid mechanics, fluid dynamics, and material sciences29. Theoretical models, e.g. of pyroclastic flows30, elastoplastic ground deformation31 and volcanic ash transport forecasting32, improve the understanding and the predictability of these processes. Laboratory models of volcanoes and lava phenomena employ analogues materials in order to experimentally study for instance lava domes33, submarine lava dynamics34 and mantle flows35.

In this interdisciplinary approach, the LMH-basalt study presented here may open new possibilities for experimental modeling in volcanology and geosciences. The controllable basalt core-melting and the lava-flow effects observed here in a miniature laboratory scale, and their resemblance to giant volcanic phenomena in nature, can be utilized for experimental small-scale simulations and demonstrations of various volcanic phenomena.

The natural ball-lightning phenomena, occasionally associated with volcanic eruptions, can also be experimentally modeled by the LMH-generated fire-column and fireball plasmas. A large number of fireball sightings has been recorded in the last centuries22, many occurring near volcanos or at times of heavy air pollution caused by volcanic eruptions. Spectrograph measurements of natural ball-lightning reveals the presence of Si, Fe, Ca and Al36 as in soil, in line with the theory suggesting that ball lightning is generated by lightning striking the soil37. These elements appear as well in the spectroscopy measurements of the basalt-generated plasma (along with other basalt components), in resemblance to the natural ball-lightning studies22,36,37. This finding adds another aspect to the visual similarity of microwave-generated fireballs to natural ball-lightning phenomena2,38).

The phenomena of lightning within eruptions of volcanic ash plumes in nature has also been recorded and studied39. This high-energy lightning chemically modifies and melts the volcanic ash40, generating spherical shapes similar to those observed in the powder accumulated in this study. For instance, the composition of the volcanic ash sampled in Mount St. Helens eruption on May 18, 198041 includes SiO2 (65%), Al2O3 (18%), FetO3 (5%), and smaller amounts of MgO, CaO, Na2O, K2O, TiO2 and P2O. For comparison, the powder accumulated from the basalt-generated plasma consists of similar elements, as listed in Table 1. The relatively high concentration of phosphorous (and of Na and K as well) detected in the powder can be attributed to its relatively low melting temperature. This environmentally significant effect also features volcanic ash42.

Major challenges have remained for further research, including in-depth investigations and modeling of (a) the LMH interaction with basalt and phase transitions, (b) plasma ejection mechanisms and effects of thermionic emission, (c) microwave interactions with dusty plasma and particle agglomeration therein, (e) plasma-surface interactions, and plasma-chemical reactions occurring in this process.

In a more technology-oriented approach, this study of LMH in basalts could be relevant to various potential applications, including for instance (a) microwave-assisted drilling in basalts20, (b) cracking and crushing of basalts for mining and construction operations43, (c) basalt vitrification, glass production and coating, (d) joining of basalt bricks, (e) direct extraction of minerals in a powder forms by means of dusty-plasma production from basalts, and (f) analyses and identification of rock contents in the field by portable microwave-induced breakdown spectroscopy (MIBS) systems44 (as a variation of the laser-based LIBS technique45).

## Methods

### Method 1. Experimental

The processes of basalt melting and plasmoid ejection therefrom are initiated in this study by directing localized microwave power into the basalt specimen. This localization effect is implemented by the microwave-drill mechanism20, which creates the hotspot from which plasma is ejected in a form of a fire-column or a fireball, into the cavity.

The experimental setup shown in Fig. 2A,B includes a microwave cavity fed by a 2.45-GHz, 1-kW magnetron. The cavity is made of a 10 × 5 cm2 cross-section waveguide, shorted at the end by a mirror made of a periodic array of metallic vanes, under cutoff. Similar arrays are also installed as the sidewalls of the cavity. This cage structure prevents microwaves leaks, and yet enables a broad view into the waveguide with no disturbance to the various in-situ diagnostic means (such as the thermal camera and optical spectrometer which require direct lines of sight).

In this experiment we use basalt stones (from the Golan heights) either in their original natural shapes or cut to (3-cm)3 cubic bricks. This load is placed inside the cavity in an optimized position whereas the (optional) movable electrode directs the microwave energy locally into the substrate. Various level of focusing are optionally available in this setup, including (i) a single-electrode focusing as in Fig. 2A, (ii) no-electrode focusing, and (iii) a multi-electrode array focusing. Each electrode in this array expedites the intentional excitation of the hotspot in its vicinity, when brought into contact with the basalt-stone surface, and hence enables the stimulation of the LMH and fire-column (and consequently of a fireball) in a more controlled fashion. Typically, electrodes were applied to cubical bricks in these experiments, whereas no electrodes were used with natural stones.

The magnetron’s switched-mode power supply (MagDrive-1000, Dipolar Ltd., Sweden) provides an adjustable input microwave power up to 1 kW. The microwave power is delivered to the cavity via an isolator and an impedance auto-tuner (Homer, S-Team Ltd., Bratislava, Slovak republic), as depicted in Fig. 2B. The incident and reflected waves are recorded by the impedance-analyser mode of the auto-tuner, which also enables adaptive impedance matching, and optimal transmission of the microwave power into the cavity. The adaptive tuning is applied to intensify the hotspot heating in order to eject the plasma (whereas the synchronized de-embedded reflection coefficient measurements are presented and stored for offline analysis). In order to get more accurate measurements once the plasma is ejected, we turn off the adaptive tuning in order to measure the actual reflection coefficient instead of the de-embedded signal. This is possible due to the self-tuning effect of the plasmoid, as an alternative to the external impedance matching.

The scattered microwave is analysed in order to find the plasmoid impedance, and hence to estimate its dielectric and plasma properties. First, the reflections of the 2.45-GHz input power are measured during the various stages presented in Fig. 1A–D. The reflection measurements (as in Fig. 5C) enable us to find the impedance and dielectric properties of the fire-column by simulating an equivalent load, with the same shape, position and size.

The diagnostic means also include video recording, thermal imaging, optical emission spectroscopy (OES), and plasma I-V measurements, all conducted via the vane openings along the waveguide. A LabVIEW code controls the system, synchronizes the time between all the diagnostic means and accumulates the experimental data.

The video camera recording (at 200 fps) is used to monitor, record times and synchronize between effects such as inner hotspot formation, cracks, breakage, lava eruption and plasma ejection to other diagnostic means used in the experiment. Once ejected, the plasma column’s size, shape and position can be detected by the video recording. Also, evolution of fireballs, and their shape and movement are monitored by the video camera.

The FLIR-SC300 thermal camera monitors the spatial temperature evolution of the sample, the hotspot formation, and its temperature and size. The thermal imaging data is later compared to simulation results in order to validate the physical model.

The optical spectra emitted from the lava and plasma eruptions (Fig. 6A) are captured by an optical spectrometer (Avaspec-3648) with 0.3-nm resolution in the range 200–1000 nm. The results are analyzed for element identification and blackbody radiation, as well as radical emission curve fitting and Boltzmann plot (in order to find the rotational and excitation temperatures, respectively).

The excitation temperature is estimated, as in refs18,23,27, by using a Boltzmann plot of the line intensity, assuming a partial local thermal-equilibrium (pLTE) state of the plasma. The intensity Iki of the transition from the upper k to the lower i energy level is given in the Boltzmann equation,

$$\mathrm{ln}\,({I}_{ki}{\lambda }_{ki}/{g}_{k}{A}_{ki})=-\,(1/{k}_{B}{T}_{exc}){E}_{k}+{\rm{const}}.,$$
(M1)

where λki and Aki are the transition wavelength and probability, respectively, kB is the Boltzmann constant, and Ek is the upper energy state with a gk degeneracy (as in ref.23, the relatively large scatter of the measurement results from the fit line in Fig. 6C is due to the 0.3-nm spectral resolution and the consequent overlap of the detected atomic lines).

A Langmuir-like probe is inserted into the plasma in order to measure its I-V characteristics. As shown in Fig. 7A(a), the 1.6-mm diameter, 50-mm long probe is fed by a 50-Hz, ~100-V alternating voltage. Valid results are only observed when the melt exists as illustrated in Fig. 7A(a), and closes the electric circuits to enable the current flow (otherwise much smaller currents are erroneously measured). A presumable reason is the isolating powder oxide accumulated on the metal surfaces, which adds a significant resistant to the plasma current loop. The hysteresis observed in the I-V curve may also indicate a contamination of the electrode, which leads to a capacitive effect.

The powder products are ex-situ examined, as in refs18,23,27, by a FEI Quanta 200FEG environmental SEM. The chemical element composition is analyzed using energy dispersive spectroscopy (EDS) with a Si(Li) liquid-nitrogen cooled Oxford INCA X-ray detector.

### Method 2: LMH model and simulation

The LMH process (prior to the plasma ejection) is modelled by a set of coupled EM-thermal equations4,5 for a time-varying (temperature-dependent) inhomogeneous lossy medium in a bounded region (a basalt stone in a cavity, in this case). The effective dielectric permittivity of the medium in the microwave regime is represented as a complex variable by

$${\varepsilon }_{eff}(T)={\varepsilon }_{0}[{\varepsilon }_{r}^{{\rm{^{\prime} }}}(T)-j({\varepsilon }_{r}^{{\rm{^{\prime} }}{\rm{^{\prime} }}}(T)+{\sigma (T)/\omega \varepsilon }_{0})],$$
(M2)

where ε0 is the permittivity of vacuum, εr and εr are the real and imaginary components, respectively, of the relative temperature-dependent permittivity of the medium (where T(x, y, z; t) is the temperature, spatially and temporally evolved during the process), and σ(T) is the temperature-dependent electric conductivity of the medium.

The EM-wave equation is given in the frequency domain by

$$\nabla \times (\nabla \times \tilde{{\bf{E}}})-{\varepsilon }_{eff}(T){k}_{0}^{2}\tilde{{\bf{E}}}=0,$$
(M3)

where $$\tilde{{\bf{E}}}$$ is the electric-field vector of the EM wave, ω is the angular frequency of the EM-wave, and $${k}_{0}=\sqrt{{\varepsilon }_{0}{\mu }_{0}}\omega$$ is its wavenumber.

The heat equation is given in the time domain by

$$\rho {c}_{p}\frac{\partial T}{\partial t}-\nabla \cdot ({k}_{th}\nabla T)=Q,$$
(M4)

where ρ is the (local) medium density, cp and kth are its heat capacity and thermal conductivity, respectively, and Q(x, y, z; t) is the absorbed power density in the medium, as evolved during the LMH process. The latter is given by

$$Q=\frac{1}{2}\omega {\varepsilon }_{0}{\varepsilon }_{r}^{{\rm{^{\prime} }}{\rm{^{\prime} }}}{|\mathop{{\bf{E}}}\limits^{ \sim }|}^{2}+\frac{1}{2}\sigma {|\mathop{{\bf{E}}}\limits^{ \sim }|}^{2},$$
(M5)

for the dielectric and ohmic losses, respectively, and it couples the EM-wave and heat equations (Eqs M2 and M3, respectively, also coupled by the temperature dependence of the medium’s EM parameters). The single-frequency operation and the relatively slow-time variation of the temperature (in a > 1 ms scale) with respect to the EM-wave variation (in a ~1 ns time scale) enable us to apply a two-time scale approximation, hence to solve the EM-wave equation in the frequency domain and the heat equation in the time domain. The two solvers are iteratively applied, each with its relevant boundary conditions. The temperature-dependent parameters of basalt, employed in this analysis, are given with the relevant references in Table 2.

Referring to the material properties essential for LMH, our previous microwave-drill analyses (e.g.4) show that the intentional-LMH effect is feasible in materials such as silicon, germanium, glass, and various ceramics (e.g. mullite, cordierite, zirconia, alumina of 86% purity, and clay) but not for instance in sapphire or pure alumina (due to their small dielectric losses). Also, the expansion coefficient and mass density may affect the material’s brittleness and cracking (which seem to appear in our basalt experiments after the inner melting). In glass, the optical transparency might be useful to visually observe the molten core inside, but it is not necessary for the hotspot evolution (the LMH effect may occur as well in opaque dielectric materials).

### Method 3. Dusty plasma interaction with microwaves

Following ref.26, the effective dielectric permittivity of the dusty plasma, εr, consists of the plasma complex permittivity, $${\varepsilon }_{p}^{^{\prime} }$$ − $$j{\varepsilon }_{p}^{^{\prime\prime} }$$, and of the dust conductivity σed26, as follows

$${\varepsilon }_{r}={\varepsilon }_{p}^{{\rm{^{\prime} }}}-j{\varepsilon }_{p}^{{\rm{^{\prime} }}{\rm{^{\prime} }}}-j{\sigma }_{ed}/{\varepsilon }_{0}\omega ,$$
(M6a)

where ε0 is the vacuum permittivity and ω is the angular frequency. The dielectric permittivity of the plasma is given by its approximated real and imaginary components,

$${\varepsilon }_{p}^{{\rm{^{\prime} }}}=1-\frac{{\omega }_{p}^{2}}{{\omega }^{2}+{\upsilon }^{2}},$$
(M6b)
$${\varepsilon }_{p}^{{\rm{^{\prime} }}{\rm{^{\prime} }}}=\frac{{\omega }_{p}^{2}\upsilon }{\omega ({\omega }^{2}+{\upsilon }^{2})},$$
(M6c)

respectively, where $${\omega }_{p}=\sqrt{{e}^{2}{n}_{e}/{m}_{e}{\varepsilon }_{0}}$$ and υ are the plasma and the collision frequencies, respectively, and e, ne and me are the electron charge, density and mass, respectively. The dusty plasma conductivity is given in similar conditions by ref.26, as

$${\sigma }_{ed}\cong {\eta }_{ed}\frac{\omega }{\hat{k}}[\frac{{\omega }^{2}-\upsilon {\upsilon }_{ch}}{({\omega }^{2}+{\upsilon }_{ch}^{2})({\omega }^{2}+{\upsilon }^{2})}+j\omega \frac{\upsilon +{\upsilon }_{ch}}{({\omega }^{2}+{\upsilon }_{ch}^{2})({\omega }^{2}+{\upsilon }^{2})}],$$
(M7)

where ηed is the charging factor, presented in terms of the dust collision length factor $${l}_{d}={({n}_{d}\pi {r}_{d}^{2})}^{-1}$$, as $${\eta }_{ed}={\omega }_{p}^{2}{\varepsilon }_{0}/{l}_{d}$$, with the dust grain density and the average particle radius denoted by nd and rd, respectively. In this analysis, $$\hat{k}$$ represents the effective spatial angular frequency. The electron collision frequency is approximated by, υ = VTeσnNn where $${V}_{Te}=\sqrt{{k}_{B}{T}_{e}/{m}_{e}}$$ is the electron thermal velocity, σn and Nn are the neutrals cross-section and density, respectively, Te is the electron temperature, and υch is the dust charging frequency.

As in refs18,23, the simulation here includes a loaded microwave cavity as shown in Fig. 2A. The plasma column inside is represented by a dielectric cylinder of h = 50mm height and dPC = 15mm diameter. In the heuristic transmission-line model presented in ref.23, the plasma column is modeled by a lumped element in a transmission line (having admittances of YPC = GPC + jBPC and Yc, respectively). The conductance and susceptance of the plasma column are approximated by GPC = ωε0$${\varepsilon }_{r}^{^{\prime\prime} }$$ A/h and BPC = ωε0$${\varepsilon }_{r}^{^{\prime} }$$ A/h, respectively, where A is the effective cross-section area of the plasma-column. In this analysis (as in ref.18), the complex εr space is numerically scanned in order to find the conditions that provide reflection values as measured in the experiments. The real part of εr is initially chosen as 0.2 while the imaginary part is searched between 3 to 100. The simulation and the experimental observations, presented in the Smith chart in Fig. 5C(b), result in an estimate of $${\varepsilon }_{r}^{^{\prime\prime} }$$ ~ 25 for the effective dissipation factor (including conductivity). Using the excitation temperature found by Boltzmann plot (~0.3–0.6 eV) and the dust particle size obtained by SAXS analyses of similar dusty plasmas18,23,27,28 with the assumptions therein (e.g., υυchω2 and υchω2), the dielectric constant and the corresponding electron density are estimated in this case by

$${\varepsilon }_{r}\cong 1+\frac{{\omega }_{p}^{2}}{{\omega }^{2}+{\nu }^{2}}[-1+\frac{\nu }{\widehat{k}{l}_{d}}-j(\frac{\nu }{\omega }+\frac{1}{\widehat{k}{l}_{d}})],$$
(M8)

and

$${n}_{e}\sim \frac{{m}_{e}{\varepsilon }_{0}{\varepsilon }_{r}^{{\rm{^{\prime} }}{\rm{^{\prime} }}}}{{e}^{2}}\frac{{\omega }^{2}+{\upsilon }^{2}}{\upsilon /\omega +1/\hat{k}{l}_{d}},$$
(M9)

respectively, where $$\hat{k}$$ is approximated by ~π/dPC for the finite transverse profile of the plasma column. Equation (M9) yields ne ~ 1017–1018m−3, similarly to other weakly-ionized plasmas and flames at atmospheric pressure in air.

When the dusty-plasma region coexists with the molten hotspot in the cavity, most of the microwave power is absorbed by the plasma. This domination is visually observed, since the molten rock tends to cool down once the plasma is ejected, and it is also evidenced by the thermal-camera measurements (e.g. in Fig. 7B(c)). This effect is also verified by simulation and by an analytical estimate (taking into account the effective values of the dielectric permittivity and electrical conductivity of both media, σeff = σ + ωε″ in a transmission-line model with lumped loads23). According to this estimate, the microwave power absorbed by the plasma column is more intense by at least one order of magnitude than the power absorbed then by the rock.

## References

1. 1.

Metaxas, A. C. Foundations of Electroheat: A Unified Approach. (John Wiley & Sons, 2000).

2. 2.

Dikhtyar, V. & Jerby, E. Fireball ejection from a molten hot spot to air by localized microwaves. Physical Review Letters 96 (2006).

3. 3.

Parris, P. & Kenkre, V. Thermal runaway in ceramics arising from the temperature dependence of the thermal conductivity. physica status solidi (b) 200, 39–47 (1997).

4. 4.

Jerby, E., Aktushev, O. & Dikhtyar, V. Theoretical analysis of the microwave-drill near-field localized heating effect. Journal of Applied Physics 97, 034909 (2005).

5. 5.

Jerby, E. Localized microwave-heating intensification—A 1-D model and potential applications. Chemical Engineering and Processing: Process Intensification 122, 331–338 (2017).

6. 6.

Jerby, E., Dikhtyar V. & Einat, M. Microwave melting and drilling of basalt. AIChE Annual Meeting, Nov. 7–12, 2004, Austin, Texas, Proc., p. 1673, 2004 (Publisher: American Institute of Chemical Engineers).

7. 7.

Satish, H., Ouellet, J., Raghavan, V. & Radziszewski, P. Investigating microwave assisted rock breakage for possible space mining applications. Mining Technology 115, 34–40 (2006).

8. 8.

Hartlieb, P., Leindl, M., Kuchar, F., Antretter, T. & Moser, P. Damage of basalt induced by microwave irradiation. Minerals Engineering 31, 82–89 (2012).

9. 9.

Jerby, E., Meir, Y. & Faran, M. Basalt melting by localized-microwave thermal-runaway instability. Proc. AMPERE 14th Int’l Conf. Microwave High Freq. Heat., Sept. 16–19, 2013, Nottingham, UK, pp. 255–258 (2013).

10. 10.

Hartlieb, P., Kuchar, F., Moser, P., Kargl, H. & Restner, U. Reaction of different rock types to low-power (3.2 kW) microwave irradiation in a multimode cavity. Minerals Engineering 118, 37–51 (2018).

11. 11.

Hassani, F., Nekoovaght, P. M. & Gharib, N. The influence of microwave irradiation on rocks for microwave-assisted underground excavation. Journal of Rock Mechanics and Geotechnical Engineering 8, 1–15 (2016).

12. 12.

Mamontov, A. V., Nefedov, V. N., Tuv, A. L. & Yazykov, D. A. An investigation of the possibility of melting basalt using microwave energy. Measurement Techniques 55, 1068–1070 (2012).

13. 13.

Jerby, E. & Shoshani, Y. Fire-column-like dusty-plasma ejected from basalt by localized microwaves. Proc., Microwave Discharges MD-10 Workshop. Zvenigorod, Russia, Sept. 4–8 (2018).

14. 14.

Savovic, J. et al. LIBS Analysis of Geomaterials: Comparative study of basalt plasma induced by TEA CO2 and Nd:YAG laser in air at atmospheric pressure. Journal of Chemistry 2017, 1–9 (2017).

15. 15.

Deák, T. & Czigány, T. Chemical composition and mechanical properties of basalt and glass fibers: A comparison. Textile Research Journal 79, 645–651 (2009).

16. 16.

Ercenk, E., Sen, U. & Yilmaz, S. The erosive wear behavior of basalt based glass and glass–ceramic coatings. Tribology International 52, 94–100 (2012).

17. 17.

Jerby, E. & Dikhtyar, V. Fireball ejection from a molten hotspot in solid to air by a reversed microwave drill mechanism. Microwave Discharges: Fundamentals and Applications. Lebedev, Y. A. (Ed.), Yanus-K, Moscow, 227–232 (2006).

18. 18.

Meir, Y. et al. Observations of ball-lightning-like plasmoids ejected from silicon by localized microwaves. Materials 6, 4011–4030 (2013).

19. 19.

Jerby, E. Microwave-generated fireballs. Encyclopedia of Plasma Technology, J. L. Shohet (Ed.), CRC Press, 819–832 (2016).

20. 20.

Jerby, E., Dikhtyar, V., Aktushev, O. & Grosglick, U. The microwave drill. Science 298, 587–589 (2002).

21. 21.

Lebedev, Y. A., Epstein, I. L., Tatarinov, A. V. & Shakhatov, V. A. Electrode microwave discharge and plasma self-organization. Journal of Physics: Conference Series 44, 30–39 (2006).

22. 22.

Durand, M. & Wilson, J. G. Ball lightning and fireballs during volcanic air pollution. Weather 61, 40–43 (2006).

23. 23.

Popescu, S. et al. Plasma column and nano-powder generation from solid titanium by localized microwaves in air. Journal of Applied Physics 118, 023302 (2015).

24. 24.

Kramida, A., Ralchenko, Y. & Reader, J. NIST Atomic Spectra Database (Ver. 5.2), NIST ASD Team (2014).

25. 25.

Luque, J. & Crosley, D. R. LIFBASE: Database and Spectral Simulation (Version 1.5) (SRI International; Menlo Park, CA, USA: 1999).

26. 26.

Shi, Y.-X., Ge, D.-B. & Wu, J. Theoretical analysis of microwave attenuation constant of weakly ionized dusty plasma. Chinese Journal of Geophysics 50, 877–883 (2007).

27. 27.

Jerby, E. et al. Nanoparticle plasma ejected directly from solid copper by localized microwaves. Applied Physics Letters 95, 191501 (2009).

28. 28.

Mitchell, J. B. A. et al. Evidence for nanoparticles in microwave-generated fireballs observed by synchrotron x-ray scattering. Physical Review Letters 100 (2008).

29. 29.

Fagents, S. A., Gregg, T. K. P. & Lopes, R. M. C. Modeling Volcanic Processes the Physics and Mathematics of Volcanism. (Cambridge University Press, 2013).

30. 30.

Saucedo, R., Macías, J., Sheridan, M., Bursik, M. & Komorowski, J. Modeling of pyroclastic flows of Colima Volcano, Mexico: implications for hazard assessment. Journal of Volcanology and Geothermal Research 139, 103–115 (2005).

31. 31.

Currenti, G., Bonaccorso, A., Negro, C. D., Scandura, D. & Boschi, E. Elasto-plastic modeling of volcano ground deformation. Earth and Planetary Science Letters 296, 311–318 (2010).

32. 32.

Heffter, J. L. & Stunder, B. J. B. Volcanic ash forecast transport and dispersion (VAFTAD) model. Weather and Forecasting 8, 533–541 (1993).

33. 33.

Fink, J. H. & Griffiths, R. W. Morphology, eruption rates, and rheology of lava domes: Insights from laboratory models. Journal of Geophysical Research: Solid Earth 103, 527–545 (1998).

34. 34.

Gregg, T. K. P. & Fink, J. H. Quantification of submarine lava-flow morphology through analog experiments. Geology 23, 73 (1995).

35. 35.

Funiciello, F. et al. Mapping mantle flow during retreating subduction: Laboratory models analyzed by feature tracking. Journal of Geophysical Research: Solid Earth 111 (2006).

36. 36.

Cen, J., Yuan, P. & Xue, S. Observation of the optical and spectral characteristics of ball lightning. Physical Review Letters 112 (2014).

37. 37.

Abrahamson, J. & Dinniss, J. Ball lightning caused by oxidation of nanoparticle networks from normal lightning strikes on soil. Nature 403, 519–521 (2000).

38. 38.

Ofuruton, H., Kondo, N., Kamogawa, M., Aoki, M. & Ohtsuki, Y.-H. Experimental conditions for ball lightning creation by using air gap discharge embedded in a microwave field. Journal of Geophysical Research: Atmospheres 106, 12367–12369 (2001).

39. 39.

Mcnutt, S. R. & Williams, E. R. Volcanic lightning: global observations and constraints on source mechanisms. Bulletin of Volcanology 72, 1153–1167 (2010).

40. 40.

Mueller, S. P., Helo, C., Keller, F., Taddeucci, J. & Castro, J. M. First experimental observations on melting and chemical modification of volcanic ash during lightning interaction. Scientific Reports 8 (2018).

41. 41.

Taylor, H. E. & Lichte, F. E. Chemical composition of Mount St. Helens volcanic ash. Geophysical Research Letters 7, 949–952 (1980).

42. 42.

Shoji, S., Nanzyo, M. & Dahlgren, R. Productivity and utilization of volcanic ash soils (Chapter 8). Developments in Soil Science, Volcanic Ash Soils - Genesis, Properties and Utilization 209–251, https://doi.org/10.1016/s0166-2481(08)70269-1 (1993).

43. 43.

Buttress, A. et al. Towards large scale microwave treatment of ores: Part 1 – Basis of design, construction and commissioning. Minerals Engineering 109, 169–183 (2017).

44. 44.

Meir, Y. & Jerby, E. Breakdown spectroscopy induced by localized microwaves for material identification. Microwave and Optical Technology Letters 53, 2281–2283 (2011).

45. 45.

Karatodorov, S. et al. A novel device for spectrochemical analysis based on a combination of LIBS and a hollow cathode discharge. Journal of Physics: Conference Series 715, 012009 (2016).

46. 46.

Presnall, D. C., Simmons, C. L. & Porath, H. Changes in electrical conductivity of a synthetic basalt during melting. Journal of Geophysical Research 77, 5665–5672 (1972).

47. 47.

Frasch, L., Mclean, S. & Olsen, R. Electromagnetic properties of dry and water saturated basalt rock, 1–110 GHz. IEEE Transactions on Geoscience and Remote Sensing 36, 754–766 (1998).

48. 48.

Carter, L. M. et al. Dielectric properties of lava flows west of Ascraeus Mons, Mars. Geophysical Research Letters 36 (2009).

49. 49.

Bondre, N. R. Analysis of vesicular basalts and lava emplacement processes for application as a paleobarometer/paleoaltimeter: a discussion. The Journal of Geology 111, 499–502 (2003).

50. 50.

Ebert, H. P. et al. Thermo-physical properties of a volcanic rock material. High Temperatures-High Pressures 34, 561–568 (2002).

51. 51.

Negro, C. D. et al. Lava flow hazards at Mount Etna: constraints imposed by eruptive history and numerical simulations. Scientific Reports 3 (2013).

52. 52.

Lange, R. A., Cashman, K. V. & Navrotsky, A. Direct measurements of latent heat during crystallization and melting of a ugandite and an olivine basalt. Contributions to Mineralogy and Petrology 118, 169–181 (1994).

53. 53.

Burgi, P. Y., Caillet, M. & Haefeli, S. Field temperature measurements at Erta’Alel lava lake, Ethiopia. Bulleting of Volcanology 64, 472–485 (2002).

## Acknowledgements

This research is supported by The Israel Science Foundation (Grant No. 1896/16). The authors also wish to acknowledge Drs. Zahava Barkay and Davide Levy for the SEM and XRD analyses, respectively, and Profs. Shmuel Marco, Ehud Heyman, and Rachman Chaim for helpful discussions.

## Author information

Authors

### Contributions

E.J. conceived the fundamental concept, experimentally discovered the LMH effect of plasma emission from basalt, and supervised the research project. Y.S. participated in the experimental design, developed the data acquisition system, and performed the simulations and analyses. Both authors carried out the experimental work and wrote the paper together.

### Corresponding author

Correspondence to Eli Jerby.

## 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.

## Rights and permissions

Reprints and Permissions

Jerby, E., Shoshani, Y. Localized microwave-heating (LMH) of basalt – Lava, dusty-plasma, and ball-lightning ejection by a “miniature volcano”. Sci Rep 9, 12954 (2019). https://doi.org/10.1038/s41598-019-49049-5

• Accepted:

• Published:

By submitting a comment you agree to abide by our Terms and Community Guidelines. If you find something abusive or that does not comply with our terms or guidelines please flag it as inappropriate.


text:
# Maharashtra Board Practice Set 21 Class 7 Maths Solutions Chapter 4 Angles and Pairs of Angles

Balbharti Maharashtra State Board Class 7 Maths Solutions covers the 7th Std Maths Practice Set 21 Answers Solutions Chapter 4 Angles and Pairs of Angles.

## Angles and Pairs of Angles Class 7 Practice Set 21 Answers Solutions Chapter 4

Question 1.
∠ACD is an exterior angle of ∆ABC. The measures of ∠A and ∠B are equal. If m∠ACD = 140°, find the measures of the angles ∠A and ∠B.

Solution:
Let the measures of ∠A be x°.
m∠A = m∠B = x°
∠ACD is the exterior angle of ∆ABC
∴ m∠ACD = m∠A + m∠B
∴ 140 = x + x
∴ 140 = 2x
∴ 2x = 140
∴ x = $$\frac { 140 }{ 2 }$$
= 70
∴ The measures of the angles ∠A and ∠B is 70° each.

Question 2.
Using the measures of the angles given in the figure alongside, find the measures of the remaining three angles.

Solution:
m∠EOD = m∠AOB = 8y ….(vertically opposite angles)
∠FOL, ∠EOD and ∠COD form a straight angle.
∴ m∠FOE + m∠EOD + m∠COD = 180°
∴ 4y + 8y + 6y = 180
∴ 18y = 180
∴ y = $$\frac { 180 }{ 18 }$$
∴ y = 10
m∠EOD = 8y = 8 x 10 = 80°
m∠AOF = m∠COD ….(Vertically opposite angles)
= 6y = 6 x 10 = 60°
m∠BOC = m∠FOE ….(Vertically opposite angles)
= 4y = 4 x 10 = 40°
∴ The measures of ∠EOD, ∠AOF and ∠BOC are 80°, 60° and 40° respectively.

Question 3.
In the isosceles triangle ABC, ∠A and ∠B are equal. ∠ACD is an exterior angle of ∆ABC. The measures of ∠ACB and ∠ACD are (3x – 17)° and (8x + 10)° respectively. Find the measures of ∠ACB and ∠ACD. Also find the measures of ∠A and ∠B.

Solution:
Let the measure of ∠A be y°. A
∴ m∠A = m∠B = y°
∠ACB and ∠ACD form a pair of linear angles.
∴ m∠ACB + m∠ACD = 180°
∴ (3x – 17) + (8x + 10) = 180
∴ 3x + 8x – 17 + 10 = 180
∴ 11x – 7 = 180
∴ 11x – 7 + 7 = 180 + 7 …(Adding 7 on both sides.)
∴ 11x = 187
∴ x = $$\frac { 187 }{ 11 }$$ = 17
m∠ACB = 3x – 17 = (3 x 17) – 17 = 51 – 17 = 34°
m∠ACD = 8x + 10 = 8 x 17 + 10 = 136 + 10 = 146°
Here ∠ACD is the exterior angle of ∆ABC and ∠A and ∠B are its remote interior angles.
∴ m∠ACD = m∠A + m∠B
∴ 146 = y + y
∴ 146 = 2y
∴ 2y = 146
∴ y = $$\frac { 146 }{ 2 }$$ = 73
∴ The measures of ∠ACB, ∠ACD, ∠A and ∠B are 34°, 146°, 73° and 73° respectively.

Maharashtra Board Class 7 Maths Chapter 4 Angles and Pairs of Angles Practice Set 21 Intext Questions and Activities

Question 1.
Use straws or sticks to make all the kinds of angles that you have learnt about. (Textbook pg. no. 29)
Solution:
(Student should attempt the activity on their own)

Question 2.
Observe the table given below and draw your conclusions (Textbook pg. no. 31)

Solution:
i. 180°
ii. 360°
iii. 540°
iv. 720°
v. 180° x 5 = 900°
vi.  , 180° x 6 = 1080°

format: plain


text:
# koweycode

Hobby-hacking Eric

## 2007-12-23

### darcs at a glance

Check out Paul Bedaride's very handy darcs cheet sheat. It gives you basically everything you need to know about darcs on a single sheet of A4 paper. I'm sure Paul would appreciate any appropriate criticism you may have.

## 2007-12-18

### mail?

So we have in Haskell quite a few consumer applications
When's the mail client coming? I'm asking this in the random speculative sense, not in the "gimme a Haskell mail client now" sense. What would a Haskell mail client look like? I'm guessing that plugins will play a nice role, extensibility and all. Being able to handle really large mailboxes (a big "archive" folder) would be nice. Perhaps Sup would be good inspiration. Come to think of it, maybe the client should be implemented in Cat, just for the name...

## 2007-12-06

### Setup.(l)hs

One minor annoyance when using Cabal to install stuff is that not every project agrees on whether the Setup script should be an .hs or an .lhs file. The consequence is that when doing a bunch of installations, I'll hit the up arrow to re-run, say, runhaskell Setup.lhs configure and it will complain that the file is not found, because this project uses .hs and the project just before uses .lhs.

What I'm wondering, though is if it would be a good idea for projects to distribute both files? We could even use something like this to have the same file regardless of extension:
`#!/usr/bin/env runhaskell{-> import Distribution.Simple> main = defaultMain-}import Distribution.Simplemain = defaultMain`

I guess that once cabal-install comes out, none of this would really matter since all that building-of-dependencies stuff would be taken care of automatically.

### David Roundy is the new darcs unstable maintainer

Just wanted to announce that I am ending my stint as unstable branch maintainer and transferring the responsibility back to David. This will help me to keep up with my new life and job, and help David to usher in the new darcs-2.0.

I hope I'll be able to continue participating, maybe submitting a patch or two when things settle down over here. In the meantime, it's been fun and I've learned a lot.

So thanks for everything and good luck with 2.0!

## 2007-11-06

### PhD viva (defense)

I'll be presenting my thesis next Wednesday. You are cordially invited to attend the defence and to join us for drinks afterwards.

Surface realisation: ambiguity and determinism
Eric Kow

14 November 2007
Amphi C, LORIA
Nancy, France

Surface realisation is a subtask of natural language generation. It may be viewed as the inverse of parsing, that is, given a grammar and a representation of meaning, the surface realiser produces a natural language string that is associated by the grammar to the input meaning. This thesis presents three extensions to GenI, a realisation algorithm for Feature-Based Tree Adjoining Grammar (FB-LTAG).

The first extension improves the efficiency of the realiser with respect to lexical ambiguity. It is an adaptation from parsing of the "electrostatic tagging" optimisation, in which lexical items are associated with a set of polarities, and combinations of those items with non-neutral polarities are filtered out.

The second extension deals with the number of outputs returned by the realiser. Normally, the GenI algorithm returns all of the sentences associated with the input logical form. Whilst these inputs can be seen as having the same core meaning, they often convey subtle distinctions in emphasis or style. It is important for generation systems to be able to control these extra factors. Here, we show how the input specification can be augmented with annotations that provide for the fine-grained control that is required. The extension builds off the fact that the FB-LTAG grammar used by the generator was constructed from a "metagrammar", explicitly putting to use the linguistic generalisations that are encoded within.

The final extension provides a means for the realiser to act as a metagrammar-debugging environment. Mistakes in the metagrammar can have widespread consequences for the grammar. Since the realiser can output all strings associated with a semantic input, it can be used to find out what these mistakes are, and crucially, their precise location in the metagrammar.

## 2007-10-29

### darcs conflicts faq

Pekka Pessi and I have put together an FAQ on the darcs conflict problem. It has three major sections:
1. Everyday conflicts: what conflicts are and how you should deal with them in the general case.
2. The big conflicts bug: what it is, how you can avoid it, and what to do if you have run into trouble.
3. Darcs 2.0: from a user perspective, how it will change from darcs 1.x (not very much), and what resolving conflicts might look like (rollback will play a bigger role). David has been making some great progress. Nevertheless, our best estimates are that we will be ready for alpha testing only in Feb 2008, and release by the second quarter of that year.
There may be some mistakes or gaps in the FAQ, but I hope that you will find it useful.

## 2007-10-24

### getting things done with mutt 3 (action counter)

Here's a short tip for putting a reminder on your desktop wallpaper of how many next-action and waiting-for messages you have. The result looks like this:
`ACTION:  4WAITING: 1`

The approach is to combine a small shell script with the wonderful GeekTool program for MacOS X (similar programs exist for Linux, I'm sure). GeekTool lets you display arbitrary text, say console text on your Desktop. One of my GeekTool windows is set to run the script and display its results with a big red font.

The shell script is pretty dumb; it just counts the number of files in my Maildir directory. I guess if you're using the mbox format, you'll have to find some other way to count messages. Count the number of instances of '^From: ', maybe?
`#!/bin/sh# \$2 is just for paddingfunction count_messages (){  echo -n "\$1:\$2"; ls -1 \${HOME}/Mail/current/\$1/cur | wc -l}count_messages ACTION " "count_messages WAITING`

I'm not expecting this to have a huge impact on my productivity, but maybe this will be that extra little bit that counts.

Edit 2007-10-25Fixed counting to account for empty boxes. Zero. We like that number.

## 2007-09-21

### kowthese 1.0

I thought I might announce version 1.0 of my PhD thesis: Surface realisation: ambiguity and determinism

This is the version that went out to the committee, so it is not definitive (you may prefer to wait for version 1.1 in December). It's also not very Haskell-related, aside from the fact that the software inside is written in Haskell. If you are interested, the overall topic area is computational linguistics (natural language processing), specifically, natural language generation.

Oh, and the darcs repository for the thesis (LaTeX sources):
` darcs get http://www.loria.fr/~kow/kowthese`
The viva/defense to be held on 2007-11-14.

## 2007-08-25

### getting things done with mutt 2 (auto-review)

Last year, I posted some ideas for applying GTD to mutt. As you may have heard, GTD is a simple methodology to help people stay on top of things. The basic idea in my post was to use an on-board X-Label editor to associate each message with a 'next action' or a 'waiting for' tag, and to store them in the respective mailboxes ACTION and WAITING. This was accompanied by a small colour configuration to highlight the X-Label field of each message, thus making it clear at all times what the next action was.

After one year of use, I can report that I am 95% happy with the system. It is simple and effective... however, not entirely eric-proof. In this post, I propose a small addition to tighten up the system and make it more resistant to my foolishness. The problem is that GTD is a heavily review-oriented system. Once you move tasks out of your head and onto some external device (e.g. a pad of paper), you must also consult that device from time to time or risk forgetting to do them. For example, one thing that can easily happen to me is that I will move messages into ACTION and WAITING and simply forget they are there.

This is where the idea of automated review comes in. What I propose a simple method for reminding yourself that you have next actions to perform, or things that you are waiting on. It consists of a shell script and a crontab entry. First the script (I call it gtd-review):
`#!/bin/sh# note: I am using the maildir format; if you are using mbox, # you should just replace the 'find \$1 | xargs \$1' with 'cat \$1'function summarise () {  find \$1 | xargs cat |\    sed -n -e '/^X-Label/G' -e '/^X-Label/p'\           -e '/^From/p'    -e '/^Subject/p' -e '/^Date/p' |\    sed -e 's/From: //' -e 's/Date: //' -e 's/Subject: //'}echo '======================================================================'echo 'ACTIONS'echo '======================================================================'echosummarise \${HOME}/Mail/ACTIONecho '======================================================================'echo 'WAITING'echo '======================================================================'echosummarise \${HOME}/Mail/WAITING`

And now the crontab:
`@daily gtd-review 2>&1 /dev/null | mail -s "GTD review `date +%Y-%m-%d`" me@myaddress.com`
I'm sure you could improve on this. For example, I would rather the dates were presented in yyyy-mm-dd format and accompanied with a friendlier description like "3 weeks ago"... but working on that would probably count as fidgeting.

Anyway, I hope others find this to be useful.

## 2007-08-16

### a history of monad tutorials

Here's a historical overview of monad tutorials since Phil Wadler's original observation that monads can be implemented in Haskell and become extremely useful.

When I wrote this, I originally wanted to do a real history, with an analysis of how people have tried to teach monads over the years, but I guess this is about all I have time for. Dates, authors and blurbs. Corrections/additions always welcome! As you can tell, I have not read them all.

Edit 2007-08-17: I have updated and moved this timeline to Haskellwiki. This might be useful when some future Haskell archeologist tries to figure out the precise "ah-ha!" moment when every single programmer in the world 'got' monads.

## 2007-08-14

Looks like some wikibookian(s) have embarked upon a Chinese translation of the Haskell wikibook. Good luck to them! Chinese speakers might be interested in jumping on board. As for non Chinese speakers, the sentence above is "Haskell is a functional programming language."

## 2007-07-19

### monomorphism redux

There may be errors in this, of course!

### the context from wikibooks

Following the previous example, you might be tempted to try storing a value for that radius. Let's see what happens:
`Prelude> let r = 25Prelude> 2 * pi * r<interactive>:1:9:    Couldn't match `Double' against `Integer'      Expected type: Double      Inferred type: Integer    In the second argument of `(*)', namely `r'    In the definition of `it': it = (2 * pi) * r`

Whoops! You've just run into a programming concept known as types. Types are a feature of many programming languages which are designed to catch some of your programming errors early on so that you find out about them before it's too late. We'll discuss types in more detail later on in the Type basics chapter, but for now it's useful to think in terms of plugs and connectors. For example, many of the plugs on the back of your computer are designed to have different shapes and sizes for a purpose. This is partly so that you don't inadvertently plug the wrong bits of your computer in together and blow something up. Types serve a similar purpose, but in this particular example, well, types aren't so helpful.

### the new monomorphism-based explanation

The quick solution to this problem is to specify a type for the number 25. For lack of other information, Haskell has "guessed" that 25 must be an `Integer` (which cannot be multiplied with a `Double`). To work around this, we simply insist that it is to be treated as a Double
`Prelude> let r = 25 :: DoublePrelude> 2 * pi * r157.07963267948966`

#### Note

There is actually a little bit more subtlety behind this problem. It involves a language feature known as the monomorphism restriction. You don't actually need to know about this for now, so you can skip over this note if you just want to keep a brisk pace. Instead of specifying the type `Double`, you also have given it a polymorphic type, like `Num a => a`, which means "any type a which belongs in the class Num". The corresponding code looks like this and works just as seamlessly as before:
`Prelude> let r = 25 :: Num a => aPrelude> 2 * pi * r157.07963267948966`

Haskell could in theory assign such polymorphic types systematically, instead of defaulting to some potentially incorrect guess, like Integer. But in the real world, this could lead to values being needlessly duplicated or recomputed. To avoid this potential trap, the designers of the Haskell language opted for a more prudent "monomorphism restriction". It means
that values may only have a polymorphic type if it can be inferred from the context, or if you explicitly give it one. Otherwise, the compiler is forced to choose a default monomorphic (i.e. non-polymorphic) type. This feature is somewhat controversial. It can even be disabled with the GHC flag (-fno-monomorphism-restriction), but it comes with some risk for inefficiency. Besides, in most cases, it is just as easy to specify the type explicitly.

## 2007-07-17

### Write Yourself a Scheme in 48 Hours (PDF)

One of the wikibookians has made a rather nice PDF out of Johnathan Tang's Write Yourself a Scheme in 48 Hours. The conversion was done semi-automatically from mediawiki syntax to LaTeX [in Java... tsk]. Many thanks to Hagindaz for the conversion!

## 2007-07-15

### monomorphism and the unintentional fib

The monomorphism restriction is a simple problem with a scary name.

I think I've run into the first instance where I have actually been able to identify something as being the monomorphism restriction in action (*). The good news is that if you don't understand what the restriction is, this might be your chance. The bad news is that many Haskell newbies might have been hurt in the process, because it involves an unintentional fib that I told in near the beginning of the Haskell wikibook.

(*) I'd appreciate it if somebody could fact-check me on this.

### circles and half-truths

High school Geometry. We've got a circle of radius 25 and we want to know its circumference (2 * pi * r). Now let's see what happens when we type it into GHCi
`Prelude> let r = 25Prelude> 2 * pi * r<interactive>:1:4:    No instance for (Floating Integer)      arising from use of `pi' at :1:4-5    Possible fix: add an instance declaration for (Floating Integer)    In the second argument of `(*)', namely `pi'    In the first argument of `(*)', namely `2 * pi'    In the expression: (2 * pi) * r`

Oops! At this point, the reader runs into types for the very first time. This morning, I realised to my horror that I might have given a very wrong explanation of the problem to the gentle Haskell newbie. I said

The main problem is that Haskell doesn't let you multiply Integers with real numbers. We'll explain why later, but for now, you can get around the issue by using a Double for r so that the pieces fit together:

`Prelude> let r = 25.0Prelude> 2 * pi * r157.07963267948966`

Which is true, but is only sort of a half-truth. The problem with my explanation is that it lets the reader walk away with the mistaken belief that numbers without a decimal point, such as 25, can only be integers, when really they can be any `Num a`. It's as if somebody had taught OCaml too recently and forgotten that `haskell /= ocaml`! (Coughs discretely)

A concrete example of why it's important to get this right can be found further down the chapter. Here, I want to show that we can use variables within other variables. So here's what I have the reader type in `area = pi * 5^2`:
`Prelude> let area = pi * 5^2`

And here everything works... except...

Except if you are a sharp-eyed reader, you remember from above that I had just said that types prevent you from multiplying integers with reals and I had unintentionally implied that numbers like `5` are integers. So if you are a sharp-eyed reader, you look at that thing and you say to yourself, "HUH? That shouldn't work! You can't multiply an integer with a real!"

### monomorphism, like polymorphism without the poly

The real problem is not that we had set `r` to an integer. By right `r = 25` should give us any `Num a => a`; however, since we do not give it a type signature, `r` gets restricted to being an `Integer`. In fact, the example of `2 * pi * r` would have worked if (a) we had given `r` a polymorphic type signature or (b) we had run GHC with its 'no monomorphism restriction' extension.

#### polymorphic type signature

Here we add an explicit type signature to `r`. Everything works:
`Prelude> let  r :: Num a => a; r = 25Prelude> 2 * pi * r157.07963267948966`
(Thanks to shachaf on #haskell for reminding me that we can use `{}/;` syntax and showing me how to apply it to write type signatures)

#### -fno-monomorphism-restriction

And if you don't like type signatures, here's what it looks like running without the monomorphism restriction:
`dewdrop /tmp % ghci -fno-monomorphism-restriction   ___         ___ _  / _ \ /\  /\/ __(_) / /_\// /_/ / /  | |      GHC Interactive, version 6.6, for Haskell 98./ /_\\/ __  / /___| |      http://www.haskell.org/ghc/\____/\/ /_/\____/|_|      Type :? for help.Loading package base ... linking ... done.Prelude> let r = 25Prelude> 2 * pi * r157.07963267948966`
No surprises.

### helping the newbies

Clearly, my explanation needs to be fixed. I just need to figure out the right way to do it though. I really don't want to get too technical (the reader doesn't even know about types yet!), but I'll need to avoid lying to the reader. It's already bitten two users, and it took me one of my readers typing in this text for me to figure out what had happened:
You might be thinking that this won't work--isn't 5 an integer, and therefore 5^2 also an integer? And didn't we just get an error trying to multiply pi by an integer?. What's going on is that when you "let r = 25", the "r" you get is more restricted than using the literal string "25" or 5^2. Try :t r and :t 5^2 and see the difference

I'm not entirely satisfied with this attempt (sorry), and want to deal with the situation more gracefully. Just don't know how to go about it yet.

### knowing, Knowing and poly/mono

Oh a word about the scary name 'monomorphism restriction'. I find it curious that I should have found that name scary for so long. I mean, for the longest time, I've told myself that I liked 'polymorphism' right? So how difficult would it have been to do a little etymology and notice that 'monomorphism' sounds exactly like 'polymorphism', except that you replace the 'poly-' (many) by 'mono-' (one). By the right, the two words have equivalent scariness! But for some reason, my brain somehow refused to recognise the fact. Instead, it associated one word with warm fuzzies and the other word with huh-does-not-compute.

Otherwise, one thing I found interesting about this is how you can simultaneously (a) hold a piece of knowledge and (b) not apply it consistently. For example, when I had written that module, I knew that numbers could be any `Num a` (and that you could do fun things making up crazy implementations of `Num`), yet at the same time as I was using this knowledge (I told myself 'true, but let's not talk about that now, no point confusing the newbies'), I can completely failed to apply that knowledge, because I went back and reflexively treated `25` as an Integer, probably due to all that freshman OCaml teaching. You know something, but you don't Know it.

## 2007-07-13

### what's in season?

Another programming project for those of you who are just itching for something to code. Basically, I want a website which can tell me, given my current location, what fruits and vegetables are in season right now.

Some thoughts, questions and requirements
• The site must be dead simple to and very pleasant to use. This is not something you should have to read documentation to figure out.
• This kind of thing could be easily international, so I want pictures. Maybe you can grab them from the Wikimedia Commons. I guess it would be fair to give you bonus points if you localise the thing, or maybe let me play with the language settings so I learn how to say 'rutabaga' in Arabic.
• How does the user tell you where s/he lives? As a default, it would be nice if you auto-detected it, but what might be nicer also is if I could play around and plug in different locations. How would you pick a location? By pointing at a map of the world? Also, maybe you don't just want a single point in the map, but a region of N kilometers around me. The question is basically, what grows N kilometers from where I live, where I get to specify
• Likewise, what do you do about the current date? It would also be nice if I can play around with this, asking not just 'what's in season right now' but 'what's in season during wintertime?'
• Where is all of your data coming from? How are you going to store it and look it up? What kind of data do you really need?
• If you want to get really really fancy, you can make the site adapt to current events. Maybe parse newspaper texts to find out that it's really not a good year for mangoes.
This is not necessarily a Haskell project (although in my silly, silly eyes, everything is potentially a Haskell project), but this might be a fun way to learn how to do web stuff and maybe play around with databases. In fact, such a project might also be useful for building a Haskell web tutorial, a kind of site that we can build together. Simple objectives that everybody can understand, and actually useful for something.

This project might also be a good way to learn about building user interfaces. Or maybe if you're not interested in working on that stuff, it would be a good opportunity to partner up with somebody else. They worry about the UI stuff and you worry about the code. I don't know anything about UI, except that I think it's important to get it right. If it helps, I greatly enjoyed Donald Norman's The Design of Everyday Things, as well as Bret Victor's Magic Ink.

## 2007-07-05

### mediawiki code projects

Three more projects to practice your Haskell with, and produce something useful while you're at it:
1. a mediawiki writer for Pandoc (should be a piece of cake)
2. a mediawiki reader for Pandoc (perhaps less easy, note that there is also some HTML to deal with)
3. a mediawiki template engine : given a set of mediawiki pages on the local filesystem, convert mediawiki input into mediawiki output, with all templates interpreted
My super-seekret reason for suggesting these projects is so that we can one day convert the Haskell wikibook to LaTeX, or something else, and produce a nice PDF. Naturally, it would also be useful for the other wikibooks, many of which have crappy PDFs, or none at all. But that's not for you to worry about :-)... just have some nice exercises to play with.

(#3 might be a bit of work... and also, it's not clear that this is exactly what we want for converting wikibooks. It seems that the point would not be to expand the templates, but to convert them to something else. If I have a template called HaskellExercises, I don't want to expand it to a bunch of div tags or whatever; I want to convert it to something else)

## 2007-07-01

Another potentially fun and probably big project for Haskellers: software for the RepRap project. The goal of RepRap is to build an open-source 3D printer for under \$500 and with the ability to print out its own parts. Their control software is written in Java... borriiing.

Maybe this is the kind of niche that Haskell could jump in to, something a little unusual (like darcs and xmonad), and very useful at the same time (like darcs and xmonad). My rough thought was that we could similar successes with xmonad, building solid and minimal code for something that is real world (you don't get any more real than physical objects).

## 2007-06-16

Created on apfelmus's suggestion. Should provide a place for writers of Haskell books, tutorials, blogs, teaching materials of all sorts. We mostly had the wikibook in mind, but figured that others might like to join in on the fun. Real World?

Maybe we should host an annual monad tutorial contest or something, each year judging on different criteria, like "most creative use of tuna fish".

## 2007-05-28

I was looking at Audrey Tang's presentation Visual Basic rocks, and came across a piece of good, simple advice:

Dogmatic

Humble

Well put. I was grateful to get a little reminder, a little booster shot. I'm just hoping that I have taken it sufficiently to heart.

(I'm assuming you see the red X under 'Dogmatic' and the green check mark under 'Humble').

## 2007-05-21

### burn your gas factories down

I've been Haskelling for three years now and have been loving it. The only discomfort is that from time to time I become painfully aware of my habit of making things horrible and ugly. Consider this code for instance:

### usine à gaz

List of random indices. It is a list [ rM, r(M+1), ..., rN ] where rX is a random number from X to N
`> nexts g (l,h) = unfoldr nxt (g,l,h)>  where>    nxt (_,l,h) | l >= h = Nothing>    nxt (g,l,h) = let (r,g2) = randomR (l,h) g>                      glh2   = (g2, l + 1, h)>                  in  Just (r, glh2)`

This code has been called "clever". Anytime somebody calls your code "clever", you should begin to worry. I mean just look at that thing! You can positively hear the gears turning and the doodads clicking. This code is what the French call a "gas factory", something incomprehensibly and needlessly complex.

### is there no simpler way?

Stop micromanaging! Just tell the computer what you want, not what you want it to do

`> nexts2 g (l,h) = map (\x -> fst \$ randomR (x,h) g) [l..h-1]`

No gears or doodads. Geez... I don't what it is with me and making things more complicated than they need to be.

## 2007-05-20

### unsort bis

Boy, do I feel like a big dummy!

Here is a super short and functional version I saw from a Pythonista on reddit.

`import Data.List ( sort )import System.Random ( Random, RandomGen, randoms, getStdGen )main :: IO ()main = do gen   <- getStdGen    interact \$ unlines . unsort gen . linesunsort :: (Ord x, RandomGen g) => g -> [x] -> [x]unsort g es = [ y | (_,y) <- sort \$ zip rs es ]  where rs = randoms g :: [Integer]`

### edit!

Heffalump points out that (i) if you have duplicates in `rs`, you don't get scrambling for the relevant bits (ii) this requires Ord x, which it really ought not to (although that is ani improvement from the array thing where I had to lock the type down for some reason)

### edit deux

Hmm... what does it mean to get a list of random arbitrary precision integers?

### unsort

Here's a small script I wrote partly for wikibook stuff and partly to learn how to use arrays and random numbers in Haskell.

I'm not a particularly enlightened Haskeller, so you might want to be careful about learning from me. Go ask somebody more experienced.

Note: one thing I'm a bit annoyed about is that I can't figure out how to make the unsort function generic, how to make it work for any type of array, element, index. Suggestions and by all means simplifications welcome.

### unsort

`> import Data.Ix ( Ix )> import Data.List ( unfoldr )> import Data.Array.MArray ( MArray, getElems, newListArray, readArray, writeArray )> import System.Random ( mkStdGen, getStdGen, Random, RandomGen, random, randomR )> import Data.Array.IO> main :: IO ()> main =>  do gen   <- getStdGen>     ins   <- lines `fmap` getContents>     outs  <- unsort gen ins>     putStr . unlines \$ outs`
Our objective is to scramble a list. To do this we convert the list into a mutable array and scramble it in place. This consists of traversing the array from left to right, swapping each element N with a random element from N to the end of the array.
`> unsort :: RandomGen g => g -> [String] -> IO [String]> unsort g es =>  do arr  <- newListArray (l,h) es :: IO (IOArray Int String)>     unsortH arr l idxs >>= getElems>  where>   idxs   = nexts g (l,h)>   (l, h) = (1, length es)`
The swapping itself is pretty straightforward. We swap the element at the
given index at the next random index. Recursion to the next element until
we run out of indices.
`> unsortH :: (MArray a e m, Num i, Ix i) => a i e -> i -> [i] -> m (a i e)> unsortH arr c [] = return arr> unsortH arr c (r:rs) =>  do rElem <- readArray arr r>     cElem <- readArray arr c>     writeArray arr c rElem>     writeArray arr r cElem>     unsortH arr (c+1) rs`
And here is how we generate that list of random indices. It is a list [ rM, r(M+1), ..., rN ] where rX is a random number from X to N... Hmm... I'm pretty sure this can be greatly cut down
`> nexts :: (RandomGen g, Num n, Ord n, Random n, Ix n) => g -> (n,n) -> [n]> nexts g (l,h) = unfoldr nxt (g,l,h)>  where>    nxt (_,l,h) | l >= h = Nothing>    nxt (g,l,h) = let (r,g2) = randomR (l,h) g>                      glh2   = (g2, l + 1, h)>                  in  Just (r, glh2)`

## 2007-05-18

### risk and recursion

Lately, I've been playing a bit of correspondence Risk with some childhood friends. The good thing about correspondence Risk, when you're scattered across twelve timezones is that it is inherently self-limiting. You are forced to wait your turn every day. Well, that was my hope anyway, but it turns out that things are not quite that simple. The problem is that though you may well your turn, nothing is stopping you in the meantime from thinking about World Domination instead of doing something useful.

But maybe something useful just came out of these daydreams. I was thinking that Risk might be a good tool for teaching programming techniques. For example, it seems calculating dice roll outcomes would a rather nice example for teaching recursion and dynamic programming. This is something we typically do with factorial and fibonacci, but for some students, that might get a little boring. Perhaps dice rolls aren't all that exciting either, but maybe you could sell the Risk angle an awaken your audience's inner ten year old. Maybe you could sell this as part of a bigger package... in this class, we'll be putting together our own Risk implementation, with fancy graphics and everything.

The idea is that you want to ask your program "if the attacker has 37 armies and the defender has 10, what is the most probable outcome and its probability (assuming that each side uses as many dice as possible)?"

My belief is that there is no way to calculate this 'instantly' and without computing all possibilities. You would have to basically crunch through each one of the (a * d) eventual outcomes. (anybody with halfway decent math skills want to confirm that?)

One idea you might able to show with this is just plain simple recursion (although you probably want to start with a simpler example first). So I've got 37 and 10, and if I need the expected outcomes of 37/8 (attacker wins), 36/9 (both win one), and 35/10 (defender wins), I could just factor in the probabilities of getting those.

But I thought was interesting was that you could show that there is some redundant computation going on here. You start at 37/10, but then you go into
 37/10 37/8 36/9 35/10

which in turn expands into
 37/10 37/8 36/9 35/10 37/6 36/5 35/8 36/7 35/8 34/9 35/8 34/9 33/10

Here, we are recalculating the scenarios 36/7, 35/8 and 34/9. What happens if we turn the crank some more? If I'm not mistaken, the naive algorithm would have to do 3^n calculations (loosely speaking), when really we shouldn't be doing any more than n^2.

I suppose what you'd really want is to have some kind of record of all the outcomes you've already computed. I'm not sure how it would work out code-wise or how you'd shift all those weights around (and if you are interested, I do invite you to cook up a quick implementation, RiskBuzz). I will observe, however, that this table could make it simple to turn around and ask a slightly more involved question, like "ok, so what are the three likeliest outcomes and their probabilities?"

## 2007-05-06

### iron coder

There ought to be something like Iron Chef for programming. Naturally, the Iron Coders would each represent a different paradigm: functional, imperative, object oriented, declarative. Actually, I have no idea how this would work and suspect it probably would not very entertaining at all. I just like the idea of summoning IRON CODER FUNCTIONAL! The guy rises with a platform and it's got a little lambda on it...

## 2007-05-01

Spot the lambda?

### Haskell :: Functional Programming with Types

Haskell :: Functional Programming with Types is now a featured wikibook, which means that it will be rotated on to the front page on a regular basis.

There are around 40 books on the site that have this distinction, so if you don't see the Haskell book on the front page, try again in another hour or so.

### Write Yourself a Scheme in 48 Hours

Note that the wikibook version of Write Yourself a Scheme in 48 Hours has also been featured for quite some time. Yay, Johnathan! It's not on the front page yet, but should be making its way into the rotation at some point. Its blurb is
as follows:
 In this advanced Haskell tutorial, we will implement a significant subset of Scheme together. We assume no prior knowledge; however, we will be going fast. So if you're feeling ambitious, why don't you Write Yourself a Scheme in 48 Hours?

## 2007-04-24

### le gentle introduction

Je viens de voir sur Haskellwiki que la traduction du Gentle Introduction to Haskell est terminée. Félicitations et merci à Nicolas Vallée et TuTuX.

I just noticed that the French translation of A Gentle Introduction to Haskell has been complete. Thanks and congrats to the authors. Now how about a YAHT translation or a wikilivre on Haskell?

## 2007-04-20

The wikibooks project has a 'featured book' concept, in which the best books of the project are prominently displayed on the front page. The Haskell wikibook has been nominated to be listed as one of these featured books. Votes are positive so far, but nothing official yet. In the meantime, all wikibook authors are being encouraged to put together an advertising blurb for the front page.

Here is my attempt. Can you make it better? Please feel free to post ideas on this blog, or on the wikibook talk page.

 Haskell is a functional programming language with a state of the art type system. This book will introduce you to computer programming with our language of choice. It is friendly enough for new programmers, but deep enough to challenge the most experienced. Come stretch your mind with us!

(I'm not over-selling am I? I'm always worried about that)

Oh and the minimalist logo is just something I threw together (public domain, of course). Not married to it, just looking for something better than the current one.

## 2007-04-19

### pleac revamp - thanks!

Just wanted to say thanks to whoever it was that started the PLEAC revamp. Looks much more like Haskell now. The old notation-abuse version is now called haskell-on-steroids, which annoys me somewhat, but now we have less risk of confusing newbies. Will be interesting to see how they compare, the Haskell PLEAC and the wiki cookbook.

## 2007-04-13

### congrats to hg!

I certainly do not speak for the darcs project as whole, but as a contributor and an enthusiastic fan. In any case, congratulations to the Mercurial team for adoption by Mozilla! I'm very happy to see Mercurial being adopted by both mutt and Mozilla, two projects that I also use. For me, it means that we're slowly starting to move on from centralised version control. There may be some pain involved, bugs to shake out and what not, but overall it's for the greater good. (That being said, I'm also pleased to see people upgrading from CVS to SVN, just climbing the ladder in general).

As for darcs, well, I hope that Jason's work will lead to the resolution of bug numero 1. No pressure, or anything. Just a little bit of progress, some useful new insights into the problem would be nice already.

Now if only I could work out all those Cabalisation issues...

## 2007-03-31

Just a small project idea for in case anybody is bored: write a small web toy that generates random blog entries in the style of a given blog.

My mental image would be basically to have a form in which the user can paste a URL. What the user should get back is a formatted blog post (maybe even using the right templates), and also html code that they can paste back into their own blogs.

You'll also want to figure out how to retrieve the individual blog posts, perhaps by using a feed-discovery mechanism. The result should be a single post with title, text and maybe even comments. Haskellers, especially newbies, might be particularly interested because it'll give you a chance with the Haskell XML stuff for parsing the RSS, PFP (for the text generation?) and HApps (for the web front-end). Many of the pieces are there. I remember seeing an RSS parser and a random text generator floating about, so it might just be a matter of cobbling things together.

If you're sucessful, you might even kick off one of those memes where people dada their own blogs as a post.

## 2007-02-02

We were discussing on the Haskell fr what it would take to work with UTF-8. Here is an example I cobbled together. Do whatever you want; it's going in the public domain. Note that I've also posted it to the wiki, so please make corrections there if you can.

Note that I don't really know what the best practices are wrt to reading and writing UTF-8, but here's what works for me.

`> module Main where > import Control.Monad (mapM_)> import Data.Word (Word8)> import Foreign.Marshal.Array (allocaArray, peekArray, pokeArray)> import System.Environment (getArgs)> import System.IO (hFileSize, Handle, hGetBuf, hPutBuf, openBinaryFile,>                   IOMode(ReadMode, WriteMode))`

We're going to be using the 2002 UTF-8 implementation by Sven Moritz Hallberg. I don't know if this is the best one, but it's what darcs uses. (I do wonder though, if it's worth turning it into a little library, something like Data.Char.UTF8)

`> import UTF8`

We perform the demonstration on a list of files, specified as command line arguments. What we want to show is that we can both read and write UTF-8, so the demonstration will be of reading a file in, reverse every one of its lines, and writing it back out with the extension '.reversed'

`> main :: IO ()> main =>  do args <- getArgs>     mapM_ reverseUTF8File args > reverseUTF8File :: FilePath -> IO ()> reverseUTF8File f =>   do fb <- readFileBytes f>      case decode fb of>        (cs, []) -> writeFileBytes (f ++ ".reverse") \$ encode \$ reverseLines cs>        (_,  xs) -> fail \$ show xs>   where>     reverseLines = unlines . map reverse . lines`

For this to work, we need to have some helper functions for reading and writing [Word8]. I don't know if this is the right way to go about it.

`> readFileBytes :: FilePath -> IO [Word8]> readFileBytes f =>   do h <- openBinaryFile f ReadMode>      hsize <- fromIntegral `fmap` hFileSize h>      hGetBytes h hsize>> writeFileBytes :: FilePath -> [Word8] -> IO ()> writeFileBytes f ws =>  do h <- openBinaryFile f WriteMode>     hPutBytes h (length ws) ws > hGetBytes :: Handle -> Int -> IO [Word8]> hGetBytes h c = allocaArray c \$ \p ->>                   do c' <- hGetBuf h p c>                      peekArray c' p>> hPutBytes :: Handle -> Int -> [Word8] -> IO ()> hPutBytes h c ws = allocaArray c \$ \p ->>                      do pokeArray p ws>                         hPutBuf h p c`

## 2007-01-31

Think of a monad as a spacesuite full of nuclear waste in the ocean next to a container of apples. now, you can't put oranges in the space suite or the nucelar waste falls in the ocean, *but* the apples are carried around anyway, and you just take what you need. - Dons

Thought an illustration might be useful:

(Yes, yes, I know I have better things to be doing with my time)

## 2007-01-17

### yaht latex now up to date with wiki

YAHT has two versions: a LaTeX one, which produces a nice PDF including margin notes, an index, etc; and a wiki(book) one, which provides an HTML view and instant editing.

The latex (darcs) version was lagging a bit behind the wiki one for a while, but it has now caught up. I'm quite pleased with the results. I have received 3 darcs patches so far, which may not be huge, but is still better than nothing. More importantly, I have observed that people still like going to the PDF version a lot, so we know that keeping that up to date is important. Having YAHT on the wiki has certainly been useful as well. In the two and half months since its wikification, you have not only corrected countless crappy-script-induced-deformations, over a dozen factual errors, and twice as many typos or spelling/grammatical errors. Good work, Haskellers!

Note also that keeping the LaTeX version up to date should now be a lot easier, thanks to (1) a cleaned up and less noisy conversion script (2) stupid darcs tricks. I've got three branches: the (noisy) auto-convered version (latex-to-darcs), a "production" version, which has less noise than the prior, and an MVS version, which pulls in changes from the wiki. The noisy version has some gunk from my scripts that I just have to revert. The MVS version has some changes which only affect noise (errors in where I put my $tags, for example\right), but I can just record these as local patches. Now if somebody modifies the wiki, I just have to do:$
`mvs updatedarcs whatsnew`

This tells me right away if there any changes I need to incorporate in the latex version. We'll have to see how this turns out in practice, but for now it seems we have now averted the danger of forking the YAHT (whew!). As usual, you can either send me patches to the latex version (darcs get http://darcs.haskell.org/yaht) or just edit the wikibook.

## 2007-01-16

### House runs under Parallels

House is an operating system written in Haskell. Ever since CSE380 (titled "Operating Systems") and my many many segfaults, I have deeply impressed with those I call "people who know how computers work". So whenever somebody says "I wrote an operating system!"... I simply marvel.

Anyway, was just sort of fiddling with my computer trying to see if I can get it to run, but I was having the toughest time! The thing boots fine under Q (the qemu front end), but nothing I did could make it work on Parallels. Tried renaming it with .hdd extension, but then I just got a grub prompt with no idea how to proceed. Renaming it to .fdd and connecting it as a floppy wouldn't work, so my first reaction was "oh! it must be some kind of crazy Parallels-specific format", so I kept searching the web and asking on IRC, trying to see if anyone know how to produce Parallels-compatible bootable floppy images...

Well you know what the problem was?

Next to the floppy drive icon [connected to hOp-0.8.fdd] are two checkboxes, Enabled and Connect on Startup. Connect on Startup was unchecked.

Yes eric, you have to put the disk in the drive for it to work... good job!

What a dolt.

### Edit 2006-01-17

Here are a couple of screenshots, as requested. The first is just the Parallels window:

And the second is of the whole desktop (probably a little gratuitous):

If you're having trouble getting this to work on your machine:
1. Rename hOp-0.8.flp to hOp-0.8.fdd
2. Add it as the floppy disk drive to your virtual machine
3. Set the boot sequence to start with the floppy (or at least, have the floppy somewhere)
4. Remember to click that Connect on Setup button next to the floppy config

Parallels might crash the first two times you do this. I have no idea why, but it seems to work after that.

## 2007-01-07

Le nombre d'utilisateurs sur #haskell.fr (irc.freenode.net) a encore doublé. On est 8, maintenant, 8 êtres humains. Je vais noter chaque passage à 2X jusqu'à 32. J'imagine que à partir de cette taille, le channel n'aura plus besoin d'encouragement.

Ick. Eric-French is scary. There's now 8 of us in #haskell.fr (or rather, 8 max) and that's bona fide human beings too. I'm going to note each of these doublings until there's 32 of us. At that point, I figure that we're not going to need anybody blowing on the fire.

Francophone Haskeller? Come on in! And stick around; just put it in your automated login. If #haskell is too busy for you, consider maybe #haskell.fr as a quieter alternative. We want newbies, experts and curious hangers-on alike. It would be especially good if experienced Haskellers hung around, because newbies really should not be taking advice from yellow-belt Eric. Oh, and unless they kick me out, non-native speakers bienvenues.