On Mon, Dec 14, 2015 at 7:25 AM, Michael Paquier
<michael.paquier@gmail.com> wrote:
> On Mon, Nov 9, 2015 at 6:46 AM, Robert Haas <robertmhaas@gmail.com> wrote:
>> On Sat, Nov 7, 2015 at 2:45 AM, Fabien COELHO <coelho@cri.ensmp.fr> wrote:
>>> After looking at the generated html version, I find that the "1/param" and
>>> "2/param" formula are very simple and pretty easy to read, and they would
>>> not be really enhanced with additional spacing.
>>>
>>> ISTM that adaptative spacing (no spacing for level 1 operations, some for
>>> higher level) is a good approach for readability, ie:
>>>
>>> f(i) - f(i+1)
>>> ^ no spacing here
>>> ^ some spacing here
>>>
>>> So I would suggest to keep the submitted version, unless this is a blocker.
>>
>> Well, I think with the ".0" version it looks more like floating-point
>> math, and I like the extra white-space. But I'm happy to hear other
>> opinions.
>
> - defined as <literal>(max + min) / 2.0</>, then value <replaceable>i</>
> + defined as <literal>(max+min)/2</>, with
> This thing reminds me a bit of the little of TeX I know, when writing
> things like "\sqrt{1-e^2}" spaces would be printed in the converted
> html, and as that's floating arythmetic, we should have as well a .0.
> So I would agree on both points with Robert.
>
> I have looked for now at the first patch and finished with the
> attached while looking at it. Perhaps a committer could look already
> at that?
It looks fine to me except that I think we should spell out "param" as
"parameter" throughout, instead of abbreviating.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company