Subject: Re: [Ffc] [Branch ~ffc-core/ffc/dev] Rev 1443: Remove \n in formats

From: Marie Rognes <[email-masked]>
Date: Wed, 13 Jan 2010 18:39:56 +0100

[email-masked] wrote:
> ------------------------------------------------------------
> revno: 1443
> committer: Anders Logg <[email-masked]>
> branch nick: ffc-dev
> timestamp: Wed 2010-01-13 17:00:13 +0100
> message:
>   Remove \n in formats
> modified:
>   ffc/cpp.py
>
>   

I like the \n in formats. Makes more sense to me to have a line break
after for instance "each assignment" than explicitly stating breaks
in the code generation functions.

--
Marie

---

From: Anders Logg <[email-masked]>
Date: Wed, 13 Jan 2010 19:22:24 +0100

> in the code generation functions.

I agree, but it becomes problematic in some cases. For example when we
insert things into the UFC format strings in the formatting stage:

  /// Return the dimension of the finite element function space
  virtual unsigned int space_dimension() const
  {
%(space_dimension)s
  }

Then we get things like

  virtual unsigned int space_dimension() const
  {
    return 3;

  }

It's better with \n since \n can easily be added where needed but not
(so) easily removed where not needed.

--
Anders

---

From: Marie Rognes <[email-masked]>
Date: Wed, 13 Jan 2010 20:27:33 +0100

>   virtual unsigned int space_dimension() const

Remove the "\n" in the format["return", "comment"] then ... and keep 
"iadd" and "assign" then?

--
Marie

---

From: Anders Logg <[email-masked]>
Date: Wed, 13 Jan 2010 21:25:01 +0100

> "iadd" and "assign" then?

I thought this was ok, but just found out it wasn't. It will lead to
things like

    // Compute element tensor
    A[0] += 0;
    A[1] += 0;
    A[2] += 0;
    A[3] += 0;
    A[4] += 0;
    A[5] += 0;
    A[6] += 0;
    A[7] += 0;
    A[8] += 0;

  }

Since we can't avoid the last \n.

So the general rule needs to be no \n in formatting rules and we add
it where we need it.

--
Anders

---

From: Marie Rognes <[email-masked]>
Date: Wed, 13 Jan 2010 21:26:25 +0100

>     // Compute element tensor

Could you remind me why that last spare line is so evil?

--
Marie

---

From: Anders Logg <[email-masked]>
Date: Wed, 13 Jan 2010 21:27:27 +0100

> Could you remind me why that last spare line is so evil?

Yes, it looks ugly.

We should generate code that not only runs faster than hand-written
code, but also looks better than hand-written code. :-)

--
Anders

---

From: Johan Hake <[email-masked]>
Date: Wed, 13 Jan 2010 12:35:35 -0800

> >> "iadd" and "assign" then?

Sorry for bumping into the discussion with a potentially irrelevant comment.

Have you considered collecting code snippets in a list by

  code_snippets.append(code_snippet)

and then last you do a

  code = "\n".join(code_snippets)

This might also be faster (if this snippeting is ever going to be a bottle 
neck?), as string is immutable in Python which means that 

  code_snippet += some_code

always creates a new string.

Johan

---

From: Anders Logg <[email-masked]>
Date: Wed, 13 Jan 2010 21:42:46 +0100

> always creates a new string.

Good point. This makes good sense in some places but not in others.

I've used it now in one more place.

Note that we are currently pushing to ffc/dev instead of ffc/main so
changes will appear there.

--
Anders

---

From: Marie Rognes <[email-masked]>
Date: Wed, 13 Jan 2010 21:44:12 +0100

> code, but also looks better than hand-written code. :-)

Ah. I'll add this to my list of "obviously logical things" along with the
ordering of the ufc functions ;)

--
Marie

---

From: Marie Rognes <[email-masked]>
Date: Wed, 13 Jan 2010 21:45:26 +0100

> Good point. This makes good sense in some places but not in others.

I think this is what we did before, and I can happily revert to that.

--
Marie

---

From: Anders Logg <[email-masked]>
Date: Wed, 13 Jan 2010 21:47:24 +0100

> ordering of the ufc functions ;)

It will be a long list. :-)

--
Anders

---

From: Johan Hake <[email-masked]>
Date: Wed, 13 Jan 2010 12:52:06 -0800

On Wednesday 13 January 2010 12:42:46 Anders Logg wrote:
> > > >>>> I like the \n in formats. Makes more sense to me to have a line
> > > >>>> break after for instance "each assignment" than explicitly stating
> > > >>>> breaks in the code generation functions.
> > > >>>
> > > >>> I agree, but it becomes problematic in some cases. For example when
> > > >>> we insert things into the UFC format strings in the formatting
> > > >>> stage:
> > > >>>
> > This might also be faster (if this snippeting is ever going to be a
> > bottle neck?), as string is immutable in Python which means that
> >

Sure!

> I've used it now in one more place.

:)

Johan

---

From: Marie Rognes <[email-masked]>
Date: Wed, 13 Jan 2010 22:03:04 +0100

Johan Hake wrote:
> neck?), 

On a related subject, do we have some fancy timing functionality to time 
the different
compiler stages and different functions? (In the spirit of: time first, 
optimize afterwards ;) )

--
Marie

> as string is immutable in Python which means that 
>

---

From: Anders Logg <[email-masked]>
Date: Wed, 13 Jan 2010 22:13:43 +0100

On Wed, Jan 13, 2010 at 10:03:04PM +0100, Marie Rognes wrote:
> >This might also be faster (if this snippeting is ever going to be
> >a bottle neck?),
>
> On a related subject, do we have some fancy timing functionality to
> time the different
> compiler stages and different functions? (In the spirit of: time
> first, optimize afterwards ;) )

No, but that's a very good idea. I can add something simple.

We could add something fancy like the Timing class in DOLFIN but that
might be overkill.

--
Anders

---

From: Kristian Oelgaard <[email-masked]>
Date: Thu, 14 Jan 2010 09:29:55 +0100

2010/1/13 Marie Rognes <[email-masked]>:
> On a related subject, do we have some fancy timing functionality to time the
> different

Definitely, but in my experience the time spent generating the code
for tabulate_tensor is "much "*7 larger than anything else in FFC.

Kristian

> _______________________________________________
> Mailing list: https://launchpad.net/~ffc
> Post to     : [email-masked]
> Unsubscribe : https://launchpad.net/~ffc
> More help   : https://help.launchpad.net/ListHelp
>