Re: [boost] Iterator adaptor question
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Rozental, Gennadiy wrote: | What is the problem adapting pair of iterators to scalar vectors to produce | an iterator with complex value type? The problem is you can hardly adapt a pair. So using iterator_adaptor (the new class template) does not provide any benefit. | | I am sure both old and new iterator adaptor easily allows it. | As I said before iterator_facade (new) would be the right tool AFAICS. Thomas - -- Dipl.-Ing. Thomas Witt Institut fuer Verkehrswesen, Eisenbahnbau und -betrieb, Universitaet Hannover voice: +49(0) 511 762 - 4273, fax: +49(0) 511 762-3001 http://www.ive.uni-hannover.de -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQE/MUsi0ds/gS3XsBoRAh8HAJ4kZumstczYuRg1VklfHHadWsjpCQCdGZT1 1KOJGnqwMriz3ZarJSpth7A= =pStw -END PGP SIGNATURE- ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Iterator adaptor question
At 03:06 PM 8/6/2003, Thomas Witt wrote: >The whole point in adapting is that you modify some but not all >behaviour/interface of a thing. Ther is nothing a pair provides that can >be reused so adaption is pointless. > >That's why the new version provides iterator_facade and >iterator_adaptor. iterator_facade helps with implementing iterators, >iterator_adaptor is for adapting iterator like types. I found this separation of usages into iterator_facade and iterator_adaptor to be a vast improvement, FWIW. It seems to have resolved all the frustrations I felt with the old interface. --Beman ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Iterator adaptor question
On Wednesday 06 August 2003 01:41 pm, Thomas Witt wrote: > gpgkeys: WARNING: this is an *experimental* HKP interface! > gpgkeys: key D1DB3F812DD7B01A not found on keyserver > > Neal, > > Neal D. Becker wrote: > | Some time back I mentioned I was interested in iterator adaptors to > > convert > > | between vectors of complex and scalar. I have looked at using the > > iterator > > | adaptor framework in boost. It appears that it is easy enough to > > adapt from > > | a complex sequence to pick off either the real or imaginary part, but > > going > > | the other direction is not feasible? > | > | You would need to adapt from a pair of iterators over scalars to > > output an > > | iterator over complex. > > Thomas Becker is working on a combine iterator that will solve this > problem. IIUC he has a working draft. > Does this use the "old" iterator adaptor framework? Do you know where to find sample code? > | Will the "new" iterator adaptor framework help? > > If you need it badly iterator_facade will help with getting the iterator > interface right. > Don't know what that means. Is this part of the "new" iterator stuff? pgp0.pgp Description: signature
[boost] Iterator adaptor question
Some time back I mentioned I was interested in iterator adaptors to convert between vectors of complex and scalar. I have looked at using the iterator adaptor framework in boost. It appears that it is easy enough to adapt from a complex sequence to pick off either the real or imaginary part, but going the other direction is not feasible? You would need to adapt from a pair of iterators over scalars to output an iterator over complex. Will the "new" iterator adaptor framework help? pgp0.pgp Description: signature
RE: [boost] Iterator adaptor question
> |>| What is the problem adapting pair of iterators to scalar > vectors to > |>produce > |>| an iterator with complex value type? > |> > |>The problem is you can hardly adapt a pair. So using > iterator_adaptor > |>(the new class template) does not provide any benefit. > | > | > | Why is that? > > The whole point in adapting is that you modify some but not > all behavior/interface of a thing. There is nothing a pair > provides that can be reused so adoption is pointless. There is all that we need so we could create valid iterator. As for how much we will need to overwrite - it still less then writing iterator from scratch. > That's why the new version provides iterator_facade and > iterator_adaptor. iterator_facade helps with implementing > iterators, iterator_adaptor is for adapting iterator like types. > > | I did not look in depth on new version but I remember that old one > | allowed to adapt any source. > > You needed to do this as the iterator interface > implementation was not separated from the actual iterator_adaption. I do not argue which version better fit for the task. I just saying that it could be easily done with old version either. Gennadiy. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Iterator adaptor question
On Wednesday 06 August 2003 02:38 pm, Thomas Witt wrote:
> gpgkeys: WARNING: this is an *experimental* HKP interface!
> gpgkeys: key D1DB3F812DD7B01A not found on keyserver
>
> Rozental, Gennadiy wrote:
> | What is the problem adapting pair of iterators to scalar vectors to
>
> produce
>
> | an iterator with complex value type?
>
> The problem is you can hardly adapt a pair. So using iterator_adaptor
> (the new class template) does not provide any benefit.
>
> | I am sure both old and new iterator adaptor easily allows it.
>
> As I said before iterator_facade (new) would be the right tool AFAICS.
>
>
> Thomas
This seems to work, but it's klugey. I guess it is an existance proof that
it's possible to do with old iterator adaptors?
1) Since only 1 object can be passed to the iterator adaptor constructor, I
had to pass a pair.
2) Distance uses only one of the base iterators.
3) iterator_category uses only 1 of the iterators.
Can anyone suggest ways to improve this?
The first 2 policies pick off real or imag parts of complex. They are no
problem.
The last 1 combines real and imag into complex. That's where the problems
lie.
#include
#include
#include // pair
// #include
namespace boost {
namespace detail{
template
class complex_real_iterator_policy : public default_iterator_policies {
public:
// Constructors
complex_real_iterator_policy (BaseIterator const& _base) :
base (_base) {}
template
typename IteratorAdaptor::reference dereference (IteratorAdaptor& x)
const {
return real (*x.base());
}
private:
const BaseIterator& base;
};
template
class complex_imag_iterator_policy : public default_iterator_policies {
public:
// Constructors
complex_imag_iterator_policy (BaseIterator const& _base) :
base (_base) {}
template
typename IteratorAdaptor::reference dereference (IteratorAdaptor& x)
const {
return imag (*x.base());
}
private:
const BaseIterator& base;
};
template
class real_imag_complex_iterator_policy : public default_iterator_policies
{
public:
typedef typename std::pair base_type;
// Constructors
real_imag_complex_iterator_policy (base_type const& _base) :
base (_base) {}
template
typename IteratorAdaptor::reference dereference (IteratorAdaptor& x)
const {
return typename IteratorAdaptor::value_type (*x.base().first,
*x.base().second);
}
template
void increment(IteratorAdaptor& x)
{ ++x.base().first; ++x.base().second; }
template
void decrement(IteratorAdaptor& x)
{ --x.base().first; --x.base().second; }
template
typename IteratorAdaptor1::difference_type
distance(const IteratorAdaptor1& x, const IteratorAdaptor2& y) const
{ return y.base().first - x.base().first; }
private:
const base_type base;
};
} // namespace detail
template
struct complex_real_iterator_generator {
typedef typename boost::detail::iterator_traits::value_type
complex_value_type;
typedef typename complex_value_type::value_type scalar_value_type;
typedef
boost::iterator_adaptor,
reference_is > type;
};
template
typename complex_real_iterator_generator::type
make_complex_real_iterator(BaseIterator const& begin) {
typedef typename complex_real_iterator_generator::type
ret_type;
return ret_type (begin, detail::complex_real_iterator_policy
(begin));
}
template
struct complex_imag_iterator_generator {
typedef typename boost::detail::iterator_traits::value_type
complex_value_type;
typedef typename complex_value_type::value_type scalar_value_type;
typedef
boost::iterator_adaptor,
reference_is > type;
};
template
typename complex_imag_iterator_generator::type
make_complex_imag_iterator(BaseIterator const& begin) {
typedef typename complex_imag_iterator_generator::type
ret_type;
return ret_type (begin, detail::complex_imag_iterator_policy
(begin));
}
template
struct real_imag_complex_iterator_generator {
typedef typename boost::detail::iterator_traits::value_type
scalar_value_type;
typedef typename std::complex complex_value_type;
typedef typename std::pair pair_type;
typedef boost::iterator_adaptor,
complex_value_type, complex_value_type, complex_value_type*, typename
std::iterator_traits::iterator_category, typename
std::iterator_traits::difference_type > type;
};
template
typename real_imag_complex_iterator_generator::type
make_real_imag_complex_iterator(BaseIterator1 const& begin1, BaseIterator2
const& begin2) {
typedef typename real_imag_complex_iterator_generator::type ret_type;
typedef typename std::pair pair_type;
return ret_type (pair_type (begin1, begin2),
detail::real_imag_complex_iterator_policy
(pair_type (begin1, begin2)));
RE: [boost] Iterator adaptor question
> -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Rozental, Gennadiy wrote: > > | What is the problem adapting pair of iterators to scalar vectors to > produce > | an iterator with complex value type? > > The problem is you can hardly adapt a pair. So using > iterator_adaptor (the new class template) does not provide > any benefit. Why is that? I did not look in depth on new version but I remember that old one allowed to adapt any source. For convenience one could've created object generators. Gennadiy. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Iterator adaptor question
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Rozental, Gennadiy wrote: |>1) Since only 1 object can be passed to the iterator adaptor |>constructor, I |>had to pass a pair. | | | Use object generators. | | |>2) Distance uses only one of the base iterators. | | | Use minimal distance. Different distances are most certainly a precondition violation. AFAIAC assert on differing distances. | | |>3) iterator_category uses only 1 of the iterators. | | Use most restrictive category. In general don't use the old iterator_adaptor unless you really have to. Thomas - -- Dipl.-Ing. Thomas Witt Institut fuer Verkehrswesen, Eisenbahnbau und -betrieb, Universitaet Hannover voice: +49(0) 511 762 - 4273, fax: +49(0) 511 762-3001 http://www.ive.uni-hannover.de -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQE/MWiy0ds/gS3XsBoRAg/mAKCFxhPTSwxfrqQloTThZN9HfNjt0gCgkgKB 32RUc1R4EOJzUgw4dmlRgoE= =gADX -END PGP SIGNATURE- ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Iterator adaptor question
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Rozental, Gennadiy wrote: |>-BEGIN PGP SIGNED MESSAGE- |>Hash: SHA1 |> |>Rozental, Gennadiy wrote: |> |>| What is the problem adapting pair of iterators to scalar vectors to |>produce |>| an iterator with complex value type? |> |>The problem is you can hardly adapt a pair. So using |>iterator_adaptor (the new class template) does not provide |>any benefit. | | | Why is that? The whole point in adapting is that you modify some but not all behaviour/interface of a thing. Ther is nothing a pair provides that can be reused so adaption is pointless. That's why the new version provides iterator_facade and iterator_adaptor. iterator_facade helps with implementing iterators, iterator_adaptor is for adapting iterator like types. | I did not look in depth on new version but I remember that old | one allowed to adapt any source. You needed to do this as the iterator interface implementation was not seperated from the actual iterator_adaption. Thomas - -- Dipl.-Ing. Thomas Witt Institut fuer Verkehrswesen, Eisenbahnbau und -betrieb, Universitaet Hannover voice: +49(0) 511 762 - 4273, fax: +49(0) 511 762-3001 http://www.ive.uni-hannover.de -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQE/MVHC0ds/gS3XsBoRAsJLAJ4gb8KM3GJGi3wYM65ppMSfasuXtACghiD3 dGgVfgSioFYgEm0ihB0r9zY= =wm0V -END PGP SIGNATURE- ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Iterator adaptor question
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Neal, Neal D. Becker wrote: | Some time back I mentioned I was interested in iterator adaptors to convert | between vectors of complex and scalar. I have looked at using the iterator | adaptor framework in boost. It appears that it is easy enough to adapt from | a complex sequence to pick off either the real or imaginary part, but going | the other direction is not feasible? | | You would need to adapt from a pair of iterators over scalars to output an | iterator over complex. Thomas Becker is working on a combine iterator that will solve this problem. IIUC he has a working draft. | | Will the "new" iterator adaptor framework help? If you need it badly iterator_facade will help with getting the iterator interface right. Thomas - -- Dipl.-Ing. Thomas Witt Institut fuer Verkehrswesen, Eisenbahnbau und -betrieb, Universitaet Hannover voice: +49(0) 511 762 - 4273, fax: +49(0) 511 762-3001 http://www.ive.uni-hannover.de -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQE/MT3Q0ds/gS3XsBoRAk+gAJ4vWlBSQkW8+pGAwMlHYWJ6y7k2JgCfRSF9 a6MjiFmWyB01bI7tScpMY6Y= =BLfu -END PGP SIGNATURE- ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Iterator adaptor question
> 1) Since only 1 object can be passed to the iterator adaptor > constructor, I > had to pass a pair. Use object generators. > 2) Distance uses only one of the base iterators. Use minimal distance. > 3) iterator_category uses only 1 of the iterators. Use most restrictive category. Gennadiy. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Iterator adaptor question
What is the problem adapting pair of iterators to scalar vectors to produce an iterator with complex value type? I am sure both old and new iterator adaptor easily allows it. Gennadiy. > -Original Message- > From: Neal D. Becker [mailto:[EMAIL PROTECTED] > Sent: Wednesday, August 06, 2003 1:31 PM > To: [EMAIL PROTECTED] > Subject: [boost] Iterator adaptor question > > > Some time back I mentioned I was interested in iterator > adaptors to convert > between vectors of complex and scalar. I have looked at > using the iterator > adaptor framework in boost. It appears that it is easy > enough to adapt from > a complex sequence to pick off either the real or imaginary > part, but going > the other direction is not feasible? > > You would need to adapt from a pair of iterators over scalars > to output an > iterator over complex. > > Will the "new" iterator adaptor framework help? > ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
