[ratio] Assignation between equivalent ratios
Hi, I was wondering if we need to be able to make assignations between equivalent ratios. e.g. ratio<1,3> r1; ratio<3,9> r2; r1 = r2; // (1) Reading N3000 even if they are equivalents (synonym ) as its num and den are the same, there is no defined assignation. So (1) should not compile with the current recomendation. IMO, this should compile, and so we need to add a specific assignement operator. Other example ratio<1,3> r1; ratio<2,3> r2; r1 = r2-r1; // the type of this expression could be ratio<3,9> so the compilation fails. Otherwise the recomendation should clarify the meaning of synonym on the ratio arithmetic operators [ratio.arithmetic] 2 "The nested typedef type shall be a synonym for ratio<T1, T2> where T1 has the value R1::num * R2::den + R2::num * R1::den and T2 has the value R1::den * R2::den." Maybe we should talk of normalized ratio and not of synonym. BTW, where is synonym defined? In addition I think that we need also to add that the declaration of no normalized ratios, as ratio<3,9>, must fail at compile time as it is not normalized and we can not assigne nothing to them. I'm missing something? Any thougths? Best regards _____________________ Vicente Juan Botet Escribá
On Dec 6, 2009, at 1:33 PM, vicente.botet wrote:
Hi,
I was wondering if we need to be able to make assignations between equivalent ratios. e.g.
ratio<1,3> r1;
ratio<3,9> r2;
r1 = r2; // (1)
Reading N3000 even if they are equivalents (synonym ) as its num and den are the same, there is no defined assignation. So (1) should not compile with the current recomendation.
IMO, this should compile, and so we need to add a specific assignement operator.
Other example
ratio<1,3> r1;
ratio<2,3> r2;
r1 = r2-r1; // the type of this expression could be ratio<3,9> so the compilation fails.
Otherwise the recomendation should clarify the meaning of synonym on the ratio arithmetic operators [ratio.arithmetic] 2
"The nested typedef type shall be a synonym for ratio<T1, T2> where T1 has the value R1::num *
R2::den + R2::num * R1::den and T2 has the value R1::den * R2::den."
Maybe we should talk of normalized ratio and not of synonym. BTW, where is synonym defined?
In addition I think that we need also to add that the declaration of no normalized ratios, as ratio<3,9>, must fail at compile time as it is not normalized and we can not assigne nothing to them.
I'm missing something? Any thougths?
Hi Vicente, I think you've made a good observation. The original intent was to just have the special members of <ratio> governed by [functions.within.classes]. However your example code has given me pause for thought. I haven't found any motivating use cases for the assignment operator. But I can easily think of motivating uses for the copy constructor (and having the assignment operator be consistent, with the copy constructor, motivating cases or not, makes sense). I'm experimenting with the following special members and things look good to me: ratio() {} template <intmax_t _N2, intmax_t _D2> ratio(const ratio<_N2, _D2>&, typename enable_if < ratio<_N2, _D2>::num == num && ratio<_N2, _D2>::den == den >::type* = 0) {} template <intmax_t _N2, intmax_t _D2> typename enable_if < ratio<_N2, _D2>::num == num && ratio<_N2, _D2>::den == den, ratio& >::type operator=(const ratio<_N2, _D2>&) {return *this;} I.e. ratio is default constructible, and can be constructed or assigned from any ratio which has the same normalized form. I encourage you to write up an issue for the LWG issues list proposing this addition. Instructions for doing so can be found here: http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#submit_issue Thanks for working on this. -Howard
----- Original Message ----- From: "Howard Hinnant" <howard.hinnant@gmail.com> To: <boost@lists.boost.org> Sent: Sunday, December 06, 2009 11:42 PM Subject: Re: [boost] [ratio] Assignation between equivalent ratios
On Dec 6, 2009, at 1:33 PM, vicente.botet wrote:
Hi,
I was wondering if we need to be able to make assignations between equivalent ratios. e.g.
ratio<1,3> r1;
ratio<3,9> r2;
r1 = r2; // (1)
<snip>
I'm missing something? Any thougths?
Hi Vicente,
I think you've made a good observation. The original intent was to just have the special members of <ratio> governed by [functions.within.classes]. However your example code has given me pause for thought. I haven't found any motivating use cases for the assignment operator. But I can easily think of motivating uses for the copy constructor (and having the assignment operator be consistent, with the copy constructor, motivating cases or not, makes sense). I'm experimenting with the following special members and things look good to me:
ratio() {}
template <intmax_t _N2, intmax_t _D2> ratio(const ratio<_N2, _D2>&, typename enable_if < ratio<_N2, _D2>::num == num && ratio<_N2, _D2>::den == den >::type* = 0) {}
template <intmax_t _N2, intmax_t _D2> typename enable_if < ratio<_N2, _D2>::num == num && ratio<_N2, _D2>::den == den, ratio& >::type operator=(const ratio<_N2, _D2>&) {return *this;}
I.e. ratio is default constructible, and can be constructed or assigned from any ratio which has the same normalized form.
I encourage you to write up an issue for the LWG issues list proposing this addition. Instructions for doing so can be found here:
http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#submit_issue
Thanks for working on this.
Hi, do you think it is worth considering a ratio generator that will ensure a normalized ratio. In thi way ratio_normalizer<1,3>::type will be the same as ratio_normalizer<3,9>::type. So no need to add the copy constructors and assignement operators. Best, Vicente
On Mon, Dec 7, 2009 at 10:44 PM, vicente.botet <vicente.botet@wanadoo.fr>wrote:
do you think it is worth considering a ratio generator that will ensure a normalized ratio. In this way
ratio_normalizer<1,3>::type will be the same as ratio_normalizer<3,9>::type. So no need to add the copy constructors and assignement operators.
This may seem petty, but is there a specific need or demonstrable pretext for the use of Americanised 'z' over the traditional 's' in the term 'normalize'? I know there is little chance for the English S to win here, resulting in * normalise*, but I want to support the noble cause of supporting the European English language (I am an Australian German). What about both? I can't think of where use of 'z' over 's' in a similar way grated on my nerves in the STL or even the C lib. Is there an equivalent term that avoids the issue entirely? Christian
On Mon, Dec 07, 2009 at 11:47:38PM +1100, Christian Schladetsch wrote:
This may seem petty, but is there a specific need or demonstrable pretext for the use of Americanised 'z' over the traditional 's' in the term 'normalize'?
Not only petty but misguided. The Oxford English Dictionary gives "normalize" as the primary spelling and notes that both -ise and -ize have been around since the 18th century. It's quite commonplace to assume that -ise is traditional English but -ize is American, but the historical evidence doesn't bear out this world-view. OED's -ize entry notes that "prob. the earliest -ize word in Eng." is "baptize," a traditional spelling that has now fallen into disuse. The -ise/-ize variation long predates the colonisation of the Americas by Europeans. I hope that this helps you to feel better about reading the word "normalize" correctly spelt. -- “But it fareth with Sentences as with coynes: In coines, they that in smallest compasse conteine greatest value, are best esteemed: and, in sentences, those that in fewest words comprise most matter, are most praised.” -- Lancelot Andrewes
Christian Schladetsch wrote:
This may seem petty, but is there a specific need or demonstrable pretext for the use of Americanised 'z' over the traditional 's' in the term 'normalize'?
As a long time engineer, I have to say that I've always liked the way you could deduce something about the country of an engineer from spellings like this. I would not want to lose that charming aspect of the software engineering life by suggesting to people that they spell like I do. Patrick
On Dec 7, 2009, at 6:44 AM, vicente.botet wrote:
----- Original Message ----- From: "Howard Hinnant" <howard.hinnant@gmail.com> To: <boost@lists.boost.org> Sent: Sunday, December 06, 2009 11:42 PM Subject: Re: [boost] [ratio] Assignation between equivalent ratios
On Dec 6, 2009, at 1:33 PM, vicente.botet wrote:
Hi,
I was wondering if we need to be able to make assignations between equivalent ratios. e.g.
ratio<1,3> r1;
ratio<3,9> r2;
r1 = r2; // (1)
<snip>
I'm missing something? Any thougths?
Hi Vicente,
I think you've made a good observation. The original intent was to just have the special members of <ratio> governed by [functions.within.classes]. However your example code has given me pause for thought. I haven't found any motivating use cases for the assignment operator. But I can easily think of motivating uses for the copy constructor (and having the assignment operator be consistent, with the copy constructor, motivating cases or not, makes sense). I'm experimenting with the following special members and things look good to me:
ratio() {}
template <intmax_t _N2, intmax_t _D2> ratio(const ratio<_N2, _D2>&, typename enable_if < ratio<_N2, _D2>::num == num && ratio<_N2, _D2>::den == den
::type* = 0) {}
template <intmax_t _N2, intmax_t _D2> typename enable_if < ratio<_N2, _D2>::num == num && ratio<_N2, _D2>::den == den, ratio&
::type operator=(const ratio<_N2, _D2>&) {return *this;}
I.e. ratio is default constructible, and can be constructed or assigned from any ratio which has the same normalized form.
I encourage you to write up an issue for the LWG issues list proposing this addition. Instructions for doing so can be found here:
http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#submit_issue
Thanks for working on this.
Hi,
do you think it is worth considering a ratio generator that will ensure a normalized ratio. In thi way
ratio_normalizer<1,3>::type will be the same as ratio_normalizer<3,9>::type. So no need to add the copy constructors and assignement operators.
If we want to do this, I suspect the easiest thing would be to make type a nested typedef of ratio itself: ratio<3,9>::type is ratio<1,3> -Howard
----- Original Message ----- From: "Howard Hinnant" <howard.hinnant@gmail.com> To: <boost@lists.boost.org> Sent: Monday, December 07, 2009 3:18 PM Subject: Re: [boost] [ratio] Assignation between equivalent ratios
On Dec 7, 2009, at 6:44 AM, vicente.botet wrote:
Hi,
do you think it is worth considering a ratio generator that will ensure a normalized ratio. In thi way
ratio_normalizer<1,3>::type will be the same as ratio_normalizer<3,9>::type. So no need to add the copy constructors and assignement operators.
If we want to do this, I suspect the easiest thing would be to make type a nested typedef of ratio itself:
ratio<3,9>::type is ratio<1,3>
Yes, this looks simple and avoid the normaliZer linguistic issue :). Best, Vicente
participants (5)
-
Christian Schladetsch -
Daniel Hulme -
Howard Hinnant -
Patrick Horgan -
vicente.botet