On 6 July 2011 14:44, Kristian Ølgaard <k.b.oelga...@gmail.com> wrote:
> On 6 July 2011 13:17, Garth N. Wells <gn...@cam.ac.uk> 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
_______________________________________________
Mailing list: https://launchpad.net/~ffc
Post to : ffc@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ffc
More help : https://help.launchpad.net/ListHelp
