Re: [Ffc] [Dolfin] [Branch ~dolfin-core/dolfin/main] Rev 4434: Set parameter to use tensor rep for DG Poisson demo. It's broken.
Anders Logg wrote: > On Tue, Feb 02, 2010 at 11:20:32PM -, nore...@launchpad.net wrote: >> >> revno: 4434 >> committer: Garth N. Wells >> branch nick: dolfin-all >> timestamp: Tue 2010-02-02 23:16:44 + >> message: >> Set parameter to use tensor rep for DG Poisson demo. It's broken. >> >> This shows that tensor rep is not wotking for DG. > > I think it just shows that the tensor representation does not handle > FacetNormals This sounds to me like a significant deficiency. Is there are technical reason for this? or Division which is known. > Without the -r representation > option, FFC will automatically discover that the integrand in question > needs to be done with quadrature OK, it's good it if can figure this out. Garth > but if someone insists on -r tensor, > then FFC will try and explain why it fails: > > *** FFC: No handler defined for expression Division. > > I'll switch the demo back to "auto". > > -- > Anders > > > >> modified: >> demo/pde/dg/poisson/python/demo.py >> >> > >> === modified file 'demo/pde/dg/poisson/python/demo.py' >> --- demo/pde/dg/poisson/python/demo.py 2010-01-27 21:09:29 + >> +++ demo/pde/dg/poisson/python/demo.py 2010-02-02 23:16:44 + >> @@ -23,6 +23,8 @@ >> >> from dolfin import * >> >> +parameters["form_compiler"]["representation"] = "tensor" >> + >> # Create mesh and define function space >> mesh = UnitSquare(24, 24) >> V = FunctionSpace(mesh, "DG", 1) >> > > > > > ___ > 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
Re: [Ffc] strip_variables
Kristian Oelgaard wrote: > > > On 2 February 2010 23:26, Garth N. Wells wrote: >> Should the UFL function 'strip_variables' be called on a UFL form from >> inside FFC? I suspect that this may fix the bug > > I remember that there was a problem with calling the algorithm_strip > variables. I did that once as an easy fix to handle Variable, but it > screwed something up I remember but what it was I don't recall. Maybe it > was a performance issue? > Does calling strip_variables solve all problems related to Variable? > Seems to. I trawled http://www.fenics.org/pub/mailinglists/ffc-dev.mbox and a discussion seemed to relate to expand_indices and strip_variables, with expand_indices being evil. When I have time I'll ask the Launchpad admins to import our mailing lists, unless someone else beats me to it. Garth > Kristian > >> https://bugs.launchpad.net/ufl/+bug/512425 >> >> 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] [Bug 512425] Re: variable + facet restriction broken
On 3 February 2010 09:48, Garth Wells wrote:
Bug was in FFC, marking as invalid.
** Changed in: ufl
Status: Confirmed => Invalid
I would call this a bug in UFL.
from ufl.algorithms import propagate_restrictions
cell = triangle
V = FiniteElement("DG", cell, 1)
u = Coefficient(V)
flux2 = variable(grad(u))
e = avg(flux2)
print e
print propagate_restrictions(e)
produces:
{ A | A_{i_8} = 0.5 * var0(grad(w_0)))('-')) +
((var0(grad(w_0)))('+')))[i_8]) }
{ A | A_{i_8} = 0.5 * (({ A | A_{i_9} = 2 * ((var0(grad((w_0)('-'[i_9])
})[i_8]) }
I don't see why UFL shouldn't be able to handle that.
Kristian
--
variable + facet restriction broken
https://bugs.launchpad.net/bugs/512425
You received this bug notification because you are a member of UFL Core
Team, which is the registrant for UFL.
Status in Unified Form Language: Invalid
Bug description:
UFL is doing something wrong when a Function which is made into a 'variable',
e.g. u = variable(u), is used for a facet integral. The below code
demonstrates the error.
from dolfin import *
from numpy import random
mesh = UnitSquare(24, 24)
n = FacetNormal(mesh)
V = FunctionSpace(mesh, "DG", 1)
v = TestFunction(V)
u = Function(V)
# Fill vector with some numbers
random.seed(2)
u.vector().set_local( random.rand(u.vector().size()) )
# Define flux. One without, and one with 'variable'
flux1 = grad(u)
flux2 = variable(grad(u))
# Define linear forms
L0 = dot(jump(v, n), avg(grad(u)))*dS
L1 = dot(jump(v, n), avg(flux1))*dS
L2 = dot(jump(v, n), avg(flux2))*dS
L3 = dot(jump(v, n), flux2('+'))*dS
L4 = dot(jump(v, n), flux2('-'))*dS
print "Testing matrix norms. All should be equal."
print "Norm case 0: ", assemble(L0).norm("l2")
print "Norm case 1: ", assemble(L1).norm("l2")
print "Norm case 2 (using variable): ", assemble(L2).norm("l2")
print "Norm case 3 (using variable): ", assemble(L3).norm("l2")
print "Norm case 4 (using variable): ", assemble(L4).norm("l2")
signature.asc
Description: OpenPGP digital signature
___
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] [Bug 512425] Re: variable + facet restriction broken
Kristian Oelgaard wrote:
>
>
> On 3 February 2010 09:48, Garth Wells wrote:
>> Bug was in FFC, marking as invalid.
>>
>> ** Changed in: ufl
>> Status: Confirmed => Invalid
>
> I would call this a bug in UFL.
>
> from ufl.algorithms import propagate_restrictions
> cell = triangle
> V = FiniteElement("DG", cell, 1)
> u = Coefficient(V)
> flux2 = variable(grad(u))
>
> e = avg(flux2)
> print e
> print propagate_restrictions(e)
>
> produces:
>
> { A | A_{i_8} = 0.5 * var0(grad(w_0)))('-')) +
> ((var0(grad(w_0)))('+')))[i_8]) }
> { A | A_{i_8} = 0.5 * (({ A | A_{i_9} = 2 *
> ((var0(grad((w_0)('-'[i_9]) })[i_8]) }
>
> I don't see why UFL shouldn't be able to handle that.
>
Reply to the bug report so we can track the discussion.
Garth
> Kristian
>
>> --
>> variable + facet restriction broken
>> https://bugs.launchpad.net/bugs/512425
>> You received this bug notification because you are a member of UFL Core
>> Team, which is the registrant for UFL.
>>
>> Status in Unified Form Language: Invalid
>>
>> Bug description:
>> UFL is doing something wrong when a Function which is made into a
>> 'variable', e.g. u = variable(u), is used for a facet integral. The
>> below code demonstrates the error.
>>
>>
>>
>> from dolfin import *
>> from numpy import random
>>
>> mesh = UnitSquare(24, 24)
>> n = FacetNormal(mesh)
>> V = FunctionSpace(mesh, "DG", 1)
>> v = TestFunction(V)
>> u = Function(V)
>>
>> # Fill vector with some numbers
>> random.seed(2)
>> u.vector().set_local( random.rand(u.vector().size()) )
>>
>> # Define flux. One without, and one with 'variable'
>> flux1 = grad(u)
>> flux2 = variable(grad(u))
>>
>> # Define linear forms
>> L0 = dot(jump(v, n), avg(grad(u)))*dS
>> L1 = dot(jump(v, n), avg(flux1))*dS
>> L2 = dot(jump(v, n), avg(flux2))*dS
>> L3 = dot(jump(v, n), flux2('+'))*dS
>> L4 = dot(jump(v, n), flux2('-'))*dS
>>
>> print "Testing matrix norms. All should be equal."
>> print "Norm case 0: ", assemble(L0).norm("l2")
>> print "Norm case 1: ", assemble(L1).norm("l2")
>> print "Norm case 2 (using variable): ", assemble(L2).norm("l2")
>> print "Norm case 3 (using variable): ", assemble(L3).norm("l2")
>> print "Norm case 4 (using variable): ", assemble(L4).norm("l2")
>>
>>
>>
>
>
>
>
> ___
> 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] [Branch ~dolfin-core/dolfin/main] Rev 4434: Set parameter to use tensor rep for DG Poisson demo. It's broken.
On Wed, Feb 03, 2010 at 08:04:54AM +, Garth N. Wells wrote: > > > Anders Logg wrote: > > On Tue, Feb 02, 2010 at 11:20:32PM -, nore...@launchpad.net wrote: > >> > >> revno: 4434 > >> committer: Garth N. Wells > >> branch nick: dolfin-all > >> timestamp: Tue 2010-02-02 23:16:44 + > >> message: > >> Set parameter to use tensor rep for DG Poisson demo. It's broken. > >> > >> This shows that tensor rep is not wotking for DG. > > > > I think it just shows that the tensor representation does not handle > > FacetNormals > > This sounds to me like a significant deficiency. Is there are technical > reason for this? It has been like this for about a year (since the UFL introduction last year). Before we had the quadrature option, we stretched the tensor representation to support things it really couldn't handle like division, sqrt etc by some tricks. When we did the UFL conversion last year, I thought it best to remove these special tricks to keep the implementation simple. FacetNormal is somewhere in between. It could be added with some effort but since it is handled nicely by the quadrature representation it is not a high priority to add back. > or Division which is known. > > > Without the -r representation > > option, FFC will automatically discover that the integrand in question > > needs to be done with quadrature > > OK, it's good it if can figure this out. Here's how FFC selects the representation: 1. If there's a quadrature element --> return "quadrature" 2. If tensor representation is not possible --> return "quadrature" 3. Compare estimated cost of tensor and quadrature representation and use the most efficient option. The above case gets quadrature because of 2. The cost is estimated as the rank of the geometry tensor (number of derivatives + number of coefficients) and tensor representation is used if the cost is 3 or less. This can be fine-tuned with some appropriate benchmarks. -- Anders > Garth > > > but if someone insists on -r tensor, > > then FFC will try and explain why it fails: > > > > *** FFC: No handler defined for expression Division. > > > > I'll switch the demo back to "auto". > > > >> modified: > >> demo/pde/dg/poisson/python/demo.py > >> > >> > > > >> === modified file 'demo/pde/dg/poisson/python/demo.py' > >> --- demo/pde/dg/poisson/python/demo.py 2010-01-27 21:09:29 + > >> +++ demo/pde/dg/poisson/python/demo.py 2010-02-02 23:16:44 + > >> @@ -23,6 +23,8 @@ > >> > >> from dolfin import * > >> > >> +parameters["form_compiler"]["representation"] = "tensor" > >> + > >> # Create mesh and define function space > >> mesh = UnitSquare(24, 24) > >> V = FunctionSpace(mesh, "DG", 1) > >> > > > > > > > > > > ___ > > Mailing list: https://launchpad.net/~dolfin > > Post to : dol...@lists.launchpad.net > > Unsubscribe : https://launchpad.net/~dolfin > > More help : https://help.launchpad.net/ListHelp > > signature.asc Description: Digital signature ___ 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] Regression test for HyperElasticity
The regression test is failing of HyperElasticity. I guess this is after the recent work on stripping variables? Is this demo ok so we can update the reference? -- Anders signature.asc Description: Digital signature ___ 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] Regression test for HyperElasticity
On 3 February 2010 13:21, Anders Logg wrote: The regression test is failing of HyperElasticity. I guess this is after the recent work on stripping variables? Is this demo ok so we can update the reference? I pushed a fix to ufl, and the tests are green apart from MixedMixedElement for which I get: 346_evaluate_dof_6: values differ old = 0.645561 new = 0.645562 355_evaluate_dofs: values differ old = -0.844483 -0.984214 -1.12569 0.04968 0.063168 0.077184 0.645561 0.71467 0.752005 0.055611 0.0594 0.068229 -0.824896 -0.8811 -1.01206 new = -0.844483 -0.984214 -1.12569 0.04968 0.063168 0.077184 0.645562 0.71467 0.752005 0.055611 0.0594 0.068229 -0.824896 -0.8811 -1.01206 a tolerance issue. Kristian -- Anders -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAktpajoACgkQTuwUCDsYZdHgOwCbBRxQ/rW8EBSMoQ5Z3EFPfDQX aRQAniTR0vkzJqokdKJeVxcCK/EGqF+o =fmDC -END PGP SIGNATURE- ___ Mailing list: https://launchpad.net/~ffc Post to : ffc@lists.launchpad.net Unsubscribe : https://launchpad.net/~ffc More help : https://help.launchpad.net/ListHelp signature.asc Description: OpenPGP digital signature ___ 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] Regression test for HyperElasticity
On Wed, Feb 03, 2010 at 01:27:51PM +0100, Kristian Oelgaard wrote: > > > On 3 February 2010 13:21, Anders Logg wrote: > >The regression test is failing of HyperElasticity. I guess this is > >after the recent work on stripping variables? > > > >Is this demo ok so we can update the reference? > > I pushed a fix to ufl, and the tests are green apart from MixedMixedElement > for which I get: > > 346_evaluate_dof_6: values differ > old = 0.645561 > new = 0.645562 > 355_evaluate_dofs: values differ > old = -0.844483 -0.984214 -1.12569 0.04968 0.063168 0.077184 0.645561 > 0.71467 0.752005 0.055611 0.0594 0.068229 -0.824896 -0.8811 -1.01206 > new = -0.844483 -0.984214 -1.12569 0.04968 0.063168 0.077184 0.645562 > 0.71467 0.752005 0.055611 0.0594 0.068229 -0.824896 -0.8811 -1.01206 > > a tolerance issue. ok, nice. I'll increase it to 1e-5. Soon we'll be at 0.1... -- Anders signature.asc Description: Digital signature ___ 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] buildbot failure in FEniCS Buildbot on ffc-linux64-exp
The Buildbot has detected a new failure of ffc-linux64-exp on FEniCS Buildbot. Full details are available at: http://fenics.org:8080/builders/ffc-linux64-exp/builds/170 Buildbot URL: http://fenics.org:8080/ Buildslave for this Build: linux64-exp Build Reason: Build Source Stamp: HEAD Blamelist: Anders Logg BUILD FAILED: failed ffc check sincerely, -The Buildbot ___ 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] buildbot failure in FEniCS Buildbot on ffc-jaunty-amd64
The Buildbot has detected a new failure of ffc-jaunty-amd64 on FEniCS Buildbot. Full details are available at: http://fenics.org:8080/builders/ffc-jaunty-amd64/builds/171 Buildbot URL: http://fenics.org:8080/ Buildslave for this Build: jaunty-amd64 Build Reason: Build Source Stamp: HEAD Blamelist: Anders Logg BUILD FAILED: failed ffc check sincerely, -The Buildbot ___ 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] Regression test for HyperElasticity
On Wed, Feb 03, 2010 at 01:46:32PM +0100, Anders Logg wrote: > On Wed, Feb 03, 2010 at 01:27:51PM +0100, Kristian Oelgaard wrote: > > > > > > On 3 February 2010 13:21, Anders Logg wrote: > > >The regression test is failing of HyperElasticity. I guess this is > > >after the recent work on stripping variables? > > > > > >Is this demo ok so we can update the reference? > > > > I pushed a fix to ufl, and the tests are green apart from MixedMixedElement > > for which I get: > > > > 346_evaluate_dof_6: values differ > > old = 0.645561 > > new = 0.645562 > > 355_evaluate_dofs: values differ > > old = -0.844483 -0.984214 -1.12569 0.04968 0.063168 0.077184 0.645561 > > 0.71467 0.752005 0.055611 0.0594 0.068229 -0.824896 -0.8811 -1.01206 > > new = -0.844483 -0.984214 -1.12569 0.04968 0.063168 0.077184 0.645562 > > 0.71467 0.752005 0.055611 0.0594 0.068229 -0.824896 -0.8811 -1.01206 > > > > a tolerance issue. > > ok, nice. I'll increase it to 1e-5. Soon we'll be at 0.1... Fixed, finally, with a tolerance of 1e-9. The problem was comparison of strings rather than float values with a tolerance. I thought initially it would be enough to just compare the strings and make sure those string values are printed out with only a certain number of decimals, but we kept being screwed over by values like 0.0625001 0.0624999 Which are rounded to different numbers... -- Anders signature.asc Description: Digital signature ___ 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] Regression test for HyperElasticity
On 3 February 2010 20:03, Anders Logg wrote: On Wed, Feb 03, 2010 at 01:46:32PM +0100, Anders Logg wrote: On Wed, Feb 03, 2010 at 01:27:51PM +0100, Kristian Oelgaard wrote: > > > On 3 February 2010 13:21, Anders Logg wrote: > >The regression test is failing of HyperElasticity. I guess this is > >after the recent work on stripping variables? > > > >Is this demo ok so we can update the reference? > > I pushed a fix to ufl, and the tests are green apart from MixedMixedElement for which I get: > > 346_evaluate_dof_6: values differ > old = 0.645561 > new = 0.645562 > 355_evaluate_dofs: values differ > old = -0.844483 -0.984214 -1.12569 0.04968 0.063168 0.077184 0.645561 0.71467 0.752005 0.055611 0.0594 0.068229 -0.824896 -0.8811 -1.01206 > new = -0.844483 -0.984214 -1.12569 0.04968 0.063168 0.077184 0.645562 0.71467 0.752005 0.055611 0.0594 0.068229 -0.824896 -0.8811 -1.01206 > > a tolerance issue. ok, nice. I'll increase it to 1e-5. Soon we'll be at 0.1... Fixed, finally, with a tolerance of 1e-9. The problem was comparison of strings rather than float values with a tolerance. I thought initially it would be enough to just compare the strings and make sure those string values are printed out with only a certain number of decimals, but we kept being screwed over by values like 0.0625001 0.0624999 Which are rounded to different numbers... Yes, I noticed that I was still getting errors, but good that you fixed it. I'm cleaning up the parts of the code I've been working on the most including some of the code in cpp.py. Kristian -- Anders -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAktpyHYACgkQTuwUCDsYZdF/qwCeOB1nj37JrAggBHGgXKZLVk/m RyQAnRCqEgrAGudiwoCMttbEPSqiHW5c =wp9r -END PGP SIGNATURE- signature.asc Description: OpenPGP digital signature ___ 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] Regression test for HyperElasticity
On Wed, Feb 03, 2010 at 08:08:38PM +0100, Kristian Oelgaard wrote: > > > On 3 February 2010 20:03, Anders Logg wrote: > >On Wed, Feb 03, 2010 at 01:46:32PM +0100, Anders Logg wrote: > >>On Wed, Feb 03, 2010 at 01:27:51PM +0100, Kristian Oelgaard wrote: > >>> > >>> > >>> On 3 February 2010 13:21, Anders Logg wrote: > >>> >The regression test is failing of HyperElasticity. I guess this is > >>> >after the recent work on stripping variables? > >>> > > >>> >Is this demo ok so we can update the reference? > >>> > >>> I pushed a fix to ufl, and the tests are green apart from > >>> MixedMixedElement for which I get: > >>> > >>> 346_evaluate_dof_6: values differ > >>> old = 0.645561 > >>> new = 0.645562 > >>> 355_evaluate_dofs: values differ > >>> old = -0.844483 -0.984214 -1.12569 0.04968 0.063168 0.077184 0.645561 > >>> 0.71467 0.752005 0.055611 0.0594 0.068229 -0.824896 -0.8811 -1.01206 > >>> new = -0.844483 -0.984214 -1.12569 0.04968 0.063168 0.077184 0.645562 > >>> 0.71467 0.752005 0.055611 0.0594 0.068229 -0.824896 -0.8811 -1.01206 > >>> > >>> a tolerance issue. > >> > >>ok, nice. I'll increase it to 1e-5. Soon we'll be at 0.1... > > > >Fixed, finally, with a tolerance of 1e-9. > > > >The problem was comparison of strings rather than float values with a > >tolerance. I thought initially it would be enough to just compare the > >strings and make sure those string values are printed out with only a > >certain number of decimals, but we kept being screwed over by values > >like > > > > 0.0625001 > > 0.0624999 > > > >Which are rounded to different numbers... > > Yes, I noticed that I was still getting errors, but good that you fixed it. > I'm cleaning up the parts of the code I've been working on the most including > some of the code in cpp.py. Great. I think we should try to finish up a release of FFC 0.9.1 before the end of February. Ideally, we should go through all the code again and remove all FIXMEs. Then FFC will be in ridiculously good shape. -- Anders signature.asc Description: Digital signature ___ 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] Regression test for HyperElasticity
On 3 February 2010 20:11, Anders Logg wrote: On Wed, Feb 03, 2010 at 08:08:38PM +0100, Kristian Oelgaard wrote: On 3 February 2010 20:03, Anders Logg wrote: >On Wed, Feb 03, 2010 at 01:46:32PM +0100, Anders Logg wrote: >>On Wed, Feb 03, 2010 at 01:27:51PM +0100, Kristian Oelgaard wrote: >>> >>> >>> On 3 February 2010 13:21, Anders Logg wrote: >>> >The regression test is failing of HyperElasticity. I guess this is >>> >after the recent work on stripping variables? >>> > >>> >Is this demo ok so we can update the reference? >>> >>> I pushed a fix to ufl, and the tests are green apart from MixedMixedElement for which I get: >>> >>> 346_evaluate_dof_6: values differ >>> old = 0.645561 >>> new = 0.645562 >>> 355_evaluate_dofs: values differ >>> old = -0.844483 -0.984214 -1.12569 0.04968 0.063168 0.077184 0.645561 0.71467 0.752005 0.055611 0.0594 0.068229 -0.824896 -0.8811 -1.01206 >>> new = -0.844483 -0.984214 -1.12569 0.04968 0.063168 0.077184 0.645562 0.71467 0.752005 0.055611 0.0594 0.068229 -0.824896 -0.8811 -1.01206 >>> >>> a tolerance issue. >> >>ok, nice. I'll increase it to 1e-5. Soon we'll be at 0.1... > >Fixed, finally, with a tolerance of 1e-9. > >The problem was comparison of strings rather than float values with a >tolerance. I thought initially it would be enough to just compare the >strings and make sure those string values are printed out with only a >certain number of decimals, but we kept being screwed over by values >like > > 0.0625001 > 0.0624999 > >Which are rounded to different numbers... Yes, I noticed that I was still getting errors, but good that you fixed it. I'm cleaning up the parts of the code I've been working on the most including some of the code in cpp.py. Great. I think we should try to finish up a release of FFC 0.9.1 before the end of February. Ideally, we should go through all the code again and remove all FIXMEs. Then FFC will be in ridiculously good shape. Agree, I think that it sounds like a good idea. Kristian -- Anders -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAktpylsACgkQTuwUCDsYZdEHNwCeLbfmwDBvNioPcxBwCM8YLPXX clQAn3obqjXfn5Jk4bU7W2OUjb/Gce7Z =zmxm -END PGP SIGNATURE- signature.asc Description: OpenPGP digital signature ___ Mailing list: https://launchpad.net/~ffc Post to : ffc@lists.launchpad.net Unsubscribe : https://launchpad.net/~ffc More help : https://help.launchpad.net/ListHelp
