ffc team mailing list archive

[Martin Sandve Alnæs <martinal@xxxxxxxxx>]

On 6 July 2011 14:44, Kristian Ølgaard <k.b.oelgaard@xxxxxxxxx> wrote:
> On 6 July 2011 13:17, Garth N. Wells <gnw20@xxxxxxxxx> wrote:
>> FFC can generated *very* large files with the tensor contraction
>> approach, especially when auxiliary problems like error estimation are
>> used. This makes compilation slow, and possibly fail.
>>
>> The array A in the generated code often has a lot of zeroes. Would it be
>> sensible to
>>
>> 1. Initialise A to zero and then fill non-zero entries
>>
>>  // Initialise (size is known at runtime, so compiler can optimise)
>>  for (unsigned int i = 0; i < size; ++i)
>>      A[i] = 0.0;
>>
>>  // Nonzero terms of in
>>  A[0]  = 1.0;
>>  A[22] = 2.0;
>>  A[23] = 1.0;
>
> Yes.
>
>>
>> 2. Format floating point numbers for compactness, e.g.
>>
>>  A[0] = 0.0;
>>  A[1] = 1.0;
>>
>> instead of
>>
>>  A[0] = 0.00000000000;
>>  A[1] = 1.00000000000;
>
> I think Martin recently changed the formatting of floats in UFL to
> achieve this for the signatures.
> We can do the same for floats in the code, although I don't know if it
> will have implications with respect to the regression tests?
> We currently lower the precision when running the tests to make it
> work across multiple platforms, versions of Python etc. but this is
> perhaps easy to adopt in the new format?
>
> Kristian

ufl.format_float(x) currently does this:

("%%.%dg" % precision) % x

alternatively you can use this for full precision:

repr(x)

The %g formatter with no precision gives less than double precision:

In [24]: repr(1.000000000000023)
Out[24]: '1.000000000000023'

In [25]: repr(.000000000000023)
Out[25]: '2.3e-14'

In [26]: "%g" % 1.000000000000023
Out[26]: '1'

In [27]: "%g" % .000000000000023
Out[27]: '2.3e-14'


Martin