[Ffc] Multi-type parameters?
I'm thinking of how to handle this bug: https://bugs.launchpad.net/ffc/+bug/787010 I see two solutions: 1. Handle parameters with dynamical type in C++ (fairly easy to add). 2. Not use parameters that may change type in FFC (from "auto" to an int). -- Anders ___ Mailing list: https://launchpad.net/~ffc Post to : ffc@lists.launchpad.net Unsubscribe : https://launchpad.net/~ffc More help : https://help.launchpad.net/ListHelp
[Ffc] Large generated code
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; 2. Format floating point numbers for compactness, e.g. A[0] = 0.0; A[1] = 1.0; instead of A[0] = 0.000; A[1] = 1.000; Garth ___ Mailing list: https://launchpad.net/~ffc Post to : ffc@lists.launchpad.net Unsubscribe : https://launchpad.net/~ffc More help : https://help.launchpad.net/ListHelp
Re: [Ffc] Large generated code
On 6 July 2011 13:17, Garth N. Wells 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.000; > A[1] = 1.000; 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 > Garth > > ___ > Mailing list: https://launchpad.net/~ffc > Post to : ffc@lists.launchpad.net > Unsubscribe : https://launchpad.net/~ffc > More help : https://help.launchpad.net/ListHelp > ___ Mailing list: https://launchpad.net/~ffc Post to : ffc@lists.launchpad.net Unsubscribe : https://launchpad.net/~ffc More help : https://help.launchpad.net/ListHelp
Re: [Ffc] Large generated code
On 6 July 2011 14:44, Kristian Ølgaard wrote:
> On 6 July 2011 13:17, Garth N. Wells 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.000;
>> A[1] = 1.000;
>
> 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.023)
Out[24]: '1.023'
In [25]: repr(.023)
Out[25]: '2.3e-14'
In [26]: "%g" % 1.023
Out[26]: '1'
In [27]: "%g" % .023
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
Re: [Ffc] Large generated code
On Wed, Jul 06, 2011 at 12:17:15PM +0100, Garth N. Wells 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; We have done this before in various ways, either a simple loop as above or using std::fill. It can be done again. -- Anders > // Nonzero terms of in > A[0] = 1.0; > A[22] = 2.0; > A[23] = 1.0; > 2. Format floating point numbers for compactness, e.g. > > A[0] = 0.0; > A[1] = 1.0; > > instead of > > A[0] = 0.000; > A[1] = 1.000; > > Garth > > ___ > Mailing list: https://launchpad.net/~ffc > Post to : ffc@lists.launchpad.net > Unsubscribe : https://launchpad.net/~ffc > More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~ffc Post to : ffc@lists.launchpad.net Unsubscribe : https://launchpad.net/~ffc More help : https://help.launchpad.net/ListHelp
Re: [Ffc] [Dolfin] Multi-type parameters?
On Jul 6, 2011, at 1:54, Anders Logg wrote: > I'm thinking of how to handle this bug: > > https://bugs.launchpad.net/ffc/+bug/787010 > > I see two solutions: > > 1. Handle parameters with dynamical type in C++ (fairly easy to add). Not sure I like this. It is nice to have a strongly typed regime here. > 2. Not use parameters that may change type in FFC (from "auto" to an > int). Is it possible to store the parameter As an int internally in FFC, -1 for auto, and then add logic to the parsing of this variable so 'auto' becomes -1? Did that make sense? Johan > -- > Anders > > ___ > Mailing list: https://launchpad.net/~dolfin > Post to : dol...@lists.launchpad.net > Unsubscribe : https://launchpad.net/~dolfin > More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~ffc Post to : ffc@lists.launchpad.net Unsubscribe : https://launchpad.net/~ffc More help : https://help.launchpad.net/ListHelp
