dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Sat, May 09, 2009 at 11:18:27PM +0200, Johan Hake wrote:
> On Saturday 09 May 2009 21:55:26 Anders Logg wrote:
> > On Sat, May 09, 2009 at 08:14:22PM +0100, Garth N. Wells wrote:
> > > Anders Logg wrote:
> > > > On Sat, May 09, 2009 at 07:36:46PM +0100, Garth N. Wells wrote:
> > > >> There is an ambiguity in Table with the two functions:
> > > >>
> > > >>    void Table::set(std::string row, std::string col, int value);
> > > >>    void Table::set(std::string row, std::string col, uint value);
> > > >>
> > > >> since it's not clear which should be called if one does:
> > > >>
> > > >>    Table table;
> > > >>    table.set("a", "a", 10);
> > > >>
> > > >> Garth
> > > >
> > > > It works here. I actually added the uint version to remove an error
> > > > message from GCC about ambiguity. If it is not there, the compiler
> > > > will have to choose between converting an uint to a char*, double or
> > > > int.
> > >
> > > I get swig warnings:
> > >
> > > dolfin/log/Table.h:52: Warning(509): Overloaded method
> > > dolfin::Table::set(std::string,std::string,dolfin::uint) is shadowed by
> > > dolfin::Table::set(std::string,std::string,int) at dolfin/log/Table.h:49.
> >
> > ok, I didn't look at SWIG. I imagine this can be fixed by a suitable
> > ignore or similar in one of the .i files. Johan or Ola should know
> > what to do.
> 
> Jepp, I suppose that we %ignore the uint one.
> 
> > > I also get
> > >
> > > dolfin/log/Table.h:70: Warning(314): 'print' is a python keyword,
> > > renaming to '_print'
> >
> > When I implemented the .info() functions, it felt natural to use
> > .print(). We didn't come to any conclusion about the str(), info(),
> > print() functions. Any suggestions? In many cases (Mesh, Vector,
> > Matrix, Parameters etc), we need two ways to print data to the screen:
> > a short (one-liner) version and a long. And one of them should be
> > mapped to the Python __str__ method so the same information is shown
> > when doing
> >
> >   print foo
> >
> > This might indicate putting the following in Variable:
> >
> >   // Must be implemented by subclass
> >   virtual std::string str() const = 0;
> >
> >   // Implemented in variable, sends result of str() to info()
> >   void print() const;
> >
> > So in C++ .print() would be a shortcut for info(foo.str()) and in
> > Python, __str__ would return the same as C++ str() and print foo would
> > do the same as C++ .print().
> >
> > The questions are then, which version should str()/print() do, long or
> > short? And what should the other version be named?
> 
> If foo.print() is a short for info(foo.str()), why not call it foo.info()? In 
> python we could just ignore what ever we land on. We also need to decide what 
> we should do with the disp() methods, especially the one that uses the 
> different la backends. 
> 
> I think they are nice and they save us from some work, but if we find a clever 
> way to display a sparse matrix we could do that in the GenericMatrix 
> interface and remove the call to the different backends in the derived 
> classes.

This should be fairly easy to do with getrow().

-- 
Anders

Attachment: signature.asc
Description: Digital signature