Final Call for Participation Conference on Intelligent Computer Mathematics CICM 2015 13-17 July 2015 Washington DC, USA Registration Deadline July 6th, 2015 The programme for this year's CICM in Washington can be found as http://www.cicm-conference.org/2015/cicm.php?event=&menu=detailed-programme The accepted papers as http://www.cicm-conference.org/2015/cicm.php?event=&menu=talks In addition we solicit for posters which will not be peer reviewed, but we will just do a screen review for relevance to the conference. A poster presentation will consist of a 5 minute teaser talk and the presentation of the poster on Tuesday morning (together with the other presentations in the Systems/Data/Projects track). You can submit a brief abstract on a poster by 22 June 2015 via EasyChair: https://www.easychair.org/conferences/?conf=cicm2015 You will be informed about acceptance shortly after your submission. Registration to the conference will open shortly. For details on the conference, registration, accommodation, etc. see http://www.cicm-conference.org/2015/cicm.php ********************************************************************** Invited Speakers: ********************************************************************** * Leonardo de Moura, https://leodemoura.github.io/ "Formalizing mathematics using the Lean Theorem Prover" (http://leanprover.github.io/) * Tobias Nipkow, http://www21.in.tum.de/~nipkow/ "Analyzing the Archive of Formal Proofs" * Jim Pitman, http://www.stat.berkeley.edu/~pitman/ "Towards a Global Digital Mathematics Library" * Richard Zanibbi, http://www.cs.rit.edu/~rlaz/ "Math Search for the Masses: Multimodal Search Interfaces and Appearance-Based Retrieval" ********************************************************************** The principal tracks of the conference will be: ********************************************************************** * Calculemus (Symbolic Computation and Mechanised Reasoning) Chair: Jacques Carette * DML (Digital Mathematical Libraries) Chair: Volker Sorge * MKM (Mathematical Knowledge Management) Chair: Cezary Kaliszyk * Systems and Data Chair: Florian Rabe * Doctoral Programme Chair: Umair Siddique Publicity chair is Serge Autexier. The local arrangements are coordinated by the Local Arrangements Chairs, Bruce R. Miller (National Institute of Standards and Technology, USA) and Abdou Youssef (The George Washington University, Washington, D.C.), and the overall programme is organized by the General Programme Chair, Manfred Kerber (U. Birmingham, UK). As in previous years, we have co-located workshops: * Formal Mathematics for Mathematicians * Theorem proving components for Educational software (ThEdu'15) * MathUI Furthermore we have a doctoral programme to mentor doctoral students giving presentations and a tutorial on the generic proof assistant Isabelle. --------------------------------------------------------------------------------

On 20150627 at 143534-0700 "Asmus Freytag (t)" writes: > Unicode generally does not encode characters by usage. For > example there's no distinction between period, decimal > point, abbreviation point etc.. This reflects the underlying > situation, to wit, that this is a case of the *same* symbol > being used in different conventions. > > The downside is that it is thus not possible to use plain > text to capture which convention is intended (but nothing > prevents anyone from providing rich-text markup). The upside > is that data can't exhibit "random alternation" between > identical looking symbols; experience has shown that this is > a most likely outcome if "the same" item is encoded several > times, based merely on convention. Period, decimal point, abbreviation point: three different names and three different concepts commonly sharing the same symbol though not necessarily the same left and right spacing. As a point of argument (but not a request) they *should* be three different characters. Absent that, the typesetter with a proportional font must use various conventions, not completely reliable, to guess the spacing. Of course, commonly the user will be oblivious of these differences and the user's keyboard will have only one of these. But the astute user may want to be able to make distinctions. The distinctions can be made available, for example, in rich text, as you observe, in SGML, or in LaTeX. With a given oblivious user and a given typesetting suite random alternation will not occur. Other than for searching I fail to see why random alternation should be a problem. Are there other problems associated with random alternation? As to mathematical searching, searching for mathematical symbols is an order of magnitude more complicated than searching for text, e.g., multi-character math symbols, things like phi vs varphi, ..., so the small number of possible alternations (at most 256, the size of the U+21xx block, actually quite a few less than that) should not add much complexity to code for mathematical symbol searching. -- Bill