"Thorsten Ottosen" <nesotto@cs.auc.dk> wrote in message news:c6quof$dtl$1@sea.gmane.org...
I have some questions. Will it be possible to say
1. typedef boost::rational< big_integer > big_rational.
Yes. In fact, the big_integer_example contains an example where boost::rational<big_integer> is used.
2. Why is faculty() a part of the interface. I have a generic version of faculty in some prob&stat code I'm doing that I hope would work with big_integer.
Your generic version will most probably work. There is one difference, my version returns an expression instead of a value, which saves the creation of one temporary value. In this case, the gained performance is probably minimal. I'm happy to refactor this function out of the library, throw it away, or come up with a hybrid solution where the expression-returning version is included when both big_integer and your library is included.
3. Are you planning big_float? I would be happy with focus on interface specs and then better implementation later.
Unfortunately not. I can see that big_float would have its uses, but I rarely even use float. My interests ly in algebraic computations such as cryptology.
The C++ standard could really use a "big" library and it's always nice with a version in boost first.
br
Thorsten
Thanks for the response, Richard Peters
From: "Richard Peters" <r.a.peters@student.tue.nl>
"Thorsten Ottosen" <nesotto@cs.auc.dk> wrote in message news:c6quof$dtl$1@sea.gmane.org...
I have some questions. Will it be possible to say
1. typedef boost::rational< big_integer > big_rational.
Yes. In fact, the big_integer_example contains an example where boost::rational<big_integer> is used.
I have not had success using big_integer inside rational. I get concept check errors with the test code below. /////////////////////// jyoung.1133 ==> g++ --version g++ (GCC) 3.3.2 20031022 (Red Hat Linux 3.3.2-1) Copyright (C) 2003 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. /////////////////////// I'm not sure if this is a problem with big_integer, rational, or multi_array. The below code works with boost::rational<long long>, double, and CLN's rational type, and even boost::rational<cln::cl_I>. I have other issues with using cl_I with boost::rational as cl_I doesn't implement all the operators, but thats not the trouble here. Joel //////////////////////////////CUT HERE///////////////////////////////// #include <cln/integer.h> #include <cln/rational.h> #include "boost/big_integer.hpp" #include "boost/multi_array.hpp" #include "boost/rational.hpp" // Works: //typedef double data_t; // // Works: //typedef boost::rational<long long> data_t; // // Doesn't Work: typedef boost::rational<boost::big_integer> data_t; // // Works: //typedef cln::cl_RA data_t; // // Main Program int main(int argc, char* argv[]) { data_t dx; data_t dt; data_t a; typedef boost::multi_array<data_t, 2> array_type; boost::array<array_type::index, 2> u_dim; array_type u(u_dim); typedef array_type::index_range range; typedef array_type::array_view<1>::type view_t; typedef boost::multi_array<data_t, 2> tri_diag_array_t; tri_diag_array_t A(boost::extents[3][10]); view_t x = u[ boost::indices[range()][15+1] ]; view_t b = u[ boost::indices[range()][15] ]; typedef boost::multi_array<data_t, 1> vector_type; vector_type d(boost::extents[10]); d = A[boost::indices[1][range()]]; } //////////////////////////////CUT HERE///////////////////////////////// The error looks like: //////////////////////////////CUT HERE///////////////////////////////// /home/afit1/fac/jyoung/boost/boost/include/boost-1_31/boost/concept_check.hpp: In member function `void boost::EqualityComparableConcept<TT>::constraints() [with TT = boost::detail::multi_array::array_iterator<data_t, data_t*, boost::mpl::size_t<1>, data_t&>]': /home/afit1/fac/jyoung/boost/boost/include/boost-1_31/boost/concept_check.hpp:49: instantiated from `void boost::function_requires(boost::mpl::identity<T>*) [with Concept = boost::EqualityComparableConcept<boost::detail::multi_array::array_iterator<data_t, data_t*, boost::mpl::size_t<1>, data_t&> >]' /home/afit1/fac/jyoung/boost/boost/include/boost-1_31/boost/iterator/iterator_concepts.hpp:147: instantiated from `void boost_concepts::SinglePassIteratorConcept<Iterator>::constraints() [with Iterator = boost::detail::multi_array::array_iterator<data_t, data_t*, boost::mpl::size_t<1>, data_t&>]' /home/afit1/fac/jyoung/boost/boost/include/boost-1_31/boost/concept_check.hpp:49: instantiated from `void boost::function_requires(boost::mpl::identity<T>*) [with Concept = boost_concepts::SinglePassIteratorConcept<boost::detail::multi_array::array_iterator<data_t, data_t*, boost::mpl::size_t<1>, data_t&> >]' /home/afit1/fac/jyoung/boost/boost/include/boost-1_31/boost/iterator/iterator_concepts.hpp:165: instantiated from `void boost_concepts::ForwardTraversalConcept<Iterator>::constraints() [with Iterator = boost::detail::multi_array::array_iterator<data_t, data_t*, boost::mpl::size_t<1>, data_t&>]' /home/afit1/fac/jyoung/boost/boost/include/boost-1_31/boost/concept_check.hpp:49: instantiated from `void boost::function_requires(boost::mpl::identity<T>*) [with Concept = boost_concepts::ForwardTraversalConcept<boost::detail::multi_array::array_iterator<data_t, data_t*, boost::mpl::size_t<1>, data_t&> >]' /home/afit1/fac/jyoung/boost/boost/include/boost-1_31/boost/multi_array/concept_checks.hpp:65: instantiated from `void boost::detail::multi_array::ConstMultiArrayConcept<Array, NumDims>::constraints() [with Array = boost::detail::multi_array::multi_array_view<data_t, 1>, unsigned int NumDims = 1]' /home/afit1/fac/jyoung/boost/boost/include/boost-1_31/boost/concept_check.hpp:49: instantiated from `void boost::function_requires(boost::mpl::identity<T>*) [with Concept = boost::detail::multi_array::ConstMultiArrayConcept<boost::detail::multi_array::multi_array_view<data_t, 1>, 1>]' /home/afit1/fac/jyoung/boost/boost/include/boost-1_31/boost/multi_array/multi_array_ref.hpp:470: instantiated from `boost::multi_array_ref<T, NumDims>& boost::multi_array_ref<T, NumDims>::operator=(const ConstMultiArray&) [with ConstMultiArray = boost::detail::multi_array::multi_array_view<data_t, 1>, T = data_t, unsigned int NumDims = 1]' /home/afit1/fac/jyoung/boost/boost/include/boost-1_31/boost/multi_array.hpp:174: instantiated from `boost::multi_array<T, NumDims, Allocator>& boost::multi_array<T, NumDims, Allocator>::operator=(const ConstMultiArray&) [with ConstMultiArray = boost::detail::multi_array::multi_array_view<data_t, 1>, T = data_t, unsigned int NumDims = 1, Allocator = std::allocator<data_t>]' b.cpp:53: instantiated from here /home/afit1/fac/jyoung/boost/boost/include/boost-1_31/boost/concept_check.hpp:305: error: ISO C++ says that `typename boost::mpl::apply2<boost::detail::always_bool2, Derived1, Derived2>::type boost::operator==(const boost::iterator_facade<Derived1, V1, TC1, R1, D1>&, const boost::iterator_facade<Derived2, V2, TC2, R2, D2>&) [with Derived1 = boost::detail::multi_array::array_iterator<data_t, data_t*, boost::mpl::size_t<1>, data_t&>, V1 = data_t, TC1 = boost::random_access_traversal_tag, R1 = data_t&, D1 = ptrdiff_t, Derived2 = boost::detail::multi_array::array_iterator<data_t, data_t*, boost::mpl::size_t<1>, data_t&>, V2 = data_t, TC2 = boost::random_access_traversal_tag, R2 = data_t&, D2 = ptrdiff_t]' and `bool boost::expression::operator==(T, const boost::expression::expression<Base>&) [with T = boost::detail::multi_array::array_iterator<data_t, data_t*, boost::mpl::size_t<1>, data_t&>, Base = boost::expression::post_increment]' are ambiguous even though the worst conversion for the former is better than the worst conversion for the latter /home/afit1/fac/jyoung/boost/boost/include/boost-1_31/boost/concept_check.hpp:305: error: ISO C++ says that `typename boost::mpl::apply2<boost::detail::always_bool2, Derived1, Derived2>::type boost::operator==(const boost::iterator_facade<Derived1, V1, TC1, R1, D1>&, const boost::iterator_facade<Derived2, V2, TC2, R2, D2>&) [with Derived1 = boost::detail::multi_array::array_iterator<data_t, data_t*, boost::mpl::size_t<1>, data_t&>, V1 = data_t, TC1 = boost::random_access_traversal_tag, R1 = data_t&, D1 = ptrdiff_t, Derived2 = boost::detail::multi_array::array_iterator<data_t, data_t*, boost::mpl::size_t<1>, data_t&>, V2 = data_t, TC2 = boost::random_access_traversal_tag, R2 = data_t&, D2 = ptrdiff_t]' and `bool boost::expression::operator==(T, const boost::expression::expression<Base>&) [with T = boost::detail::multi_array::array_iterator<data_t, data_t*, boost::mpl::size_t<1>, data_t&>, Base = boost::expression::post_decrement]' are ambiguous even though the worst conversion for the former is better than the worst conversion for the latter /home/afit1/fac/jyoung/boost/boost/include/boost-1_31/boost/concept_check.hpp:49: instantiated from `void boost::function_requires(boost::mpl::identity<T>*) [with Concept = boost::EqualityComparableConcept<boost::detail::multi_array::array_iterator<data_t, data_t*, boost::mpl::size_t<1>, data_t&> >]' /home/afit1/fac/jyoung/boost/boost/include/boost-1_31/boost/iterator/iterator_concepts.hpp:147: instantiated from `void boost_concepts::SinglePassIteratorConcept<Iterator>::constraints() [with Iterator = boost::detail::multi_array::array_iterator<data_t, data_t*, boost::mpl::size_t<1>, data_t&>]' /home/afit1/fac/jyoung/boost/boost/include/boost-1_31/boost/concept_check.hpp:49: instantiated from `void boost::function_requires(boost::mpl::identity<T>*) [with Concept = boost_concepts::SinglePassIteratorConcept<boost::detail::multi_array::array_iterator<data_t, data_t*, boost::mpl::size_t<1>, data_t&> >]' /home/afit1/fac/jyoung/boost/boost/include/boost-1_31/boost/iterator/iterator_concepts.hpp:165: instantiated from `void boost_concepts::ForwardTraversalConcept<Iterator>::constraints() [with Iterator = boost::detail::multi_array::array_iterator<data_t, data_t*, boost::mpl::size_t<1>, data_t&>]' /home/afit1/fac/jyoung/boost/boost/include/boost-1_31/boost/concept_check.hpp:49: instantiated from `void boost::function_requires(boost::mpl::identity<T>*) [with Concept = boost_concepts::ForwardTraversalConcept<boost::detail::multi_array::array_iterator<data_t, data_t*, boost::mpl::size_t<1>, data_t&> >]' /home/afit1/fac/jyoung/boost/boost/include/boost-1_31/boost/multi_array/concept_checks.hpp:65: instantiated from `void boost::detail::multi_array::ConstMultiArrayConcept<Array, NumDims>::constraints() [with Array = boost::detail::multi_array::multi_array_view<data_t, 1>, unsigned int NumDims = 1]' /home/afit1/fac/jyoung/boost/boost/include/boost-1_31/boost/concept_check.hpp:49: instantiated from `void boost::function_requires(boost::mpl::identity<T>*) [with Concept = boost::detail::multi_array::ConstMultiArrayConcept<boost::detail::multi_array::multi_array_view<data_t, 1>, 1>]' /home/afit1/fac/jyoung/boost/boost/include/boost-1_31/boost/multi_array/multi_array_ref.hpp:470: instantiated from `boost::multi_array_ref<T, NumDims>& boost::multi_array_ref<T, NumDims>::operator=(const ConstMultiArray&) [with ConstMultiArray = boost::detail::multi_array::multi_array_view<data_t, 1>, T = data_t, unsigned int NumDims = 1]' /home/afit1/fac/jyoung/boost/boost/include/boost-1_31/boost/multi_array.hpp:174: instantiated from `boost::multi_array<T, NumDims, Allocator>& boost::multi_array<T, NumDims, Allocator>::operator=(const ConstMultiArray&) [with ConstMultiArray = boost::detail::multi_array::multi_array_view<data_t, 1>, T = data_t, unsigned int NumDims = 1, Allocator = std::allocator<data_t>]' b.cpp:53: instantiated from here /home/afit1/fac/jyoung/boost/boost/include/boost-1_31/boost/concept_check.hpp:306: error: ISO C++ says that `typename boost::mpl::apply2<boost::detail::always_bool2, Derived1, Derived2>::type boost::operator!=(const boost::iterator_facade<Derived1, V1, TC1, R1, D1>&, const boost::iterator_facade<Derived2, V2, TC2, R2, D2>&) [with Derived1 = boost::detail::multi_array::array_iterator<data_t, data_t*, boost::mpl::size_t<1>, data_t&>, V1 = data_t, TC1 = boost::random_access_traversal_tag, R1 = data_t&, D1 = ptrdiff_t, Derived2 = boost::detail::multi_array::array_iterator<data_t, data_t*, boost::mpl::size_t<1>, data_t&>, V2 = data_t, TC2 = boost::random_access_traversal_tag, R2 = data_t&, D2 = ptrdiff_t]' and `bool boost::expression::operator!=(T, const boost::expression::expression<Base>&) [with T = boost::detail::multi_array::array_iterator<data_t, data_t*, boost::mpl::size_t<1>, data_t&>, Base = boost::expression::post_increment]' are ambiguous even though the worst conversion for the former is better than the worst conversion for the latter /home/afit1/fac/jyoung/boost/boost/include/boost-1_31/boost/concept_check.hpp:306: error: ISO C++ says that `typename boost::mpl::apply2<boost::detail::always_bool2, Derived1, Derived2>::type boost::operator!=(const boost::iterator_facade<Derived1, V1, TC1, R1, D1>&, const boost::iterator_facade<Derived2, V2, TC2, R2, D2>&) [with Derived1 = boost::detail::multi_array::array_iterator<data_t, data_t*, boost::mpl::size_t<1>, data_t&>, V1 = data_t, TC1 = boost::random_access_traversal_tag, R1 = data_t&, D1 = ptrdiff_t, Derived2 = boost::detail::multi_array::array_iterator<data_t, data_t*, boost::mpl::size_t<1>, data_t&>, V2 = data_t, TC2 = boost::random_access_traversal_tag, R2 = data_t&, D2 = ptrdiff_t]' and `bool boost::expression::operator!=(T, const boost::expression::expression<Base>&) [with T = boost::detail::multi_array::array_iterator<data_t, data_t*, boost::mpl::size_t<1>, data_t&>, Base = boost::expression::post_decrement]' are ambiguous even though the worst conversion for the former is better than the worst conversion for the latter /home/afit1/fac/jyoung/boost/boost/include/boost-1_31/boost/concept_check.hpp: In member function `void boost::EqualityComparableConcept<TT>::constraints() [with TT = boost::detail::multi_array::array_iterator<data_t, const data_t*, boost::mpl::size_t<1>, const data_t&>]': /home/afit1/fac/jyoung/boost/boost/include/boost-1_31/boost/concept_check.hpp:49: instantiated from `void boost::function_requires(boost::mpl::identity<T>*) [with Concept = boost::EqualityComparableConcept<boost::detail::multi_array::array_iterator<data_t, const data_t*, boost::mpl::size_t<1>, const data_t&> >]' /home/afit1/fac/jyoung/boost/boost/include/boost-1_31/boost/iterator/iterator_concepts.hpp:147: instantiated from `void boost_concepts::SinglePassIteratorConcept<Iterator>::constraints() [with Iterator = boost::detail::multi_array::array_iterator<data_t, const data_t*, boost::mpl::size_t<1>, const data_t&>]' /home/afit1/fac/jyoung/boost/boost/include/boost-1_31/boost/concept_check.hpp:49: instantiated from `void boost::function_requires(boost::mpl::identity<T>*) [with Concept = boost_concepts::SinglePassIteratorConcept<boost::detail::multi_array::array_iterator<data_t, const data_t*, boost::mpl::size_t<1>, const data_t&> >]' /home/afit1/fac/jyoung/boost/boost/include/boost-1_31/boost/iterator/iterator_concepts.hpp:165: instantiated from `void boost_concepts::ForwardTraversalConcept<Iterator>::constraints() [with Iterator = boost::detail::multi_array::array_iterator<data_t, const data_t*, boost::mpl::size_t<1>, const data_t&>]' /home/afit1/fac/jyoung/boost/boost/include/boost-1_31/boost/concept_check.hpp:49: instantiated from `void boost::function_requires(boost::mpl::identity<T>*) [with Concept = boost_concepts::ForwardTraversalConcept<boost::detail::multi_array::array_iterator<data_t, const data_t*, boost::mpl::size_t<1>, const data_t&> >]' /home/afit1/fac/jyoung/boost/boost/include/boost-1_31/boost/multi_array/concept_checks.hpp:67: instantiated from `void boost::detail::multi_array::ConstMultiArrayConcept<Array, NumDims>::constraints() [with Array = boost::detail::multi_array::multi_array_view<data_t, 1>, unsigned int NumDims = 1]' /home/afit1/fac/jyoung/boost/boost/include/boost-1_31/boost/concept_check.hpp:49: instantiated from `void boost::function_requires(boost::mpl::identity<T>*) [with Concept = boost::detail::multi_array::ConstMultiArrayConcept<boost::detail::multi_array::multi_array_view<data_t, 1>, 1>]' /home/afit1/fac/jyoung/boost/boost/include/boost-1_31/boost/multi_array/multi_array_ref.hpp:470: instantiated from `boost::multi_array_ref<T, NumDims>& boost::multi_array_ref<T, NumDims>::operator=(const ConstMultiArray&) [with ConstMultiArray = boost::detail::multi_array::multi_array_view<data_t, 1>, T = data_t, unsigned int NumDims = 1]' /home/afit1/fac/jyoung/boost/boost/include/boost-1_31/boost/multi_array.hpp:174: instantiated from `boost::multi_array<T, NumDims, Allocator>& boost::multi_array<T, NumDims, Allocator>::operator=(const ConstMultiArray&) [with ConstMultiArray = boost::detail::multi_array::multi_array_view<data_t, 1>, T = data_t, unsigned int NumDims = 1, Allocator = std::allocator<data_t>]' b.cpp:53: instantiated from here /home/afit1/fac/jyoung/boost/boost/include/boost-1_31/boost/concept_check.hpp:305: error: ISO C++ says that `typename boost::mpl::apply2<boost::detail::always_bool2, Derived1, Derived2>::type boost::operator==(const boost::iterator_facade<Derived1, V1, TC1, R1, D1>&, const boost::iterator_facade<Derived2, V2, TC2, R2, D2>&) [with Derived1 = boost::detail::multi_array::array_iterator<data_t, const data_t*, boost::mpl::size_t<1>, const data_t&>, V1 = data_t, TC1 = boost::random_access_traversal_tag, R1 = const data_t&, D1 = ptrdiff_t, Derived2 = boost::detail::multi_array::array_iterator<data_t, const data_t*, boost::mpl::size_t<1>, const data_t&>, V2 = data_t, TC2 = boost::random_access_traversal_tag, R2 = const data_t&, D2 = ptrdiff_t]' and `bool boost::expression::operator==(T, const boost::expression::expression<Base>&) [with T = boost::detail::multi_array::array_iterator<data_t, const data_t*, boost::mpl::size_t<1>, const data_t&>, Base = boost::expression::post_increment]' are ambiguous even though the worst conversion for the former is better than the worst conversion for the latter /home/afit1/fac/jyoung/boost/boost/include/boost-1_31/boost/concept_check.hpp:305: error: ISO C++ says that `typename boost::mpl::apply2<boost::detail::always_bool2, Derived1, Derived2>::type boost::operator==(const boost::iterator_facade<Derived1, V1, TC1, R1, D1>&, const boost::iterator_facade<Derived2, V2, TC2, R2, D2>&) [with Derived1 = boost::detail::multi_array::array_iterator<data_t, const data_t*, boost::mpl::size_t<1>, const data_t&>, V1 = data_t, TC1 = boost::random_access_traversal_tag, R1 = const data_t&, D1 = ptrdiff_t, Derived2 = boost::detail::multi_array::array_iterator<data_t, const data_t*, boost::mpl::size_t<1>, const data_t&>, V2 = data_t, TC2 = boost::random_access_traversal_tag, R2 = const data_t&, D2 = ptrdiff_t]' and `bool boost::expression::operator==(T, const boost::expression::expression<Base>&) [with T = boost::detail::multi_array::array_iterator<data_t, const data_t*, boost::mpl::size_t<1>, const data_t&>, Base = boost::expression::post_decrement]' are ambiguous even though the worst conversion for the former is better than the worst conversion for the latter /home/afit1/fac/jyoung/boost/boost/include/boost-1_31/boost/concept_check.hpp:49: instantiated from `void boost::function_requires(boost::mpl::identity<T>*) [with Concept = boost::EqualityComparableConcept<boost::detail::multi_array::array_iterator<data_t, const data_t*, boost::mpl::size_t<1>, const data_t&> >]' /home/afit1/fac/jyoung/boost/boost/include/boost-1_31/boost/iterator/iterator_concepts.hpp:147: instantiated from `void boost_concepts::SinglePassIteratorConcept<Iterator>::constraints() [with Iterator = boost::detail::multi_array::array_iterator<data_t, const data_t*, boost::mpl::size_t<1>, const data_t&>]' /home/afit1/fac/jyoung/boost/boost/include/boost-1_31/boost/concept_check.hpp:49: instantiated from `void boost::function_requires(boost::mpl::identity<T>*) [with Concept = boost_concepts::SinglePassIteratorConcept<boost::detail::multi_array::array_iterator<data_t, const data_t*, boost::mpl::size_t<1>, const data_t&> >]' /home/afit1/fac/jyoung/boost/boost/include/boost-1_31/boost/iterator/iterator_concepts.hpp:165: instantiated from `void boost_concepts::ForwardTraversalConcept<Iterator>::constraints() [with Iterator = boost::detail::multi_array::array_iterator<data_t, const data_t*, boost::mpl::size_t<1>, const data_t&>]' /home/afit1/fac/jyoung/boost/boost/include/boost-1_31/boost/concept_check.hpp:49: instantiated from `void boost::function_requires(boost::mpl::identity<T>*) [with Concept = boost_concepts::ForwardTraversalConcept<boost::detail::multi_array::array_iterator<data_t, const data_t*, boost::mpl::size_t<1>, const data_t&> >]' /home/afit1/fac/jyoung/boost/boost/include/boost-1_31/boost/multi_array/concept_checks.hpp:67: instantiated from `void boost::detail::multi_array::ConstMultiArrayConcept<Array, NumDims>::constraints() [with Array = boost::detail::multi_array::multi_array_view<data_t, 1>, unsigned int NumDims = 1]' /home/afit1/fac/jyoung/boost/boost/include/boost-1_31/boost/concept_check.hpp:49: instantiated from `void boost::function_requires(boost::mpl::identity<T>*) [with Concept = boost::detail::multi_array::ConstMultiArrayConcept<boost::detail::multi_array::multi_array_view<data_t, 1>, 1>]' /home/afit1/fac/jyoung/boost/boost/include/boost-1_31/boost/multi_array/multi_array_ref.hpp:470: instantiated from `boost::multi_array_ref<T, NumDims>& boost::multi_array_ref<T, NumDims>::operator=(const ConstMultiArray&) [with ConstMultiArray = boost::detail::multi_array::multi_array_view<data_t, 1>, T = data_t, unsigned int NumDims = 1]' /home/afit1/fac/jyoung/boost/boost/include/boost-1_31/boost/multi_array.hpp:174: instantiated from `boost::multi_array<T, NumDims, Allocator>& boost::multi_array<T, NumDims, Allocator>::operator=(const ConstMultiArray&) [with ConstMultiArray = boost::detail::multi_array::multi_array_view<data_t, 1>, T = data_t, unsigned int NumDims = 1, Allocator = std::allocator<data_t>]' b.cpp:53: instantiated from here /home/afit1/fac/jyoung/boost/boost/include/boost-1_31/boost/concept_check.hpp:306: error: ISO C++ says that `typename boost::mpl::apply2<boost::detail::always_bool2, Derived1, Derived2>::type boost::operator!=(const boost::iterator_facade<Derived1, V1, TC1, R1, D1>&, const boost::iterator_facade<Derived2, V2, TC2, R2, D2>&) [with Derived1 = boost::detail::multi_array::array_iterator<data_t, const data_t*, boost::mpl::size_t<1>, const data_t&>, V1 = data_t, TC1 = boost::random_access_traversal_tag, R1 = const data_t&, D1 = ptrdiff_t, Derived2 = boost::detail::multi_array::array_iterator<data_t, const data_t*, boost::mpl::size_t<1>, const data_t&>, V2 = data_t, TC2 = boost::random_access_traversal_tag, R2 = const data_t&, D2 = ptrdiff_t]' and `bool boost::expression::operator!=(T, const boost::expression::expression<Base>&) [with T = boost::detail::multi_array::array_iterator<data_t, const data_t*, boost::mpl::size_t<1>, const data_t&>, Base = boost::expression::post_increment]' are ambiguous even though the worst conversion for the former is better than the worst conversion for the latter /home/afit1/fac/jyoung/boost/boost/include/boost-1_31/boost/concept_check.hpp:306: error: ISO C++ says that `typename boost::mpl::apply2<boost::detail::always_bool2, Derived1, Derived2>::type boost::operator!=(const boost::iterator_facade<Derived1, V1, TC1, R1, D1>&, const boost::iterator_facade<Derived2, V2, TC2, R2, D2>&) [with Derived1 = boost::detail::multi_array::array_iterator<data_t, const data_t*, boost::mpl::size_t<1>, const data_t&>, V1 = data_t, TC1 = boost::random_access_traversal_tag, R1 = const data_t&, D1 = ptrdiff_t, Derived2 = boost::detail::multi_array::array_iterator<data_t, const data_t*, boost::mpl::size_t<1>, const data_t&>, V2 = data_t, TC2 = boost::random_access_traversal_tag, R2 = const data_t&, D2 = ptrdiff_t]' and `bool boost::expression::operator!=(T, const boost::expression::expression<Base>&) [with T = boost::detail::multi_array::array_iterator<data_t, const data_t*, boost::mpl::size_t<1>, const data_t&>, Base = boost::expression::post_decrement]' are ambiguous even though the worst conversion for the former is better than the worst conversion for the latter ///////////////////////////// CUT HERE/////////////////////////////////
----- Original Message ----- From: "Joel Young" <jdy@cs.brown.edu>
I have some questions. Will it be possible to say
1. typedef boost::rational< big_integer > big_rational.
Yes. In fact, the big_integer_example contains an example where boost::rational<big_integer> is used.
I have not had success using big_integer inside rational. I get concept check errors with the test code below.
<snip code> I managed to get the code to compile by adding 'explicit' to the constructor on line 132 of big_integer.hpp. However, when I tried to run your code under vc7.1 or gcc, the program requested massive amounts of memory and crashed with a write access violation, even when not using boost::rational<big_integer> but boost::rational<long long>. I'm not familiar with the multi_array library, so I cannot investigate it further. best regards, Richard Peters
I'll try that fix out. Don't worry about the code not running. I just hacked down a long sequence of typedefs and declarations from a series of function calls. It doesn't "mean" anything in the form I sent you. I noticed I still left in a bunch of lines. Thanks, Joel -------- From: "Richard Peters" <r.a.peters@student.tue.nl> Date: Fri, 30 Apr 2004 12:42:03 +0200 To: <boost@lists.boost.org> Cc: <jdy@cs.brown.edu> Subj: Re: [Boost] Big integer library ----- Original Message ----- From: "Joel Young" <jdy@cs.brown.edu>
I have some questions. Will it be possible to say
1. typedef boost::rational< big_integer > big_rational.
Yes. In fact, the big_integer_example contains an example where boost::rational<big_integer> is used.
I have not had success using big_integer inside rational. I get concept check errors with the test code below.
<snip code> I managed to get the code to compile by adding 'explicit' to the constructor on line 132 of big_integer.hpp. However, when I tried to run your code under vc7.1 or gcc, the program requested massive amounts of memory and crashed with a write access violation, even when not using boost::rational<big_integer> but boost::rational<long long>. I'm not familiar with the multi_array library, so I cannot investigate it further. best regards, Richard Peters
Richard, From: "Richard Peters" <r.a.peters@student.tue.nl>
I managed to get the code to compile by adding 'explicit' to the constructor on line 132 of big_integer.hpp.
That fix worked, in that my code compiles and runs. The catch is now that the code is at least two orders of magnitude slower using boost::rational<boost::big_integer> for the core data_t vs using cln::cl_RA if I run using double as the data_t my alg takes 0.14 seconds cpu. with cln::cl_RA it takes 90 seconds cpu, with boost::rational<boost::big_integer> it is taking more than 40 minutes and is still running (less than 1/3 complete). I'll let it run through lunch, and then if it is still churning, I'll break it and check if it is stuck in a loop. I am working with numbers extremely close to zero so I can't challenging problems for exact solutions with boost::rational<long long> to get a timing comparison to see if rational is the bottleneck or big_integer. The work done up to the point where the running program is stuck at now checks out as exactly correct. Joel
From: "Joel Young" <jdy@cs.brown.edu>
Richard,
From: "Richard Peters" <r.a.peters@student.tue.nl>
I managed to get the code to compile by adding 'explicit' to the
constructor
on line 132 of big_integer.hpp.
That fix worked, in that my code compiles and runs. The catch is now that the code is at least two orders of magnitude slower using boost::rational<boost::big_integer> for the core data_t vs using cln::cl_RA
if I run using double as the data_t my alg takes 0.14 seconds cpu. with cln::cl_RA it takes 90 seconds cpu, with boost::rational<boost::big_integer> it is taking more than 40 minutes and is still running (less than 1/3 complete). I'll let it run through lunch, and then if it is still churning, I'll break it and check if it is stuck in a loop.
I am working with numbers extremely close to zero so I can't challenging problems for exact solutions with boost::rational<long long> to get a timing comparison to see if rational is the bottleneck or big_integer.
The work done up to the point where the running program is stuck at now checks out as exactly correct.
Joel
I guess you can't use boost::rational<cln::cl_I> for comparison here? I noticed that my division algorithm can be quite slow in some instances. When dividing an integer by another, it first makes a guess and then starts subtracting in a loop (around line 318 in big_integer_impl.hpp). It should refine its first guess in a more subtle way, but implementing that is still a todo item. I'll let you know when it is done. Besides from that, the rest of the code also hasn't seen much optimization yet, so the problem may be somewhere else. best regards, Richard Peters
"Richard Peters" <r.a.peters@student.tue.nl> writes:
I guess you can't use boost::rational<cln::cl_I> for comparison here? I noticed that my division algorithm can be quite slow in some instances. When dividing an integer by another, it first makes a guess and then starts subtracting in a loop (around line 318 in big_integer_impl.hpp). It should refine its first guess in a more subtle way, but implementing that is still a todo item. I'll let you know when it is done. Besides from that, the rest of the code also hasn't seen much optimization yet, so the problem may be somewhere else.
I seriously hope you're using Knuth Vol II (Seminumerical Algorithms) for this. He covers everything ;-) -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
Hello, Perhaps it's just me being inattentive or Boost.Lambda lacks some feature I would consider quite useful. Rummaging through documentation and source code did not turn out to be constructive. Well, the problem is: struct foo { template<typename ExprT> typename ExprT::result_type operator[](ExprT expr) { return expr(/*params here*/); } }; Umm... We can write as follows then: foo bar; bar[ some_stl_conformant_unary_functor() // or binary, or whatever... compiles OK ]; It would be nice to write little lambda expressions too, bar[ std::cout << _1 // Fails miserably ]; for example. The problem is that lambda expressions do not have result_type defined although technically they are functors too (like STL functors). It would be trivial to write little metafunction wrapper though. After all, boost::lambda::is_lambda_functor metafunction exists but I haven't found lambda_result_type traits or something like that. Documentation conveniently skips through that part of implementation and code is a bit obscure at times. Is there a way to implement such a metafunction boost::lambda::functor_result<T>::type that it would return result type of lambda expression if T is lambda expression or T::result_type if T is ordinary STL functor, or just null_type if neither of them? that its implementation would not turn out to be a pain in the... emm... neck? Or perhaps this could be a part of Boost.Lambda library? Regards, Justinas V.D.
On Thu, Apr 29, 2004 at 10:05:19PM +0300, Justinas V.D. wrote:
The problem is that lambda expressions do not have result_type defined although technically they are functors too (like STL functors). It would be trivial to write little metafunction wrapper though. After all, boost::lambda::is_lambda_functor metafunction exists but I haven't found lambda_result_type traits or something like that. Documentation conveniently skips through that part of implementation and code is a bit obscure at times.
Is there a way to implement such a metafunction
boost::lambda::functor_result<T>::type that it would return result type of lambda expression if T is lambda expression or T::result_type if T is ordinary STL functor, or just null_type if neither of them?
that its implementation would not turn out to be a pain in the... emm... neck? Or perhaps this could be a part of Boost.Lambda library?
I think what you want is result_of. http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1454.html Last I heard, a complete implementation had not yet made it into Boost. Douglas? I think maybe Boost.Lambda already has the implementation support for it, we just need the main result_of interface. To Douglas: I am starting to have a little free time again, so if you want help implementing it or making some tests, I will help here. -- -Brian McNamara (lorgon@cc.gatech.edu)
On Thursday 29 April 2004 04:15 pm, Brian McNamara wrote:
Last I heard, a complete implementation had not yet made it into Boost. Douglas? I think maybe Boost.Lambda already has the implementation support for it, we just need the main result_of interface.
To Douglas: I am starting to have a little free time again, so if you want help implementing it or making some tests, I will help here.
I think I have some free time as well... I'll need to get reacquainted with the existing result_of code (in the sandbox) before I know what to ask for. Doug
On Saturday 01 May 2004 11:45 am, Douglas Gregor wrote:
I think I have some free time as well... I'll need to get reacquainted with the existing result_of code (in the sandbox) before I know what to ask for.
It looks like the result_of implementation is in pretty good shape. I've expanded/fixed it to deal with a few cases I'd missed before. I'll check it in Two general issues remain: "support" for broken compilers and a matter of protocol. Broken compilers can't use result_of: without partial specialization, it's completely unusable. Also, compilers that don't support SFINAE can't detect result_type. I'm not sure how limiting this will be, but obvious Borland, HP, and pre-7.1 Microsoft are all toast. As for the protocol side of things: does anyone think we need to review a library that is (1) merely scaffolding for other libraries, (2) trivial, and (3) already blessed by the standards committee? Methinks not. Doug
Douglas Gregor <gregod@cs.rpi.edu> writes:
On Saturday 01 May 2004 11:45 am, Douglas Gregor wrote:
I think I have some free time as well... I'll need to get reacquainted with the existing result_of code (in the sandbox) before I know what to ask for.
It looks like the result_of implementation is in pretty good shape. I've expanded/fixed it to deal with a few cases I'd missed before. I'll check it in Two general issues remain: "support" for broken compilers and a matter of protocol.
Broken compilers can't use result_of: without partial specialization, it's completely unusable. Also, compilers that don't support SFINAE can't detect result_type. I'm not sure how limiting this will be, but obvious Borland, HP, and pre-7.1 Microsoft are all toast.
As for the protocol side of things: does anyone think we need to review a library that is (1) merely scaffolding for other libraries, (2) trivial, and (3) already blessed by the standards committee? Methinks not.
We probably don't need to. Maybe we should anyway, just to give the fast track review process some exercise? I don't really have a position on what the answer should be. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
On Sun, 02 May 2004 09:29:37 -0400, David Abrahams wrote
As for the protocol side of things: does anyone think we need to review a library that is (1) merely scaffolding for other libraries, (2) trivial, and (3) already blessed by the standards committee? Methinks not.
We probably don't need to. Maybe we should anyway, just to give the fast track review process some exercise? I don't really have a position on what the answer should be.
Given that we still have 7 reviews on the backlog it isn't really a good time to test out the process. And given #2, #3, and that it is a small extension to an already existing library it seems it doesn't seem to qualify for review anyway. Jeff
"Jeff Garland" <jeff@crystalclearsoftware.com> writes:
On Sun, 02 May 2004 09:29:37 -0400, David Abrahams wrote
As for the protocol side of things: does anyone think we need to review a library that is (1) merely scaffolding for other libraries, (2) trivial, and (3) already blessed by the standards committee? Methinks not.
We probably don't need to. Maybe we should anyway, just to give the fast track review process some exercise? I don't really have a position on what the answer should be.
Given that we still have 7 reviews on the backlog it isn't really a good time to test out the process. And given #2, #3, and that it is a small extension to an already existing library it seems it doesn't seem to qualify for review anyway.
OK -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
On 5/2/04 12:03 AM, "Douglas Gregor" <gregod@cs.rpi.edu> wrote:
On Saturday 01 May 2004 11:45 am, Douglas Gregor wrote:
I think I have some free time as well... I'll need to get reacquainted with the existing result_of code (in the sandbox) before I know what to ask for.
It looks like the result_of implementation is in pretty good shape. I've expanded/fixed it to deal with a few cases I'd missed before. I'll check it in Two general issues remain: "support" for broken compilers and a matter of protocol.
Broken compilers can't use result_of: without partial specialization, it's completely unusable. Also, compilers that don't support SFINAE can't detect result_type. I'm not sure how limiting this will be, but obvious Borland, HP, and pre-7.1 Microsoft are all toast.
As for the protocol side of things: does anyone think we need to review a library that is (1) merely scaffolding for other libraries, (2) trivial, and (3) already blessed by the standards committee? Methinks not.
There's documentation, right? Could anything outside of Boost internals have a use for "result_of"? Have other people looked at it? (You could have missed something and not realize it.) Didn't we have an incident at the last release where some "innoncent" code was just plunked in at the last minute and broke a lot of stuff during testing? Let's not do that again. Maybe it can go under a quick-review. -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com
On Sun, 2 May 2004, Daryle Walker wrote:
On 5/2/04 12:03 AM, "Douglas Gregor" <gregod@cs.rpi.edu> wrote: There's documentation, right?
Yep.
Could anything outside of Boost internals have a use for "result_of"?
Yep.
Have other people looked at it? (You could have missed something and not realize it.) [snip] Maybe it can go under a quick-review.
It's in CVS now. Code in boost/utility/result_of.hpp and boost/utility/detail/result_of_iterate.hpp, test in libs/utility/test/result_of_test.cpp, and docs in libs/utility/utility.htm. Doug
Douglas Paul Gregor wrote:
It's in CVS now. Code in boost/utility/result_of.hpp and boost/utility/detail/result_of_iterate.hpp, test in libs/utility/test/result_of_test.cpp, and docs in libs/utility/utility.htm.
Definitely useful utility this one is. Documentation is sufficient, OTOH result_of is intuitive to use, and very nicely fits in project outside of boost internals. I'm glad that Mr. Gregor finally provided this utility and I'm looking forward seing this in boost release, if possible. On the other hand, more explicit error reporting would be nice as well. For example, #endif // can't use result_of #endif // BOOST_RESULT_OF_HPP perhaps would be constructive to extend so that #else // can't use result_of # error <appriopriate error message here> #endif #endif // BOOST_RESULT_OF_HPP Otherwise, I think, everything is fine. I'd love to see Boost.Lambda using this, just for sake of consistency. Regards, Justinas V.D.
Hi, Brian replied to this already, and pointed out that what you want is the result_of template. That's not yet part of BLL. There's a similar mechanism though (sig template) that is explained in section 5.3.4. Note that just the std result_type typedef is not an adequate mechanism for expressing the return type of a lambda functor (which is polymorphic). See below...
Perhaps it's just me being inattentive or Boost.Lambda lacks some feature I would consider quite useful. Rummaging through documentation and source code did not turn out to be constructive.
Well, the problem is:
struct foo { template<typename ExprT> typename ExprT::result_type operator[](ExprT expr) { return expr(/*params here*/); } };
If ExprT is a lambda functor, say -_1, the return type is not detemined by ExprT alone, but rather by ExprT and the type of the argument with which the lambda functor is called. float f; int i; (-_1)(f) // returns float (-_1)(i) // returns int Jaakko
Umm... We can write as follows then:
foo bar;
bar[ some_stl_conformant_unary_functor() // or binary, or whatever... compiles OK ];
It would be nice to write little lambda expressions too, bar[ std::cout << _1 // Fails miserably ]; for example.
The problem is that lambda expressions do not have result_type defined although technically they are functors too (like STL functors). It would be trivial to write little metafunction wrapper though. After all, boost::lambda::is_lambda_functor metafunction exists but I haven't found lambda_result_type traits or something like that. Documentation conveniently skips through that part of implementation and code is a bit obscure at times.
Is there a way to implement such a metafunction
boost::lambda::functor_result<T>::type that it would return result type of lambda expression if T is lambda expression or T::result_type if T is ordinary STL functor, or just null_type if neither of them?
that its implementation would not turn out to be a pain in the... emm... neck? Or perhaps this could be a part of Boost.Lambda library?
Regards, Justinas V.D.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
participants (4)
-
Brian McNamara -
Daryle Walker -
David Abrahams -
Douglas Gregor -
Douglas Paul Gregor
-
Jaakko -
Jeff Garland -
Joel Young -
Justinas V.D. -
Richard Peters