[modularization] How to remove the Math -> multuplecission dependency?
Hi,
John, ther is a cycle between multuprecision and Math.
how can this dependency be removed?
/math ->multiprecision/
http://www.pdimov.com/tmp/report-6d1f271/multiprecision.html
|
John, ther is a cycle between multuprecision and Math.
I know.
how can this dependency be removed?
/math ->multiprecision/ http://www.pdimov.com/tmp/report-6d1f271/multiprecision.html
|
| * from |
|
I would argue it's a "false positive": the header generate.hpp is a maintenance header used for generating new numeric constants, and the dependency to multiprecision is optional (inside #ifdef's). It is however documented, so I'm loathed to just move it. There are quite a few of Math's dependencies that are introduced via similar headers that exist for maintenance/testing/optional use, and are not included by any of the "include everything" entry point headers. John.
John Maddock wrote:
I would argue it's a "false positive": the header generate.hpp is a maintenance header used for generating new numeric constants, and the dependency to multiprecision is optional (inside #ifdef's). It is however documented, so I'm loathed to just move it. There are quite a few of Math's dependencies that are introduced via similar headers that exist for maintenance/testing/optional use, and are not included by any of the "include everything" entry point headers.
Yes, Math has headers such as
On 6/6/2014 7:09 AM, Peter Dimov wrote:
John Maddock wrote:
I would argue it's a "false positive": the header generate.hpp is a maintenance header used for generating new numeric constants, and the dependency to multiprecision is optional (inside #ifdef's). It is however documented, so I'm loathed to just move it. There are quite a few of Math's dependencies that are introduced via similar headers that exist for maintenance/testing/optional use, and are not included by any of the "include everything" entry point headers.
Yes, Math has headers such as
and that are probably only needed by its tests, and could have been in the test/ directory instead of include/. could have been in libs/math/minimax, and so on.
Despite possible maintenance complications Boost might want to explore the idea of separate git submodules for a library's implementation code/documentation and a library's tests. That way an end-user's dependencies on a given library would be reduced if use of that library does not include test dependencies.
I would argue it's a "false positive": the header generate.hpp is a maintenance header used for generating new numeric constants, and the dependency to multiprecision is optional (inside #ifdef's). It is however documented, so I'm loathed to just move it. There are quite a few of Math's dependencies that are introduced via similar headers that exist for maintenance/testing/optional use, and are not included by any of the "include everything" entry point headers.
Yes, Math has headers such as
and that are probably only needed by its tests, and could have been in the test/ directory instead of include/. could have been in libs/math/minimax, and so on. Despite possible maintenance complications Boost might want to explore the idea of separate git submodules for a library's implementation code/documentation and a library's tests. That way an end-user's dependencies on a given library would be reduced if use of that library does not include test dependencies.
Indeed, but libraries may still have optional headers, and/or "bridging" headers that glue two libraries together. All the headers we're talking about are documented (at least to some degree), and are intended for end users to at least experiment with. They're just not core to Boost.Math, more like "fringe" if you prefer. John.
Le 06/06/14 17:29, John Maddock a écrit :
Indeed, but libraries may still have optional headers, and/or "bridging" headers that glue two libraries together. All the headers we're talking about are documented (at least to some degree), and are intended for end users to at least experiment with. They're just not core to Boost.Math, more like "fringe" if you prefer.
I would opt in these cases to add a Math.Multiprecision submodule Math.Multiprecision -> Multiprecision -> Math This makes clear that these files are not associated to the Math core, but to something optional. Vicente
Le 06/06/14 19:37, Vicente J. Botet Escriba a écrit :
Le 06/06/14 17:29, John Maddock a écrit :
Indeed, but libraries may still have optional headers, and/or "bridging" headers that glue two libraries together. All the headers we're talking about are documented (at least to some degree), and are intended for end users to at least experiment with. They're just not core to Boost.Math, more like "fringe" if you prefer.
I would opt in these cases to add a Math.Multiprecision submodule
Math.Multiprecision -> Multiprecision -> Math
This makes clear that these files are not associated to the Math core, but to something optional.
John, please could you comment this point? Best, Vicente
Indeed, but libraries may still have optional headers, and/or "bridging" headers that glue two libraries together. All the headers we're talking about are documented (at least to some degree), and are intended for end users to at least experiment with. They're just not core to Boost.Math, more like "fringe" if you prefer.
I would opt in these cases to add a Math.Multiprecision submodule
Math.Multiprecision -> Multiprecision -> Math
This makes clear that these files are not associated to the Math core, but to something optional.
John, please could you comment this point?
Sorry I'm backlogged, I'm going to try and tidy up some of Math's headers soon. John.
Le 06/06/14 09:55, John Maddock a écrit :
John, ther is a cycle between multuprecision and Math.
I know.
how can this dependency be removed?
/math ->multiprecision/ http://www.pdimov.com/tmp/report-6d1f271/multiprecision.html
|
| * from |
| I would argue it's a "false positive": the header generate.hpp is a maintenance header used for generating new numeric constants, and the dependency to multiprecision is optional (inside #ifdef's). It is however documented, so I'm loathed to just move it. There are quite a few of Math's dependencies that are introduced via similar headers that exist for maintenance/testing/optional use, and are not included by any of the "include everything" entry point headers.
I don't mind for the other optional dependencies. The issue with this one is that it introduce a cycle. It would be great if this cycle can be broken but of course, there is nothing in Boost rules that force us to don't have cycles :) Vicente
participants (4)
-
Edward Diener -
John Maddock -
Peter Dimov -
Vicente J. Botet Escriba