Re: [eigen] An insistent plea for an input operator |

[ Thread Index | Date Index | More lists.tuxfamily.org/eigen Archives ]

*To*: eigen@xxxxxxxxxxxxxxxxxxx*Subject*: Re: [eigen] An insistent plea for an input operator*From*: Benoit Jacob <jacob.benoit.1@xxxxxxxxx>*Date*: Tue, 20 Jul 2010 13:18:26 -0400*Dkim-signature*: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=iPDlQoZpza01CN+NELU3h2pKfXT889qfRmASdTXpPR4=; b=l2BYk0kmob8BEafX83UJxfpExeughWqqOO9kS+uLzdqXhbrg1DGf6/cfzzg5dO3GoX DDLoV+WUckguOlFPOfvmO7nsn9xM1MnaFoVkzKMPe+XDgYkaP98l/VhHTeVvNMdyK5Lg s6QGUYsAqmJ43SlKJUPe5v5cOVObgxG7tUIps=*Domainkey-signature*: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=fiwFTd3xrzTyGwuEZMI0J0csRvipQLrMtbkvhQJtFQv2L+A/g4CRI6rvyf/f4mmvfU re4jjyMZI4wn8IhdmGQ9H+up4EXtd2cR3zTSYtzsmBjlJRILOxn6TcWR5tUpzTJ3C7Qx tNQnMKI3/lggNUm84qwV4ZSqYKSUMiBsTd7Rs=

2010/7/20 Benoit Jacob <jacob.benoit.1@xxxxxxxxx>: > 2010/7/20 Hauke Heibel <hauke.heibel@xxxxxxxxxxxxxx>: >> On Tue, Jul 20, 2010 at 5:14 PM, Benoit Jacob <jacob.benoit.1@xxxxxxxxx> wrote: >>> 2010/7/20 Hauke Heibel <hauke.heibel@xxxxxxxxxxxxxx>: >>>>> Sure! How is this a problem? >>>> >>>> Not really but somebody might think hey, it accepts input from >>>> std::cin in the form of >>>> >>>> 1 2 3 >>>> 4 5 6 >>>> >>>> why not from a text file... I admit, we can easily deal with that. I >>>> was more like brainstorming. ;) >>> >>> Just for the record: I don't see how allowing reading from a text file >>> is a drawback, I see it as a feature :-) >> >> Of course it is! But not if it does not work even though it compiles. >> I requires a different method. >> >> Your other proposal sound fine to me as long as its fine for the user. >> I was actually hoping for something as the standard library does. You >> know, there are these modifiers. I don't recall perfectly, but they >> somehow look like this >> >> std::cout << std::ios_base::hex << 10 << std::endl; > > The problem is that we can't extend that from the out side with our > own modifiers: that would require adding new data members in cout... (ignore the above and read only the below) > >> >> or then with Eigen types like this >> >> std::cout << Eigen::Format(...) << m; >> >> or this >> >> std::cin >> Eigen::Format(...) >> m; > > Ah, this looks possible. so here the std::cout << Eigen::Format(...) > would return a stream of a different type, inheriting the type of the > original stream. > > Benoit > > >> >> I would like this a lot since it were following the standard approach >> but the other one is fine too. >> >> - Hauke >> >> >> >

**References**:**[eigen] An insistent plea for an input operator***From:*Helmut Jarausch

**Re: [eigen] An insistent plea for an input operator***From:*Benoit Jacob

**Re: [eigen] An insistent plea for an input operator***From:*Gael Guennebaud

**Re: [eigen] An insistent plea for an input operator***From:*Hauke Heibel

**Re: [eigen] An insistent plea for an input operator***From:*Benoit Jacob

**Re: [eigen] An insistent plea for an input operator***From:*Hauke Heibel

**Re: [eigen] An insistent plea for an input operator***From:*Benoit Jacob

**Re: [eigen] An insistent plea for an input operator***From:*Hauke Heibel

**Re: [eigen] An insistent plea for an input operator***From:*Benoit Jacob

**Messages sorted by:**[ date | thread ]- Prev by Date:
**Re: [eigen] eigen3 replacement of start/segment/end** - Next by Date:
**[eigen] Assertion in DenseStorageBase.h:487: Nonnegativity of rows and cols sufficient?** - Previous by thread:
**Re: [eigen] An insistent plea for an input operator** - Next by thread:
**Re: [eigen] An insistent plea for an input operator**

Mail converted by MHonArc 2.6.19+ | http://listengine.tuxfamily.org/ |