removed the check because it makes absolutely no sense
TODO: check the strange "optimization" of lower bound.
svn path=/trunk/boost/numeric/ublas/; revision=49578
removed the check because it makes absolutely no sense
TODO: check the strange "optimization" of lower bound.
svn path=/trunk/boost/numeric/ublas/; revision=49578
- the exception was caused when trying to erase an empty range
- now erase(it1, it2) does nothing if it1 == it2
svn path=/trunk/boost/numeric/ublas/; revision=49576
- the exception was caused when trying to erase an empty range
- now erase(it1, it2) does nothing if it1 == it2
svn path=/trunk/boost/numeric/ublas/; revision=49576
Fixes#2392.
Change includes of <cmath> to <boost/config/no_tr1/config.hpp>.
Previously if Boost.TR1 was in the include path then including <cmath> pulls in all the new TR1 math functions, which in turn also requires linking to an external library. With auto-linking support this requires that library to have been built and be present in the library search path, even if the actual library under use is header only.
[SVN r49314]
Fixes#2392.
Change includes of <cmath> to <boost/config/no_tr1/config.hpp>.
Previously if Boost.TR1 was in the include path then including <cmath> pulls in all the new TR1 math functions, which in turn also requires linking to an external library. With auto-linking support this requires that library to have been built and be present in the library search path, even if the actual library under use is header only.
svn path=/branches/release/boost/numeric/ublas/; revision=49314
Fixes#2392.
Change includes of <cmath> to <boost/config/no_tr1/config.hpp>.
Previously if Boost.TR1 was in the include path then including <cmath> pulls in all the new TR1 math functions, which in turn also requires linking to an external library. With auto-linking support this requires that library to have been built and be present in the library search path, even if the actual library under use is header only.
svn path=/branches/release/boost/numeric/ublas/; revision=49314
Previously if Boost.TR1 was in the include path then including <cmath> pulls in all the new TR1 math functions, which in turn also requires linking to an external library. With auto-linking support this requires that library to have been built and be present in the library search path, even if the actual library under use is header only.
Fixes#2392.
svn path=/trunk/boost/numeric/ublas/; revision=49254
Previously if Boost.TR1 was in the include path then including <cmath> pulls in all the new TR1 math functions, which in turn also requires linking to an external library. With auto-linking support this requires that library to have been built and be present in the library search path, even if the actual library under use is header only.
Fixes#2392.
svn path=/trunk/boost/numeric/ublas/; revision=49254
Previously if Boost.TR1 was in the include path then including <cmath> pulls in all the new TR1 math functions, which in turn also requires linking to an external library. With auto-linking support this requires that library to have been built and be present in the library search path, even if the actual library under use is header only.
Fixes#2392.
[SVN r49254]
Previously if Boost.TR1 was in the include path then including <cmath> pulls in all the new TR1 math functions, which in turn also requires linking to an external library. With auto-linking support this requires that library to have been built and be present in the library search path, even if the actual library under use is header only.
Fixes#2392.
- fixed problem that iterator1 and iterator2 of triangular matrices (and related) sometimes
pointed to wrong element or outside the storage
[SVN r48756]
- fixed problem that iterator1 and iterator2 of triangular matrices (and related) sometimes
pointed to wrong element or outside the storage
svn path=/branches/release/boost/numeric/ublas/; revision=48756
- fixed problem that iterator1 and iterator2 of triangular matrices (and related) sometimes
pointed to wrong element or outside the storage
svn path=/branches/release/boost/numeric/ublas/; revision=48756
- added missing changes of triangular_adaptor (see rev. 48466)
- fixed order of arguments in functional basic_strict_lower::global_restrict1(...)
svn path=/trunk/boost/numeric/ublas/; revision=48523
- added missing changes of triangular_adaptor (see rev. 48466)
- fixed order of arguments in functional basic_strict_lower::global_restrict1(...)
svn path=/trunk/boost/numeric/ublas/; revision=48523
- added missing changes of triangular_adaptor (see rev. 48466)
- fixed order of arguments in functional basic_strict_lower::global_restrict1(...)
[SVN r48523]
- complete redesign of functionals lower, unit_lower and strict_lower
- added new transpose_structure<L> class that converts a "lower" functional to an "upper" functional
- fixed find1(...) and find2(...) methods of triangular_matrix
- the attachement of taks #2272 now runs fine with gcc 4.1.2
svn path=/trunk/boost/numeric/ublas/; revision=48466
- complete redesign of functionals lower, unit_lower and strict_lower
- added new transpose_structure<L> class that converts a "lower" functional to an "upper" functional
- fixed find1(...) and find2(...) methods of triangular_matrix
- the attachement of taks #2272 now runs fine with gcc 4.1.2
svn path=/trunk/boost/numeric/ublas/; revision=48466
- complete redesign of functionals lower, unit_lower and strict_lower
- added new transpose_structure<L> class that converts a "lower" functional to an "upper" functional
- fixed find1(...) and find2(...) methods of triangular_matrix
- the attachement of taks #2272 now runs fine with gcc 4.1.2
[SVN r48466]
- complete redesign of functionals lower, unit_lower and strict_lower
- added new transpose_structure<L> class that converts a "lower" functional to an "upper" functional
- fixed find1(...) and find2(...) methods of triangular_matrix
- the attachement of taks #2272 now runs fine with gcc 4.1.2
