Re: [boost] [units] Pull request and RFC: information unit definitions for Boost.Units
Hi all, I have created a pull request building on top of Erik's proposal. It adds missing zebi and yobi prefixes as defined by IEC. I have also added tests for these prefixes. The only thing is that zebi (2^70) and yobi (2*80) are too large for *long long int*, so I test them with boost::multiprecision::int128_t. Link to PR: https://github.com/boostorg/units/pull/6 Description: I have added zebi and yobi IEC prefixes and corresponding tests for completeness taking Erik's pull request as a base. I am not sure if creating a new PR is a good solution or if there is any way to add a commit directly to the existing one. If you know a better way, I would appreciate any information. Regards, Marek Kurdej I would love to pass the responsibility for ongoing maintenance of
Boost.Units on to a new torchbearer. My time to dedicate to this project has dwindled to essentially zero, and I believe it would be best for all involved to enlist some fresh blood, ideally someone who is using the library on a regular basis... Any volunteers? As far as Erik's request, I don't have any objections to adding these to the library, though I have not had time myself to verify that they are correct. Matthias
----- Original Message -----
Link to PR: https://github.com/boostorg/units/pull/3
Description: Adds unit definitions for standard units of information: bit, byte,
nat,
hartley, shannon. Defines a new unit system boost::units::information for convenient manipulation. Also includes IEC binary prefixes: kibi, mebi, gibi, tebi, pebi, exbi
Example code:
https://github.com/erikerlandson/units/blob/info_units/example/information.c...
Unit testing code:
https://github.com/erikerlandson/units/blob/info_units/test/test_information...
I've been unable to raise a response from either Steven Watanabe or
Matthias Schabel, either on- or off-list. It would be nice to get a thumbs up or thumbs down so I can make a decision on how to proceed with my other project.
Hi Marek, Am Friday, 1. August 2014, 12:50:11 schrieb Curdeius Curdeius:
Hi all,
I have created a pull request building on top of Erik's proposal. It adds missing zebi and yobi prefixes as defined by IEC. I have also added tests for these prefixes. The only thing is that zebi (2^70) and yobi (2*80) are too large for *long long int*, so I test them with boost::multiprecision::int128_t.
Link to PR: https://github.com/boostorg/units/pull/6
Description: I have added zebi and yobi IEC prefixes and corresponding tests for completeness taking Erik's pull request as a base.
I've now looked at them and this looks fine so far. But I'm missing the needed documentation for the new functionality. Can you add some? And there is not need to prefix the commit message with "[Boost] [Units]", the context is clear :-)
I am not sure if creating a new PR is a good solution or if there is any way to add a commit directly to the existing one. If you know a better way, I would appreciate any information.
As far as I know, that it okay. I've been able to pull both commits to my working copy without problems. Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! * voice: ++49 4257 300 ! Fährstraße 1 * fax : ++49 4257 300 ! 31609 Balge/Sebbenhausen * jhunold@gmx.eu ! Germany
----- Original Message -----
Hi Marek,
Am Friday, 1. August 2014, 12:50:11 schrieb Curdeius Curdeius:
Hi all,
I have created a pull request building on top of Erik's proposal. It adds missing zebi and yobi prefixes as defined by IEC. I have also added tests for these prefixes. The only thing is that zebi (2^70) and yobi (2*80) are too large for *long long int*, so I test them with boost::multiprecision::int128_t.
Link to PR: https://github.com/boostorg/units/pull/6
Description: I have added zebi and yobi IEC prefixes and corresponding tests for completeness taking Erik's pull request as a base.
I've now looked at them and this looks fine so far. But I'm missing the needed documentation for the new functionality. Can you add some?
Good point. As I recall, I held off on doc because I could not figure out where unit-specific docs actually lived. In fact I couldn't find doc for any of the existing units, it was all more general description of how the library worked. Is there an established place for information unit doc to live?
And there is not need to prefix the commit message with "[Boost] [Units]", the context is clear :-)
I am not sure if creating a new PR is a good solution or if there is any way to add a commit directly to the existing one. If you know a better way, I would appreciate any information.
As far as I know, that it okay. I've been able to pull both commits to my working copy without problems.
Yours,
Jürgen -- * Dipl.-Math. Jürgen Hunold ! * voice: ++49 4257 300 ! Fährstraße 1 * fax : ++49 4257 300 ! 31609 Balge/Sebbenhausen * jhunold@gmx.eu ! Germany
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
AMDG On 08/22/2014 08:55 AM, Erik Erlandson wrote:
----- Original Message -----
I've now looked at them and this looks fine so far. But I'm missing the needed documentation for the new functionality. Can you add some?
Good point. As I recall, I held off on doc because I could not figure out where unit-specific docs actually lived. In fact I couldn't find doc for any of the existing units, it was all more general description of how the library worked. Is there an established place for information unit doc to live?
I think there's a list of units in the reference. You could create a table near that listing all the prefixes. In Christ, Steven Watanabe
Congratulations Jürgen! Let me know what can I improve on [0] to get the pull-request merged. Best of luck, Gonzalo [0] https://github.com/boostorg/units/pull/1 On Fri, Aug 22, 2014 at 5:27 PM, Steven Watanabe <watanabesj@gmail.com> wrote:
AMDG
On 08/22/2014 08:55 AM, Erik Erlandson wrote:
----- Original Message -----
I've now looked at them and this looks fine so far. But I'm missing the needed documentation for the new functionality. Can you add some?
Good point. As I recall, I held off on doc because I could not figure
out where unit-specific docs actually lived. In fact I couldn't find doc for any of the existing units, it was all more general description of how the library worked. Is there an established place for information unit doc to live?
I think there's a list of units in the reference. You could create a table near that listing all the prefixes.
In Christ, Steven Watanabe
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Hi Gonzalo, Am Montag, 25. August 2014, 12:33:49 schrieb Gonzalo BG:
Congratulations Jürgen!
Thanks!
Let me know what can I improve on [0] to get the pull-request merged.
Well, the usual suspects are missing: - Tests - Documentation. - (Examples) Any new feature should be tested. Especially if we want to find out which compilers support it :-) Documenting the feature is necessary for new and old users to discover it. And I'd like a snappy sentence to add to the release notes. Some minor nitpicks: - The patch also changes unrelated whitespace like line-endings, removes empty lines and changes wrapping. This should go into a separate pull request if necessary. - The patch also removes some code blocks currently commented out. This should be done in a separate request, too. I'm without internet access from Friday, 30.8.2014 until 06.9.2014 and fully available from Monday, 15.9.2014. Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! * voice: ++49 4257 300 ! Fährstraße 1 * fax : ++49 4257 300 ! 31609 Balge/Sebbenhausen * jhunold@gmx.eu ! Germany
On Wed, Aug 27, 2014 at 12:21 PM, Jürgen Hunold <jhunold@gmx.eu> wrote:
- Documentation: - (Examples)
I'll add a small section to the documentation with an constexpr example. The (automatically generated?) API reference documentation already includes the BOOST_CONSTEXPR in the data-types member functions which should be self-explanatory. I'll ping you when I update the PR and we can discuss there how to improve the documentation further but basically either you can use Boost.Units in constant expressions or you can't.
- Tests
I have some unit-tests but removed them because I wasn't able to enable them only for compilers with constexpr support (otherwise they will fail to compile). Boost.Build/Boost.Test documentation wasn't very helpful in this regard. I just went through Boost.Array develop branch and found: https://github.com/boostorg/array/blob/develop/test/array_constexpr.cpp Should I implement the constexpr tests in a similar manner or do anything differently?
And I'd like a snappy sentence to add to the release notes.
I'll add "Boost.Units has gained constexpr support." to the commit message.
- The patch also changes unrelated whitespace like line-endings, removes empty lines and changes wrapping. This should go into a separate pull request if necessary. - The patch also removes some code blocks currently commented out. This should be done in a separate request, too.
I was just following the boy scout rule but will revert them. I won't create a new pull-request with these but I since navigating the code in a 80char terminal was a bit unpleasant I would be happy if you consider some of them in the future. Bests, Gonzalo
Hi Gonzalo, Am Mittwoch, 27. August 2014, 12:49:49 schrieb Gonzalo BG:
On Wed, Aug 27, 2014 at 12:21 PM, Jürgen Hunold <jhunold@gmx.eu> wrote:
- Documentation: - (Examples)
I'll add a small section to the documentation with an constexpr example. The (automatically generated?) API reference documentation already includes the BOOST_CONSTEXPR in the data-types member functions which should be self-explanatory.
Yes, doxygen driven
I'll ping you when I update the PR and we can discuss there how to improve the documentation further but basically either you can use Boost.Units in constant expressions or you can't.
Sounds reasonably
- Tests
I have some unit-tests but removed them because I wasn't able to enable them only for compilers with constexpr support (otherwise they will fail to compile).
Great news.
Boost.Build/Boost.Test documentation wasn't very helpful in this regard.
Unfortunately. Just get the test to work with compliant compilers and I'll have a look.
I just went through Boost.Array develop branch and found:
https://github.com/boostorg/array/blob/develop/test/array_constexpr.cpp
Should I implement the constexpr tests in a similar manner or do anything differently?
No, this is a valid approach for me. Complicating the Boost.Build logic for the tests is not necessary.
And I'd like a snappy sentence to add to the release notes.
I'll add "Boost.Units has gained constexpr support." to the commit message.
Thanks.
- The patch also changes unrelated whitespace like line-endings, removes
empty
lines and changes wrapping. This should go into a separate pull request if necessary. - The patch also removes some code blocks currently commented out. This
should
be done in a separate request, too.
I was just following the boy scout rule but will revert them.
Well, I try to separate the style changes while editing the commits. This one of the reasons I really like git(k) :-) Following the boy scout rule is fine otherwise.
I won't create a new pull-request with these but I since navigating the code in a 80char terminal was a bit unpleasant I would be happy if you consider some of them in the future.
Well, 80 chars is quite small, I'd raise the bar to 120 or so myself. I think I'll revisit the changes when reviewing your updated PR. Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! * voice: ++49 4257 300 ! Fährstraße 1 * fax : ++49 4257 300 ! 31609 Balge/Sebbenhausen * jhunold@gmx.eu ! Germany
participants (5)
-
Curdeius Curdeius -
Erik Erlandson -
Gonzalo BG -
Jürgen Hunold -
Steven Watanabe