3-7

We have represented here the "exclusion segments" where 𝑓 (𝑋) should not live if we were to prove that some integer 𝑚 is the hardness-to-round of 𝑓 (𝑥). If we think of it

Éléments réglementaires en langue française

Introduction

La conception des bibliothèques d'évaluation de fonctions est un activité complexe qui nécessite beaucoup de soin et d'application, particulièrement lorsque l'on vise des niveaux élevés de fiabilité et de performances.

En pratique et de manière habituelle, on ne peut se livrer à ce travail sans disposer d'outils qui guident le concepteur dans le dédale d'un espace de solutions étendu et complexe mais qui lui garantissent également la correction et la quasi-optimalité de sa production.

Dans l'état actuel de l'art, il nous faut encore plutôt raisonner en termes de « boite à outils » d'où le concepteur doit tirer et combiner des mécanismes de base au mieux de ses objectifs plutôt qu'imaginer que l'on dispose d'un dispositif à même de résoudre automatiquement tous les problèmes. Le présent travail s'attache à la conception et la réalisation de tels outils dans deux domaines:

• la consolidation du test d'arrondi de Ziv utilisé, jusqu'à présent de manière plus ou moins empirique, pour l'implantation des approximations de fonction ;

• le développement d'une implantant de l'algorithme SLZ dans le but de résoudre le « Dilemme du fabricant de table » dans le cas de fonctions ayant pour opérandes et pour résultat approché des nombres flottants en quadruple précision (format Binary64 selon la norme IEEE-754).

Résumé des chapitres

Chapitre introductif

Ce chapitre introduit les notions, notations et définitions qui seront utilisées dans les deux chapitres suivants.

Mieux comprendre et contrôler le test de Ziv

Au cours de ce chapitre nous donnons plusieurs formules permettant de calculer rigoureusement la « Constante de Ziv » utilisée dans le test éponyme, dans plusieurs contextes numériques (lorsqu'on peut effectuer des calculs en précision arbitraire, en présence ou en l'absence de FMA pour effectuer le test, losqu'on calcule en n'utilisant que la « précision de travail »).

Ces formules sont prouvées et leurs conditions d'emploi précisées. Leur optimalité n'est cependant démontrée que dans quelques cas particuliers. Des test numériques permettent cependant de s'assurer de leur quasi-optimalité.

Dans ce chapitre nous mettons en oeuvre des techniques classiques pour résoudre ce genre de problèmes et les difficultés rencontrées sont également très représentatives des celles habituellement rencontrées lorsque l'on travaille dans ce domaine.

La méthode de Coppersmith et le « Dilemme du fabricant de table » (une implémentation de l'algorithme SLZ )

Dans ce chapitre nous décrivons l'implantation de l'algorithme que nous avons réalisée. Nous expliquons également une série d'optimisations que nous avons utilisées pour améliorer de manière significative les performances des calculs.

Au regard de ces améliorations, et d'autres pouvant être encore réalisées, nous évaluons également la pertinence de l'algorithme SLZ pour résoudre le « Dilemme du fabricant de table » lors de l'approximation de fonctions lorsque les opérandes et les résultats (correctement !) arrondis sont des nombres flottants en quadruple précision.

Conclusions

Les principales conclusions de ce travail consistent en :

• des formules pour le calcul de valeurs sûres et efficaces de la constante de Ziv ; cela permet de continuer d'utiliser ce test dans les meilleures conditions et une totale confiance ; le travail effectué en base 2 pourrait également être reconduit, notamment, en base 10 mais nécessiterait certainement une nouvelle étude complète ;

• la mise en oeuvre systématique de l'algorithme SLZ est une première ; son utilisation pour résoudre le « Dilemme du fabricant de table » n'est possible qu'avec de très importants moyens de calcul hors il n'est pas certains que ceux-ci puissent être facilement mobilisés pour une telle tâche ; d'autres avancées, plutôt de nature mathématique, seront probablement nécessaires pour pouvoir résoudre ce problème avec des outils de calcul plus banals.

Tools for the Design of Reliable and Efficient Functions Evaluation

Libraries by

Serge Torres

Submitted to the Éns de Lyon -LIP on 2016-05-31, in partial fulfillment of the requirements for the degree of PhD

Abstract

The design of function evaluation libraries is a complex task that requires a great care and dedication, especially when one wants to satisfy high standards of reliability and performance.

In actual practice, it cannot be correctly performed, as a routine operation, without tools that not only help the designer to find his way in a complex and extended solution space but also to guarantee that his solutions are correct and (almost) optimal. As of the present state of the art, one has to think in terms of "toolbox" from which he can smartly mix-and-match the utensils that fit better his goals rather than expect to have at hand a solve-all automatic device.

The work presented here is dedicated to the design and implementation of such tools in two realms:

• the consolidation of Ziv's1 rounding test that is used, in a more or less empirical way, for the implementation of functions approximation;

• the development of an implementation of the 𝑆𝐿𝑍-algorithm2 in order to solve the Table Maker Dilemma for the function with quad-precision floating point (IEEE-754 Binary128 format) arguments and images.

Acknowledgments

Saying that this work could not have been performed without the help of many people who deserve to be thanked here is an inescapable cliché because it is perfectly true. Better be a poor stylist than ungrateful. Besides, missing the opportunity to express one's gratitude is not only a moral misstep, it is also, for the failed thanksgiver, a personal deprivation of a great pleasure and a great honor.

And there are not so many occasions to write good things about people before their memorial speech as to miss one.

I will start with my advisors, Jean-Michel Muller and Nicolas Brisebarre. Jean-Michel Muller is not only the acclaimed scientist everybody knows, in the floating-point community and beyond, he is also a generous man. He has given a chance into the PhD career to a bunch of improbable contenders, among more regular students, who would not have got this opportunity if it were not because of him. I am proud to be one of these mavericks. Jean-Michel will not only offer the stepping stone: he will make all the journey with you and will not let you down as you stumble.

His knowledge, experience and friendliness breathe the needed confidence it takes to make it to the finish line. Nicolas Brisebarre is also a brilliant scientist and a man "who cares". He especially cares about people and the world around him. A cartoonist would portray him as an oversized extended hand. If you are brave enough to grab it, it will make you climb higher than you ever thought you could. But beware, you will have to do what it takes: it is more about lifting oneself than about being pulled up. Should you slip, his hand grip will comfortingly get firmer. Dealing with him brings many happy returns. Personal ones are not the most insignificant. Early 2016 has given him a hard time during which his stamina and dependability have been inspiring and instrumental in the termination of this work. I wish him many and many more PhD students to come.

I am also deeply in debt with my two reviewers, Pr. Philippe Langlois and Pr. Dominique

Michelucci. I sent them the initial version of my manuscript at the beginning of summer when people are more in a holiday mood than inclined to arid readings. I must first thank them for not taking this dispatch for an hostile move. But they did more than that. In their emails and reviews they raised unaddressed issues, pointed out errors and suggested betterment. The final state of this document, with regard to accuracy and clarity, owes much to their remarks and questions. These have always been formulated in benevolent terms which alleviated the stress always involved in this important step of the evaluation process. For this too I want to express them my gratitude.

I want to mention my lab bosses for the years this work lasted: Gilles Villard and Guillaume

Hanrot. They both have been supportive despite the heavy toll this work took on my schedule at the expense of some of my other duties. They were more than facilitating: they were inspiring and helpful. "Just do it!" is the customary Gilles's answer to those who come to him with some blurry idea, waving all the usual excuses for procrastinating about it. If you can get his point, this is an extraordinary kick. Guillaume could be called a "thoughtful ankylophobic". He wants people and things to keep moving around. But within his deep background and far reaching pondering "moving" has nothing to do with the frantic hustle and bustle so often mistaken nowadays with genuine action.

In some important occasions, Guillaume also was directly helpful with specific aspects of this work.

I cannot overlook my colleagues of the technical and administrative teams of the lab. For one, they are my professional folks, I am one of them and forever will as long as my career lasts. Strangely, and while no one has ever said a word about it, I have always felt accountable towards them for the successful termination of this work. For two, they have always been supportive even when, as it happened more often than they deserved, some work I could not do would fall back on their own shoulders. For three they have been helpful just in the same way they always are with all our regular "customers" (PhD students, faculty, interns. . . ). And, yes, it makes one really comfortable to be on the "other side of the fence" and to know that dependable people are pulling the organizational strings out there.

Another mention for my fellow PhD students with the AriC team. I find it refreshing to acknowledge that they have accepted me as one of them while I have been young long enough to stand somewhere between their fathers and theirs grandfathers! I want to thank them for this welcome. I am not sure I have always responded adequately and this is possibly my single serious regret in all this experience.

Last but not least: Laurence! To put it mildly, she has never been a great fan of this project.

But she has trusted me on this one and I appreciate this trust to its true value. And I also keep remembering that no soothing words will restore my so deeply sunk debit balance. As time will now allow for it, only acts will.

A final work for all those here, in Éns, who have expressed encouragement and helped. In a sense, it is exhilarating to realize that are there so many of them that I cannot recall all the names and all the deeds. My apologies for being so absent-minded and my sincere thanks to everyone.

Lyon, Sep. 2016

List of Tables

Contributions

This dissertation essentially deals with two apparently loosely connected topics:

• Ziv's rounding test: a technique used in function approximation implementation;

• an implementation of the 𝑆𝐿𝑍-algorithm 1 that addresses the resolution of the But the connection is quite obvious when one has the function approximation framework in mind, and especially the problem of implementing correctly rounded functions.

In the introductory chapter, we classically present a minimal set of notions and definitions used in the two other ones in order to make this work essentially self-contained. It can be skipped by readers familiar with floating-point arithmetic applied to the function approximation field.

In Chapter 2, we give a detailed account of our work on Ziv's rounding test. This material has already been published in [START_REF] De Dinechin | On Ziv's Rounding Test[END_REF]. We take advantage here of a less strictly limited space than in a journal paper to give more comprehensive explanations, hopefully easier to follow, than those found in our admittedly rather terse original publication.

The main contribution of our study on Ziv's rounding test is in the sanitation of a technique used for some time now (the original A. Ziv code [START_REF] Ziv | Fast Evaluation of Elementary Mathematical Functions with Correctly Rounded Last Bit[END_REF] goes back to 1991) in the realm of function approximation. The practical result we exhibit is quasi-optimal constant values that can be actually used for the test in different contexts 3 , backed by rigorous proofs.

The other interest of this presentation is in the exposition of techniques routinely used in floatingpoint related reasoning and in an attempt to link them, beyond dry calculations, with the underlying informal insights one can have about the problem.

Chapter 3 is devoted to an implementation of the 𝑆𝐿𝑍-algorithm ( §3.3 and on) and to some results we were able to obtain with it for the exp(𝑥) function ( §3.7 and §3.9). 1 An algorithm designed and first published in 2003, by V. Lefèvre, D. Stehlé, and P. Zimmermann, see [START_REF] Stehlé | Worst Cases and Lattice Reduction[END_REF] and [START_REF] Stehlé | Searching Worst Cases of a One-Variable Function Using Lattice Reduction[END_REF]. 2 Put very informally and in a nutshell, the Table Maker's Dilemma can be stated as: how accurate should an approximation 𝑔 to some function 𝑓 be in order to make sure that we can always compute the correct rounding of 𝑓 (𝑥) to some precision 𝑝 from 𝑔(𝑥)?

3 With and without FMA, with and without arbitrary precision arithmetic.

The from-the-ground-up developed implementation is independent of that mentioned in [START_REF] Stehlé | Worst Cases and Lattice Reduction[END_REF] for we have at hand tools 4 that were not available back then. In §3.6.2 we give an extended example of its behavior. Many more tests than those presented have been performed to check the validity of the code. Those displayed here are exclusively devoted to the exp(𝑥) function and the 113-bit precision. Nevertheless these are only specific input parameters since our implementation can deal with any function 5 our tool base can handle and with any sensible precision.

The parameters chosen for our presented experimental data were aimed to a precise target:

"solve" 6 the Table Maker's Dilemma for the "quad precision" (aka the IEEE 754 binary128 format), with the epitomizing exp(𝑥) function, for this format might become, in a not too distant future, available either in hardware or in efficient software implementations.

More precisely, and beyond the theoretical complexity results obtained for a hardness-to-round in the order of the square of the precision (see [START_REF] Stehlé | Algorithmique de la réduction de réseaux et application à la recherche de pires cas pour l'arrondi de fonctions mathématiques[END_REF]), we have wanted to assess if more realistic values 7 could be practically checked. That kind of work has never been performed before. Our ultimate goal here is to validate a possible scheme (exposed in §3.1) for the development, as of today or very soon, of correctly rounded elementary functions in quadruple precision.

In the end, our conclusion is not fully. . . conclusive! While technically conceivable, the exploration of a function like exp(𝑥) would require the deployment of an extensive computing infrastructure. In our view this situation should spur two kinds of efforts:

• optimize the Coppersmith technique for our particular context 8 ;

• develop alternative mathematical approaches to the Table Maker's Dilemma than those explored so far.

Passing, this work also brings in ( §3. [START_REF] Boneh | Cryptanalysis of RSA with Private Key 𝑑 less than 𝑁 0.292[END_REF].3) a new and dazzling confirmation to the results exposed in [START_REF] Akhavi | Speeding-up Lattice Reduction with Random Projections[END_REF]. In this paper about possible optimizations in the search of a basis for a lattice with some short-norm vectors, the authors show the gains one can expect from using random projection and 𝐿𝐿𝐿-reduction of the projected matrix instead of a straight reduction of the initial matrix representing the lattice, in the so-called "rectangular case". Acknowledging the stunning efficiency 9 of this technique in our particular case, we can only recommend systematically giving it an inexpensive try whenever dealing with Coppersmith-like algorithms.

21

Our test results also indicate ( §3.7.1.3) that the algorithm (or, at the very least, our implementation) does not perform equally well, by a wide margin, under any arbitrary set of parameters. For some of them, the behavior is markedly better. The practical implication is that careful parameter tuning is a vital preliminary step to any tentative large-scale exploration.

By-products of this work are the codes created for the implementation (see [START_REF] Torres | PoBySo: Powered By Sollya, Python-Sage bindings[END_REF]). The two main realized pieces are:

• Sollya10 to Python/SageMath11 integration;

• interval exploration with the 𝑆𝐿𝑍-algorithm for an arbitrary precision and function.

To the moment, both should be considered as research prototypes rather than as off-the-shelf products for general audience use.

Chapter 1

Introduction

Topics and motivations

All the work presented here is, one way or another, related to function approximation. This topic is possibly one of the most overworked in Computer Science since its inception. To make the matter worse to those who only swear by absolute novelty, initial work on function approximation predates by centuries the creation of the first computer (whatever the preferred device of the reader is for the title). And yet, as of 2016, it is a very lively investigation field, with groups of researchers all around the World devoted to, scientific congresses and conferences held on, and articles not only written but even paper printed and read about. Such a topical subject, with deep roots in a wealthy history, necessarily has a special appeal of its own.

The landscape

When people find out that one is working in Computer Arithmetic there is often a moment of puzzlement. What? Problems with numerical computations? Is not this supposed to be the most unquestionable realm of computers? What do we call them "number crunchers" for? There can even be a moment of suspicion. Are not these Computer Arithmetic folks comfortably encrusted in some sinecure at the expense of our hard earned tax cash? It does not get any better if one specifies that she is specifically working on function approximation. The elders remember of their trigonometric and logarithmic tables, the youngsters of their pocket calculators: it is all there, is not it?

This lack of knowledge about pending issues is not limited to the public at large (but who could seriously blame it?). More surprisingly, it is shared by a wide fraction of the technical or even scientific community. If a personal memory is relevant here, the author vividly recalls (nowadays, Chapter 1. Introduction with a bit of shame) his astonishment when, as an already seasoned computer engineer, he joined his current laboratory, fifteen years ago. He then discovered there was a Computer Arithmetic team and the topics it was working on. All right, by 2000, cars did not fly as had been speculated by overenthusiastic futurists, but still in numerical trouble with computations at the break of the 21st

Century? It must be a joke.

We have to acknowledge that there is some truth in the naive views exposed above. Indeed, a lot of work has already been done and achievements are spectacular. Limiting ourselves to recent examples, Higgs's Boson hunt could not have succeeded if computers were performing that bad at numerical tasks. In this realm, as in many others, the "standing on the shoulders of giants" metaphor is perfectly appropriate. Nevertheless many issues are still pending and, worse (or better, depending on one's perspective) new ones pop up at an untamed rate.

We can spot, at least, three driving forces for the need of research in function approximation, to limit ourselves to this question, but without ever forgetting that it is a piece of the much wider "computer numericals" domain.

One is the many-facet evolution of hardware and its use. The improvement of general purpose processors (notably FMA instruction, vector instructions, and soon, rounding mode tagged operations) allows for innovative ways to perform classical computations. The "scissors effect" affecting processing power and memory access performance is also a big incentive for the design of new (or the adaptation of older) algorithms to mitigate it. The widespread use of GPU and innovative architecture chips (e.g. Xeon Phi) for numerical computations rises the pressure for innovation too.

The ubiquity of digital devices powered by a wide range of chips offering limited resources (available electric power, instruction set, memory, etc.) that have to perform function computations impose new designs and the automation of their conception as it has to become routine in order to keep the pace of technological evolution and applications. Last but not least, the soaring use of programmable circuits (e.g. FPGA) challenges our ability to devise the best ways to take advantage of their peculiar (and evolving) architectures for a fast pace growing application domain.

Applications are another pusher. "Explosion" is more appropriate than "Evolution" to describe what is going on in this realm. The question is not anymore "What could applications be?" but rather "Where do digital technologies really not belong?". And the answer is not an easy one. This question is intimately connected with hardware issues and asks for an answer in terms of our ability to quickly give ad hoc solutions. But high-end applications become more and more challenging.

Physical models grow larger, longer time spans without numerical degeneracy are wanted for simu-lations. This involves not only being able to perform computations faster but also getting better a grip on their numerical quality.

For our third pushing force we have chosen to highlight a question that could belong to the application realm as well. But we think it deserves a special attention. It is safety and, more generally, numerical quality control. The widening spectrum of numerical devices and applications has the consequence that more and more of them are used for critical or near-critical applications. This can happen without the designers being really aware of it with the growing complexity emerging from the cooperation of possibly many unrelated but interconnected systems. This problem affects every one, from hardware architects to software builders and gives a particular responsibility to those in charge of the numerical founding blocks. This comes along with an increased demand for certification and stresses our ability to support our quality claims with unquestionable evidence.

All these challenges have to be addressed and this represents a heavy workload for the Computer Arithmetic community and for all those related to these issues. Indeed, one of the present trends is that problems need to be tackled by new approaches for which specialists of different domains have to cooperate.

We reach now the delicate point when one needs to hinge what can only be a limited contribution presented here to the very wide perspectives and general motivations sketched above and, if possible, avoid a harmful clay pot / iron pot clash.

What is this work about?

Our answer comes in four parts. In this overview we will use terms that are not defined yet. We apologize to the reader for our feeble solution to the chicken-egg problem any introduction faces.

Nevertheless all the necessary clarification will be delivered at some point in the sequel.

Function approximation

The scope over which digital computations exactly match mathematical ones is relatively narrow.

When trying to implement a mathematical object and its behavior in a program 1 , one quickly faces the fact that she can not exactly represent them. This is only a half truth if one also considers Computer Algebra, Formal Tools and the quick progresses in these domains. In fact, the above statement stands better when numerical high performance is also required. All that can actually be done, when we can not manipulate the mathematical object, is to use or create a surrogate: an approximation. When it comes to functions, replacing them by approximations is common place.

Among the many arbitrary ways of splitting the function approximation realm in two parts, one is to distinguish the situation where the function is known from that where all we have at hand is a "black-box"2 type function or even a plot made of a finite number of domain × codomain pairs.

In both situations, tools and methods differ, notwithstanding overlaps. In the first case, Approximation Theory prevails. In the second, Interpolation, Extrapolation, Regression Analysis and Curve Fitting are the most often spoken words. This work is entirely relevant to the first situation.

We not only know explicit formulas for the functions we deal with but we also have high accuracy approximations whose main drawbacks are limited performance (computing time) and heavy requirements (hardware, memory consumption, etc.). What we work on are, in a sense, "second order" approximations, to fulfill more limited resources requirements and exhibit decent performance. But they could not be built if it were not for these function initial high accuracy approximation tools (e.g. MPFR [START_REF] Fousse | MPFR: A Multipleprecision Binary Floating-point Library with Correct Rounding[END_REF]).

Another possible ways to bisect the function approximation realm is to make a distinction between univariate and multivariate functions. Work presented here is almost exclusively dedicated to functions of one variable, even if extensions to other cases could be envisioned.

When we refer to function approximation, what we generally have in mind are elementary functions. An elementary function is a function of one variable which is the composition of a finite number of arithmetic operations (+, -, ×, /), exponentials, logarithms, constants, and solutions of algebraic equations (a generalization of 𝑛th roots). A subset of these functions is usually available from the libm-libraries delivered with compilers and those are, by themselves or in composition, the "bread and butter" of scientific computing3

But this work will not deal with function approximation at large. It is focused on a limited number of particular questions, even if all are relevant to function approximation. Let us enter into more details.

Ziv's rounding test

As will be seen in Chap. 2, p. 79, Ziv's Rounding Test is not news. This is a technique that has been in use for years to validate (or not) the result computed by an approximant under the form of two floating-point numbers. The novelty in this work lies in the fact that this technique had never been analyzed in details. It relies on the use of a constant whose optimal value had never been thoroughly investigated. In this work two near-optimal correct bounds are given with a bundle of proofs for correctness (and optimality when specific contexts allow for it) and extra empirical evidence.

This work is part of a larger sanitization effort to "declutter the attic" that aims to revisit pieces of the worthy heritage left by our forerunners and, possibly, fix them (when proofs were not... proofs!), extend them (to other radices, with new instructions such as FMA, etc.) or, regrettably, dump them to the junkyard (when too badly broken).

Quad-Precision and the Table Maker Dilemma

In this part, Chap. 3, p. 135, we reconnect with wide perspectives briefly presented above. At the same time, we do not leave the realm of tool manufacturing. One of the possible improvements in the area of Computer Arithmetic would be the availability of 128-bit floating-point numbers support in hardware. It remains to be seen if manufacturers will incorporate it in a near future, if at all. But there are already software implementations, with variable degrees of compliance with the IEEE 754-2008 standard. There is still room for a dramatic improvement of their performance which is their weakest point. Will betterment reach a point where users will consider to use them extensively?

There are no answers yet.

While all these issues are still in debate, a question pops up to mind: will we be able to use 128-bit floating-point numbers "right", beyond basic operations? More precisely will we be able to build correctly-rounded mathematical libraries for that precision? The answer is important at two different moments. One is, of course, when we get there: when our big-irons are capable to crunch quad-precision numbers (almost) as quickly as they do nowadays with double-precision ones. The other is before that ecstatic day. Do we really need to rush for quad-precision if it is to discover that we can not create the tools to really take advantage of it?

This is where the work presented here comes into play. A prerequisite to building correctly rounded libraries for 128-bit floating-point numbers is our ability to solve the Table Maker Dilemma for that precision. We know for a fact that the current toolset we use to deal with the doubleprecision format will not scale up. We have to explore new avenues. The 𝑆𝐿𝑍-algorithm [102] [START_REF] Stehlé | Searching Worst Cases of a One-Variable Function Using Lattice Reduction[END_REF] is such a novel approach.

Chapter 1. Introduction

Our idea here is twofold:

• develop an implementation of the algorithm;

• try to validate an approach that, without actually solving the TMD, will make it possible to design suboptimal but usable correctly-rounded function approximations.

What comes next in this chapter is, in part, what was missed in the introduction bits. We present the necessary concepts to get with the subsequent chapters. Nothing particularly new should be expected here and we will try to limit ourselves to what is absolutely necessary.

To begin with, we will get back where it all started: the womb of the floating-number beast.

Floating-point numbers: a world of their own

It is nowadays common knowledge that the finite representation of numbers in computers sets up a whole range of issues and that machine floating-point numbers should not indiscriminately be manipulated as elements of R are unless one is seriously looking for trouble.

Floating-point representation of numbers, as per IEEE 754-2008 standard (see [START_REF]IEEE 754-2008, Standard for Floating-Point Arithmetic[END_REF]), is widely accepted and most (if not all) of the modern processors offer efficient and compliant machine instructions to process them. It has become the de facto standard for number crunching applications.

A key operation when dealing with these floating-point numbers and which can be blamed as the source of (most of 4 ) all evil in their use is rounding.

According to the Rounding article of Wikipedia, rounding a numerical value means:

replacing it by another value that is approximately equal but has a shorter, simpler, or more explicit representation. . .

The article goes on with the following example: replacing. . . √ 2 by 1.414.

that epitomizes what is constantly done in scientific computing. 4 Arithmetic exceptions should not be overlooked. To mitigate our statement, it must be said that rounding functions are a great progress: instead of returning some result "not-too-far", in a very fuzzy sense, from the exact value, the concept of function conveys with itself the notion of a specification of the difference between the exact and the returned value.

One must notice that rounding does not only take place for the representation of irrational numbers constants or that of experimental data. Rounding is performed after almost any of the basic arithmetic operations {+, -, ×, /} (it is common, as in the IEEE-754 standard, to append √ to this set) whenever the exact result does not fit into the fixed format of the target representation. Not to speak about rounding when elementary functions (and combinations thereof) are computed. As such, rounding happens every time and everywhere along any non trivial computation.

Let us take a look to a simple example on how things can quickly get weird, even with a short program that toys around with 1.1, 1.0, 0.1 values, addition and subtraction. The output of this program is:

(1.1 -1) != 0.1 (1.1 -1) != 0.1 but 1.1 == 1 + 0.1 (1.1 -1) != 0.1 but (1 + (1.1 -1)) == (1 + 0.1)
This is a lot of violations of usual arithmetic rules for such a small piece of code.

Chapter 1. Introduction

There are many situations where floating-point number computations can go totally out of control (no single digit in the result is valid) if some (sometimes, great) care is not taken. Correct (accurate) use of floating-point numbers can lead to quite counter-intuitive algorithms.

From the early days of numerical computing, a large and fruitful research effort has been dedicated to their correct and yet efficient use. It has produced the huge body of results that have allowed for the present situation of general pervasiveness of numerical computations in all realms of science (even Humanities!) and engineering.

Computer scientists, numerical analysts and users have always wanted to quantify the divergence of actual computer calculations from their exact mathematical counterparts. This is the starting point of error analysis where one tries to figure out how rounding errors show up and accumulate along computations to evaluate the quality (or lack thereof) of a numerical algorithm or a piece of code.

Floating-point numbers, as defined in the IEEE 754-2008 standard should not only be considered as mere crippled real numbers but as true mathematical objects, with their peculiar (and sometimes disconcerting) properties, as a world of their own. This is why we will spend some time to present the properties of the IEEE 754-2008 standard, not striving for completeness but trying to limit ourselves to what is really useful to grasp what this work is about. For a full-blown description and analysis one could consider giving a hard look to [START_REF] Muller | Handbook of Floating-Point Arithmetic[END_REF].

Basic Notions and Definitions

Floating-point numbers

A floating-point representation of numbers is made of a series of parameters and a set of rules that considered together define what we will call here a "Floating-point format" 5 . In particular, for the standard parameters, the set of numbers defined by the format is finite.

We are going to build a floating-point number step by step, one piece at a time. Basically, and commonly 6 , a floating-point number can be seen as the signed product of two positive numbers: a fixed size integer and a rational number The first parameter of a floating-point format is the radix, a positive nonzero integer larger than 1, hereby denoted by 𝛽. It plays two roles. For one, it is the radix of the numeral system the integral number is written in.

± fixed_size_integer × rational_scaling_factor.
The second role is that, raised to some integer power, it will form the scaling factor of the floating-point number, ± integral_significand × 𝛽 𝑒 , with integral_significand expressed in base 𝛽 and 𝑒 ∈ Z.

The second parameter of a floating-point format is the precision, denoted by 𝑝. It is the number of digits the integral significand is made of:

𝑀 = 𝑀 𝑝-1 . . . 𝑀 0 , 0 𝑀 𝑖 < 𝛽, 𝛽 ∈ N ∖ {0, 1}, 𝑖 ∈ {0, . . . , 𝑝 -1}.
Indexing the digits from right to left allows us to say that digit 𝑀 𝑖 has weight 𝛽 𝑖 . The values spanned by 𝑀 are the integers in {0, . . . , 𝛽 𝑝 -1}.

To summarize and roughly speaking, a precision-𝑝 and radix-𝛽 floating-point number 𝑋 can be represented as:

𝑋 = ± 𝑀 × 𝛽 𝑒 ,
where 𝛽 is the radix, 𝑀 is 𝑋's integral significand and 𝑒 is the 𝑋's exponent corresponding to 𝑀8 .

Notice that, to the moment, this fuzzy idea of what a floating-number is does not convey the notion of finite set of numbers since the exponent 𝑒 can take arbitrary values. To settle the matter, bounds must be enforced on 𝑒.

Let us enter into more details.

Definition 1.1. A floating-point format is (partially) 9 characterized by four integers:

• a radix (or base), 𝛽 ∈ N and 𝛽 2;

• a precision, 𝑝 ∈ N and 𝑝 2 (roughly speaking, 𝑝 is the number of "significant digits" of the representation and sets one of the bounds for its finiteness);

• two extremal exponents: 𝑒 min ∈ Z and 𝑒 max ∈ Z such that:

-𝑒 min < 𝑒 max ,
-𝑒 min > -∞ and 𝑒 max < +∞ , which seals the finiteness property, in all practical cases 𝑒 min < 0 < 𝑒 max .

We will often denote such a format by F 𝛽,𝑝,𝑒min,𝑒max or as F, if the context allows for it, with the doubtful hope that the compactness of this notation will forgive for its ugliness. From time to time, we will also abuse a bit our notation by using F as the set of the finite numbers 10 which are defined by the format, a subset of Q.

A floating-point number 𝑋 representing a finite numerical value in such a format is a number for which there exists at least one representation (𝑀 ,𝑒) such that

𝑋 = ±𝑀 × 𝛽 𝑒-𝑝+1 , (1.1)
where:

• 𝑀 ∈ N and 𝑀 𝛽 𝑝 -1;

• 𝑒 ∈ Z and 𝑒 min 𝑒 𝑒 max , is called the exponent of the representation of 𝑋.

We do just recall here that this representation is also signed but since this is a general property of floating-point formats it is not systematically mentioned.

Up to this point, the representation of a number is not necessarily unique. To illustrate that, let us consider the following "toy format": F 2,4,-7,8 (radix: 𝛽 = 2; precision: 𝑝 = 4; minimum exponent: 𝑒 min = -7; maximum exponent: 𝑒 max = 8). In this format, number 8 can receive different representations such as: 9 The full definition of a format also specifies the binary encoding of the significands and exponents. It also deals with special values: infinities, results of invalid operations, etc. 10 As we will see, we will append special notations to denote infinities and other special values. Finite numerical values are those that do not refer to these special cases.

• (+,1,6): 1 × 2 6-4+1 = 8;

• (+,2,5): 2 × 2 5-4+1 = 8;

• (+,4,4): 4 × 2 4-4+1 = 8;

• and so forth. . . The set of all these equivalent representations is called a cohort.

Number 𝛽 𝑒-𝑝+1 is called the quantum of the representation of 𝑋.
This state of things may not always be desirable. In fact there are many and diverse reasons why we may want to set an extra rule that allows for one, and only one, representation for a number.

We give here two examples:

• if we only allow for one representation of a floating-point number, we can have the notion of "the" exponent of a number; in turn, this will allow us to conveniently define concepts as the unit in the last place of a number, whose definition will be given below ( §1.4.1, p. 39) and is very useful to make reasoning about errors ;

• the authors of the IEEE 754 standards put a lot of dedication into crafting the numbers encoding scheme so that it exhibits interesting properties; one is, for instance, that numbers ordering is consistent with the lexicographic order of their representation; this is extremely convenient if we are to have efficient comparisons; allowing for multiple representations of a number would break this consistency; another one is that if we view representations as integers, that of the successor of some floating-point number can be obtained by adding 1 to the representation of the latter.

Normalization also brings in its own share of problems 11 . But, all in all, normalizers felt the advantages outweighed inconveniences. Hence format is specified further to allow only for a single representation of a number that will be called its normalized representation.

Normalized representation

Among the previous different representations we could pick the one, if it exists, such that:

𝛽 𝑝-1 𝑀 𝛽 𝑝 -1.
In our toy format F 2,4,-7,8 : 8 𝑀 15.

With this convention, the favorite representation of number 8 would be (+,8,3):

8 × 2 3-4+1 = 8.
Notice that 2 -10 does not have such a representation. Even using the smallest possible exponent (𝑒 min = -7), what yields 𝛽 𝑒min = 2 -7 in our example, there is no integer 𝑀 such that 𝑀 × 2 -7-4+1 = 2 -10 and 𝑀 8. As seen above, the smallest allowed value for 𝑀 in this case is 2 3 . The smallest positive number that has a representation conforming to our conventions is 2 -7 :

2 3 × 2 -7-4+1 = 2 -7
. Nevertheless, 2 -10 has the following denormalized representation (+,1,-7):

1 × 2 -7-4+1 = 2 -10
. It is the smallest non zero positive number one can represent in this format.

In this floating-point format, 8 will be called a normal number and 2 -10 a subnormal number (sometimes also called a denormalized number ).

From there, the representation of a normal number 𝑋 could take form of a triplet (𝑠,𝑚,𝑒) such that:

𝑋 = (-1) 𝑠 × 𝑚 × 𝛽 𝑒 ,
where:

• 𝑒 ∈ Z is the same as before, "The" exponent (but this time with a capital "T");

• 𝑚 = 𝑀 × 𝛽 1-𝑝 is called the normal significand or, in short, the significand12 of the representation; it has one digit before the fractional point, and at most 𝑝 -1 digits after it; also notice that 1 𝑚 < 𝛽 and that 𝑚 is a rational number;

• 𝑠 ∈ {0, 1} is the bit sign of 𝑋 (its sign is (-1) 𝑠 ).

A collateral benefit is that, in radix-2 formats, the first digit of the significand of a normal number is always 1 so it does not need to be stored. It is a way to save one bit in encoding. This technique is called many names: leading bit convention, implicit bit convention, hidden bit convention.

The significand is also frequently (though slightly improperly) called the mantissa 13 .

For a given floating-point format, the numbers that can be represented in a (unique) normalized form will be called normal numbers.

Whe can also define some usefull values: 𝜔 = 𝛽 𝑒𝑚𝑖𝑛 is the smallest absolute value for a normal floating-point number in F; Ω = (𝛽 𝑝 -1) 𝛽 𝑒max-𝑝+1 is the largest normal floating-point number in F.

With the previous normalization convention 14 , one quickly sees that there is no normalized way to express number 0, which is, at the very least, embarrassing. We will deal with it later ( §1.3.4, p. 37).

Subnormal numbers

For implementation reasons 15 , it would be very tempting to limit the set of the floating-point numbers to those that can have a normalized representation. But a less obvious problem arises: a very sharp cut-off effect for the very small absolute values. With the round-to-nearest rounding mode, all the values smaller than 𝛽 𝑒min 2 will be rounded to 0.

Subnormal numbers are our children too

An alternative is to allow for subnormal numbers. This has the first beneficial effect of allowing for what W. Kahan calls a gradual underflow : loss of precision is progressive instead of being abrupt.

It also has an unexpected interesting property: if 𝑋 ̸ = 𝑌 , with 𝑋 ∈ F and 𝑌 ∈ F then the computed value of 𝑋 -𝑌 ̸ = 0. This even applies to subnormal numbers! See Figure 1-1.

When the first version of the IEEE 754 standard was published in 1985, allowing for subnormal numbers was a controversial decision. The terms of the debate were, on the one hand, the difficulty of an implementation in hardware (or conversely the performance impact if implemented in software), and, on the other hand, the beneficial properties brought by the availability of subnormal numbers:

ease of development of stable numerical software in some fields, weakening the conditions for some important results as the Sterben'z lemma [START_REF] Sterbenz | Floating-point computation[END_REF].

Underflow

The term can be ambiguous in a variety of ways. A definition that springs to mind is that underflow happens whenever the exact result of an arithmetic operation has an absolute value smaller than the 14 Notice that the IEEE 754-2008 standard requires a normalized representation in radix 2 but not in radix 10. In the sequel, we will mostly interested in the former case. 15 As we will see in the part dedicated to IEEE 754-2008 standard, taking subnormal numbers into account leads to a more intricate encoding and, as their implementation is often realized in software, an adverse performance impact is incurred when they show up in a computation. This is not always the case: see [START_REF] Raina | FLIP: a Floating-Point Library for Integer Processors[END_REF], p. 39-40 or [START_REF]A floating-point library for integer processors[END_REF] for counterexamples.

Figure 1-1: Life near 0 with and without subnormal numbers in our toy floatingpoint system. In the first case there are still numbers between 0 and 2 -7 , the smallest normal number, and the subtraction of two different nonzero numbers never yields 0 in the rounding-to-nearest mode. This remains true even if the numbers are both picked from the subnormal set. In the second case, the subtraction of two close and small normal numbers may yield 0. Incidentally, we also have the following interesting property: the sum of two subnormal numbers is always exact. smallest nonzero representable number. This is supposed to include subnormal numbers, if they are available. If it were the case underflow would relate to absolute values smaller than 𝛽 𝑒min-𝑝+1 . But this is not the definition adopted by the successive IEEE 754-1985 andIEEE 754-2008 standards.

Here, underflow is defined in reference to the smallest normal number, 𝛽 𝑒min . But to make the situation more confusing there are indeed two different definitions of underflow and none of the standards made a choice about them. Definition 1.2. Underflow before rounding.

In radix-𝛽, an arithmetic operation or function underflows if the exact result of that operation or function is of absolute value strictly less than 𝛽 𝑒min . Definition 1.3. Underflow after rounding.

In radix-𝛽, precision-𝑝 arithmetic, an arithmetic operation or function underflows if the result we would compute with an unbounded exponent range and precision 𝑝 would be nonzero and of absolute value strictly less than 𝛽 𝑒min .

In practical terms, they only differ on very narrow interval between 𝛽 𝑒min and its preceding floating-point number 16 whose exact location and width depend on the rounding mode. 16 If subnormal numbers are available.

We must also notice that, when it comes to actual behavior of a IEEE 754 floating-point implementation, an underflow is signaled (the underflow flag is raised) only if the computed result is inexact. The rationale is that an underflow matters to the user as it indicates that the relative error of the result might be larger than usual. If the computed value is exact, there is not point in needlessly bothering the user.

Normal and subnormal range

We will call normal range the set of real numbers whose absolute value belongs to the [𝜔, Ω] interval over R.

Along the same lines, we will call subnormal range the set of real numbers whose absolute value belongs to the [0, 𝜔) interval over R.

Special floating-point data

We use here the more generic "data" term rather than "numbers" because some of our special items can not strictly be considered as "numeric". Why are these data needed? The main reason is that we want floating-point numbers to be a stable set: any machine operation has to be well defined 17and return a floating-point datum. Having a "closed" system has two main advantages:

• it is a must for portability (there should be no case where the results returned by two different implementations diverge);

• it helps for reasoning about floating-point numbers whenever everything is well defined.

One obviously needed element is a datum to represent values whose magnitude is larger (resp. smaller) than that of the largest (resp. smallest) representable floating-point number. Conceptually this can be done in different ways: as an infinity "absolute value" (∞) that can be signed to denote both situations or, directly, as two signed infinities (-∞ and +∞). The latter convention is adopted in the IEEE 754-2008 standard. Moreover, the binary representation is built in such a way that the conceptual difference mentioned above has no impact on how things are done in practice: in binary representation, -∞ and +∞ only differ by the leading sign bit.

As the reader may remember, we had no way to give a normalized representation for 0. As a consequence of the previous choice on infinities and for symmetry reasons (

1 +0 = +∞ and 1 -0 = -∞ ) ,
signed zeros (-0 and +0) have also been appended. For a more in-depth discussion the reader may refer to [START_REF] Kahan | Branch Cuts for Complex Elementary Functions, or Much Ado About Nothing's Sign Bit[END_REF].

Eventually any operation over the floating-point numbers, however invalid over the real ones ( e.g. √ -5 or 0 0

) , should output a result. The result of an invalid operation will be represented by a special datum, denoted by NaN (for Not a Number ) in IEEE 754-1985 standard and successor, specifically devised for this purpose. As a matter of fact, two kinds of NaNs are defined by the standards: quiet NaN (qNaN) and signaling NaN (sNaN). A complete explanation can be found in [START_REF] Muller | Handbook of Floating-Point Arithmetic[END_REF].

We have to acknowledge the fact that the introduction of special floating-point data also brings in its own burden of issues. What should be returned when special values such as -∞, +∞ or NaN are themselves the arguments of an operation or a function is still debated for some cases.

Sometimes more or less arbitrary decisions have to be taken: in IEEE 754-2008 pow(qNaN,0) and pow(1,qNaN) should both return 1 since that is what the function pow does when qNaN is replaced by any other floating-point number (sNaN excluded) in the above expressions. While this adds up to the arcane reputation of floating-point "theory", all in all, the introduction of special values is unquestionably beneficial.

F as a finite and (almost) ordered set

F, as we have defined it, is always a finite set. If we exclude NaN's and make a particular case of signed zeroes, this set is totally ordered. For each (but -∞) floating-point number 𝑋 we can then have notion of the (unique) predecessor of 𝑋 (denoted here as 𝑋 -). Similarly, for each (but +∞)

floating-point number 𝑋 we can have the notion of the (unique) successor of 𝑋 (denoted here by

𝑋 + ).
This allows us to represent F as a graduated ruler over the R axis. We will very often add extra graduations to represent, for instance, midpoints. These are the numbers that represent the center of the interval defined by two consecutive elements of F. They themselves are not elements of F and should not be confused with them. But they are instrumental for reasoning about rounding.

The ulp() function

When dealing with floating-point number operations, one is constantly worried about errors between exact values and rounded (or approximated) ones. Conceptually, we make a distinction between relative errors and absolute errors.

If 𝑋 ∈ F is an approximation of 𝑥 ∈ R they are defined as follows:

Definition 1.4. Absolute error:

𝜖 𝑎𝑏𝑠 = |𝑋 -𝑥|.
Definition 1.5. Relative error:

𝜖 𝑟𝑒ℓ = ⃒ ⃒ ⃒ ⃒ 𝑋 -𝑥 𝑥 ⃒ ⃒ ⃒ ⃒ , if 𝑥 ̸ = 0. If 𝑋 = 𝑥 = 0 then 𝜖 𝑟𝑒ℓ = 0.
This distinction is of course of paramount importance. Nevertheless there are situations where one would like to discuss about "parametrized" absolute errors. In other words, absolute errors whose value depends on the context.

Definitions

The ulp() function is such a tool. This concept has a somewhat complicated story. See [START_REF] Muller | Handbook of Floating-Point Arithmetic[END_REF] §2.3.1 for an in-depth discussion about this topic. In the sequel we will stick to the option selected in this reference: we will use Goldberg's [START_REF] Goldberg | What Every Ccomputer Scientist Should Know About Floating-Point arithmetic[END_REF] definition extended to real numbers, since it is the most widely used.

Let us start with the original Goldberg's definition of the units in the last place. This definition has the following limitations:

• it defines the number of units in the last place for a (floating-point, real number) pair and not as an intrinsic attribute of a (real) number, for a given floating-point system F;

• it does not take subnormal numbers into account.

But from this definition we can derive the following one, more fit to our purposes. • consider first the normal number √

2; ulp( √ 2) = 2 -3 since -2 0 √ 2 < 2 1 , -(𝑒 min = -7) (0 = 𝑒 √ 2 ), -2 0-4+1 = 2 -3 ;
• consider now the subnormal number 2 -12 ; ulp(2

-12 ) = 2 -10 since -2 -12 2 -12 < 2 -11 , -max(-12,-7) = -7, -2 -7-4+1 = 2 -10 .
The situation is often a bit complex around the integer powers of the radix 𝛽 𝑘 , 𝑘 ∈ Z, elements of F: there is a sharp change in the value of the ulp() function.

Figure 1-2 depicts such a the situation in radix-2.

Figure 1-2: For a radix-2 floating-point system, in the neighborhood of a power of 2, the value of the ulp() function experiences a sharp change: it doubles when reaching 2 𝑘 "from the left". It remains constant over subsets called binades. Also notice how the distance to midpoints also changes making a power of 2 a particular case: its "left" midpoint neighbor is twice as close as its "right" one. This gives an idea as why, in proofs, powers of 2 often have to be dealt with as a separated case.

Some interesting properties

For 𝑋 ∈ F and 𝑥 ∈ R, we have the following properties.

Property 1.1. In radix-2,

|𝑋 -𝑥| < 1 2 ulp(𝑥) ⇒ 𝑋 = RN(𝑥),
where RN() denotes the round-to-nearest function that will be formally defined in §1.5.2, p. [START_REF] Horner | A new method of solving numerical equations of all orders, by continuous approximation[END_REF].

Notice that we are reasoning here over ulp(𝑥). This property holds even if 𝑋 is a power of 2.

Depending on the relative position of 𝑥 to 𝑋, the value of ulp(𝑥) "self-adjusts" accordingly in order to make the property hold.

Property 1.2. For any radix 𝛽, and as long as 𝑋 is not a power of 𝛽,

|𝑋 -𝑥| < 1 2 ulp(𝑋) ⇒ 𝑋 = RN(𝑥).
In contrast to the previous property, as we reason over ulp(𝑋), we must exclude the 𝑋 = 𝛽 𝑘 , 𝑘 ∈ Z case.

Property 1.3. For any radix,

𝑋 = RN(𝑥) ⇒ |𝑋 -𝑥| ≤ 1 2 ulp(𝑥).
Again, ulp(𝑥) adapts to the right value whatever the value of 𝑋 is (including a power of 𝛽).

Property 1.4. For any radix,

𝑋 = RN(𝑥) ⇒ |𝑋 -𝑥| ≤ 1 2 ulp(𝑋).
Notice here that the 1 2 ulp(𝑋) bound is partly an overestimation when 𝑋 is a normal number and an integer power of 𝛽. If both 𝑥 and 𝑋 are positive (the both negative case is similar) and 𝑋

is an integer power of 𝛽, if 𝑥 𝑋 then 𝑋 = RN(𝑥) ⇒ |𝑋 -𝑥| 1 4 ulp(𝑋).

Binades and the ulp() function

A binade is the interval between two consecutive powers of 2. More precisely:

[2 𝑘 , 2 𝑘+1
), where 𝑘 ∈ Z, is a binade.

Notice how we exclude the upper bound from the interval. The reason for it will become obvious in the sequel.

We will often refer to a binade by its lower bound or even only by the exponent of this lower bound: "the 2 4 binade" expression or even shorter, "the 4-binade" expression both denote the [2 4 , 2 5 ) binade. Conversely, 4 will be said to be the exponent of the 4-binade.

If 2 𝑘 𝑥 < 2 𝑘+1 , 𝑥 ∈ R, 𝑘 ∈ Z, we will say that "𝑥 belongs to the 2 𝑘 binade" or that "𝑘 is the binade of 𝑥".

From that we can define a binade() function. If we denote by ⌊𝑥⌋ the value of the floor(𝑥) function, binade(𝑥) = ⌊log 2 (𝑥)⌋. This definition is compatible with the exclusion of the upper bound of the interval. The function is defined over the nonzero positive real numbers. It can be extended to the nonzero negative numbers as well if applied to abs(𝑥) instead of 𝑥.

For a F 2,𝑝,𝑒min,𝑒max floating-point system, the elements of F that belong to the same 2 𝑘 binade are evenly spaced (as depicted in Figure 1-3 for our toy example). If we generalize the notion of binade to that of "𝛽-ade" (as interval [𝛽 𝑘 , 𝛽 𝑘+1 ), 𝑘 ∈ Z), this even spacing property of floating-point numbers in radix 𝛽 inside each "𝛽-ade" is conserved.

Figure 1-3: Elements of our F 2,4,-7,8 toy floating-point format spanning two binades, 2 3 and 2 4 , are represented here. Notice how the distance between the elements of the same binade is constant and doubles when we move from one binade to the next. In our examples, for binade 2 𝑘 it computes as 2 𝑘-4+1 = ulp(2 𝑘 ). For binade 2 3 , ulp(2 3 ) = 1 and for binade binade 2 4 , ulp(2 4 ) = 2.

As stated before, the ulp() function is also defined for the interval spanned by the subnormal numbers [0, 𝛽 𝑒min ). The distance between two successive numbers is constant over this interval and its value is 𝛽 𝑒min-𝑝+1 . Nevertheless, this interval is not a binade. It spans over an infinity of them! Notice that while the value of the ulp() function is constant over a binade, this not the case for the relative error ulp(𝑋) 𝑋 , with 𝑋 ∈ F. For normal numbers, it decreases from 2 -𝑝+1 , for the smallest element of the binade, to almost 2 -𝑝+2 , for the largest one.

In the subnormal numbers realm considered as a whole, ulp(𝑋) 𝑋 decreases from 1 (!), for the smallest nonzero subnormal number, to almost 2 -𝑝+1 , for the largest one.

Converting error in ulps to/from relative error

Let us see how absolute errors in ulps help us to build a bridge between absolute and relative errors.

Notice that we will have to think in terms of bounds since the value of the ulp() function is the same for all the numbers of the same binade whereas their absolute value continually varies.

Assume first that 𝑋 ∈ F approximates some 𝑥 ∈ R and 𝑥 ∈ [𝛽 𝑒 , 𝛽 𝑒+1 ).

Let us examine first the conversion from the error in ulps to the relative error, assuming that

𝜖 𝑎𝑏𝑠 = |𝑋 -𝑥|.
We can always rewrite this absolute error in ulp terms as:

𝜖 𝑎𝑏𝑠 = 𝛼 × ulp(𝑥).
Assuming no underflow, we can write: 𝛼 × ulp(𝑥) = 𝛼 × 𝛽 𝑒-𝑝+1 .

From our initial assumptions, we have |𝑥| ≥ 𝛽 𝑒 .

Hence:

⃒ ⃒ ⃒ ⃒ 𝑋 -𝑥 𝑥 ⃒ ⃒ ⃒ ⃒ = ⃒ ⃒ ⃒ ⃒ 𝛼 × 𝛽 𝑒-𝑝+1 𝑥 ⃒ ⃒ ⃒ ⃒ ≤ 𝛼 × 𝛽 𝑒-𝑝+1 𝛽 𝑒 = 𝛼 × 𝛽 -𝑝+1 .
Let us examine how it works the other way around, assuming that

𝜖 𝑟𝑒ℓ = ⃒ ⃒ ⃒ ⃒ 𝑋 -𝑥 𝑥 ⃒ ⃒ ⃒ ⃒ .
Assuming again no underflow, we can state that

|𝑋 -𝑥| 𝛽 𝑒+1 ≤ ⃒ ⃒ ⃒ ⃒ 𝑋 -𝑥 𝑥 ⃒ ⃒ ⃒ ⃒ = 𝜖 𝑟𝑒ℓ . Hence: |𝑋 -𝑥| 𝛽 𝑒+1 × 𝛽 𝑒-𝑝+1 ≤ 𝜖 𝑟𝑒ℓ × 𝛽 𝑒-𝑝+1 = 𝜖 𝑟𝑒ℓ × ulp(𝑥). Finally: |𝑋 -𝑥| ≤ 𝜖 𝑟𝑒ℓ × 𝛽 𝑝 × ulp(𝑥).
Expressing errors in ulp's is the usual way for floating-point arithmetic operations and functions.

Relative errors are much easier to deal with when performing error calculations. Being able to switch easily between both representations is therefore very convenient. But one must remind that some information is lost along the way. Hence moving back and forth between error in ulps and relative errors is not advisable in error analysis.

Rounding

Given the importance of this operation (in general, when dealing with floating-point numbers, and in this work as well), we feel compelled to enter into more details about it and introduce some notions that are closely associated with it.

Rounding functions

Rounding is a routine operation when dealing with finite number representation, of which floatingpoint numbers is a particular case.

To start with, many numbers often used in computations (e.g. constant 𝜋) do not have an exact representation in the floating-point numbers.

Moreover, the result of an operation or of the evaluation of a function, even if performed over the floating-point numbers, will often be a value that can not be exactly represented by a floating-point number.

In all cases, one will have to replace them by some approximating floating-point value. This operation is called rounding. Let us denote it by the ∘ symbol. If 𝑥 ∈ R is some number not representable in a given floating-point system F, 𝑋 = ∘(𝑥) will be the floating-point number resulting

from rounding. Of course, if 𝑥 is representable in F then 𝑋 = ∘(𝑥) = 𝑥;
Historically, the ∘ operation was not always fully specified and could not technically be called a function. For a given 𝑥 and F the result could vary from an implementation to another. If several numbers 𝑥 1 , 𝑥 2 , 𝑥 3 . . . , 𝑥 𝑛 were considered the order of ∘(𝑥 𝑖 ) and 𝑥 𝑖 and the relative error

⃒ ⃒ ⃒ ⃒ ∘(𝑥) -𝑥 𝑥 ⃒ ⃒ ⃒ ⃒ could vary in inconsistent ways.
That is why the advent of IEEE 754-1985 helped to level the ground, in particular with the concept of rounding modes. It allowed for an exact specification of how any numerical value is rounded to a finite (well, including here the -∞ and +∞ values) floating-point number. Rounding modes are functions and we will stick to the convention of denoting them by ∘.

Some definitions

Many rounding modes can be imagined. Four appear in the IEEE 745-2008:

• round toward -∞ or "round down": RD(𝑥) = max 𝑋 ∈ F (𝑋 𝑥); RD(𝑥) is the largest floating-point number (possibly -∞) less than or equal to 𝑥;

Rounding

• round toward +∞ or "round up": RU(𝑥) = min 𝑋 ∈ F (𝑋 𝑥); RU(𝑥) is the smallest floating-point number (possibly +∞) greater than or equal to 𝑥.

• round toward 0:

-if 𝑥 0: RZ(𝑥) = RD(𝑥), -if 𝑥 0: RZ(𝑥) = RU(𝑥);
RZ(𝑥) is the closest floating-point number to 𝑥 that is no greater in magnitude than 𝑥;

• round-to-nearest:

-RN(𝑥) = 𝑋 ∈ F such that |𝑋 -𝑥| is minimal; then such 𝑋 is unique;

if there are two consecutive elements of F, 𝑋 𝑙 and 𝑋 𝑢 , such that |𝑋 𝑙 -𝑥| = |𝑋 𝑢 -𝑥|, then a tie-breaking rule is necessary to select which of the two, 𝑋 𝑙 or 𝑋 𝑢 , will be returned.

The different modes are illustrated in Figure 1234.

Figure 1-4: The four rounding modes of the IEEE 754-2008 standard [START_REF]IEEE 754-2008, Standard for Floating-Point Arithmetic[END_REF] are illustrated here. We assume here that both 𝑥 and 𝑦 are positive members. Midpoints are not elements of F. They are only shown here to justify the choices for RN(𝑥) and RN(𝑦).

For reasons that will soon become obvious, round-to-nearest is of special interest to us. This is why, and because the round-to-nearest mode is not fully specified without it, we will go into more details about the tie-breaking rules. The IEEE 754-2008 standard [START_REF]IEEE 754-2008, Standard for Floating-Point Arithmetic[END_REF] has chosen the so called round-to-nearest, tie-break to even rule as its default mode. It works as follows: since 𝑋 𝑙 and 𝑋 𝑢 are consecutive numbers, the integral significand corresponding to their representation 18 are alternatively even or odd (or the other way round). In case of a tie, it is the number with the even integral significand that will be returned. The standard makes its availability mandatory for both radix-2 and radix-10 implementations. This is not the only possible choice. One could have taken the symmetrical rule (round-to-nearest odd ). The IEEE 754-2008 standard [START_REF]IEEE 754-2008, Standard for Floating-Point Arithmetic[END_REF] defines another tie-breaking rule called round ties to away:

in the case of a tie, the value with the largest absolute value is returned. The standard make its availability mandatory for radix-10 implementations. It is not the case for binary implementations as this rule is often used in financial computations, the main target of radix-10 implementations.

In the sequel, when we will refer to the "round-to-nearest mode" denoted by RN()), it will always be in its "round-to-nearest even" version, unless otherwise stated of course.

Not any idea of tie-breaking rule that pops to mind can be a useful one. Some properties may be desirable such as symmetry (RN( -𝑥) = -RN(𝑥)), the lack of statistical bias, the ease of implementation, and reproducibility.

Rounding function properties

For any of the given rounding modes, it is easy to see that a rounding function defined over R is a step or staircase function. The value of the function is constant over some interval and suddenly changes at or immediately beyond the interval bounds. We will call these sudden change points rounding breakpoints or more briefly breakpoints. Notice that breakpoints may (in the case of rounding to both infinities or to 0) be elements of F or may not (in the case of round-to-nearest). As we have seen, in the latter case, they are called midpoints. We can define the midpoint function as

midpoint(𝑌, 𝑌 + ) = 𝑌 + 𝑌 + 2 .
where 𝑌 and 𝑌 + are numerical values floating-point numbers (i.e. not a special datum as NaN) and 𝑌 + is the successor of 𝑌 . Though midpoint(𝑌, 𝑌 + ) is a rational number (since 𝑌 and 𝑌 + are), it is not an element of F.

An important and instrumental property is that, for all of the IEEE 754-2008 [START_REF]IEEE 754-2008, Standard for Floating-Point Arithmetic[END_REF] defined modes, the ∘ rounding function is a non-decreasing function (i.e., ∀𝑥, 𝑦 ∈ R, 𝑥 𝑦 =⇒ ∘(𝑥) ∘(𝑦)).

Another property is attached to the round toward 0 or to the round-to-nearest (provided a symmetric tie-breaking rule is adopted) rounding modes is that the symmetries of the function are preserved by the rounding function (i.e., 𝑓 (-𝑥) = -𝑓 (𝑥) =⇒ ∘(𝑓 (-𝑥)) = -∘ (𝑓 (𝑥)).

It is also interesting to investigate how rounding modes and the relative error due to rounding interact.

Rounding

When rounding takes place a relative error 𝜖 𝑟𝑒ℓ is committed:

𝜖 𝑟𝑒ℓ = ⃒ ⃒ ⃒ ⃒ 𝑥 -∘(𝑥) 𝑥 ⃒ ⃒ ⃒ ⃒ .
(1.2)

In the normal range and for the round-to-nearest mode

𝜖 𝑟𝑒ℓ 1 2 𝛽 1-𝑝 .
In the normal range and for the "directed" rounding modes (toward infinities, toward 0)

𝜖 𝑟𝑒ℓ < 𝛽 1-𝑝 .
Plotting the value of 𝜖 𝑟𝑒ℓ produces a sawtooth pattern since 𝜖 𝑟𝑒ℓ grows and shrinks as 𝑥 moves between breakpoints, falling down to 0 each time 𝑥 can be exactly represented by a floating-point number.

When it comes to subnormal numbers, the relative error can become very large: close to 1!

One can possibly comfort herself with the absolute rounding error, if this is what matters for her application:

• 𝜖 𝑎𝑏𝑠 = |𝑥 -RN(𝑥)| 1 2
𝛽 𝑒min-𝑝+1 (round-to-nearest mode);

• 𝜖 𝑎𝑏𝑠 = |𝑥 -∘(𝑥)| < 1 2 𝛽 𝑒min-𝑝+1
(where ∘ is one of the directed rounding modes).

We can now combine the two, relative and absolute, errors for some correctly rounded operation ⊤. Let us assume that we have 𝐴, 𝐵, 𝑌 ∈ F such that 𝑌 = ∘(𝐴⊤𝐵). We have

𝑌 = (𝐴⊤𝐵)(1 + 𝜖) + 𝜖 ′ , (1.3)
where:

• |𝜖| 1 2 𝛽 1-𝑝 and |𝜖 ′ | 1 2 𝛽 𝑒min+1-𝑝 in round-to-nearest mode:
• |𝜖| 𝛽 1-𝑝 and |𝜖 ′ | 𝛽 𝑒min+1-𝑝 in directed rounding modes;

• 𝜖 = 0 or 𝜖 ′ = 0 19 .
The bound on 𝜖 is often called the unit roundoff, machine epsilon or even machine precision and is often denoted by u.

It relates with ulp as defined in §1.4, p. 38:

• u = 1 2 ulp(1) = 1 2 𝛽 1-𝑝 in round-to-nearest mode; • u = ulp(1) = 𝛽 1-𝑝 in directed rounding modes.
This notion is the corner stone of the Standard Model of floating-point arithmetic that is widely used for the analysis of numerical algorithms (e.g. see Nicholas J. Higham's book Accuracy and Stability of Numerical Algorithms [START_REF] Higham | Accuracy and Stability of Numerical Algorithms[END_REF]). The model is based, for any arithmetic operation with floating-point numbers ⊤ ∈ {+, -, ×, /}, for any rounding mode ∘ ∈ {𝑅𝑁, 𝑅𝐷, 𝑅𝑈, 𝑅𝑍}, for all 𝐴, 𝐵 ∈ F and as long as 𝐴⊤𝐵 does not underflow or overflow, on the following expression:

∘(𝐴⊤𝐵) = (𝐴⊤𝐵)(1 + 𝜖 1 ) = 𝐴⊤𝐵 1 + 𝜖 2 .
with

|𝜖 1 | u and |𝜖 2 | u.
As it has been already stated, a wealth of results has been gathered through this approach and the cited book is acclaimed as a spectacular achievement in this respect.

But it has also been shown, as in [START_REF] Jeannerod | On relative errors of floating-point operations: optimal bounds and applications[END_REF], that sometimes better results (sharper bounds or even optimal, in the sense of actually attainable) could be obtained if one followed a more precise approach and model, taking into account the minute details of floating-point numbers properties, including the peculiar properties of some "new" basic operations as the Fused Multiply-Add (𝑥 + 𝑦 × 𝑧) with a single final rounding 20 .

Remark 1. From time to time one can bump into the faithful rounding expression. We feel some clarification is needed at the end of this section devoted to rounding. Let us call 𝑦 the exact result of some operation or function. Faithful rounding refers to a property of an implementation guaranteed to deliver either RD(𝑦) or RU(𝑦), without any further indication. By extension we call such a returned value a faithful value and if all operations verify that property, we will speak about a faithful arithmetic. But by no means can it be called a rounding mode in the sense of those described above since the result of faithful rounding is not unequivocally defined: it is not a function. It does not mean that this property is worthless and that no reasoning can be made about it.

Fused multiply-add

We will conclude this section devoted to rounding functions by a few words about the Fused Multiply-Add machine instruction (FMA). 20 More details to come about FMA.

From MAC to FMA

There are many kinds of computation where the sequence of operations 𝐴 + 𝐵 × 𝐶, 𝐴, 𝐵, 𝐶 ∈ F is often performed. One important such application field is signal processing [START_REF] Lapsley | DSP Processor Fundamentals: Architectures and Features[END_REF]. But this sequence also happens often in scientific computing at large (e.g. dot products, polynomial evaluation with Horner's scheme).

A natural idea among processor architects has been to create a specialized instruction that would perform the sequence at a faster pace than the consecutive executions of a multiplication and an addition, says, almost as quickly as the multiplication. This instruction is known as MAC (for Multiply ACcumulate):

𝑎 ← 𝑎 + 𝑏 × 𝑐.
The name proceeds from a frequent use where successive 𝑏𝑐 products with different data accumulate into 𝑎. In MAC, rounding is performed twice, after each elementary operation. The principal enhancement brought along is an execution speedup.

Later on, a new instruction was introduced in 1990 by IBM in the first scion of its general purpose processors POWER family [START_REF] Montoye | Design of the IBM RISC System/6000 Floatingpoint Execution Unit[END_REF]. Only one rounding takes place here: multiplication is computed (as if) exactly, followed by an (as if) exact addition, completed by a single rounding.

FMA and FMAC

The instruction was called Fused Multiply Add. Since its introduction most of the other manufacturers have appended it to the instruction set of their own processors. Two variants exist:

• 𝑟 ← 𝑎 + 𝑏 × 𝑐; • 𝑎 ← 𝑎 + 𝑏 × 𝑐.
In the first one, the result is assigned to a fourth register. In the second one, the result of the multiplication is added with the current value of the left operand. The left operand is eventually overwritten with the final result. This form is also called Fused Multiply-Accumulate.

When This algorithm only requires two operations whereas Dekker's Algorithm needs seventeen. Furthermore, it works for any radix and precision. Although presented here it for round-to-nearest mode, it works for the other rounding modes as well.

Correct rounding

In this section we will elaborate a bit on correct rounding issues in order to be able to discuss at more length the Table Maker's Dilemma.

What is correct rounding?

First of all, the notion of correct rounding is relative to a rounding mode (e.g. rounding-to-nearest, tie-breaking to even) and to a floating-point system: there is no such thing as correct rounding in general 21 . Secondly, this property refers to an implementation 𝑓 𝑖𝑚𝑝 of a mathematical function 𝑓 , not to 𝑓 itself: it does not actually make sense when one speaks about a "correctly rounded exponential". But, as this is a common expression, we will keep using this misnomer. An implementation 𝑓 𝑖𝑚𝑝 : F 𝑚 ↦ → F 𝑛 of an operation or a function 𝑓 : R 𝑚 ↦ → R 𝑛 is correctly rounded for rounding mode ∘, if for any input, 𝑋 = (𝑋 1 , . . . , 𝑋 𝑚 ) ∈ F 𝑚 , for any component 𝑌 𝑖 of the output 𝑓 𝑖𝑚𝑝 (𝑋) = 𝑌 = (𝑌 1 , . . . , 𝑌 𝑛 ) ∈ F 𝑛 , either: 21 Unless we possibly refer to correct rounding for all four rounding modes (RN, RD, RU, RZ) and some implicit F.

• 𝑌 𝑖 is a non-numerical value (e.g NaN, an infinity. . . ) for some mathematically sound reason (e.g. 1/ √ 0 = +∞);

• 𝑌 𝑖 is set to some numerical value by definition or by convention (e.g. pow(-1, ±∞) = 1);

• if 𝑦 = 𝑓 (𝑋), 𝑦 = (𝑦 1 , . . . , 𝑦 𝑛 ) ∈ R 𝑛 , then 𝑌 𝑖 = ∘𝑦 𝑖 , 𝑖 ∈ {1, . . . , 𝑛}.
The point here is, in the third case, that rounding refers to the mathematically exact value of the function evaluation. It does not imply that one absolutely has to compute this exact value, which very often is out of her reach, and then apply the rounding function. The requirement is that the returned floating-point value is "as if" it had been computed by rounding the exact value. In that case, which is the most common since approximations are used to compute the value intended to be rounded, the developer of a correctly rounded function implementation must make sure this is the case and also have good arguments to support her claims.

Let us give a tricky example of this third case. We want to compute correctly rounded, in round-to-nearest mode, images by function

𝑓 : 𝑥 ↦ → 1/ √ 𝑥 F 2,53,-1022,1023 ↦ → F 2,53,-1022,1023 binary64 binary64
for the value 𝑎 = 1.651028399744791652636877188342623412609100341796875.

While it may not seem absolutely obvious at first glance, 𝑎 is exactly representable in the binary64 format and it's value is 3717785442934375/2 51 . In the sequel of this example, we will display binary values since they make the problems easier to spot and explain. The target format has 53 bits of precision.

We provide below a high (512 bits) precision of 𝑓 (𝑎), and complement it with the rounded-tonearest value in 53-bit precision and the rounded-up value for the same precision: The position of the 53rd bit in the high-precision computed value is tagged with a down arrow.

In a naive approach, one could think that all is needed is to compute an approximation ̂ 𝑓 with an error less than 2 -55 in order to have bit-54 correct. But this is not enough. One must remember that, by definition, when an approximation is computed, all we have is an upper bound on the difference between the approximation and the exact value. We do not know what the distance to the exact value exactly is. We do not even know which, of the exact value and the approximation, is the largest. For the contrary to be true, one should know the exact value: in that case, what would be the point of computing an approximation at all?

We are constantly forced to consider the worst case, if we are to give any guaranty. In this particular case, with 𝜖 2 -55 , we have to suppose, that the approximating value ̂ 𝑓 (𝑎) can be as much as 2 -55 in excess of the exact value. What will then happen, as far as rounding is concerned?

If we add 2 -55 to the exact value, this will flip bit-55 to 0 with a carry that will propagate to bit-54 and, in turn, flip it to 1. The approximation then is

1 2 3 4 5 6 1234567890123456789012345678901234567890123456789012↓4567890  𝑓 (𝑎) = 0.110001110011101111010000100011000101000110000100101011 RU(𝑓 (𝑎)) = 0.11000111001110111101000010001100010100011000010010110
The application of the tie-break even rule will take us to the rounded-up value instead of the correctly rounded-to-nearest one. The same process repeats itself if we compute an approximation with an accuracy of 2 -56 as we have to assume again that the approximation can be in excess by 2 -56 to the exact value: bit-56 is flipped to 0 with a carry propagation that will cascade up to bit-54, with the same consequence as to rounding as above.

How far, in accuracy terms, does one need to go? She must target for an approximation with an error bound that, added to the exact value, will not cause a cascade of carry propagation that will eventually flip bit-54 to 1. And this will take an accuracy as high as 𝜖 2 -113 . If this is the case, bit-54 will have the same value in the approximated and exact values. Rounding rules applied to the approximation will then yield the correctly rounded value.

We must point out here that all our reasoning is based on our knowledge of the exact value (or, more precisely, of an extra-accurate approximation). It cannot be the basis for the actual approximation process. To conclude this example, we observe that, fortunately, computing the exact value is not needed. We can do "as if" we had it and yet perform a correct rounding. We have seen that, for this particular value 𝑎, it was possible to find an approximation accuracy for which we could blindly round the approximation and yet get the correct rounded value of the exact one.

But working out an approximation that guarantees a correct rounding for all possible inputs is by no means an easy task.

1.6.2 Why does correct rounding matter?

We, at the AriC team [3], firmly believe that being able to provide correctly rounded functions is greatly beneficial to those who compute with them. This is not a matter of hair-splitting concern for pervert theorists. It has a lot of practical implications.

Even from the most very basic perspective, it is a way, in the round-to-nearest mode, to provide the best possible accuracy when function 𝑓 is evaluated with argument 𝑋. If the result is in the normal range:

• the absolute error is bounded by 1 2 ulp(𝑓 (𝑋)) (this one is even true for subnormal numbers);

• the relative error is bounded by u = 2 -𝑝 (but that does not stand for subnormal numbers).

Generally, in real-world programs, a function is not used all by itself. It is combined with other functions and operations in complex sequences. Accuracy possibly decreases from the very first evaluation and the situation worsens as computation goes on. A good starting point helps to mitigate this accuracy fraying process with, hopefully, the lesser the garbage in, the lesser the garbage out.

Another important issue is software portability: users expect that a program will yield the same results whatever the platform it is run on (at least if they can work with the same precision).

There are many issues that can antagonize this expectation (non-deterministic parallel execution effects, compiler options, etc.). Those are very difficult to control. Using mathematical libraries that provide a consistent level of rounding quality across all platforms can relieve the burden for those who try to achieve portability. This consistent level can be nothing short of correct rounding.

But there is more. Nowadays, the dedicated programmer not only expects that his code will yield the best possible result but he also wants to have more than a vague feeling about what its accuracy is. This is the kind of insight that error analysis provides but it can only work if walking on firm grounds. Having correctly rounded functions allows for the kind of mathematical reasoning that is needed here, especially for formal proofs.

Correct rounding also greatly eases the implementation of interval arithmetic and makes it more useful. Even if, in this respect, it is not the only technique to use, it delays the moment where extravagantly spread apart and useless interval bounds are returned. More generally, any computation where tight bounds around the exact result of a sequence of floating-point operations are needed benefits from correct rounding. This is not only true for accurate modeling of unstable systems over large time spans [START_REF] Laskar | Existence of collisional trajectories of Mercury, Mars and Venus with the Earth[END_REF] but also when computations are used for mathematical proofs [56] [42].

One could object that a function guaranteed to be accurate to, say, the last two bits would give the same ability to provide rigorous error bounds. That is true. But certifying rounding is always complex, whatever the accuracy is. Furthermore, we now know for a fact [START_REF]CRLlibm[END_REF] that it is possible to design and implement a correctly rounded library of elementary mathematical functions without incurring a performance penalty. Why should we satisfy ourselves with low grade tools when topquality ones are at hand?

Last but not least, other interesting properties (preservation of monotonicity, compatibility with symmetry properties of functions, see §1.5.3, p. 46, for more details) of the rounding functions as IEEE 754 standard defines them for the four modes should not be overlooked.

For all these compelling reasons, at the occasion of its 2008 revision, IEEE 754 standard [START_REF]IEEE 754-2008, Standard for Floating-Point Arithmetic[END_REF],

that already mandated correct rounding for arithmetic operations, made it a recommendation for a large set of elementary functions 22 .

22 The function's list is: , 𝑥 𝑛 , 𝑥 1/𝑛 , (𝑛 is an integer), sin(𝜋𝑥), cos(𝜋𝑥), arctan(𝑥)/𝜋, arctan(𝑦/𝑥)/𝜋, sin(𝑥), cos(𝑥), tan(𝑥), arcsin(𝑥), arccos(𝑥), arctan(𝑥), arctan(𝑦/𝑥), sinh(𝑥), cosh(𝑥), tanh(𝑥), sinh -1 (𝑥),cosh -1 (𝑥), tanh -1 (𝑥).

𝑒 𝑥 , 𝑒 𝑥 -1, 2 𝑥 , 2 𝑥 -1, 10

The Table Maker's Dilemma

Let us imagine a magic world, where we have at hand an iterative algorithm that computes an approximation of some function 𝑓 , at the rate of one correct digit of the exact value (possibly made of an infinity of digits) per iteration. To correctly round-to-nearest the exact value of 𝑓 (𝑥) to a floating-point of precision 𝑝, all we have to do is to perform 𝑝 + 1 iterations of our algorithm and decide rounding upon the value of the (𝑝 + 1)-th digit according to tie-breaking rules.

But this is not how things happen in Real Life. In mathematical libraries running on computers, functions are not abstractly (mathematically) computed and then (trivially correctly) rounded as above. It turns out that all we have access to are approximants that compute approximations of function values and that all we know about them is their accuracy. And one should not confuse, for a value close to 1, having an accuracy of, say, 𝜖 2 -56 and having a guarantee that 55 bits or even 54 bits are correct. We have seen above, on an example, that things can get much complicated: there is a subtle alchemy between the accuracy of the approximant, the exact value of the function and the precision we want to round to. Since we do not know exact values, we have to be ready for the worst. At this point, a legitimate question is: what happens when we round these approximations?

How can we ensure, in general, that this yield the same result as the rounding of the exact values?

By no means is this an absolutely new problem. Those who computed the now long gone mathematical tables (as trigonometric or log tables) faced the same kind of issues as they also used approximation techniques to provide rounded values of the functions 23 . Oddly enough, it was not before the end of the 20th century that William Kahan, as he tells us the story in a 2004 text [START_REF] Kahan | A Logarithm Too Clever by Half[END_REF],

coined the suggestive and colorful expression of "Table Maker's Dilemma" to refer to this problem.

We will elaborate a bit more on this question in Chap. 3, p. 135, since solving it is an important motivation for this part of the presented work. In the sequel, we will especially consider the "round to nearest, tie-break to even" mode but the ideas outlined here apply to any of the other modes. In this particular case breakpoints are midpoints.

The TMD in pictures

As stated, the starting point is that we do not compute the mathematically exact value of the function but an approximation. And it is this approximation that we will want to round. Correct rounding in this context is making sure that rounding the approximation yields the same result as rounding the exact value.

Our first case shows that rounding is not only a matter of getting a floating-point number.

Figure 1 In this case, while the approximation is a straight floating-point number, "rounding" is still needed and in this particular proves impossible to perform: we cannot safely pick any of 𝑌 -, 𝑌 and 𝑌 + .

In our second case, illustrated in Figure1-6, 𝑓 (𝑥) is located "somewhere" in an interval centered on the computed value ̂ 𝑓 (𝑥). In this particular example, rounding is not an issue. The exact value, 𝑓 (𝑥), lives in the [𝑌, midpoint(𝑌, 𝑌 + )) interval. Hence its rounded value is 𝑌 = RN(𝑓 (𝑥)) = RN( f (𝑥)).

Let us consider now the situation depicted in Figure1-7. Here the exact 𝑓 (𝑥) value can be smaller or larger than (or even equal to) midpoint(𝑌, 𝑌 + ). Based on the present values of ̂ 𝑓 (𝑥) and 𝜖 we can not decide whether 𝑌 or 𝑌 + is the correctly rounded value of 𝑓 (𝑥).

What should we do next? The only reasonable solution (if correct rounding is to be obtained) is to compute a new approximation of 𝑓 (𝑥) with the another approximant ̂ 𝑓 (1) (𝑥), that allows for a better accuracy (e.g 𝜖 / 2). Our expectation is that we will reach a situation similar to that exemplified in Figure1-8.

Notice that this process is not guaranteed to terminate. It suffices that 𝑓 (𝑥) = midpoint(𝑌, 𝑌 + ) for some 𝑋 ∈ F for it to fall in an infinite loop. This is why it is necessary to make sure that such a situation never happens. We have two options here:

• prove that it is impossible; • enumerate all the cases where it happens and deal with them separately.

It is sometimes possible to mathematically assert that the image of any number of the D ⋂ F floating-point domain of 𝑓 (or any other convenient superset) is not a rational number, while midpoint(𝑌, 𝑌 + ), as we recall, always is. This can be done, for instance, by applying Lindemann's Theorem [START_REF] Baker | Transcendental number theory[END_REF] and corollaries for several elementary functions (as exp, log, cos. . . ). They state that:

• the image of any nonzero algebraic number is transcendental for exponential, sine, cosine, tangent, arctangent and hyperbolic functions;

• the logarithm of any algebraic number different from 1 is transcendental too.

If 𝑥 ∈ D ⋂ F such that 𝑓 (𝑥) is rational, then we are done with one part of the convergence This figure is a possible sequel to Figure1-7 where function 𝑓 is now approximated by a machine computable function ̂ 𝑓 (1) with an error 𝜖/2. This function is more accurate than the previously used ̂ 𝑓 (𝑥). The computed value  𝑓 (1) (𝑥) is still a rational number that, in general, does not coincide with any of the numbers of F and will therefore have to be rounded. Notice that, while 𝑓 (𝑥) has to be "somewhere" in the [ ̂ 𝑓 (1) (𝑥) -𝜖/2, ̂ 𝑓 (1) (𝑥) + 𝜖/2] interval, we have no clue as to where it actually lives. But this time, as in Figure1-6, all the possible values of 𝑓 (𝑥) are on "the same side" relatively to midpoint(𝑌, 𝑌 + ) what eventually makes correct rounding (to 𝑌 ) possible.

impossibility.

If a general result such as Lindemann's can not be obtained, an alternative is to enumerate the rational images (or, if possible, only the midpoint images) and deal with these particular cases in specific branches of the implementation. An example of this kind of characterization can be found in an article by C.-P. Jeannerod, N. Louvet, J.-M. Muller and A. Panhaleux [START_REF] Jeannerod | Midpoints and Exact Points of Some Algebraic Functions in Floating-Point Arithmetic[END_REF].

The other problem is that we must also ensure that either ̂ 𝑓 (𝑥) can be computed to any arbitrary accuracy relatively to 𝑓 (𝑥) or that we have at hand a family of approximants ̂ 𝑓 (𝑥), ̂ 𝑓 (1) (𝑥),  𝑓 (2) (𝑥) . . . that allows for an arbitrary accuracy approximation of 𝑓 (𝑥).

How far should this process be taken to ensure that RN( ̂ 𝑓 (𝑥)) = RN(𝑓 (𝑥)) is the heart of the We should notice that:

1. the elements of the floating-point domain of 𝑓 where the TMD shows its ugly face are a property of function 𝑓 itself related to precision 𝑝 and not one of its approximating functions;

2. the problem does not necessarily happen at high precisions; closeness to a midpoint of an image by 𝑓 can happen, for any precision, however small, for any value in its floating-point domain ;

3. precision matters a lot as to when points of the domain (or better said, their image by 𝑓 ) become problematic; we can not say that some floating-point number 𝑋 1 is a hard-to-round case for function 𝑓 (𝑥) in full generality; number 𝑋 1 can indeed be a problem when computing RN(𝑓 (𝑋 1 )) to an image in precision 𝑝 1 and totally innocuous if the image is in precision

𝑝 2 ̸ = 𝑝 1 ;
the respective values of 𝑝 1 and 𝑝 2 do not matter either: if, for instance, 𝑝 1 < 𝑝 2 and 𝑓 (𝑋 1 ) is hard-to-round to precision 𝑝 1 , one can not automatically conclude that it will also be hard to round to precision 𝑝 2 on the grounds of some "hard once, hard forever on" rule.

1.6.3.2 Hardness-to-round: the symptoms Beyond this pictorial presentation, we can also think about the problem in terms of the precision and accuracy of the approximant. We will still deal, in what comes next, with the "round to nearest, tie-break to even" rounding mode and with a binary representation of the numbers (for both the exact value and its approximation).

Let us suppose that 𝑦 (1) is the infinite significand of the image of some 𝑋 (1) ∈ F 2,𝑝,𝑒min,𝑒max by function 𝑓 . This image has an exponent 𝑒 𝑦 [START_REF] Akhavi | Speeding-up Lattice Reduction with Random Projections[END_REF] . Let use suppose the same relationship exists between 𝑦 (2) , 𝑋 (2) and 𝑒 𝑦 [START_REF] Albrecht | fplll-4.0, a floating-point LLL implementation[END_REF] . We write 𝑦 (1) and 𝑦 (2) under a form, where 𝑦 𝑛 are the 𝑝-most significant bits and 𝑢 are bits whose value is of no interest:

𝑦 (1) = 𝑦 0 .𝑦 1 𝑦 2 . . . 𝑦 𝑝-1 𝑘 bits ⏞ ⏟ 01111111111111111 0𝑢𝑢𝑢𝑢𝑢𝑢𝑢𝑢𝑢 . . . and
𝑦 (2) = 𝑦 0 .𝑦 1 𝑦 2 . . . 𝑦 𝑝-1 𝑘 bits ⏞ ⏟ 10000000000000000 1𝑢𝑢𝑢𝑢𝑢𝑢𝑢𝑢𝑢 . . . .
We can easily see that 𝑦 (1) and 𝑦 (2) are very close to a midpoint. The larger the length-𝑘 string is, the closer we are to a midpoint.

Let us define 𝑌 as:

𝑌 = 𝑦 0 .𝑦 1 𝑦 2 . . . 𝑦 𝑝-1 .
Here 𝑌 𝛽 𝑒 𝑦 (1) and its successor 𝑌 + 𝛽 𝑒 𝑦 (1) in precision 𝑝. Furthermore, we assume that 𝑌 𝛽 𝑝-1 is odd (𝑦 𝑝-1 = 1) and 𝑌 + 𝛽 𝑝-1 is even (𝑦 + 𝑝-1 = 0).

Obviously we have

𝑌 𝛽

𝑒 𝑦 (1)

= RN ( 𝑦 (1) )

and

𝑌 + 𝛽 𝑒 𝑦 (2) = RN ( 𝑦 (2)
) .

Suppose now that we have at hand an approximant ̂ 𝑓 (1) that is accurate up to 2 -𝑝-𝑘+1 and yields 𝑝 + 𝑘 digits. With this approximant, we compute ̂ 𝑓 (1) (𝑋 (1) ) = ̂ 𝑦 (1) , an approximation of 𝑦 (1) , whose significand is:

̂ 𝑦 (1) = ̂ 𝑦 0 .̂ 𝑦 1 ̂ 𝑦 2 . . . ̂ 𝑦 𝑝-1 1 𝑘 bits ⏞ ⏟ 0000000000000000 .
This value is an approximation of 𝑦 (1) with an error equal to 2 -𝑝-𝑘+1 , the maximum allowed by the accuracy of ̂ 𝑓 (1) . From this approximation alone we could erroneously conclude that RN ( 𝑦 (1) ) = 𝑌 + 𝛽 𝑒 𝑦 (1) , since 𝑦 + 𝑝-1 = 0 (break tie to even rule). Remember that, when we compute an approximation, all we know is ̂ 𝑦 (1) and 𝜖 = 2 -𝑝-𝑘+1 . We have no precise idea (to put it vaguely) of what 𝑦 (1) is nor do we know anything better than ⃒ ⃒ ̂ 𝑦 (1) -𝑦 (1) ⃒ ⃒ 𝜖.

We see here that it will take to compute an approximant ̂ 𝑓 (2) (𝑋 (1) ) with an accuracy better than or equal to 2 -𝑝-𝑘 yielding at least 𝑝 + 𝑘 + 1 digits for the new value of ̂ 𝑦 (1) be able to correctly round it to 𝑌 𝛽 𝑒 𝑦 (1) .

The same applies with the second case where we could compute an approximation of 𝑦 (2) with  𝑓 (1) whose significand is:

̂ 𝑦 (2) = ̂ 𝑦 0 .̂ 𝑦 1 ̂ 𝑦 2 . . . ̂ 𝑦 𝑝-1 0 𝑘 bits ⏞ ⏟ 1111111111111111 .
This value is an approximation of 𝑦 (2) with an error equal to 2 -𝑝+1-𝑘 , the maximum allowed by the accuracy of ̂ 𝑓 (1) . From this approximation we could as erroneously well conclude that RN ( 𝑦 (2) ) = 𝑌 𝛽 𝑒𝑦 1 .

Again, it will take to compute an approximant ̂ 𝑓 (2) (𝑋 (2) ) with an accuracy better than or equal to 2 -𝑝-𝑘 yielding at least 𝑝+𝑘 +1 digits be able to correctly round the new value of ̂ 𝑦 (2) to 𝑌 + 𝛽 𝑒 𝑦 (2) .

While these explanations may help to understand the problem, one must remember that the exact infinite significand values are beyond our reach. One can not make at leisure the above suggested adjustments in precision and accuracy. The dilemma is still here.

Gauging hardness-to-round

Before trying to solve the dilemma, we are going first to try and characterize it. We will first define the notion of hardness-to-round.

We have seen that 𝑘, the length of the peculiar sequences we depicted above, is a key factor to

assess
𝑚 𝑋 ∈ N such that : 1 2 𝑚 𝑋 +1 < |𝑦 0 .𝑦 1 . . . -𝜇 0 .𝜇 1 . . . 𝜇 𝑝 | 1 2 𝑚 𝑋 .
(1.4)

Let us consider now 24 𝑚 as the maximum value over all the 𝑚 𝑋 , for all the elements of F (at least for those whose image has a numerical value and after a clean up of the elements of the domain whose image is an exact midpoint).

This 𝑚 is called the hardness-to-round-to-nearest of function 𝑓 with respect to F (or a subdomain thereof). This is also the maximum length of a "011 . . . 110" or "100 . . . 001" string starting from the 𝑝-th position of the infinite significand of 𝑓 (𝑋).

This definition generalizes to other rounding modes. Hardness-to-round "in general" refers to the largest value for all rounding modes. However, in the context of this work, since we will focus most of the time on the rounding-to-nearest mode, hardness-to-round will only refer to this mode.

Floating-point numbers of the domain whose image by 𝑓 exhibits near-maximum length "011 . . . 110"

or "100 . . . 001" strings starting at the 𝑝-th position of its infinite significand are called hard-to-round cases. Notice that we make here another abuse of language. What is actually hard to round is not floating-point number 𝑋 in the domain, which is, by definition, "rounded". It is its image by 𝑓 , 𝑓 (𝑋)

which is a potential troublemaker. This way of expressing oneself strongly reflects the implementation developer concern: she wants to know beforehand which are those values in the domain whose image will give her a hard time to round. A floating-point number of the domain corresponding to the longest weird string in its image (or those that correspond to it, if several numbers share this property) will be called the (or a) worst case.

But yet, we have made no progress in the path towards the computation of 𝑚.

Given the importance of this question for the implementation of correct rounding, many efforts and expertise have been dedicated to this computation. A recapitulation of these endeavors and their achievements can be found in Chap. 12 of [START_REF] Muller | Handbook of Floating-Point Arithmetic[END_REF].

The point is to find either the exact value of 𝑚 or a reasonable upper bound to it. In the latter case, we want this bound to be rather tight since, for actual computations, using unnecessarily large values of 𝑚 impose needlessly high accuracies for approximations that will possibly take an heavy toll on performance: these computations may be very time (and possibly, memory) consuming.

As we have no access to exact values, a first approach is to make an abstract reasoning on the shape of the digits strings that represents them.

Approaching the problem: a probabilistic model

Let us assume that in 𝑦, the infinite length binary significand of 𝑓 (𝑋), the bits after the 𝑝-th position form a sequence of independent random digits. Each of them has a 1/2 probability of being either "0" or "1". This is a very crude assumption since one can easily find situations where it does not stand.

For instance the quotient of two floating-point numbers (once exact floating-point values and exact midpoint values have been discarded) can have an infinite significand but, at some point, the digits form a non-random at all infinite periodic sequence. Another assumption-debunking situation can be found for the exp(𝑥) function, when 𝑥 is so small that exp(𝑥) = 1 + 𝑥 with an extremely good accuracy. Nevertheless, let us toy a bit with this idea to see where it takes us.

Standing behind our assumption, the probability of having any particular sequence of some 𝑘 0 bits starting from position 𝑝 is 2 They are also helpful for picking adequate parameters for our worst cases search algorithms.

Several checks have been done. Some can be found in Chap. 12 of [START_REF] Muller | Handbook of Floating-Point Arithmetic[END_REF] for the sin(𝑥) and exp(𝑥)

functions for precisions ranging from 8 to 24, in interval [1/2, 1). The value of these checks is that, at such "low" precisions, exhaustive verification of actual values can be done in a reasonable time.

The experiments show that the expected values of the model closely fit those found in reality.

Furthermore, the actual verification of the hardness-to-round by other methods (see below) have also comforted the validity of the model for higher precisions (the 53 bits of the IEEE 754 binary64 format) and for a full-fledged floating-point system (not only a single binade). Actual hardnessesto-round have been found in the 2𝑝 order of magnitude.

This model can be used for three important but different purposes:

1. check our hardness-to-round research tools (they should find a number of cases more or less in line with those of the model);

2. give us a hint about the optimality of bounds to the hardness-to-round found with other methods (a bound constantly larger, by a wide margin, than that expected from the modelregardless of the function, the interval, etc. -deserves to be questioned for its optimality);

3. tune elementary functions algorithms that use Ziv's strategy (see Chap. 2, p. 79) when actual hardness-to-round is still unknown.

But we should never forget that improbable events occur (more often than usually expected [START_REF] Ellenberg | How not to be wrong: the hidden maths of everyday life[END_REF])

and "unusually" high values for hardness-to-round should not be overlooked as impossible.

Armed with our yardstick, we can come back to the efforts to compute actual hardness-to-round bounds and summarize the situation as follows.

Proved operational bounds for hardness-to-round

For a basic operation such as quotient (𝑓 (𝑥, 𝑦) → 𝑥/𝑦) of two floating-point numbers, it has been proved [START_REF] Lang | Bound on run of zeros and ones for algebraic functions[END_REF] that the length of strings "0" or "1" after the 𝑝 + 1-th digit is bounded by 𝑝 -1 what gives a hardness-to-round of 2𝑝 -1 (whenever the quotient is not an exact floating-point number, for directed rounding modes and noticing that the quotient can not be a midpoint when the radix is a prime number, for rounding-to-nearest mode). The principal qualities of this bound are that it is mathematically proved and yet allows for fast implementations since it is sharp.

Proved but intractable bounds for hardness-to-round

There is a large bunch of results deriving from the 1851 Liouville Theorem [START_REF] Liouville | Sur des classes très étendues de quantités dont la valeur n'est ni algébrique, ni même réductible à des irrationnelles algébriques[END_REF] about algebraic functions. For instance, Brisebarre and Muller, in [START_REF] Muller | Correct rounding of algebraic functions[END_REF] give a bound for the 𝑓 (𝑥) → 𝑥 𝑎/𝑏 function.

This bound is, except for some special values of 𝑎 and 𝑏, much larger than that one can expect from the probabilistic model. It can be debated for its optimality and cannot be used to implement efficient approximations since it mandates computing with a very high precision.

We already mentioned the 1882 Lindemann Theorem and corollaries. They assert that no image by 𝑓 (𝑥) will be a midpoint but do not give any clue as to what the minimal distance to a midpoint is.

Eventually, we have the Nesterenko and Waldschmidt Theorem [START_REF] Nesterenko | On the approximation of the values of exponential function and logarithm by algebraic numbers[END_REF] that, when specialized to rational numbers, allows for the computation of the hardness-to-round of several functions. Their starting point is the following:

• suppose we have a nonzero real number 𝜃 ∈ R * ;

• suppose that 𝛼 and 𝛼 ′ are any two algebraic numbers;

the |𝑒 𝜃 -𝛼| + |𝜃 -𝛼 ′ | sum is lower bounded. Notice that in this formula 𝑒 = 2.718 . . . represents the base of the natural logarithm and not the exponent of a floating-point number 25 .

In other words, if 𝜃 is "close" to an algebraic number, 𝑒 𝜃 is "far" from any of them. And their contribution goes as far as setting an explicit lower bound to this sum. In terms of floating-point numbers -and since they are rational numbers, hence algebraic numbers -for any floating point number 𝜃 there obviously exists an algebraic number 𝛼 ′ such that |𝜃 -𝛼 ′ | = 0. It suffices to set 𝛼 ′ = 𝜃. Then 𝜃's exponential is necessarily at some lower bounded distance from any algebraic number. This is also a lower bound to the distance of this exponential to any floating-point number and to any of their midpoints too (they are rational numbers as well). Why not to use it as a bound to the hardness-to-round of the exponential? To sort out this question we need to go into more details.

In the expression of their bound, Nesterenko and Waldschmidt use the concept of Weil's height that we will briefly present here before the theorem itself. (𝑥 -𝛼 𝑖 ) be the factorization of 𝑃 over the complex numbers. The Weil's height of 𝛼 is

𝐻(𝛼) = ( |𝑃 𝑑 | × 𝑑 ∏ 𝑖=0 max(1, |𝛼 𝑖 |) ) 1 𝑑 .
Let us remind that the minimal polynomial of an irreducible rational number 𝑎/𝑏 over Q is

𝑃 (𝑥) = 𝑏𝑥 -𝑎 and that its factorization is 𝑃 (𝑥) = 𝑏(𝑥 -𝑎/𝑏).
With rational numbers, the parameters found in the definition of Weil's height become:

• 𝑑 = 1 (the exponent 1/𝑑 vanishes, the product is reduced to a single factor);

• |𝑃 𝑑 | = |𝑃 1 | = |𝑏|.
The height itself is:

𝐻(𝑎/𝑏) = |𝑏| max(1, |𝑎/𝑏|). (1.5)
This can be expressed more clearly as:

𝐻(𝑎/𝑏) = max(|𝑎|, |𝑏|) = ⎧ ⎪ ⎨ ⎪ ⎩ |𝑎|, if ⃒ ⃒ ⃒ 𝑎 𝑏 ⃒ ⃒ ⃒ 1 |𝑏|, if 0 < ⃒ ⃒ ⃒ 𝑎 𝑏 ⃒ ⃒ ⃒ < 1 . (1.6)
If we come back now to the normalized floating-point numbers, 𝑋 ∈ F ∖ {subnormal numbers} can be written as 𝑀 𝛽 𝑒 𝑋 -𝑝+1 where 𝑀 is the integral significand of 𝑋. This implies that 𝛽 𝑝-1 𝑀 < 𝛽 𝑝 .

If we write 𝑋 as a rational number, we have:

• if |𝑋| 1, |𝑋| = 𝑀 𝛽 𝑒 𝑋 𝛽 𝑝-1
, with 𝑀 𝛽 𝑒 𝑋 < 𝛽 𝑝 𝛽 𝑒 𝑋 and 𝑒 𝑋 as the exponent of 𝑋;

• if 0 < |𝑋| < 1, |𝑋| = 𝑀 𝛽 -𝑒 𝑋 +𝑝-1 .
If we now use these values in 1.6, we have :

• if |𝑋| 1, 𝐻(𝑋) = 𝑀 𝛽 𝑒 𝑋 < 𝛽 𝑝 𝑀 𝛽 𝑒 𝑋 𝛽 𝑝-1 = 𝛽 𝑝 |𝑋|; • if 0 < |𝑋| < 1, 𝐻(𝑋) = 𝛽 𝑝-1 < 𝛽 -𝑒 𝑋 +𝑝-1
as one must remember here that 𝑒 𝑋 < 0 ;

𝛽 -𝑒 𝑋 +𝑝-1 < 𝛽 𝑝 𝑀 𝛽 -𝑒 𝑋 +𝑝-1 = 𝛽 𝑝 𝛽 -𝑒 𝑋 +𝑝-1 𝑀 = 𝛽 𝑝 |𝑋| .
We can conclude that, for any nonzero normalized floating-point number 𝑋, we have:

𝐻(𝑋) 𝛽 𝑝 max(|𝑋|, |1/𝑋|).
Let us come back now to Nesterenko and Waldschmidt's Theorem [START_REF] Nesterenko | On the approximation of the values of exponential function and logarithm by algebraic numbers[END_REF] itself, in a version specialized to rational numbers.

Theorem 1.1. Let 𝛼 and 𝛼 ′ be rational numbers. Let 𝜃 be an arbitrary nonzero real number. Let 𝐴, 𝐴 ′ and 𝐸 be positive real numbers with

𝐸 𝑒, 𝐴 max(𝐻(𝛼), 𝑒), 𝐴 ′ 𝐻(𝛼 ′ ).
Then

|𝑒 𝜃 -𝛼| + |𝜃 -𝛼 ′ | exp ( -211 × ( log(𝐴 ′ ) + log(log(𝐴)) + 2 log(𝐸 × max(1, |𝜃|)) + 10 ) × ( log(𝐴) + 2𝐸|𝜃| + 6 log(𝐸) ) × ( 3.7 + log(𝐸) ) × log(𝐸) -2 ) .
The proof of the theorem can also be found in [START_REF] Nesterenko | On the approximation of the values of exponential function and logarithm by algebraic numbers[END_REF].

Now we are going to try to apply this theorem to the TMD in the case of the function exp(𝑥).

Suppose now that 𝛼 is a precision-𝑝 floating-point number in interval [1, 𝛽). The exact value of

exp(𝛼) belongs to interval [𝑒, 𝑒 𝛽 ). Let 𝑘 be a number such that [𝑒, 𝑒 𝛽 ) ⊂ [1, 𝛽 𝑘 ).
We use now the Theorem 1.1 with 𝐸 = 𝑒 and 𝜃 = 𝛼 ′ , where 𝛼 is any precision-𝑝 floating-point number in [1, 𝛽 𝑘 ).

We obtain the following:

⃒ ⃒ ⃒𝑒 𝛼 ′ -𝛼 ⃒ ⃒ ⃒ exp ( -992 × ( (3𝑘 + 𝑝) log(𝛽) + log((𝑝 + 1) log(𝛽)) + 12 ) × ( (𝑝 + 1) log(𝛽) + 2𝑒𝛽 𝑘 + 6 ) ) .
If we specialize further our formula for radix-2 (𝛽 = 2 and 𝑘 = ⌈log 2 (𝑒 2 )⌉ = 3), this gives

⃒ ⃒ ⃒𝑒 𝛼 ′ -𝛼 ⃒ ⃒ ⃒ 2 -688𝑝 2 -992𝑝 log(𝑝+1)-67514𝑝-71824 log(𝑝+1)-1283614 .
This formula shows that the distance of the exponential of a floating-point number in interval

[1, 2) to a midpoint is lower bounded by a value in the order of 2 -𝐶𝑝 2 , where 𝐶 is a rather big constant.

To be even more specific, a final specialization performed by setting 𝑝 = 53 (double-precision C type or binary64 format) gives

⃒ ⃒ ⃒𝑒 𝛼 ′ -𝛼 ⃒ ⃒ ⃒ 2 -7290678 .
The consequence is that, to ensure that an approximation ̂ 𝑓 of function 𝑓 allows for correct rounding, its accuracy must be 𝜖 2 -7290678 and gives us an upper bound for the hardness-to-round 𝑚 = 7290678. That is a lot, both compared to our probabilistic yard stick and to actual findings (a maximum of 𝑚 = 158 was found for the exponential function with 𝑝 = 53 and in directed rounding mode) by other methods that we will see thereafter.

This value is way too large for any Real Life implementation attempt.

Generating hard-to-round cases This is another way to tackle the problem. If one can generate hard-to-round cases she gets a lower bound of the hardness-to-round. And if she can generate the Holly Grail "worst case", she has solved the dilemma.

A starting point in this direction could be the seminal work of several researchers (Kahan [START_REF] Kahan | A test for correctly rounded sqr[END_REF],

Parks [START_REF] Parks | Number-theoretic test generation for directed rounding[END_REF] [83], Cornea [START_REF] Cornea-Hasegan | Proving the IEEE Correctness of Iterative Floating-Point Square Root, Divide, and Remainder Algorithms[END_REF]. . . ) who have followed this route for the square root function. Their target was not actually to solve the dilemma but to make it is easier to check the implementations by stress testing them with hard-to-round cases. As such they could efficiently create "pretty good" hard-to-round cases but did not try to ensure they created "The" worst case.

Exhaustive search: a dead end? To be fair, this approach, computing and checking the image of all the floating-point numbers of the domain, has been realized for "low" precisions (up to the 24-bit precision significands of the IEEE 754 binary32 format, see, for instance, [START_REF] Muller | Handbook of Floating-Point Arithmetic[END_REF], Chap. 12).

To our knowledge, the first who did that were M. Schulte and E. Swartzlander as they explain in [START_REF] Schulte | Exact rounding of certain elementary functions[END_REF] p. 139, 141. Beyond that point, it becomes technically intractable for, says, IEEE 754 binary64 format even if a promising result, based on an implementation using FPGA's, was published in 2011 [START_REF] De Dinechin | An FPGA architecture for solving the Table Maker's Dilemma[END_REF]. Nevertheless, work done with this technique has allowed to gather data and knowledge about how hardness-to-round actually behaves. It has helped to validate (in the weak sense that it did not disprove it) the statistical model presented above and helps to test (over limited intervals) the algorithms sketched below.

Direct hard-to-round case finding: the 𝐿-algorithm This algorithm has been developed, implemented and intensively used ever since by Vincent Lefèvre. It is described in his PhD thesis [START_REF]L-algorithm[END_REF].

In a nutshell, it uses linear approximations (degree-1 polynomials) of function 𝑓 over small domains and checks that the evaluation of these polynomials never "comes too close" to a breakpoint.

If it does, a hard-to-round case has possibly been spotted and has to be checked more thoroughly.

The power of the method relies on the ability to make very quick computations and reuse the already done ones as much as possible. Domain splitting makes the problem embarrassingly parallel. Hence, spreading processing over a large number of cores/processors mitigates the adverse effect of using small intervals and eventually allows for a much quicker exploration of the full domain of 𝑓 .

The smart ideas behind the algorithm go much beyond using affine approximations and breaking the domain into small pieces since those alone would not have sufficed to make the algorithm an effective search tool. Over the time, Vincent Lefèvre has improved upon the original algorithm and implementation. Others have also contributed to improvements as, for instance, in [START_REF] Fortin | Solving the table maker's dilemma by reducing divergence on gpu[END_REF] to adapt the 𝐿-algorithm to GPUs.

The main achievement (and a still ongoing effort) realized through the use of the 𝐿-algorithm is the computation and publication of complete lists of hard-to-round cases for some elementary functions in IEEE-754 binary64. Those can be found in [START_REF] Muller | Handbook of Floating-Point Arithmetic[END_REF] and [START_REF] Lefevre | Hardest-to-round cases, part 2[END_REF].

This knowledge makes it possible to implement correctly rounded functions for, say, the libm used as the mathematical library for a C compiler. It has actually been used for this purpose by the authors of CRlibm [START_REF]CRLlibm[END_REF].

Hard-to-round case finding beyond binary64: 𝑆𝐿𝑍-algorithm?

The 𝐿-algorithm, while tractable with the IEEE-754 binary64 format, at the expense of years of consolidated computing time for a single function, has been found impractical for higher precisions and, more specifically, for IEEE-754 binary128, the so-called "quadruple precision" with its 113 bits significand. With the 𝐿-algorithm, the number of searches for a single binade is roughly proportional to 2 2𝑝/3 . This value is bound to the affine approximation that forces to break the approximation interval (say, again, a binade) into that number of very small sub-intervals.

A possible move out of this complexity trap is to try to use higher degree approximation polynomials to achieve a coarser granularity. This is the idea behind the 𝑆𝐿𝑍-algorithm [START_REF] Stehlé | Worst Cases and Lattice Reduction[END_REF] created by D. Stehlé, V. Lefèvre, and P. Zimmermann. For instance, D. Stehlé showed in [START_REF] Stehlé | Algorithmique de la réduction de réseaux et application à la recherche de pires cas pour l'arrondi de fonctions mathématiques[END_REF] and [START_REF] Stehlé | On the randomness of bits generated by sufficiently smooth functions[END_REF] that with degree-3 polynomials, one could limit himself to 2 𝑝/2 intervals per binade (still for the IEEE-754 binary64 format).

But then the ingenious method used in the 𝐿-algorithm to detect "near-misses" with breakpoints does not work anymore and has to be replaced with something different. We will not delve into more details here since the implementation of the 𝑆𝐿𝑍-algorithm is a hefty part of the work presented in Chap.3, p. 135. What can be said for the moment is that sophisticated techniques borrowed from cryptography (Coppersmith's algorithm [START_REF] Coppersmith | Finding a Small Root of a Univariate Modular Equation[END_REF]) are used to detect hard-to-round cases. The basic idea is to transform the computation of the distance to midpoints problem into a modular root finding for bivariate polynomials over the integers problem.

Some basic algorithms

We will not give an extensive presentation of all the possibly interesting and/or useful basic algorithms on floating-point numbers. For an in-depth coverage see [START_REF] Muller | Handbook of Floating-Point Arithmetic[END_REF].

Accurate computation of the sum of two floating-point numbers

The Fast2Sum algorithm computes the sum of two floating point numbers 𝐴 and 𝐵 as the unevaluated sum of two other numbers 𝑌 ℎ and 𝑌 ℓ . At first sight no progress has been made but, as we will see, 𝑌 ℎ and 𝑌 ℓ have interesting properties. The algorithm has a long story (see [START_REF] Muller | Handbook of Floating-Point Arithmetic[END_REF], p. 126, for details).

It has four requirements:

• radix 𝛽 3 ; in practice 𝛽 = 2, unless one insists in using a Setun radix-3 computer [START_REF] Brusentsov | Ternary Computers: The Setun and the Setun 70[END_REF];

• subnormal numbers are available;

• rounding-to-nearest mode is used for operations (the tie-breaking rule is indifferent here);

• the exponent of the first input number, 𝐴, is larger than or equal to that of the second input number 𝐵; that can be reduced to the often easier to check condition 26 |𝐴| |𝐵|.

And here are the algorithm's two interesting properties:

• 𝑌 ℎ + 𝑌 ℓ = 𝐴 + 𝐵 exactly;
• 𝑌 ℎ is "the"27 floating-point number that is closest to 𝐴 + 𝐵.

Accurate computation of the product of two floating-point numbers

← RN(𝐴 + 𝐵) 𝑌 𝑡𝑒𝑚𝑝 ← RN(𝑌 ℎ -𝐴) 𝑌 ℓ ← RN(𝐵 -𝑌 𝑡𝑒𝑚𝑝 ) /* 𝐴 + 𝐵 = 𝑌 ℎ + 𝑌 ℓ and RN(𝐴 + 𝐵) = 𝑌 ℎ */ return 𝑌 ℎ , 𝑌 ℓ end function 1.7.2.

Veltkamp's splitting

The whole idea is to "split" an element 𝐴 of some F 𝛽,𝑝,𝑒𝑚𝑖𝑛,𝑒𝑚𝑎𝑥 floating-point system into two floating-point numbers of F, 𝐴 ℎ and 𝐴 ℓ , such that, for a given integer 𝑠, 𝑠 < 𝑝 (here "s" stands for "shift", nothing to do with the sign bit), we have:

• the significand of 𝐴 ℎ fits into 𝑝 -𝑠 digits;

• the significand of 𝐴 ℓ fits into 𝑠 digits (if the radix is 2, the significand of 𝐴 ℓ actually fits into 𝑠 -1 digits);

• 𝐴 = RN(𝐴 ℎ + 𝐴 ℓ )
We owe to Veltkamp Algorithm 3.

Algorithm 3 Veltkamps's splitting algorithm /* Assume a binary floating-point system

F 𝛽,𝑝,𝑒𝑚𝑖𝑛,𝑒𝑚𝑎𝑥 . */ function Split(𝐴, 𝑠) 𝐶𝑂𝑁 𝑆𝑇 ← 𝛽 𝑠 + 1 𝑇 𝐸𝑀 𝑃 1 ← RN(𝐶𝑂𝑁 𝑆𝑇 × 𝐴) 𝑇 𝐸𝑀 𝑃 2 ← RN(𝐴 -𝑇 𝐸𝑀 𝑃 1 ) 𝐴 ℎ ← RN(𝑇 𝐸𝑀 𝑃 1 + 𝑇 𝐸𝑀 𝑃 2 ) 𝐴 ℓ ← RN(𝐴 -𝐴 ℎ ) return 𝐴 ℎ , 𝐴 ℓ end function
It must be noted that nothing guarantees that 𝐴 ℎ and 𝐴 ℓ have the same sign. Veltkamp's algorithm is not equivalent, for 𝐴 ℎ , to masking the least significant digits of the significand of 𝐴, and, for 𝐴 ℓ , to masking the most significant digits of the significand of 𝐴. This is why it may seem a bit convoluted. This also explains why, in radix-2, we can have a (𝑝 -𝑠)-digit 𝐴 ℎ and a (𝑠 -1)-digit 𝐴 ℓ . The latter method could hardly be formulated in terms of operations that could work with any floating-point system.

Dekker's multiplication algorithm

Discovered by Dekker (see [START_REF] Dekker | A floating-point technique for extending the available precision[END_REF]), Algorithm 4, under the conditions presented below, allows for the exact computation of the product of finite28 floating-point numbers, 𝐴 and 𝐵, to be returned as an unevaluated sum of two numbers 𝑌 ℎ and 𝑌 ℓ (floating-point numbers themselves). Let 𝑒 𝐴 and 𝑒 𝐵 respectively be the exponents of 𝐴 and 𝐵.

Let us assume that for our floating-point system F 𝛽,𝑝,𝑒𝑚𝑖𝑛,𝑒𝑚𝑎𝑥 and the values of 𝐴 and 𝐵 the four following conditions are met:

• 𝑝 3;
• 𝛽 𝑒min-𝑝+1 1;

• 𝛽 = 2 or 𝑝 is even;

• there is no overflow when splitting 𝐴 and 𝐵 nor in the computation of

𝑌 ℎ = RN(𝐴 × 𝐵) nor in that of RN(𝐴 ℎ × 𝐵 ℎ ).
The first two conditions hold in any sensible floating-point system. The two others may seem more baroque, see [START_REF] Muller | Handbook of Floating-Point Arithmetic[END_REF] p. 137 for a detailed explanation.

Under these conditions, the numbers 𝑌 ℎ and 𝑌 ℓ computed by Dekker's algorithm have two remarkable properties:

1. if 𝑒 𝐴 + 𝑒 𝐵 𝑒 min -𝑝 + 1 then 𝐴𝐵 = 𝑌 ℎ + 𝑌 ℓ exactly; 2. in any case, |𝐴𝐵 -(𝑌 ℎ + 𝑌 ℓ )| 7 2 𝛽 𝑒min-𝑝+1 .
Behind (and far from) their superficial simplicity, the workings of these two algorithms make it difficult to establish rigorous proofs. As for Dekker's algorithm, the reiterated efforts of several authors culminated in Sylvie Boldo's transcription to the Coq theorem prover and proof completion as reported in [START_REF] Boldo | Pitfalls of a Full Floating-Point Proof: Example on the Formal Proof of the Veltkamp/Dekker Algorithms[END_REF].

Error Free Transformations

The previous examples are typical of a class of algorithms collectively known as Error Free Transformations (EFT). Let us denote as • an operation defined on F. Very often, for 𝐴 ∈ F, 𝐵 ∈ F,

𝐴 • 𝐵 / ∈ F even if RN(𝐴 • 𝐵) is a numerical value in F. But it is known for basic operations (• ∈ {+, -, ×}) that the rounding error itself ((𝐴 • 𝐵) -RN(𝐴 • 𝐵)) is an element of F. For 𝐴 ∈ F and 𝐵 ∈ F, RN(𝐴 • 𝐵) = 𝑌 1 , 𝐴 • 𝐵 = 𝑌 1 + 𝑌 2 with 𝑌 1 ∈ F
-𝑝 + 1. */ 𝑇 𝑀 𝑃 1 ← RN(-𝑌 ℎ + RN(𝐴 ℎ × 𝐵 ℎ )) 𝑇 𝑀 𝑃 2 ← RN(𝑇 𝑀 𝑃 1 + RN(𝐴 ℎ × 𝐵 ℓ )) 𝑇 𝑀 𝑃 3 ← RN(𝑇 𝑀 𝑃 2 + RN(𝐴 ℓ × 𝐵 ℎ )) 𝑌 ℓ ← RN(𝑇 𝑀 𝑃 3 + RN(𝐴 ℓ × 𝐵 ℓ )) /* Eventually, 𝑌 ℓ is the exact difference between 𝐴 × 𝐵 and 𝑌 ℎ . */ return 𝑌 ℎ , 𝑌 ℓ end function
There are generally some extra conditions (e.g. no underflow is assumed for multiplication). But the interesting point is that the values of 𝑌 1 and 𝑌 2 can be computed exactly within floating-point arithmetic itself. In general, the first value, 𝑌 1 , is straightforwardly computed, with a single floatingpoint instruction. The computation of 𝑌 2 is sometimes more complicated, as can be seen from our previous examples.

Many authors [START_REF] Graillat | Algorithms for Accurate, Validated and Fast Computations with Polynomials[END_REF]

Function approximation

In this section we present the principal steps taken to perform a function approximation and how this thesis work fits into this framework. We must first reassert that the driving spirit of our (as a research team) endeavor in the realm of function approximation is combining numerical quality (correct rounding, method error bounding, certified evaluations) with computation efficiency (speed, memory footprint). This is necessary to explain the emphasis we put on some not-so-obvious steps for unworldly approaches. For each of them we will give a reference to a PhD thesis work realized in the team. It has nothing to do with an AriC-centric bias, neither with a PhD-thesis-centric one.

Our only point here is to demonstrate the constancy of this team's dedication in this field and how the present work fits in a long term collective endeavor.

The steps

We can single out six main steps in the approximation of some function 𝑓 in some floating-point format F: 0. compute hard-to-round cases for function 𝑓 for F;

1. design argument(s) range reduction of 𝑓 ; 2. devise a "machine efficient" polynomial approximation 𝑝 𝑜𝑝𝑡 ; 3. set up an evaluation scheme; 4. compute a rigorous approximation error ||𝑓 -𝑝 𝑜𝑝𝑡 ||; 5. compute a certified evaluation error for 𝑝 𝑜𝑝𝑡 .

Compute the hard-to-round cases

We give this step a special attention by numbering it as "0" since it is not classically identified, per se, as a part of function approximation. The reason is that not everyone is interested in correct rounding.

If, for instance, faithful rounding (see Remark 1, p. 48) is all that is wanted, this step can be avoided.

Hard-to-round cases, as already stated in §1.6.3, p. 55, are closely connected to the TMD. One must notice that the list of the hard-to-round cases is a mathematical property of both the function 𝑓 and the target floating-point format, independently of our intent to approximate it. But it is also important to understand that, for a given function 𝑓 , there is no such thing as a "generic" list of hard-to-round cases. For that matter, we must also consider what the floating-point domain and image formats are in.

When analyzed for hard-to-round cases, each triplet (𝑓 , F 𝑑 , F 𝑖 ) (where 𝑓 is a function, F 𝑑 the floating-point format domain of 𝑓 and F 𝑖 the set where the images of the elements of the domain must live in) will yield its own list of cases.

As stated above ( §1.6.3.3, p. 67), two principal approaches have been designed for a systematical research of hard-to-round cases. The first one is the so-called "𝐿-algorithm" due to V. Lefèvre and is described at length in his PhD thesis [START_REF] Lefèvre | Moyens arithmétiques pour un calcul fiable[END_REF]. The second one, known as the "𝑆𝐿𝑍-algorithm", was designed by Damien Stehlé, Vincent Lefèvre and Paul Zimmermann and exposed in [START_REF] Stehlé | Worst Cases and Lattice Reduction[END_REF] and [START_REF] Stehlé | Searching Worst Cases of a One-Variable Function Using Lattice Reduction[END_REF].

A part of this PhD thesis (Chap. 3, p. 135) will be devoted the work done for the implementation and the exploration of the properties of this algorithm.

Argument/range reduction

The usual techniques for function approximation rely on polynomials. The reasons for picking this option are technical and mathematical as well. From the technical point of view, the main appeal of polynomials is that -when the only operations at hand are addition, subtraction, multiplication, and comparison operators -piecewise polynomials are the only functions in one variable that can be computed. This may still be the case in simple microcontrollers. Yet, with more sophisticated processors, these operations can be computed at blazing speed which sustains the appeal of polynomials, even on these advanced architectures.

To be more specific here, for those written in the so called "standard monomial basis", classical evaluation schemes as Horner's algorithm (see [START_REF] Horner | A new method of solving numerical equations of all orders, by continuous approximation[END_REF]) are very often used since they only rely on addition and multiplication (and for some time now, FMA) that are highly optimized (small cycle number, pipelining) in nowadays hardware. Other efficient schemes are also available for other bases.

Mathematically, polynomial approximation has a long and rich history. Important mathematicians such as Weierstrass [START_REF] Weierstrass | Über die analytische Darstellbarkeit sogenannter willkürlicher Functionen einer reellen Veränderlichen[END_REF], Chebyshev [START_REF] Chebyshev | Sur les questions de minima qui se rattachent á la représentation approximative des fonctions[END_REF], La Vallée Poussin [START_REF] De | Leçons sur l'approximation des fonctions d'une variable réelle[END_REF], Remez [START_REF] Remez | Sur la détermination des polynômes d'approximation de degré donné[END_REF] [88], to name only a few, have not only leveled the theoretical ground and but have also created tools that allow for the design of robust polynomial approximation. Unfortunately these techniques are plagued by the narrowness of the intervals over which they are accurate for a reasonable29 degree.

When it comes to the approximation of some non-trivial function 𝑓 defined over an interval as wide as (approximately) [-2 1024 , +2 1024 ] (the span of the binary64 format) there are very small chances that a polynomial with a degree, say, smaller than 100 will provide an accurate enough approximation. It could be necessary to resort to a set of polynomials, each defined over a somehow limited interval. But then the cardinal of the set could be prohibitively large.

But even a cursory observation of, say, periodical functions, can lead one to think that it is not necessary to compute an approximation polynomial that works over the whole domain of 𝑓 . If we can reduce the computation of many elements image of the domain to those of a much more limited interval, a single or an itself limited number of polynomials can be sufficient. This is argument reduction.

When designing the argument reduction scheme one can first set apart from the initial domain some values or even subsets for which elements have an obvious image that can be returned without further evaluation. For instance, the image by the exp(𝑥) function of large positive argument values will, above some easy to compute once-for-all threshold, be assigned to the positive infinity in the target floating-point format.

For what is left, the solution is to switch, through smart mathematical transformations, from the initial function 𝑓 , defined on domain D 𝑓 , to another (or limited number of) function(s) 𝑔 defined over a much narrower domain D 𝑔 . The function 𝑔 is somehow equivalent (in a very broad sense, since it can actually be very different) to 𝑓 , but can be approximated, over its own domain, by a single (or limited number of) polynomial(s).

The result of the evaluation of 𝑔 will possibly go through another series of transformations to take into account the effects of range reduction before being returned as the result of the evaluation of 𝑓 .

The (somehow intricate) process is sketched in Figure 1-9. It has not been the main topic of any of the thesis defended at LIP but cursory remarks can be found in the work of David Defour [START_REF] Defour | Fonctions élémentaires: algorithmes et implémentations efficaces pour l'arrondi correct en double précision[END_REF], who wrote one of the first thesis that ever covered the correctly-rounded function approximation development process from start to end. A few years later Christoph Lauter developed a more systematic approach to the question with an opening to its automatic management in his own work [START_REF] Lauter | Arrondi correct de fonctions mathématiques[END_REF]. The design of range reduction is mathematically challenging as soon as we leave the relatively well-marked path of additive range reduction 30 . It must be done with great care to keep errors under control (see [START_REF] Muller | Handbook of Floating-Point Arithmetic[END_REF] Chap. 11). As such, its automation is a really difficult challenge.

Computing polynomial 𝑝 𝑜𝑝𝑡

Before we compute an optimal approximation polynomial, we must clarify how we gauge accuracy.

Norms and accuracy

We have defined above (def. 1.4 and def. 1.4) what absolute and relative error are for a single value.

When is comes to the accuracy of an approximation we need a more general definition based on norms on the real-valued bounded functions. In this work we will consider the supremum norm 30 Let us assume 𝑋 is the initial floating-point argument and 𝑐 the range reduction constant. In additive reduction, we are looking for an integer 𝑘 and a real number

𝑦 ∈ [0, 𝑐] or 𝑦 ∈ [-𝑐/2, 𝑐/2] such that 𝑦 = 𝑋 -𝑘𝑐.
Figure 123456789: 𝑓 is the function to approximate. Some part of its domain D 𝑓 (gray area) can be mapped, through a "smart transformation" 𝑠𝑚𝑎𝑟𝑡𝑇 𝑟𝑎𝑛𝑠 1 , into some narrow interval (for instance, 𝑥 and 𝑦 will be mapped to the same value 𝜔) denoted by D 𝑔 . This is the domain of a function 𝑔 (we only consider here one 𝑔 function, for clarity), "equivalent" to 𝑓 in the sense that, at a final (optional) "smart transformation" 𝑠𝑚𝑎𝑟𝑡𝑇 𝑟𝑎𝑛𝑠 2 short, 𝑓 (𝑥) = 𝑔(𝜔). Hopefully function 𝑔 can be approximated with a single (or limited number of) polynomial(s). Value 𝑦 can possibly have a different image (dashed line) than 𝑥 whenever the final transformation 𝑠𝑚𝑎𝑟𝑡𝑇 𝑟𝑎𝑛𝑠 2 takes into account the initial values (𝑥 or 𝑦). The representation of two arguments case for 𝑠𝑚𝑎𝑟𝑡𝑇 𝑟𝑎𝑛𝑠 2 is omitted for clarity. Ultimately, there is a subset of D 𝑓 whose elements image by 𝑓 can be trivially computed (bottom arrow).

(also called uniform norm, infinity norm or maximum norm 31 ); Definition 1.9. The supremum norm of the function 𝑓 (𝑥) over the interval [𝑎, 𝑏] ⊂ R is defined as:

‖𝑓 ‖ [𝑎,𝑏] ∞ = sup{|𝑓 (𝑥)|, 𝑥 ∈ [𝑎, 𝑏]}.
We will often denote this norm simply by ‖𝑓 ‖ when the interval is obvious.

When we say that the function 𝑝(𝑥) (possibly a polynomial) is an approximation of the function 𝑓 (𝑥) with an absolute error accuracy 𝜖 𝑎𝑏𝑠 over the interval [𝑎, 𝑏] we mean that:

‖𝑓 -𝑝‖ [𝑎,𝑏] ∞ = sup{|𝑓 (𝑥) -𝑝(𝑥)|, 𝑥 ∈ [𝑎, 𝑏]} < 𝜖 𝑎𝑏𝑠 .
Almost identically, when it comes the relative error accuracy 𝜖 𝑟𝑒ℓ . what we have in mind is:

⃦ ⃦ ⃦ ⃦ 1 - 𝑝 𝑓 ⃦ ⃦ ⃦ ⃦ [𝑎,𝑏] ∞ = sup {⃒ ⃒ ⃒ ⃒ 1 - 𝑝(𝑥) 𝑓 (𝑥) ⃒ ⃒ ⃒ ⃒ , 𝑥 ∈ [𝑎, 𝑏] } < 𝜖 𝑟𝑒ℓ .

Approximation polynomial properties

At this point an approximation polynomial 𝑝 𝑜𝑝𝑡 matching all the user desired properties will be crafted. These can be many and sometimes conflicting:

• accuracy of the result ("small" absolute or relative error);

• numerical properties (e.g. correct rounding);

• polynomial structural properties (e.g. precision and/or specific values for the coefficients);

• execution time/memory footprint optimization;

• etc.

Many approaches are possible to realize this step. The already mentioned Christoph Lauter's thesis pays a sustained attention to this question [START_REF] Lauter | Arrondi correct de fonctions mathématiques[END_REF]. In his own text [START_REF] Chevillard | Évaluation efficace de fonctions numériques -Outils et exemples[END_REF], Sylvain Chevillard's develops an in-depth analysis with a special emphasis on certification. Both are the main authors of the Sollya [13] software.

Setting up an evaluation scheme

As already mentioned in our plea for polynomials, those expressed in the "standard basis" can be efficiently evaluated using Horner's algorithm. Other schemes exist for these, as Estrin's [START_REF] Muller | Elementary Functions: Algorithms and Implementation[END_REF], which allows for more parallelism. For Chebyshev polynomials one can efficiently use Clenshaw's algorithm [START_REF] Clenshaw | A note on the summation of Chebyshev series[END_REF]. De Casteljau's algorithm [START_REF] De Faget De Casteljau | Outillages méthodes de calcul[END_REF][31] can be applied to Bernstein's form polynomials.

While the major incentive for using evaluation schemes is that they are much faster (and/or more memory-saving) than naive evaluation of polynomials, performance is not the only criterion.

Numerical properties of the scheme matter too. Mathematically equivalent methods on real numbers may, now to no surprise, exhibit diverging accuracies when applied to floating-point ones. Insights on the application of different schemes can be found in Guillaume Révy's work [START_REF] Revy | Implementation of binary floating-point arithmetic on embedded integer processors -Polynomial evaluation-based algorithms and certified code generation[END_REF].

Certified approximation error

Tools used at the previous steps often deliver quite satisfactory results. Some properties of the approximants (size/structure) are easy to check. Nevertheless approximation error checking is more complicated and can not be left in some "almost-OK" nebulous state, specially when critical applications are envisioned. Techniques and tools that allow for a certified error have to be called in. This is not a matter of hair-splitting perfectionism. First of all, as already noted, absolute certitude is mandatory for critical systems. But, even in less stringent applications, an approximant is often one single piece of the possibly many that make up some artifact. Making any relevant reasoning about its properties as a whole requires that each element is rigorously qualified (certified). Mioara Joldeş's thesis manuscript [START_REF] Joldeş | Approximations polynomiales rigoureuses et applications[END_REF] is largely devoted to that question. She is also an important contributor to the Sollya software.

Computing a certified evaluation error

The previous step gives certified bounds on the committed error when replacing function 𝑓 by its approximation polynomial 𝑝 𝑜𝑝𝑡 . But there are more errors to come. The evaluation of polynomial 𝑝 𝑜𝑝𝑡 will be implemented under the form of some machine computable program. Its execution will, in turn, generate its own string of numerical errors. These have to be rigorously characterized too.

Investigating the numerical properties of computer codes is an arduous problem. Computations and proof about them are particularly tedious and error-prone. That is why the capability of automatic extraction of these properties from programs code and their handling with formal tools as proof assistants strongly fortifies the trust one can have in the approximants and their implementations.

In our team the GAPPA tool [START_REF] Melquiond | Génération Automatique de Preuves de Propriétés Arithmétiques[END_REF] [73], was developed by Guillaume Melquiond during his thesis [START_REF] Melquiond | De l'arithmétique d'intervalles à la certification de programmes[END_REF] work, and the Coq [START_REF]The coq proof assistant[END_REF] theorem prover, whose application to proofs on floating-points theorems is a large body of Sylvie Boldo's thesis [START_REF] Boldo | Preuves formelles en arithmétiques à virgule flottante[END_REF], are routinely used for that certification task.

This final step bridges back between high performance computations and mathematics.

After all these steps are completed, the resulting computing modules do not only have an intrinsic high quality to be directly called from user code (for some scientific application) but, as already stated, can also be confidently used as building blocks to assemble more complex tools.

It is time now for us to put to use all this introductory material and, with the next chapter, to take on the core of the presented works.

Chapter 2

A better understanding and control of Ziv's rounding test

Motivation

Developing algorithms and software for floating-point function approximation is a many-facet activity. The complexity and the diversity of the issues can spark many different kinds of preoccupations.

Sometimes it is a matter of creating new concepts or importing methods developed in other fields into the realm of function approximation. This is for instance the case when Coppersmith's algorithm is applied to the Table Maker's Dilemma.

Other times it can be the creation of new devices in order to supplement the "function approximator's toolbox" with extra and more efficient machinery. Combining linear-programming, Remez algorithm and LLL-reduction as to optimize the polynomial approximation of a function can be viewed from this perspective.

But there is another aspect, possibly less glamorous, that deserves a close attention. Interest in floating-point computation is not a new whim: it has a long and tumultuous history. Our predecessors have accumulated a large and valuable "bag of tricks". Some of them have, from the start, been established on firm grounds or, later on, thoroughly checked under rigorous mathematical scrutiny.

Others have not and have nevertheless made their way into the informal floating-point trade Credo.

We feel it a necessary work to revisit this heritage and to get pending clarifications done. An important step in this direction, among other things, has been taken with the publication of the Handbook of Floating-Point Arithmetic [START_REF] Muller | Handbook of Floating-Point Arithmetic[END_REF]. In a sense it has opened a new research program, possibly very mundane at first glance, but that has clearly important implications. In fact, it does not only involve the verification of admitted rules but also the investigation of their possible extensions (radix-dependency is a big issue in this field, as is the possible availability of not-so-new FMA processor instruction whose implication are yet overlooked). Studying their limitations is also instrumental for their safe use. Rather than the useless rumination of old chewed bones, this exercise can be a way to deepen our understanding of the behavior of floating-point computations and extend our ability to perform them safely.

This chapter is an inroad in this direction, in the realm of techniques used in function approximation computation. The main results present here were already published in a more terse version in [START_REF] De Dinechin | On Ziv's Rounding Test[END_REF].

The "main + correcting term" technique

Let us assume that we want to compute or approximate the exact value, noted 𝑦, of, say, an arithmetic operation, a function evaluation at some point or any other accurate numerical computation.

There are many instances where this 𝑦, if it can actually be computed or, if not, its approximation, is returned as the unevaluated sum of two floating-point numbers noted 𝑦 1 and 𝑦 2 . Another quite similar situation is when a single floating-point is eventually returned but is computed as the sum of two numbers at a very last stage of the algorithm.

Let us take a first example of a result under the form of such an unevaluated sum, that of Dekker's Fast2Sum algorithm, whose detailed description can be found in §1.7.1, p. 69.

We quickly remind the algorithm here.

= RN(𝑦 1 + 𝑦 2 ).
When the order of magnitude of the elements in the pair differ largely, as in our first example (we have here 𝑦 2 < ulp(𝑦 1 )), this result is generally more valuable (i.e. more accurate) than the single value RN(𝑦 1 + 𝑦 2 ).

In this case, the largest of the two in magnitude noted 𝑦 1 , will be called the "main term" (providing, roughly speaking, for the most significant bits of the value) and the other one noted 𝑦 2 , will be called the "correcting term" (providing, when added to the main term, for the least significant bits, and possibly affecting the most significant ones due to carries propagation), that "adjusts" the main term value closer to that of the exact value of 𝑦.

In our next example, the algorithm returns a single value, as in function approximation. But what is interesting here is that at the very last stage the algorithm performs the sum of a "main + correcting term" pair. This second example is taken from [START_REF] Graillat | Algorithms for Accurate, Validated and Fast Computations with Polynomials[END_REF]. That paper deals with accurate polynomials evaluation using a so called "Horner's Compensated Algorithm". In §3, it is described as follows in Algorithm 6. Error Free Transformations are introduced in §1. [START_REF] Boldo | Pitfalls of a Full Floating-Point Proof: Example on the Formal Proof of the Veltkamp/Dekker Algorithms[END_REF] Here, the point of the authors of [START_REF] Graillat | Algorithms for Accurate, Validated and Fast Computations with Polynomials[END_REF] is to guarantee that the computed result, r, is approximately as good as if Horner's algorithm had been performed with twice the precision of the available floating-point arithmetic system and eventually rounded to this working precision. This is achieved, by the end of the algorithm, by adding to the main term of the result r the correcting term ĉ.

Chapter 2. A better understanding and control of Ziv's rounding test

But still, correct rounding is not the final target of the authors since Horner's algorithm is sensitive to the condition number of the problem and it can, in very adverse situations, output very poor results, wrong up to the order of magnitude of the correct value!

When correct rounding matters: the "main + correcting term" technique in function approximation

Suppose now one wants to compute the correctly rounded value of some function 𝑓 in some floatingpoint system F 𝛽,𝑝,𝑒min,𝑒max

1 . Here, we will limit ourselves to the "round to nearest, ties-to-even" rounding mode which is the most common.

As stated in §1.8, p. 72, we will approximate function 𝑓 by some many-steps "composite function"

𝒢 such that ∀ 𝑋 ∈ F, 𝒢(𝑋) = RN(𝑓 (𝑋)), if 𝑓 (𝑋) is mathematically defined, or 𝒢(𝑋) = NaN otherwise.
Sections within the computer program implementing 𝒢 will filter out the input elements whose image is not defined or can be trivially determined or read from a table, those whose image is a midpoint (when possible2 ), some hard-to-round cases, in short, all the special cases. Another section will take care of argument reduction, if any. Eventually we will end up with a residual domain D 𝑟 ⊂ F whose element must have their image computed by some function 𝑔, more or less deeply buried inside 𝒢.

Function 𝑔 may possibly be very different from 𝑓 (due, for instance, to argument reduction). This function 𝑔 is the one we have to approximate over D 𝑟 since (generally) we are not able to compute it exactly for each value of its domain. For that purpose we will devise an approximating function ℎ 𝜖 (or a family of these, if D 𝑟 is still too large and must be broken into smaller subdomains) such that3 :

𝜖 > max 𝑋 ∈ D𝑟 ⃒ ⃒ ⃒ ⃒ ℎ 𝜖 (𝑋) -𝑔(𝑋) 𝑔(𝑋) ⃒ ⃒ ⃒ ⃒ .
In practical terms, ℎ 𝜖 will approximate 𝑔 over a tight real number interval

[𝑎, 𝑏] including D 𝑟 4 such that 𝜖 > ⃒ ⃒ ⃒ ⃒ ⃒ ⃒ ⃒ ⃒ ℎ 𝜖 (𝑥) -𝑔(𝑥) 𝑔(𝑥) ⃒ ⃒ ⃒ ⃒ ⃒ ⃒ ⃒ ⃒ ∞ , for 𝑥 ∈ [𝑎, 𝑏] ⊂ R,
on the grounds that what stands for real numbers also stands for floating-point ones. Ideally, for a given 𝜖, the actual values of the maximum or of the infinity norm above should not be much smaller than 𝜖. Otherwise it would mean that ℎ 𝜖 approximates 𝑔 with an excessively high accuracy, possibly at the expense of a long evaluation time.

Notice that the values returned by ℎ 𝜖 are not only theoretical real numbers but are computed floating-point ones.

What should be the value of 𝜖? In very broad terms, it should be small enough to allow for the resolution of the Table Maker's Dilemma for all the elements in D 𝑟 and their image in the target floating-point system.

But this is where grim reality catches up. A sufficiently small value of 𝜖 to go past the TDM in all cases will generally be too expensive in terms of execution time. And very often this time will be wasted because for most of the cases a milder value of 𝜖 would have been enough.

This opens the door to different strategies for real-world approximation. One, for instance, is to perform a very quick approximation, with a relatively large value for 𝜖 but nevertheless small enough for most of the elements of the domain. Then make a check to assess whether the accuracy was sufficient (more on this to come very soon). If the check fails, performs another, possibly slower, approximation with a value of 𝜖 known to be sufficient to avoid the TMD. The idea is to have the second round performed so seldom that the average time of execution of the approximation is not much larger than that of the quick method. This strategy is currently implemented in CRlibm [START_REF]CRLlibm[END_REF].

Another strategy somehow generalizes the previous one. Why limit ourselves to two stages? Let us start with some ℎ 𝜖 approximation function that has the same properties as in in our preceding example. Perform a check. If it fails, make another try with, for instance, a ℎ 𝜖 2 𝑘 , with 𝑘 ∈ N, function 5 . Check again. If it still fails give ℎ 𝜖 2 2𝑘 a try, and so on until the check succeeds. The idea is the same though we do not need to know what the ultimate value of 𝜖 is. Notice that elements whose image is a midpoint must have been dealt with beforehand to avoid an endless loop (or to resort to some bound on 𝜖 to force exit from the loop but then take the chance to return an incorrect value). This is, in a nutshell, the "onion peel" strategy developed by Abraham Ziv in [START_REF] Ziv | Fast Evaluation of Elementary Mathematical Functions with Correctly Rounded Last Bit[END_REF].

What can we say about the precision of the values returned by the approximation functions? It will have indeed to be larger than that of the target floating-point system, if we want any actual rounding to be performed at all. Even if 𝑔 is easy to round (i.e. 𝑔(𝑋) is far from a midpoint), the accuracy 𝜖 will be such that |ℎ 𝜖 (𝑋) -𝑔(𝑋)|, upper-bounded by |𝑔(𝑋)| × 𝜖, will be smaller than ulp(RN(𝑔(𝑋))). Therefore it will take more than 𝑝 bits (say, 𝑝 ′ ) to express the floating-point number ℎ 𝜖 (𝑋) if it is to "come close enough" to 𝑔(𝑋).

How could this precision-𝑝 ′ number (with 𝑝 ′ 𝑝) be expressed?

Among the many possibilities, one is to use a pair of floating-point numbers of F. Indeed, if the numbers do not "overlap" and are not too much "spread apart" (that is their exponents exactly differ by 𝑝 + 1) one can view this pair as a precision-(2𝑝 + 1) number represented by the unevaluated sum of its members. Possible ways to view a pair of floating-point numbers as higher precision number as represented in Figure 2-1.

Figure 2-1: A floating-point numbers of precision 𝑝 pair can be viewed as a precision-𝑝 𝑖 number, with 𝑝 𝑖 𝑝, if considered as an unevaluated sum of the pair members. Two normal numbers (notice the fractional point) are represented here "aligned" with respect to their relative exponents. In situation 1, the two numbers "overlap", the precision 𝑝 1 of the pair is larger than that, 𝑝, of the single member but smaller or equal than 2𝑝. In the extreme situation 2, the two numbers are "exactly aligned". We can represent all the possible values over 2𝑝 bits. In situation 3, a much higher precision-𝑝 3 number can be represented but not all 𝑝 3 -possible numbers can: the "central part" of the significand must be all 0s. Subnormal numbers could also be used as the second element of the pair.

Returning such pair is obviously an instance of "main + correcting term" technique. If we call the elements 𝑦 ℎ and 𝑦 ℓ they are such that:

𝑦 ℎ + 𝑦 ℓ = ℎ 𝜖 (𝑋) = 𝑔(𝑋) × (1 + 𝛼), with |𝛼| < 𝜖. (2.1)
Notice that 𝛼 is unknown. All we know about it is a bound on its absolute value.

When correct rounding matters: the "main + correcting term" technique in function approximation85

Suppose, without any loss of generality 6 , that

RN(𝑦 ℎ + 𝑦 ℓ ) = 𝑦 ℎ . (2.2)
This is a shorthand for the following more lengthy and complex set of conditions:

• if 𝑦 ℎ is not a power of 2 and its integral significand (see §1.3.2, p. 33) is odd then

|𝑦 ℓ | < 1 2 ulp(𝑦 ℎ );
• if 𝑦 ℎ is not a power of 2 and its integral significand is even then

|𝑦 ℓ | 1 2 ulp(𝑦 ℎ );
• if 𝑦 ℎ is a power of two (its significand is, almost per definition, a power of two) and 𝑦 ℎ > 0

then -1 4 ulp(𝑦 ℎ ) 𝑦 ℓ 1 2 ulp(𝑦 ℎ ).
• if 𝑦 ℎ is a power of two (again, its significand is a power of 2) and

𝑦 ℎ < 0 then -1 2 ulp(𝑦 ℎ ) 𝑦 ℓ 1 4 ulp(𝑦 ℎ ).
The length and complexity of the set of conditions pertain to both the behavior of the "round to nearest, ties-to-even" rounding mode and the peculiarities of the definition we use for the ulp() function (see §1.4.1, p. 39). Under these assumptions, (2.1) and (2.2), we would like to know when we can safely state that 𝑦 ℎ = RN(𝑦).

To get acquainted with the problem, assume first that 𝑦 ℎ and 𝑦 ℓ are both positive.

We may find ourselves in one of the two situations depicted by Figures 2-2 and2-3.

If in the first situation (Figure 2-2), we can safely state that 𝑦 ℎ = RN(𝑦). If in the second one (Figure 2-3), this is not the case and 𝑔(𝑥) should be approximated by another, more accurate, function ulp(𝑦 ℎ ) to make sure that 𝑦 ℎ = RN(𝑦 ℎ + 𝑦 ℓ ). Again, and despite the smaller length of the "𝑦 segment", another attempt at higher precision should be made in the situation depicted in Figure 234.

Figure 234: Numbers 𝑦 ℎ and 𝑦 ℓ can have different signs and, to make it worse, 𝑦 ℎ can be a power of 2. Here while the length of the "𝑦 segment" is smaller than in the previous cases, 𝑦 can be a midpoint or beyond it, in the direction of 𝑦 - ℎ .

How could one possibly make the check?

From the figures, we see that one could add9 the length of the "𝑦 segment" to 𝑦 ℓ and run Algorithm 7.

Algorithm But this algorithm is doomed to fail: the computation of variable 𝑦𝑠𝑙 (the "𝑦 segment length") is impossible since we do not know 𝑦. On the other hand the relative error bound 𝜖 is known (it should be for without this knowledge any attempt to round is inutile!).

Nevertheless it points us toward a possible solution: add "𝑠𝑜𝑚𝑒𝑡ℎ𝑖𝑛𝑔" to 𝑦 ℓ and check whether

𝑦 ℎ = RN(𝑦 ℎ + RN(𝑦 ℓ + 𝑠𝑜𝑚𝑒𝑡ℎ𝑖𝑛𝑔)).
Intuitively, we see that "𝑠𝑜𝑚𝑒𝑡ℎ𝑖𝑛𝑔" depends on the absolute value of 𝑦 or, at least, on its order of magnitude. This forces us to compute a different "𝑠𝑜𝑚𝑒𝑡ℎ𝑖𝑛𝑔" for each order of magnitude for all possible 𝑦 which is an annoyance. Indeed we would like the test to perform as quick as possible since it can possibly be taken many times in a computation. We have also seen that, depending on the respective signs of 𝑦 ℎ and 𝑦 ℓ we may have to subtract "𝑠𝑜𝑚𝑒𝑡ℎ𝑖𝑛𝑔" instead of adding it.

A different approach could be to multiply 𝑦 ℓ by some constant 𝑒 > 1. Ideally 𝑒 would only depend on the parameters of F and on the value of 𝜖. It could then be computed once for all, for a given algorithm.

The test would then conform to Algorithm 8.

With the very loose requirements put on 𝑒, Algorithm 8 is not guaranteed to give correct results. These can fall in four categories:

• positives: 𝑦 ℎ = RN(𝑦 ℎ + RN(𝑦 ℓ × 𝑒)) and 𝑦 ℎ = RN(𝑦); • negatives: 𝑦 ℎ ̸ = RN(𝑦 ℎ + RN(𝑦 ℓ × 𝑒)) and 𝑦 ℎ ̸ = RN(
= RN(𝑦 ℎ + 𝑦 ℓ ) Require: 𝑒 = 𝑠𝑜𝑚𝑒_𝑓 𝑢𝑛𝑐𝑡𝑖𝑜𝑛 (F, 𝜖) and 𝑒 > 1 if 𝑦 ℎ == RN(𝑦 ℎ + RN(𝑦 ℓ × 𝑒)) then True else False end if • false positives: 𝑦 ℎ = RN(𝑦 ℎ + RN(𝑦 ℓ × 𝑒)) but 𝑦 ℎ ̸ = RN(𝑦); • false negatives: 𝑦 ℎ ̸ = RN(𝑦 ℎ + RN(𝑦 ℓ × 𝑒)) but 𝑦 ℎ = RN(𝑦).
Of course, desirable properties of the test (and of the value of 𝑒) are:

• make no false positives;

• yield the least possible number of false negatives.

The first property is self-evident. We want the test to be absolutely safe: we should never return a wrong value for RN(𝑦).

The second has to do with performance issues. Test failure mandates i) another computation of an approximation, ii) with a better accuracy (that will unavoidably take longer, otherwise why not use it from the very start?). The false negative cases must then be kept to a minimum for this (quick) test to be acceptable. If false negatives were too frequent, other, possibly more time consuming but more accurate, options would become relevant.

Figures 2-2, 2-3 and 2-4 are in fact a bit misleading since the length of the represented "𝑦 segment" is small, smaller indeed than 1/2 × ulp(𝑦 ℎ ). This is not necessarily true and this length depends, for a given 𝑦, on the value of 𝜖. As depicted in Figure 2345, when the "𝑦 segment" is too wide, any attempt to round 𝑦 ℎ + 𝑦 ℓ is futile.

The very notion of the correct rounding of the value of a function only makes sense if the accuracy of the approximation is sufficient.

If the relative error of the approximation is larger than 1 2 2 -𝑝+1 (or 1 2 ulp(𝑦)) = 2 -𝑝 (as in Figure 2345) it makes it impossible to correctly round. This gives us an absolute lower bound on 𝜖.

When correct rounding matters: the "main + correcting term" technique in function approximation89

In reality, we will impose an even more stringent condition on 𝜖 for reasons that will become clear in the sequel:

𝜖 < 2 -𝑝-1 .
(2.3) This is not a particular problem since, in all practical situations, 𝜖 will be smaller than that 10 .

F

|(𝑦 ℎ + 𝑦 ℓ ) -𝑦| < 𝜖 × |𝑦| (2.4)
and

𝜖 < 2 -𝑝-1 , 𝑦 ℎ = RN(𝑦 ℎ + 𝑦 ℓ ). (2.5)
Can we find a quick test that allows us to determine if 𝑦 ℎ = RN(𝑦)?

Notice that (2.4) implies that both 𝑦 and 𝑦 ℎ have the same sign. In the sequel, without loss of generality, we will assume that they are both positive.

Up to now we have essentially been toying with the idea of a rounding test. We will see in the following how it has actually been used (and still is) in the context of the correct rounding of function approximation.

Ziv's rounding test, crlibm and the "magic constant"

In 1991 A. Ziv published the so-called "Accurate Portable Mathlib" (or libultim) library of correctly ("to the last bit") rounded elementary functions and the companion paper [START_REF] Ziv | Fast Evaluation of Elementary Mathematical Functions with Correctly Rounded Last Bit[END_REF].

In that article, he elaborates on a (possibly) two-staged process to compute an approximation:

• a "quick" and "low precision" algorithm that yields two numbers 𝑓 ℓ and 𝑏 (in Ziv's notations);

𝑏 being a few orders of magnitude smaller than 𝑓 ℓ and the result being RN(𝑓 ℓ + 𝑏), if the exact sum 𝑓 ℓ + 𝑏 does not exhibits the stigmas of a hard-to-round case (see §1.6.3.2, p. 59 for hardness-to-round semiology);

• a set of increasingly high precision but slower algorithms, until a sufficient precision is reached.

The article does not enter into details on how to perform the check in the first step.

The problem is mentioned, under the form we have stated it, and is dealt with more details in another article [START_REF] De Dinechin | Towards the Post-Ultimate Libm[END_REF] Their solution to the problem is a test in the form of a product with a "magic constant" 𝑒:

𝑦 ℎ = RN(𝑦 ℎ + RN(𝑦 ℓ × 𝑒)) ⇒ 𝑦 ℎ = RN(𝑦) (2.6)
In the sequel, we will call it Ziv's rounding test.

It is discussed also at length again in the crlibm [START_REF]CRLlibm[END_REF] documentation. Possible values of 𝑒 and proofs are given.

Nevertheless, this could not be considered as the last word on the issue. Notably because:

• the question was only examined in the case of IEEE binary64 values for 𝑦 ℎ and 𝑦 ℓ (and the rounding to IEEE binary64);

• the subnormal situation was not dealt with;

• the documentation itself mentioned that FMA usage should be investigated (and erroneously leaned to the opinion that it should not be used at all); for a presentation about FMA, see §1.5.4, p. 48.

Before proceeding to the next section we will make the following remarks, based on the monotonicity of the function 𝑦 → RN(𝑦).

Remark 2. if (𝑦, 𝑦 ℎ , 𝑦 ℓ ) is a false negative for Ziv's rounding test with constant 𝑒, then it will be a false negative with any constant 𝑒 ′ > 𝑒 (i.e. the larger the constant 𝑒, the more false negatives will show up).

Remark 3. if (𝑦, 𝑦 ℎ , 𝑦 ℓ ) is a false positive for Ziv's rounding test with constant 𝑒, then it will be a false positive with any constant 𝑒 ′ < 𝑒 (i.e. the smaller the constant 𝑒, the more false positives will show up).

It follows that our goal is, given 𝜖 and F 2,𝑝,𝑒𝑚𝑖𝑛,𝑒𝑚𝑎𝑥 , to find the smallest value of 𝑒 that yields no false positive.

The reader has noticed that in our goal definition we surreptitiously limit ourselves to the radix-2 case. A general theory (at least an extension to radix-10) of Ziv's rounding test would of course be more intellectually satisfactory. Indeed, as will be seen in the sequel, this matter is very radixdependent. We face here a contradiction between tight bounds on 𝑒 for some particular radix or "universal" but larger ones. Aside from its theoretical interest, the clarification of Ziv's rounding test has practical applications, mainly in the field of scientific computing. At the moment (and for the foreseeable future) these will essentially be carried on in a radix-2 context. Nevertheless the outlined approach will be as general as possible (and as practical) in three directions:

• the floating-point precision 𝑝;

• the relative error 𝜖;

• the consideration given to the subnormal case.

Furthermore, insights are given for situations where the FMA operation is available.

All together, this explains why we focus on this case. At the same time the acknowledgement of this limitation points towards possible directions for future work.

Breaking the magic spell: mostly provable near optimal constants

As we have seen, Ziv's rounding test is used in some form or another in various correctly-rounded elementary functions floating-point libraries. We would like to improve on the efficiency and reliability of these libraries by providing an optimal (or, at least, near-optimal) value of constant 𝑒. This could also be used in future (or other existing) libraries that would contemplate using Ziv's rounding test as it is particularly appealing thanks to its simplicity: three 11 elementary operations (two only, when an FMA instruction is available).

For 𝑦 ∈ R, 𝑦 ℎ , 𝑦 ℓ ∈ F 2,𝑝,𝑒min,𝑒max and 𝜖 < 2 -𝑝-1 verifying:

• |𝑦 ℎ + 𝑦 ℓ -𝑦| < |𝜖 × 𝑦|; Notice: this implies that 𝑦 ℎ and 𝑦 have the same sign; without loss of generality will assume them positive;

• 𝑦 ℎ = RN(𝑦 ℎ + 𝑦 ℓ ).
We want the value of 𝑒 to be such that:

𝑦 ℎ = RN(𝑦 ℎ + RN(𝑦 ℓ × 𝑒)) ⇒ 𝑦 ℎ = RN(𝑦)
More precisely, from a constructive perspective, we are looking for an expression that links 𝑒 to the other global parameters of the problem (as 𝑝 and 𝜖), and such that we can compute its (near) optimal value once for all for this set of parameters.

Preliminary properties

We will start by a set of properties that will be used in the forthcoming developments. In most of them we try to find bounds on different aspects of the problem that will only use what is actually known to us: 𝑦 ℎ , 𝑦 ℓ , 𝑝, and 𝜖.

Notice first that, in our introductory sketches and discussion, we extensively used the [𝑦 × (1 -𝜖), 𝑦 ×

(1 + 𝜖)] segment (the "𝑦 segment") in a somewhat omniscient "God's view" of the problem. As "mere mortals" we cannot do that here since this segment is unknown to us, just as the value of 𝑦 is. Our first task will be to give a bound on |𝑦 ℎ -𝑦| based on what we actually know.

|𝑦 ℎ -𝑦| = |𝑦 ℎ + 𝑦 ℓ -𝑦 -𝑦 ℓ | |(𝑦 ℎ + 𝑦 ℓ ) -𝑦| + |𝑦 ℓ |.
Hence, from (2.4):

|𝑦 ℎ -𝑦| < 𝜖 × |𝑦| + |𝑦 ℓ |. (2.7)
Notice now that from the definition of the relative error,

⃒ ⃒ ⃒ ⃒ 𝑦 -(𝑦 ℎ + 𝑦 ℓ ) 𝑦 ⃒ ⃒ ⃒ ⃒
, and as we assume 𝑦 0:

𝑦 < 𝑦 ℎ + 𝑦 ℓ 1 -𝜖 . (2.8)
Combining (2.7) and (2.8), we can deduce:

|𝑦 ℎ -𝑦| < 𝜖 1 -𝜖 × (𝑦 ℎ + 𝑦 ℓ ) + |𝑦 ℓ |. (2.9)
This gives us the wanted bound on |𝑦 ℎ -𝑦|.

This bound is the sum of two terms. The second one is an absolute term (it also is an absolute value but this is not the point here). The first one is a product between the computed value, 𝑦 ℎ + 𝑦 ℓ , and the factor 𝜖 1 -𝜖 that we could call the "reverse relative error" (as opposed to the "direct relative error" 𝜖).

Put in another way, we could say that 𝜖 1 -𝜖 is a relative error in the "𝑦 ℎ + 𝑦 ℓ perspective" whereas 𝜖 is the relative error in the "𝑦 perspective". It really makes a difference, as can be seen in the following example, also illustrated by Figure 23456.

Figure 23456: "God's view" (at the top) vs "mere mortal's view" (at the bottom) of an approximation and rounding problem with 𝑦 0. In this extreme case 𝑦 ℎ + 𝑦 ℓ is very close to the upper bound of the "𝑦 segment". Since the bound computed in the "mortal's view" realm by adding

𝜖 1 -𝜖 × (𝑦 ℎ + 𝑦 ℓ ) to 𝑦 ℎ + 𝑦 ℓ
is beyond the midpoint, we can do nothing but erroneously conclude that the computation should be restarted with a higher accuracy. This layout shows that false negatives can not be totally avoided.

Let us now examine a numerical example, with 𝑦 0, based on the following parameters:

• precision 𝑝 = 53 (IEEE-754 binary64) ;

• 𝜖 = 2 -56 (unrealistically large, but for demonstration purposes).

Suppose now that we have the following values:

• 𝑦 ℎ = 1.5, or 1.1 • 2 0 , in "binary";

• 𝑦 ℓ = 2 -54 + 2 -55 + 2 -56 + 2 -57 , i.e. 1.111 • 2 -54 ; • 𝑦 = 1.5 + 2 -54 + 2 -55 .
It is very easy to verify that the following conditions:

• 𝜖 < 2 -53-1 ; • (1 -𝜖) 𝑦 < 𝑦 ℎ + 𝑦 ℓ < (1 + 𝜖) 𝑦; • 𝑦 ℎ = RN(𝑦 ℎ + 𝑦 ℓ )
are matched.

We have:

• 𝜖 × 𝑦 ≈ 1.1 • 2 -56 + 1.1 • 2 -110 ≈ 3 32 ulp(𝑦 ℎ ); • 𝜖 1 -𝜖 (𝑦 ℎ + 𝑦 ℓ ) ≈ 1.1 • 2 -56 + 1.001 • 2 -109 ≈ 3 32 ulp(𝑦 ℎ ).
The difference between these two values is small but cannot be ignored. But the most important element to take into consideration is the starting point of the bound computation, in "𝑦 segment" case 𝜖 × 𝑦 is added to the value of 𝑦 while in the other case, 𝜖 1 -𝜖 (𝑦 ℎ + 𝑦 ℓ ) is added at the "tip" of 𝑦 ℎ + 𝑦 ℓ .

As can be seen from Figure 2-6 reasoning on bounds will, in our example, produces a false negative (a situation where 𝑦 ℎ = RN(𝑦) but where we conclude that the computation should be restarted with a higher accuracy). It also shows why, in a very informal and pictorial form, without additional information, a perfect (no false positives, no false negatives) rounding test is impossible.

We can also see why some increase in the accuracy of the approximation may pay for itself as the number of false negative situations (and the number of extra computations associated with them)

decreases. We will come back to this topic with experimental results.

The different cases

Our goal is to find an expression to compute 𝑒. From our problem statement, we know that 𝑒 1.

As we will see, different situations regarding:

• the signs of 𝑦 -𝑦 ℎ and 𝑦 ℓ are different;

• if 𝑦 ℎ is a power of 2 or not when the signs of 𝑦 -𝑦 ℎ and 𝑦 ℓ are the same will give us different lower bounds for 𝑒. The value we will actually use will be the maximum of all these bounds.

If 𝑦 -𝑦 ℎ and 𝑦 ℓ have different signs

The following property simplifies the problem, but it should not be regarded per se as a possible test. In fact, as we will discover, this situation is of no help for the computation of 𝑒 since it places no new constraint upon it.

Suppose 𝑦 -𝑦 ℎ and 𝑦 ℓ have different signs and, as stated before,

𝑦 ℓ < 1 2 × ulp(𝑦 ℎ ) and 𝜖 < 2 -𝑝-1 . Property 2.1. if 𝑦 -𝑦 ℎ and 𝑦 ℓ have different signs then 𝑦 ℎ = RN(𝑦).
Proof. If 𝑦 -𝑦 ℎ and 𝑦 ℓ have different signs then either:

• 𝑦 𝑦 ℎ 𝑦 ℎ + 𝑦 ℓ , if 𝑦 ℎ < 0 and 𝑦 ℓ 0; • (𝑦 ℎ + 𝑦 ℓ ) 𝑦 ℎ 𝑦, if 𝑦 ℎ > 0 and 𝑦 ℓ 0 see Figure 2-7.
At any rate 𝑦 is closer to 𝑦 ℎ than to (𝑦 ℎ + 𝑦 ℓ ). Combined with (2.4), this also implies that |𝑦 ℎ -𝑦| < |𝑦| × 𝜖.

Since |𝜖| < 2 -𝑝-1 , this implies that 𝑦 ℎ = RN(𝑦).

(𝑦 ℎ + 𝑦 ℓ ) 𝑦 ℎ 𝑦, if 𝑦 ℎ > 0 and 𝑦 ℓ 0.
In this situation, 𝑦 can only live in the "𝑦 permitted segment". Hence, and despite a large value of 𝜖, 𝑦 ℎ = RN(𝑦).

As a consequence, in this situation, with any value of 𝑒 1

𝑦 ℎ = RN(𝑦 ℎ + RN(𝑦 ℓ × 𝑒)) ⇒ 𝑦 ℎ = RN(𝑦).
No new lower bound, other than that already present in the problem statement, can be computed from this situation.

When 𝑦 ℎ is not a power of 2

From now on, we consider that 𝑦 -𝑦 ℎ and 𝑦 ℓ have the same sign. Let us give a set of properties that apply when 𝑦 ℎ is not a power of two. Another one for the case where 𝑦 ℎ is a power of two will be given in the next subsection.

The first one gives a bound on 𝑦 ℓ , solely based on the values of 𝑦 ℎ and 𝜖, leaving 𝑦 out of the picture, for 𝑦 ℎ = RN(𝑦).

Property 2.2. Assume that 𝑦 ℎ is not a power of two. If

|𝑦 ℓ | 1 2 ulp(𝑦 ℎ ) × (1 -𝜖) -𝑦 ℎ × 𝜖 then 𝑦 ℎ = RN(𝑦) See Figure 2-8 Figure 2-8: |𝑦 ℓ | 1 2 ulp(𝑦 ℎ ) × (1 -𝜖) -𝑦 ℎ × 𝜖.
Here 𝑦 ℎ and 𝑦 ℓ are both > 0.

Proof.

If |𝑦 ℓ | 1 2 ulp(𝑦 ℎ ) × (1 -𝜖) -𝑦 ℎ × 𝜖,
we can also say that

(1 -𝜖 + 𝜖) × |𝑦 ℓ | 1 2 ulp(𝑦 ℎ ) × (1 -𝜖) -𝑦 ℎ × 𝜖. Then ( 1 + 𝜖 1 -𝜖 ) × |𝑦 ℓ | 1 2 ulp(𝑦 ℎ ) - 𝜖 1 -𝜖 × 𝑦 ℎ .
In turn

( 𝜖 1 -𝜖 ) × 𝑦 ℓ + |𝑦 ℓ | 1 2 ulp(𝑦 ℎ ) - 𝜖 1 -𝜖 × 𝑦 ℎ .
This implies:

( 𝜖 1 -𝜖 ) × (𝑦 ℎ + 𝑦 ℓ ) + |𝑦 ℓ | 1 2 ulp(𝑦 ℎ ).
Eventually, using (2.9):

|𝑦 ℎ -𝑦| < 1 2 ulp(𝑦 ℎ ).
Hence:

𝑦 ℎ = RN(𝑦).
Are there many 𝑦 ℓ values left with the bound we impose on it?

It is easy to see how the value of 𝜖 impacts that of the 1 2 ulp(𝑦 ℎ ) × (1 -𝜖) term. Since 𝜖 < 2 -𝑝-1 , under no circumstance it can be smaller than 1 2 ulp(𝑦 ℎ ) -

( 1 2 ulp(𝑦 ℎ ) × 2 -𝑝-1
). This is indeed smaller than 1 2 ulp(𝑦 ℎ ) but by a narrow margin, for practical values of 𝑝.

Notice conversely how |𝑦 ℎ × 𝜖| is bounded. Suppose 𝑦 ℎ belongs to the [2 𝑚 , 2 𝑚+1 ) binade and 𝜖 = 2 -𝑎 where 𝑎 > 𝑝 + 1. We have:

ulp(𝑦 ℎ ) = 2 𝑚-𝑝+1 .
We also have

|𝑦 ℎ × 𝜖| < 2 𝑚+1 × 2 -𝑎 < 2 𝑚+1 × 2 -𝑝-1 = 2 𝑚-𝑝 = 1 2 ulp(𝑦 ℎ ).
For very large values of 𝜖 (𝑎 close to -𝑝 -1) and large values of 𝑦 ℎ (in the sense of close to the binade upper bound 2 𝑚+1 ) there may be no acceptable value of 𝑦 ℓ left . But as soon a 𝜖 decreases, this gives more and more room for 𝑦 ℓ .

We are going now to find a bound on |𝑦 ℓ | based on some hypothetical values of 𝑒 > 1, the constant used in Ziv's rounding test, should it exist. The other parameters of the bound expression will be problem parameters as well (precision 𝑝, approximation accuracy 𝜖).

At some point, our reasoning only works if we assume that 1 2 ulp(𝑦 ℎ ) is in the normal range. That's why this condition appears in our hypothesis list. Property 2.3. Assume that 𝑦 ℎ is not a power of 2. Let 𝑒 be a nonnegative floating-point number.

If 1 2 ulp(𝑦 ℎ ) is in the normal range, then if

𝑦 ℎ = RN(𝑦 ℎ + RN(𝑦 ℓ × 𝑒)),
then

|𝑦 ℓ | (1 + 2 -𝑝 ) × ulp(𝑦 ℎ ) 2𝑒 .
Proof. From 𝑦 ℎ = RN(𝑦 ℎ + RN(𝑦 ℓ × 𝑒)), since 𝑦 ℎ is not a power of two and from Property 1.4, p. 41:

𝑦 ℎ - 1 2 ulp(𝑦 ℎ ) 𝑦 ℎ + RN(𝑦 ℓ × 𝑒) 𝑦 ℎ + 1 2 ulp(𝑦 ℎ ).
This implies

|RN(𝑦 ℓ × 𝑒)| 1 2 ulp(𝑦 ℎ ).
(2.10)

From Property 1.3, p. 41, we evidently have

|RN(𝑦 ℓ × 𝑒)| - 1 2 ulp(RN(𝑦 ℓ × 𝑒)) ≤ |𝑦 ℓ × 𝑒| ≤ |RN(𝑦 ℓ × 𝑒)| + 1 2 ulp(RN(𝑦 ℓ × 𝑒)).
As obviously, we have:

1 2 ulp (RN(𝑦 ℓ × 𝑒)) 1 2 ulp ( 1 2 ulp (𝑦 ℎ ) ) .
From the definition of the ulp() function (def. 1.7, p. 39) and (2.10), and since

1 2 ulp(𝑦 ℎ ) is in the normal range ulp ( 1 2 ulp(𝑦 ℎ ) ) = 2 -𝑝+1 1 2 ulp (𝑦 ℎ ) . Finally 1 2 ulp (RN(𝑦 ℓ × 𝑒)) 2 -𝑝 × 1 2 ulp (𝑦 ℎ ) . (2.11)
From (2.10) and (2.11), it follows:

|𝑦 ℎ × 𝑒| (1 + 2 -𝑝 ) × 1 2 ulp(𝑦 ℎ ).
Combining Properties 2.2 and 2.3 if

(1 + 2 -𝑝 ) × ulp(𝑦 ℓ ) 2𝑒 1 2 ulp(𝑦 ℎ ) (1 -𝜖) -𝑦 ℎ × 𝜖, (2.12)
then

𝑦 ℎ = RN(𝑦 ℎ + RN(𝑦 ℎ × 𝑒)) ⇒ 𝑦 ℎ = RN(𝑦).
Condition 2.12 is equivalent to:

𝑒 (1 + 2 -𝑝 ) × ulp(𝑦 ℎ ) ulp(𝑦 ℎ ) (1 -𝜖) -2𝑦 ℎ × 𝜖 .
Notice that this lower bound on 𝑒 still depends on the value of 𝑦 ℎ . It would be convenient to get rid of it in order to obtain one that would only depend on parameters of the problem. The maximum value of this bound would give us a minimum value for 𝑒.

... If 𝑦 ℎ is in the normal range, we can write:

ulp(𝑦 ℎ ) = 𝜉 × 𝑦 ℎ × 2 -𝑝 , with 1 < 𝜉 2.
See Figure 23456789.

Hence:

(1 + 2 -𝑝 ) × ulp(𝑦 ℎ ) ulp(𝑦 ℎ ) × (1 -𝜖) -2𝑦 ℎ × 𝜖 = (1 + 2 -𝑝 ) × 𝜉 𝜉 × (1 -𝜖) -2 𝑝+1 × 𝜖 .
Our lower bound can be rewritten as:

𝑒 (1 + 2 -𝑝 ) × 𝜉 𝜉 × (1 -𝜖) -2 𝑝+1 × 𝜖 .
And we can try to find for which values of 𝜉 the right hand expression is maximized.

First of all, we want to make sure our fractional bound is always defined and positive, hence the denominator of the expression must be strictly positive (the numerator always is), setting conditions as necessary.

In other words:

𝜉 (1 -𝜖) -2 𝑝+1 × 𝜖 > 0.
Chapter 2. A better understanding and control of Ziv's rounding test

The worst case is when 𝜉 is close to 1. Let us set 𝜉 = 1. We then have:

1 -𝜖 > 2 𝑝+1 × 𝜖
We can deduce:

1 2 𝑝+1 + 1 > 𝜖. (2.13)
Incidentally, this condition is very close to that on 𝜖 in the problem statement. The small difference comes from the fact that we identified 𝜉 to 1, which is never actually the case.

Let us consider now function Ξ(𝜉) defined as:

Ξ(𝜉) = (1 + 2 -𝑝 ) 𝜉 (1 -𝜖) 𝜉 -2 𝑝+1 × 𝜖 . (2.14)
We can rewrite it as

Ξ(𝜉) = 𝑎𝜉 + 𝑏 𝑐𝜉 + 𝑑
where:

• 𝑎 = 1 + 2 -𝑝 ;
• 𝑏 = 0;

• 𝑐 = 1 -𝜖;

• 𝑑 = -2 𝑝+1 𝜖.
From calculus rules, we have

Ξ ′ (𝜉) = ⃒ ⃒ ⃒ ⃒ ⃒ ⃒ 𝑎 𝑏 𝑐 𝑑 ⃒ ⃒ ⃒ ⃒ ⃒ ⃒ 𝜉 (𝑐𝜉 + 𝑑) 2 .
We are only interested in the sign of the derivative. The denominator is positive, which leaves us with the question of the sign of the numerator, made of the single 𝑎𝑑𝜉 term since 𝑏 = 0, to deal with. We have:

𝑎𝑑𝜉 = (1 + 2 -𝑝 ) × (-2 𝑝+1 𝜖) 𝜉 < 0 for 1 + 2 -𝑝 0, -2 𝑝+1 𝜖 < 0 and 𝜉 ∈ (1, 2].
Under Condition 2.13, function Ξ is decreasing over the interval [START_REF] Akhavi | Speeding-up Lattice Reduction with Random Projections[END_REF][START_REF] Albrecht | fplll-4.0, a floating-point LLL implementation[END_REF].

Hence it reaches its maximum at 1.

From the preceding we can deduce the following property:

Property 2.4. Assume :

• 𝑦 ℎ is not a power of 2;

• 1 2 ulp(𝑦 ℓ ) is in the normal range. If 𝑒 ≥ 1 + 2 -𝑝 1 -𝜖 -2 𝑝+1 𝜖 then 𝑦 ℎ = RN(𝑦 ℎ + RN(𝑦 ℓ × 𝑒)) ⇒ 𝑦 ℎ = RN(𝑦)
When 𝑦 ℎ is a power of 2 This case will be broken down into a string of sub-cases.

On some instances detailed below the previous result can be applied straight away.

We will start with the situation where 𝑦 𝑦 ℎ and 𝑦 ℓ 0, still remembering of the 𝑦 0 and 𝑦 ℎ 0 assumptions (see Figure 2345678910). This "right hand side" of a power of 2 configuration does not differ from the non-power of 2 situation. We have:

𝑦 -𝑦 ℎ 1 2 ulp(𝑦 ℎ ) ⇒ 𝑦 ℎ = RN(𝑦) (2.15)
and, whatever the value of 𝑒 1 is, We also have: if

if 𝑦 ℎ = RN(𝑦 ℎ + RN(𝑦 ℓ × 𝑒)) then 𝑦 ℎ 𝑦 ℎ + RN(𝑦 ℓ × 𝑒) 𝑦 ℎ + 1 2 ulp(𝑦 ℎ ). ( 2
(𝑦 ℎ = RN(𝑦 ℎ + RN(𝑦 ℓ × 𝑒)) 𝑡ℎ𝑒𝑛 𝑦 ℎ 𝑦 ℎ + RN(𝑦 ℓ × 𝑒) 𝑦 ℎ + 1 2 ulp(𝑦 ℎ ).
We are left now with the case where 𝑦 𝑦 ℎ and 𝑦 ℓ 0. Since 𝑦 ℎ is a power of 2, we are in the peculiar instance where ulp(𝑦 ℎ ) = 2 -𝑝+1 𝑦 ℎ .

Property 2.5. Assume that 𝑦 ℎ is a power of 2, that 𝑦 𝑦 ℎ , and

𝑦 ℓ 0. If |𝑦 ℓ | 𝑦 ℎ × 2 -𝑝+1 - 𝜖 1 -𝜖 1 - 𝜖 1 -𝜖 (2.17) then 𝑦 ℎ = RN(𝑦).
This property plays the same part as Property 2.2 in the non-power of 2 case. But since the "rounding distance to 𝑦 ℎ " is twice as small on the "left side" as it is on the "right side", the condition on 𝑦 ℓ has to be stiffer (see .

Figure 2-11: Here 𝑦 ℎ is a power of 2, 𝑦 𝑦 ℎ and 𝑦 ℓ 0. We also have

|𝑦 ℓ | 𝑦 ℎ × 2 -𝑝+1 - 𝜖 1 -𝜖 1 - 𝜖 1 -𝜖 .
This guarantees, even in the "worst case" depicted here, where 𝑦 ℓ is very close to the upper bound of the "𝑦 segment" (but still inside it), that we have 𝑦 ℎ = RN(𝑦).

Notice that Condition 2.17 can not be satisfied if 2 -𝑝+1 -𝜖 1 -𝜖 0. It implies again, see (2.13), that 𝜖 should be smaller than

1 1 + 2 𝑝+1 .
Proof. If (2.17) is satisfied, then:

|𝑦 ℓ | × ( 1 - 𝜖 1 -𝜖 ) 𝑦 ℎ × ( 2 -𝑝-1 - 𝜖 1 -𝜖 ) .
In other terms:

|𝑦 ℓ | + (𝑦 ℎ -|𝑦 ℓ |) × 𝜖 1 -𝜖 𝑦 ℎ × 2 -𝑝-1 .
Notice that, from our assumptions, |𝑦 ℓ | = -𝑦 ℓ , so we can state:

|𝑦 ℓ | + (𝑦 ℎ + 𝑦 ℓ ) × 𝜖 1 -𝜖 𝑦 ℎ × 2 -𝑝-1 .
That implies, using (2.9) and ulp(𝑦 ℎ ) = 2 -𝑝+1 𝑦 ℎ (as 𝑦 ℎ is exactly a power of two), that:

0 𝑦 ℎ -𝑦 𝑦 ℎ × 2 -𝑝-1 = 1 4 ulp(𝑦 ℎ ).
Finally:

𝑦 ℎ = RN(𝑦).
Notice that condition 𝑦 ℎ -𝑦 1 4 ulp(𝑦 ℎ ) is absolutely necessary here, since from the milder (and "usual") condition 𝑦 ℎ -𝑦 1 2 ulp(𝑦 ℎ ) we could not conclude 𝑦 ℎ = RN(𝑦), as 𝑦 ℎ is exactly a power of two.

We have obtained a bound on |𝑦 ℓ | in terms of 𝑦 ℎ , the precision 𝑝 and the approximation accuracy 𝜖. We are going to give another bound on |𝑦 ℓ | in terms of 𝑦 ℎ , the precision 𝑝, and on some hypothetical 𝑒 that would be used in Ziv's rounding test.

Property 2.6. Assume that 𝑦 ℎ is a power of 2, 𝑦 𝑦 ℎ , 𝑦 ℓ 0, and that

2 -𝑝-1 𝑦 ℎ = 1 4 ulp(𝑦 ℎ ) is a normal number. If 𝑦 ℎ = RN(𝑦 ℎ + RN(𝑦 ℓ × 𝑒)), (2.18)
then

|𝑦 ℓ | (1 + 2 -𝑝 ) × 2 -𝑝-1 × 𝑦 ℎ 𝑒 . ( 2

.19)

Proof. As 𝑦 ℎ is a power of 2, (2.18) implies:

𝑦 ℎ - 1 4 ulp(𝑦 ℎ ) 𝑦 ℎ + RN(𝑦 ℓ × 𝑒) 𝑦 ℎ .
Since ulp(𝑦 ℎ ) = 2 -𝑝+1 𝑦 ℎ exactly, as 𝑦 ℎ is a power of 2, it follows:

𝑦 ℎ -2 -2 × 2 -𝑝+1 × 𝑦 ℎ 𝑦 ℎ + RN(𝑦 ℓ × 𝑒) 𝑦 ℎ .
That is:

-2 -𝑝-1 × 𝑦 ℎ RN(𝑦 ℓ × 𝑒) 0.
If 2 -𝑝-1 𝑦 ℎ is a normal number, then:

|𝑦 ℓ × 𝑒| 2 -𝑝-1 𝑦 ℎ + 1 2 ulp(2 -𝑝-1 𝑦 ℎ ).
More precisely:

|𝑦 ℓ × 𝑒| 2 -𝑝-1 𝑦 ℎ + 2 -𝑝 × 2 -𝑝-1 𝑦 ℎ = (1 + 2 -𝑝 ) × 2 -𝑝-1 𝑦 ℎ .
Finally (remembering that 𝑒 > 0):

|𝑦 ℓ | (1 + 2 -𝑝 ) × 2 -𝑝-1 𝑦 ℎ 𝑒 .
We are ready now, combining Properties 2.5 and 2.6 and previous remarks, to give a bound on 𝑒 in terms of precision 𝑝 and accuracy 𝜖.

Property 2.7. Assume that 𝑦 ℎ is a power of 2, that 1 4 ulp(𝑦 ℎ ) is a normal number, and that 𝜖 <

1 1 + 2 𝑝+1 . If 𝑒 (1 + 2 -𝑝 ) × (1 -2𝜖) 1 -𝜖 -2 𝑝+1 𝜖 (2.20) then 𝑦 ℎ = RN(𝑦 ℎ + RN(𝑦 ℓ × 𝑒)) ⇒ 𝑦 ℎ = RN(𝑦).
Proof. Since most of the cases have been dealt with before by equating them to generic cases or non-power of 2 cases, all we have to do here is to check the 𝑦 𝑦 ℎ and 𝑦 ℓ 0 case.

Properties 2.5 and 2.6 both give an upper bound on |𝑦 ℓ |. We are going to combine them in order to find the wanted lower bound on 𝑒. Since 𝑒 is in the denominator of Expression (2.19), if we let it shrink to arbitrary values, the upper bound on 𝑦 ℓ given in (2.19) will overrun that given by (2.17).

To prevent that we have to bound Expression (2.19) by Expression (2.17):

(1 + 2 -𝑝 ) × 2 -𝑝-1 𝑦 ℎ 𝑒 𝑦 ℎ × 2 -𝑝+1 - 𝜖 1 -𝜖 1 - 𝜖 1 -𝜖 .
The idea is, from that inequality, to find a lower bound for 𝑒. From there, it turns out that with elementary calculus, we fall back on Expression (2.20) which is such a bound.

The values of 𝑒 that allow for a correct Ziv's rounding test

The bounds obtained for 𝑒 in Properties 2.4 (when 𝑦 ℎ is not a power of 2) and 2.7 (when 𝑦 ℎ actually is a power of 2) are different, 𝑒

(1 + 2 -𝑝 ) 1 -𝜖 -2 𝑝+1 𝜖 and 𝑒 (1 + 2 -𝑝 ) × (1 -2𝜖) 1 -𝜖 -2 𝑝+1 𝜖 respectively.
From that, taking the largest of the two, we can now deduce Theorem 2.1. Assume that:

• 𝜖 < 1 1 + 2 𝑝+1 ; • |(𝑦 ℎ + 𝑦 ℓ ) -𝑦| < 𝜖 × |𝑦|; • 𝑦 ℎ = RN(𝑦 ℎ + 𝑦 ℓ );
• 𝑦 ℎ is a floating-point number such that 1 4 ulp(𝑦 ℎ ) is in the normal range;

if

𝑒 (1 + 2 -𝑝 ) 1 -𝜖 -2 𝑝+1 𝜖 then 𝑦 ℎ = RN(𝑦 ℎ + RN(𝑦 ℓ × 𝑒)) ⇒ 𝑦 ℎ = RN(𝑦).
This upper bound is somewhat theoretical in the sense that we did not care to check whether, for some floating-point system F,

(1 + 2 -𝑝 ) 1 -𝜖 -2 𝑝+1 𝜖
actually is an element of F.

It turns out that this expression can not be decently computed inside F. For instance, in this context, sub-expressions like (1 + 2 -𝑝 ) will always round to 1. We can't rely on the 2 𝑝+1 𝜖 to save our neck for "small" values of 𝜖 (𝜖 2 -2𝑝-1 ). Neither shall we exactly compute 1 -𝜖 for any value of 𝜖 < 1 1 + 2 𝑝+1 , as the hypothesis of Theorem 2.1 mandate.

Expression 1 + 2 -𝑝 1 -𝜖 -2 𝑝+1 𝜖
will then have to be computed in a higher precision floating-point arithmetic system (or rational arithmetic system, provided that 𝜖 is expressed as a rational number) than that of F and then the result will be rounded up into F to yield an acceptable value for 𝑒 (that is an element of F larger than or equal to

(1 + 2 -𝑝 ) 1 -𝜖 -2 𝑝+1 𝜖 ).
Hence, in practice, the rounding test will be performed with:

𝑒 = RU ( 1 + 2 -𝑝 1 -𝜖 -2 𝑝+1 𝜖 )
as computed in some high precision arithmetic system at hand and rounded to nearest to an element of F. This is not actually an issue since, in the context of function approximation, one must make use of some extended precision framework (relatively to that of F) to compute the function approximants with a sufficient accuracy, and that computation is done once for all when designing a function evaluation program that, itself, will likely run millions of times.

How good is this value?

We will not make the suspense last too long. The bound is excellent but we cannot prove it to be optimal in any circumstance, even under the conditions we have given (such as 1 4 ulp(𝑦 ℎ ) should be in the normal range). However we will provide here some evidence to support our near-optimality claims. Experimental result will add up later on.

It is important to stress here that corner cases matter a lot and should not be seen as mere curiosities. Ziv's rounding test is meant to be quick. Going through a contrived nest of conditionals thwarts the whole purpose. The values for 𝑒 should work without any other case splitting than the one we introduced by requesting that the value of 1 4 ulp(𝑦 ℎ ) be in the normal range. We will come back later to this subject.

2.5.3.1

For some values of 𝜖 and a generic value for 𝑝 it is possible to prove our 𝑒

near-optimal

We will first consider a somewhat particular form of 𝜖. The peculiarities stem from technical reasons that will become clear in the sequel.

Let us consider an 𝜖 of the form

𝜖 = 2 -𝑝-𝑘+1 + 2 -3𝑝 2 -2 -𝑝 + 2 -3𝑝 , for 1 < 𝑘 < 𝑝 2 .
Let us set 𝜐 = 2 -𝑝 .

We can rewrite our expression for 𝜖 as

𝜖 = 2 -𝑘+1 𝜐 + 𝜐 3 2 -𝜐 + 𝜐 3 .
For that particular expression of 𝜖 and using the above convention for 𝜐, the minimum value of 𝑒, as given in Theorem 2.1 becomes

𝑒 min = 1 + 2 -𝑝 1 -𝜖 -2 𝑝+1 𝜖 = 1 + 𝜐 1 - ( 1 + 2 𝜐 ) × 2 -𝑘+1 𝜐 + 𝜐 3 2 -𝜐 + 𝜐 3
. This expression can be considered as a function of 𝜐. Its Taylor development can be (hopefully)

computed at 𝜐 = 0 with a computer algebra system.

As it turns out, after some simplifications,

𝑒 min = (1 + 2 -𝑝 ) 1 -𝜖 -2 𝑝+1 𝜖 = ( 2 𝑘 2 𝑘 -2 ) + ( 4 𝑘 (2 𝑘 -2) 2 ) × 𝜐 - ( -4 𝑘 + 2 1+𝑘 -8 𝑘 (2 𝑘 -2) 3 ) × 𝜐 2 + . . .
After replacing 𝜐 by its value, one gets

𝑒 min = (1 + 2 -𝑝 ) 1 -𝜖 -2 𝑝+1 𝜖 = ( 2 𝑘 2 𝑘 -2 ) + ( 4 𝑘 (2 𝑘 -2) 2 ) × 2 -𝑝 - ( -4 𝑘 + 2 1+𝑘 -8 𝑘 (2 𝑘 -2) 3 ) × 2 -2𝑝 +. . .

The first term

( 2 𝑘 2 𝑘 -2 )
can be rewritten as

( 2 𝑘 2 𝑘 -2 ) = 1 1 -2 1-𝑘
that itself can be expanded to

1 1 -2 1-𝑘 = 1 + 2 1-𝑘 + 2 2-2𝑘 + 2 3-3𝑘 + . . . .
The difference between 𝑒 min and 1 + 2 1-𝑘 is essentially packed into the 2 2-2𝑘 term as the subsequent terms are quickly decaying.

The same reasoning (very quick decrease) applies to next terms of the development of 𝑒 min , 4 𝑘 (2 𝑘 -2) 2 × 2 -𝑝 and its successors.

It turns out that we can consider 1 + 2 1-𝑘 as a very close, and yet smaller, approximation of 𝑒 min .

What happens if we take it for 𝑒 for a rounding test?

Let us check with the following example where:

• 𝑦 ℎ = 2 -2 -𝑝+1 ; • 𝑦 ℓ = 2 -𝑝 -2 -𝑝-𝑘+1 ; • 𝑦 = 2 -2 -𝑝 + 2 -3𝑝 ;
• 𝑒 = 1 + 2 -𝑘+1 , as suggested above.

We have:

• |𝑦 ℎ + 𝑦 ℓ -𝑦| < 𝜖 × |𝑦|; • 𝑦 ℎ = RN(𝑦 ℎ + 𝑦 ℓ ); • 𝑦 ℎ = RN(𝑦 ℎ + RN(𝑦 ℓ × 𝑒));
and yet 𝑦 ℎ ̸ = RN(𝑦). This demonstrates the value of 𝑒 given by Theorem 2.1, if not optimal, is very close to it. This result is generic (for it is for arbitrary values of 𝑝, though limitations are imposed on 𝑘). It can also be interesting to scrutinize what happens in particular cases.

2.5.3.2

For some particular values of 𝑝, even more can be said Let us consider the following example:

• the floating-point format is IEEE binary64 (AKA "double precision") with 𝑝 = 53;

• 𝑦 = 1461983273612937874357096965722 776934764230052409376713600323
, with RN(𝑦) = 8474569075036949 4503599627370496 ;

• 𝜖 = 2 -80 (not an unrealistic value in the context of function approximation);

• 𝑦 ℎ = 8474569075036948 4503599627370496 ;

• 𝑦 ℓ = 9007199188662643 81129638414606681695789005144064 .

Notice that 𝑦 ℎ ̸ = RN(𝑦).

It is easy (if tedious) to check that

|(𝑦 ℎ + 𝑦 ℓ ) -𝑦| < 𝜖 × |𝑦|,
and that |(𝑦 ℎ + 𝑦 ℓ ) -𝑦| is very close to the allowed maximum since

|(𝑦 ℎ + 𝑦 ℓ ) -𝑦| 𝜖 × |𝑦| ≈ 1 -2.54811 × 10 -37 .
Let us call 𝑒 * the minimum given by Theorem 2.1

𝑒 * = (1 + 2 -𝑝 ) 1 -𝜖 -2 𝑝+1 𝜖 = 1208925819614629308923904 1208925801600230665224191 .
Again, it is easy to check that, correctly,

𝑦 ℎ ̸ = RN(𝑦 ℎ + RN(𝑦 ℓ × 𝑒 * ))
If we take for 𝑒 a slightly smaller value than 𝑒 * 𝑒 = 4503599649443365 4503599627370496 with 𝑒 𝑒 * = 0.9999999900000000987640. . . then we have

𝑦 ℎ = RN(𝑦 ℎ + RN(𝑦 ℓ × 𝑒 * ))
while 𝑦 ℎ ̸ = RN(𝑦): an outrageous false positive!

From the two previous examples, we can conclude that Theorem 2.1 gives rather sharp approximations of the optimal bound.

A precision-𝑝 computable bound for 𝑒

As stated before, Theorem 2.1 assumes some high precision (higher than 𝑝) floating-point system is available to correctly compute 𝑒. We said this is not a real issue, since to approximate the function with a sufficient accuracy, one must use some high-precision tool that could also be used to compute 𝑒. But one may wonder if it is possible to give a bound, let us call it 𝑒 𝑠𝑖𝑚𝑝𝑙𝑒 because it does not rely on fancy high-precision arithmetic, that could be computed using solely the target arithmetic system and yet be an accurate one.

Assumptions and general form

The quick answer is that it can be done, under not too stringent assumptions. Possible use cases are situations where the high-precision arithmetic is not available. This often happens to the users of a floating-point mathematical library where the high-precision primitives are deeply buried into it and are not directly accessible to them for their own usage. Or if one wants to quickly compute 𝑒 on the fly for values different of 𝜖.

Our principal assumption is that 1 -2 𝑝+1 𝜖 is exactly representable in precision-𝑝 floating-point arithmetic. This can be translated into more specific terms:

• 𝜖 must be a power (or the sum of a small number of powers) of 2;

• the smallest power of 2 involved in the decomposition of 𝜖 must be larger than 2 -2𝑝 .

In the most simple situation, as it often happens in real life, 𝜖 is a power of 2 larger than 2 -2𝑝 .

We will give first a general form a 𝑝-precision computable bound for 𝑒

𝑒 𝑠𝑖𝑚𝑝𝑙𝑒 = 1 + 2 -𝑝+1 1 -2 𝑝+1 𝜖
and discuss in more details our assumptions.

Notice that, in general, 𝑒 𝑠𝑖𝑚𝑝𝑙𝑒 is not a floating-point number. It must be rounded. This issue will be dealt with below.

One can easily see the reason for our main assumption. If 1 -2 𝑝+1 𝜖 is not exactly representable, the computation of 𝑒 goes out of control and there is not much that can mathematically be said about it.

The requirement that 1 -2 𝑝+1 𝜖 has an exact representation has a cascade effect on the elements of the expression: both 2 𝑝+1 𝜖 and 𝜖 have to be exactly representable.

If we follow the chain the other way around, we start with the fact 𝜖 must be a sum of powers of 2 to be exactly representable in 𝑝 bits. If this is the case 2 𝑝+1 𝜖 will also be since this computation is merely a change of exponent of the corresponding floating-point number (no overflow can happen for any sensible value of 𝜖). For 1 -2 𝑝+1 𝜖 to be exactly representable, it takes the smallest power of 2 in the binary representation of the product of 𝜖 and 2 𝑝+1 to be larger than or equal to ulp [START_REF] Akhavi | Speeding-up Lattice Reduction with Random Projections[END_REF] for the F 2,𝑝,𝑒𝑚𝑖𝑛,𝑒𝑚𝑎𝑥 system.

Let us check with the following examples.

Examples on how our assumptions matter Example 1

Let us assume the following values:

• The floating-point number system is IEEE 754 binary64 (F 2,53,-1022,1023 );

• 𝜖 = 2 -100 + 2 -101 .
In this case 𝜖 is exactly representable in F.

𝜖 = 1.10 . . . 0 × 2 -100 .
We then have

We can therefore exactly compute 1 -2 53+1 × 𝜖 since 2 -47 2 -52 = ulp(1).

Example 2

Let us suppose now that, with the same floating-point system, 𝜖 = 2 -105 + 2 -106 + 2 -107 .

We then have

2 53+1 × 𝜖 = 2 -51 + 2 -52 + 2 -53 .
Now, we can't exactly compute 1 -2 53+1 × 𝜖 since 2 -53 ≤ 2 -52 = ulp(1).

More precise properties

From the general form given above, we will consider two more specific forms of 𝑒 𝑠𝑖𝑚𝑝𝑙𝑒 :

𝑒 𝑢𝑝 𝑠𝑖𝑚𝑝𝑙𝑒 = RU ( 1 + 2 -𝑝+1 1 -2 𝑝+1 𝜖
) , and

𝑒 𝑛𝑒𝑎𝑟𝑒𝑠𝑡 𝑠𝑖𝑚𝑝𝑙𝑒 = RN ( 1 + 2 -𝑝+1 1 -2 𝑝+1 𝜖
) .

We will give here two properties about them. In the sequel the optimal (high-precision computed) value of 𝑒 will be called 𝑒 * , which is not a floating-point number.

Lets us start with a rather general property of 𝑒 𝑢𝑝 𝑠𝑖𝑚𝑝𝑙𝑒 . For technical reasons that will become obvious in the proof, we need to (slightly) further restrict the upper bound for 𝜖 to 2 Proof. From the definition of RU () and that of ulp(1) we obviously have

1 + 2 -𝑝+1 1 -2 𝑝+1 𝜖 RU ( 1 + 2 -𝑝+1 1 -2 𝑝+1 𝜖 ) (1 + 2 -𝑝+1 ) × 1 + 2 -𝑝+1 1 -2 𝑝+1 𝜖 = (1 + 2 -𝑝+1 ) (1 + 2 -𝑝+1 ) 1 -2 𝑝+1 𝜖 Let us define 𝜌 as 𝑒 𝑢𝑝 𝑠𝑖𝑚𝑝𝑙𝑒 𝑒 * . It is clear that 1 + 2 -𝑝+1 1 -2 𝑝+1 𝜖 1 + 2 -𝑝 1 -𝜖 -2 𝑝+1 𝜖 𝜌 (1 + 2 -𝑝+1 ) × (1 + 2 -𝑝+1 ) 1 -2 𝑝+1 𝜖 1 + 2 -𝑝 1 -𝜖 -2 𝑝+1 𝜖
To make our expression more legible, let us define now 𝜔 as 1 -2 𝑝+1 𝜖. With this notation

1 -𝜖 -2 𝑝+1 𝜖 = 𝜔 -𝜖 = 𝜔 ( 1 - 𝜖 𝜔 ) .
With this new notation and the above remark, our previous expression becomes now

1 + 2 -𝑝+1 𝜔 1 + 2 -𝑝 𝜔 ( 1 - 𝜖 𝜔 ) 𝜌 (1 + 2 -𝑝+1 ) × (1 + 2 -𝑝+1 ) 1 -2 𝑝+1 𝜖 1 + 2 -𝑝 𝜔 ( 1 - 𝜖 𝜔 )
.

From this expression, simplifying by 𝜔 whenever possible,

1 + 2 -𝑝+1 1 + 2 -𝑝 ( 1 - 𝜖 𝜔 ) 𝜌 (1 + 2 -𝑝+1 ) 2 1 + 2 -𝑝 ( 1 - 𝜖 𝜔 ) .
We are going now to prove the upper bound of Property 2.8. Notice that

1 - 𝜖 𝜔 = 𝜖 1 -2 𝑝+1 𝜖 = 1 1 𝜖 -2 𝑝+1
.

As 𝜖 < 1 1 + 2 𝑝+1 we also have

0 < 1 1 𝜖 -2 𝑝+1 < 1 1 + 2 𝑝+1 -2 𝑝+1 = 1. Hence 1 - 𝜖 𝜔 < 1. Then (1 + 2 -𝑝+1 ) 2 1 + 2 -𝑝 ( 1 - 𝜖 𝜔 ) ≤ (1 + 2 -𝑝+1 ) 2 1 + 2 -𝑝 .
Notice that, on the one hand,

(1 + 4 × 2 -𝑝 ) (1 + 2 -𝑝 ) = 1 + 5 × 2 -𝑝 + 4 × 2 -2𝑝 = 1 + 5 × 2 -𝑝 + 2 -2𝑝+2 ,
and that, on the other hand,

(1 + 2 -𝑝+1 ) 2 = 1 + 4 × 2 -𝑝 + 2 -2𝑝+2 .
As 1 + 2 -𝑝 > 1, whatever 𝑝 is, we have

(1 + 2 -𝑝+1 ) 2 1 + 2 -𝑝 < 1 + 4 × 2 -𝑝 ,
and consequently

1 + 2 -𝑝+1 1 + 2 -𝑝 ( 1 - 𝜖 𝜔 ) 𝜌 < 1 + 4 × 2 -𝑝 . Now, let us make sure that 𝜌 = 𝑒 𝑢𝑝 𝑠𝑖𝑚𝑝𝑙𝑒 𝑒 * 1. For all 𝑝 1 1 + 2 -𝑝+1 1 + 2 -𝑝 = 1 + 2 -𝑝 + 2 -𝑝 1 + 2 -𝑝 = (1 + 2 -𝑝 ) + 2 -𝑝 1 + 2 -𝑝 = 1 + 2 -𝑝 1 + 2 -𝑝 .
Let us concentrate on the last term of the final sum on the previous line. We can see that

2 -𝑝 × (1 -2 -𝑝 ) (1 + 2 -𝑝 ) × (1 -2 -𝑝 ) = 2 -𝑝 -2 -2𝑝 1 -2 -2𝑝 . Since 1 -2 -2𝑝 < 1 2 -𝑝 -2 -2𝑝 1 -2 -2𝑝 2 -𝑝 -2 -2𝑝
and, putting all together,

1 + 2 -𝑝+1 1 + 2 -𝑝 1 + 2 -𝑝 -2 -2𝑝 .
From our hypothesis 𝜖 2 𝑝-3 . This implies that, as 𝜔 = 1 -2 𝑝+1 𝜖, 𝜔 3 4 and, consequently,

1 - 𝜖 𝜔 1 -3 × 2 -𝑝-1 .
Combining the first lower bound and the second upper bound

(1 + 2 -𝑝 -2 -2𝑝 ) × (1 -3 × 2 -𝑝-1 ) = 1 + 5 6 2 -𝑝 - 7 6 2 -2𝑝 + 1 6 2 -3𝑝
which is larger than 1 as soon as 𝑝 1.

Ultimately

1 𝜌 < 1 + 4 × 2 -𝑝 .
Our second property is a bit different and possibly has more practical applications. We will first limit ourselves to particular values of 𝑝, those that are very often used in actual computations: the binary interchange formats of the IEEE Standard for Floating-Point Arithmetic and the INTEL "double-extended precision" format. Secondly our property will relate to 𝑒 𝑛𝑒𝑎𝑟𝑒𝑠𝑡 𝑠𝑖𝑚𝑝𝑙𝑒 which is easier and quicker to compute since it does involve any time-consuming rounding-mode change (round-to-nearest being usually the default mode). We remind here that generally 𝑒 * is not a floating-point number. The proof of the property can be done by an enumeration of all cases and computing the numbers. Within the hypothesis of Property 2.9 it is not possible to compute a better Ziv's test constant by using Theorem 2.1. The "simple" yields a result as good as that of the "regular" one.

For the sake of completeness we will give a third and last property of the simple bound. We will also give some insights into its apparent limitations when accurate (i.e. very small values of 𝜖) approximations are computed.

Property 2.10.

If 𝜖 2 -2𝑝-2 , then 𝑒 * 𝑒 𝑛𝑒𝑎𝑟𝑒𝑠𝑡 𝑠𝑖𝑚𝑝𝑙𝑒 .
Proof. If 𝜖 2 -2𝑝-2 , then

1 = RN(1) RN(1 -2 -𝑝+1 𝜖) RN(1 -2 -𝑝+1 × 2 -2𝑝-2 ) = RN(1 -2 -𝑝-1 ) = 1.
Hence, for any 𝜖 2 -2𝑝-2 , RN

( 1 + 2 -𝑝+1 1 -2 𝑝+1 𝜖 ) = 1 + 2 -𝑝+1 .
How does it compare with

𝑒 = 1 + 2 -𝑝 1 -𝜖 -2 𝑝+1 𝜖 ? Since 1 1 -𝜖 -2 𝑝+1
𝜖 whatever the value of 𝜖 matching our hypothesis and whatever the (high) precision used to compute the last expression, we are done if we can prove that

(1 + 2 -𝑝+1 ) (1 -𝜖 -2 𝑝+1 𝜖) 1 + 2 -𝑝
Assigning 𝜖 to its maximum value 2 -2𝑝-2 , elementary computations give:

(1 + 2 -𝑝+1 ) (1 -𝜖 -2 𝑝+1 𝜖) = (1 + 2 -𝑝+1 ) (1 -2 -2𝑝-2 -2 𝑝+1 × 2 -2𝑝-2 ) = 1 + 2 -𝑝+1 -2 -3𝑝-1 -2 -𝑝-1 -5 × 2 -2𝑝-2 = 1 + 2 -𝑝 + 2 -𝑝 -2 -3𝑝-1 -2 -𝑝-1 -5 × 2 -2𝑝-2 .
At this point, the verification boils down to checking that:

2 -𝑝 -2 -3𝑝-1 -2 -𝑝-1 -5 × 2 -2𝑝-2 0, or
2 -𝑝-1 + 2 -𝑝-1 -2 -3𝑝-1 -2 -𝑝-1 -5 × 2 -2𝑝-2 0.
Eventually we can easily check that:

2 -𝑝-1 > 2 -3𝑝-1 + 8 × 2 -2𝑝-2 = 2 -3𝑝-1 + 2 -2𝑝+1
But this is not the end of the story about 𝑒 𝑛𝑒𝑎𝑟𝑒𝑠𝑡 𝑠𝑖𝑚𝑝𝑙𝑒 and high accuracy approximation. It must be noted it is stuck to the constant value 1 + 2 -𝑝+1 as soon as, when 𝜖 decreases, it reaches 2 -2𝑝-1 . One could think that this is not the case with 𝑒 * which may "freely" continue to decrease and consider that, 𝑒 𝑛𝑒𝑎𝑟𝑒𝑠𝑡 𝑠𝑖𝑚𝑝𝑙𝑒 , though safe (no false positives) becomes less and less efficient as a Ziv's rounding constant since its divergence from 𝑒 * leads to an increasing number of false negatives as 𝜖 plunges under 2 -2𝑝-2 . This is not the case since RU(𝑒 * ) itself, the actually used value, is lower bounded by 1 and is also a floating-point number. The value immediately above 1 is 1 + ulp [START_REF] Akhavi | Speeding-up Lattice Reduction with Random Projections[END_REF], which also happens to be 1 + 2 -𝑝+1 , the limit value of 𝑒 𝑛𝑒𝑎𝑟𝑒𝑠𝑡 𝑠𝑖𝑚𝑝𝑙𝑒 . When one gets approximation accuracies close to 2 -2𝑝 , the final rounding in the computation of 𝜖 * sweeps out the refinement brought in by the previous high precision evaluations.

At this point, one could rather question the relevance of Ziv's rounding test in these conditions. In fact, this questioning relates to the very idea of computing very sharp approximations (𝜖 < 2 -2𝑝-2 ) with (only) a "main term" and a single "correcting term" that together provide, at most (if no "gap" is allowed, see Figure 2-1(3)), 2𝑝 + 1 bits of precision.

If we elaborate a bit on one of our initial assumptions about 𝑦 ℎ and 𝑦 ℓ (namely 𝑦 ℎ = RN(𝑦 ℎ + 𝑦 ℓ ))

we have seen that it has twofold implication:

• |𝑦 ℓ | < 1
2 ulp(𝑦 ℎ ), if 𝑦 ℎ and 𝑦 ℓ have the same signs or 𝑦 ℎ is not a power of 2;

• |𝑦 ℓ | < 1 4 ulp(𝑦 ℎ ), if 𝑦 ℎ is a power of 2 and 𝑦 ℎ and 𝑦 ℓ have different signs.

We will not care further about the 1 2 and 1 4 difference here as we will think in terms of orders of magnitude and only consider the first case. We will not deal with the subnormal issues either.

Chapter 2. A better understanding and control of Ziv's rounding test

With these restrictions the 𝑦 ℎ + 𝑦 ℓ sum can then be seen as some kind of (2𝑝 + 1)-precision number that we can represent, when 𝑦 ℎ and 𝑦 ℓ have the same sign, in most situations (for "large" values of 𝑦 ℎ ) as:

𝑦 ℎ + 𝑦 ℓ = 1.ℎℎ • • • ℎℎℎ01ℓℓ • • • ℓℓℓ ⏟ ⏞ 2𝑝+1 bits × 2 𝑒𝑦 ℎ , where 𝑒 𝑦 ℎ is the exponent of 𝑦 ℎ ,
assuming here that 𝑦 ℓ 1/4ulp(𝑦 ℎ ).

Here the ℎℎ • • • ℎℎℎ and the ℓℓ • • • ℓℓℓ strings represent, respectively, the bits of the fraction of 𝑦 ℎ and those of the fraction of 𝑦 ℓ . We can also say that 2 𝑒𝑦 ℎ is the order of magnitude of 𝑦 ℎ and that of 𝑦 as well.

Had 𝑦 ℎ and 𝑦 ℓ different signs, the values of the bits would differ, the central bit would possibly not be 0, but the structure should remain the same.

Let us consider now the "ulp()" 12 :

ulp(𝑦 ℎ + 𝑦 ℓ ) = 2 (-2𝑝-1)+1 × 2 𝑒𝑦 ℎ = 2 -2𝑝 × 2 𝑒𝑦 ℎ .
With such a value for ulp(𝑦 ℎ + 𝑦 ℓ ), it does not make much sense to try and compute approximations of 𝑦 with an accuracy sharper than 2 -2𝑝-1 . It comes to no surprise that this limitation extends its shadow to Ziv's rounding test itself.

Additional results

If test fails, lose no hope!

As we will see soon, when the Ziv's test fails, it does not imply that RN(𝑦) can go wild, neither that |𝑦 ℎ -𝑦| can take any arbitrary value and, finally, neither that the computation of 𝑦 ℎ and 𝑦 ℓ was a complete waste of time.

What happens when the Ziv's test fails?

Our hypothesis is that

𝑦 ℎ + 𝑦 ℓ = 𝑦 × (1 + 𝛼) with |𝛼| 𝜖.
(2.21)

And we have

𝑦 ℎ ̸ = RN(𝑦 ℎ + RN(𝑒 × 𝑦 ℓ )).
In other words, we have

RN(𝑦 ℎ + RN(𝑒 × 𝑦 ℓ )) = 𝑦 𝑐 with 𝑦 𝑐 ̸ = 𝑦 ℎ .
In fact, under reasonable assumptions, the values of 𝑦 𝑐 and RN(𝑦) are quite constrained as stated in the following property:

Theorem 2.2. If
• 𝑝 2 (a very mild condition);

• 𝜖 < 1 2 𝑝+3 + 9
(this weird value has technical reasons that will explain by themselves in the proof );

• 𝑒 = RN ( 1 + 2 -𝑝 1 -𝜖 -2 𝑝+1 𝜖 )
(the smallest value of 𝑒 that is guaranteed for Ziv's test to be correct)

then, when the test fails (remember:

𝑦 ℎ ̸ = 𝑦 𝑐 = RN(𝑦 ℎ + RN(𝑒 × 𝑦 ℓ ))):
1. 𝑦 ℎ and 𝑦 𝑐 are two consecutive floating-point numbers;

2. 𝑦 ℎ 𝑦 𝑦 𝑐 or 𝑦 𝑐 𝑦 𝑦 ℎ ; 3. 𝑦 ℎ = RN(𝑦) or 𝑦 𝑐 = RN(𝑦).
Notice that (3) is only a self-evident consequence of (2), when (1) holds.

Proof. We will first check that 𝑒 never gets larger than 2. Let us consider the following family

of functions 𝐸 𝑝 (𝜖) = 1 + 2 -𝑝 1 -𝜖 -2 𝑝+1 𝜖 of 𝜖, each defined in domain [ 0, 1 2 𝑝+3 + 9 ] with 𝑝 in the [2, +∞) ⋂ N set.
We can easily see that these are increasing functions in 𝜖.

Let us consider now the 𝐸 𝑚 (𝑝) function, which computes the maximum of each of the 𝐸 𝑝 (𝜖)

family members when they reach their respective 1 2 𝑝+3 + 9 value:

𝐸 𝑚 (𝑝) = 1 + 2 -𝑝 1 - 1 + 2 𝑝+1 2 𝑝+3 + 9
One can check that the value of this function is always smaller than 2.

Among the members of the family, 𝐸 2 (𝜖) reaches the largest value for any given 𝜖.

The variable 𝜖 reaches its upper bound

1 2 𝑝+2 + 8 = 1 2 2+2 + 8
. We then have

𝐸 2 ( 1 24
) = 2.

As soon as 𝑝 2 and 𝜖 < 1 2 𝑝+2 + 8 then 𝑒 2. As we will see, the stronger condition on 𝜖 in our hypothesis will be needed later on. Yet the property 𝑒 2 will still stand.

We can assume, now on and without loss of generality, that 𝑦 ℎ and 𝑦 are both positive numbers.

Since, under our assumptions, 𝑒 2, we can deduce that

if |𝑦 ℓ | 1 8 ulp(𝑦 ℎ ) then |RN(𝑒 × 𝑦 ℓ )| 1 4 ulp(𝑦 ℎ ).
If so, then 𝑦 𝑐 = RN(𝑦 ℎ + RN(𝑒 × 𝑦 ℓ )) = 𝑦 ℎ because either:

• 𝑦 ℎ is not a power of 2 and this is straightforward;

• 𝑦 ℎ is a power of 2 and this is a consequence of the "round to nearest, ties-to-even" rule (a power of 2 always has an even integral significand, almost per definition).

In this situation,

𝑦 𝑐 ̸ = 𝑦 ℎ implies that |𝑦 ℓ | > 1 8 ulp(𝑦 ℎ ) > 2 -𝑝-3 𝑦 ℎ . And, consequently ⃒ ⃒ ⃒ ⃒ 𝑦 ℎ 𝑦 ℓ ⃒ ⃒ ⃒ ⃒ < 2 𝑝+3 . (2.22)
From our hypothesis (2.21), we can derive

𝑦 -𝑦 ℎ = 𝑦 ℓ ( 1 -𝛼 𝑦 𝑦 ℓ ) (2.23)
with |𝛼| 𝜖.

We also have, as our fundamental hypothesis, RN(𝑦 ℎ + 𝑦 ℓ ) = 𝑦 ℎ which implies

⃒ ⃒ ⃒ ⃒ 𝑦 ℎ 𝑦 ℓ ⃒ ⃒ ⃒ ⃒ 2 𝑝 . (2.24)
From (2.21) we have

𝑦 = 𝑦 ℎ + 𝑦 ℓ 1 + 𝛼 ,
from which, by using (2.24), we can deduce (remember we still assume that both 𝑦 ℎ and 𝑦 are positive numbers and

1 + 𝛼 1 -𝜖) ⃒ ⃒ ⃒ ⃒ 𝑦 𝑦 ℓ ⃒ ⃒ ⃒ ⃒ 𝑦 ℎ + |𝑦 ℓ | |𝑦 ℓ |(1 + 𝛼) 𝑦 ℎ + |𝑦 ℓ | |𝑦 ℓ |(1 -𝜖) 𝑦 ℎ (1 + 2 -𝑝 ) |𝑦 ℓ |(1 -𝜖) = 𝑦 ℎ |𝑦 ℓ | × 1 + 2 -𝑝 1 -𝜖 .
Therefore, using (2.22) we can state

⃒ ⃒ ⃒ ⃒ 𝑦 𝑦 ℓ ⃒ ⃒ ⃒ ⃒ < 2 𝑝+3 1 + 2 -𝑝 1 -𝜖 , finally |𝛼| × ⃒ ⃒ ⃒ ⃒ 𝑦 𝑦 ℓ ⃒ ⃒ ⃒ ⃒ < 2 𝑝+3 × (1 + 2 -𝑝 ) × 𝛼 1 -𝜖 2 𝑝+3 × (1 + 2 -𝑝 ) × 𝜖 1 -𝜖 . ( 2

.25)

If we express 𝜖 as

𝜖 = 1 2 𝑝+3 + 𝑘 , with 𝑘 ∈ N, then 𝜖 1 -𝜖 = 1 2 𝑝+3 + 𝑘 -1 .
We can rewrite the right hand side of (2.25) as

2 𝑝+3 × (1 + 2 -𝑝 ) × 1 2 𝑝+3 + 𝑘 -1 = 2 𝑝+3 + 8 2 𝑝+3 + 𝑘 -1 . (2.26)
We have (2.26) < 1 as soon as 𝑘 > 9. Consequently, under the same conditions and if

𝑦 𝑐 ̸ = 𝑦 ℎ , we have |𝛼| × ⃒ ⃒ ⃒ ⃒ 𝑦 𝑦 ℓ ⃒ ⃒ ⃒ ⃒ < 1, 1 -|𝛼| × ⃒ ⃒ ⃒ ⃒ 𝑦 𝑦 ℓ ⃒ ⃒ ⃒ ⃒ > 0.
Combining with (2.23) we can deduce two things:

• 𝑦 -𝑦 ℎ and 𝑦 ℓ have the same sign;

• 𝑦 - ℎ 𝑦 and 𝑦 𝑦 + ℎ .

Therefore:

• if 𝑦 ℓ > 0 then 𝑦 > 𝑦 ℎ and (straightforwardly), 𝑦 𝑐 > 𝑦 ℎ ;

• if 𝑦 ℓ < 0 then 𝑦 < 𝑦 ℎ and (straightforwardly), 𝑦 𝑐 < 𝑦 ℎ .

Eventually, when the test fails, 𝑦 is between the two consecutive floating-point numbers, 𝑦 𝑐 and 𝑦 ℎ .

From the definition of the RN() function, either:

• RN(𝑦) = 𝑦 𝑐 ; • RN(𝑦) = 𝑦 ℎ .
Theorem 2.2 is particularly useful for the implementation of an (at least) locally monotonic elementary function 𝑓 at point 𝑋. If one can approximate 𝑓 -1

( 𝑦 ℎ + 𝑦 𝑐 2
) with a good enough accuracy 13 , it is possible to determine if RN(𝑓 (𝑋)) = 𝑦 ℎ or RN(𝑓 (𝑋)) = 𝑦 𝑐 . See Figure 2-12 for more details.

( 𝑦 ℎ + 𝑦 𝑐 2
) . We assume that 𝑓 is locally increasing. In example 1, 𝑓 -1

( 𝑦 1ℎ + 𝑦 1𝑐 2
) computes a value smaller than 𝑋 1 and error on 𝑓 -1 rises no issue here. We can safely conclude that RN(𝑓 (𝑋 1 )) = 𝑦 1 ℎ . In example 2, the ordering of 𝑦 2𝑐 and 𝑦 2ℎ is different (there is no reason one should prevail over the other). This time 𝑓 -1

( 𝑦 2ℎ + 𝑦 2𝑐 2
) computes a value larger than 𝑋 2 and still, the error on 𝑓 -1 rises no issue. We can safely conclude that RN(𝑓 (𝑋 2 )) = 𝑦 2ℎ . In the third example the accuracy of the approximation of 𝑓 -1 is not sufficient to make a safe choice between 𝑦 3ℎ or 𝑦 3𝑐 . Worse, 𝑓 (𝑋 3 ) could be a midpoint of F!

13 if the relative error 𝜖 is such that 𝑥 / ∈ ( 𝑓 -1 ( 𝑦 ℎ + 𝑦𝑐 2 ) (1 -𝜖) , 𝑓 -1 ( 𝑦 ℎ + 𝑦𝑐 2 ) (1 + 𝜖)
) , when

𝑓 -1 ( 𝑦 ℎ + 𝑦𝑐 2
) > 0.

When an FMA is available

The FMA instruction properties are presented in §1.5.4, p. 48. If an FMA instruction is available Ziv's test can be modified with two beneficial consequences:

• the value of 𝑒 can possibly be smaller (less false negatives);

• the test still works when 1 4 𝑦 ℎ is a subnormal.

We will use here the property that the FMA instruction evaluates expressions of the form RN(𝑎 + 𝑏 × 𝑐), that is with a single rounding.

Fundamentally, we replace the 𝑦 ℎ

? = RN(𝑦 ℎ + RN(𝑒 × 𝑦 ℓ )) test by the 𝑦 ℎ ? = RN(𝑦 ℎ + 𝑒 × 𝑦 ℓ ) test.
The analysis of this new test will follow the same lines as that of the original one.

When 𝑦 ℎ is not a power of 2 and 𝑦 ℎ is in the normal range, we can both get rid of the (1 + 2 -𝑝 ) term and drop the 1 2 ulp(𝑦 ℎ ) in the normal range condition from Property 2.3.

Property 2.11. Assume that 𝑦 ℎ is not a power of 2. Let 𝑒 be a nonnegative floating-point number.

If

𝑦 ℎ = RN(𝑦 ℎ + 𝑦 ℓ × 𝑒), then |𝑦 ℓ | ulp(𝑦 ℎ ) 2𝑒 .
We then have an analogous property to Property 2.4.

Property 2.12. Assume 𝑦 ℎ is not a power of 2.

If 𝑒 ≥ 1 1 -𝜖 -2 𝑝+1 𝜖 then 𝑦 ℎ = RN(𝑦 ℎ + 𝑦 ℓ × 𝑒) ⇒ 𝑦 ℎ = RN(𝑦).
Similarly, when 𝑦 ℎ is a power of 2, Property 2.6 is modified as follows.

Property 2.13. Assume that 𝑦 ℎ is a power of 2, 𝑦 𝑦 ℎ , and 𝑦 ℓ 0.

If

𝑦 ℎ = RN(𝑦 ℎ + 𝑦 ℓ × 𝑒), (2.27)
then

|𝑦 ℓ | 2 -𝑝-1 × 𝑦 ℎ 𝑒 . (2.28)
Additionally, Property 2.7 is also altered into the following statement.

Property 2.14. Assume that 𝑦 ℎ is a power of 2, and that 𝜖 <

1 1 + 2 𝑝+1 . If 𝑒 ≥ 1 -2𝜖 1 -𝜖 -2 𝑝+1 𝜖 (2.29) then 𝑦 ℎ = RN(𝑦 ℎ + 𝑦 ℓ × 𝑒) ⇒ 𝑦 ℎ = RN(𝑦).
From all these properties we can deduce the following theorem.

Theorem 2.3. Assume that:

• 𝜖 < 1 1 + 2 𝑝+1 ; • |(𝑦 ℎ + 𝑦 ℓ ) -𝑦| < 𝜖 × |𝑦|; • 𝑦 ℎ = RN(𝑦 ℎ + 𝑦 ℓ ); if 𝑒 1 1 -𝜖 -2 𝑝+1 𝜖 then 𝑦 ℎ = RN(𝑦 ℎ + 𝑦 ℓ × 𝑒) ⇒ 𝑦 ℎ = RN(𝑦).
Another difference is that for values of 𝑒 very close or equal to the FMA bound, 𝑒 can eventually

(when 𝜖 < 2 -2𝑝 ) reach 1. At such an approximation accuracy, if |(𝑦 ℎ + 𝑦 ℓ ) -𝑦|
|𝑦 × 𝜖| we are in one of the two following situations:

• |𝑦 ℓ | is much smaller than 1 2 ulp(𝑦 ℎ ) (or 1 4 ulp(𝑦 ℎ )) and then there is not the slightest chance that 𝑦, even if placed at the "tip" of the

(𝑦 ℎ + 𝑦 ℓ ) × ( 1 + 𝜖 1 -𝜖 )
segment, can reach or be beyond a midpoint; necessarily RN(𝑦) = 𝑦 ℎ ;

• |𝑦 ℓ | ≈ 1 2 ulp(𝑦 ℎ ) (or 1 4 ulp(𝑦 ℎ )
), but nevertheless smaller; the (𝑦 ℎ , 𝑦 ℓ ) pair can be viewed as a kind of 2𝑝 + 1 "floating-point number"; we must consider ourselves very lucky that 𝑦 ℎ + 𝑦 ℓ is so close to 𝑦 with such a limited precision; any other value for 𝑦 ℓ , say 𝑦 ′ ℓ , even if only differing from 𝑦 ℓ by ulp(𝑦 ℓ ), will violate the

|(𝑦 ℎ + 𝑦 ′ ℓ ) -𝑦|
|𝑦 × 𝜖| fundamental accuracy assumption.

For an approximation accuracy 𝜖 < 2 -2𝑝 , the fact that 𝑒 reaches 1 could be be interpreted as "we have found a right (𝑦 ℎ , 𝑦 ℓ ), rounding test is inutile since we are sure that RN(𝑦) = 𝑦 ℎ ". But it is impossible to consistently approximate a function at such an accuracy with only two floating-point numbers. If one targets for a higher accuracy, she must resort to other techniques (e.g. triple-double numbers -see [START_REF]CRLlibm[END_REF] for an implementation -if she insists on using groups of floating-point numbers).

Ziv's rounding test is not relevant in these contexts.

2.6.3 What if 1 4 ulp(𝑦 ℎ ) is subnormal and no FMA is available?

We know that the relative error committed in rounding to subnormal numbers can be very large.

In the worst case, if we call 𝑠𝑢𝑏 𝑚𝑖𝑛 = 2 𝑒min-𝑝+1 the smallest subnormal number in F, and if

RN(𝑥) = 𝑠𝑢𝑏 𝑚𝑖𝑛 then |𝑥| ∈ ((1 -1 2 ) × 𝑠𝑢𝑏 𝑚𝑖𝑛 , (1 + 1 2 ) × 𝑠𝑢𝑏 𝑚𝑖𝑛 ).
The relative error is almost as large as 1 2 ! Hence, if we revisit the proof of Property 2.3, all we can deduce from

|RN(𝑦 ℓ × 𝑒)| 1 2 ulp(𝑦 ℎ ) is |RN(𝑦 ℓ × 𝑒)| 3 4 ulp(𝑦 ℎ ).
Following the reasoning that led us to Theorem 2.1, we end up with the following bound

𝑒 3/2 1 -𝜖 -2 𝑝+1 𝜖 (2.30)
which is quite discouraging. To add insult to injury this rather bad bound is not the result of poor calculus: this would have, at least, left hope for improvement. It is indeed possible to find examples where a value slightly lower than our bound leads to false positives.

Consider the following extreme (but nevertheless possible) situation:

• 𝑦 ℎ = 2 𝑒min+1 ;
• 𝑦 ℓ = 2 𝑒min-𝑝+1 (which is the smallest subnormal);

• 𝑦 = 2 𝑒min+1 + 2 𝑒min-𝑝+1 + 2 𝑒min-2𝑝 = 𝑦 ℎ + 𝑦 ℓ + 2 𝑒min-2𝑝 ; • 𝜖 = 2 -2𝑝-1 .
We have, while 𝑦 ℓ is a midpoint in the 𝑦 ℎ binade but the integral significand of 𝑦 ℎ is even,

𝑦 ℎ = RN(𝑦 ℎ + 𝑦 ℓ )
and

|(𝑦 ℎ + 𝑦 ℓ ) -𝑦| |𝑦 × 𝜖|.
If we compute the bound given by (2.30), we get

𝑒 3/2 1 -𝜖 -2 𝑝+1 𝜖 ≈ 3 2 (1 + 2 -𝑝 ).
Let us pick a slightly smaller value for 𝑒:

𝑒 = 3 2 -2 -𝑝+1 = 1.011. . . 111 ⏟ ⏞ 𝑝 bits .
Multiplying 𝑦 ℓ by 𝑒 and rounding gives 𝑦 ℓ again:

RN(𝑦 ℓ × 𝑒) = RN(2 𝑒min-𝑝+1 × 1.011. . . 111 ⏟ ⏞ 𝑝 bits ) = 2 𝑒min-𝑝+1 .
We then still have

RN(𝑦 ℎ + RN(𝑦 ℓ × 𝑒)) = 𝑦 ℎ . But yet RN(𝑦) = 2 𝑒min+1 + 2 𝑒min-𝑝+1 ̸ = 𝑦 ℎ .
But what would have happened here had an FMA instruction been available (and used)?

In this case, the first multiplication issues a number larger than 𝑦 ℓ , hence also larger than 1 2 ulp(𝑦 ℎ ). The upcoming addition is performed with this number and will output 𝑦 + ℎ ̸ = 𝑦 ℎ : the test will fail calling for a new computation for the (𝑦 ℎ , 𝑦 ℓ ) pair under more stringent accuracy conditions. But this may also require a change in precision since is it very unlikely, given the value of 𝑦, that two floating-point numbers provide enough precision to approximate it with a sufficient accuracy.

The order of magnitude of 𝑦 is that of 𝑦 ℎ . Hence, the order of magnitude of the absolute error, |𝑦 × 𝜖| is 2 𝑒min+1 × 2 -𝑝-1 = 2 𝑒min-𝑝 , which, in turn, is smaller that ulp(𝑠𝑢𝑏𝑛𝑜𝑟𝑚𝑎𝑙𝑠) = 2 𝑒min-𝑝+1 for this floating-point system.

As for Ziv's test, the FMA version is without controversy the way to go. The increasing availability of this instruction on mainstream devices 14 will probably make the previous discussion history in a near future.

But there is still a very large installed base of efficient hardware in use and more important, a huge body of code devoted to numerical computations and approximations. How can all these assets be properly used?

What can be done, for function approximation, if no FMA instruction is available?

If we consider the problem of the correctly-rounded evaluation of the usual transcendental functions, we can often escape from the trap of the subnormal values.

Suppose we want to compute some 𝑓 (𝑋) for domain values where 𝑓 (𝑋) ≈ 0 but still, 𝑓 (𝑋) ̸ = 0 (and of course, RN (𝑓 (𝑋)) ̸ = 0). This situation may happen in, at least, two cases:

• we compute 𝑓 (𝑋) for tiny arguments for which 𝑓 (𝑋) ≈ 0;

• we compute 𝑓 (𝑋) for large arguments (in the sense of far from the subnormals range) that are very close to a root of 𝑓 (𝑋).

Let us start with an example of the first case. We want to compute, for instance, sin (𝑋) where 𝑋 is a very small floating-point number and 𝑋 > 0.

One possible way to evaluate a function for very small arguments is to compute its Taylor series expansion in the vicinity of 𝑋 = 0.

In the case of the sine function this expansion is

𝑓 (𝑥) = 𝑥 - 𝑥 3 3! + 𝑥 5 5! -• • • + (-1) 𝑛 𝑥 2𝑛+1 (2𝑛 + 1)! + 𝑂(𝑥 2𝑛+3 ). ( 2

.31)

Let 𝑋 = 𝑚 𝑋 × 2 𝑒 𝑋 , with 1 𝑚 𝑋 < 2 and let us assume that 𝑋 is not a power of two (this case can be dealt with separately). If

𝑋 √ 3 × 2 -𝑝 2 ,
then

𝑚 𝑋 × 𝑋 2 < 2 × 𝑋 2 < 2 × ( √ 3 × 2 -𝑝 2 ) 2 < 6 × 2 -𝑝 .
From that, we can deduce

𝑋 3 = 𝑚 𝑋 3 × 2 3𝑒 𝑋 < 6 × 2 𝑒 𝑋 × 2 -𝑝 ,
and then

𝑋 3 6 < 2 𝑒 𝑋 -𝑝 = 1 2 ulp(𝑋).
This is an alternate series whose successive terms have a decreasing absolute value. The error generated by truncating it at some term is upper bounded by the value of the first dropped term.

No check is needed for any of the subsequent terms.

RN

( 𝑋 - 𝑋 3 6 ) = 𝑋 Consequently, for 𝑋 √ 3 × 2 -𝑝
2 , we can say that RN (sin(𝑋)) = 𝑋.

Similar reasoning can be held for other functions and even better bounds can be found for specific values of 𝑝. Table 2.1 shows how small values can be handled for a set of usual functions for 𝑝 = 53.

Another situation is when 𝑋 is a "large" floating-point number. In practice, 𝑓 (𝑋) is always far away from the subnormal range, even if, theoretically, 𝑋 is close to a root of 𝑓 . For instance, in the case of the trigonometric functions, using a continued-fraction argument presented first by W. Kahan [START_REF] Kahan | Minimizing q*m-n[END_REF] (a Maple implementation can be found in [START_REF] Muller | Handbook of Floating-Point Arithmetic[END_REF]), one can show that the doubleprecision/IEEE-binary64 number larger than 1 which is nearest to an integer multiple of 𝜋 2 is 6381956970095103 × 2 797 ≈ 𝑘 * 𝜋/2 + 2 -60.8879 with 𝑘 ∈ N.

If we deal with the cos(𝑥) function, we find out that cos(6381956970095103 × 2 797 ) ≈ -4.69 × 2 -19 .

We cannot get any closer to 0 with double-precision arguments larger than one with the cosine function. And this 1 4 ulp(-4.69 × 2 -19 ) value is very far from the subnormal range. Hence one could safely use the non-FMA version of Ziv's test for the design of a correctly-rounded approximation of the cos(𝑥) function.

Tests and checks

Tests and checks were performed here, not so much as a support or as a substitute for mathematical proofs, but because numerical experiments are instrumental for documenting some interesting behaviors. This function. . . can be replaced by. . . when. . .

exp(𝑥) -1 𝑥 |𝑥| < RN( √ 2) × 2 -53 exp(𝑥) -1, 𝑥 0 𝑥 + RN( √ 2) × 2 -53 𝑥 < RN( √ 3) × 2 -52 ln(1 + 𝑥) 𝑥 |𝑥| < RN( √ 2) × 2 -53 sin(𝑥), sinh(𝑥), sinh -1 (𝑥) 𝑥 |𝑥| RN(3 1 3 ) × 2 -26 arcsin(𝑥) 𝑥 |𝑥| < RN(3 1 3 ) × 2 -26 sin(𝑥), sinh -1 (𝑥) 𝑥 -= 𝑥 -2 -78 RN(3 1 3 ) × 2 -26 < 𝑥 2 -25 sinh(𝑥) 𝑥 + = 𝑥 + 2 -78 RN(3 1 3 ) × 2 -26 < 𝑥 < 2 -25 arcsin(𝑥) 𝑥 + RN(3 1 3 ) × 2 -26 𝑥 < 2 -25 tan(𝑥), tanh -1 (𝑥) 𝑥 |𝑥| < RN(12 1
3 ) × 2 -27 tanh(𝑥), arctan(𝑥) 𝑥 |𝑥| RN(12

1 3 ) × 2 -27
tan(𝑥), tanh -1 (𝑥) 𝑥 + RN(12

1 3 ) × 2 -27 𝑥 1.650 × 2 -26
arctan(𝑥), tanh(𝑥) 𝑥 - RN(12

1 3 ) × 2 -27 < 𝑥 1.650 × 2 -26
Table 2.1: Rounding to nearest is assumed (this table is extracted from that, more comprehensive, in [START_REF] Muller | Handbook of Floating-Point Arithmetic[END_REF]). They can be extended to other precisions. They make evaluating function for tiny argument straightforward and allow one to avoid using the non-FMA version of Ziv's test in areas where it is of no value. Number RN(3

1 3 ) × 2 -26 ≈ 1.4422 • • • × 2 -26
, and number RN(12

1 3 ) × 2 -27 ≈ 1.1447 × 2 -26 .
If 𝑥 is a floating-point number, 𝑥 -denotes the largest floating-point number strictly less than 𝑥 while 𝑥 + denotes the smallest floating-point number strictly larger than 𝑥. The 2 -78 skew from 𝑥 given here for 𝑥 -and 𝑥 + only makes sense in the corresponding 2 -26 binade and for double-precision format.

General remarks

We have limited our tests to IEEE binary64 floating-point numbers (𝑝 = 53): both 𝑦 ℎ and 𝑦 are of the type "double" of the C language. We (allegedly) tried to approximate an arbitrary precision number 𝑦, with relative error bounded by 𝜖. We also have limited ourselves to peculiar values of 𝑦 ℓ , where it is positive (the negative case is symmetric), and close to 1 2 ulp(𝑦 ℎ ) since, considering the small values of 𝑒 that we obtain for reasonable values of 𝜖, nothing special happens for values of 𝑦 ℓ notably smaller than 1 2 ulp(𝑦 ℎ ). The value of 𝑦 is chosen extremely close to the limit imposed by 𝜖. When 𝑦 ℓ is very close to 1 2 ulp(𝑦 ℎ ), 𝑦 is almost guaranteed to be larger than or equal to 𝑦 ℎ + 1 2 ulp(𝑦 ℎ ) unless 𝜖 is very small. Therefore our experiments can be viewed as mimicking a worst case situation, where 𝑦 is always cornered close to the upper bound rather than having its value scattered all over the interval ((

𝑦 ℎ + 𝑦 ℓ ) (1 -𝜖), (𝑦 ℎ + 𝑦 ℓ ) (1 + 𝜖)).
Let us remind here the semantics associated with our results typology:

• positive: (𝑦 ℎ = RN(𝑦 ℎ + RN(𝑦 ℓ × 𝑒)) and 𝑦 ℎ = RN(𝑦); in such a case, we are done: Ziv's rounding test correctly indicates that 𝑦 ℎ = RN(𝑦);

• false positive: (𝑦 ℎ = RN(𝑦 ℎ + RN(𝑦 ℓ × 𝑒)) and 𝑦 ℎ ̸ = RN(𝑦); that case should never occur since it means that the rounding test is not correct;

• negative: (𝑦 ℎ ̸ = RN(𝑦 ℎ + RN(𝑦 ℓ × 𝑒) and 𝑦 ℎ ̸ = RN(𝑦); in such a case, a different strategy (e.g. a tighter approximation) should be used;

• false negative: (𝑦 ℎ ̸ = RN(𝑦 ℎ + RN(𝑦 ℓ × 𝑒)) and 𝑦 ℎ = RN(𝑦), which causes us to unduly switch to a more expensive strategy; this case must occur as infrequently as possible.

More precisely, the parameters involved in our experiments satisfy: 15 32 ulp(1), 16 32 ulp(1));

• 𝑝 = 53; • 𝑦 ℎ ∈ [1, 2); • 𝑦 ℓ ∈ [
• 𝜖 ∈ (2 -81 , 2 -55 ];

• as a consequence, 𝑒 ∈ [1.0000000074505808, 2.0000000000000004].

Stressing Ziv's rounding test under various relative error values

Our experiments consist in 100,000,000 𝜖 values randomly picked in each interval [2 -𝑘 , 2 -𝑘+1 ), for 𝑘 varying from -81 to -56.

a "negative" result) because, due to our "worse case" bias for computing it, on the one hand, 𝑦 is certain to be larger than or equal to 𝑦 ℎ + ulp(𝑦 ℎ ) and, on the other hand RN(𝑦 ℓ × 𝑒) 1 2 ulp(𝑦 ℎ ). This indicates that the theoretical bound on 𝜖 in Theorem 2.1 is probably not a good practical one.

Consequently, at least in the 𝑝 = 53 case, one should favor a sharper initial approximation accuracy to avoid a too frequent resort to high-accuracy approximation.

As 𝜖 decreases, so does 𝑒 and 𝑦 has less latitude to wander beyond 𝑦 ℎ + ulp(𝑦 ℎ ). As a consequence, the number of "negatives" decreases too and so does the number of "false negatives". At some point, the "false negatives" seem to vanish totally: the probability of a "false negative" is too low for them to show up among the tested cases, and all we have left is a small and decreasing (by a factor 2 each time 𝜖 itself decreases by a factor 2) number of "negatives".

The comforting result is that, at no point, do we have a "false positive".

Near optimality of the value of 𝑒 provided by Theorem 2.1

In order to minimize the number of "false negatives" 𝑒 must be as small as possible (and yet large enough to allow for a correct Ziv's test). Hence, it is important to assess how optimal is the value of 𝑒 given by Theorem 2.1). Let us call it 𝑒 * . As we could not prove it mathematically to be minimal, we will try to shave off tiny amounts from 𝑒 * and check when we start getting "false positives". In several experiments, in the 𝑝 = 53 context, we started getting them at 𝑒 * -2 -31 . One should not conclude from this experiment that the "Real and True Optimal Constant" is shyly ensconced somewhere in the [𝑒 * -2 -31 , 𝑒 * ] interval. Neither could one lightheartedly pick any value in this interval to brew an "optimized" and yet safe Ziv's rounding test of their own. We will not venture further than saying that the bound given by Theorem 2.1 is rather efficient for practical purposes. As we noted in §2.5.4, p. 109, we were able to figure out a formula to compute a bound for 𝑒 that only uses the target 𝑝-precision floating-point arithmetic. Two formulas were given

𝑒 𝑢𝑝 𝑠𝑖𝑚𝑝𝑙𝑒 = RU ( 1 + 2 -𝑝+1 1 -2 𝑝+1 𝜖
) , and

𝑒 𝑛𝑒𝑎𝑟𝑒𝑠𝑡 𝑠𝑖𝑚𝑝𝑙𝑒 = RN ( 1 + 2 -𝑝+1 1 -2 𝑝+1 𝜖 ) .
The latter, always smaller or equal to the former, is preferable since it yields a more efficient test. Unfortunately, we were not able to prove it larger or equal to the bound computed from the accurate formula, in the general case. This has only been done in particular cases (see Property 2.9).

Conclusion

First of all, we have exhibited formulas that allow for the computation of bounds for the 𝑒 constant in the Ziv's rounding test. We have proved that, under some realistic conditions, if one uses a value of 𝑒 larger or equal to these bounds, she can perform reliable (i.e. no "false positives" at all) and yet effective (with a low probability of "false negatives") tests.

We have also shown that, by using state-of-the-art technologies like FMA instructions, the safety domain of the test extends, to put it in a bit over-simplistic terms, to the subnormal range (see Section 2.6.2 for a more delineated description).

Most of the results are precision-independent, which broaden their generality. This in-depth analysis pulls out this utensil from the realm of "Black Magic" and anoints it as a dependable tool for practitioners. At the same time it confirms the intuitions and practices of our forerunners (starting with Abraham Ziv himself) who designed and used the test.

We have extensively mentioned correctly-rounded (usual elementary) functions as the main application field. Others exist, as, mainly, the implementation of "heterogeneous" operations (more information about it can be gathered from [START_REF] De Dinechin | On Ziv's Rounding Test[END_REF]) and others may be devised.

Is it the end of the story for Ziv's rounding test, from a research perspective? Not yet, could we answer. As noticed before, some holes in the proofs (optimality or, possibly, a better bound, correctness in general cases) still need to be plugged up.

Besides, our investigation limited itself to radix 2. It may be interesting to produce equivalent results for, at least, radix-10, as it will possibly be used more and more extensively, out of it original "financial" application domain. Nevertheless, as can be seen from our proofs, the issue is still highly radix-dependent and we do not envision yet (even if we can not totally dismiss it) the possibility of a general, radix-independent and nevertheless optimal solution.

Chapter 3

Coppersmith's Method and the TMD An implementation of the SLZ-algorithm.

Motivation: floating-point numbers beyond 64 bits

The development of floating-point number systems is still a work in progress. The last major normalization round held in 2008 (IEEE 754-2008) did not speak the final word about it.

In particular, the standard stepped ahead in the direction of a larger precision representation than that of the "historical" 64-bit (aka double precision with its companion binary64 interchange format 1 ) and 80-bit (aka double-extended precision, for which no interchange format was defined) representations that still are the bread-and-butter of today's numerical computations.

A 128-bit interchange format, binary128, was defined in order to anticipate the users expectations in this realm. Rules to define interchange formats were even set for even larger precision, and it is then possible to figure out; for instance, what binary256 or binary1024 would look like. Nevertheless, only binary128 was incorporated into the basic formats list [START_REF]IEEE 754-2008, Standard for Floating-Point Arithmetic[END_REF].

While no mainstream hardware implementation has shown yet 2 support for 128-bit floatingpoint arithmetic, some processor architectures, notably SPARC and IBM POWER, have dedicated instructions for 128-bit formats but, when called, they trigger a trap to software emulation rather 1 For the sake of brevity we will refer to the floating-point systems by the name of their interchange format. The former define the precision, the minimal and maximal exponents, the bias and other characteristics (rounding modes and rules, NaN's, subnormal numbers, etc.). The latter merely describe how data should be laid out for interchange between systems. This does not rule out the idea that interchange formats can be cleverly designed in order to make them a sensible choice for internal representation. But the distinction should remain clear. 2 One should not mistake 128-bit registers and AVX vector operations in Intel processors for the support of a "true" 128-bit floating-point arithmetic.

than being performed at full metal speed. Even then, the support of IEEE 754-2008 requirements cannot be taken for granted throughout.

Nevertheless, many other initiatives have been taken, mainly in software, to mention a few :

• the gcc compiler __float128 type and the companion libquadmath library [START_REF]Precision Math Library Application Programming Interface (API[END_REF];

• some version of the icl Intel compiler _Quad type and the companion MKL library (apparently discontinued);

• the C++ Boost float128 type in the multi-precision library [START_REF] Maddock | Boost.Multiprecision[END_REF] that is a thin wrapper over the previous two;

• the IBM 128-bit long double type, as supported in its AIX R ○operating system, that exhibits a limited compatibility with IEEE 754 standard.

Space and dedication lack to make an accurate census of all the attempts to implement binary128 in software. We are not considering here the generic arbitrary precision libraries that, on their way, can also be used with 113-bit significands3 . We refer here to specialized 128-bit libraries. Notice that a great confusion exists since there are also libraries that offer higher precision arithmetic as "double-double" (or even a higher number of double's [START_REF] Bailey | [END_REF] [21]) to represent "higher precision" floating-point numbers but they are a different beast than IEEE 754 binary128. The very number of these initiatives is an indication that this topic is becoming hotter and hotter.

Here, we place ourselves in the perspective of the full support of the IEEE 754-2008 standard and, more particularly, of correctly-rounding. The aforementioned initiatives try to deal, achieving variable degrees of compliance with IEEE 754-2008, with arithmetic operations. The next step is correct rounding of the elementary functions for which the key point is solving the Table Maker's Dilemma.

The TaMaDi Project [START_REF] Tamadi | ANR project involving the AriC, Marelle and PEQUAN teams[END_REF] was started in 2010 to tackle several issues regarding floating-point numbers arithmetic. One of its main goals was to evaluate options for the search of hard-to-round cases in the binary128 and decimal128 formats in order to allow for the development of correctly rounded libraries.

As explained in §1.6.3.3, p. 68, while, thanks to the 𝐿-algorithm, the solution of the TMD is at hand reach for binary64 it is known that this solution will not work efficiently enough for binary128.

In this context, the work presented in this chapter stems of two kinds of motivations:

1. "solve", in possibly different senses detailed below, the Table Maker Dilemma; 2. check if, with the 𝑆𝐿𝑍-algorithm, we are able to tackle problems that are out of reach of our most elaborated tool to date, the 𝐿-algorithm and its implementations.

We are not sure either that the 𝑆𝐿𝑍-algorithm will allow us to solve the TMD satisfactorily, in the sense of setting exactly the hardness-to-round for a function or at least attain a very sharp upper bound. This bound should live in the neighborhood of 2𝑝 (in precision 𝑝) as the probabilistic model suggests. But this case is very difficult to test.

D. Stehlé, in his PhD thesis [START_REF] Stehlé | Algorithmique de la réduction de réseaux et application à la recherche de pires cas pour l'arrondi de fonctions mathématiques[END_REF], gives a theorem that states that hard-to-round cases can be found in polynomial time complexity of the input for a hardness-to-round in the order of 𝑂(𝑝 2 ). This can be seen as a great improvement over Y. Nesterenko and M. Waldschmidt's bound (it guarantees a distance larger than 2 -18,563,653 between the image of any rational number corresponding to a 113-bit floating-point number (a number in the domain) by the exp function and a rational number in 113-bit precision (a number in the image)), it is still impractical for an implementation. In 113-bit precision, it takes an approximation accuracy a bit better than 2 -18,563,653 .

For the interval [3/2 -2 -7 , 3/2 + 2 -7 ], no known tool4 could compute the degree of a sharp enough approximation polynomial (not to speak about the polynomial itself!).

Of course, there are other (more mathematical) methods that allow for the computation of the necessary degree. Such an evaluation may be interesting to get a clear idea of how intractable the Nesterenlo and Waldschmidt's bound is.

If we assume that we use Taylor polynomials (as will be seen in §3.6, p. 160, this is what we actually do) to approximate the exp(𝑥) function, between 0 and 1, the approximation error of a degree-n such polynomial is given by the Taylor-Lagrange formula:

exp(𝑥) = 𝑛 ∑ 𝑘=0 𝑥 𝑘 𝑘 ! + 𝑥 𝑛+1 (𝑛 + 1) ! exp(𝑡), with 𝑡 ∈ [0, 1]. (3.1)
The error term here is 𝑥 𝑛+1 (𝑛 + 1) ! exp(𝑡) 𝑒 (𝑛 + 1) ! .

where 𝑒 denotes the base of the exp(𝑥) function.

The Stirling formula implies that:

(𝑛 + 1) ! √ 2𝜋(𝑛 + 1) ( 𝑛 + 1 𝑒 ) 𝑛+1 .
Therefore, the approximation error of the degree-n Taylor polynomial is upper-bounded by 𝑒 √ 2𝜋(𝑛 + 1)

( 𝑛 + 1 𝑒 ) 𝑛+1
This value become less than 2 -18,563,653 when 𝑛 1, 003, 750.

Even if our bound is not absolutely tight, it is safe to say that using a polynomial with such a degree and with the huge coefficients implied, is not a reasonable way to go for approximation. In the case of the exponential function, other techniques can be used, based, for instance, on the AGM for the evaluation of the log(𝑥) function and the 𝑥 𝑛+1 = 1 + 𝑎 -log(𝑥 𝑛 ) Newton iteration where 𝑎 is an initial approximation of exp(𝑥). Even then, the evaluation of the approximation would require either the development of a specialized high precision arithmetic library or, and more safely, the use of an existing arbitrary precision library as MPFR with the associated time and memory costs.

But we are somehow comparing apples to oranges here. On the one hand, the Nesterenko and Waldschmidt's bound is an absolute result. How discouraging as it is, no worse surprise is to be expected beyond that. On the other hand, with a polynomial complexity, very large constant terms and/or coefficients in the complexity formula can make things much more difficult than they seem at first sight.

If a direct attack in the 𝑝 2 precision is beyond our possibilities, what can be tried instead, and succeeding would not be a trivial result, is to make sure that hardness-to-round is smaller than, say, 6𝑝, 8𝑝, 10𝑝 or even 12𝑝.

This would break ground for a three-step (once all special cases have been dealt with) viable function implementation strategy. Steps would differ in accuracy, expressed here as a function of precision 𝑝. A first approximation could be made at an accuracy of 2 -(𝑝 + 20 % of 𝑝) . This would correspond, for binary128, to what is done in the "fast phase" approximation currently used in the implementation of libm's. Should this fail, another step could be taken at 2 Before we go further into the motivations, let us reset the stage.

Setting the stage

Most of the description can be done in general terms, we will specialize it only when it becomes absolutely necessary. Let us start with some floating-point system F 2,𝑝,𝑒𝑚𝑖𝑛,𝑒𝑚𝑎𝑥 . Our interest is in the rounding-to-nearest, tie-break to even rounding mode. Nevertheless we must say here that, from Lindeman's Theorem and corollaries (see [START_REF] Baker | Transcendental number theory[END_REF]), ties never happen for the exp(𝑥) function and many other common ones. Most of what we say here can be applied to other tie-breaking rules. We study the hardness-to-round, as defined in §1.6.3.3, p. 61 for this mode, of some function 𝑓 : F → F.

From now on, we assume that we have dealt with or eliminated all the troublesome parts such as:

1. parts of F where 𝑓 (𝑥) is not defined;

2. parts of F such that their image by 𝑓 (𝑥) is an infinity;

argument reduction;

4. parts of F whose image by 𝑓 (𝑥) does not require complex computations (e.g. RN( exp(𝑥)) = 1, when 𝑥 is "small enough", depending on precision); 5. elements of F whose image by 𝑓 (𝑥) are midpoints 5 .

At this point, we end up with a domain 𝒟 ⊂ F. This is where we actually want to study the hardness-to-round of 𝑓 (𝑥) for rounding-to-nearest mode. As expressed in our motivations, we want to make it in a "reasonable" amount of time which rules out exhaustive search of the possible options.

"Solving" the TMD

In the round-to-nearest mode we are essentially interested in the distance from the images to the midpoints of F. We should always keep in mind that they are not elements of F.

Let us call ℳ the set of the midpoints corresponding to the F ∩ [1, 2) set. In other words,

ℳ = { 𝜇 ∈ R such that, ∃ 𝑋 ∈ F ∩ [1, 2) such that 𝜇 = 𝑋 + + 𝑋 2 } ,
where, as usual in this document, 𝑋 + denotes the successor of 𝑋 in F6 .

Let us call nn (for Normalized Notation) a function that maps a real number 𝑥 to the absolute value of its "scientific" notation in base-2 deprived of its scaling term.

∀ 𝑥 ∈ R, nn(𝑥) = 𝑥 𝑛𝑛 = ⎧ ⎪ ⎪ ⎪ ⎪ ⎨ ⎪ ⎪ ⎪ ⎪ ⎩ ⃒ ⃒ ⃒ 𝑥 2 ⌊log 2 (|𝑥|)⌋ ⃒ ⃒ ⃒ , if 𝑥 ̸ = 0 0, otherwise.
In more fuzzy terms, the function nn operates similarly to the computation of the normalized significand of a floating-point number, only generalized to real numbers.

Strictly speaking, solving the TMD over domain 𝒟 ⊂ F consists in finding the smallest 𝑚 ∈ N such that, ∀ 𝑋 ∈ 𝒟, and for all 𝜇 ∈ ℳ, |nn (𝑓 (𝑋)) -𝜇| 1 2 𝑚 .

Hunting directly for the smallest 𝑚 is a difficult task and no one has yet devised an algorithm that shoots straight into the bullseye 7 . What can be done instead is to figure out some value ̃ 𝑚,

and try to check it.

We have assumed, when we have defined 𝒟, that all 𝑋 ∈ 𝒟 such that 𝑓 (𝑋) ∈ ℳ had been cleaned up beforehand. Depending on the inner workings of the checking algorithm, this may not be absolutely necessary if it can detect such a situation without falling into an infinite loop. Of course, and as already stated, these points should be dealt with specifically.

When checking if ̃ 𝑚 is over the hardness-to-round, we can get into one of the two following situations:

• the first is:

∀ 𝑋 ∈ 𝒟, ∀ 𝜇 ∈ ℳ, |nn (𝑓 (𝑋)) -𝜇| 1 2 ̃ 𝑚 ;
• the second is:

there exists some 𝑋 (or several of them) for which ∃ 𝜇 ∈ ℳ such that |nn (𝑓 (𝑋)) -𝜇| < 1 2 ̃ 𝑚 .

In the first case, ̃ 𝑚 is an upper bound to 𝑚. Though not optimal this information can be very interesting since, as noted above, if ̃ 𝑚 is relatively small (sharp, in regard to 𝑚), a reasonably efficient implementation of a correctly rounded approximation can be devised on these grounds. 𝑚 can be precisely spotted8 and if there are not to many of them, to avoid hampering the algorithm operation with the special precessing these situations require. Indeed, it can be worth computing high-precision values of 𝑓 (𝑥) for these particular cases, make an ad hoc analysis that would culminate in the recovery of "the" exact value of 𝑚 when all these cases have been dealt with.

Back to motivations

In this work, the 𝑆𝐿𝑍-algorithm will be mainly used to work out upper bounds (in the 6𝑝 to 12𝑝 bracket) for binary128 floating-point numbers system. Why do we not try to compute an exact value for the hardness-to-round? As it will be seen, the complexity of the algorithm grows when ̃ 𝑚 shrinks and searching for a very sharp value can still be out of the range of our tools.

History serves: the 𝐿-algorithm

Having a look to the 𝐿-algorithm is not only a not a ritual "hats off" to a dignified predecessor.

For one, the 𝐿-algorithm is not a mummy in display in some computer science mausoleum. It is alive and running. The ever-improved original strain is still hunting for hard-to-round cases in the evaluation of elementary functions with binary64 arguments. A full description of the seminal work can be found in [START_REF] Lefèvre | Moyens arithmétiques pour un calcul fiable[END_REF]. As already mentioned, it has also given birth to recent investigations in order to adapt it to state-of-the-art parallel computation technologies (on CPU and GPU, see [START_REF] Gouicem | Conception et implantation d'algorithmes efficaces pour la résolution du dilemme du fabricant de tables sur architectures parallèles[END_REF]).

This quick look back is also for us an opportunity to introduce some of the concepts shared by the 𝐿-algorithm and the 𝑆𝐿𝑍-algorithm and, of course, to point out some differences between them.

As we have already said, the very first method to solve the TMD is checking all the possible inputs for the closeness of their image to break point. But we have also noticed that this process becomes intractable when the precision 𝑝 grows. This is still the case for binary64 with 𝑝 = 53 despite the pioneer work realized in 2011, based on FPGA (see [START_REF] De Dinechin | An FPGA architecture for solving the Table Maker's Dilemma[END_REF]). The 𝐿-algorithm, and the 𝑆𝐿𝑍-algorithm as well, are methods that improve on enumeration by avoiding pinpoint checking as much as possible.

The TMD as curve-to-grid distance problem

As shown on Figure 3-1, a hard-to-round case can be viewed as a situation where the vertical distance between a curve (the graph of the function 𝑓 ), and a grid (made of the points that represent, in abscissa, the floating-point numbers and, in ordinate, the breakpoints for the different rounding modes 9 ) is very small. The tiny (but still very exaggerated in length) vertical bars on grid points in Figure 3-1 indicate the threshold that, when "hit" by the curve, triggers a close examination for hardness-to-round. In Figure 3-1, we have this situation for 𝑓 (𝑋 2 ) (for the rounding-to-nearest mode) and 𝑓 (𝑋 5 ) (for the directed rounding modes). Solving the TMD comes down to this process of (hopefully scarce) 9 Floating-points are breakpoints for directed rounding modes, midpoints are for rounding-to-nearest.

hard-to-round case candidates quick insulation and their scrutiny.

It turns out that this process can be enhanced and regularized (from our initial rectangular grid to a square one) if we consider the function 𝑓 and its reciprocal 𝑓 where 𝛿 is a small positive real number. Let us also assume, without any loss of generality 10 that the function 𝑓 is strictly increasing and that 𝑋 < 𝑓 -1 (𝑌 ).

If we assume that 𝑋 is a hard-to-round case for the function 𝑓 and applying the Mean Value 10 For other situations, all we have to do is switch the bounds of the intervals accordingly.

Theorem for this function, we can write:

|𝑌 -𝑓 (𝑋)| = ⃒ ⃒ ⃒𝑓 ′ (𝜉) (𝑓 (-1) (𝑌 ) -𝑋) ⃒ ⃒ ⃒ < 𝛿, (3.2)
where 𝜉 ∈ (𝑋, 𝑓 -1 (𝑌 )).

From Equation 3.2 we can see that if 𝑋 is hard-to-round case for the function 𝑓 , and provided |𝑓 ′ (𝜉)| is not too small, then the value of the expression ⃒ ⃒ 𝑓 -1 (𝑌 ) -𝑋 ⃒ ⃒ is also (or can also be) small, since, by hypothesis, the value ⃒ ⃒ 𝑌 -𝑓 (-1) (𝑋) ⃒ ⃒ is small. Hence, 𝑌 is a good candidate for being a hard-to-round case for the function 𝑓 -1 and worth checking.

Considering all the points of our new grid duplicates the number of necessary checks but does the work for two functions at the same time. It is not more expensive than considering both functions independently since other gains can be expected from, for instance, computing only one function approximation. Nevertheless, it may lead us to useless checks for points that do not make sense as, for instance, the point at coordinates (midpoint (𝑋 4 , 𝑋 5 ) , midpoint (𝑌 2 , 𝑌 3 )). Useless check can also be induced if our hypothesis on the smallness of the derivative is not verified.

But there is more. One can carefully pick which function (𝑓 or 𝑓 -1 ) one will use to make the checks. In the configuration presented in Figure 3-2 and for an enumerative method, it is quicker to consider the reciprocal function 𝑓 -1 than the function 𝑓 since there are less cases to deal with. For a more convincing and real-world detailed example, see [START_REF] Muller | Handbook of Floating-Point Arithmetic[END_REF], p. 435.

Working with a linear approximation

As already stated, function 𝑓 will not be routine-evaluated with some arbitrary precision library as MPFR. We absolutely want to limit the invocation of such a library to checking only serious contenders for hard-to-round case because of the involved overhead. The most common approximating functions family is polynomials and among them, apart from the trivial case of a mere constant, their simplest form is degree-1. This is what is used in the case of the 𝐿-algorithm for reasons that will become clearer latter latter on. Our previous curve-to-grid distance becomes a segment-to-grid distance one.

But before we go to the approximation step, let us, in order to simplify the expression of the problem, scale the input and the output values so that we work with the first non-negative integers instead of the original rational values as the indeterminate of our polynomial. More precisely, the scaling takes the following form. We assume that:

• the distance between two consecutive input values is 𝛽 -𝑣 , where 𝛽 is the floating-point system radix and 𝑣 ∈ Z;

• the distance between two consecutive breakpoints in the image is 𝛽 -𝑤 /2, where 𝑤 ∈ Z.

Instead of the restriction of the function 𝑓 to the set {𝑋 ℓ𝑜 , . . . , 𝑋 𝑢𝑝 }, with 𝑋 ℓ𝑜 < 𝑋 𝑢𝑝 and 𝑋 ℓ𝑜 ∈ F, 𝑋 𝑢𝑝 ∈ F, we consider now the function 𝑔 defined over the set of integers {0, . . . , 𝑁 -1} ⊂ N such that:

𝑔(𝑘) = 2 × 𝛽 𝑤 𝑓 ( 𝑋 ℓ𝑜 + 𝛽 -𝑣 𝑘 ) .
What corresponds to a hard-to-round case is now a non negative integer 𝑘 < 𝑁 such that 𝑔(𝑘) is very close to an integer. Finding one such case comes down, for some small number 𝛿 0 ∈ R + , to solving:

∃𝑢 ∈ Z, |𝑔(𝑘) -𝑢| < 𝛿 0 2
What we do here is approximate the function 𝑔(𝑘) (and not 𝑓 (𝑥)) by a degree-1 polynomial 𝑃 (𝑘) = 𝑏 0 -𝑎𝑘, with 𝑎 ∈ R and 𝑏 0 ∈ R. Taking into account the approximation error with a new small real number 𝛿 ∈ R + , the problem becomes:

∃𝑢 ∈ Z, |(𝑏 0 -𝑎𝑘) -𝑢| < 𝛿 2 .
In other words, in order to get rid of the absolute value, we have:

∃𝑢 ∈ Z, - 𝛿 2 < (𝑏 0 -𝑎𝑘) -𝑢 < 𝛿 2 .
With this formulation, we have to check the distance of 𝑏 0 -𝑎𝑘 to an integer in both directions, up and down. We can easily transform the problem into a single check, to the "below" integer, by slightly shifting "upward" the 𝑦 = 𝑏 0 -𝑎𝑘 segment, using 𝑏 = 𝑏 0 + 𝛿 as the intercept in our linear function. The problem becomes:

∃ 𝑢 ∈ Z, (𝑏 -𝑎𝑘) -𝑢 < 𝛿.
With a classical definition (see [START_REF] Graham | Concrete Mathematics: A Foundation for Computer Science[END_REF], p. 70 and [START_REF] Havil | Gamma: Exploring Euler's Constant[END_REF], p. 110) of the fractional part function (also often noted {𝑥}):

frac(𝑥) = 𝑥 -⌊𝑥⌋,
we can restate the problem as finding the non-negative integers 𝑘 < 𝑁 such that frac(𝑏 -𝑎𝑘) < 𝛿, keeping in mind that ∀ 𝑥 ∈ R, frac(𝑥) > 0. As noted above, this simplifies somehow the search.

Avoiding an exhaustive search

An obvious way to check the values of 𝑘 for which a hard-to-round case exists is to enumerate the values of frac(𝑏 -𝑎𝑘) for 𝑘 ∈ {0, . . . , 𝑁 -1}. In fact this is the only option if one wants an exact result. Nevertheless it is possible to make checking faster, yielding an approximate result in the sense that more possible hard-to-round cases are detected than necessary but none of the actual ones is missed (see [START_REF] Muller | Handbook of Floating-Point Arithmetic[END_REF] p.440-442).

It happens that the succession of frac(𝑘𝑎), with 𝑘 ∈ {0, . . . , 𝑁 -1} and 𝑎 an irrational number, has a special structure 11 . The position of the successive values of frac(𝑘𝑎) on the [0, 1) interval do not happen at random but according to a, if not simple yet predictable, pattern.

Exploiting this particular structure allows for the search of a lower bound on frac(𝑏 -𝑎𝑘) without the enumeration the 𝑘's. If, from the value of this bound, one deduces that a possible hard-to-round case is buried in the interval, she can resort to exhaustive search to localize it. The lower bound search does not generate false negatives (intervals pronounced free of hard-to-round cases but actually containing one).

The general shape of the algorithm strongly reminds that of the subtractive euclidean one for the GCD (see [START_REF] Muller | Handbook of Floating-Point Arithmetic[END_REF], p. 441). One of the niceties (among others) of the algorithm used for the lower bound computation is that, at the expense of minor modifications, it yields the one used for pinpoint searches. In the actual implementation, one also has to deal with other issues as, for instance, the fact that our hypothesis on the irrationality of 𝑎 is not relevant for machine numbers.

Quick approximation computation

The above sketched technique for the search of the hard-to-round cases, relies on degree-1 polynomial approximations. While this warrants the exploitation of a structure on frac(𝑘𝑎), it generates annoyances of its own.

Degree-1 polynomials have a limited approximation ability. This implies that the domain of the function must be split into many small subdomains (remember: in the order of 2 2𝑝/3 per binade, as analyzed in [START_REF] Stehlé | Algorithmique de la réduction de réseaux et application à la recherche de pires cas pour l'arrondi de fonctions mathématiques[END_REF], p. 164-165). As a consequence, as many approximation polynomials have to be computed. These computations do not come cheap even with quick techniques as Taylor truncated series (see §3.3.3, p. 159). The very narrowness of the intervals makes them quick to check and by contrast the overhead occasioned by the computation of the approximants becomes more detrimental in this context.

Here too some optimization is possible when one remarks that if a new approximant must be computed for each new interval, it is not very different from the just used one. If one can devise a method that cheaply (in computing terms) derives the next polynomial from the current one (or the former ones), instead of computing it from scratch, some gains may be expected.

This is what is achieved through the Finite Difference Method (used here to compute successive values of a polynomial without evaluating it through traditional methods such as Horner's rule) and the application of this method to the computation of the coefficients of the next polynomial from those of the previous ones. Detailed explanations can be found in [START_REF] Lefèvre | Moyens arithmétiques pour un calcul fiable[END_REF] and [START_REF] Lefèvre | Génération de coefficients de polynômes d'approximation sur des sous-intervalles, avec bornes d'erreur garanties[END_REF].

The dependence on degree-1 approximation polynomials has been seen as the main limitation of the 𝐿-algorithm. Hence using higher degree ones was the starting point for the development of the 𝑆𝐿𝑍-algorithm. But this change in approximation technique has had a deep impact on the subsequent parts of the computations since, as we have seen, the 𝐿-algorithm heavily relies on the fact that the sequence of the approximations from one point to the next form an arithmetic progression that allows for exploration methods inspired from the euclidean GCD algorithm. This property is lost with higher degree approximation polynomials. Using the Coppersmith method is the response to these new conditions.

After this historical and technical introduction, it is time to get to the heart of our matter.

First steps towards the 𝑆𝐿𝑍-algorithm

This section is very extensive for two main reasons:

1. the algorithm is itself rather complex;

2. a large batch of preparatory work is necessary to level the ground before a single algorithm can be used to deal with the whole problem.

We can not directly dive into the heart of the problem before some housekeeping chores are performed and we have the problem formulated in proper terms for the techniques that will be used thereafter.

Hair Splitting

We will often discuss splitting here. But what we are about to perform here is a first step that has more to do with problem conditioning than with the usual reasons for domain splitting in approximation (e.g. operate on a sufficiently narrow interval so that a polynomial of a given degree 𝑑 approximates the function accurately enough).

These reasons, and more specific ones, will be invoked when we talk again about interval splitting.

What we eventually want is to work on "normalized" domains. All our endeavor here is to prepare this normalization and try to make sure it is correctly done.

We mentioned that we were dealing now with a subset of F that we call 𝒟. It is a finite set and, as such, it has a smaller (resp. larger) element we shall call 𝑙𝑏 (resp. 𝑢𝑏). Most of the time, we will denote this set as 𝑙𝑏, 𝑢𝑏 . From now on, we shall make a distinction between real intervals (e.g. [𝑎, 𝑏]) and finite subsets of F, Z or N denoted by their bounds (e.g. 𝑥 ∈ 𝑙𝑏, 𝑢𝑏 ⇔ (𝑥 ∈ F and 𝑙𝑏 ≤ 𝑥 ≤ 𝑢𝑏)). In addition, and to be more accurate, notice that in particular situations, some "trouble making" elements of F may be missing from 𝑢𝑏, 𝑙𝑏 . What we have in mind here are subsets of F from which some element(s) 𝑋 has (have) been removed for specific reasons (e.g. 𝑓 (𝑋) is not numerical).

Monotonic splitting

We will first split 𝒟 into a family of subsets {𝒟 0 , 𝒟 1 , . . . , 𝒟 𝑟 } such that 𝑓 (𝑥) is monotonic on each of them; if no splitting takes place (i.e. the function is monotonic), we end up with a single subset 𝒟 0 .

Subdomain binade-wise splitting

We will, if necessary, split each of the domains 𝒟 𝜌 obtained at the previous step into a family of subsets {𝒟 𝜌,0 , 𝒟 𝜌,1 , . . . , 𝒟 𝜌,𝑠 } such that each of them fits into a single binade; if some 𝒟 𝜌 is not split, it yields a single 𝒟 𝜌,0 set.

Subdomain image binade-wise image splitting

Eventually, and if necessary, we will split each of the 𝒟 𝜌,𝜎 sets into a family of subsets {𝒟 𝜌.𝜎.0 , 𝒟 𝜌,𝜎,1 , . . . , 𝒟 𝜌,𝜎,𝑡 } such that 𝑓 (𝒟 𝜌,𝜎,𝑘 ) fits into a single binade; again, if some 𝒟 𝜌,𝜎 is not split, it yields a single 𝒟 𝜌,𝜎,0 .

Splitting in pictures

Notice that these splitting operations are always possible since 𝒟 (and offspring) and 𝑓 (𝒟) (and offspring) are all finite sets.

Notice also that this can lead to unnecessary splitting if, on some subset 𝒟 included in a single binade, 𝑓 (𝑥) is not monotonic over 𝒟 but 𝑓 (𝒟) "lives" in a single binade: think of, for instance, some periodic function as in Figure 34.

From Figure 3-5 we can see why it is first necessary to split into monotonic domains if we want the image of each final domain to fit into a single binade.

Figure 34The [1, 2) interval domain is split in three subdomains 𝒟 𝜌 , 𝒟 𝜌+1 , 𝒟 𝜌+2 based on monotonicity. This is not absolutely relevant here, at least at this stage, since both the domain and the image live in a single binade. The full splitting process is illustrated and recapped in Figure 3456.

0 (f(x) = 1) 1 2 x log 2 f(x) 1 (f(x) = 2) 2 (f(x) = 4)
From now on, we will assume that we are working on some interval 𝒟 𝑥,𝑦,𝑧 obtained from the process described above.

What comes next is a reformulation of the hard-to-round cases in terms that will be more suited to the techniques we want to use hereafter.

Hardness-to-round revisited

Let us assume we work with a precision-𝑝 floating-point system F 2,𝑝,𝑒𝑚𝑖𝑛,𝑒𝑚𝑎𝑥 . We introduce here new notations about binades. The domain and image splitting according, first, to monotonicity, and then to the binade spanning of both the domain and the image.

0 (f(x) = 1) 1 2 x log2(f(x)) 1 (f(x) = 2) 2 (f(x) = 4) a b 0 1/2 0 1 2 x log2(f(x)) 1 2 lb0 0 1/2 ub0 1 2 x log2(f(x)) 0 1/2 lb1 ub1 0 1 2 x log2(f(x)) a 1/2 lb1.0,0 ub1.0,0 0 1 2 x log2(f(x)) 1/2 lb1,0.1 ub1,0,1 0 1 2 1 2 x log2(f(x)) 0 1/2 lb0,1 ub0,1 0 1 2 1 2 x log2(f(x)) 0 1/2 lb0,0 ub0,0 0 1 2 x log2(f(x)) 1/2 lb0.0.1 ub0.0.1 0 1 2 x log2(f(x))

Leveling the playground: toying with binades

As defined in the introduction ( §1.4.3, p. 41), let us denote ℓ-binade the following interval over R:

[2 ℓ , 2 ℓ+1 ) (e.g. the 0-binade is the [1, 2) interval).
Let us denote as 𝑘-fbinade, the "restriction to F of the 𝑘-binade" that holds all the 𝑋 ∈ F such

that 𝑋 ∈ [2 𝑘 , 2 𝑘+1 ) (e.g the 0-fbinade is all the 𝑋 ∈ F such that 𝑋 ∈ [1, 2)).
If 𝑝 is the precision of the floating-point system, then

𝑘-fbinade = 2 𝑝-1+𝑘 2 𝑝-1 , 2 𝑝+𝑘 -2 𝑘 2 𝑝-1 .
In our notation -𝑘-fbinade will denote

all the 𝑋 ∈ F such that 𝑋 ∈ - 2 𝑝+𝑘 -2 𝑘 2 𝑝-1 , - 2 𝑝-1+𝑘 2 𝑝-1 .
Notice that 𝑘 is an element of Z. Nevertheless, when 𝑘 < 0, -𝑘-fbinade ̸ = |𝑘|-fbinade. The initial explicit minus sign and the implicit one attached to the negative integer 𝑘 do not relate to the same thing and can not be simplified according to the usual signed numbers multiplying and dividing rules. The initial minus sign indicates that we are dealing with negative floating-point numbers.

The implicit sign of 𝑘 relates to the magnitude of these numbers. Fortunately we will never get caught in such a confusing "clash of signs" situation in the forthcoming developments.

We will also add a subnorm-fbinade, that, for the positive range, will hold all the elements of F smaller than 2 𝑒min and larger or equal to 0. At this point our definition diverges from that used for the "regular" fbinades (this fbinade span an infinity of binades as defined over R) but it allows for a practical decomposition of F.

Let us now decompose F into the list of the fbinades it is made of 12 as follows:

F = ⋃ 𝑖 ∈ -(𝑒max),-(𝑒𝑚𝑖𝑛) ∪ 𝑒min,𝑒max

𝑖-fbinade

⋃

subnorm-fbinade ∪ subnormal-fbinade.

Stretching and shrinking

We consider now some function 𝑓 : F → R that we want to correctly round into F13 .

From our previous splitting work, the search of the smallest 𝑚 (or checking of some ̃ 𝑚) is well specified since any 𝒟 𝜌,𝜎,𝜏 fits into a single (f)binade as well as 𝑓 (𝒟 𝜌,𝜎,𝜏 ) does. But, for a given hardness-to-round 𝑚, the actual distance between 𝑓 (𝑋) and the midpoints one has to check differs from one binade to another, as shown in Figure 34567.

Figure 3-7: We have represented here the "exclusion segments" where 𝑓 (𝑋) should not live if we were to prove that some integer 𝑚 is the hardness-toround of 𝑓 (𝑥). If we think of it in absolute terms, the width of the segments changes when we change binades.

One may want to simplify the problem by creating the conditions where the distances to consider, between the floating-point numbers and the midpoints, are the same for all subsets 𝒟 𝜌,𝜎,𝜏 , (in the domain of 𝑓 (𝑥) or in its image). In a sense, this is what we did for our definition of the hardness-to-round. To this end, we will now take an extra step in order to normalize the subdomains (each included in some 𝑘-fbinade) and their images (each included in some ℓ-fbinade) as if they were both included in the 0-fbinade.

This operation will allow us to have a single formulation of the algorithm that deals with different binades, either for the domain or for the image. Normalizing to the 0-fbinade is a natural choice, but any other is possible, as long as bookkeeping for denominators, approximation accuracy in relation to hardness-to-round, etc. is ensured.

We can easily realize that by scaling any 𝑘-fbinade or ℓ-fbinade to the 0-fbinade. Remember that, in a precision-𝑝 floating-system, all fbinades hold the exact same number of elements: 2 𝑝-1 . A one-to-one correspondence between the elements of two fbinades boils down to a multiplication by a power of 2. This is what we do, back and forth, between any 𝑘-fbinade and the 0-binade.

Let us call 𝑠𝑐𝑎𝑙𝑒

𝑔(𝑥) = 𝑠𝑐𝑎𝑙𝑒 ℓ→0 ( 𝑓 ( 𝑠𝑐𝑎𝑙𝑒 0→𝑘 (𝑥) )) .
If we set 𝑦 = 𝑠𝑐𝑎𝑙𝑒 0→𝑘 (𝑥), the function 𝑔(𝑥) behaves exactly the same as 𝑓 (𝑦) in terms of hardnessto-round:

• the initial scaling from the domain of 𝑔(𝑥) to that of 𝑓 (𝑦) maps a floating-point, 𝑥 0 , onto another one, 𝑥 𝑘 , exactly (no rounding ever takes place) since the mapping is a multiplication by a power of 2;

• nothing changes for 𝑓 (𝑦), that computes images from the 𝑘-binade into the ℓ-binade;

• the final scaling from the ℓ-binade to the 0-binade changes the value 𝑓 (𝑥 𝑘 ) but not its behaviour in terms of hardness-to-round; more accurately this scaling is necessary to make the application of our definition of hardness-to-round ( §1.6.3.3, p. 61) possible; this definition considers the "normalized significands"14 both for the exact value of 𝑓 (𝑥 𝑘 ) and for the midpoints; all these are elements of the 0-binade; this is exactly what the final scaling does.

As everything is now properly scaled back and forth, without any loss of information, we will operate, from now on, only over the 0-(f)binade for both the domain and the image.

Obviously each fbinade, or chunk of fbinade, in the domain will require a different 𝑔(𝑥) function since scaling changes from one binade to another (this is how they were built in the first place).

Nevertheless we can use the same function for different chunks as long all their elements (resp. the images thereof by 𝑓 (𝑦)) belong to the same binade (resp. the images all belong to the same binade), what remains possible since splitting can happen for other reasons (e.g. monotonicity) than binade change.

We have reduced our problem of finding the hard-to-round cases of function 𝑓 (𝑦) over F (or a large subset of it) into multiple sub-problems of finding the hard-to-round cases of a family of func-tions 𝑔 1 , 𝑔 2 , . . . , 𝑔 𝑛 with their domain in the 0-fbinade (remember we are only interested in images of floating-point numbers) and their image in the 0-binade (these images can be anywhere in the 0-binade, all the problems stem from that). We could even perform the rounding of the images in the 0-fbinade (to be accurate, marginally, from time to time, some rounding would be to 2, and 2 / ∈ 0-fbinade). Scaling the rounded value back to the image domain is equivalent to performing rounding on the image itself.

At this point, we have to expand our analysis with a new issue. Indeed, we will not be actually working with the "real" function 𝑔(𝑥) itself (which is, admittedly, only a very thin wrapper around 𝑓 (𝑦)), but we will rather have to use a machine computable approximation function. In the case of the 𝑆𝐿𝑍-algorithm this function will be a polynomial. The problem shifts now from the hardnessto-round of an arbitrary function to that of a polynomial. It will allow us both to use the same technique for any function and to leverage on some particular properties of polynomials Let 𝑃 (𝑥) be such an approximation of 𝑔(𝑥). For the moment, we do not specify the accuracy of this approximation, this will come a bit later and will be related to the value of 𝑚 one wants to test. We introduce 𝑃 (𝑥) here in order to stabilize the notations in this new part of our analysis.

From inequality to modular equations

In the 0-fbinade and in precision 𝑝, floating-point numbers are rational numbers of the form 𝑖

2 𝑝-1 with 𝑖 ∈ 2 𝑝-1 , 2 𝑝 -1 .
The following relations stand, as long as the accuracy of the approximation of 𝑔(𝑥) by 𝑃 (𝑥) is sufficient 15 :

𝑔 ( 2 𝑝-1 2 𝑝-1 , 2 𝑝 -1 2 𝑝-1 ) ⊂ 0-binade, 𝑃 ( 2 𝑝-1 2 𝑝-1 , 2 𝑝 -1 2 𝑝-1
) ⊂ 0-binade.

From now on, we completely remove 𝑔(𝑥) out of the picture (and the long gone 𝑓 (𝑦) as well).

We can restate the previous in terms of the approximation polynomial 𝑃 (𝑥) as:

∀ 𝑖 ∈ 2 𝑝-1 , 2 𝑝 -1 , ∃ 𝑗 ∈ 2 𝑝-1 , 2 𝑝 -1 such that 𝑗 2 𝑝-1 𝑃 ( 𝑖 2 𝑝-1 ) < 𝑗 + 1 2 𝑝-1
since all the 𝑗 2 𝑝-1 belong to the 0-binade.

We can now define the midpoint that is immediately larger than 𝑗 2 𝑝-1 as

2 𝑗 + 1 2 𝑝 .
At this point we have two options for 𝑃 ( 𝑖

2 𝑝-1
) :

• 𝑃 ( 𝑖 2 𝑝-1 ) = 2𝑗 + 1 2 𝑝 , in other words 𝑃 ( 𝑖 2 𝑝-1
) is an exact midpoint;

• 𝑃 ( 𝑖 2 𝑝-1
) is not such a midpoint.

In the latter case, ∃ 𝑚 𝑖,𝑗 ∈ N such that

1 2 𝑚𝑖,𝑗 ⃒ ⃒ ⃒ ⃒ 𝑃 ( 𝑖 2 𝑝-1 ) - 2 𝑗 + 1 2 𝑝 ⃒ ⃒ ⃒ ⃒ < 1 2 𝑚𝑖,𝑗 + 1 .
This situation, for some 𝑖, is depicted in Figure 345678.

Figure 345678The image by polynomial 𝑃 (𝑥) of some 𝑖 2 𝑝-1 lives between 1 2 𝑚 and 1 2 𝑚-1 from a midpoint.

If, from 2 𝑝-1 , 2 𝑝 -1 , we get rid of all the cases where 𝑃 ( 𝑖

2 𝑝-1
) is an exact midpoint, we obtain what we will denote 2 𝑝-1 , 2 𝑝 -1 * . One could think that the this distinction is pointless in the case of the exp(𝑥) function and of all the others Liouville's Theorem and subsequent lemmas deal with. But we must remember here that 𝑃 (𝑥) is an approximation. We then have to perform the midpoints clean-up in order to have our definition make sense.

We can now define 𝑚, the hardness-to-round of 𝑃 (𝑥) over the 0-fbinade as:

𝑚 = max(𝑚 𝑖,𝑗 ), for all 𝑖 ∈ 2 𝑝-1 , 2 𝑝 -1 * , with 𝑗, ∈ 2 𝑝-1 , 2 𝑝 -1 .

Back to approximation precision

This is where the 𝑔(𝑥) function makes a short comeback. As mentioned above, we left aside the problem of the accuracy of the approximation of 𝑔(𝑥) by 𝑃 (𝑥). We even took for granted the fact that 𝑔(𝑥) could be approximated by a polynomial. At this point we come back to these issues. To all the restriction we have placed on 𝑔(𝑥), considered as a function over the real numbers on some interval [𝑎, 𝑏], we must append the two following conditions : Why are these conditions appended? In order to be able to apply the Weierstrass Approximation Theorem [START_REF] Weierstrass | Über die analytische Darstellbarkeit sogenannter willkürlicher Functionen einer reellen Veränderlichen[END_REF], [START_REF] Weierstrass | Sur la possiblité d'une représentation analytique des fonctions dites arbitraires d'une variable réelle[END_REF] that states that any continuous function defined over a closed and bounded interval can be uniformly approximated on that interval by polynomials and to any degree of accuracy. Or put in more formal way: If 𝑔(𝑥) is a continuous real-valued function on [𝑎, 𝑏], for any given 𝜖 > 0 there exists a polynomial of degree 𝑑, 𝑝 𝑑 , such that

∀ 𝑥 ∈ [𝑎, 𝑏], |𝑔(𝑥) -𝑝 𝑑 (𝑥)| < 𝜖. (3.3)
We will deal soon with the question of actually computing approximations. For the time being, we just recall the results that make it theoretically possible. First, we can use to our advantage another result stating that, for a given degree 𝑑, there is a unique optimal polynomial 𝑝 * 𝑑 in the sense that ||𝑔 -𝑝 * 𝑑 || ∞ is minimal (e.g. equal to some 𝜖 * ). The reader may refer to [START_REF] Cheney | Introduction to approximation theory[END_REF] for a detailed discussion and a proof. Furthermore, there is a constructive algorithm that, for a given degree 𝑑, computes this optimal polynomial 16 . This is the famous Remez Algorithm [START_REF] Remez | Sur la détermination des polynômes d'approximation de degré donné[END_REF], [START_REF] Remez | Sur un procédé convergent d'approximations successives pour déterminer les polynômes d'approximation[END_REF], [START_REF] Remez | Sur le calcul effectif des polynômes d'approximation de Tchebichef[END_REF] that was followed by several improvements.

Notice that 𝑝 *

𝑑 is a real number coefficient polynomial. But in practice, as we will machinecompute it with a tool like Sollya and as we want it to be machine-evaluable for further processing, what we will eventually get is a polynomial whose coefficients are rational numbers with bounded numerator and denominator. Let us call it 𝑃 𝑑 (𝑥) or more briefly 𝑃 (𝑥) if the we do not need to embed the degree in the notation.

The difference between 𝑝 * 𝑑 and 𝑃 𝑑 that is most relevant to our present discussion is that the latter will generally be less accurate than the former relatively to 𝑔(𝑥). If the rational number coefficients 158 Chapter 3. Coppersmith's Method and the TMD: An implementation of the SLZ-algorithm. polynomial is not accurate enough, we will still have options:

• allow for more bits for the coefficients of 𝑃 𝑑 , by performing the approximation with a better precision;

• switch to a higher degree polynomial;

• do some extra interval splitting.

What stands for real numbers of the domain of 𝑔(𝑥) is also true for rational ones. We switch now from the interval [𝑎, 𝑏] to the rational numbers set

𝑙𝑏 2 𝑝-1 , 𝑢𝑏 2 𝑝-1
where 𝑙𝑏 2 𝑝-1 = 𝑎 and 𝑢𝑏 2 𝑝-1 = 𝑏 17 . This set holds all the elements of F comprised between 𝑙𝑏 2 𝑝-1 and 𝑢𝑏 2 𝑝-1 . At the same time we will replace 𝑝 * 𝑑 by its rational surrogate 𝑃 (𝑥) :

∀𝑖 ∈ 𝑙𝑏 2 𝑝-1 , 𝑢𝑏 2 𝑝-1 , ⃒ ⃒ ⃒ ⃒ 𝑔 ( 𝑖 2 𝑝-1 ) -𝑃 (𝑖) ⃒ ⃒ ⃒ ⃒ < 𝜖.
As stated before, we are not going to compute "the" hardness-to-round of 𝑔(𝑥) directly but rather check if a given integer value 𝑚 is larger or equal to this (unknown) hardness-to-round 18 .

Let us assume now, without loss of generality, that 𝑔(𝑥) is an increasing function 19 . With our present notation and state of affairs (i.e. after all the above presented substitutions are made) we are trying to prove about the above a given 𝑚 that:

If ∀ 𝑖 ∈ 𝑙𝑏, 𝑢𝑏 , ∀ 𝑗 ∈ ⌊ 𝑔 ( 𝑙𝑏 2 𝑝-1 ) 2 𝑝-1 ⌋ , ⌈ 𝑔 ( 𝑢𝑏 2 𝑝-1 ) 2 𝑝-1 ⌉ , 𝑔 ( 𝑖 2 𝑝-1 ) ̸ = 2𝑗 + 1 2 𝑝 , then ∀𝑖 ∈ 𝑙𝑏, 𝑢𝑏 , ∀𝑗 ∈ ⌊ 𝑔 ( 𝑙𝑏 2 𝑝-1 ) 2 𝑝-1 ⌋ , ⌈ 𝑔 ( 𝑢𝑏 2 𝑝-1 ) 2 𝑝-1 ⌉ , 𝑚 ∈ N is such that ⃒ ⃒ ⃒ ⃒ 𝑔 ( 𝑖 2 𝑝-1 ) - 2𝑗 + 1 2 𝑝 ⃒ ⃒ ⃒ ⃒ 1 2 𝑚 .
We are ready now to connect the approximation accuracy of 𝑃 (𝑥) to the value 𝑚, as an upper bound to the actual hardness-to-round of 𝑔(𝑥). 17 Since we are interested in images of elements of F, the considered intervals should also have bounds in F: our equalities are not overenthusiastic. 18 We make it clear here that the value 𝑚 we are dealing with is not "the" hardness-to-round as defined above but, as we want the former to have the same properties as the latter, we get along with the same notation. 19 Remember we did split the domain first in intervals where the initial function 𝑓 (𝑥) is increasing or decreasing. The function 𝑔(𝑥) behaves the same. If 𝑔(𝑥) is decreasing all we have to change are the bounds 𝑗 lives in.

Lemma 3.1.

If ∀𝑖 ∈ 𝑙𝑏, 𝑢𝑏 , ∀𝑗 ∈ ⌊ 𝑔 ( 𝑙𝑏 2 𝑝-1 ) 2 𝑝-1 ⌋ , ⌈ 𝑔 ( 𝑢𝑏 2 𝑝-1 ) 2 𝑝-1 ⌉ , 𝑚 ∈ N is such that ⃒ ⃒ ⃒ ⃒ 𝑃 ( 𝑖 2 𝑝-1 ) - 2𝑗 + 1 2 𝑝 ⃒ ⃒ ⃒ ⃒ 1 2 𝑚+1
(3.4)

and ⃒ ⃒ ⃒ ⃒ 𝑔 ( 𝑖 2 𝑝-1 ) -𝑃 ( 𝑖 2 𝑝-1 )⃒ ⃒ ⃒ ⃒ < 1 2 𝑚+1 , (3.5)
then

𝑚 ∈ N is such that ⃒ ⃒ ⃒ ⃒ 𝑔 ( 𝑖 2 𝑝-1 ) - 2𝑗 + 1 2 𝑝 ⃒ ⃒ ⃒ ⃒ 1 2 𝑚 .
Proof. From Expression 3.4 we have

⃒ ⃒ ⃒ ⃒ 𝑃 ( 𝑖 2 𝑝-1 ) -𝑔 ( 𝑖 2 𝑝-1 )⃒ ⃒ ⃒ ⃒ + ⃒ ⃒ ⃒ ⃒ 𝑔 ( 𝑖 2 𝑝-1 ) - 2𝑗 + 1 2 𝑝 ⃒ ⃒ ⃒ ⃒ ⃒ ⃒ ⃒ ⃒ 𝑃 ( 𝑖 2 𝑝-1 ) -𝑔 ( 𝑖 2 𝑝-1 ) + 𝑔 ( 𝑖 2 𝑝-1 ) - 2𝑗 + 1 2 𝑝 ⃒ ⃒ ⃒ ⃒ 1 2 𝑚+1 .
Combining with Expression 3.5, we have

1 2 𝑚+1 + ⃒ ⃒ ⃒ ⃒ 𝑔 ( 𝑖 2 𝑝-1 ) - 2𝑗 + 1 2 𝑝 ⃒ ⃒ ⃒ ⃒ 1 2 𝑚+1
Ultimately, we have

⃒ ⃒ ⃒ ⃒ 𝑔 ( 𝑖 2 𝑝-1 ) - 2𝑗 + 1 2 𝑝 ⃒ ⃒ ⃒ ⃒ 1 2 𝑚
In order words, provided that 1. polynomial 𝑃 (𝑥) approximates function 𝑔(𝑥) with an absolute accuracy smaller than 1 2 𝑚+1 , 2. integer 𝑚 + 1 is an upper bound on the hardness-to-round of polynomial 𝑃 (𝑥), then integer 𝑚 is an upper bound on the hardness-to-round of function 𝑔(𝑥).

The first condition sets the accuracy of the polynomial approximation of function 𝑔(𝑥) we will have to compute. The second describes the hardness-to-round problem we are going to solve about polynomial 𝑃 (𝑥) instead of the initial one we had about function 𝑔(𝑥).

Let us examine now how polynomial approximation will be performed.

Taylor truncated series/polynomials

Before we try to deal with our final goal, we have to focus a moment on how we are going to compute the polynomial approximations. We have mentioned the Remez algorithm to assert the theoretical and, in some way, practical possibility to compute polynomial approximations satisfying our accuracy requisites. But, in practice we take a different route. As the reader may have noticed we have been heavily splitting intervals above. The consequence is that we possibly end up with a very large set of subdomains. And there will be many 𝑔(𝑥) functions (up to possibly one for each subdomain obtained after the decomposition depicted in Figure 3456). This can sum up to a lot of approximations to compute and, possibly, to a hefty amount of time if an expensive approximation computation technique is picked up. The Remez algorithm execution does not always come cheap.

But there are other ways to compute function approximations that we can use. Taylor polynomials is one of them.

Taylor theorem

The following is a well known result. Full discussion and proof can be found in many textbooks such as [START_REF] Spivak | Calculus[END_REF], from p. 391et seq.

𝑔(𝑎 + ℎ) = 𝑔(𝑎) + 𝑔 ′ (𝑎) 1! ℎ + 𝑔 (2) (𝑎) 2! ℎ 2 + . . . + 𝑓 (𝑛) (𝑎) 𝑛! ℎ 𝑛 + 𝑅 𝑛,𝑎 (ℎ)
Let us set a real positive value 𝑟 and define the interval [𝑎 -𝑟, 𝑎 + 𝑟] centered on 𝑎. Under this last form of the Taylor's formula, we obtain a polynomial in ℎ that computes approximate values of 𝑔(𝑎 + ℎ) in the [𝑎 -𝑟, 𝑎 + 𝑟] interval. The maximum absolute value of the remainder 𝑅 𝑛,𝑎 (ℎ) over

[𝑎 -𝑟, 𝑎 + 𝑟] is the approximation error. We can pick the Taylor polynomial as our approximation polynomial 𝑃 (𝑥), if we make a final domain change.

Initially, we had set

[ 𝑙𝑏 2 𝑝-1 , 𝑢𝑏 2 𝑝-1
] as the approximation polynomial domain. Let us compute

𝑎 = ⌊ 𝑢𝑏 + 𝑙𝑏 2 ⌋ , 𝑟𝑙 = 𝑙𝑏 -𝑎 and 𝑟𝑢 = 𝑢𝑏 -𝑎. We will use [ 𝑟𝑙 2 𝑝-1 , 𝑟𝑢 2 𝑝-1
] as the domain for our Taylor's polynomial that computes an approximation to our initial 𝑃 (𝑥). In the sequel, and in order to limit the notation bloat, we will, also call 𝑃 (𝑥) the Taylor approximation polynomial.

As one can see, it can be computed very quickly for a given interval and a given degree. This functionality is available in many tools and, while less obvious from the formula alone, the approximation error can also be provided without the need of an extra expensive computation.

The choice of Taylor polynomials is not one of extra performance, but mainly for its convenience.

We can always compute one, for a given degree 𝑑, that has the required approximation accuracy. If this not immediately the case, we resort to our trusted splitting technique: if the error is too large, the interval is split into two (or more) subdomains where, in turn, new truncated Taylor series are computed until a sufficient accuracy is achieved.

Another advantage stems from the change of variables imposed by the form we chose for Taylor polynomials. In general the maximum absolute value of the elements in set 𝑟𝑙..𝑟𝑢 will be smaller than that of the elements in set 𝑙𝑏..𝑢𝑏 . We will see latter that this a desirable property.

This choice, of course, introduces an extra constraint on function 𝑔(𝑥): it must be differentiable to (at least) order 𝑑, where 𝑑 is the degree of the polynomial we want to compute. Other properties may be desirable, as analyticity, if we want the approximation to have a sufficient accuracy and the polynomial to have a reasonable degree. Notice that, nevertheless, what comes next is agnostic (notations excepted) to the technique that is used to compute polynomial approximations. It could be reformulated to support other approximation options.

Hardness-to-round: the definitive reformulation

We have now to combine together all the elements we have introduced in the above sections to specify the exact problem we are going to work on. Those are essentially:

• a shift in targets from checking if 𝑚 is an upper bound to the hardness-to-round of function 𝑔(𝑥) to checking if 𝑚 + 1 is such an upper bound for the approximation polynomial 𝑃 (𝑥);

• having the domain of our polynomial defined differently than that of function 𝑔(𝑥).

The image of the domain by the polynomial

Let us note min

𝑖 ∈ 𝑟𝑙..𝑟𝑢 ( RD ( 𝑃 ( 𝑖 2 𝑝-1 ))) = 𝑗 𝑙 2 𝑝-1 and max 𝑖 ∈ 𝑟𝑙..𝑟𝑢 ( RU ( 𝑃 ( 𝑖 2 𝑝-1 ))) = 𝑗 𝑢 2 𝑝-1 .
Rounding here is considered relatively to the rationals 𝑗 2 𝑝-1 (𝑗 ∈ Z).

We assume here that both 𝑗 𝑙 2 𝑝-1 and 𝑗 𝑢 2 𝑝-1 belong to the same binade. This assumption is not a thorny one since the domain we use for 𝑃 (𝑥) is designed in such way that the image of its elements by 𝑔(𝑥), live all in the same binade. Of course, since 𝑃 (𝑥) is only an approximation of 𝑔(𝑥), the image by 𝑃 ′ 𝑥 of at least one such element could live outside the common binade. Should this happen, extra splitting of the interval in order to isolate the problematic cases could solve this uncommon issue.

If we now view

[ 𝑗 𝑙 2 𝑝-1 , 𝑗 𝑢 2 𝑝-1 ]
as an interval over R, we have:

𝑃 ( 𝑟𝑙 2 𝑝-1 , 𝑟𝑢 2 𝑝-1 ) ⊂ [ 𝑗 𝑙 2 𝑝-1 , 𝑗 𝑢 2 𝑝-1
] .

Hardness-to-round reformulated

Checking if 𝑚 + 1 is the hardness-to-round for the round-to-next rounding mode of 𝑃 (𝑥) (or at least an upper bound to it) over the 𝑟𝑙 2 𝑝-1 , 𝑟𝑢 2 𝑝-1 domain can eventually be restated as:

∀𝑖 ∈ 𝑟𝑙..𝑟𝑢 , ∀𝑗 ∈ 𝑗 𝑙 , 𝑗 𝑢 , ⃒ ⃒ ⃒ ⃒ 𝑃 ( 𝑖 2 𝑝-1 ) - 2𝑗 + 1 2 𝑝 ⃒ ⃒ ⃒ ⃒ 1 2 𝑚+1 . (3.7)
We said in several occasions that we had to get rid first of all the cases where the image an element in the domain was an exact midpoint. It is important to stress this point again here. Let us suppose that one such a point of the domain, 𝑖 𝜇 , was not filtered out. Its image by 𝑃 (𝑥), 𝑃 (

𝑖𝜇 2 𝑝-1
) , will be very close to some midpoint. But as 𝑃 (𝑥) is an approximation, the image will not be exactly equal to this midpoint (and even if it were, this information would be nothing more than a hint).

At this point in the computations, it may be very difficult to decide if, either, 𝑖 𝜇 is a special case (an element whose image is a midpoint) or a particularly hard-to-round case.

Unless we have at hand, because of some simple mathematical property, an easy test to check if the image of element of the domain is a midpoint, the presence, even if residual, of special cases can make it difficult to verify that 𝑚 + 1 is or is not the actual hardness-to-round.

Out of the situation where one is absolutely sure that all special cases have been removed, and if the value of 𝑚 + 1 is large relatively to that of 𝑝, each element of the domain whose image by 𝑃 (𝑥)

is closer than 1 2 𝑚+1 to a midpoint deserves a very close scrutiny before concluding.

From rational polynomials to integer polynomials

Our next stage now is to transform our rational inequalities into integer inequalities. All we have to do is to clear out the denominators. This is done in two steps:

• a simple change of variable 𝑥 = 𝑦 2 𝑝-1 , with 𝑦 ∈ Z, yields a new polynomial 𝑃 𝑟𝑎𝑡,𝑖𝑛𝑡 (𝑦) = 𝑃 ( 𝑦 2 𝑝-1
) where 𝑃 𝑟𝑎𝑡,𝑖𝑛𝑡 (𝑦) has rational number coefficients and integer arguments.

• clear denominators by multiplying the terms that show up in the inequality of (3.7) by the least common multiple of the denominators of the coefficients of 𝑃 (𝑟𝑎𝑡,𝑖𝑛𝑡) , 2 𝑝 and 2 𝑚+1 . Now we have 𝑃 (𝑖𝑛𝑡,𝑖𝑛𝑡) (𝑖) ∈ Z[𝑖], with 𝑖 ∈ Z (where 𝑖, by an unfortunate choice in notations, is our indeterminate for integer coefficients polynomials).

From that we can deduce a new inequality:

⃒ ⃒ 𝑃 (𝑖𝑛𝑡,𝑖𝑛𝑡) (𝑖) -2 𝐾 (2𝑗 + 1) ⃒ ⃒ 2 𝑘 , (3.8)
where:

• 𝑃 (𝑖𝑛𝑡,𝑖𝑛𝑡) comes from the transformation (general reduction to the same denominator and denominators elimination) of 𝑃 (𝑟𝑎𝑡,𝑖𝑛𝑡) ;

• 𝐾 and 𝑘 have been computed in the course of the same reduction/elimination, for 1 2 𝑝 and 1 2 𝑚+1 , respectively.

Notice that we still have 𝑖 ∈ 𝑟𝑙, 𝑟𝑢 and 𝑗 ∈ 𝑗 𝑙 , 𝑗 𝑢 .

From inequality to modular equation

Inequality 3.8 is not easy to solve. We now turn it into a new form that, though this is not obvious at first glance, will be easier to deal with.

As we want our unknowns to be small 20 , we will replace 2𝑗 + 1 by 𝑃 (𝑖𝑛𝑡,𝑖𝑛𝑡) (𝑖) -2 𝐾 (2𝑗 + 1) as an unknown. Indeed, since the coefficients of 𝑃 (𝑖𝑛𝑡,𝑖𝑛𝑡) are all integers, for any 𝑖 and 𝑗 (themselves integers) the expression 𝑃 (𝑖𝑛𝑡,𝑖𝑛𝑡) (𝑖) -2 𝐾 (2𝑗 + 1) always evaluates to some integer 𝑡. Hence, Inequality 3.8 reduces to:

𝑃 (𝑖𝑛𝑡,𝑖𝑛𝑡) (𝑖) -2 𝐾 (2𝑗 + 1) = 𝑡, with 𝑡 ∈ Z and |𝑡| < 2 𝑘 .
For 𝑖 ∈ 𝑟𝑙, 𝑟𝑢 and 𝑗 ∈ 𝑗 𝑙 , 𝑗 𝑢 , we want:

𝑃 (𝑖𝑛𝑡,𝑖𝑛𝑡) (𝑖) -2 𝐾 (2𝑗 + 1) = 𝑡, with 𝑡 / ∈ {-2 𝑘 ..2 𝑘 }.
We can write 𝑃 (𝑖𝑛𝑡,𝑖𝑛𝑡) (𝑖) -𝑡 = 2 𝐾 (2𝑗 + 1).

From which we can derive (𝑃 (𝑖𝑛𝑡,𝑖𝑛𝑡) (𝑖) -𝑡) mod 2 𝐾 = (2 𝐾 (2𝑗 + 1)) mod 2 𝐾 = 0 mod 2 𝐾 .

Let us now define the polynomial 𝑄(𝑖, 𝑡) ∈ Z as 𝑄(𝑖, 𝑡) = 𝑃 (𝑖𝑛𝑡,𝑖𝑛𝑡) (𝑖) -𝑡, with 𝑖, 𝑡 ∈ Z. Let us also set 𝒩 = 2 𝐾 .

We have now 𝑄(𝑖, 𝑡) ∈ Z[𝑖, 𝑡], with 𝑖, 𝑡 ∈ Z. The hardness-to-round check problem becomes:

prove that 𝑄(𝑖, 𝑡) mod 𝒩 = 0 has no solution for 𝑖 ∈ 𝑟𝑙, 𝑟𝑢 and 𝑡 ∈ -2 𝑘 , 2 𝑘 . (3.9)

It may seem that no progress has been done so far since we are grappling now with a bivariate polynomial modular equation which is not at all easy to solve. But due to some particular characteristics of the problem 21 , we will manage to transform it into a set of bivariate polynomial equations over the integers, which is a more amenable one.

From a modular equation to an equation over the integers

We are going to examine here the conditions under which the above announced transformation can take place. For this purpose, we are going to use an adaptation of the Coppersmith techniques devised for cryptanalysis purposes. When it comes to polynomial roots, Coppersmith has developed two different techniques:

• one for finding small roots of univariate modular polynomial equations [START_REF] Coppersmith | Finding a Small Root of a Univariate Modular Equation[END_REF];

• another for small roots of bivariate polynomial equations over the integers [START_REF] Coppersmith | Finding a Small Root of a Bivariate Integer Equation; Factoring with High Bits Known[END_REF]. 20 The explanation for this "small is beautiful" preference will be given soon. 21 Mainly the fact that we are looking for bounded and small solutions and not trying to solve the problem in general. More about this to come next.

Our main interest is in the first provided it is extended to cope with two variables since Coppersmith's seminal work is only about univariate polynomials. Furthermore, Coppersmith's initial algorithm was seen as a bit involved. Fortunately, clarification and extensions to bivariate polynomials have been realized in two steps by N. Howgrave-Graham (univariate untangled version [START_REF] Howgrave-Graham | Finding Small Roots of Univariate Modular Equations Revisited[END_REF]) and D. Boneh and G. Durfee (bivariate version [START_REF] Boneh | Cryptanalysis of RSA with Private Key 𝑑 less than 𝑁 0.292[END_REF]).

Regrettably, a property was lost in the extension process: while Coppersmith's algorithm is proved to actually yield all the small roots, bivariate extensions can only be dubbed as "heuristic" for a reason that will be detailed below.

These tools were initially developed in the context of the cryptanalysis of RSA, for solving what is known as "The small inverse problem" in this community. But their scope has been extending ever since.

We are going here to rephrase their formalization in the language of our own context. It all starts with the following definition and theorem. Then ℎ(𝑖 0 , 𝑡 0 ) = 0 holds over the integers.

In other words, if (𝑖 0 , 𝑡 0 ) a solution of the modular equation and two conditions (one on the absolute values of 𝑖 0 and 𝑡 0 , another one (often referred to as the Coppersmith condition) on the norm of ℎ(𝑖, 𝑡)) hold, (𝑖 0 , 𝑡 0 ) is also a solution over the integers. The similarity with our problem is pretty obvious. The conditions on the absolute values of 𝑖 0 and 𝑡 0 translate almost transparently into the 𝑖 ∈ 𝑟𝑙, 𝑟𝑢 and 𝑡 ∈ -2 𝑘 , 2 𝑘 ones. We will see below what can be done for the more intricate condition on the polynomial norm.

Let us start first with the proof of Theorem3.3.

Proof.

|ℎ(𝑖 0 , 𝑡 0 )| = ⃒ ⃒ ⃒ ∑ 𝑎 𝜌,𝜎 𝑖 𝜌 𝑡 𝜎 ⃒ ⃒ ⃒ ∑ |𝑎 𝜌,𝜎 ||𝑖| 𝜌 |𝑡| 𝜎 ∑ |𝑎 𝜌,𝜎 |𝐼 𝜌 𝑇 𝜎 .
By the Cauchy-Schwarz inequality:

∑ |𝑎 𝜌,𝜎 𝐼 𝜌 𝑇 𝜎 | ‖(|𝑎 𝜌1,𝜎1 𝐼 𝜌1 𝑇 𝜎 𝑙 | , . . . , |𝑎 𝜌𝑤,𝜎𝑤 𝐼 𝜌𝑤 𝑇 𝜎𝑤 |)‖ × ‖(1 , . . . , 1)‖ = √ ∑ |𝑎 𝜌,𝜎 𝐼 𝜌 𝑇 𝜎 | 2 × ⎯ ⎸ ⎸ ⎷ 𝑤 ∑ 1 1 2 = √ ∑ |𝑎 𝜌,𝜎 𝐼 𝜌 𝑇 𝜎 | 2 × √ 𝑤.
In this case, we have √ ∑ |𝑎 𝜌,𝜎 𝐼 𝜌 𝑇 𝜎 | 2 = ‖ℎ(𝑖𝐼, 𝑡𝑇 )‖ (if we aggregate 𝐼 and 𝑇 , at their respective powers, to the coefficients).

Hence:

|ℎ(𝑖 0 , 𝑡 0 )| ≤ ‖ℎ(𝑖𝐼, 𝑡𝑇 )‖ √ 𝑤.
From condition 2 of Theorem 3.3:

|ℎ(𝑖 0 , 𝑡 0 )| ≤ ‖ℎ(𝑖𝐼, 𝑡𝑇 )‖ √ 𝑤 < 𝒩 .
Hence:

|ℎ(𝑖 0 , 𝑡 0 )| < 𝒩 .
Since, from condition 1 of Theorem 3.3, ℎ(𝑖 0 , 𝑡 0 ) = 0 mod 𝒩 , therefore ℎ(𝑖 0 , 𝑡 0 ) = 0.

Families of modular equations

Let us return to our problem (and notations) and assume now that (𝑖 0 , 𝑡 0 ) is a solution to our modular equation 𝑄(𝑖, 𝑡) = 0 mod 𝒩 .

For reasons that will become clearer below, it is necessary to derive other modular equations from our original one, actually a full family of them, whose solutions, if any, include all those of 𝑄(𝑖, 𝑡) = 0 mod 𝒩 .

For instance, the above mentioned pair (𝑖 0 , 𝑡 0 ) is also a solution of 𝑄(𝑖, 𝑡) 2 = 0 mod 𝒩 2 . But there are many other modular equations that also share this property. To mention a few:

• 𝒩 𝑄(𝑖, 𝑡) = 0 mod 𝒩 2 also accepts (𝑖 0 , 𝑡 0 ) as a solution;

• as does ℓ 𝒩 𝑄(𝑖, 𝑡) = 0 mod 𝒩 2 , ∀ ℓ ∈ Z, and, particularly, 𝑖 𝒩 𝑄(𝑖, 𝑡) = 0 mod 𝒩 2 and 𝑡 𝒩 𝑄(𝑖, 𝑡) = 0 mod 𝒩 2 ;

• as also do 𝑖 2 𝒩 𝑄(𝑖, 𝑡) = 0 mod 𝒩 2 , 𝑖 𝑡 𝒩 𝑄(𝑖, 𝑡) = 0 mod 𝒩 2 , 𝑡 2 𝒩 𝑄(𝑖, 𝑡) = 0 mod 𝒩 2 and so forth, since 𝑖 and 𝑡 are integers;

• as will also do any modular equation formed, for its left member, by a linear combination of the left members, 𝑙 𝑗 (𝑖, 𝑡), of the above given equations, ∑ 𝜆 𝑗 𝑙 𝑗 (𝑖, 𝑡) = 0 mod 𝒩 2 , 𝜆 𝑗 ∈ Z.

We can generalize our previous examples as follows. Let 𝛼 be an integer parameter, if (𝑖 0 , 𝑡 0 ) is a solution to 𝑄(𝑖, 𝑡) = 0 mod 𝒩 , then any modular equation of the following form:

𝑖 𝑟 𝑡 𝑠 𝒩 𝑢 𝑄(𝑖, 𝑡) 𝛼-𝑢 = 0 mod 𝒩 𝛼 , with 𝑟, 𝑠 ∈ N and 𝑢 ∈ 0, 𝛼 , (

will also accept (𝑖 0 , 𝑡 0 ) as a solution.

We can even generalize further, to linear combinations of equations of the above form:

∑ 𝑗 𝜆 𝑗 𝑖 𝑟𝑗 𝑡 𝑠𝑗 𝒩 𝑢𝑗 𝑄(𝑖, 𝑡) 𝛼-𝑢𝑗 = mod 𝒩 𝛼 , with 𝜆 𝑗 ∈ Z, 𝑟 𝑗 , 𝑠 𝑗 ∈ N and 𝑢 𝑗 ∈ 0, 𝛼
The idea is, using these linear combinations, to build two polynomials of small norm so the second condition of Howgrave-Graham's Theorem holds for each of them. If this is the case, we have a system of two polynomials and two unknowns which we can try to solve over the integers.

If we can find roots over the integer -i.e. non-modular roots -(which is much easier here than solving modular equations), we will check them against our initial modular equation:

In this context, B, is called the basis of 𝐿 and 𝐿 the lattice generated by B.

The rank of the lattice, rank(𝐿) is the dimension of the linear span of the basis of 𝐿, 𝑚, since we have assumed that the b 𝑖 vectors are linearly independent. When rank(𝐿) = 𝑛 the lattice is said to be full-rank.

Another very common presentation is based on linearly independent row vectors. Several tools (e.g. fplll [START_REF] Albrecht | fplll-4.0, a floating-point LLL implementation[END_REF]) assume this representation. We will exclusively use it now on to keep the presentation and the programs in line.

From integer coefficient polynomials to lattices and back

The general idea is to use a family of polynomials built along the lines proposed in §3.3.8, p. 167.

These polynomials are linearly independent. From these polynomials, we are going extract linearly independent vectors that can form the basis of a lattice:

1. we set an order on the monomials found in the polynomials;

2. from each polynomial we derive a vector whose elements are the coefficients;

3. more precisely, to build a vector, we pick the coefficients of the monomials in the polynomial, in the order set above;

4. by stacking the obtained row vectors, we can create a matrix representing a basis of some lattice 𝐿;

5. this basis is then 𝐿𝐿𝐿-reduced (see the proper definition coming soon below);

6. we use the shortest-norm (hopefully satisfying Coppersmith's condition) vectors pair of the 𝐿𝐿𝐿-reduced basis to recreate polynomials (reversing the above process) and compute the roots (by techniques exposed below) of this polynomial equations system; 7. if the set of the roots is not empty, check these against our initial polynomial equation (𝑄(𝑖, 𝑡) = 0 mod 𝒩 ), since if the latter equation has roots they will necessarily show up in the former set.

This informal sketch still leaves many unresolved issues that we will tackle in the upcoming sections. We will try first to clarify what an 𝐿𝐿𝐿-reduced basis is. For that purpose the first needed concept is that of Gram-Schmidt orthogonalization.

Gram-Schmidt orthogonalization

Orthogonality of a lattice basis is measured by comparing it with that of the matching orthogonal basis.

Let us first remind here the Gram-Schmidt 22 orthogonalization process that, starting from a basis of a subspace of R 𝑛 , computes an orthogonal basis with the following properties.

Input: a family (𝑏 1 , . . . , 𝑏 𝑚 ) of linearly independent vectors of R 𝑛 , with 𝑛 𝑚 Output: a family (𝑏 * 1 , . . . , 𝑏 * 𝑚 ) of linearly independent vectors of R 𝑛 such that

• (𝑏 * 1 , . . . , 𝑏 * 𝑚 ) is orthogonal; • Vect(𝑏 * 1 , . . . , 𝑏 * 𝑘 ) = Vect(𝑏 1 , . . . , 𝑏 𝑘 ) for all 𝑘, 1 𝑘 𝑚.
We first set 𝑏 * 1 = 𝑏 1 . Next, each 𝑏 * 𝑘 is computed by projecting 𝑏 𝑘 orthogonally along the subspace Vect(𝑏 1 , . . . , 𝑏 𝑘-1 ).

We search for 𝑏 * 𝑘 as 𝑏 𝑘 -

𝑘-1 ∑ 𝑖=1 𝜇 𝑘,𝑖 𝑏 * 𝑖 ; as ⟨𝑏 * 𝑘 , 𝑏 * 𝑖 ⟩ has to be 0, we deduce 𝜇 𝑘,𝑖 = ⟨𝑏 𝑘 , 𝑏 * 𝑖 ⟩/‖𝑏 * 𝑖 ‖ 2 .
Notice that for all 𝑖 = 1, . . . , 𝑚, ||𝑏 * 𝑖 || ||𝑏 𝑖 ||.

See [START_REF] Zur Gathen | Modern Computer Algebra[END_REF] for a detailed description of Gram-Schmidt orthogonalization.

Notice that if the vector family (𝑏 1 , . . . , 𝑏 𝑚 ) defines a lattice, there is no reason why the family (𝑏 * 1 , . . . , 𝑏 * 𝑚 ) should define the same one.

Determinant of a lattice

Let now 𝐿 be the lattice generated by a family (𝑏 1 , . . . , 𝑏 𝑚 ) of linearly independent vectors of R 𝑛 , with 𝑚 ≤ 𝑛.

Let us consider the matrix 𝑀 formed by the 𝑚 row vectors, as explained above, and define the volume of lattice 𝐿 as vol(𝐿) = √ det(𝑀 × 𝑀 𝑇 )

The quantity det(𝑀 × 𝑀 𝑇 ) is often called the Gram determinant of 𝑀 or its Gramian (see [START_REF] Gantmacher | The Theory of Matrices[END_REF] p. 246-256).

This definition of the volume is less common than the more usual vol(𝐿) = | det(𝑀 )| that only applies to square matrices. But since 𝑀 needs not be square (when 𝑚 ̸ = 𝑛), we rather consider the square root of the Gramian of the family (𝑏 1 , . . . , 𝑏 𝑚 ).

When the matrix 𝑀 is square, of course, both definitions of the volume coincide, we have Proof. Since the vectors of the (𝑏 * 1 , . . . , 𝑏 * 𝑚 ) family are mutually orthogonal and if we consider the 𝑀 * matrix formed by these row vectors, we have:

det 𝑀 = ± √ det(𝑀 × 𝑀 𝑇 ).
𝑀 * × 𝑀 *𝑇 = ⎡ ⎢ ⎢ ⎢ ⎢ ⎢ ⎢ ⎢ ⎢ ⎢ ⎢ ⎢ ⎢ ⎢ ⎢ ⎢ ⎣ ||𝑏 *
⎤ ⎥ ⎥ ⎥ ⎥ ⎥ ⎥ ⎥ ⎥ ⎥ ⎥ ⎥ ⎥ ⎥ ⎥ ⎥ ⎦ , since ⟨𝑏 * 𝑖 , 𝑏 * 𝑗 ⟩ = 0 for 𝑖 ̸ = 𝑗 and ||𝑏 * 𝑖 || = √ ⟨𝑏 * 𝑖 , 𝑏 * 𝑖 ⟩.
As 𝑀 * × 𝑀 * is a square diagonal matrix:

det(𝑀 * × 𝑀 * ) = 𝑚 ∏ 𝑖=1 ||𝑏 * 𝑖 || 2 (the product of the diagonal elements).
We also have, from the description of the GSO,

⎡ ⎢ ⎢ ⎢ ⎢ ⎢ ⎢ ⎢ ⎣ 𝑀 * ⎤ ⎥ ⎥ ⎥ ⎥ ⎥ ⎥ ⎥ ⎦ = ⎡ ⎢ ⎢ ⎢ ⎢ ⎢ ⎢ ⎢ ⎢ ⎢ ⎣ 1 * . . . * * 0 1 . . . * * . . . . . . . . . . . . . . . 0 0 . . . 1 * 0 0 . . . 0 1 ⎤ ⎥ ⎥ ⎥ ⎥ ⎥ ⎥ ⎥ ⎥ ⎥ ⎦ × ⎡ ⎢ ⎢ ⎢ ⎢ ⎢ ⎢ ⎢ ⎣ 𝑀 ⎤ ⎥ ⎥ ⎥ ⎥ ⎥ ⎥ ⎥ ⎦
, where we have an upper triangular matrix formed with the previously defined 𝜇 𝑖,𝑗 in the orthogonalization process (denoted here by "*" as we do not care about their actual value) and whose diagonal elements are all 1s.

When is comes to the transposed matrices, we also have

⎡ ⎢ ⎢ ⎢ ⎢ ⎢ ⎢ ⎢ ⎣ 𝑀 * ⎤ ⎥ ⎥ ⎥ ⎥ ⎥ ⎥ ⎥ ⎦ = ⎡ ⎢ ⎢ ⎢ ⎢ ⎢ ⎢ ⎢ ⎣ 𝑀 ⎤ ⎥ ⎥ ⎥ ⎥ ⎥ ⎥ ⎥ ⎦ × ⎡ ⎢ ⎢ ⎢ ⎢ ⎢ ⎢ ⎢ ⎢ ⎢ ⎣ 1 0 . . . 0 0 * 1 . . . 0 0 . . . . . . . . . . . . . . . * * . . . 1 0 * * . . . * 1 ⎤ ⎥ ⎥ ⎥ ⎥ ⎥ ⎥ ⎥ ⎥ ⎥ ⎦ .
We can form the 𝑀 𝑀 product as

⎡ ⎢ ⎢ ⎢ ⎢ ⎢ ⎢ ⎢ ⎣ 𝑀 * ⎤ ⎥ ⎥ ⎥ ⎥ ⎥ ⎥ ⎥ ⎦ × ⎡ ⎢ ⎢ ⎢ ⎢ ⎢ ⎢ ⎢ ⎣ 𝑀 * ⎤ ⎥ ⎥ ⎥ ⎥ ⎥ ⎥ ⎥ ⎦ = ⎡ ⎢ ⎢ ⎢ ⎢ ⎢ ⎢ ⎢ ⎢ ⎢ ⎣ 1 * . . . * * 0 1 . . . * * . . . . . . . . . . . . . . . 0 0 . . . 1 * 0 0 . . . 0 1 ⎤ ⎥ ⎥ ⎥ ⎥ ⎥ ⎥ ⎥ ⎥ ⎥ ⎦ × ⎡ ⎢ ⎢ ⎢ ⎢ ⎢ ⎢ ⎢ ⎣ 𝑀 ⎤ ⎥ ⎥ ⎥ ⎥ ⎥ ⎥ ⎥ ⎦ × ⎡ ⎢ ⎢ ⎢ ⎢ ⎢ ⎢ ⎢ ⎣ 𝑀 ⎤ ⎥ ⎥ ⎥ ⎥ ⎥ ⎥ ⎥ ⎦ × ⎡ ⎢ ⎢ ⎢ ⎢ ⎢ ⎢ ⎢ ⎢ ⎢ ⎣ 1 0 . . . 0 0 * 1 . . . 0 0 . . . . . . . . . . . . . . . * * . . . 1 0 * * . . . * 1 ⎤ ⎥ ⎥ ⎥ ⎥ ⎥ ⎥ ⎥ ⎥ ⎥ ⎦ .
As the determinant of our upper and lower triangular matrices is 1, we can deduce

vol(𝐿) = √ det(𝑀 * × 𝑀 * ) = 𝑚 ∏ 𝑖=1 ||𝑏 * 𝑖 ||.

𝐿𝐿𝐿-algorithm

The 𝐿𝐿𝐿-algorithm, created by A. Lenstra, H. Lenstra and L. Lovász in 1982, performs an operation called lattice basis reduction. Given a basis (𝑣 1 , . . . , 𝑣 𝑚 ) of 𝐿, the 𝐿𝐿𝐿-algorithm [START_REF] Lenstra | Factoring polynomials with rational coefficients[END_REF] computes in polynomial time a new basis of 𝐿, (𝑏 1 , . . . , 𝑏 𝑚 ), (called the 𝐿𝐿𝐿-reduced basis), from which we can derive the the orthogonal (𝑏 * 1 , . . . , 𝑏 * 𝑚 ) basis by GSO, with the following properties:

• ∀𝑘, if 𝑏 𝑘 = 𝑏 * 𝑘 + 𝑘-1 ∑ ℓ=1 𝜇 𝑘,ℓ 𝑏 * ℓ , then |𝜇 𝑘,ℓ | ≤ 1 2 , ∀ℓ ∈ 1, 𝑘 -1 ; • ||𝑏 * 𝑘 + 𝜇 𝑘,𝑘-1 𝑏 * 𝑘-1 || 2 3 4 ||𝑏 * 𝑘-1 || 2 , ∀ 𝑘 ∈ {2..𝑚}.
The constant 3 4 above is somewhat arbitrary and is a parameter of the algorithm that can be replaced by any fixed real number 𝛿 such that 1 4 < 𝛿 < 1. The 1 strict upper bound must be honored to guarantee polynomial time.

Notice that the second property applies to the elements of the set of vectors 23 produced by the Gram-Schmidt orthogonalization of the 𝐿𝐿𝐿-reduced basis and not to the reduced basis itself.

This property tells us more than one could think at first sight about the reduced basis itself. If we combine both properties, we obtain

||𝑏 * 𝑘 || ||𝑏 * 𝑘-1 || 2
. This indicates that the norm of the Gram-Schmidt orthogonal vectors does not decrease too quickly. Intuitively this means that the vectors of the reduced basis are near-orthogonal or at least not too far from being orthogonal. Indeed, it is when vectors of the basis are the closest to be collinear that the sharpest reductions of norm are seen along the Gram-Schmidt orthogonalization process. And this near-orthogonality property has also the interesting consequence that the first (and often the first follow-up) vector(s) is(are) have relatively short norms.

Another theorem, derived from the original LLL article [START_REF] Lenstra | Factoring polynomials with rational coefficients[END_REF] by Alexander May (the proof can be found in his PhD thesis [START_REF] May | New RSA Vulnerabilities Using Lattice Reduction Methods[END_REF]), puts more emphasis on 𝐿𝐿𝐿-reduced basis vectors ordering and on the individual upper bound of their norm.

Theorem 3.5. Let L be a lattice of dimension 𝑚. In polynomial time, the 𝐿𝐿𝐿-algorithm outputs a reduced basis (𝑏 1 , . . . , 𝑏 𝑚 ) such that:

‖𝑏 1 ‖ ‖𝑏 2 ‖ • • • ‖𝑏 𝑖 ‖ 2 𝑚(𝑚-1) 4(𝑚+1-𝑖) det(𝐿) 1 𝑚+1-𝑖 .
We will not enter into much details about the 𝐿𝐿𝐿-algorithm as we will mainly use as a black box.

However, the original 𝐿𝐿𝐿-algorithm is mainly of theoretical interest, since, although it has polynomial time complexity, it remains quite slow in practice. Instead, floating-point variants are used, where the underlying Gram-Schmidt orthogonalization is performed with floating-point numbers rather than with rational arithmetic (which produces huge numerators and denominators).

In the floating-point versions of the algorithm, another parameter 𝜂 is often introduced. We recall here the following theorem under a formulation authored by D. Stehlé in [START_REF] Stehlé | Floating-point lll: Theoretical and practical aspects[END_REF] that rephrases in the floating-point context the one found in the editio princeps [START_REF] Lenstra | Factoring polynomials with rational coefficients[END_REF] of the Lenstra, Lenstra and Lovász article.

Theorem 3.6. Let 𝛿 ∈ (1/4, 1] and 𝜂 ∈ [1/2, √ 𝛿). Let (𝑏 1 , . . . , 𝑏 𝑚 ) be a (𝛿, 𝜂)-𝐿𝐿𝐿-reduced basis of the 𝐿 lattice. Then:

‖𝑏 1 ‖ ( 2 𝛿 -𝜂 2 ) 𝑚-1 4 vol(𝐿) 1 𝑚 . 𝑚 ∏ 𝑘=1 ‖𝑏 𝑘 ‖ ( 2 𝛿 -𝜂 2 ) 𝑚(𝑚-1) 4 vol(𝐿).
The value of 𝛿 is as above (0.25 < 𝛿 < 1.0) and that of 𝜂 is 0.5 ≤ 𝜂 < √ 𝛿. In practice, we use 𝛿 = 0.99 and 𝜂 = 0.501.

All these elements should convince ourselves that the norms of the first vectors of an 𝐿𝐿𝐿-reduced basis of a lattice are shorter than those from a random basis.

It may be useful to remind here that the vectors of the reduced basis represent polynomials (according to the mapping exposed in §3.4.2, p. 169), each element of a vector being a coefficient for the monomial at the matching index in the corresponding polynomial. Hence, computing the ℓ 2 -norm of the vectors is equivalent to computing the norm of the polynomials as defined for Theorem 3.3.

And this is where we eventually wanted to get: have vectors a small enough norm so that they can satisfy Condition 2 of Theorem 3.3?

Hence, after reduction, we will filter out the vectors of the basis whose norm is too large (thanks to the nice norm ordering property of the reduced basis, it suffices to stop as soon as we get a vector that does not match the norm condition) and transform vectors back to polynomials. This involves getting rid of 𝐼 and 𝑇 , the bounds for 𝑖 and 𝑡, respectively, taking into account the exponent according to which monomial we are dealing with.

Back to the general algorithm

We had to make this rather long detour through the 𝐿𝐿𝐿-algorithm and its application to our problem because it is a key element in the overall strategy. We wanted to make its contribution clear and show how it fits in the whole process. It is time now to return to the main algorithm, and make use of the results obtained through 𝐿𝐿𝐿-reduction.

Chasing the roots of the polynomials

Let us call 𝑄 1 (𝑖, 𝑡), . . . 𝑄 𝑛 (𝑖, 𝑡) the polynomials reconstructed from the vectors of the 𝐿𝐿𝐿-reduced basis that comply with Condition 2 of Theorem 3.3. We know for sure now all the roots (𝑖 0 , 𝑡 0 ) such that |𝑖 0 | 𝐼 and |𝑡 0 | 𝑇 of 𝑄(𝑖, 𝑡) are also roots of any of the 𝑄 𝑘 's, with 𝑘 ∈ {1, . . . , 𝑛}.

At this point, a possible technique would be to search for the integral roots of any of these 𝑄 𝑘 's and check them against the 𝐼 and 𝑇 bounds and, if they successfully take the test, eventually check them against the 𝑄(𝑖, 𝑡) mod 𝒩 expression to verify if they are also modular roots of this polynomial.

But finding the zero integer set of a single bivariate polynomial (which forms an underdetermined system) is by no means easy. The problem is indeed geometrically ill-posed as, generically, a single polynomial defines a curve.

Fortunately this is not necessary as we do not need all the integral roots of any of the 𝑄 𝑘 's by itself. Since the roots of polynomial 𝑄(𝑖, 𝑡) are common to all the 𝑄 𝑘 's, it suffices to find the roots common to a pair of the latter to get all we want (and possibly more: a superset) for the former. In contrast with our single polynomial roots search, a system of two bivariate polynomial equations is, since it defines the intersection of two curves, often a finite set of points, a well-posed problem. By "often", we mean as soon as the two polynomials forming the system are coprime. Unfortunately, the technique used to generate them only guarantees linear independence over Z but not over Z[𝑥, 𝑦].

As a consequence, we can not just pick any two random 𝑄 𝑘 's and go for their common roots.

The fact that pairs of polynomials returned after basis reduction and norm checking may still have a non-trivial GCD is the reason why the algorithm we use for root finding of modular polynomial equations is dubbed as "heuristic" rather than proved. This property (or lack thereof) is often mentioned in literature because, in contrast, Coppersmith's algorithm for univariate polynomials is proved.

In our context, the fact that, at some step, we use a heuristic algorithm does not imply that our own algorithm, considered as as a whole, can itself be called "heuristic". For our application, in case we cannot get two polynomials with a non-trivial GCD, we always have the option to split the interval we are currently working on. The number of polynomials matching Coppersmith's condition will generally be larger on this reduced interval (essentially because of a smaller value for constant 𝐼), increasing therefore the odds to find among them a pair that comply with the coprime condition.

Should splitting continue all the way down to a single floating-point number, direct checking of this value for hardness-to-round would solve the problem. Of course, we do not want this to happen often, if at all: it would turn down into an overwhelmingly expensive way to perform exhaustive search! In practice, it does not and splitting to smaller but still reasonably large intervals always saves the day.

Nevertheless, the complexity of the method is heuristic, since all the analysis rests on the fact that the first two first polynomials are coprime.

Root finding with the resultant method

We will not recall resultant theory at large which is a vast and intricate domain. A more detailed approach and the proofs of several lemmas used here can be found in von zur Gathen and Gerhard's work [START_REF] Zur Gathen | Modern Computer Algebra[END_REF] from which we borrow and specialize the following results.

Theorem 3.7. (Gauss) If R is a unique factorization domain (UFD), then R[x] is a UFD.

A proof of the theorem can be found in the above cited reference. As Z is a UFD and after Nevertheless, and by same token, Z[𝑥, 𝑦] is a UFD.

From the coefficients of two polynomials 𝑝 and 𝑞 of Z[𝑥, 𝑦], one can build their Sylvester matrix 𝑆𝑦𝑙(𝑝, 𝑞). It can be constructed in different ways, according to our view of the polynomials as ele-

ments of Z[𝑥][𝑦] or of Z[𝑦][𝑥].
In the first case the elements of the Sylvester matrix are polynomials in 𝑥. In the second case they are polynomials in 𝑦.

We will focus now on the first case, for reasons that will become clear later on. Nevertheless what comes next also applies to the second case.

One can compute the determinant of the Sylvester matrix, that, in our first case, is called the resultant of 𝑝 and 𝑞 with respect to 𝑦, res 𝑦 (𝑝(𝑥, 𝑦), 𝑞(𝑥, 𝑦)). It is also a polynomial in 𝑥.

We borrow again 24 this second result from [START_REF] Zur Gathen | Modern Computer Algebra[END_REF].

Theorem 3.8. Let 𝑅 be a UFD and 𝑝, 𝑞 ∈ 𝑅[𝑦] not both zero. Then gcd(𝑝, 𝑞) is nonconstant in

𝑅[𝑦] if and only if res (𝑝, 𝑞) = 0 in 𝑅.
The proof of this theorem can also be found in the above cited reference.

We can use it to our advantage if we identify 𝑅 with Z[𝑥] and res (𝑝, 𝑞) with res 𝑦 (𝑝, 𝑞).

This result has two important consequences:

• it provides us with a criterion to check if two polynomials are coprime (their resultant is nonzero);

• when the resultant is nonzero, we can search for its roots in 𝑥 (remember the resultant is a polynomial in 𝑥); if any, those form a superset of the roots 𝑝 and 𝑞 have in common.

At this point let us come back to our original problem and recover our initial notation. Here 𝑖 (resp. 𝑡) corresponds to 𝑥 (resp. 𝑦). From now on, we will use the former.

As a reminder, we were looking for roots of polynomial 𝑄(𝑖, 𝑡) = 0 mod 𝒩 . Those, if any, are common to Coppersmith's condition compliant (𝑄 𝑗 (𝑖, 𝑡), 𝑄 𝑘 (𝑖, 𝑡)) pairs, if any, obtained after the 𝐿𝐿𝐿-reduction. This way, we can find all the roots for 𝑄(𝑖, 𝑡) = 0 mod 𝒩 that are bounded as follows: |𝑖| < 𝐼 and |𝑡| < 𝑇 .

To summarize, once res 𝑡 (𝑄 𝑗 (𝑖, 𝑡), 𝑄 𝑘 (𝑖, 𝑡)) is computed 25 , we have four options:

• res 𝑡 (𝑄 𝑗 (𝑖, 𝑡), 𝑄 𝑘 (𝑖, 𝑡)) = 0: we can say nothing about any common roots; as we have seen 𝑄 𝑗 and 𝑄 𝑘 have at least a common factor; for our problem this implies a complete new search from the start on a smaller interval;

• res 𝑡 (𝑄 𝑗 (𝑖, 𝑡), 𝑄 𝑘 (𝑖, 𝑡)) is a nonzero constant: there is no root common to 𝑄 𝑗 (𝑖, 𝑡) and 𝑄 𝑘 (𝑖, 𝑡); in our case it follows that no hard to round case exists in the considered interval;

• in the remaining case res 𝑡 (𝑄 𝑗 (𝑖, 𝑡), 𝑄 𝑘 (𝑖, 𝑡)) has a degree in 𝑖 larger or equal to one, we try to compute its integral roots; according to the result we have two sub-cases:

no integral root is found; again, there is no integral root common to 𝑄 𝑗 (𝑖, 𝑡) and 𝑄 𝑘 (𝑖, 𝑡), no hard-to-round case exists,

the number of roots found is nonzero, value checking is now necessary.

As stated above, root checking is only necessary if, for two polynomials 𝑄 𝑗 (𝑖, 𝑡) and 𝑄 𝑘 (𝑖, 𝑡) with 𝑗 ̸ = 𝑘, polynomial res 𝑡 (𝑄 𝑗 (𝑖, 𝑡), 𝑄 𝑘 (𝑖, 𝑡)) ∈ Z[𝑖] has integral roots. If there are such 𝑖 𝑟 ∈ Z, 𝑟 ∈ N, the next logical step could be, for each root 𝑖 𝑟 , to compute the corresponding value(s) 𝑡 𝑟,𝑠 ∈ Z, 𝑠 ∈ N to form as many as possible (𝑖 𝑟 , 𝑡 𝑟,𝑠 ) root pairs common to 𝑄 𝑗 (𝑖, 𝑡) and 𝑄 𝑘 (𝑖, 𝑡).

There are several ways to do it but we must notice here that it is pointless. Indeed, computing values for 𝑡 involves more or less expensive resultant computations and/or root finding searches.

These roots should also be checked for bounds conformity (|𝑖 𝑟 | < I and |𝑡 𝑟,𝑠 | < 𝑇 , which, admittedly is computationally cheap) and against 𝑄(𝑖, 𝑡) and 𝒩 ) (𝑄(𝑖 𝑟 , 𝑡 𝑟,𝑠 ) = 0 mod 𝒩 ) for validity (remember we have possibly computed a superset of the roots of 𝑄(𝑖, 𝑡)).

We can bypass all of these root computations and checks to go straight ahead towards what really matters to us: do these values 𝑖 𝑟 correspond to hard-to-round cases? Of course, we fork here from the classical descriptions found in cryptography-related literature because our target is different. In fact, we do not care one iota about the 𝑡 𝑟,𝑠 values.

We can do then straightforwardly:

• scale back 𝑖 𝑟 to the corresponding floating-point value 𝑋 𝑟 in the 𝑔(𝑥) function domain;

• compute 𝑔 (𝑋 𝑟 ) with enough accuracy (e.g. using an arbitrary precision package like MPFR);

• check whether the obtained image is a hard-to-round case.

Producing the initial basis

We deal, at the bottom of this section, with a question that chronologically should rest on the top.

If we have commented at length on how to manipulate (essentially, reduce) our initial basis and what to do with the output of these transformations (root search and check), we have not said much about how we build it in the first place. It is about time to fill this gap.

We will start with a small reminder on what the initial basis is made of. We noticed that if (𝑖 0 , 𝑡 0 ) is a solution of 𝑄(𝑖, 𝑡) = 0 mod 𝒩 , we can build new polynomial modular equations based on 𝑄(𝑖, 𝑡), 𝑖, 𝑡, and 𝒩 that also have (𝑖 0 , 𝑡 0 ) among their own roots (if any).

They could have, for instance, the following general form:

𝑖 𝑟 𝑡 𝑠 𝑄(𝑖, 𝑡) 𝑢 𝒩 𝑣 = 0 mod 𝒩 𝑢+𝑣 , with: 𝑟, 𝑠, 𝑢, 𝑣 ∈ N.

We have two groups of exponents here:

• 𝑢 and 𝑣 that set the modulus of the modular equations: 𝒩 𝑢+𝑣 ;

• 𝑟 and 𝑠 whose different values allow for the creation of new polynomials but have no effect on the modulus.

If we are to build a consistent basis, the polynomials we use should all be related to the same modulus in modular equations. As we will see later, the exponent of 𝒩 in the modulus, as well as 𝑑 (the degree in 𝑖 of polynomial 𝑄(𝑖, 𝑡)), is one of the key parameters of the method. Let us call that exponent 𝛼.

Our previous general form goes now as:

𝑖 𝑟 𝑡 𝑠 𝑄(𝑖, 𝑡) 𝑢 𝒩 𝛼-𝑢 = 0 mod 𝒩 𝛼 , with: 𝑟, 𝑠, 𝑢, 𝛼 ∈ N and 𝑢 𝛼.

Following D. Boneh and G. Durfee in [START_REF] Boneh | Cryptanalysis of RSA with Private Key 𝑑 less than 𝑁 0.292[END_REF] but using our own notations in the sake of presentation consistency, we will create two new kinds of polynomials:

• 𝑖𝑠 𝑟,𝑢 (𝑖, 𝑡) = 𝑖 𝑟 𝑄(𝑖, 𝑡) 𝑢 𝒩 𝛼-𝑢 , called 𝑖-shifts by D. Boneh and G. Durfee;

• 𝑡𝑠 𝑠,𝑢 (𝑖, 𝑡) = 𝑡 𝑠 𝑄(𝑖, 𝑡) 𝑢 𝒩 𝛼-𝑢 , that are called 𝑡-shifts;

Remark

One may notice that there are none of what we could call mixed "𝑖𝑡-shifts" where both 𝑖 and 𝑡 show up with a nonzero exponent. In fact, those are not always necessary when, depending on the form of 𝑄(𝑖, 𝑡), any polynomial of the 𝑖 𝑟 𝑡 𝑠 𝑄(𝑖, 𝑡) 𝑢 𝒩 𝛼-𝑢 form can be obtained as linear combination of 𝑖-shifts and 𝑡-shifts.

What we are after are small-norm (remember Theorem 3.3) integral linear combinations of polynomials 𝑖𝑠 𝑟,𝑢 (𝑖𝐼, 𝑡𝑇 ) and 𝑡𝑠 𝑠,𝑢 (𝑖𝐼, 𝑡𝑇 ). We recall here that 𝐼 (resp. 𝑇 ) is an upper bound on |𝑖| (resp.

|𝑡|) mentioned in the latter theorem. To get them, we form a lattice spanned by the corresponding coefficients vectors that has sufficiently small vectors and we use the 𝐿𝐿𝐿-algorithm to find those small vectors.

As can be seen in, for instance, Theorem 3.6, their norm is connected to the volume (or the determinant) of the lattice. Hence we want to start, ideally, with the smallest possible volume since this property is conserved by a change of basis. Starting with a large volume lattice hampers the search of very short-norm vectors. This should incline us to limit the number of polynomials.

On the other hand we must provide the 𝐿𝐿𝐿-algorithm with a sufficient number of vectors to shuffle in order to compute efficiently short vectors This may require to append more polynomials at the expense of a volume expansion.

The balance is not easy to set and, as will be seen, there are no clear rules on how it can be done.

When 𝛼 and 𝑑 are set, all that is left to set, before starting the generation of the polynomials list, are the rules for 𝑟 and 𝑠. This is the point we are going to examine now.

When making it simple is not enough

The question of the initial basis production is present in the very early papers that describe the above sketched method for polynomial modular equations root finding. They start with construction rules that allow for a basis structure that facilitates the computations used in proofs.

But it soon emerges that these bases are not optimal. New construction rules are needed that produce better bases, with the consequence that proofs get more involved. We describe here two cases that especially matter to us:

• D. Bonneh and G. Durfee's approach, as they laid the foundations of the method;

• the 𝑆𝐿𝑍-algorithm approach, as it is, after all, the algorithm we implement here.

.

Boneh and Durfee's approach

In their first paper [START_REF] Boneh | Cryptanalysis of RSA with Private Key 𝑑 less than 𝑁 0.292[END_REF], where the extension of Coppersmith's method is performed for the bivariate case, D. Boneh and G. Durfee offer two different presentations of their initial basis. One, with a rather simple layout, is used to present the problem and prove preliminary results. A second one, much more convoluted, is used for improved results.

If we rephrase their description in our own notations, they initially propose the following rules:

• for all 𝑖𝑠 𝑟,𝑢 (𝑖𝐼, 𝑡𝑇 ) and 𝑡𝑠 𝑠,𝑢 (𝑖𝐼, 𝑡𝑇 ), 𝑢 is such that 0 𝑢 𝛼;

• for each 𝑢 we build 𝑖𝑠 𝑟,𝑢 (𝑖𝐼, 𝑇 𝑡), 𝑟 is such that 0 𝑟 𝛼 -𝑢;

• for each 𝑢 we build 𝑡𝑠 𝑠,𝑢 (𝑖𝐼, 𝑡𝑇 ), 𝑠 is such that 0 𝑟 𝑆, for some 𝑆 determined later;

For 𝛼 = 3 and 𝑆 = 1 the result is listed in Table 3.1.

We build the lattice matrix, from the coefficients of the polynomials as follows:

• each column corresponds to a monomial as it shows up in the polynomials;

𝒩 3 𝑖𝐼 𝑄(𝑖𝐼, 𝑡𝑇 ) 𝒩 2 𝑖𝐼 𝑄(𝑖𝐼, 𝑡𝑇 ) 2 𝒩 𝑡𝑇 𝑄(𝑖𝐼, 𝑡𝑇 ) 2 𝒩 𝑖𝐼 𝒩 3 𝑄(𝑖𝐼, 𝑡𝑇 ) 2 𝒩 𝑄(𝑖𝐼, 𝑡𝑇 ) 3 𝑡𝑇 𝑄(𝑖𝐼, 𝑡𝑇 ) 3 𝑄(𝑖𝐼, 𝑡𝑇 ) 𝒩 2 (𝑖𝐼) 3 𝒩 3 𝑡𝑇 𝒩 3 (𝑖𝐼) 2 𝒩 3 (𝑖𝐼) 2 𝑄(𝑖𝐼, 𝑡𝑇 ) 𝒩 2 𝑡𝑇 𝑄(𝑖𝐼, 𝑡𝑇 ) 𝒩 2
Table 3.1: List of polynomials obtained with D. Boneh and G. Durfee's first set of rules for 𝛼 = 3 and 𝑆 = 1.

• for each polynomial, a matrix row is formed with its coefficients each placed in the column corresponding to the monomial it refers to.

We give an example in Table 3.2, with the same polynomials as those listed in Table 3.1 and with an initial polynomial in the 𝑄(𝑖, 𝑡) = 𝑎𝑖 + 𝑖𝑡 -1 form, as it is in D. Boneh and G. Durfee's paper.

Here 𝑄(𝑖𝐼, 𝑡𝑇 ) is abbreviated to 𝑄, 𝑖𝐼 to 𝑖 and 𝑡𝑇 to 𝑡 in order to save space.

One nice feature of this polynomials set is that, when their coefficients are used to build the lattice matrix, the latter is lower triangular.

1 𝑖 𝑖𝑡 𝑖 2 𝑖 2 𝑡 𝑖 2 𝑡 2 𝑖 3 𝑖 3 𝑡 𝑖 3 𝑡 2 𝑖 3 𝑡 3 𝑡 𝑖𝑡 2 𝑖 2 𝑡 3 𝑖 3 𝑡 4 𝒩 3 𝒩 3 0 0 0 0 0 0 0 0 0 0 0 0 𝑖 𝒩 3 - 𝒩 3 𝐼 0 0 0 0 0 0 0 0 0 0 0 𝑄 𝒩 2 - - 𝒩 2 𝐼𝑇 0 0 0 0 0 0 0 0 0 0 𝑖 2 𝒩 3 - - - 𝒩 3 𝐼 2 0 0 0 0 0 0 0 0 0 𝑖 𝑄 𝒩 2 - - - - 𝒩 2 𝐼 2 𝑇 0 0 0 0 0 0 0 0 𝑄 2 𝒩 - - - - - 𝒩 𝐼 2 𝑇 2 0 0 0 0 0 0 0 𝑖 3 𝒩 3 - - - - - - 𝒩 3 𝐼 3 0 0 0 0 0 0 𝑖 2 𝑄 𝒩 2 - - - - - - - 𝒩 2 𝐼 3 𝑇 0 0 0 0 0 𝑖 𝑄 2 𝒩 - - - - - - - - 𝒩 𝐼 3 𝑇 2 0 0 0 0 𝑄 3 - - - - - - - - - 𝐼 3 𝑇 3 0 0 0 𝑡 𝒩 3 - - - - - - - - - - 𝒩 3 𝑇 0 0 𝑡 𝑄 𝒩 2 - - - - - - - - - - - 𝒩 2 𝐼𝑇 2 0 𝑡 𝑄 2 𝒩 - - - - - - - - - - - - 𝒩 𝐼 2 𝑇 3 𝑡 𝑄 3 - - - - - - - - - - - - - 𝐼 3 𝑇 4
Table 3.2: Matrix generated by polynomials of Table 3.1. Going from one polynomial to the next introduces only one new monomial. Hence the matrix is square and lower triangular. Computing its determinant is very easy: all we need to care about are the elements on the main diagonal.

The authors of [START_REF] Boneh | Cryptanalysis of RSA with Private Key 𝑑 less than 𝑁 0.292[END_REF] carry on a first analysis with this kind of basis to conclude that they achieve some level of effectiveness to solve their cryptography problem 26 Their target is to get the largest possible upper bound on one of the parameters of the problem, denoted by 𝛿. With this first approach they achieve 𝛿 < 0.284. But, at the same time, they notice two important facts :

• they will not be able to go any further with this kind of lattice: once 𝛿 > 0.284, the determinant of the matrix is always too large; 26 That is not relevant for us to discuss in detail here.

• their idea is to get rid of some of the rows whose element on the diagonal is an heavy contributor to determinant growth.

They go into some details in the technique they use for rows selection. In a nutshell, they add extra 𝑡-shifts (the value they come with for 𝑆 is larger than 1, as used to build the Table 3.2) and they eliminate those that yield a line vector that has an element on the diagonal larger that some threshold.

Of course, this breaks the comfortable squareness of the matrix and they devote a lot of time to the exposition of sophisticated techniques to bound (since it cannot be exactly computed anymore) the volume of the lattice spanned by their new rectangular matrix. But they eventually succeed in improving on their initial bound on 𝛿 to 0.292, which is more of an achievement than the small numerical difference might lead to think.

No extra details will be given here as they are not relevant to our problem. The reader interested in an in-depth study is invited to refer to [START_REF] Boneh | Cryptanalysis of RSA with Private Key 𝑑 less than 𝑁 0.292[END_REF].

SLZ and D. Stehlé own's approach

We discuss here the solutions proposed for initial basis construction found in the 2005 original paper of D. Stehlé, V. Lefèvre and P. Zimmermann [START_REF] Stehlé | Searching Worst Cases of a One-Variable Function Using Lattice Reduction[END_REF] and a later evolution, proposed by D. Stehlé all by himself [START_REF] Stehlé | On the randomness of bits generated by sufficiently smooth functions[END_REF], in 2006.

In their first work, the authors consider only what we could call, in D. Boneh and G. Durfy's parlance reworked in our own notations, i -shifts. This is due, in part, to the specific shape of their initial polynomial. In this case:

𝑄(𝑖, 𝑡) = 𝑃 (𝑖) + 𝑡, with 𝑃 (𝑖) ∈ Z[𝑖], of degree 𝑑 in 𝑖.
The considered i -shifts are those, for some constant 𝛼 ∈ N and 𝑑, the degree in 𝑖 of 𝑄(𝑖, 𝑡), such that 𝑖𝑠 𝑟,𝑢 (𝑖, 𝑡) = 𝑖 𝑟 𝑄(𝑖, 𝑡) 𝑢 𝒩 𝛼-𝑢 , where 0 𝑟 + 𝑑𝑢 𝑑𝛼.

With this setting, they obtain a square matrix of dimension (𝛼 + 1)(𝑑𝛼 + 2) 2 . Table 3.3 displays the matrix 𝑀 12,12 obtained for 𝑑 = 3 and 𝛼 = 2.

Later on, D. Stehlé found out that some of the polynomials (hence vectors in the lattice basis)

did not add much information and that they cluttered the operation of the 𝐿𝐿𝐿-algorithm. This rule yields (𝛼 + 1)(𝛼 + 2) 2 polynomials.

1 𝑖 𝑖 2 𝑖 3 𝑖 4 𝑖 5 𝑖 6 𝑡 𝑖𝑡 𝑖 2 𝑡 𝑖 3 𝑡 𝑡 2 𝒩 2 𝒩 2 0 0 0 0 0 0 0 0 0 0 0 𝑖 𝒩 2 - 𝒩 2 𝐼 0 0 0 0 0 0 0 0 0 0 𝑖 2 𝒩 2 - - 𝒩 2 𝐼 2 0 0 0 0 0 0 0 0 0 𝑖 3 𝒩 2 - - - 𝒩 2 𝐼 3 0 0 0 0 0 0 0 0 𝑖 4 𝒩 2 - - - - 𝒩 2 𝐼 4 0 0 0 0 0 0 0 𝑖 5 𝒩 2 - - - - - 𝒩 2 𝐼 5 0 0 0 0 0 0 𝑖 6 𝒩 2 - - - - - - 𝒩 2 𝐼 6 0 0 0 0 0 𝑄 𝒩 - - - - - - - 𝒩 𝑇 0 0 0 0 𝑖 𝑄 𝒩 - - - - - - - - 𝒩 𝐼𝑇 0 0 0 𝑖 2 𝑄 𝒩 - - - - - - - - - 𝒩 𝐼 2 𝑇 0 0 𝑖 3 𝑄 𝒩 - - - - - - - - - - 𝒩 𝐼 3 𝑇 0 𝑄 2 - - - - - - - - - - - 𝑇 2
Table 3.4 displays the matrix obtained with the same parameters as for Table 3.3: 𝛼 = 2 and the degree of 𝑄(𝑖, 𝑗) in 𝑖 is 3, to make a comparison possible with the previous building rule. As for the implementation presented here, we will stick to the rule presented by D. Stehlé in [START_REF] Stehlé | On the randomness of bits generated by sufficiently smooth functions[END_REF].

1 𝑖 𝑖 2 𝑖 3 𝑡 𝑖 4 𝑖𝑡 𝑖 5 𝑖 6 𝑖 2 𝑡 𝑖 3 𝑡 𝑡 2 𝒩 2 𝒩 2 0 0 0 0 0 0 0 0 0 0 0 𝑖 𝒩 2 - 𝒩 2 𝐼 0 0 0 0 0 0 0 0 0 0 𝑖 2 𝒩 2 - - 𝒩 2 𝐼 2 0 0 0 0 0 0 0 0 0 𝑄 𝒩 - - - 𝒩 𝐼 3 𝒩 𝑇 0 0 0 0 0 0 0 𝑖 𝑄 𝒩 - - - - - 𝒩 𝐼 4 𝒩 𝐼𝑇 0 0 0 0 0 𝑄 2 - - - - - - - 𝐼 5 𝐼 6 𝐼 2 𝑇 𝐼 3 𝑇 𝑇 2

Still journeying: from an interval to the next

Solving the Table Maker's Dilemma for a function and some F requires the exploration of all the fbinades of F. As it has been seen, the technique used here does not allow to make it in one shot.

Once the "special cases" removed (elements of the domain that map to non numeric values, those for which the function is not defined, etc.) what is left is split into small sub-domains. Dealing

with those may lead to extra splitting since the technique used here heavily relies on polynomial approximation. For our hardness-to-round investigations this requires high accuracy approximations that can only be obtained for relatively narrow intervals if the degree of the polynomial is to be kept at a reasonable level.

The general case

Running the algorithm is another source of splitting. Even if the width of an interval is in line with what the accuracy of the approximation polynomial allows for, problems may surface after the 𝐿𝐿𝐿reduction. The number of short-norm vectors may be insufficient or the polynomials derived from those may share a non trivial common factor. This is often overlooked in literature as an uncommon situation never happening in practice. Our own experience differs on that: it does happen. The only remedy to this situation is, again, extra splitting.

This kind of failure is very expensive because, as will be seen, reductions are time consuming and performing them in vain is hardly acceptable. But, as we have noted, for a given interval, it is difficult to come up with a "right" set of parameters. It does not only take thinking but also tedious, frustrating and time-consuming testing.

For a given function, precision and hardness-to-round, one would like to get the best possible return of investment on one's expensively gained parameters for a given interval. Ideally, they should apply equally well wherever another tested interval of the same relative width is located on the function domain.

At this point, the question is: is such a requirement only wishful thinking or is there any sound foundation to support it?

One problem comes from function approximation. After higher-level domain slicing into subdomains where the function is monotonic, these are in turn split into lower level subdomains that span, at most, one binade. Each of these is then mapped to the 0-fbinade ( 1, 2 ). More splitting is done for the images to fit into a single fbinade too. But this does not mean that the scaled functions we try to approximate are similar because they share the same domain. Scaling does not blur the differences in behavior of the function in different fbinades of its domain. This precisely what makes this scaling legitimate.

One must also take into account the following effect: equal interval lengths in the 0-fbinade, where different fbinades are mapped to, do not correspond to equal interval lengths in the original fbinades. Let us take an example. We can make a one-to-one map between the floating-point numbers in The same is true for the floating-point numbers in 4 8 , 5 8 (a subset of the -1-fbinade) but this time for a scaling up of 2.

We will not study the hardness-to-round of the exp(𝑥) function on the original sets 4 16 , 5 16 or 4 8 , 5 8 but instead will will study the hardness-to-round of the corresponding scaled functions (exp( 𝑥 4 ) for the first one and exp( 𝑥 2 ) for the second one) on their (same) mapping: 1, 5 4 .

In this mapping, the distance between the bounds is the same: 1 4 . But in the first case the actual distance "represented" by 1 4 is 1 16 and in the second case the distance is ] .

As a consequence, when it comes to approximation, the accuracy obtained with a polynomial of a given degree over a given interval width in the mapping may greatly vary according to the considered mapped portion of the domain.

Let us give actual data gathered in the case of the exp(𝑥) function. When we want to make a search for a hardness-to-round of 6𝑝 with precision 𝑝 = 113 (binary128), we need an approximation accuracy smaller than 3.99𝑒 -205. Let us suppose that we want an approximation polynomial of degree 17 and that we want each interval to contain 2 80 floating-point numbers, in order to explore the different binades at a steady pace. Let us examine the situation when the studied interval is astride the center of the binade 28 .

Data is presented in Table 3 We can see that the approximation accuracy of a degree-17 polynomial is sufficient for binades -3 and -2. We can even say that the chosen degree is exaggeratedly conservative for binade -3.

But for the next binades, this accuracy is insufficient.

One can get an intuition as to the reasons for this difference by examining the plots of two extremal cases of scaled functions as presented in Figure 3 • pick a larger degree, if we really insist on having even intervals;

• We have seen that parameters have to change from one binade to another. But can we have some relief when we stay inside a single binade? There is no general answer to this question but a response can be given in the particular case of the exp(𝑥) function.

We have said that we used Taylor polynomials of some degree 𝑑 at point 𝑎, the center of the interval we want to explore for hard-to-round cases for function 𝑓 (𝑥). The general form of the polynomial is:

𝑝 𝑑,𝑎 (𝑥) = 𝑓 (𝑎) + 𝑓 ′ (𝑎)(𝑥 -𝑎) + 𝑓 ′′ (𝑎) 2! (𝑥 -𝑎) 2 + . . . + 𝑓 (𝑑) (𝑎) 𝑑! (𝑥 -𝑎) 𝑑 .
If we specialize it for the exponential function case, using the property that exp (𝑑) (𝑥) = exp(𝑥) for 𝑑 ∈ N * , we have:

𝑝 𝑑,𝑎 (𝑥) = exp(𝑎) + exp(𝑎)(𝑥 -𝑎) + exp(𝑎) 2! (𝑥 -𝑎) 2 + . . . + exp(𝑎) 𝑑! (𝑥 -𝑎) 𝑑 .
We can rewrite this expression as 𝑝 𝑑,𝑎 (𝑥) = exp(𝑎)

( 1 + (𝑥 -𝑎) + (𝑥 -𝑎) 2 2! + . . . + (𝑥 -𝑎) 𝑑 𝑑! ) .
The Taylor polynomial at some other point 𝑏 such that 𝑏 > 𝑎 (what comes next is also true in the trivial situation where 𝑏 = 𝑎 but is of no interest here).

𝑝 𝑑,𝑏 (𝑥) = exp(𝑏)

( 1 + (𝑥 -𝑏) + (𝑥 -𝑏) 2 2! + . . . + (𝑥 -𝑏) 𝑑 𝑑! ) .
In both polynomials, the expressions (𝑥 -𝑎) and (𝑥 -𝑏) actually mean "distance to the center of the interval". For any pair of points 𝑥 𝑎 and 𝑥 𝑏 such that (𝑥 𝑎 -𝑎) = (𝑥 𝑏 -𝑏) we can write 𝑝 𝑑,𝑏 (𝑥 𝑏 ) = exp(𝑏)

( 1 + (𝑥 𝑏 -𝑏) + (𝑥 𝑏 -𝑏) 2 2! + . . . + (𝑥 𝑏 -𝑏) 𝑑 𝑑! ) , 𝑝 𝑑,𝑏 (𝑥 𝑏 ) = exp(𝑏) ( 1 + (𝑥 𝑎 -𝑎) + (𝑥 𝑎 -𝑎) 2 2! + . . . + (𝑥 𝑎 -𝑎) 𝑑 𝑑! ) ,
𝑝 𝑑,𝑏 (𝑥 𝑏 ) = exp(𝑏 -𝑎) 𝑝 𝑑,𝑎 (𝑥 𝑎 ).

For the actual functions, we build our lattice basis for the interval centered at 𝑎, a change of variable has been made: 𝑥 ↦ -→ 𝑦 = 𝑥 -𝑎. The actual polynomial is thus

𝑃 𝑎 (𝑦) = exp(𝑎) ( 1 + 𝑦 + 𝑦 2 2 + . . . + 𝑦 𝑑 𝑑! ) .
For a 𝑦 point located in the interval centered on 𝑏 we can compute its image either with 𝑃 𝑎 or 𝑃 𝑏 if we use the following equality 𝑃 𝑏 (𝑦) = exp(𝑏 -𝑎) 𝑃 𝑎 (𝑦).

We detailed above the transformations we made on these polynomials in order to obtain all integer coefficients and arguments. But these transformations amounted to scalings: they do not change the 𝑃 𝑏 /𝑃 𝑎 ratio. If the only thing we are interested in is the ratio 𝑃 𝑏 (𝑦) 𝑃 𝑎 (𝑦) we can leave the polynomials under this form even when we change the real 𝑦 variable to the 𝑖 integer variable as was described at length in §3.3.5, p. 163. We can still write 𝑃 𝑏 (𝑖) = exp(𝑏 -𝑎) 𝑃 𝑎 (𝑖).

As we remember, we introduced another integer variable 𝑡 to form polynomial 𝑄(𝑖, 𝑡) = 𝑃 (𝑖) -𝑡.

If we introduce this variable to form polynomials derived from the previous ones, we can write

𝑄 𝑎 (𝑖, 𝑡) = 𝑃 𝑎 (𝑖) -𝑡 = exp(𝑎) ( 1 + 𝑖 + 𝑖 2 2 + . . . + 𝑖 𝑑 𝑑! ) - exp(𝑎) 𝑡 exp(𝑎) = exp(𝑎) ( 1 + 𝑖 + 𝑖 2 2 + . . . + 𝑖 𝑑 𝑑! - 𝑡 exp(𝑎) ) .
Let us now examine how we build our lattice basis or, equivalently, our lattice matrix. Our notation will be plagued with abuses of language. But what we are about to write remains correct as long as our interest stays focused on ratios rather than on exact values.

To be more clear, let us use an example. For that end we will reuse the lattice matrix presented in §3.5.2.3, p. 182. Let us examine first a slightly different presentation of the matrix built for the interval centered at 𝑎 in Table 3.6.

We have extracted to a new column, outside and to the left of the matrix table, the exp(𝑎) 𝑘 𝑘 ∈ {1, 2} factors that are common to all the term of the corresponding row. We can notice that exp(𝑎) is risen to the same power as the one of the polynomial 𝑄(𝑖, 𝑡). Let us call this matrix 𝑀 𝑎 .

We put the label in the uppermost/leftmost table cell.

𝑀 𝑎 1 𝑖 𝑖 2 𝑖 3 𝑡 𝑖 4 𝑖𝑡 𝑖 5 𝑖 6 𝑖 2 𝑡 𝑖 3 𝑡 𝑡 2 𝒩 2 𝒩 2 0 0 0 0 0 0 0 0 0 0 0 𝑖 𝒩 2 - 𝒩 2 𝐼 0 0 0 0 0 0 0 0 0 0 𝑖 2 𝒩 2 - - 𝒩 2 𝐼 2 0 0 0 0 0 0 0 0 0 exp(𝑎) 𝑄 𝒩 - - - 𝒩 𝐼 3 𝒩 𝑇 0 0 0 0 0 0 0 exp(𝑎) 𝑖 𝑄 𝒩 - - - - - 𝒩 𝐼 4 𝒩 𝐼𝑇 0 0 0 0 0 exp(𝑎) 2 𝑄 2 - - - - - - - 𝐼 5 𝐼 6 𝐼 2 𝑇 𝐼 3 𝑇 𝑇 2
Table 3.6: Matrix generated by polynomials for the exp function at point 𝑎.

We can repeat the same process for the lattice matrix we built for the interval centered on 𝑏. We present it in Table 3.6

𝑀 𝑏 1 𝑖 𝑖 2 𝑖 3 𝑡 𝑖 4 𝑖𝑡 𝑖 5 𝑖 6 𝑖 2 𝑡 𝑖 3 𝑡 𝑡 2 𝒩 2 𝒩 2 0 0 0 0 0 0 0 0 0 0 0 𝑖 𝒩 2 - 𝒩 2 𝐼 0 0 0 0 0 0 0 0 0 0 𝑖 2 𝒩 2 - - 𝒩 2 𝐼 2 0 0 0 0 0 0 0 0 0 exp(𝑏) 𝑄 𝒩 - - - 𝒩 𝐼 3 𝒩 𝑇 0 0 0 0 0 0 0 exp(𝑏) 𝑖 𝑄 𝒩 - - - - - 𝒩 𝐼 4 𝒩 𝐼𝑇 0 0 0 0 0 exp(𝑏) 2 𝑄 2 - - - - - - - 𝐼 5 𝐼 6 𝐼 2 𝑇 𝐼 3 𝑇 𝑇 2
Table 3.7: Matrix generated by polynomials for the exp function at point 𝑏.

But, if we remember well, rows, in both matrices, correspond to polynomials and using the relationship between the polynomials we established above, we can rewrite 𝑀 𝑏 as a function of 𝑀 𝑎 .

The result is displayed in in Table 3.8

𝑀 𝑎 1 𝑖 𝑖 2 𝑖 3 𝑡 𝑖 4 𝑖𝑡 𝑖 5 𝑖 6 𝑖 2 𝑡 𝑖 𝑡 𝑡 2 𝒩 2 𝒩 2 0 0 0 0 0 0 0 0 0 0 𝑖 𝒩 2 - 𝒩 2 𝐼 0 0 0 0 0 0 0 0 0 𝑖 2 𝒩 2 - - 𝒩 2 𝐼 2 0 0 0 0 0 0 0 0 exp(𝑏 -𝑎) exp(𝑎) 𝑄 𝒩 - - - 𝒩 𝐼 3 𝒩 𝑇 0 0 0 0 0 0 exp(𝑏 -𝑎) exp(𝑎) 𝑖 𝑄 𝒩 - - - - - 𝒩 𝐼 4 𝒩 𝐼𝑇 0 0 0 0 exp(𝑏 -𝑎) 2 exp(𝑎) 2 𝑄 2 - - - - - - - 𝐼 5 𝐼 6 𝐼 2 𝑇 𝐼 𝑇 𝑇 2
Table 3.8: Matrix generated by polynomials for the exp function at point 𝑏 as derived from that at point 𝑎.

Notice that we start here from the matrix built for the interval centered at 𝑎 to form the one for the interval centered at 𝑏. Our interest turns now to the ratio between the volumes of the lattices generated by the two matrices 𝑀 𝑎 and 𝑀 𝑏 . The matrices are quite similar 29 . They differ in that, in 𝑀 𝑏 , some lines of 𝑀 𝑎 , are multiplied by exp(𝑏 -𝑎) raised to a suitable power.

We recall that, if we denote by 𝐿 𝑎 the lattice generated by the 𝑀 𝑎 matrix, the volume of the lattice is given by vol (𝐿 𝑎 ) = √ det (𝑀 𝑎 × 𝑀 𝑎 ).

where det (𝑀 𝑎 × 𝑀 𝑎 ) is the Gram determinant 30 .

We can represent the above matrices relationship by the following matrix expression

⎡ ⎢ ⎢ ⎢ ⎢ ⎢ ⎢ ⎢ ⎢ ⎣ 𝑀 𝑏 ⎤ ⎥ ⎥ ⎥ ⎥ ⎥ ⎥ ⎥ ⎥ ⎦ = ⎡ ⎢ ⎢ ⎢ ⎢ ⎢ ⎢ ⎢ ⎢ ⎢ ⎢ ⎢ ⎢ ⎣ 1 0 0 0 0 0 0 1 0 0 0 0 0 0 1 0 0 0 0 0 0 exp(𝑏 -𝑎) 0 0 0 0 0 0 exp(𝑏 -𝑎) 0 0 0 0 0 0 exp(𝑏 -𝑎) 2 ⎤ ⎥ ⎥ ⎥ ⎥ ⎥ ⎥ ⎥ ⎥ ⎥ ⎥ ⎥ ⎥ ⎦ × ⎡ ⎢ ⎢ ⎢ ⎢ ⎢ ⎢ ⎢ ⎢ ⎣ 𝑀 𝑎 ⎤ ⎥ ⎥ ⎥ ⎥ ⎥ ⎥ ⎥ ⎥ ⎦ .
Notice that, in the above expression, 𝑀 𝑎 and 𝑀 𝑏 look squarer than they should (they actually are outstretched rectangular) while the term multiplying 𝑀 𝑎 is actually a diagonal (hence square) matrix. Let us call this matrix Λ.

When it comes to the computation of the volume of the generated lattices, which involves transposed matrices, we can notice that

𝑀 𝑏 = 𝑀 𝑎 Λ.
If we call vol(𝐿 𝑎 ) (resp. vol(𝐿 𝑏 )) the volume of the lattice generated by 𝑀 𝑎 (resp. 𝑀 𝑏 ), we have vol

(𝐿 𝑏 ) = √ det (𝑀 𝑏 × 𝑀 𝑏 ), vol (𝐿 𝑏 ) = √ det (Λ × 𝑀 𝑎 × 𝑀 𝑎 × Λ), vol (𝐿 𝑏 ) = √ det (Λ) × det (Λ) √ det (𝑀 𝑎 × 𝑀 𝑎 ).
Since Λ is a diagonal matrix, we have

det (Λ) = exp(𝑏 -𝑎) exp(𝑏 -𝑎) exp(𝑏 -𝑎) 2 = exp(𝑏 -𝑎) 4 .
Consequently vol (𝐿 𝑏 ) = exp(𝑏 -𝑎) 4 × vol (𝐿 𝑎 ) . This is for our example. But what is the factor in the general case?

30 Some care is needed with volume definition as read in literature. In some instances it is presented as equal to the determinant. These cases, often implicitly, refer to square matrices were the absolute value of the "classical" determinant is interpreted as the volume. With rectangular matrices we use Gram's determinant, hence the square root.

We recall the building rule 𝑖𝑠 𝑟,𝑢 (𝑖, 𝑡) = 𝑖 𝑟 𝑄(𝑖, 𝑡) 𝑢 𝒩 𝛼-𝑢 , where 0 𝑟 + 𝑢 𝛼.

The factors exp(𝑏 -𝑎) appear for row corresponding to 𝑢 1. For a given 𝛼 and 𝑢, the number of factors exp(𝑏 -𝑎) 𝑢 will be 𝛼 + 1 -𝑢 . Their total contribution to the volume augmentation will be exp(𝑏 -𝑎) 𝑢 (𝛼+1-𝑢) .

Their total contribution is

exp(𝑏 -𝑎) 𝛼 ∑ 𝑢=0 𝑢 (𝛼+1-𝑢)
.

Elementary calculations show that

𝛼 ∑ 𝑢=0 𝑢 (𝛼 + 1 -𝑢) = 𝛼 (𝛼 + 1) (𝛼 + 2) 6 .
Hence, when it comes to lattice volumes vol(𝐿 𝑏 ) = exp(𝑏 -𝑎)

𝛼 (𝛼+1) (𝛼+2) 6 vol(𝐿 𝑎 ).
But what eventually interests us are the relationships between the lengths of the short-norm vectors computed at 𝑎 and at 𝑏. We use here a different formula than that introduced in §3.4.5, p. 172 for the bound on the first vector on a 𝐿𝐿𝐿-reduced basis. It is less technical (the references to the parameters used to configure the 𝐿𝐿𝐿-algorithm are removed), more legible and sufficient for our present needs:

||𝑏 1 || 2 𝑤 2 vol(𝐿) 1 𝑟 ,
where 𝑤 is the number of monomials produced by all the shifts and 𝑟 is the dimension (the number of vectors of the basis) of the lattice. In our case, we have:

||𝑏 1 || 2 𝑤 2 vol(𝐿) 2 (𝛼+1)(𝛼+2) .
If we want to compare now the bounds on the first vector of the reduced basis computed at point 𝑎 and at point 𝑏, we have

||𝑏 1 @𝑏 || 2 𝑤 2 vol(𝐿 𝑏 ) 2 (𝛼+1)(𝛼+2) = 2 𝑤 2 ( exp(𝑏 -𝑎) 𝛼 (𝛼+1) (𝛼+2) 6 vol (𝐿 𝑎 ) ) 2 (𝛼+1)(𝛼+2) .
From which we have

||𝑏 1 @𝑏 || 2 𝑤 2 vol(𝐿 𝑏 ) 2 (𝛼+1)(𝛼+2) = 2 𝑤 2 exp(𝑏 -𝑎) 2𝛼 (𝛼+1) (𝛼+2) 6(𝛼+1)(𝛼+2) vol (𝐿 𝑎 ) 2 (𝛼+1)(𝛼+2) .
And, eventually

||𝑏 1 @𝑏 || 2 𝑤 2 vol(𝐿 𝑏 ) 2 (𝛼+1)(𝛼+2) = 2 𝑤 2 exp ( 𝛼 3 (𝑏 -𝑎) ) vol (𝐿 𝑎 ) 2 (𝛼+1)(𝛼+2) .
If we examine now what the values of 𝑎 and 𝑏 can be, we remind that we scale everything to the 0-fbinade whose bounds are 1 and 2 -2 -𝑝+1 . Hence, 𝑏 -𝑎 < 1. For the 𝛼 = 6 case, a typical value when one searches for a hardness-to-round of 6𝑝, exp(1) 2 ≈ 7.39.

This is the ratio between the bounds on the shortest-norm vectors of the 𝐿𝐿𝐿-reduced basis computed at points 𝑎 = 1 and 𝑏 = 2 -2 -𝑝+1 . If parameters are set in order to get an efficient operation at the upper end of a binade, one is guaranteed that these settings will work all the way down to its lower end.

Using the same parameter values for several binades is more problematic. The ratio computed above increases by 7.39 per binade. If the settings adopted for the worst case are used all along a large interval, it will very quickly happen that they are far from optimal for the lowest values. As we have seen, other considerations, as approximation error, come into play when exploring far apart intervals.

As a final note, the above analysis only applies, as is, to the exp(𝑥) function.

The Implementation

In this section, we will give a closer look to the implementation itself. The transition from paper and pencil algorithms to an actual running code should never be overlooked. It is especially true here, where practical goals matter so much to us. In any case, and regardless of the efforts made by the developer to stick with the specification, the practical conditions of the implementation always introduce twists of their own that have an impact on the behavior of the code. One is not always able to report them completely. At some point, the tools that are used for the implementation are black boxes that are opaque to the developer himself. This is unavoidable and even, in a way, desirable.

Schnorr by himself, and heuristic [94][95]) and L 2 [START_REF] Nguyen | Floating-Point LLL Revisited[END_REF] algorithms. Developers of implementations feel compelled to offer several options to their users because of the possible execution time, problem complexity and results safety trade-offs.

If we come back to the fpLLL library, several options are offered for reduction. Beyond those that control its quality (at the expense of more computation time), 1/4 < 𝛿 1 and 1/2 < 𝜂 < √ 𝛿, aforementioned in the LLL section, the two main controls are on method and floatType. A precision argument can be used when computation are to be performed with MPFR floating-point numbers.

The following is excerpted from fpLLL documentation and gives some details.

First, about the available methods: The target and ambition of the project can be read from SageMath's FAQ as:

The stated mission of SageMath is to be viable free open source alternative to Magma, Maple, Mathematica, and Matlab.

We can augment this description with a few words about the features we particularly relied upon in this work.

First of all, we will be manipulating multivariate polynomials. Since SageMath has a more than decent support for these objects, there was no point in trying to develop a new library from scratch.

Using excellent embedded libraries as Maxima was a wiser choice. And that's what we actually do through SageMath.

The second important element is the ability to use SageMath to integrate scattered pieces of code. This is one of its key features since, for lots of its operations on many different mathematical objects, it relies on best-of-breed open source specialized libraries. At its inception, SageMath specific code was mostly written to plug up the holes between existing libraries and glue them together.

Nowadays many new developments take place directly in Python/SageMath. This leads to a third element which is the ability to squeeze different performance levels from a given SageMath code. Initially, code written in "pure" SageMath runs at the speed allowed by the underlying Python interpreter31 . While it is not particularly slouch, it is still possible to improve upon it in terms of performance. A possibility is to have the initial code transformed into C and compiled with the help of Cython [START_REF]Cython: C-Extensions for Python[END_REF]. This code executes more efficiently than native Python code.

Most of SageMath's core is nowadays written in Cython.

Another interesting feature of the use of Cython for SageMath performance improvement is that the shift is not an all-or-nothing move. Initially, Cython code is almost Python code translated to C. One can obtain an increasing performance boost by enlightening the original Python code with annotations that provide information about the manipulated objects. The more details are given, the more the compiler has room for improvement. But, at the same time, the further it gets from the original Python/SageMath code. The process can be incrementally performed: when time allows, or when performance bottlenecks urge, a higher level of code improvement can be reached with more work on the already running code. Tiny bits of our bindings of Sollya were written in Cython, not so much for performance improvement but rather to access the underlying C language structures of some arbitrary precision numbers from MPFR, MPI, and GMP libraries.

impact on complexity.

It happens that when we compute our approximation polynomial 𝑃 (𝑥) of function 𝑔(𝑥) output coefficients span all the available bits in working precision of the tool. Indeed, it tries very hard to give the best possible approximation and has no particular reason to optimize coefficients size. It turns out, especially for high degree polynomials, that all this precision in coefficients is superfluous and that shorter ones may yield very decent approximants.

Of course, reduction operated at this early stage may not fully withstand all the transformations the initial polynomial will suffer (from floating-point numbers to integers and the incorporation of possibly large parameters, as the bounds on 𝑖 and 𝑡 or 𝒩 ). Nevertheless, as will be seen from our experiments, the result is worth the effort.

The question is how can it be done in an efficient and yet safe way?

The main intuition is that rounding should be different among coefficients: it should prune more bits from the coefficients of the higher degree monomials that from the low degree ones.

Indeed, the intervals we work on always have a radius smaller than 1 (remember we map any f-binade into the 0-fbinade = 1, 2 ). As we move along to higher degree monomials, the powers of the argument get smaller and smaller. Their multiplication with the coefficients yields products whose least significant bits bring in only a very small contribution to the final value of the evaluation of the polynomial. The same does not apply, for instance, to the constant coefficient. But even for this one, rounding may still be desirable since it has possibly been computed at a very high precision, more than is actually needed for the expected accuracy of the approximation.

We first approximate function 𝑔(𝑥) with polynomial 𝑃 (𝑦) (with floating-point coefficients we will view here as rational numbers) of degree 𝑑 over the interval [𝑎, 𝑏], with an accuracy of 2 -𝑚-1 . We must remember here that 𝑃 (𝑦) is a Taylor polynomial that approximates 𝑔(𝑥) with an argument 𝑦 = 𝑥 -𝑥 0 , where 𝑥 0 is the center of interval [𝑎, 𝑏].

We then have:

|𝑔(𝑥) -𝑃 (𝑦)| [𝑎,𝑏] 1 2 𝑚+1 , with 𝑃 (𝑦) = 𝑝 0 + 𝑝 1 𝑦 + . . . + 𝑝 𝑑 𝑦 𝑑
and where 𝑚 is the hardness-to-round we want to check.

In order to work with smaller coefficients, we want to replace 𝑃 (𝑦) by some polynomial 𝑅(𝑦) ("R" stands for rounded here) of the same degree 𝑑, derived from 𝑃 (𝑥), such that:

|𝑔(𝑥) -𝑅(𝑦)| [𝑎,𝑏] 1 2 𝑚+1 , with 𝑅(𝑦) = 𝑟 0 + 𝑟 1 𝑦 + . . . + 𝑟 𝑑 𝑦 𝑑 .
The succession of events is the following:

1. 𝑃 (𝑦) is derived from 𝑔(𝑥);

|𝑔(𝑥) -𝑃 (𝑦)| < 1 2 𝑚+2 , |𝑃 (𝑦) -𝑅(𝑦)| 1 2 𝑚+2 .
Notice that if polynomial rounding is to be used, we must start with a 𝑃 (𝑦) polynomial that is a closer approximation to function 𝑔(𝑥) than we initially anticipated.

In order to derive polynomial 𝑅(𝑦) from 𝑃 (𝑦) we are writing our polynomials a bit differently,

⃒ ⃒ ⃒ ⃒ ⃒ 𝑑 ∑ 𝑘=0 𝑝 𝑘 𝑦 𝑘 - 𝑑 ∑ 𝑘=0 𝑟 𝑘 𝑦 𝑘 ⃒ ⃒ ⃒ ⃒ ⃒ 1 2 𝑚+2
We write the coefficients of polynomial 𝑅(𝑦) as rational numbers with a denominator that is a power of 2:

⃒ ⃒ ⃒ ⃒ ⃒ 𝑑 ∑ 𝑘=0 𝑝 𝑘 𝑦 𝑘 - 𝑑 ∑ 𝑘=0 𝑅 𝑘 𝑦 𝑘 2 𝑚 𝑘 ⃒ ⃒ ⃒ ⃒ ⃒ 1 2 𝑚+2 , with 𝑅 𝑘 ∈ Z and 𝑚 𝑘 ∈ N, ⃒ ⃒ ⃒ ⃒ ⃒ 𝑑 ∑ 𝑘=0 ( 𝑝 𝑘 - 𝑅 𝑘 2 𝑚 𝑘 ) 𝑦 𝑘 ⃒ ⃒ ⃒ ⃒ ⃒ 1 2 𝑚+2 , with 𝑅 𝑘 ∈ Z and 𝑚 𝑘 ∈ N.
What we want now is to compute the 𝑚 𝑘 's. Once those set, we will be able to compute the 𝑅 𝑘 's from the 𝑝 𝑘 's.

At this point if we can find a sharp bound on 𝑦, we can simplify a bit the problem. It is time to use the fact that both 𝑃 (𝑦) and 𝑅(𝑦) are polynomials on the same variable whose domain is centered on zero: 𝑦 ∈ [-𝜌, 𝜌], where 𝜌 is the radius of interval [𝑎, 𝑏]. Put in another way: |𝑦| 𝜌.

We can then write

⃒ ⃒ ⃒ ⃒ ⃒ 𝑑 ∑ 𝑘=0 ( 𝑝 𝑘 - 𝑅 𝑘 2 𝑚 𝑘 ) 𝑦 𝑘 ⃒ ⃒ ⃒ ⃒ ⃒ ⃒ ⃒ ⃒ ⃒ ⃒ 𝑑 ∑ 𝑘=0 ( 𝑝 𝑘 - 𝑅 𝑘 2 𝑚 𝑘 ) 𝜌 𝑘 ⃒ ⃒ ⃒ ⃒ ⃒ .
If we can bound our new sum with 1 2 𝑚+2 , the initial one will be bounded as well. That is what we do in the following lemma. Lemma 3.9. If, ∀ 𝑘 ∈ 0, . . . , 𝑑, we set

𝑅 𝑘 = ⌊2 𝑚 𝑘 𝑝 𝑘 ⌉ and 𝑚 𝑘 = ⌊ log 2 ( 2 𝑚+2 (𝑑 + 1) 𝜌 -𝑘 )⌋ then ⃒ ⃒ ⃒ ⃒ 𝑑 ∑ 𝑘=0 ( 𝑝 𝑘 - 𝑅 𝑘 2 𝑚 𝑘 ) 𝜌 𝑘 ⃒ ⃒ ⃒ ⃒ 1 2 𝑚+2 , with 𝑅 𝑘 ∈ Z and 𝑚 𝑘 ∈ N.
Proof. Let us consider each term of the above sum, using the value we have set the 𝑅 𝑘 's to in our hypothesis. We first have

⃒ ⃒ ⃒ ⃒ 𝑝 𝑘 - 𝑅 𝑘 2 𝑚 𝑘 ⃒ ⃒ ⃒ ⃒ = ⃒ ⃒ ⃒ ⃒ 𝑝 𝑘 - ⌊2 𝑚 𝑘 𝑝 𝑘 ⌉ 2 𝑚 𝑘 ⃒ ⃒ ⃒ ⃒ = ⃒ ⃒ ⃒ ⃒ 2 𝑚 𝑘 𝑝 𝑘 2 𝑚 𝑘 - ⌊2 𝑚 𝑘 𝑝 𝑘 ⌉ 2 𝑚 𝑘 ⃒ ⃒ ⃒ ⃒ = ⃒ ⃒ ⃒ ⃒ 2 𝑚 𝑘 𝑝 𝑘 -⌊2 𝑚 𝑘 𝑝 𝑘 ⌉ 2 𝑚 𝑘 ⃒ ⃒ ⃒ ⃒ 1 2 𝑚 𝑘 +1 .
(3.12)

Considering the assignment of the 𝑚 𝑘 in our hypothesis, we also have

1 2 𝑚 𝑘 = 1 2 ⎢ ⎢ ⎢ ⎣ log 2 ⎛ ⎝ 2 𝑚+2 (𝑑 + 1) 𝜌 -𝑘 ⎞ ⎠ ⎥ ⎥ ⎥ ⎦ 1 2 log 2 ⎛ ⎝ 2 𝑚+2 (𝑑 + 1) 𝜌 -𝑘 ⎞ ⎠ 1 2 ⎡ ⎢ ⎢ ⎢ log 2 ⎛ ⎝ 2 𝑚+2 (𝑑 + 1) 𝜌 -𝑘 ⎞ ⎠ ⎤ ⎥ ⎥ ⎥ 1 2 𝑚 𝑘 +1 .
From here we can deduce

1 2 log 2 ⎛ ⎝ 2 𝑚+2 (𝑑 + 1) 𝜌 -𝑘 ⎞ ⎠ = 1 2 𝑚+2 (𝑑 + 1) 𝜌 -𝑘 = 𝜌 -𝑘 2 𝑚+2 (𝑑 + 1) 1 2 𝑚 𝑘 +1 .
(3.13)

Combining both (3.12) and 3.13, we then have

⃒ ⃒ ⃒ ⃒ 𝑝 𝑘 - 𝑅 𝑘 2 𝑚 𝑘 ⃒ ⃒ ⃒ ⃒ 𝜌 -𝑘 2 𝑚+2 (𝑑 + 1)
and

⃒ ⃒ ⃒ ⃒ 𝑝 𝑘 - 𝑅 𝑘 2 𝑚 𝑘 ⃒ ⃒ ⃒ ⃒ 𝜌 𝑘 1 2 𝑚+2 (𝑑 + 1) . (3.14)
Since 𝜌 > 0, we remark that

⃒ ⃒ ⃒ ⃒ 𝑅 𝑘 2 𝑚 𝑘 ⃒ ⃒ ⃒ ⃒ 𝜌 𝑘 = ⃒ ⃒ ⃒ ⃒ 𝑅 𝑘 2 𝑚 𝑘 𝜌 𝑘 ⃒ ⃒ ⃒ ⃒ .
If we return now to our sums, we can notice the 𝑑 + 1 factor in the denominator of (3.14). We then

have ⃒ ⃒ ⃒ ⃒ ⃒ 𝑑 ∑ 𝑘=0 ( 𝑝 𝑘 - 𝑅 𝑘 2 𝑚 𝑘 ) 𝜌 𝑘 ⃒ ⃒ ⃒ ⃒ ⃒ < 1 2 𝑚+2 .
Our assignment of the 𝑚 𝑘 's in the hypothesis of Lemma 3.9 finally amounts to an even split of the 1 2 𝑚+2 bound among all the terms of the polynomial. For a given approximation interval, the different powers 𝜌 𝑘 throttle the corresponding values for the 𝑚 𝑘 's. In general, since 𝜌 < 1, the value of the 𝑚 𝑘 will shrink with as 𝑘 grows larger. Some tests confirm the intuition that polynomial coefficients "shaving" can improve execution time.

A test result

We performed our test with the following parameters, typical of our usage of the algorithm:

• function: exp(𝑥);

• interval: [1.5 -2 -35 , 1.5 + 2 -35 ];

• polynomial approximation degree: 17;

• 𝛼 : 6;

• precision: 113 (binary128).

The run time reduction of polynomial "shaving", put parallel with the effect it has on data size reduction, measured according to different metrics, is presented in Table 3 As can be seen, the impact of polynomial coefficients rounding on execution time largely exceeds that it has on raw data size.

Starting from 1024, the final bit size of each polynomial coefficient is represented in Figure 3-10.

As remarked above, all the coefficients could benefit from this optimization, including the constant term. Incidentally, due to a programming error of Equation 3.12, factor 𝑑 + 1 was replaced by 𝑘.

This led to an even better reduction, confirming that our assignement of the 𝑚 𝑘 's in Lemma 3.9 was somehow pessimistic. Further testing showed that this extra-aggressive reduction sometimes failed (the approximation accuracy was not preserved to an acceptable level).

Nevertheless, as it is worth spending some time in data size reduction, we use a two steps coefficients rounding:

• we first apply the very aggressive formula, and check the approximation accuracy;

• if it fails, we fall back to the proved one.

Touring the implementation

What we mean to do here is to give a taste of what the implementation looks like through a small example. As we go, we will provide some information about technical details of interest and about some algorithmic aspects as well.

In this example we deal with the exp function. It has been used all around this work to develop the implementation and perform the tests that will be reported later. The parameters used in our examples make it a bit "toyish" (even if these parameters correspond more or less to those used in the "fast phase" of a two-phase function implementation, see [START_REF] Lauter | Arrondi correct de fonctions mathématiques[END_REF]). Our main justification is that we had to keep data size moderate in order to be able to legibly display them on paper.

In this tour, we will display accuracy check of the polynomial approximation after each of the many conversions we perform along the way. These checks do not happen in real code since we have thoroughly tested it in this respect and have taken into account the fact that many of the transformations are trivial. Checks in actual code do not go beyond polynomial rounding. They are presented here to support our above claim of accuracy conservation.

Initial interval splitting

There is nothing to do here, since :

• function exp(𝑥) is increasing in the [𝑙𝑏, 𝑢𝑏] interval;

• bounds 𝑙𝑏 and 𝑢𝑏 belong to the same binade (0-binade);

• both bound images belong to the same binade (2-binade).

Scaling

In order to map the images in the 0-binade, we use the following scaled function:

𝑔 : 𝑥 ↦ → exp(𝑖) 4 (3.15)
instead of 𝑓 (𝑥).

Taylor expansion computation

Taylor expansion is computed with the Sollya taylorform function in absolute error mode. We picked taylorform instead of the quickest taylor function because the former also returns bounds on the error term. Testing the highest absolute value for the bound guarantees the accuracy of the approximation.

Taylor expansion

𝑃 𝑠𝑜 denotes the approximation polynomial output by Sollya.

Taylor expansion related interval splitting

As mentioned, Sollya taylorform function also returns an interval for the approximation error of 𝑔(𝑥) by 𝑃 𝑠𝑜 . In this case :

[-3.4298178283361392775516921232804601094619229067180277569057𝑒 -41, 3.429817828336236742914815206710768736364658335326293820682𝑒 -41].
To avoid taking a risk, we use the upper bound of the interval (more precisely the maximum of the absolute values of the bounds) to check that the approximation matches our target accuracy

𝜖 𝑃𝑠𝑜 ≈ 3.429817828336236742914815206710768736364658335326293820682𝑒 -41.
For the given accuracy (5.4210108624275221700372640𝑒 -20) and the given degree (2), one polynomial is sufficient to approximate 𝑔(𝑥) with the expected accuracy over all the interval [𝑙𝑏, 𝑢𝑏]. No further splitting is needed.

We must notice that one can not use the same inputs for the 𝑔(𝑥) function and the 𝑃 𝑠𝑜 polynomial.

For the truncated Taylor polynomial, argument 0 represents the center of the interval [𝑙𝑏, 𝑢𝑏]. When one wants to check 𝑃 𝑠𝑜 against function 𝑔(𝑥) she must make a variable change:

𝑥 (for 𝑔(𝑥)) ↦ → 𝑦 = 𝑥 -𝑖𝑐 (for 𝑃 (𝑦))
At this point, we can also notice that the approximation error of polynomial 𝑃 𝑠𝑜 is needlessly good.

On the other hand, all its coefficients are expressed with 192 bits of precision, what is way too large for our purposes. In order to reduce the input size, we can try to cut back the coefficients binary size in an orderly way.

Indeed, we can reduce our the size of our polynomial coefficients as follow:

𝑃 𝑠𝑜 𝑟𝑜𝑢𝑛𝑑 = 1.
𝜖 𝑃𝑠𝑜 𝑟𝑜𝑢𝑛𝑑 ≈ 2.0453563920185731559517892732113678956410670624863181638949𝑒 -20
which is more than sufficient but not by an extraordinary wide margin. As can be seen, the reduction in size is noticeable.

Recovering the polynomial in SageMath

The expression tree of 𝑃 𝑠𝑜 𝑟𝑜𝑢𝑛𝑑 is traversed to find out which is the maximum precision used to represent the coefficients (as we have seen, precision can differ from one coefficient to another in Sollya). Conversely, in SageMath, polynomials are defined over a ring of floating-point numbers.

Such rings are indexed by the precision of their elements, hence all the coefficients of a polynomial must be represented with the same number of bits. The maximum value (here 64 bits) is used to convert the Sollya polynomial into a SageMath polynomial with no information loss: all coefficients are converted into SageMath with the broadest format.

There is no visible different in the output of the two polynomials. Nevertheless, the size reduction operated above is not lost: it relates to the informational content, not to the representation. In the sequel, we will be able to actually use the fact that the coefficient of 𝑖 From now on, all computations (but infinity norm of errors) are performed in SageMath. We want to make sure that, at any point, the just performed transformation has not spoiled the approximation accuracy achieved previously. Using the variable change proposed above we can check with the Sollya dirtyinfnorm function that

‖𝑔-𝑃 𝑠𝑎,𝑓 𝑓 ‖ ∞ over [𝑙𝑏, 𝑢𝑏] ≈ 2.045356392018573155951789273211367895655212982466770090132𝑒-20
This is marginally different from the initial value in Sollya and still better than enough for our purpose.

The Long March to the integral polynomial

In this section, through a series of transformations, we will derive an integral polynomial from our floating-point initial one. This will be the starting point to set up our small roots finding problem.

From a floating-point coefficients polynomial to a rational coefficients one Indeed floating-point coefficients and arguments are self-ignorant rational numbers. The transformation are then trivial. What matters here is to get things done with diligence. In the next step we make this correspondence explicit by transforming the original 𝑃 𝑠𝑎,𝑓 𝑓 into a polynomial over the rational numbers. Let us call this polynomial 𝑃 𝑠𝑎,𝑟𝑟 . Its coefficients are rational, hence the first r and its possible arguments are floating-point numbers or rationals (we picked r in the designation). Again an approximation error check can be done with the previously done change of variable.

‖𝑔-𝑃

𝑠𝑎,𝑟𝑟 ‖ ∞ over [𝑙𝑏, 𝑢𝑏] ≈ 2.0453563920185731559517892732113678956410670624863181638949𝑒-20
The small discrepancies in infinity norms show up at about the 40th number in the fractional part are due to decimal to binary conversion at slightly different precisions in Sollya.

From floating-point/rational arguments to integral arguments 𝑃 𝑠𝑎,𝑟𝑟 accepts floating-point and rational arguments. What we do now is to transform it in order to accept only integral arguments: the numerators. This implies that the denominators corresponding to the argument get incorporated into the coefficients, taking into account the degree of the argument in the corresponding monomial.

We obtain the following polynomial 𝑃 𝑠𝑎,𝑟𝑖 for coefficients are rational numbers and integral arguments. When, after the variable change, the check is performed we get:

‖𝑔-𝑃 𝑠𝑎,𝑟𝑖 ‖ ∞ over [𝑙𝑏, 𝑢𝑏] ≈ 2.0453563920185731559517892732113678956410670624863181638949𝑒-20
which should not surprise anyone.

From rational coefficients to integer coefficients

Our final target is an all integral expression. For that purpose, what we want to do now is to eliminate the denominators. Not only those of the polynomial coefficients but also those of the other terms that show up in our inequalities as well. Let us remind our main inequality here:

∀𝑖 ∈ 𝑟𝑙..𝑟𝑢 , ∀𝑗 ∈ 𝑗 𝑟𝑙 , 𝑗 𝑟𝑢 , ⃒ ⃒ ⃒ ⃒ 𝑃 (𝑖) - 2𝑗 + 1 2 𝑝 ⃒ ⃒ ⃒ ⃒ > 1 2 𝑚+1 .
We also have to remove the denominator of 2𝑗 + 1 2 𝑝 and 1 2 𝑚+1 terms. This involves first reducing all rational numbers (polynomial coefficients and other terms) to the same denominator by computing their least common multiple. Let us call it 𝑠𝑐𝑎𝑙𝑖𝑛𝑔_𝑓 𝑎𝑐𝑡𝑜𝑟 (we will see why below). We will store it for book keeping reasons. Of course, we adjust all numerators accordingly. When done with it, we can remove the (now common) denominator.

Let us call 𝑃 𝑠𝑎,𝑖𝑖 the obtained polynomial (integer coefficients and integer argument).

The previous inequality becomes: , based on the theoretical assumption that the denominators of polynomial 32 𝑃 𝑠𝑎,𝑟𝑖 coefficients were all powers of 2.

∀𝑖 ∈ 𝑟𝑙..𝑟𝑢 , ∀𝑗 ∈ 𝑗 𝑟𝑙 , 𝑗 𝑟𝑢 , ⃒ ⃒ ⃒ ⃒ 𝑃 𝑠𝑎,𝑖𝑖 (𝑖) - 𝑠𝑐𝑎𝑙𝑖𝑛𝑔_𝑓 𝑎𝑐𝑡𝑜𝑟 (2𝑗 + 1) 2 𝑝 ⃒ ⃒ ⃒ ⃒ > 𝑠𝑐𝑎𝑙𝑖𝑛𝑔_𝑓 𝑎𝑐𝑡𝑜𝑟 2
In real world computations this may not necessarily be the case at this stage since the computer algebra system (SageMath for that matter) may have reduced floating-points coefficients to fractions on its own way. It turns out that SageMath does it in a very hostile way to us 33 by approximating floating-points with continued fractions. The consequence is that, if nothing is done about it, the odds are very high that the denominators become mutually prime, and that 𝑠𝑐𝑎𝑙𝑖𝑛𝑔_𝑓 𝑎𝑐𝑡𝑜𝑟 becomes apocalyptically huge. So much for polynomial coefficients shaving. Performing the coefficient transformation by ourselves was straightforward and left us in total control of the transformation.

As a consequence, all our initial assumptions were still standing and the binary size of data was kept at a manageable level.

Those are the results for our example:

𝑃 𝑠𝑎,𝑖𝑖 (𝑖) = 363597813763221970528261829033984 + 80734939804336128 𝑖 + 9 𝑖 2 32 A polynomial with rational coefficients that derived, one way or another, from floating-point numbers. 33 We do not take it personally: SageMath has very good reasons to adopt this default behavior. For many applications, it is the most sensible way to convert floating-point numbers into rational ones.

𝑄 0,0 (𝑖, 𝑡) = 𝒩 2 𝑄 1,0 (𝑖, 𝑡) = 𝑖 𝒩 2 𝑄 2,0 (𝑖, 𝑡) = 𝑖 2 𝒩 2 𝑄 0,1 (𝑖, 𝑡) = 𝑄(𝑖, 𝑡) 𝒩 𝑄 1,1 (𝑖, 𝑡) = 𝑖 𝑄(𝑖, 𝑡) 𝒩 𝑄 0,2 (𝑖, 𝑡) = 𝑄(𝑖, 𝑡) 2
Once these polynomials are created we must make the following change of variables:

𝑖 ↦ → 𝑖𝐵𝑜𝑢𝑛𝑑 𝑖 and 𝑡 ↦ → 𝑡𝐵𝑜𝑢𝑛𝑑 𝑡, in order to obtain the elements for the lattice 𝐿 generating matrix. In fact 𝑖𝐵𝑜𝑢𝑛𝑑 and 𝑡𝐵𝑜𝑢𝑛𝑑, raised to the power corresponding to the degree of the monomial where the variable change is made, are incorporated into the coefficients.

The obtained polynomials are listed below. In many of the classical presentations of matrix generated lattices, the basis of is described in term of column vectors. Nevertheless, this is not a general rule among authors. Besides, the implementation of the 𝐿𝐿𝐿-algorithm used by SageMath, fplll, uses a row oriented matrix. In order to keep the exposition and the code in line, this presentation will be row-oriented.

Here the row vectors of the matrix are based on the polynomials obtained above. They are built as follows:

1. we create Ω, an ordered list of all the monomials included in the 𝑄 𝑟,𝑠 (𝑖, 𝑡) polynomials (not taking here the coefficients into account);

2. for each 𝑄 𝑟,𝑠 (𝑖, 𝑡) polynomial we create a vector 𝑉 𝑟,𝑠 which holds, for each element of Ω, its coefficient in 𝑄 𝑟,𝑠 (𝑖𝐵𝑜𝑢𝑛𝑑 𝑖, 𝑡𝐵𝑜𝑢𝑛𝑑 𝑡); notice how 𝑖𝐵𝑜𝑢𝑛𝑑 and 𝑡𝐵𝑜𝑢𝑛𝑑 make their way into the vectors; logically, if some monomial 𝜔 𝑗 ∈ Ω is missing in 𝑄 𝑟,𝑠 (𝑖, 𝑡) the value for the corresponding element of the 𝑉 𝑟,𝑠 is 0 at position 𝑗.

3. Matrix 𝑀 is built with all 𝑉 𝑟,𝑠 's as it's rows.

In our example the ordered list of monomials is the following :

Ω = [1, 𝑖, 𝑡, 𝑖 2 , 𝑖𝑡, 𝑡 2 , 𝑖 2 𝑡, 𝑖 3 , 𝑖 4 ].
For instance, the vector corresponding the first (constant) polynomial 𝑄 0,0 (𝑖, 𝑡) = 𝒩 2 is 𝑉 0,0 = (𝒩 2 , 0, 0, 0, 0, 0, 0, 0, 0, ). This vector will be the first row of the 𝑀 matrix.

Displaying the matrix on paper is difficult because its elements are really large. As they are the coefficients of the polynomials listed above, this would not add much information either.

Reducing the matrix

Once the matrix has been built, it is input to the fplll package for reduction. There is not much to say about it, since fplll is essentially used as a black box with the default optional parameters that are set to produce a guaranteed result. The very small matrix built above is reduced in a blink.

Checking the Coppersmith condition

The fplll package has done its best to reduce the lattice basis. The corresponding vectors can be found as rows of the output matrix. But we cannot be sure that the basis has been reduced enough to comply with Coppersmith's condition. This can be easily checked when the result is still in it's matrix form. The norm we are supposed to compute over the polynomials is the 2-norm of the corresponding row vector in the matrix.

For each row 𝑟 𝑖 , we must check:

‖𝑟 𝑖 ‖ 2 √ 𝑤 < 𝒩 ,
where 𝑤 is the cardinal of the monomials set Ω.

In our example 𝑤 = 9 and 𝒩 𝛼=2 = 1298074214633706907132624082305024.

On the one hand, we do not know if they have a common non trivial factor. On the other hand they are bivariate polynomials. One possible method to take care of both aspects together is to compute the pairwise resultant in one variable (𝑡 is the preferred eliminated variable in our context) for all the polynomials.

If two polynomials have a non trivial common root, their resultant will be null. If not, the resultant will be a univariate polynomial in 𝑖 whose roots, if any, can be directly computed by applying the appropriate function in SageMath. This is the technique we use here.

First of all we form all the possible polynomial pairs among those whose coefficients comply with the Coppersmith Condition. In the general case this yields |𝑅| (|𝑅| -1) 2 pairs since

Res 𝑡 (𝑅 𝑚 , 𝑅 𝑛 ) = ±Res 𝑡 (𝑅 𝑛 , 𝑅 𝑚 ). Out of our 2 polynomials we build only a single pair.

We only retain the pairs whose resultant (in one arbitrarily selected variable, here 𝑡) is not null.

In our example, for the single pair of polynomial, the result is null. An extra check (only performed for our exposition needs but no time is wasted at it in actual code) shows that their gcd is:

𝑔𝑐𝑑(𝑅 0 , 𝑅 1 ) = -1719 𝑖 2 -48378511622144 𝑖 + 191 𝑡 -4538783999459328
This situation forces us to reconsider the bounds we are working on. We will have to start over all the process (that we will spare to the reader) with a new (narrower) interval. In our implementation, we apply a slightly more than 1/2 reduction factor. This also mean that covering all the interval will take at least two iterations instead of one.

To make a long story short, at the next iteration, we obtain 3 Coppersmith's condition compliant polynomials. All of the 3 (3 -1) 2 = 3 pairs of polynomials yield again null resultants in 𝑡. After several failures, we reach a point (with 𝑖𝐵𝑜𝑢𝑛𝑑 = 81, remember we started at 256) where a non null resultant is found for two polynomials 𝑅 𝑖 (𝑖, 𝑡), 𝑅 𝑗 (𝑖, 𝑡) (that we do not specify further):

𝑅𝑒𝑠 𝑡 (𝑅 𝑖 , 𝑅 𝑗 = -643668726678221525097674985202593682333086823088156167986348694700032 𝑖 3 -16091718166955538127441874630064842058327170577203904199658717367500800 𝑖 2 + 5636607039521185895280339845419112876190841309782983563056455519488180224 𝑖 + 258026838794771984544379873643178526843182181684526074904519614895707127808
At the next step, we check if the resultant is a constant (has degree in 𝑖 < 1), which is obviously not the case here. If the resultant were a constant, we would pronounce the interval empty of hardto-round cases, since the resultant would have not root in 𝑖. In our case, we will have to search for integral roots in 𝑖 of the resultant.

An integral root exists: 168. Interestingly, it is larger than the 𝑖𝐵𝑜𝑢𝑛𝑑 = 81. It is also a root of the original 𝑄(𝑖, 𝑡) equation (remember that the obtained roots set is a superset of the 𝑄(𝑖, 𝑡)'s roots set). This is not abnormal. It only shows that the upper bound condition in Theorem 3.3 is somehow pessimistic.

The root test in polynomial 𝑄(𝑖, 𝑡) was only done here for the needs of the exposition. In actual code, as soon as we have an 𝑖 root of the resultant we directly test it for hardness-to-round. This is the process we detail below.

Analyzing a root

For that end, we map back the integral value to the floating-point number it represents in the scaled function domain (0-fbinade). This is done in three steps:

1. change coordinates from those relative to the center of the interval to those relative to the 2 𝑝-1 , 2 𝑝 -1 enumeration, (here 4503599627370496, 9007199254740991 ), by adding the value corresponding to the interval center (here 6755399441055744) to 168;

2. transform the previous integer into a floating-point number that will live in the 0-fbinade by a division by 2 𝑝-1 (here 4503599627370496);

3. transform the floating-point number in the 0-fbinade into a floating-point number in its original binade (here the scaling is straightforward since the original binade is the 0-fbinade).

The outcome of all these transformations is the following value:

• 1.0111111111111111111111111111111111111111111111111001 (binary);

• 1.4999999999999984456877655247808434069156646728515625 (decimal).

Computing, at a very high precision, the image of this number by our original function exp(𝑥) outputs (in binary):

100.01111011010011111111100110010011111100010100111001100000000000111110011100110011101 . . .

123.45678901234567890123456789012345678901234567890123↑567890123↑567890123456789

The line of digits just beneath the number in binary is not a numerical value. It is a "bit position scale" that will help us to visualize what happens. Two tiny vertical arrows are placed, respectively, at positions 54 and 64. One can see that past position 54, occupied by a 1-bit, starts a string of 0-bits. That string is not finished yet at position 64, occupied by a 0-bit. That signs, indeed, for our initial data, that we have found an hard-to-round case. In the implementation, the technique actually used to identify hard-to-round cases is different, more efficient if less pictorial.

This concludes the work on the current sub-interval. Since the set of roots of any pair of Coppersmith's condition compliant polynomials is a superset of that of 𝑄(𝑖, 𝑡), no other pair needs to be examined. All we could expect from such examination is either:

• find the same root;

• find other roots that are guaranteed not to be roots of 𝑄(𝑖, 𝑡), since they should otherwise have been found with the first pair.

Nevertheless, the considered resultant only has one root. Should it have several, one should investigate them all as hard-to-round cases candidates.

Mission accomplished

Execution of our example continues with the examination of the next sub-intervals, in order to fully cover the initial interval.

As one expects, when the next sub-interval is dealt with, the same hard-to-round case is found but, of course, for a different root since the bounds are different. This time the root lives inside the -𝑖𝐵𝑜𝑢𝑛𝑑, 𝑖𝐵𝑜𝑢𝑛𝑑 . As anticipated as it is, this result is nevertheless comforting: the implementation does not only catch roots outside the assigned sub-interval but it can also find them inside too!

In the subsequent computations, other outcomes are possible. In several occasions, false candidates are found:

• 1.5000000000000195399252334027551114559173583984375;

• 1.50000000000005595524044110788963735103607177734375.

This illustrates the fact that the polynomials rebuilt from the 𝐿𝐿𝐿-reduced basis have roots that are not roots of 𝑄(𝑖, 𝑡).

Eventually, the program terminates with a grand total of two hard-to-round cases found:

• 1.4999999999999984456877655247808434069156646728515625 (already mentioned, that was found first, outside of the assigned search interval that was the explored);

• 1.499999999999956035168224843800999224185943603515625 (that though smaller than the previous one, was found later, quietly waiting to be found in its "home sub-interval").

Anecdotally, both cases are found in the same narrow interval, when the probabilistic model predicted only 1 case for the whole interval. The reduced sample size (512 numbers!) dampens any strong conclusion one would like to draw from this example.

An exhaustive search absolutely confirms the above findings.

The total number of iterations of the algorithm is 8 since, in several occasions and especially at the beginning, there were not enough polynomials (as in iteration #1) to compute a resultant or the resultant of all the pairs of polynomials formed at some iteration was null. Interval splitting was necessary to obtain a meaningful decision about the status (free or infested of hard-to-round cases) of a given interval.

As a concluding remark about this example, we must notice that the result was obtained in 2.5 seconds (which includes a "warm up" phase until the "right" interval stride was found) whereas exhaustive search took less than a second (0.73 s).

First set of experimental results

For our experiments, and as mentioned in the example section, we have worked with the exp(𝑥)

function. One of the main reasons for this choice is that, thanks to previous work by V. Lefèvre, hard-to-round cases are known for binary64. The very least that one could expect from an implementation of the 𝑆𝐿𝑍-algorithm was that it would find back what is already known (let alone improved performance).

Experiments were a bit tedious to perform for several reasons. The first one is that there is no clearly established relationship, once precision 𝑝 is set, between the main parameters of the algorithm (𝛼, the degree -𝑑 -of the approximation polynomials, the target hardness-to-round, the width of the intervals) in actual practice. Of course, it is perfectly clear that the width of the interval should not be larger than what the degree of the polynomial allows for in terms of approximation accuracy in order to verify the constraints dictated by the hardness-to-round one wants to check.

The consequence is that testing involves a lot of groping. To make the matter worse, when performing realistic tests is wanted (remember, in the 6𝑝 to 12𝑝 bracket), each run takes a lot of time. Under these conditions, one may have the uncomfortable feeling of groping with boxing gloves.

Tests were all performed on servers powered by dual Intel R ○ Xeon R ○CPU E5-2695 v2 @ 2.40GHz, with 128 Gb of RAM.

The data set

We present here our first experimental data set obtained with implementation as described above.

Tables 3.10 through 3.13 list the information for, respectively, a hardness-to-round of 6𝑝 (for the first three ones) and 8𝑝 (for the last one). Despite several attempts, we could not run our expected tests for 10𝑝. More exactly they all failed at some points, sometimes after almost a week spent in computations, because of a program crash (a segfault error). As it can be seen, our tests concentrated on an hardness-to-round of 6𝑝 (678 bits). The reason is obvious: our incursions into the 8𝑝 realm was chastised with a tenfold execution time penalty. We did not overly insist. However scanty they are, 8𝑝 data give nevertheless some interesting indications.

Before we try to give an analysis of the data, we must first pay tribute to the rock-steady stability of fpLLL. As can be seen, some runs last more than two days, with large volumes of data. At highdegree/high-alpha, the typical size of the file holding the matrix to reduce, expressed in decimal numbers, is several hundreds of megabytes. And the larger the data set, the longer the execution time is. As stated before we experienced segfaults when running reductions for hardness-to-round of 10𝑝 after more than a week of execution time. Which element of the software chain should take the blame for these failures remains unclear.

Reduction grabs the lion's share of execution time

Without any question, reduction is the main contributor, by a wide margin, to the execution time of the 𝑆𝐿𝑍-algorithm, at least in our implementation. This is why we put so much emphasis on reduction in our tables. This is especially true for our search domain (6𝑝 and 8𝑝 hardness-to-round).

For smaller precisions (e.g. binary64) and the corresponding hardness-to-round, reduction execution time can be compared with that of other parts of the algorithm (e.g. polynomials computation and rounding, resultants computation).

This situation highlights the importance of the construction rules of the initial lattice. We believe that much remains to be done in this area. As preliminary and not reported here results

show, shifting from the initial formulation of the basis construction from that found in [START_REF] Stehlé | Worst Cases and Lattice Reduction[END_REF] to that of [START_REF] Stehlé | On the randomness of bits generated by sufficiently smooth functions[END_REF] was very useful move in this respect. But still, an elucidation of the optimal lattice basis building rule for a given problem structure could bring in great improvements for the reduction of execution time. It would, at the very least, lift the doubts we still have in this respect.

The weird reduction time drift

For a given degree, the width of the approximation interval is initially constrained by the accuracy of the approximation. We make sure the interval is narrow enough so that a single polynomial of the chosen degree can approximate the function with the necessary accuracy.

As it turns out, when a low value is used for 𝛼, one can stumble on another problem: the reduction does not yield two short enough norm vectors (and free of any non-trivial common factor) to be able perform the hunt for roots. In this case, we have to break the interval in two and carry on with the smaller sub-interval. Of course, we may be forced to make several of those splits in cascade until the interval is small enough in order to obtain the needed couple of polynomials. Our experience is, once a satisfactory interval size is found, that we can carry on with it for further checks, at least for a limited part of the domain of the function. This has been analyzed in detail in §3.5.3.2, p. 188, for the exp(𝑥) function. We systematically attempted to enlarge interval size and those attempts have systematically failed as well: even for a minimal stretching factor over the "ideal" interval width, the short-norm vectors search fails again. Reductions are then successfully34 performed on smaller intervals of growing width until the initial width is fully covered.

When multiple such searches are performed they string together inside the same system process.

We experience then a lengthening of reductions execution time from the first to the last ones in a somewhat jagged pattern but with a clear growth trend. That can be seen from our minimum and maximum reduction timings. The former are generally observed at the beginning of the execution while the latter are at the end.

When really many (over a few dozens) reductions are preformed, the drift eventually stabilizes at some relatively high value (compared with the initial ones). This has nothing to do with a real reduction time increase along the interval: when one of these last intervals is processed directly (without any forerunner), its reduction times match that of the first intervals. Our best guess is that the tools have to be regarded as responsible for that reduction time drift but we could not pinpoint (our own programming, Python/SageMath, fpLLL?) where put the blame on. This lays a shade of suspicion on our comparisons between one time reduction over a single "large interval" and aggregated reductions over smaller ones.

The "sweet spot" effect

We have not represented all of our testing to spare place and reader's attention. For degree-17, degree-18 and 6𝑝, the best explored area, our data is presented around a particular case (𝑑 = 17, 𝛼 = 6; 𝑑 = 18, 𝛼 = 6). It has two main characteristics:

• it is the smallest 𝛼 for which we do not need to split the interval because of a Coppersmith's condition failure (two valid short-norm vectors are found);

• the execution time is minimal.

Indeed, for a smaller value of 𝛼, the interval has to be split. The aggregated time of the multiple necessary searches is larger (even if we set aside the "time drift" effect) than that of a single, wider search. On the other hand, using a larger value of 𝛼, which considerably grows the volume of the input data for 𝐿𝐿𝐿-reduction, only leads to a vastly increased reduction time. To our dismay, we are not able to give an informed explanation to this phenomenon.

Our only conclusion so far, from a practical point of view, is that, if one is to use this algorithm, she must look for the "sweet spot" the parameters and perform all her computations with this setting.

For degree-19 and degree-20, we are inclined to think that we have not worked out the sweet spot yet. Apparently, the effect shows up again at degree-30 and 𝛼 = 8 for a 8𝑝 hardness-to-round.

Higher degrees do not fare better

For a given value of 𝛼, once an optimum in polynomial degree is reached (see §3.7.1.3, p. 224) increasing the degree of the polynomial does not help. On the one hand higher degree polynomials allow for larger intervals (from the approximation standpoint). But, on the other hand, the search process fails when searching for small-norm, non-trivial common factor free polynomial pairs on such wider interval. This forces us to come back to an interval width that is the same as that we used for our optimal set of parameters.

It also turns out that polynomial with higher degrees yield larger basis data size that causes a time penalty. From our degree-17 and 𝛼 = 6 best performer case, moving to higher degrees does not show any improvement. There is no real gain in interval width and should there be some, it would be overweighted by the increase in execution time. Hence, when 𝛼 is set, it is very important, for optimal performance, to pick the "right" polynomial degree.

Larger values of hardness-to-round are easier to check

This result was asymptotically expected from theoretical results. Experiments seem (considered to the limited number of tests, we cannot be absolutely conclusive on this one) to follow the trend for the small values (small compared with 𝑝 2 for which property is proved, see [START_REF] Stehlé | Algorithmique de la réduction de réseaux et application à la recherche de pires cas pour l'arrondi de fonctions mathématiques[END_REF], Theorem 27) we use.

Our best scorer in 6𝑝 can process a 2 80 number interval in 1,646 s. Its sibling in 8𝑝 performs the same task on 2 87 numbers in 71,254 s. The ratio between the two intervals is 2 7 = 128. The speedup is almost 3 in 8𝑝 and we can not discard the possibility that even better timings are obtained for this hardness-to-round value.

3.8 Accelerating operations lattice basis: from reduction to transformation Our above detailed example and initial experimental results already raised some doubts on the capacity of the initial implementation to get the work done in a reasonable time span. Those doubts are solely related with execution time, since we could recover the results found with the 𝐿-algorithm (using small intervals around the already known hard-to-round cases) or meet other challenges, as the one we set in §3.6.2, p 203, where we controlled the behavior of our implementation with exhaustive search over a necessarily limited-width interval.

We could try to comfort ourselves by thinking that the execution time data of the detailed example are not relevant since our test parameters placed us in a situation where the 𝑆𝐿𝑍-algorithm is at a disadvantage with other techniques. Nevertheless, the first test in 113-bit precision and with a hardness-to-round of 8𝑝 cleared up our doubts and confirmed that, even in better conditions, the execution time was way too long. All the timings are given in the previous section: with our best performer, it would take 224,310 years to explore a full binade on a single processor. Even if our problem is embarrassingly parallel and its processing can be split in smaller tasks executed independently, the exploration of a single binade could be intractably long to perform.

Where is the bottleneck? Without any debate, in lattice reduction. From our first experimental data, lattice reduction always represents more than 99 % of the execution time. These lengthy reductions also set another problem such as the actual possibility to deal with a "large" hardnessto-round. In our context "large" means 10𝑝 and above. In most occasions, with these parameters, reduction crashed before completion after running for rather long time spans (more than a week).

In other occasions we faced a spectacular memory ballooning that threatened the stability of the (shared) system we used. We had to abort the execution in order to avoid a memory swapping that would ultimately have swept away all our performance hopes.

At this point, "Can reduction time be shrunk?" is a legitimate question.

Two (momentarily?) discarded options

A first approach could have been to search for "tactical workarounds" for our problem such as:

• find a faster reduction library;

• call the library with different parameters.

We have felt that there was no point in changing software. The fpLLL library used in SageMath is already one of the quickest implementations around. Switching to another library would have possibly given us, at best and being optimistic, a factor 2 in time reduction: not a radical change at that point.

Another option could be to use different parameters in the fpLLL invocation. As we have seen, we have used the default ones that ensure that we get an 𝐿𝐿𝐿-reduced basis. But, if we think about it, what we actually need is a basis that has some (at least 2) sufficiently small-norm vectors to comply with the Coppersmith's condition. We 𝐿𝐿𝐿-reduce our initial basis with the expectation that the output will provide us with such vectors and that, furthermore, those will be the first ones that are returned. One can imagine that calling the fpLLL library with less aggressive parameters would be sufficient to fulfill our objective. We gave this option a lazy 35 try. The initial tests did not lean us to think that we could obtain a major acceleration factor that could completely change the picture.

It does not mean that this optimization leads are discarded forever. All we say here that we view them as useful second line options. This leaves us with more "strategic moves": interfere with the reduction process itself, keeping in mind that what we actually want are small-norm vectors.

Reducing the Gram matrix

The matrices that define the lattices we want to reduce have a very eye-catching property: they are very "rectangular". In other words, the dimension of the lattice is small compared to its degree.

More precisely, and with the building rules presented in §3.5.2.3, p. 182, the number of rows (polynomials) of the matrix is given by formula (𝛼 + 1)(𝛼 + 2) 2 while the number of columns (monomials) is computed with formula (𝛼 + 1)(𝑑𝛼 + 2) 2 , where 𝑑 is the degree of the polynomial. For our best performing set of parameter hardness-to-round 8𝑝 (𝛼 = 8, 𝑑 = 30) the matrix has 45 rows for 1089 columns.

Defining a lattice by its Gram matrix

We already met the Gram matrices when we defined the volume of a lattice in §3.4.4, p 170. It turns out that this object is connected to deeper aspects of lattice theory than only being a convenient mean to be able to compute a volume-like magnitude for lattices the defined by rectangular matrices.

One can find an in-depth and yet accessible exposition in [START_REF] Cohen | A Course in Computational Algebraic Number Theory[END_REF] Chap. 2, §2.5. In this theoretical perspective, the Gram matrix is a more fundamental object than a basis for the definition of a lattice. For instance, several different bases of the same lattice can yield the same Gram matrix.

More precisely, if from two bases, 𝑏 1 , and 𝑏 2 we form the 𝐵 1 and 𝐵 2 such that:

• 𝐵 1 and 𝐵 2 define the same lattice,

• 𝐵 1 × 𝐵 1 = 𝐵 2 × 𝐵 2 = 𝐺, where 𝐺 is a Gram matrix 36 , then 𝐵 1 = 𝐾 × 𝐵 2 , where 𝐾 is an orthogonal matrix.

In other words, the Gram matrix 𝐺 of a lattice with basis 𝑏 determines this basis uniquely up to isometry.

It comes from the above that a Gram matrix is a very natural way to define a lattice and that the algorithms to perform lattice reduction from a Gram matrix are very similar to those used from a basis-built matrix. There are theoretical arguments to support the claim of a greater efficiency of this course of action (see [START_REF] Cohen | A Course in Computational Algebraic Number Theory[END_REF] p. 89, Remark 2).

It also comes that the result of the reduction of a lattice defined by a Gram matrix, cannot be, as in the case of a lattice defined by a basis, a new (reduced) basis. Here the output of the algorithm is a transformation matrix 𝑇 such that

𝑇 × 𝐵 = 𝐵 𝐿𝐿𝐿-𝑟
where 𝐵 is a matrix formed from a basis 𝑏 defining a lattice 𝐿, and 𝐵 𝐿𝐿𝐿-𝑟 is formed from the 𝐿𝐿𝐿-reduced basis 𝑏 𝐿𝐿𝐿-𝑟 of the same lattice 37 . 36 We have swapped the order of the matrices in the products since Cohen's exposition is based on matrices formed with the vectors of the basis as column vectors and we stick to our initial choice of row-vector based matrices. 37 Again, matrix transposition and order of multiplication depend on the choice among the columns/row alternatives for the presentation.

Gram matrix dimensions

Our interest in the Gram matrix was not initially triggered by the aforementioned theoretical advantages in the reduction process. The extent to which they materialized in actual implementations remained unclear. But what was immediately and particularly appealing was that the Gram matrix opened the possibility to work with more amenable objects than our initial extraordinarily stretched matrices.

Indeed from a, say, 45 × 1089 initial matrix we could get a 45 × 45 Gram matrix. Of course, this reduction in matrix dimension did not come for free: the bit size of the matrix elements was vastly extended (essentially by a factor 2). Matrix multiplications also took their toll on performance when the global process was considered but, in actual tests, it was negligible.

A dead end

The result in actual tests, replacing the straight basis reduction by the above sketched process in our implementation, were not particularly rewarding. We do not give a detailed record of these experiments here since the timings were within 5 to 10 % of our initial results.

We insist here on the fact that going through the Gram matrix process also delivered an 𝐿𝐿𝐿reduced basis. The output was not essentially different than that we initially obtained with basis reduction alone.

Random projections and projected matrices reduction

Does the lack of improvement noticed when reducing the Gram matrix negatively seal the faith of our effort to squeeze the matrix? No, since another path has been opened by a work of A. Akhavi and D. Stehlé [START_REF] Akhavi | Speeding-up Lattice Reduction with Random Projections[END_REF] published in 2008.

A bird's eye view of the process

This global description does not settle all the issues that will be dealt with in subsequent sections.

The general scheme is essentially the same as the one described in the previous section:

1. start with a basis 𝑏 of some lattice 𝐿 made of 𝑚 vectors of 𝑛 elements, with 𝑛 𝑚;

2. from 𝑏 build a 𝑚 × 𝑛 matrix 𝐵 (we remind our convention that the vectors of 𝑏 are the rows of 𝐵);

3. from 𝐵 derive some 𝑚 × 𝑚 square matrix 𝐵 𝑝 ;

The demonstration of this lemma can be found, for instance, in [START_REF] Cohen | A Course in Computational Algebraic Number Theory[END_REF].

The transformation matrix output by the fplll implementation we use is precisely such a unimodular matrix.

It comes from the above that the matrix 𝑇 is unimodular. It follows that the set of vectors 𝑏 𝑡 computed at step ( 6) is a basis that defines the same lattice 𝐿 as 𝑏.

Let us enter into more details about the majors steps of the process.

Reducing the number of columns: matrix projection

Having anticipated the shortcoming of Gram's matrix reduction (in the Gram matrix, elements have essentially a doubled bit-size compared to those of a matrix formed with a basis), A. Akhavi and D. Stehlé have devised another method that tries to avoid this flaw. The first idea is to use a projecting matrix whose left multiplication by the initial matrix will yield a square matrix.

Let us call 𝐵 the 𝑚 × 𝑛 with 𝑛 𝑚, the matrix built from a basis of the lattice. We remind here our row-vector construction convention from the vectors of the basis (𝑚 is the dimension of the lattice, 𝑛 is the degree). Let us also call 𝑃 an 𝑛 × 𝑚 projecting matrix 38 .

We obviously have:

⎡ ⎢ ⎢ ⎢ ⎢ ⎢ ⎢ ⎢ ⎢ ⎢ ⎣ 𝐵 ⎤ ⎥ ⎥ ⎥ ⎥ ⎥ ⎥ ⎥ ⎥ ⎥ ⎦ × ⎡ ⎢ ⎢ ⎢ ⎢ ⎢ ⎢ ⎢ ⎢ ⎢ ⎢ ⎢ ⎢ ⎢ ⎢ ⎢ ⎣ 𝑃 ⎤ ⎥ ⎥ ⎥ ⎥ ⎥ ⎥ ⎥ ⎥ ⎥ ⎥ ⎥ ⎥ ⎥ ⎥ ⎥ ⎦ = ⎡ ⎢ ⎢ ⎢ ⎢ ⎢ ⎢ ⎢ ⎢ ⎢ ⎣ 𝐵 𝑝 ⎤ ⎥ ⎥ ⎥ ⎥ ⎥ ⎥ ⎥ ⎥ ⎥ ⎦
where the projected matrix 𝐵 𝑝 is an 𝑚 × 𝑚 square matrix.

If 𝑃 is built in such a way that its elements have a small bit-size, that of the elements of 𝐵 𝑝 will not be much larger than that of the elements of 𝐵.

• another where the entries are uniformly and independently picked from {-2 𝑁 , ..., 0, ...2 𝑁 -1},

where 𝑁 is a small positive integer (typically, the experimental results of [START_REF] Akhavi | Speeding-up Lattice Reduction with Random Projections[END_REF] where computed for 𝑁 = 3 and 𝑁 = 10; we used similar values).

As one can see, in both cases, our transformation matrix elements are integers.

But what is not sure yet is that 𝐵 𝑝 is still a basis. Actually, this will be the case with a high probability. If not, this will occasion a problem and it will be detected during 𝐿𝐿𝐿-reduction causing its failure. All we have to do is to gracefully recover from this misstep, compute another projection matrix 𝑃 with the expectation that this time the product 𝐵 𝑝 × 𝑃 will actually yield a basis.

The situation where 𝐵 𝑝 does not represent a basis has never happened in any of our tests. We had to make up artificial cases to test the behavior of fpLLL (linear independence of the rows of the matrix is checked when a Gram-Schmidt orthogonalization is performed) and check the handling of the generated exceptions in our implementation.

The implementation

We only give here a few elements of the implementation of the matrix projection and its behavior.

More extensive experimental results will be given in a section to come.

As explained above the projecting matrix 𝑃 is formed by picking its elements in {-1, 1} or in {-2 𝑁 , ..., 0, ...2 𝑁 -1}, with 𝑁 ∈ {4, 8, 12}. To make a long story short, we did not notice any real improvement when switching from the first distribution to the second. As for the second, we observed instead a performance degradation as 𝑁 was growing larger. Nevertheless a more systematic exploration of values for 𝑁 4 may possibly help to scrap extra bits of execution time.

Using the same notations as above, we compute 𝐵 × 𝑃 = 𝐵 𝑝 where 𝐵 𝑝 is the (square) projected matrix.

The function of the fpLLL library we use to perform reductions does not only compute an 𝐿𝐿𝐿reduced basis but it also returns, at almost no extra cost, the transformation 𝑚 × 𝑚 matrix 𝑇 that when right multiplied by the original matrix (here 𝐵) yields the reduced matrix:

𝑇 × 𝐵 𝑝 = 𝐵 𝑝𝑟 ,
where 𝐵 𝑝𝑟 is the (square) 𝐿𝐿𝐿-reduced projected matrix.

To trigger the return of the transformation matrix 𝑇 by the 𝐿𝐿𝐿-reduction function in SageMath, we have, instead of just calling with the matrix to reduce as an argument, to invoke it with an augmented matrix crafted as follow :

⎡ ⎢ ⎢ ⎢ ⎢ ⎣ 𝐼 𝐵 𝑝 ⎤ ⎥ ⎥ ⎥ ⎥ ⎦
, where 𝐼 is an 𝑚 × 𝑚 identity matrix. The final result is an 𝑚 × 2𝑚 matrix that will be the actual argument for the fpLLL call.

After reduction is performed, the matrix returned by fpLLL is laid out as follows

⎡ ⎢ ⎢ ⎢ ⎢ ⎣ 𝑇 𝐵 𝑝𝑟 ⎤ ⎥ ⎥ ⎥ ⎥ ⎦
, such that 𝑇 × 𝐵 𝑝 = 𝐵 𝑝,𝑟 .

The 𝐵 𝑝𝑟 matrix is of no use to us, it is indeed the transformation matrix 𝑇 that interests us.

We are going to left multiply our initial matrix by 𝑇 with the hope that 𝑇 × 𝑀 will be a matrix that corresponds to a basis of our lattice that has vectors with a small enough norm to comply with

Coppersmith's condition.

[ 𝑇 ] [ 𝐵 ] = [ 𝐵 𝑡 ] ,
where 𝐵 𝑡 is the transformed matrix. We call it "transformed" rather than "reduced" since it is not 𝐿𝐿𝐿-reduced and a simple check (performed here for the sake of completeness but not in actual code) with the is_LLL_reduced function of fpLLL immediately confirms it. But, as it has been written in different occasions, it is not 𝐿𝐿𝐿-reduction per se that interests us but short-norm vectors.

We leave now the realm of the reduction (or transformation acceleration) to look at another optimization possibility. We have often referred to the Coppersmith condition as the pythonissa that blessed or cursed our short-norm vectors candidates. But can we challenge the form we gave it in our initial presentation in §3.3.7, p. 164 to improve the efficency? The assumption here is that among these polynomials we will find more non trivial common factor free pairs and that we will be able to avoid some interval splitting, speeding up the whole process.

But, probably due to the peculiar shape of the polynomials we use, and after many tests, the All timings are in seconds (with commas as thousands separator). The header's definitions, for the not so obvious ones, are as follows:

• HTRN: tested hardness-to-round to nearest, in bits, given here as a multiple of precision 𝑝 = 113;

• #floats: the count of 113-bit floating-point numbers included in the searched interval;

• Min. r. t.: minimum time spent in a reduction;

• Max. r. t.: ditto, for the maximum time;

• Avg. r. t.: average time for one reduction;

• total r. t.: total time spent in reductions;

• total t.: total time spent in search;

• #iter.: the number of iteration (reductions) to span all the interval; some of them end up in failures (not enough polynomials nor any valid pairs). We analyze here our second set of results obtained with an the improved transformation technique described in §3.8.3, p. 228. In general terms, these results are, from a practical perspective, a powerful stimulus to persist in the optimization tracks we are on. At the same time, at a more conceptual level, they rise more issues than they solve.

For our 10𝑝 experiments and specifically for the higher degrees, we run our tests for the maximal interval width for which we did not incur a failure in non-trivial common factor free polynomial

The vanished time drift

This remark may seem of anecdotal interest but we think it can be put at use to discover the reason for this phenomenon. This allows to discard the hypothesis of a steady accumulation of "friction" in the SageMath runtime even if we do not have any alternative explanation yet.

Confirmation of the "sweet spot" effect

We witness the same kind of behavior with this second set of data, even it is not as sharp was with the first set. This probably indicates that our previous observations are not an artifact generated by our reduction process but probably reveal a more profound property of the lattice basis, even if we are not able to characterize it yet.

Our present lack of clues certainly relates to our flawed knowledge about what the underlying structure of the problem is. This shortcoming has already emerged in different occasions: lattice building rules, optimal choice of parameters, etc. One possible extension of this work is to gather more and more precise, empirical data, thanks to the existing implementation, in order to figure out how what is actually going on here.

Other conserved trends

For one, the ease to explore the higher hardness-to-round receives a second confirmation since, this time, we have timings for 10𝑝. In the listed results the effect is not as striking that for the 6𝑝 to 8𝑝 transition, but is still visible (a factor 2). A possible explanation is also that the transition from 6𝑝 to 8𝑝 is proportionally larger than that from 8𝑝 to 10𝑝.

Another conserved trend is that pertaining higher degrees. For a given value of constant 𝛼, the gains in interval width obtained thanks to a better approximation accuracy with higher-degree polynomials are more than outbalanced by the failures in non-trivial common factor free polynomial pairs search. Losses in execution time occasioned by the growth of lattice basis data size worsen the picture. In some tests for 10𝑝 we even witnessed a kind of regressive behavior. For instance, for a polynomial degree in 46 or 47 (not reported in our tables) and with 𝛼 = 10, we could not cover a 2 93 -floating-point-numbers interval with a single iteration while it was done with a polynomial in degree 45 and with the same value for 𝛼.

A new target: Optimize in other areas

The results of the first set of data focused our attention on the reduction step. As can be seen with the second set, lattice basis transformation "only" represents from 2/3 to 3/4 of all the execution time. This means that other parts of the implementation deserve now our optimization zeal.

While not shown in our data, resultants computation and roots finding grab most of the remaining execution time. This opens several paths in this realm:

• use more effective implementations than those presently available in SageMath;

• use different algorithms (as, for instance, Hensel lifting, see [START_REF] Zur Gathen | Modern Computer Algebra[END_REF], Chap. 15, instead of resultants).

More generally, now that lattice basis transformation optimization is a less obsessive matter, all other up to now neglected enhancement trails may require our attention.

3.9.6 When do we get there?

From the timings and the interval width we can try to figure out how long it takes to cover a complete binade. We think that a single but full binade processing time is the right metric to judge on the practicability of the exploration. For a full function domain, many parts can be dealt with in such a way that we never have to run the 𝑆𝐿𝑍-algorithm for them. But their size differs from function to function.

3.9.6.1 Not all the binades always have to be explored

In our case for instance, with the function exp(𝑥) and binary128 format, the situation is depicted in Figure 3-11. It turns out that only 258 fbinades need to be explored out of the 65534 that the full domain comprises (a reduction factor of 254!).

Computing fantasies

As it goes, and using our best performing parameters (hardness-to-round checked = 10𝑝, 𝛼 = 10, degree = 45, number of floating point numbers per interval = 2 93 ), the exploration of a full binade would take 66 years on a single of our E5-2695 cores. Nevertheless one can easily break this task in a set of embarrassingly parallel jobs that can be simultaneously run on the adequate infrastructure.

As of April 2016, the top500 [START_REF] Meuer | top500 Supercomputercomputing Sites[END_REF] first ranking supercomputer is the Chinese Tianhe-2 (MilkyWay-2). It has as much as 32,000 Intel R ○Xeon R ○E5-2692 @ 2.2GHz and 48,000 Intel R ○Xeon Phi TM 31S1P @ 1.1GHz processors. These amount to 3,120,000 cores.

Under the (mildly optimistic) hypothesis that these cores would fare as well as the ones we tested with, and the ludicrous one that we could borrow it in full from its present users (and provided we could master the beast), we could obtain the following throughput:

• single binade exploration: the timing is lower bounded by that of the exploration of a single interval (as it has been seen, splitting to smaller intervals is a waste of resources); in our example it would take 1.1 h but using only 524,288 of the 3,120,000 cores;

• full function exp(𝑥) exploration: it would take a bit less than 2 days (a bit more than 17,000 core × year);

• full generic worst-case function exploration (without any binade elimination): a bit less than 1.4 year (around 4, 319, 895 core × year).

Back to Real World

A large part of the hardest-to-round cases output from the work performed by V. Lefèvre were computed in our lab, over years, on a set of servers and desktops whose total core count amounts to about 500. These computers are not fully dedicated to that task: a scheduler gathers the computing time of unused cores for low priority jobs, such as those that search for hard-to-round cases. There are many different processor models (even if they are all 64-bit) in this infrastructure and the ones we used to set our own timings are among the fastest available.

Neglecting all these details and assuming we have 500 powerful cores at hand, exploring a single binade would take about 1, 150 hours, (48 days). Checking for the full exp(𝑥) function, would require 34 years of computations and for a generic (without binade elimination, a very unlikely situation though) function, one should have the patience to wait 8, 639 years.

We must imagine a better than 3 optimization factor (by taking full advantage of all the above proposed leads?) and a 5, 000-core cluster (a 6 to 7 full racks set and for an about 2, 500, 000 e price tag with commodity hardware) to be able to perform the checking of the exp(𝑥) function in a single year.

No animals were harmed during the experiments

But no hard-to-round cases were found either. . . which was expected!

Conclusion

As a Table Maker's Dilemma solver, the 𝑆𝐿𝑍-algorithm fits in the category of (enhanced) exhaustive search methods. It shares this characteristic with the 𝐿-algorithm. Scorn is not the point here, far from it. Both algorithms rely on much more smart ideas and clever methods than the mere enumeration of the floating-point numbers. The implementation of the 𝐿-algorithm by V. Lefèvre has given important fruits: complete lists of hard-to-round cases for that are actually used [START_REF]CRLlibm[END_REF] for correctly rounded implementations of elementary functions. This long-run effort is still in progress nowadays.

The results presented in this work are the first for the 6𝑝 to 10 hardness-to-round bracket for the exp(𝑥) function. The fact that this exploration is not totally out of our reach is not, despite of our reluctance to admit it, a trivial result.

The ultimate question in debate here is can exhaustive search methods, even in sophisticated clothing, stand the hit on the violent combinatorial explosion of the problem in binary128? If one compares with binary64, one must remember that it is not only the number of floating-point numbers in each binade that balloons to unprecedented levels (from 2 52 from 2 112 ) but that this problem is made worse by the widely increased exponent range (from 2, 047 fbinades to 32, 767) even if, as we have seen for the function exp(𝑥), the actual number of fbinades can be squeezed to more tractable levels.

The present work has tried to investigate this question. The answer it gives, though encouraging, is not absolutely conclusive:

• we cannot infer from our current results that exploration is impossible; there are still what we have called "second line" optimizations that can be introduced and while we cannot expect time reduction factors as dramatic as those obtained with projection, even single-digit integer divisors would improve very much the practicability of the exploration;

• our timings based on the availability of Tianhe-2 are a bit unfair and provocative; such an infrastructure will never be devoted to this kind of investigation, however important we may think it is; (but) even building or borrowing more modest (but still a very powerful one, as sketched above) platforms dedicated to this task is hard to imagine nowadays;

• resorting to, as once envisioned, volunteer computing and other kinds of lightweight computation units aggregation would require a deep rewrite of the implementation (what may be needed anyway) in order to alleviate or fully remove the burdening dependencies computing nodes have over huge pieces of software (SageMath, essentially, but also Sollya, fpLLL and the luggage they carry along with them).

There are still too many misunderstood issues. To name a few:

• the rules of optimal initial basis construction for a given polynomial pattern;

• a clear and detailed understanding of the relationship between the main parameters of the method (𝛼, the polynomial degree, the precision, the target hardness-to-round);

• what can be done, if at all, and gained with a more aggressive reduction of the precision of the coefficients.

All these questions have to be examined at an operational level. In other words, for values of the parameters that can be used in actual computations. This involves extensive experimentation and mathematical advances as well.

One could also question the use of an 𝐿𝐿𝐿-algorithm implementation as a black box. As D. Stehlé suggests himself in [START_REF] Stehlé | Floating-point lll: Theoretical and practical aspects[END_REF], adapting the implementation of the 𝐿𝐿𝐿-algorithm (we should more accurately speak now of a family of algorithms) to a particular type of input can be a rewarding move. He also opens more general options for the improvement of the 𝐿𝐿𝐿-algorithm implementations at large.

But we can also ask ourselves if this effort is worth it. Is the order of magnitude of the gain one can expect from the above suggested improvements enough to make the method actually usable in practice and at what cost? Are there not other routes that should be explored? Did Mathematics speak their last word with the works of Y. Nesterenko and M. Waldschmidt? These questions are still open and we hope that in the forthcoming years they will receive the attention their practical, and possibly theoretical, importance deserves.

  int main ( int argc , char ** argv ) m _ o n e _ d i f f _ o n e D o t O n e _ o n e = 0.0; d i f f _ o n e D o t O n e _ o n e = oneDotOne -one ; sum_one_oOne = one + oOne ; s u m _ o n e _ d i f f _ o n e D o t O n e _ o n e = one + d i f f _ o n e D o t O n e _ o n e ; if ( d i f f _ o n e D o t O n e _ o n e != oOne ) { fprintf ( stdout , "(1.1 -1) != 0.1\ n "); if ( oneDotOne == sum_one_oOne ) { fprintf ( stdout , "(1.1 -1) != 0.1 but 1.1 == 1 + 0.1\ n "); if ( s u m _ o n e _ d i f f _ o n e D o t O n e _ o n e == sum_one_oOne ) { fprintf ( stdout , "(1.1 -1) != 0.1 but (1 + (1.1 -1)) == (1 + 0.1)\ n ");

  The integer is represented by a string of digits of a preliminarily specified length. It is called the integral significand 7 . It will be denoted by 𝑀 . Its possible values are the set of integers spanned by the available digits. To represent fractional values or values larger than the maximum integer, a scaling factor is applied: the rational number. A floating-point system specifies, among other things, what are these factors made of through a number of parameters.

  (𝑎)) = 0.11000111001110111101000010001100010100011000010010101 RU(𝑓 (𝑎)) = 0.11000111001110111101000010001100010100011000010010110

Figure 1 - 8 :

 18 Figure 1-8: In this figure 𝑌 , 𝑌 + and midpoint(𝑌, 𝑌 + ) are the same as in Fig-ure1-6. This figure is a possible sequel to Figure1-7 where function 𝑓 is now approximated by a machine computable function ̂𝑓(1) with an error 𝜖/2. This function is more accurate than the previously used ̂ 𝑓 (𝑥). The computed value

Definition 1 . 8 (

 18 Weil's height). Let 𝛼 be an algebraic number of degree 𝑑 and 𝑃 (𝑥) = 𝑑 ∑ 𝑖=0 𝑃 𝑖 𝑥 𝑖 be its minimal polynomial. Let 𝑃 (𝑥) = 𝑃 𝑑 × 𝑑 ∏ 𝑖=0

  [START_REF] Graillat | Error-free transformation in rounding mode toward zero[END_REF][66][START_REF] Ogita | Accurate sum and dot product[END_REF][84][91][90] other than those already cited have developed such error free algorithms. The introduction of the FMA instruction has strongly stimulated this kind of research.

Figure 2 - 2 :

 22 Figure 2-2: 𝑦 can't be a midpoint nor beyond it: correct rounding is possible.

Figure 2 - 7 :

 27 Figure 2-7: We are in the second case mentioned in the proof of Property 2.1:(𝑦 ℎ + 𝑦 ℓ ) 𝑦 ℎ 𝑦, if 𝑦 ℎ > 0 and 𝑦 ℓ 0.In this situation, 𝑦 can only live in the "𝑦 permitted segment". Hence, and despite a large value of 𝜖, 𝑦 ℎ = RN(𝑦).

Figure 2 - 9 :

 29 Figure 2-9: Both ends of the positive binade 2 𝑘 in precision-𝑝 (referenced as the 𝐾 𝑝 binade) are represented here. The value of the ulp() function is constant among the members 𝑋 of this binade and equal to 2 𝑘-𝑝+1 . If we define 𝜉 as ulp(𝑋) = 𝜉 × 𝑋 × 2 -𝑝 , its possible values are 2, for the first element (2 𝑘 ) of the binade and almost 1 for the last element (2 𝑘+1 -2 𝑘-𝑝+1 ), with a set of intermediate values in between.

Figure 2 - 10 : 1 . 1 2

 21011 Figure 2-10: 𝑦 ℎ is a power of 2. Here 𝑦 𝑦 ℎ 0 and 𝑦 ℓ 0. Remember 𝑒 1. In the depicted situation 𝑦 -𝑦 ℎ 1 2 ulp(𝑦 ℎ ) hence 𝑦 ℎ = RN(𝑦).We also have: if(𝑦 ℎ = RN(𝑦 ℎ + RN(𝑦 ℓ × 𝑒)) 𝑡ℎ𝑒𝑛 𝑦 ℎ 𝑦 ℎ + RN(𝑦 ℓ × 𝑒)𝑦 ℎ + 1 2 ulp(𝑦 ℎ ).

Property 2 . 9 .

 29 If 𝑝 ∈ {11, 24, 53, 64, 113}, and 𝜖 = 𝛾 × 2 -𝑝-𝑘 , with 𝛾 = 1< 𝑒 * + ulp(𝑒 * ).

Figure 2 - 12 :

 212 Figure 2-12: We have here three examples of a situation where Ziv's test has failed and we were able to compute 𝑓 -1

Figure 3 - 1 :

 31 Figure 3-1: Hard-to-round cases for the function 𝑓 happen when its graph hits one of the small vertical bars place on the dotted grid.

- 1

 1 at the same time, as on Figure 3-2. The extra horizontal bars represent now the threshold for the reciprocal function. Here, 𝑓 -1 (𝑌 2 ) can possibly be problematic.

Figure 3 - 2 :

 32 Figure 3-2: We can consider both the function 𝑓 and its reciprocal with a new "square" grid.

Figure 3 -

 3 Figure3-3 illustrates this last formulation. We have a regular square grid, where, in abscissa,

Figure 3 - 3 :

 33 Figure 3-3: Hard-to-round cases search reformulated as the search of values of frac(𝑏 -𝑎𝑘) smaller than a bound depending on the investigated hardness to round.

a c b 0 Figure 3 - 5 :

 035 Figure 3-5: While [𝑎, 𝑏] domain of 𝑓 (𝑥) is contained in single binade, 𝑓 ([𝑎, 𝑏]) spans several ones. Both 𝑓 (𝑎) and 𝑓 (𝑏) belong to the same binade, and yet 𝑓 (𝑐) belongs to a different one.

  Image binade splitting:nothing to do here.

Figure 3 - 6 :

 36 Figure 3-6: Domain and image splitting.The domain and image splitting according, first, to monotonicity, and then to the binade spanning of both the domain and the image.

𝑚→𝑛(

  𝑥) the scaling from the 𝑚-fbinade to the 𝑛-fbinade. With this definition, 𝑠𝑐𝑎𝑙𝑒 0→𝑘 (𝑥) maps all the elements of the 0-fbinade to those of the 𝑘-binade, as does 𝑠𝑐𝑎𝑙𝑒 ℓ→0 (𝑥) for all the elements of the ℓ-binade to those of the 0-fbinade. From function 𝑓 (𝑥), that computes images from the 𝑘-binade into the ℓ-binade, let us define a new function 𝑔 : 0-binade → 0-binade as:

Theorem 3. 2 .

 2 Suppose that function 𝑔 : R ↦ -→ R is 𝑛 + 1 times differentiable on interval [𝑎, 𝑥] and that 𝑅 𝑛,𝑎 (𝑥) is defined by𝑔(𝑥) = 𝑔(𝑎) + 𝑔 ′ (𝑎)(𝑥 -𝑎) + . . . + 𝑔 (𝑛) (𝑎) 𝑛! + 𝑅 𝑛,𝑎 (𝑥). (3.6) Then 𝑅 𝑛,𝑎 (𝑥) = 𝑔 (𝑛+1) (𝑡) 𝑛! (𝑥 -𝑡) 𝑛 (𝑥 -𝑎) for some 𝑡 ∈ (𝑎, 𝑥), 𝑅 𝑛,𝑎 (𝑥) = 𝑔 (𝑛+1) (𝑡) (𝑛 + 1)! (𝑥 -𝑎) 𝑛+1 for some 𝑡 ∈ (𝑎, 𝑥). Moreover, if 𝑔 (𝑛+1) is integrable on [𝑎, 𝑥], then 𝑅 𝑛,𝑎 (𝑥) = ∫ 𝑥 𝑎 𝑔 (𝑛+1) (𝑡) 𝑛! (𝑥 -𝑡) 𝑛 d𝑡.Expression 3.6 is often called Taylor's Formula. The 𝑔(𝑎) + 𝑔 ′ (𝑎)(𝑥-𝑎) + . . . + 𝑔 (𝑛) (𝑎) 𝑛! expression is called the Taylor polynomial of degree 𝑛 for 𝑔(𝑥) at 𝑎. The 𝑅 𝑛,𝑎 (𝑥) expression is called the remainder. The three above forms of the remainder are respectively called Cauchy, Lagrange and integral form. With a simple change of variable 𝑥 = 𝑎 + ℎ we can obtain the following form of Taylor's formula

  Let ℎ(𝑖, 𝑡) = ∑ 𝜌,𝜎 𝑎 𝜌,𝜎 𝑖 𝜌 𝑡 𝜎 . Assume that the polynomial ℎ(𝑖, 𝑡) ∈ Z[𝑖, 𝑡] is a sum of, at most, 𝑤 monomials. Let us define: Definition 3.1. ‖ℎ(𝑖, 𝑡)‖ 2 := ∑ 𝜌,𝜎 𝑎 2 𝜌,𝜎 . Theorem 3.3. Suppose that: 1. ℎ(𝑖 0 , 𝑡 0 ) mod 𝒩 = 0 where |𝑖 0 | < 𝐼 and |𝑡 0 | < 𝑇 (𝐼 and 𝑇 are some positive integer constants), and 2. ‖ℎ(𝑖𝐼, 𝑡𝑇 )‖ < 𝒩 √ 𝑤 .

Theorem 3. 4 .

 4 If (𝑏 * 1 , . . . , 𝑏 * 𝑚 ) is the result of the Gram-Schmidt orthogonalization of (𝑏 1 , . . . , 𝑏 𝑚 ) and 𝐿 is the lattice generated by (𝑏 1 , . . . , 𝑏 𝑚 ), then vol(𝐿) = 𝑚 ∏ 𝑖=1 ||𝑏 * 𝑖 ||.

Theorem 3. 7 ,

 7 so is Z[𝑥]. In our problem, we have bivariate polynomials in Z[𝑥, 𝑦]. They can be viewed as polynomials in Z[𝑥][𝑦] that is to say polynomials in 𝑦 with coefficients in Z[𝑥]. They also be viewed as polynomials in 𝑥 with coefficients in Z[𝑦].

4 16 , 5 16 (

 1616 a subset of the -2-fbinade) and those in 1, 5 4 (a subset of the 0-fbinade) by a 4-scaling up.

- 9 .

 9 The first (square-dotted line, almost horizontal) is the scaled function used for binade -2. The second (ball-dotted line, canted) is used for binade 8 (notice that the plot of this function was largely offset down in order to get both plots side by side and observe them on the same figure). Functions used in other binades, as presented in Table3.5, would plot as almost straight lines but with increasing slopes as the binade index grows.Contrarily to what pops up at first sight, these plots are not straight lines but slightly bent curves. Intuitively, a degree-17 polynomial has a much harder time at sticking to the curvature of the scaled exp(𝑥) function and at dealing with the (relatively) high difference in image values from the beginning to the end of the interval, all at the same time (as in ball-dotted line plot), than dealing with the curvature alone (as in the square-dotted line plot). This is peculiar to the exp(𝑥) function, where the value of the derivative increases towards positive values. The situation would be different with some other function, but the problem remains the same.

Figure 3 - 9 :

 39 Figure 3-9: The ball-dotted line is the plot of the scaled exp(𝑥) function in a small portion of the 8-binade. The square-dotted is the plot of the scaled exp function in an equivalent portion of the -2-binade.

  the matrix with a combination of the following methods with increasing precision. Then, runs the proved version with the default precision. The floatType must be FT_DEFAULT and precision must be 0. The result is guaranteed. LM_PROVED Proved method. Uses integers to compute dot products. The result is guaranteed if floatType=FT_DEFAULT/FT_MPFR and pre-cision=0 (see above). LM_HEURISTIC Heuristic method. Uses floating-point numbers to compute dot products. The result is not guaranteed. It is more efficient that the proved version when the coefficients of the input are large (the threshold depends on the floating-point type and precision). LM_FAST Same as LM_HEURISTIC with floatType=FT_DOUBLE, with a special trick to handle larger inputs. Next, about floating-point number types (FP_DOUBLE and FT_MPFR are self-explanatory) in relation to methods:

2 .

 2 𝑅(𝑦) is derived from 𝑃 (𝑦). How can this be done in order to satisfy the final conditions on |𝑔(𝑥) -𝑅(𝑦)| [𝑎,𝑏] |? More precisely, what are the conditions on 𝑃 (𝑦) and 𝑅(𝑦) that make it possible? Since |𝑔(𝑥) -𝑃 (𝑦)| |𝑔(𝑥) -𝑃 (𝑦)| + |𝑃 (𝑦) -𝑅(𝑦)|, an obvious and acceptable choice is

Figure 3 - 10 :

 310 Figure 3-10: Starting from a uniform 1024 bit size, the coefficients of the test polynomial in degree 17 are rounded to the presented values.

3. 6 . 2 . 1

 621 Initial data precision: 𝑝 = 53 hardness-to-round: 𝑚 = 𝑝 + 10 = 63 approximation polynomial accuracy: 2 -𝑚-1 < 2.7105054312137610850186320𝑒 -20 approximation polynomial hardness-to-round: 𝑚 + 1 ): 𝑢𝑙𝑝𝑖𝑐 = 2 -53+1 interval width in ulpic: 𝑖𝑤𝑢 = 2 9 𝑢𝑙𝑝𝑖𝑐 → [𝑖𝑐 -2 8 𝑢𝑙𝑝𝑖𝑐, 𝑖𝑐 + 2 8 𝑢𝑙𝑝𝑖𝑐] lower bound: 𝑙𝑏 = 1.49999999999994315658113919198513031005859375 upper bound: 𝑢𝑏 = 1.50000000000005684341886080801486968994140625 Sollya internal pecision: 𝑝𝑟𝑒𝑐 = 192 bits.

𝑃 9 / 16 𝑖 2 208

 9162 𝑠𝑎,𝑟𝑟 (𝑖) = 10334071412308445887/9223372036854775808 + 18357/16384 𝑖 + Chapter 3. Coppersmith's Method and the TMD: An implementation of the SLZ-algorithm.

2

 2 If we want to check the accuracy of the approximation, we have to use the following variable change: 𝑥 (for 𝑔(𝑥)) ↦ → 𝑦 = (𝑥 -𝑖𝑐)/𝑢𝑙𝑝𝑖𝑐 (for 𝑃 (𝑦))

𝑄 0, 0

 0 (𝑖, 𝑡) = 1298074214633706907132624082305024 𝑄 1,0 (𝑖, 𝑡) = 332306998946228968225951765070086144 𝑖 𝑄

  𝜎 𝑖 𝜌 𝑡 𝜎 ⃒ ⃒ ⃒ ∑ |ℎ 𝜌,𝜎 | |𝑖 𝜌 | |𝑡 𝜎 | ∑ |ℎ 𝜌,𝜎 | 𝐼 𝜌 𝑇 𝜎 = |ℎ(𝑖𝐼, 𝑡𝑇 ), |ℎ(𝑖 0 , 𝑡 0 )| |ℎ(𝑖𝐼, 𝑡𝑇 )| < 𝒩 (from our initial conditions).Hence|ℎ(𝑖 0 , 𝑡 0 )| < 𝒩 Since ℎ(𝑖 0 , 𝑡 0 ) = 0 mod 𝒩 .We eventually have ℎ(𝑖 0 , 𝑡 0 ) = 0.3.8.4.2 How well does this condition behave in our case?What is expected from this new condition (|ℎ(𝑖𝐼, 𝑡𝑇 )| < 𝒩 ) is that |ℎ(𝑖𝐼, 𝑡𝑇 )| will be smaller than ||ℎ(𝑖𝐼, 𝑡𝑇 )|| √ 𝑤 in order to filter out more polynomials.

Figure 3 - 11 :

 311 Figure 3-11: The top line indicates the value of the image of the elements of the bottom line domain by the exp(𝑥) function. Only gray shaded domain intervals need to be checked for hard-to-round cases. The boundaries of the domain intervals where all the elements have a constant image (0, 1, +∞) do not coincide with binades limits. For instance, the value of exp(𝑥) transitions to +∞ "somewhere" in 15-fbinade. Hence, at least some part of this fbinade should be explored. Strictly speaking the actual extremal boundaries of the domain are one floating-point number short of those indicated on the figure.

  Matrix generated by polynomials build according to D. Stehlé modified rules. The matrix is not square any more and a different technique is used to get, at least, an upper bound on the lattice determinant. . . . . . . . . . . . . . . . . . . . . . . . . . 3.5 Approximation error for the exp function by degree-17 in several binades, for intervals holding 2 80 floating-point numbers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.6 Matrix generated by polynomials for the exp function at point 𝑎. . . . . . . . . . . . LIST OF TABLES 3.10 SLZ experimental results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.11 SLZ experimental results cont'd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.12 SLZ experimental results cont'd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.13 SLZ experimental results cont'd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.14 SLZ experimental results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.15 SLZ experimental results cont'd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.16 SLZ experimental results cont'd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.17 SLZ experimental results cont'd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.18 SLZ experimental results cont'd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.1 Some results for several functions and small values in the double-precision/IEEE-binary64 format. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2 Results of our experiments, for 𝜖 ∈ (2 -81 , 2 -55 ]. . . . . . . . . . . . . . . . . . . . . 2.3 Results of our experiments, for 𝜖 ∈ (2 -81 , 2 -55 ]. . . . . . . . . . . . . . . . . . . . . 2.4 Accurate (𝑒 * ) and simplified (𝑒 𝑛𝑒𝑎𝑟𝑒𝑠𝑡 𝑠𝑖𝑚𝑝𝑙𝑒 ) bounds comparison . . . . . . . . . . . . . . . 3.1 List of polynomials obtained with D. Boneh and G. Durfee's first set of rules for 𝛼 = 3 and 𝑆 = 1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2 Matrix generated by polynomials of Table 3.1. Going from one polynomial to the next introduces only one new monomial. Hence the matrix is square and lower triangular. Computing its determinant is very easy: all we need to care about are the elements on the main diagonal. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3 Matrix generated from polynomials built according to the SLZ given rules. Going from one polynomial to the next introduces only one new monomial. Once again, the matrix is square and lower triangular. Computing its determinant is very easy: all we need to care about are the elements on the main diagonal. . . . . . . . . . . . . . 3.4 3.7 Matrix generated by polynomials for the exp function at point 𝑏. . . . . . . . . . . . 3.8 Matrix generated by polynomials for the exp function at point 𝑏 as derived from that at point 𝑎. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.9 Reduction of execution time with cutback of Taylor approximation polynomial coefficients initial binary size. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

  Table Maker's Dilemma 2 .

  𝐴 and 𝐵, has been devised with the help of FMA. Provided the product 𝐴 × 𝐵 does not overflow and 𝑒 𝐴 + 𝑒 𝐵 𝑒 min + 𝑝 -1, where 𝑒 𝐴 and 𝑒 𝐵 are the exponents of 𝐴 and 𝐵, Algorithm 1 computes their exact product as the unevaluated sum of two floating-point numbers 𝑌 1 and 𝑌 2 . 𝑌 2 is the exact difference between 𝐴 × 𝐵 and 𝑌 1 . */ return 𝑌 1 , 𝑌 2 end function

	new possibilities were opened and old problems or processes could be revisited with opportunities
	for improvement.
	For instance a strikingly short and improved version of the Dekker's multiplication algorithm (see
	Algorithm 4, p. 72) used, under some conditions, to compute the exact product of two floating-point
	numbers, Algorithm 1 2MultFMA Algorithm
	/* Assume a binary floating-point system F 𝛽,𝑝,𝑒𝑚𝑖𝑛,𝑒𝑚𝑎𝑥 and */
	/* that the conditions on exponents and overflow are met. */
	function 2MultFMA(𝐴, 𝐵)
	𝑌 1	← RN(𝐴 × 𝐵)
	𝑌 2	← RN(𝐴 × 𝐵 -𝑌 1 )
	/*
		the instruction made it to the IEEE 754 standard, in its 2008 version, it was specified with
	the single terminal rounding. The standard did not consider the different variants: what matters to
	is the single and final rounding.
	This specification caught much attention among the numerical computing specialists. It was
	quickly discovered that, beyond the prosaic idea that the lesser the rounding, the better the result,

  𝑛

  -5: In this figure 𝑌 denotes a floating-point number, 𝑌 -its predecessor, 𝑌 + its successor in F; midpoint(𝑌 -, 𝑌 ) and midpoint(𝑌, 𝑌 + ) are rational numbers equal to (𝑌 -+ 𝑌 ) / 2 and (𝑌 + 𝑌 + ) / 2 which are not elements of F. The function 𝑓 is approximated, for some floating-point argument 𝑥, by a machine computable function f with an error 𝜖. Here, f (𝑥) can exactly be represented by floating-point number 𝑌 . Does f (𝑥) require rounding? Cannot we just say RN(𝑓 (𝑥)) = 𝑌 ? With such a large value for 𝜖 (more than half ulp( f (𝑥))), one has to think twice before returning 𝑌 .

In this figure 𝑌 , 𝑌 + and midpoint(𝑌, 𝑌 + ) are the same as in Figure1- 6. Function 𝑓 is approximated, for some floating-point argument 𝑥, by

   In this figure 𝑌 denotes a floating-point, number 𝑌 + its successor in F and midpoint(𝑌, 𝑌 + ) a rational number equal to (𝑌 + 𝑌 + ) / 2, which is not an element of F. Function 𝑓 is approximated, for some floating-point argument 𝑥, by a machine computable function f with an error 𝜖.

	The computed value
	f (𝑥) is a rational number that has to be rounded (even if it can be represented
	by a floating-point number, as seen above). Notice that while we know that 𝑓 (𝑥)
	has to be "somewhere" in the [ ̂ 𝑓 (𝑥) -𝜖, f (𝑥) + 𝜖] interval we have no clue as to
	its exact whereabouts. Nevertheless correct rounding is possible here to value
	𝑌 .
	Figure 1-7: a machine
	computable function ̂ 𝑓 with an error 𝜖. The computed value ̂ 𝑓 (𝑥) clearly has
	to be rounded. Again, if 𝑓 (𝑥) has to be "somewhere" in the [ ̂ 𝑓 (𝑥) -𝜖, ̂ 𝑓 (𝑥) + 𝜖]
	interval, we have no idea as to where it actually lives. But this time the interval
	encompasses midpoint(𝑌, 𝑌 + ). Correct rounding is not possible.

Table Maker

 Maker

	's Dilemma (TMD).

  the closeness of the values of function 𝑓 to midpoints. Similarly, other peculiar sequences can be described for the closeness to breakpoints for other rounding modes. This conditions the accuracy that ̂ 𝑓 (𝑥) approximants should have in relation to 𝑓 (𝑥) to be able to correctly round it. 𝑦 0 .𝑦 1 . . .) and that of this closest midpoint (𝜇 0 .𝜇 1 . . . 𝜇 𝑝 ) there exists

	Put in another way, we compute 𝑓 (𝑋), 𝑋 ∈ F (or a subdomain of F) either:
	1. 𝑓 (𝑋) is a midpoint of F;
	2. 𝑓 (𝑋) has one (if next to the bounds) or two neighboring midpoints.
	In the latter case, 𝑓 (𝑋) has a closest midpoint neighbor (we can pick any of the two neighboring
	midpoints if 𝑓 (𝑋) has an exact floating-point value). If we consider the normalized significands
	of 𝑓 (𝑋) (possibly infinite :

  -𝑘0 . Of course, this is also true for our peculiar "100 . . . 001" and "011 . . . 110" strings of interest. Hence, if we consider a set of 𝑁 floating-point elements of F (or an interval within it) the number of their image by 𝑓 having any particular sequence of 𝑘 0 bits starting at position 𝑝 is 𝑁 × 2 -𝑘0 . As soon a 𝑘 0 grows larger than log 2 (𝑁 ), this number of occurrences becomes fractional. It means that such a situation should seldom happen. Furthermore, there is a relationship between 𝑁 and 𝑝. For instance the number of elements of a binade in precision 𝑝 is 2 𝑝 . In this context the 𝑘 0 tipping point above which the number of occurrences becomes fractional is 𝑘 0 = 𝑝. For F in full the number of elements 𝑁 ≈ 2 𝑝 × 2(𝑒 max -𝑒 min ) + 2. So much for 𝑘 0 .The interest of theses relations between 𝑁 , 𝑘 0 , and the number of occurrences is that it makes it possible to test (not to prove, we lightheartedly concede it) how well this model does in Real World.

  𝑌 ℎ ← RN(𝐴 × 𝐵) /* From now on, compute the correcting term: subtract from the inexact value 𝑌 ℎ the four */ /* exact "cross terms" computed as when using the school-grade multiplication algorithm to

and 𝑌 2 ∈ F Algorithm 4 Dekker's multiplication algorithm /* Assume a binary floating-point system F 𝛽,𝑝,𝑒𝑚𝑖𝑛,𝑒𝑚𝑎𝑥 and */ /* that the four conditions in main text are met. */ function DekkerMult(𝐴, 𝐵) Require: 𝑠 == ⌈ p/2 ⌉ /* Split the two arguments so that the "halves" can be exactly "cross multiplied". */ (𝐴 ℎ , 𝐴 ℓ ) ← Split(𝐴, 𝑠) (𝐵 ℎ , 𝐵 ℓ ) ← Split(𝐵, 𝑠) /* Compute the main term: a "quick and dirty", possibly inexact, approximation for 𝐴 × 𝐵. */ */ /* perform 𝐴 × 𝐵 as (𝐴 ℎ , 𝐴 ℓ ) × (𝐵 ℎ , 𝐵 ℓ ). Intermediate computations values are all exact */ /* under the condition 𝑒 𝐴 + 𝑒 𝐵 𝑒 min

  .2.3, p. 71.

	Algorithm 6 Compensated Horner's algorithm

/* 𝑝 is a floating-point coefficient polynomial evaluated for floating-point argument 𝑥. */ function CompHorner(𝑝, 𝑥) /* EFTHorner is a custom version of Horner's algorithm that uses error-free transformations */ /* and returns a value r (the main term) and two new polynomials, 𝑝 𝜋 and 𝑝 𝜎 . */ /* These polynomials convey the information needed to compute a correcting term. */ [r, 𝑝 𝜋 , 𝑝 𝜎 ] ← EFTHorner(𝑝, 𝑥) /* ĉ (the correcting term) is computed by applying the classic Horner's algorithm on */ /* polynomial RN(𝑝 𝜋 + 𝑝 𝜎 ) and 𝑥. */ ĉ ← Horner(RN(𝑝 𝜋 + 𝑝 𝜎 ), 𝑥) /* Eventually, the result is computed as the rounded sum of r and ĉ. */ r ← RN(r + ĉ) return r end function

  7 , ℎ 𝜖 ′ (𝑥), such that 𝜖 ′ < 𝜖. Should we fall in the second situation again, another attempt would be made with an even better accuracy 𝜖 ′′ , such that 𝜖 ′′ < 𝜖 ′ , and so forth, until a final (𝑦 ℎ 𝑓 𝑖𝑛𝑎𝑙 , 𝑦 ℓ 𝑓 𝑖𝑛𝑎𝑙 ) pair is computed from which we can safely conclude 8 that 𝑦 ℎ 𝑓 𝑖𝑛𝑎𝑙 = RN(𝑦).

Figure 2-3: 𝑦 can be a midpoint or beyond it: correct rounding is impossible.

Equivalent figures could be drawn should the signs of 𝑦 ℎ and 𝑦 ℓ be both negative.

The problem can become quite intricate if, more realistically, we allow for different signs for 𝑦 ℎ and 𝑦 ℓ , and even worse, if 𝑦 ℎ is a power of 2, as in Figure

2-4

. Here Condition 2.2 can't anymore be restated as |𝑦 ℓ | < 1 2 ulp(𝑦 ℎ ). It takes at least |𝑦 ℓ | 1 4

7

  Correct rounding test 1 /* 𝑦 is the exact value of 𝑓 (𝑋), 𝑋 ∈ 𝒟 𝑟 . */ /* (𝑦 ℎ , 𝑦 ℓ ) is a pair of numbers computed to approximate 𝑦. */ /* 𝜖 is the relative error of the approximation. */ Require: 𝑦 × (1 -𝜖) < 𝑦 ℎ + 𝑦 ℓ < 𝑦 × (1 + 𝜖) /* (by definition of the relative error) */ Require: 𝑦 ℎ = RN(𝑦 ℎ + 𝑦𝑙) /* 𝑦𝑠𝑙 is the "y segment length".

*/ 𝑦𝑠𝑙 ← 2𝜖 × 𝑦 if 𝑦 ℎ == RN(𝑦 ℎ + RN(𝑦 ℓ + 𝑦𝑠𝑙)) then True else False end if

  Correct rounding test 2 /* 𝑦 is the exact value of 𝑓 (𝑋), 𝑥 ∈ 𝒟 𝑟 . */ /* (𝑦 ℎ , 𝑦 ℓ ) is a pair of numbers computed to approximate 𝑦. */ /* 𝜖 is the relative approximation error. */ Require: 𝑦 × (1 -𝜖) < 𝑦 ℎ + 𝑦 ℓ < 𝑦 × (1 + 𝜖) /* (by definition of the relative error) */ Require: 𝑦 ℎ

𝑦); Algorithm 8

  More informally stated, under Property 2.8 hypothesis, 𝑒 𝑢𝑝 𝑠𝑖𝑚𝑝𝑙𝑒 is a safe (no false positives) and good (very close to) approximation of 𝑒 * .

-𝑝-3 . Property 2.8. If 𝜖 2 -𝑝-3 and 1 -2 𝑝+1 𝜖 is exactly representable (see above for a more precise statement) then 𝑒 𝑢𝑝 𝑠𝑖𝑚𝑝𝑙𝑒 𝑒 * and 𝑒 𝑢𝑝 𝑠𝑖𝑚𝑝𝑙𝑒 𝑒 * < 1 + 4 × 2 -𝑝 = 1 + 2 ulp(1).

Table 2 .

 2

	Example 1

3 provides a handful of examples of failures at 𝑒 = 𝑒 * -2 -31 . ℎ = 1.9802155978993843 𝑦 ℓ = 1.1102230085276806 × 10 -16 𝜖 = 8.2224179116152375 × -25

Table 2 .

 2

3: Results of our experiments, for 𝜖 ∈ (2 -81 , 2 -55 ].

2.7.4 How do the simplified and the accurate formulas for 𝑒 compare in practice?

Table 2 .

 2 .This is a limited annoyance since, as can be found up from §2.7.2, p. 128, in this approximation accuracy interval the test is far from pertinent (all our corner cases are "negative", but that could also happen for many of the more "conventional" cases).

	Again, these experiments do not fill the void of the absence of proof. Nevertheless they foster our
	intuition about the validity of the simplified bound.
	Maximum relative error	𝑒 𝑛𝑒𝑎𝑟𝑒𝑠𝑡 𝑠𝑖𝑚𝑝𝑙𝑒 -𝑒 * 𝑒 *	2.2204460492339477 × 10 -16
	𝑒 𝑛𝑒𝑎𝑟𝑒𝑠𝑡 𝑠𝑖𝑚𝑝𝑙𝑒 = 𝑒 * cases		1 514 615 533
	Total number of cases		3 500 000 000

4 displays the results of some tests done in the IEEE-binary64 format, for approximation accuracy bounds varying from 2 -56 to 2 -90 . Notice that in all the aforementioned developments, we have considered 𝜖 2 -𝑝-2 . In this context we should start at 2 -55 . But when 𝜖 ∈ (2 -56 , 2 -55 ] we have found many instances where 𝑒 𝑛𝑒𝑎𝑟𝑒𝑠𝑡 𝑠𝑖𝑚𝑝𝑙𝑒 𝑒 *

Table 2 .

 2

4: Accurate (𝑒 * ) and simplified (𝑒 𝑛𝑒𝑎𝑟𝑒𝑠𝑡 𝑠𝑖𝑚𝑝𝑙𝑒 ) bounds comparison

  Eventually a very high accuracy (and possibly very expensive to compute) approximation (with an accuracy in the 2 -8𝑝 -2 -12𝑝 range) that would be (hopefully) seldom, if ever, called, should the first two fail. The question of the implementation technique of this last step is left open to debate: should one use an arbitrary precision library as MPFR or create from scratch a dedicated high precision computing framework?That is mainly what we are trying to do here: work out an implementation of SLZ that would allow us to check values in the 2 6𝑝 to 2 12𝑝 hardness-to-round bracket.

-(2𝑝 + 𝑎_𝑠𝑚𝑎𝑙𝑙_𝑓 𝑟𝑎𝑐𝑡𝑖𝑜𝑛_𝑜𝑓 _𝑝) accuracy (that, from our probabilistic model, should work most of the time) but it would be more expensive to compute. It corresponds, more or less, to the "slow phase" of an implementation in 53-bit precision since the actually known hard-to-round cases for this format are all in this precision frame.

  1. the [𝑎, 𝑏] interval is closed and bounded; 2. the function 𝑔(𝑥) is continuous over this interval.In turn, these conditions can rise new issues. For the first one, we must remark that we are only interested in approximations over bounded intervals (we do not care about what happens beyond the minimum and the maximum numerical values represented in F) and we can always have closed intervals of interest with floating-point (rational) numbers. So the condition always holds. For the second, if 𝑔(𝑥) is at least piecewise continuous, the solution is extra splitting into subdomains where the function is continuous.

Table 3 .

 3 3: Matrix generated from polynomials built according to the SLZ given rules. Going from one polynomial to the next introduces only one new monomial. Once again, the matrix is square and lower triangular. Computing its determinant is very easy: all we need to care about are the elements on the main diagonal. The considered i -shifts are now those, for some constant 𝛼 ∈ N 27 such that 𝑖𝑠 𝑟,𝑢 (𝑖, 𝑡) = 𝑖 𝑟 𝑄(𝑖, 𝑡) 𝑢 𝒩 𝛼-𝑢 , where 0 𝑟 + 𝑢 𝛼.

	Retaining the original monomials list of length	(𝛼 + 1)(𝑑𝛼 + 2) 2	, he proposed in [100] a different
	polynomial construction rule.

Table 3 .

 3 4: Matrix generated by polynomials build according to D. Stehlé modified rules. The matrix is not square any more and a different technique is used to get, at least, an upper bound on the lattice determinant.The reasons that explain this modified basis building rule are similar in principle, if technically different, to those used by D. Boneh and G. Durfee. The details can be found in[START_REF] Stehlé | On the randomness of bits generated by sufficiently smooth functions[END_REF] as Theorem 2; its proof is in the Appendices of the article. At some point D. Stehlé remarks that his polynomial/basis building rule does not allow, when applied to D. Boneh and G. Durfee's problem, for the same effectiveness. In fact, building rules are very problem-dependent. Up to the date there is no general model that, for a given problem, allows one to derive the optimal initial basis building rules.

  1 8 . The only real constant here is the number of floating-point numbers that are represented.

	It come as no surprise that the approximation of the scaled functions behaves differently even
	if it is performed over the same interval,	[ 1, 5 4	] , just as much as the approximation of the exp(𝑥)
	function behaves differently in	[ 4 16 , 5 16	]	and in	[ 4 8 , 5 8

  .5.

	Binade Approx. error	Binade Approx. error
	-3	1.61e-211	3	5.38e-179
	-2	5.10e-206	4	1.75e-173
	-1	9.73e-201	5	3.54e-168
	0	2.69e-195	6	1.10e-162
	1	7.93e-190	7	4.09e-157
	2	2.61e-184	8	1.07e-151
	Table 3.5: Approximation error for the exp func-
	tion by degree-17 in several binades, for intervals
	holding 2 80 floating-point numbers.

  have a variable (in this case, decreasing) interval width, if sticking to degree-17 is what matters most to us. None of them is fully satisfactory. Changing degrees may involve changing the value of 𝛼 if one wants a minimal reduction time (see §3.7), p. 219. It probably requires some experimental tweaking, what we do not really want. Changing the interval width is not necessarily a smart move. As will be seen, it can be more expensive to scan through several short intervals than to process a larger one that contains them all. 3.5.3.2 A special case: the exp(𝑥) function on a single binade

  .9.

	Execution time ratio (rounded/non-rounded)	0.25
	Maximum vector L 2 norm ratio (rounded/non-rounded)	0.67
	Mean vector element size ratio (rounded/non-rounded)	0.70
	Maximum vector size ratio (rounded/non-rounded)	0.66
	Table 3.9: Reduction of execution time with cutback of Taylor
	approximation polynomial coefficients initial binary size.

  2 is a 4-bit number despite the fact it is represented, in the initial conversion, by a 64-bit precision floating-point number. 𝑃 𝑠𝑎,𝑓 𝑓

	denotes the floating-point coefficients (first f) polynomial for floating-point arguments (second f) in
	SageMath.
	𝑃 𝑠𝑎,𝑓 𝑓 (𝑖) =	1.12042226758451621
		+ 1.12042236328125000 𝑖
		+ 0.562500000000000000 𝑖 2

  𝑚+1 terms are integral, since, as we remember, 𝑠𝑐𝑎𝑙𝑖𝑛𝑔_𝑓 𝑎𝑐𝑡𝑜𝑟 is the least common multiple of a list of numbers that includes 2 𝑝 and 2 𝑚+1 . In our algorithm de-

	The 2 scription we denoted 2 𝐾 = 𝑠𝑐𝑎𝑙𝑖𝑛𝑔_𝑓 𝑎𝑐𝑡𝑜𝑟 2 𝑝 𝑠𝑐𝑎𝑙𝑖𝑛𝑔_𝑓 𝑎𝑐𝑡𝑜𝑟 and 𝑠𝑐𝑎𝑙𝑖𝑛𝑔_𝑓 𝑎𝑐𝑡𝑜𝑟 2 𝑝	and 2 𝑘 =	𝑠𝑐𝑎𝑙𝑖𝑛𝑔_𝑓 𝑎𝑐𝑡𝑜𝑟 2 𝑚+1

𝑚+1

.

Table 3 .

 3 HTRN Degree 𝛼 #floats Min. r. t. Max. r. t. Avg. r. t.• #iter.: the number of iteration (reductions) to span all the interval; some of them end up in failures (not enough polynomials nor any valid pairs). 11: Main experimental results with binary128 (cont'd). Headings and conventions are the same as in Table3.10.

	total r. t.	total t.	#iter.

All timings are in seconds (with commas as thousands separator). The header's definitions, for the not so obvious ones, are as follows:

• HTRN: tested hardness-to-round to nearest, in bits, given here as a multiple of precision 𝑝 = 113;

• #floats: the count of 113-bit floating-point numbers included in the searched interval;

• Min. r. t.: minimum time spent in a reduction;

• Max. r. t.: ditto, for the maximum time;

• Avg. r. t.: average time for one reduction;

• total r. t.: total time spent in reductions;

• total t.: total time spent in search;

Table 3 .

 3 13: Main experimental results with binary128 (cont'd). Headings and conventions are the same as in Table 3.10.

Table 3 .

 3 |ℎ(𝑖𝐼, 𝑡𝑇 )| < ||ℎ(𝑖𝐼, 𝑡𝑇 )|| √ 𝑤 condition was never satisfied. Since our interval splitting policy is very aggressive (division by 2 when not enough condition compliant polynomials are found) we did not notice any real difference in overall execution time. Using what happens to be a more stringent condition did not cause extra splitting. It eventually happened as often with both conditions. It also remains to be seen, when the |ℎ(𝑖𝐼, 𝑡𝑇 )| < ||ℎ(𝑖𝐼, 𝑡𝑇 )|| √ 𝑤 condition stands and more polynomials are filtered out, if we can find, among those, pairs of non trivial common factor free ones. If no such pairs are found, as already explained, all we can do is shrink the interval and run a new iteration. It turns out that what is gained at Coppersmith's condition checking stage could be lost at the roots finding one. In other words, does the use of a different condition affect the "quality" 𝛼 #floats Min. r. t. Max. r. t. Avg. r. t. 14: Main experimental results with binary128 with floating-point numbers intervals centered on 3/8.

	total r. t.	total t.	#iter.

of the selected polynomials?

Unfortunately we cannot answer this question since our test cases never gave us a chance to investigate it. But this does not imply that there is no point, in other contexts, in using this HTRN Degree

Table 3 .

 3 HTRN Degree 𝛼 #floats Min. r. t. Max. r. t. Avg. r. t. Crashes after about 48 hours spent in computations, with 2 64.5 floats intervals. 15: Main experimental results with binary128 (cont'd). Headings and conventions are the same as in Table 3.14. HTRN Degree 𝛼 #floats Min. r. t. Max. r. t. Avg. r. t.

	total r. t.	total t.	#iter.

Table 3 .

 3 16: Main experimental results with binary128 (cont'd). Headings and conventions are the same as in Table 3.14. HTRN Degree 𝛼 #floats Min. r. t. Max. r. t. Avg. r. t.

	total r. t.	total t.	#iter.

Table 3 .

 3 17: Main experimental results with binary128 (cont'd). Headings and conventions are the same as in Table 3.14. HTRN Degree 𝛼 #floats Min. r. t. Max. r. t. Avg. r. t.

	total r. t.	total t.	#iter.

Table 3 .

 3 18: Main experimental results with binary128 (cont'd). Headings and conventions are the same as in Table 3.14.

Named after Abraham Ziv.

Named after Vincent Lefèvre, Damien Stehlé and Paul Zimmermann.

Sollya[START_REF] Chevillard | 'agit d'un outil pour aider au développement de code sûr utilisant la virgule flottante. Il dispose, en particulier, d'une norme infinie certifiée et d'une implantation libre de l'algorithme de Remez[END_REF] is an ad hoc designed tool for handling numerical functions and working with arbitrary precision. It is extensively used in our implementation for approximation and infinity norm computations.

SageMath[START_REF]Sage: Open source mathematics software[END_REF] is a free open-source computer algebra system.

We do not mean to refute, passing, the sacrosanct Curry-Howard correspondence. The only problem is that if actual programs are mathematical proofs, those, very often, have little to do with what the developer has in mind.

An object we can only probe by giving it an argument and getting the output image, without any knowledge of its inner workings.

In a meeting with CERN scientists working on numerical efficiency, they reported us that they found out, after instrumenting some pieces of code, that 30 % of the computing time was spent in elementary functions. Of course this result should not be overgeneralized but considered anyway as valuable hint on elementary functions impact and importance.

The "Floating-point system" expression is also frequently used.

Other presentations are possible: see[START_REF] Gustafson | The End of Error: Unum Computing[END_REF]. We stick to the "classical" one here.

Clarification about significands is just below.

As will be seen there can be several (𝑀 𝑖 , 𝑒 𝑖 ) pairs that represent the same floating-point number 𝑋. That is why we cannot speak here about "the" exponent of 𝑋.

For instance a sharp cutoff effect for values smaller than the smallest normalized number that can be brutally flushed to 0 at rounding. To mitigate this issue, subnormal numbers had to be introduced for very small values, adding an unwelcomed level of complexity to the system.

This also justifies the "integral" adjective when is comes to 𝑀 as a significand.

Accurately, the mantissa of a non-negative number is the fractional part of its logarithm.

Without generating a trap (i.e. a transfer of control to some handler routine).

This is also true for subnormal numbers.

If 𝑌 is in the normal range, then 𝜖 ′ = 0; If 𝑌 is a subnormal number, then 𝜖 = 0.

We would have gladly provided references to early documents but, unfortunately, the works of Hipparchus of Nicaea (c.190 -c.120 BCE) and Menelaus of Alexandria (c.70 -140 CE) dubbed as the first authors of trigonometric tables, did not make it to present time.

We make here an important change in notation. To the point 𝑚 was used for significands. From now on it will denote hardness-to-round.

Access to exponents and their comparison is more tricky than direct comparison of numbers.

Under certain circumstances there can be two of them.

In the sense of different from the special values -∞ and +∞. No surreptitious smuggle in of a new kind of floating-point numbers on sight!

In the sense that the polynomial can be stored in a reasonable amount of memory space and evaluated in a reasonable time span.

We assume here, for the sake of simplicity, that both the domain and the image are subsets of the same floatingpoint system F.

2 see[START_REF] Jeannerod | Midpoints and exact points of some algebraic functions in floating-point arithmetic[END_REF] for a discussion when midpoints are subnormal

numbers.3 We assume here that ∀ 𝑋 ∈ D𝑟, 𝑔 (𝑋) ̸ = 0. If not so, further refinement and/or splitting must be

done on D𝑟.[START_REF] Bailey | [END_REF] where D𝑟 = [𝑎, 𝑏] ⋂ F.

with 𝑘 > 1 to allow for a fast enough decrease of the error to make the new attempt worth it.

It suffices to consider instead 𝑦 ′ ℎ and 𝑦 ′ ℓ such that (𝑦 ′ ℎ , 𝑦 ′ ℓ ) = Fast2Sum(𝑦 ℎ , 𝑦 ℓ ).

It can use the same algorithm but with a better accuracy.

We optimistically assume here that the cases where 𝑓 (𝑋) is exactly a midpoint of F have been dealt with beforehand.

Well, or could subtract, depending on the sign of 𝑦 ℓ !

Indeed, other issues such as the TableMakerDilemma may make it necessary to approximate 𝑦 with much smaller relative errors

Quotes are necessary here since one has to remember that the ulp() function is fully specified only in the context of a floating-point system. Here, we deal with the blurry 𝑦 ℎ + 𝑦 ℓ unevaluated sum object.

At least in the realm of numerical and/or high-performance computing but presently also in mobile processors as the recent ARM Cortex series.

Notice, passing, that arbitrary precision libraries do not mimic the exact behavior of binary128 when precision is set to 113 bits since, for instance, they do not have the same exponent range or lack support of subnormal numbers.

In particular, we gave Sollya a very hard try. We had to put down the process running Sollya after 12 636 minutes (near 9 days), at the point where, using over 82 GB of memory and still ballooning, it was about to trigger the system into swapping.

For some functions, as explained in the introduction, §1.6.3.1, p. 58, no image is a rational number (e.g. exp(𝑥)). For others we assume some way can be devised to get rid of them. As we will see 𝑆𝐿𝑍-algorithm could also catch these cases but if there were overwhelmingly many of them they could jam the algorithm. Hence trying to spot them beforehand is still a good option.

For the largest midpoint, 𝑋 ∈ F ∩ [1, 2) while 𝑋 + / ∈ F ∩ [1, 2).

The algorithm returns a more precise answer than " Well, there is one or several 𝑋 out there for which |𝑓 (𝑋) -𝜇| < 1 2 ̃ 𝑚 ".

A particular and different structure also exists when 𝑎 ∈ Q but we are more interested in the 𝑎 ∈ R ∖ Q case.

We could want to have an image in different floating-point system. Conceptually, it would not make any difference, at the cost of limited, but terse, notations adaptations.

An almost unbearable abuse of language since we speak of a possibly infinite string of digits (for 𝑓 (𝑥 𝑘 )) and a "significand" written in 𝑝 + 1 digits for the midpoints!

Another abuse of language here. Of course, the domain of 𝑃 (𝑥) may not be the full binade, we spent enough time in splitting to be well aware of that. The same is true for the image, but it does not change anything here and acting this way helps to keep notations more legible. Also notice that, with a (too) low accuracy approximation, we could

𝑝-1 , 2 𝑝 -1 2 𝑝-1 , 𝑃 (𝑋) / ∈ 0-binade.

In fact the optimal polynomial with a degree lower or equal to 𝑑.

We prefer not to speak of a basis here since the set of vectors produced by the orthogonalization process is not basis of the 𝐿 lattice.

When res𝑡(𝑄 𝑗 (𝑖, 𝑡), 𝑄 𝑘 (𝑖, 𝑡)) ̸ = 0 we also have the following inclusions chain: roots (|𝑥 0 |<𝐼) (𝑄(𝑖, 𝑡)) ⊆ roots𝑥 0 (𝑄 𝑗 (𝑖, 𝑡), 𝑄 𝑘 (𝑖, 𝑡)) ⊆ roots𝑥 0 (res𝑡(𝑄 𝑗 (𝑖, 𝑡), 𝑄 𝑘 (𝑖, 𝑡))).

Notice that 𝑑, the degree of 𝑄(𝑖, 𝑡) in 𝑖, does not show up anymore in the formula.

The exact location in the binade does not especially matter here, but we had to pick the same one for each binade to make the comparison meaningful.

We refer here to code written by an application developer, not SageMath code itself

84 208,762 208,762 208,762 208,762 209,117 1 Table

3.12: Main experimental results with binary128 (cont'd). Headings and conventions are the same as in Table3.10.

In the sense that they yield short-norm vectors and those are free from non-trivial common factor.

We resist the temptation of using the term projector here since it has precise technical meaning that does not fit with what the matrix 𝑃 actually is.

For each value 𝜖 we pick:

• one random 𝑦 ℎ ∈ [1, 2);

• one random 𝑦 ℓ ∈ [ 15 32 ulp(𝑦 ℎ ), 16 32 ulp(𝑦 ℎ )

] .

The results are presented in Table 2 For the largest values of 𝜖, the values of 𝑒 are so large that the test fails systematically (yielding 𝑄(𝑖, 𝑡) mod 2 𝐾 = 0 for 𝑖 ∈ 𝑟𝑙, 𝑟𝑢 and 𝑡 ∈ -2 𝑘 , 2 𝑘 .

In order to have the problem fully specified, we finally set the 𝐼 and 𝑇 constants as : 𝐼 = max(-𝑟𝑙, 𝑟𝑢) (recall 𝑟𝑙 < 0 < 𝑟𝑢) and 𝑇 = 2 𝑘 .

How are we going to generate polynomials of a sufficiently small norm? This where the 𝐿𝐿𝐿algorithm comes into play.

Connecting the 𝐿𝐿𝐿-algorithm to our problem

While we use the 𝐿𝐿𝐿-algorithm essentially as a "black box" under the form of the fpLLL implementation [START_REF] Albrecht | fplll-4.0, a floating-point LLL implementation[END_REF], we feel it necessary to give here a few indications of what it does and of what are the main parameters involved in the reduction operation which is central to solve our problem.

A quick reminder about lattices

We will not dwell on lattices at large. We will only expose basic definitions and facts needed to solve our problem.

Definition 3.2. A lattice 𝐿 is the set of all integral linear combinations of a family of 𝑚 𝑛 linearly independent vectors b 𝑖 ∈ R 𝑛 :

The vectors b 𝑖 are often referred to as a basis of 𝐿. The dimension of the lattice dim(𝐿), is 𝑚 (the number of vectors in the basis). Its degree, deg(𝐿), is 𝑛 (the dimension of each vector). When the degree and the dimension match, the lattice is said full-dimensional. Obviously, the degree of the lattice 𝐿 cannot be smaller than its dimension.

As soon as 𝑚 2, a lattice can be generated by an infinite number of different bases.

The previous definition can formulated under a matrix form:

The lattice generated by B is the set:

The tools of the trade

We will first introduce the tools used for the implementation since some of its peculiarities are related with the features (and lack thereof) of the tools.

3.6.1.1 Sollya [START_REF] Chevillard | Sollya[END_REF] This is our first tool. The simplest and most accurate description is found in the introduction to the reference manual:

Sollya is an interactive tool for handling numerical functions and working with arbitrary precision. It can evaluate functions accurately, compute polynomial approximations of functions, automatically implement polynomials for use in math libraries, plot functions, compute infinity norms, etc. Sollya is also a full-featured script programming language with support for procedures etc.

As it will be seen, it is mainly used here for its ability to compute polynomial approximations as Taylor forms (approximation errors are provided as well) and infinite norms. The second interesting trait is that most of the features of Sollya are also available through calls to a C language library which allows us to harness it to other tools. Besides, it is free software and is continuously enhanced by three researchers who are very active in the realm of approximation at large and who use it for their own research. A wider, if small yet, community of users is building around the tool.

fpLLL

The implementation of the 𝐿𝐿𝐿-algorithm we use is fpLLL [START_REF] Albrecht | fplll-4.0, a floating-point LLL implementation[END_REF] This incarnation of the 𝐿𝐿𝐿-algorithm is disseminated as a C language library. Thanks to this format it can also be called from other tools.

As such, it is one of the two default implementations of the 𝐿𝐿𝐿-algorithm in SageMath.

Its other outstanding feature is very good performance. As reductions are to be performed very often and take the lion's share of computing time in this implementation this aspect cannot be overlooked.

Besides 𝐿𝐿𝐿-reduction, fpLLL offers another reduction algorithm, BKZ, and a function for the computation of the shortest nonzero vector of a lattice. A set of data type templates are also provided to allow for the manipulation different types (e.g. different integer types) in a uniform way.

In fact, state-of-the art libraries do not expose a function that performs "the" 𝐿𝐿𝐿-algorithm.

For one, using floating-point numbers is a departure from original 𝐿𝐿𝐿-algorithm. For two, even in this realm, innovation has constantly been popping up, notably Schnorr-Euchner's (both proved [START_REF] Schnorr | A more efficient algorithm for lattice basis reduction[END_REF], As fpLLL is invoked from SageMath, one has to check the arguments provided in this environment.

Indeed SageMath offers a choice between the fpLLL methods and an alternative implementation from Victor Shoup's NTL [START_REF] Shoup | NTL: A Library for Doing Number Theory[END_REF].

We invoke fpLLL with the default parameters in SageMath which correspond to LM_WRAPPER and FT_DEFAULT. This method is dubbed a "Thoughtful Wrapper" as it relieves the user from the burden of selecting and transitioning between variants. What end-users (as we characterize ourselves in this implementation) want here is the execution to terminate and to return a good quality answer.

It is not an easy task when it is to be done the proper way (i.e. trying to speed up things when it is possible and not unconditionally following a safe but slow route). It involves making use of heuristics, detecting and interpreting misbehavior that may happen in such a way that the cheapest variant that is likely to safely work is picked.

Important notice about LLL

From 𝐿𝐿𝐿-algorithm analysis (as in D. Stehlé's work [START_REF] Stehlé | Floating-point lll: Theoretical and practical aspects[END_REF]), one should not overlook the fact that the bit-complexity of the algorithm is not only bound to the dimension of lattice basis. It also depends on the bit size of input (see §3. Together these reasons explain why SageMath was picked as the integration platform all along this project.

All together now!

As explained above, the integration of fpLLL to SageMath had already been realized by the authors of the former. What was missing yet was an access to Sollya from SageMath. An important effort was devoted to this task. While publicly available [START_REF] Torres | PoBySo: Powered By Sollya, Python-Sage bindings[END_REF], this is still a work in progress or even a draft since only we concentrated on the part that was absolutely needed for this work: large parts remain to be coded for a complete binding. Hence the existing wrapper cannot be considered yet as a full integration of Sollya. Completing it (probably at the cost of a full rewrite taking into account the gathered experience) is future work and our experience with Sollya power harnessed to SageMath has convinced us that it would be worth the effort. Many developers in SageMath but also in Python could benefit from this work. It could also offer a wider audience to Sollya thanks the momentum SageMath is picking up.

Close shaved polynomials look nicer

The 𝐿𝐿𝐿-algorithm complexity depends on multiple factors. In the initial A. K. Lenstra and al.

article [START_REF] Lenstra | Factoring polynomials with rational coefficients[END_REF] the complexity of the algorithm is upper bounded by 𝑂(𝑛 4 log 𝐵) arithmetic operations on integers of binary length 𝑂(𝑛 log 𝐵) where

• 𝑛 is the number of vectors in the lattice basis

• 𝐵 is the maximum of the 𝐿 2 norms of the vectors of the input matrix.

Which gives a total complexity of 𝑂(𝑛 6 log 3 𝐵) of bit operations.

Better bounds may have been obtained with new variants of the algorithm and/or for special cases, but these data give an idea of the execution time dependency on the input data size. Since basis reduction grabs the largest, by far, share of overall execution time, all legitimate transformations on input data that have a favorable impact are definitely welcome. We have already seen in our discussion about the initial basis ( §3.5.2, p. 178) how dropping some vectors that add not much value kills two birds with one stone:

• get a lattice with a smaller average volume;

• reduce the lattice dimension.

The first allows generically for shorter-norm vectors in the output basis. The second makes reductions quicker. But as can be clearly seen in the above formula, vectors bit size has also a large

For the record, the other computed data are:

With the same variable change as before, but this time dividing the output of 𝑃 𝑠𝑎,𝑖𝑖 by 𝑠𝑐𝑎𝑙𝑖𝑛𝑔_𝑓 𝑎𝑐𝑡𝑜𝑟 (hence the variable name), we can still check the quality of the approximation accuracy:

No change, nor surprise. At this point we want to solve the modular equation:

We are now ready to create the family of polynomials used to build the basis of lattice 𝐿 that will be input into an 𝐿𝐿𝐿-algorithm implementation for reduction.

Creating polynomials for a lattice basis

The choice of the polynomial set is very important, as discussed in §3.5.2, p. 178. We use here the selection proposed by D. Stehlé in his PhD thesis [START_REF] Stehlé | Algorithmique de la réduction de réseaux et application à la recherche de pires cas pour l'arrondi de fonctions mathématiques[END_REF] and his 2006 article [START_REF] Stehlé | On the randomness of bits generated by sufficiently smooth functions[END_REF].

We remind here that we set the 𝛼 parameter to 2, essentially here for legibility reasons .

We compute here all the polynomials such that:

We obtain the following list of polynomials:

We filter out all the row vectors that match the condition. Here, 2 vectors out of 6 successfully take the test. With these "winner row vectors" (and only these), we are going to build back polynomials.

Again, numbers are too large to be output here.

Polynomials (re)building

We can first built "raw polynomial" 𝑅𝑟𝑎𝑤 𝑚 (𝑖, 𝑡) using the 𝑚-th row 𝑟 𝑚 of the reduced matrix as follows:

The second step, to produce 𝑅 𝑚 (𝑖, 𝑡) "reduced polynomials", is to remove 𝑖𝐵𝑜𝑢𝑛𝑑 and 𝑡𝐵𝑜𝑢𝑛𝑑 from the 𝑅𝑟𝑎𝑤 𝑚 (𝑖, 𝑡) polynomials.

It is simply performed by making the following changes of variables: The last step differs from that of the Gram matrix reduction technique. Whereas the transformation matrix obtained in this case allowed for the computation of an actually 𝐿𝐿𝐿-reduced basis, this is not the case anymore with 𝑇 : 𝑏 𝑡 is not guaranteed to be 𝐿𝐿𝐿-reduced anymore. But as expressed in different occasions, we are not interested in 𝐿𝐿𝐿-reduction per se. All we want are short-norm vectors in the basis.

But wait a minute, how can we ensure that 𝑏 𝑡 is a basis and that it defines the same lattice as the one defined by the basis 𝑏?

More reminders on lattices

The above question forces us to extend a bit our reminders. As they we only be used here, will feel it relevant to introduce them only at this point of our exposition. Let us start with a classical definition and lemma.

A classical result is the following lemma.

Lemma 3.10. If 𝑈 ∈ Z 𝑚×𝑚 is unimodular, then 𝑈 -1 is also unimodular.

Saying that 𝑈 -1 is unimodular also conveys the idea that 𝑈 -1 ∈ Z 𝑚×𝑚 .

A more lattice-specific and also classical result is the following lemma.

Lemma 3.11. Let two matrices 𝐵 1 and 𝐵 2 derive respectively from the two bases 𝑏 1 and 𝑏 2 . They define the same lattice 𝐿, if and only if 𝐵 1 = 𝑈 × 𝐵 2 for some unimodular matrix 𝑈 .

But then two other issues immediately pop up:

• how do we pick the elements of the projecting matrix 𝑃 (beyond our intention to have small bit-sized elements)?

• are 𝐵 𝑝 and the 𝐿𝐿𝐿-reduction of 𝐵 𝑝 relevant to our problem with the basis 𝐵?

3.8.3.4 How do we use the results of A. Akhavi and D. Stehlé?

Our starting point is the situation we are in after §3.7:

• our timings are unbearably long;

• 𝐿𝐿𝐿-reduction is not an end but a mean to get short-norm vectors.

We see the A. Akhavi and D. Stehlé proposition as a possible option that, given their experimental results, deserve more than a casual try in order to exit from the performance pit were stuck in.

Of course we have taken into account their analysis about complexity and the quality of the transformed basis. On the latter we have also noticed that, in the available form of the paper which is dubbed as "an extended abstract", continuous random models are used and that the full analysis involving the effect of quantization is left for the "full version".

We then use their method as an oracle to obtain a basis with some short-norm vectors.

We validate afterward the obtained data with our own criteria:

• as for the complexity: the actual improvement in timings;

• as for the quality of the basis: our yardstick is the Coppersmith condition.

Building a random projecting matrix

What is proposed in [START_REF] Akhavi | Speeding-up Lattice Reduction with Random Projections[END_REF] is several probabilistic models to pick the elements of the projecting matrix 𝑃 . We will not enter into more details about these models here.

This discussion would have been relevant for us if one model had shown a clear advantage over the others. This is not the case in the experimental results presented in [START_REF] Akhavi | Speeding-up Lattice Reduction with Random Projections[END_REF].

We have picked for our own tests two simple models:

• one where the elements of the matrix a uniformly and independently picked from {-1, 1};

Changing the Coppersmith condition

What we are going to deal with now cannot be strictly aggregated under the umbrella of the acceleration of operations on lattice basis. But it is so strongly connected to this question and pertains so tightly to the enhancements to the algorithm topic that we feel it relevant to discuss it here.

This implementation is based on Theorem 3.3. We have used it to obtain the experimental results given below. Nevertheless, as has been seen in our detailed example, the bounds given are not absolutely tight since we could find a hard to round case outside the interval is was supposed to live in. We claim here that, under the above listed conditions, if |ℎ(𝑖𝐼, 𝑡𝑇 )| < 𝒩 then ℎ(𝑖 0 , 𝑡 0 ) = 0 also stands over the integers.

Proof. We start from the same point as for the proof of Theorem 3.3 but quickly fork to a different modified condition. To the moment, we consider it as an open option. When using the Coppersmith method, one may give it a try and check if, in her case, this condition gives better results (more "interesting" polynomials) than the "classical one".

Projection in action: a second set of experimental results

This second set is computed using projection as explained in §3.8.3. The conditions are otherwise identical (platform, function exp(𝑥)) as those under which our initial data were observed.

The experimental area has been extended since, from the quicker execution time, we had the opportunity to explore a broader parameter space. We could lead to a normal ending computations that collapsed in our first test round.

The projection technique has also allowed for the completion of some extra computations that systematically failed without it (10𝑝 and over).

Two sets of results are listed in Table 3.14 through Table 3.18.

pairs search. When this kind of failure happens, we have to split the interval and run our search on the sub-intervals. This situation calls for the following comments:

• we have noticed that when an experiment is run with a set of parameters that force interval splitting, we can find a different set of parameters that, either, avoids it entirely or runs faster on the sub-interval; in both cases the aggregated time is smaller;

• we also experienced lots of unexplained program crashes when interval splitting was involved;

this is peculiar to 10𝑝 experiments and does not happen in 8𝑝 or 6𝑝 or only if a very large number (> 1000) of intervals is involved.

Substantially reduced lattice basis transformation timings

We speak here about lattice basis transformation and not reduction since, as noted, the obtained basis is not necessarily 𝐿𝐿𝐿-reduced. Reduction in transformation timings is of course the most striking difference between the two sets of data. This decrease can amount to a factor 300 in most favorable cases (for a hardness-to-round of 8𝑝). It could perhaps have been even larger if we had been able to succeed in the "full" 𝐿𝐿𝐿-reductions for hardness-to-round 10𝑝.

Decreasing the time transformation of the lattice is good but not at any price. How do the vectors obtained after transformation compare with those we get after a "regular" 𝐿𝐿𝐿-reduction?

As a matter of fact our tests show that most of the time (above 99 %) the transformed matrix provides us with polynomials whose quality is comparable (in terms of failures to comply with Coppersmith's condition) with those the 𝐿𝐿𝐿-reduction outputs. While performing a full 𝐿𝐿𝐿-reduction of the transformed matrix is relatively quick we do not find it very helpful.

Most of the time, when the first transformation fails, performing the full 𝐿𝐿𝐿-reduction does not provide us with the vectors we need. It turns out that, instead of stubbornly persevering with the current attempt, it is better to give up and to immediately split the interval and work on the two subintervals.

This performance enhancement has many consequences that will be detailed in subsequent sections. The most outstanding one is that it takes us to the verge of considering that the exploration in the initial hardness-to-round bracket we have considered (6𝑝 to 12𝑝) is practically doable.

BIBLIOGRAPHY

Sept. 1991. http://dl.acm.org/citation.cfm?id=114697.116813&coll=DL&dl=ACM&CFID= 453974937&CFTOKEN=40298601.