Apologies for lack of proper review structure, I'm working with last bits of free time to post before the deadline... IMO, the proposed XInt, as can be downloaded from the vault, should NOT be accepted into Boost. Rationale: The reasons were mostly already covered by other boost.devel posters and pretty much all fall into the categories of a too coupled/inflexible and inefficient design. My primary concern is lack of support for true, efficient, no-fail-guarantee fixed-size integers: the provided fixed-size support still uses dynamic memory allocation (which can fail and requires/introduces EH code) and the nothrow policy does not in fact disable the use of exceptions (it only wraps and 'eats' them with try-catch blocks...which is just plain inefficient...this is like implementing malloc in terms of new instead of the other way around). For such low level operations, as fixed-sized integer arithmetic, it is quite reasonable to expect the implementation to be able to work even without linking to the CRT (i.e. no use of keywords new, virtual or throw)... This might at first be viewed as a possibly 'conditional yes' vote but since Chad has repeatedly said that he considers fixed-sized integers to be 'second class citizens' of his library I vote no for such a library... I am also not convinced by the rationale behind the different-than-built-in-behaviour (sign-magnitude, overflow NaN...).
"Chad Nelson" <chad.thecomfychair@gmail.com> wrote in message news:20110302202855.5cd8067f@ubuntu...
On Wed, 02 Mar 2011 18:18:33 +0100 Mathias Gaunard <mathias.gaunard@ens-lyon.org> wrote:
[...] Also, it seems that the object always contains the copy count and a readonly boolean, which total 2 words, even if COW is disabled.
Eliminating sixteen bits of overhead, on an integer that is almost always going to be larger than 64 bits (and often *much* larger), seems to be a premature optimization at best.
2 words are 64 bits on a 32 bit system and 128 bits on a 64 bit system...that's 25% of a 512 bit number. In fact, for a fixed-sized integer with disabled COW, there are, AFAICT, two redundant std:size_ts and two bools (in addition to the data pointer and dynamic memory allocation) per integer...that certainly is not so easily dismissible, especially on a 64 bit system and especially if we also consider the code that maintains those 'useless' data members...Quite to the contrary, I would sooner accuse your approach of premature pessimization (have you even examined the assembly output of your code?). In one post you complained that you are already tired of all the criticism on this list but please try to learn from this. The above misunderstanding and/or unwarranted dismissal of data layout/storage issues along with things like thinking that virtual inheritance is resolved at compile time, not knowing about the CRTP and misunderstanding of when to 'pass by value for performance' shows that you have holes in your knowledge which should make you more humble before honest criticism... You also complained about not getting enough feedback in the last iteration of your library, IMHO your attitude (of fixing your library on your own set of use cases) again may have something to do with that. I remember way back then people were already criticising the hardwired dynamic allocation and data-layout&storage coupling design. I proposed that you extract algorithms into free functions that simply take and work on data ranges as this would both eliminate template bloat (in your current design the algorithms get replicated for every integer_t instantiation) and allow for cleaner implementation of different data storage strategies. As far as I remember you gave little heed to these concerns/suggestions or complained that that would be too much time consuming to implement while OTOH you spent who knows how much time on implementing COW which AFAICT turned to be a misguided premature optimization (of an a priori inefficient design)... When I finally saw that you actually defended your hardwired dyn.mem. allocation by saying that it enables faster swaps I simply gave up on replying at that time deciding I'd wait for an official review (when boost.devel input has to be taken into consideration else you don't get accepted)... ps. I'm sorry if some/all of the above mentioned issues were already resolved (I did not manage to read through the whole discussion before the review deadline)... pps. I saw FFT being mentioned, you migh want to check out this http://drdobbs.com/cpp/199500857 ppps. You use a member-function-pointer based "unspecified bool type" implementation which produces suboptimal code on MSVC <10...IMO a plain operator bool would probably do just fine here as the built-in integral types also implicitly convert to bool... -- "What Huxley teaches is that in the age of advanced technology, spiritual devastation is more likely to come from an enemy with a smiling face than from one whose countenance exudes suspicion and hate." Neil Postman
On Sat, 12 Mar 2011 05:00:49 +0100 "Domagoj Saric" <dsaritz@gmail.com> wrote: Thank you for the review, and comments. Most of them require no response, but I will address one point:
My primary concern is lack of support for true, efficient, no-fail-guarantee fixed-size integers: [...] This might at first be viewed as a possibly 'conditional yes' vote but since Chad has repeatedly said that he considers fixed-sized integers to be 'second class citizens' of his library I vote no for such a library...
The whole point of the library is unlimited-size integers. I plan to improve the fixed-size integers, but they are not the primary focus of the library. -- Chad Nelson Oak Circle Software, Inc. * * *
"Chad Nelson" <chad.thecomfychair@gmail.com> wrote in message news:20110312020807.3aa7c86f@ubuntu...
The whole point of the library is unlimited-size integers. I plan to improve the fixed-size integers, but they are not the primary focus of the library.
Then my acceptance vote remains a firm no...not just because such a library will not fulfil my needs or satisfy my notion of a 'proper implementation' but because you seem to fixed on the idea of adding a library to Boost that primarily suits your needs in spite of objective and validly argued demands from the Boost community. Your 'whole point of the library' is exactly that,
your< point, I did not see any reviewer agreeing with you on that point. All of this makes the library not Boost.XInt but ChadNelson.XInt...
And why exactly do you refuse to treat fixed-size integers 'properly and equally'? So far the only reasons I could find are: - you have no need for them - a priori irrelevant if you want inclusion in Boost - you do not have or do not want to spend time 'doing it right' - if you listened to advice, various people repeatedly already gave you way back in the earlier iterations of the library, to decouple orthogonal concepts (namely algorithms from data storage) it would have been trivial to add fixed-size support (i.e. almost as simple as choosing between boost::array and std::vector). Probably a fraction of the time spent arguing about it (and coming up with pointless arguments like that of a 'performant swap')... The argument against separating algorithms so far has been that it would expose a wider public interface with the addition of SW's arguments against STL-like algorithms specifically. However, none of those arguments apply to the sole idea of algorithm extraction as this does not in any way imply that you have to make them public or STL-like...They can still remain an internal implementation detail... The fact that you refuse to listen to advice, even such 'ancient truisms' as 'decoupling is always right', and even after your experience and/or knowledge has been shown as lacking, cements the no vote even more because, as Dave Abrahams said, the vote goes to the library and the maintainer... -- "What Huxley teaches is that in the age of advanced technology, spiritual devastation is more likely to come from an enemy with a smiling face than from one whose countenance exudes suspicion and hate." Neil Postman
On Mon, 14 Mar 2011 10:35:18 +0100 "Domagoj Saric" <domagoj.saric@littleendian.com> wrote:
The whole point of the library is unlimited-size integers. I plan to improve the fixed-size integers, but they are not the primary focus of the library.
Then my acceptance vote remains a firm no...
Your point, and your vote, were quite clear the first time.
not just because such a library will not fulfil my needs or satisfy my notion of a 'proper implementation' but because you seem to fixed on the idea of adding a library to Boost that primarily suits your needs in spite of objective and validly argued demands from the Boost community.
I have yet to see any other objection to my focus on unlimited-size integers for an unlimited-size integer library.
Your 'whole point of the library' is exactly that, >your< point, I did not see any reviewer agreeing with you on that point.
I don't see that the point ever came up, suggesting that other reviewers had no objection to it.
All of this makes the library not Boost.XInt but ChadNelson.XInt...
I believe everyone on this list understands and agrees that he who creates the library and does all the work on it has the privilege of deciding its purpose. If you want DomagojSaric.XInt instead, you know how to get it.
And why exactly do you refuse to treat fixed-size integers 'properly and equally'?
I'm not well versed in debating terms, but that sounds like a straw man argument, since I've never done so. My position is, and remains, that fixed-size integers are not the primary purpose of an unlimited-length integer library, but that if I can find a way to make them work well, I will do so.
[...] The fact that you refuse to listen to advice, even such 'ancient truisms' as 'decoupling is always right', and even after your experience and/or knowledge has been shown as lacking, cements the no vote even more because, as Dave Abrahams said, the vote goes to the library and the maintainer...
You're obviously following only selected pieces of the discussion. In any case, you've done what you can to kill the library, you can drop the subject now. -- Chad Nelson Oak Circle Software, Inc. * * *
Chad Nelson wrote:
I have yet to see any other objection to my focus on unlimited-size integers for an unlimited-size integer library.
That's odd, because my very first posts in this review focused on your code's unacceptably-poor performance for fixed-size integers. Here's what I wrote in my review: "Performance of small and fixed-length integers is poor. This could be resolved by storing fixed-length values on the stack, or by using some sort of small buffer optimisation." Phil.
On Mon, 14 Mar 2011 15:15:06 +0000 "Phil Endecott" <spam_from_boost_dev@chezphil.org> wrote:
I have yet to see any other objection to my focus on unlimited-size integers for an unlimited-size integer library.
That's odd, because my very first posts in this review focused on your code's unacceptably-poor performance for fixed-size integers. Here's what I wrote in my review: "Performance of small and fixed-length integers is poor. This could be resolved by storing fixed-length values on the stack, or by using some sort of small buffer optimisation."
I read that as an objection to the performance of the fixed-size integers, not an objection to the library itself because it focused on unlimited-size integers. -- Chad Nelson Oak Circle Software, Inc. * * *
Chad Nelson wrote:
"Phil Endecott" <spam_from_boost_dev@chezphil.org> wrote:
I have yet to see any other objection to my focus on unlimited-size integers for an unlimited-size integer library.
That's odd, because my very first posts in this review focused on your code's unacceptably-poor performance for fixed-size integers. Here's what I wrote in my review: "Performance of small and fixed-length integers is poor. This could be resolved by storing fixed-length values on the stack, or by using some sort of small buffer optimisation."
I read that as an objection to the performance of the fixed-size integers, not an objection to the library itself because it focused on unlimited-size integers.
That's how it appears to me. _____ Rob Stewart robert.stewart@sig.com Software Engineer using std::disclaimer; Dev Tools & Components Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
"Stewart, Robert" <Robert.Stewart@sig.com> wrote in message news:DF2E67F3D097004694C8428C70A3FD690A4FD9F41B@msgbal516.ds.susq.com...
Chad Nelson wrote:
"Phil Endecott" <spam_from_boost_dev@chezphil.org> wrote:
I have yet to see any other objection to my focus on unlimited-size integers for an unlimited-size integer library.
That's odd, because my very first posts in this review focused on your code's unacceptably-poor performance for fixed-size integers. Here's what I wrote in my review: "Performance of small and fixed-length integers is poor. This could be resolved by storing fixed-length values on the stack, or by using some sort of small buffer optimisation."
I read that as an objection to the performance of the fixed-size integers, not an objection to the library itself because it focused on unlimited-size integers.
That's how it appears to me.
How is that significantly different? The suboptimal performance of fixed-sized integers is the direct consequence of a wrong internal design and 'focus on unlimited-size integers'... -- "What Huxley teaches is that in the age of advanced technology, spiritual devastation is more likely to come from an enemy with a smiling face than from one whose countenance exudes suspicion and hate." Neil Postman
Domagoj Saric wrote:
"Stewart, Robert" <Robert.Stewart@sig.com> wrote
Chad Nelson wrote:
"Phil Endecott" <spam_from_boost_dev@chezphil.org> wrote:
I have yet to see any other objection to my focus on unlimited-size integers for an unlimited-size integer library.
That's odd, because my very first posts in this review focused on your code's unacceptably-poor performance for fixed-size integers. Here's what I wrote in my review: "Performance of small and fixed-length integers is poor. This could be resolved by storing fixed-length values on the stack, or by using some sort of small buffer optimisation."
I read that as an objection to the performance of the fixed-size integers, not an objection to the library itself because it focused on unlimited-size integers.
That's how it appears to me.
How is that significantly different? The suboptimal performance of fixed-sized integers is the direct consequence of a wrong internal design and 'focus on unlimited-size integers'...
The difference is that Chad's focus on unlimited-size integers and implementing fixed-size integers on top of that base led to poor performance of fixed-size integrals, but doesn't necessarily mean that his unlimited-size integer implementation is inherently wrong. As written, the library may not satisfy your needs for fixed-size integers, but that doesn't imply that it has "wrong internal design" for unlimited-size integers. _____ Rob Stewart robert.stewart@sig.com Software Engineer using std::disclaimer; Dev Tools & Components Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
"Stewart, Robert" <Robert.Stewart@sig.com> wrote in message news:DF2E67F3D097004694C8428C70A3FD690A4FEA6C94@msgbal516.ds.susq.com...
The difference is that Chad's focus on unlimited-size integers and implementing fixed-size integers on top of that base led to poor performance of fixed-size integrals, but doesn't necessarily mean that his unlimited-size integer implementation is inherently wrong. As written, the library may not satisfy your needs for fixed-size integers, but that doesn't imply that it has "wrong internal design" for unlimited-size integers.
For some more "academic bike-shedding", this simply begs the question "is a design for/focused on unlimited-sized integers the right design for a Boost extended integer library"? -- "What Huxley teaches is that in the age of advanced technology, spiritual devastation is more likely to come from an enemy with a smiling face than from one whose countenance exudes suspicion and hate." Neil Postman
"Chad Nelson" <chad.thecomfychair@gmail.com> wrote in message news:20110314104859.2a587afb@ubuntu...
The whole point of the library is unlimited-size integers. I plan to improve the fixed-size integers, but they are not the primary focus of the library.
Then my acceptance vote remains a firm no...
Your point, and your vote, were quite clear the first time.
In my 'quick review' I said that the no vote could be considered a conditional accept vote if it weren't for your simple refusal to treat fixed-size integers 'properly'/equally. Since I was unable to read the whole discussion this left space for the possibility that you changed your mind. When you, then, reaffirmed your 'second-class citizen' decision I reaffirmed my no vote.
I have yet to see any other objection to my focus on unlimited-size integers for an unlimited-size integer library. [+] I don't see that the point ever came up, suggesting that other reviewers had no objection to it.
I can't believe that you deny that others before me objected to the treatment of fixed-sized integers?? (Wrapping it in reverse/'positive' wording of 'focus on unlimited-sized integers' does not imply a different issue.)
I believe everyone on this list understands and agrees that he who creates the library and does all the work on it has the privilege of deciding its purpose.
Of course, _until_ he or she wants to include it into Boost. I fail to see how an "extended integer library", in general, implies that 'unlimited sized integers' are more important than 'fixed-sized integers'...as they are both "extended integers".
And why exactly do you refuse to treat fixed-size integers 'properly and equally'?
I'm not well versed in debating terms, but that sounds like a straw man argument, since I've never done so. My position is, and remains, that fixed-size integers are not the primary purpose of an unlimited-length integer library, but that if I can find a way to make them work well, I will do so.
That would be a straw man argument from my side if in fact you've never done so, however in this very paragraph you restate that you do not/will not treat fixed-size integers equally (which is what "primary purpose/focus" "weasel wording" seems to translate to). Then you follow this statement with a shifting-goal-posts fallacy by stating that you will 'focus' on them if you find a way how (until now, as far as I could follow, the answer was more like "I will not 'focus' on them because I do not have time and/or interest in them"). The fallaciousness is further compounded by the fact that a way to 'make them work well' was already presented to you multiple times and in previous discussions (e.g. I briefly repeated my idea in the first post of this thread which you simply chose to ignore)...
You're obviously following only selected pieces of the discussion.
I tried to follow as much as I could but I primarily focused on fixed-sized integers.
In any case, you've done what you can to kill the library, you can drop the subject now.
'Killing' the library was never my goal. Because all objective arguments failed to convince you that in general, fixed-sized integers are not second-class citizens and are actually rather trivial to implement, I was left only with unhappy tools of 'subjective arguments' in trying to show you that there is 'something wrong' with your attitude. Which you demonstrate again by selectively responding to objections and, obviously, taking them personally as you finish off implying that argued objections are actually there to "kill your library"... ps. at one place I saw that you translate std::bad_alloc into a xint specific exception, why? pps. can you please check the settings in your email client because all of your posts look empty with .txt and .asc attachments to me (Windows Live Mail) making it really difficult to reply to them... -- "What Huxley teaches is that in the age of advanced technology, spiritual devastation is more likely to come from an enemy with a smiling face than from one whose countenance exudes suspicion and hate." Neil Postman
On Tue, 15 Mar 2011 14:18:50 +0100 "Domagoj Saric" <domagoj.saric@littleendian.com> wrote:
I have yet to see any other objection to my focus on unlimited-size integers for an unlimited-size integer library. [+] I don't see that the point ever came up, suggesting that other reviewers had no objection to it.
I can't believe that you deny that others before me objected to the treatment of fixed-sized integers?? (Wrapping it in reverse/'positive' wording of 'focus on unlimited-sized integers' does not imply a different issue.)
If, by your own words, the issue you brought up is the same as objecting "to my focus on unlimited-size integers for an unlimited-size integer library", then it definitely never came up. The closest I've seen are complaints about the performance of the fixed-size integers. To match, I'll add, the complaints about the performance of unlimited-size integers.
And why exactly do you refuse to treat fixed-size integers 'properly and equally'?
I'm not well versed in debating terms, but that sounds like a straw man argument, since I've never done so. My position is, and remains, that fixed-size integers are not the primary purpose of an unlimited-length integer library, but that if I can find a way to make them work well, I will do so.
That would be a straw man argument from my side if in fact you've never done so, however in this very paragraph you restate that you do not/will not treat fixed-size integers equally (which is what "primary purpose/focus" "weasel wording" seems to translate to).
If you insist on (mis)translating my words, there's little point in continuing this conversation. My words are perfectly clear without the help.
[...] The fallaciousness is further compounded by the fact that a way to 'make them work well' was already presented to you multiple times and in previous discussions (e.g. I briefly repeated my idea in the first post of this thread which you simply chose to ignore)...
I suppose I'd better add this sentence then, or be accused of ignoring this repetition too.
In any case, you've done what you can to kill the library, you can drop the subject now.
'Killing' the library was never my goal. Because all objective arguments failed to convince you that in general, fixed-sized integers are not second-class citizens and are actually rather trivial to implement, I was left only with unhappy tools of 'subjective arguments' in trying to show you that there is 'something wrong' with your attitude. [...]
Perhaps translation *is* needed, because what I'm hearing is that because I insist on disagreeing with you, there must be something wrong with my attitude.
ps. at one place I saw that you translate std::bad_alloc into a xint specific exception, why?
Because a bad_alloc at that point doesn't necessarily mean out-of-memory, it means that the number is too big for the library to represent.
pps. can you please check the settings in your email client because all of your posts look empty with .txt and .asc attachments to me (Windows Live Mail) making it really difficult to reply to them...
So far as I've been able to determine, Claws Mail has no options that affect that. It sounds like Windows Live Mail is misinterpreting the GPG signature. -- Chad Nelson Oak Circle Software, Inc. * * *
Chad Nelson wrote:
"Domagoj Saric" <domagoj.saric@littleendian.com> wrote:
I can't believe that you deny that others before me objected to the treatment of fixed-sized integers?? (Wrapping it in reverse/'positive' wording of 'focus on unlimited-sized integers' does not imply a different issue.)
It does, however, clarify the purpose and theme of the library.
And why exactly do you refuse to treat fixed-size integers 'properly and equally'? [snip] If you insist on (mis)translating my words, there's little point in continuing this conversation. My words are perfectly clear without the help.
[...] The fallaciousness is further compounded by the fact that a way to 'make them work well' was already presented to you multiple times and in previous discussions (e.g. I briefly repeated my idea in the first post of this thread which you simply chose to ignore)... [snip] 'Killing' the library was never my goal. Because all objective arguments failed to convince you that in general, fixed-sized integers are not second-class citizens and are actually rather trivial to implement, I was left only with unhappy tools of 'subjective arguments' in trying to show you that there is 'something wrong' with your attitude.
Perhaps translation *is* needed, because what I'm hearing is that because I insist on disagreeing with you, there must be something wrong with my attitude.
As far as I can see, Domagoj is using argumentative and aggressive language to drive home his point that fixed, but extended length integers are important and that XInt is not acceptable without them. Whether there had been prior communication on solutions is almost moot. Either Chad didn't see the suggestions or had reasons to reject them at the time. Thus, the library being offered is XInt, not Domagoj's version of it. There is a great deal for Chad to do now to absorb the review comments and wend his way through the various suggestions to produce an updated version of the library. I think the result will be markedly improved from the current version, though with such drastic changes before the library, I'm unsure how similar it will prove to be to what's been reviewed. Nevertheless, it may well be that the result will enable Chad to understand how to provide fixed length integers better than he's done thus far. Perhaps Domagoj can offer to review future versions and make *constructive* comments at that time. I'm reasonably confident that Chad will accept those comments and act upon them if he understands them and finds them consistent with his vision for the library. This is the way forward if the goal is improving the library rather than being destructive.
pps. can you please check the settings in your email client because all of your posts look empty with .txt and .asc attachments to me (Windows Live Mail) making it really difficult to reply to them...
So far as I've been able to determine, Claws Mail has no options that affect that. It sounds like Windows Live Mail is misinterpreting the GPG signature.
FWIW, I see the text of his messages fine. I also get two attachments with his signature and what follows it (as attached by the majordomo). _____ Rob Stewart robert.stewart@sig.com Software Engineer using std::disclaimer; Dev Tools & Components Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
"Stewart, Robert" <Robert.Stewart@sig.com> wrote in message news:DF2E67F3D097004694C8428C70A3FD690A4FEA6C7F@msgbal516.ds.susq.com...
Chad Nelson wrote:
"Domagoj Saric" <domagoj.saric@littleendian.com> wrote:
I can't believe that you deny that others before me objected to the treatment of fixed-sized integers?? (Wrapping it in reverse/'positive' wording of 'focus on unlimited-sized integers' does not imply a different issue.)
It does, however, clarify the purpose and theme of the library.
That purpose is, IMNHO, just/yet another issue on the 'review debating table'...Most specifically (to really repeat myself ad nauseam) because there is no real objective reason not to 'repurpose' it differently (make no first-class/second-class citizen assumptions) because it is relatively trivial to do so while at the same time providing benefits for a wide area of real world usage scenarios (e.g. the mentioned cryptographic keys...)...
Perhaps translation *is* needed, because what I'm hearing is that because I insist on disagreeing with you, there must be something wrong with my attitude.
As far as I can see, Domagoj is using argumentative and aggressive language to drive home his point that fixed, but extended length integers are important and that XInt is not acceptable without them. Whether there had been prior communication on solutions is almost moot. Either Chad didn't see the suggestions or had reasons to reject them at the time. Thus, the library being offered is XInt, not Domagoj's version of it.
Chad did see them, unless we accept the unlikely chain of events in which he was able to miss exactly just the specific points in many of the posts which he certainly did see as he replied to them...and was then additionally pointed to the fact that he ignored pieces of argumentation. And again, I was not the first to point this out (if I recall correctly Mathias Gaunard objected to the very same thing)... Additionally, Chad had no (or at least did not provide any) valid reasons to reject those objections and arguments. The only one I can recall is the constantly repeated circular "I will not focus on f.s.i because I will not" argument which of course simply begs the question. It was sometimes expanded with "because I do not have time to do it or do not know how" and then simply ignored counter arguments that it is relatively trivial to do it and various ways on how to actually do it...
Nevertheless, it may well be that the result will enable Chad to understand how to provide fixed length integers better than he's done thus far.
A prerequisite for this is for Chad to actually want to provide proper fixed-sized integers, i.e. give them 'focus'...and, IMO, a prerequisite for this to be done is to stop treating them just as an 'ugly patch on an otherwise hardwired-dynamic-xint that others force me to do'...
Perhaps Domagoj can offer to review future versions and make *constructive* comments at that time. I'm reasonably confident that Chad will accept those comments and act upon them if he understands them
Sorry but LOL...I really hope that you simply did not follow the discussion so far in order to give such a comment...I did, as did others to whose objections Chad reacted as 'attempts to kill the library', give constructive comments (not only in this discussion but in previous ones also). And often Chad simply refused to 'accept' those comments or dismissed them for dubious reasons...
and finds them consistent with his vision for the library.
And we arrive at the key point...Is his, or anyone else's vision for that matter, not also a debatable matter? When I started to work on my GIL.IO2 proposal, I went out of my way to support and provide support for a wide range of use cases (of which I personally need just a tiny fraction) simply accepting the fact that there is an obvious difference between a Boost.Library and a JohnDoe.Library... -- "What Huxley teaches is that in the age of advanced technology, spiritual devastation is more likely to come from an enemy with a smiling face than from one whose countenance exudes suspicion and hate." Neil Postman
Domagoj Saric wrote:
"Stewart, Robert" <Robert.Stewart@sig.com> wrote:
Chad Nelson wrote:
It does, however, clarify the purpose and theme of the library.
That purpose is, IMNHO, just/yet another issue on the 'review debating table'...
Certainly. That should be part of your vote for or against the library, but it isn't necessarily important to other's votes. If others can accept the library with unlimited length integers and accept that the fixed length integer support, if retained, is less than ideal, then they will vote to accept. Your views have been expressed repeatedly but that doesn't make them more important than when first stated.
Most specifically (to really repeat myself ad nauseam) because there is no real objective reason not to 'repurpose' it differently (make no first-class/second-class citizen assumptions)
There is a real, objective reason to not refocus the library: Chad has expressed a lack of desire for doing so. Since he must write, document, and maintain the code, it isn't your place to force him to do so. You may have good arguments for your position, but they needn't be authoritative to Chad.
because it is relatively trivial to do so while at the same time providing benefits for a wide area of real world usage scenarios (e.g. the mentioned cryptographic keys...)...
There's no argument that the fixed length integers can be beneficial to some (possibly large) subset of developers. For example, while I've never done any cryptography, I can see how high performance, fixed length integers would be beneficial in financial computations. That doesn't, however, require that Chad include them in his library. Whether supporting fixed length integers is "relatively trivial" (relative to what, I wonder), that is not, or has not, been obvious to Chad if for no other reason than he views the idea relative to his current design/implementation. If you're right, and Chad redesigns his code and recognizes how to support them easily and is willing to take them on, then the library benefits and you'll be ecstatic, I'm sure. However, many things must occur to reach that state, not least Chad's need to investigate removing COW and factoring out the algorithms. Is it a surprise that he wishes to restrict the library's focus to reduce the scope of that work instead of also adding improved fixed length integers?
Perhaps translation *is* needed, because what I'm hearing is that because I insist on disagreeing with you, there must be something wrong with my attitude.
As far as I can see, Domagoj is using argumentative and aggressive language to drive home his point that fixed, but extended length integers are important and that XInt is not acceptable without them. Whether there had been prior communication on solutions is almost moot. Either Chad didn't see the suggestions or had reasons to reject them at the time. Thus, the library being offered is XInt, not Domagoj's version of it.
Chad did see them, unless we accept the unlikely chain of events in which he was able to miss exactly just the specific points in many of the posts which he certainly did see as he replied to them...
Does it follow that Chad understood what he read in the way you meant it? Furthermore, I noted that he may well have "had reasons to reject [the suggestions] at the time." You may prefer that he hadn't rejected them or you may think his reasons flawed, but he's under no obligation to accept other's suggestions.
and was then additionally pointed to the fact that he ignored pieces of argumentation.
You seem to forget that communication requires two people and is particularly hard in written communication between strangers. One must write clearly and present information so the other party understands what's intended and how it applies in the context. The second party reads words with a certain mindset that may not match that of the first party. Thus, the second party may understand the words to mean something quite different from what was intended and, thereby, misunderstand and misapply them. Concretely, isn't it possible that Chad understood things other than you intended and considered them to apply differently to his library than you meant or that he failed to grasp how what you suggested could even work because he failed to understand something critical in your suggestion? Chad has gotten advice from a great many people and has learned that not all participants in this list are equal in skill. Therefore, it's not surprising that he would take your suggestions with some skepticism, particularly if they didn't fit his mindset.
And again, I was not the first to point this out (if I recall correctly Mathias Gaunard objected to the very same thing)...
I understood your earlier remark on this point to be a reference to prior discussions -- last year, perhaps -- on the library, not to discussions during the review.
Additionally, Chad had no (or at least did not provide any) valid reasons to reject those objections and arguments. The only one I can recall is the constantly repeated circular "I will not focus on f.s.i because I will not" argument which of course simply begs the question. It was sometimes expanded with "because I do not have time to do it or do not know how" and then simply ignored counter arguments that it is relatively trivial to do it and various ways on how to actually do it...
I fail to understand how a library author's lack of interest in a feature of interest to any audience is a problem. The question is whether the library, as presented, is useful and well designed, not whether it could do more. Suggestions for improvement or extensions to the library are useful, but it is solely the author's decision whether to accept them. If a reviewer finds the lack of some feature as critical, that reviewer may reject the library, but I consider such a review flawed because it can deny a useful library from Boost users. Note also what you find trivial or obvious is in no way indicative of what another will find trivial or obvious. Thus, your insistence that Chad is unreasonable to reject your ideas -- which I don't think he did outright reject, but rather indicated he would consider for possible incorporation after dealing with a great many other things -- is, itself, unreasonable.
Nevertheless, it may well be that the result will enable Chad to understand how to provide fixed length integers better than he's done thus far.
A prerequisite for this is for Chad to actually want to provide proper fixed-sized integers, i.e. give them 'focus'... and, IMO, a prerequisite for this to be done is to stop treating them just as an 'ugly patch on an otherwise hardwired-dynamic-xint that others force me to do'...
Until Chad understands and accepts a view similar to your own on the design of the library, another view prevails. In his present view of things, it is clear that fixed length integers are sufficiently different to be a problem for him to support beyond what he has now done. He is under no obligation to accept your view, though hopefully he will spend sufficient time to understand it fully in order to knowledgeably accept or reject it.
Perhaps Domagoj can offer to review future versions and make *constructive* comments at that time. I'm reasonably confident that Chad will accept those comments and act upon them if he understands them
Sorry but LOL...I really hope that you simply did not follow the discussion so far in order to give such a comment...I did, as did others to whose objections Chad reacted as ' attempts to kill the library', give constructive comments (not only in this discussion but in previous ones also). And often Chad simply refused to 'accept' those comments or dismissed them for dubious reasons...
What I saw was Chad's attitude change significantly in the middle of the review. He became far humbler and more willing to listen to other viewpoints and respond more reasonably than he did at first. As Dave put it, "the process works!" By contrast, you continue to attack and rail at him as if nothing changed. Consequently, I find your behavior to be more troublesome.
and finds them consistent with his vision for the library.
And we arrive at the key point...Is his, or anyone else's vision for that matter, not also a debatable matter?
It is debatable, but Chad needn't change his vision as a consequence. If an author's vision makes a library unacceptable to you, then vote against it. You should state your *opinion* on the matter and let it go. It's that last part you seem to be struggling with in this case.
When I started to work on my GIL.IO2 proposal, I went out of my way to support and provide support for a wide range of use cases (of which I personally need just a tiny fraction) simply accepting the fact that there is an obvious difference between a Boost.Library and a JohnDoe.Library...
That's terrific. Doing so, however, meant that you chose to take on more work. Thus far, Chad's been reticent to *commit* to doing that. That doesn't mean the unlimited length integer capability suffers as a consequence. _____ Rob Stewart robert.stewart@sig.com Software Engineer using std::disclaimer; Dev Tools & Components Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
Stewart, Robert wrote:
Domagoj Saric wrote:
Most specifically (to really repeat myself ad nauseam) because there is no real objective reason not to 'repurpose' it differently (make no first-class/second-class citizen assumptions)
There is a real, objective reason to not refocus the library: Chad has expressed a lack of desire for doing so. Since he must write, document, and maintain the code, it isn't your place to force him to do so. You may have good arguments for your position, but they needn't be authoritative to Chad.
+1
because it is relatively trivial to do so while at the same time providing benefits for a wide area of real world usage scenarios (e.g. the mentioned cryptographic keys...)...
There's no argument that the fixed length integers can be beneficial to some (possibly large) subset of developers. For example, while I've never done any cryptography, I can see how high performance, fixed length integers would be beneficial in financial computations. That doesn't, however, require that Chad include them in his library.
+1
Whether supporting fixed length integers is "relatively trivial" (relative to what, I wonder), that is not, or has not, been obvious to Chad if for no other reason than he views the idea relative to his current design/implementation. If you're right, and Chad redesigns his code and recognizes how to support them easily and is willing to take them on, then the library benefits and you'll be ecstatic, I'm sure. However, many things must occur to reach that state, not least Chad's need to investigate removing COW and factoring out the algorithms. Is it a surprise that he wishes to restrict the library's focus to reduce the scope of that work instead of also adding improved fixed length integers?
Daniel James wrote:
On 25 March 2011 11:41, Nevin Liber <nevin@eviloverlord.com> wrote:
I really do believe that fixed sized integers should be a part of this library.
I disagree. Fixed sized integers would be best implemented by someone who shares your enthusiasm for them. I suppose you could group different implementations by different people under a common banner if that would make you happy.
+1 Perhaps Domagoj Saric would like to provide a fixed size integer library, to be bundled with Chad Nelson's Xint? Domagoj invested considerable amounts of energy in pleading for a fixed size integer library, he seems to have a serious need for them and he also seems to have a clear opinion on the way they should be implemented. Hence, he might be the right person to invest similar amounts of energy in the actual implementation. -Julian
On Mar 25, 2011, at 8:00 AM, Stewart, Robert wrote:
I fail to understand how a library author's lack of interest in a feature of interest to any audience is a problem. The question is whether the library, as presented, is useful and well designed, not whether it could do more. Suggestions for improvement or extensions to the library are useful, but it is solely the author's decision whether to accept them.
I think the line can be fuzzy between questions about the design of a library and questions about its scope. IMO Domagoj has a good argument (expressed somewhat harshly) that if the library were designed a little differently, it would support fixed-length large integers better than having a second library duplicating the interface and algorithms. So, while I strongly agree that library writers shouldn't be forced to implement features they are not interested in, I think people may be fooling themselves if they think they can always distinguish clearly between design and scope. In any case, "the process works" and Chad was convinced to support the separation of algos and data, which enables fixed-length and other representations. This design arises naturally from the problem and was already present internally. Cheers to another successful review! Gordon
"Chad Nelson" <chad.thecomfychair@gmail.com> wrote in message news:20110315111145.16769868@ubuntu...
I have yet to see any other objection to my focus on unlimited-size integers for an unlimited-size integer library. [+] I don't see that the point ever came up, suggesting that other reviewers had no objection to it.
I can't believe that you deny that others before me objected to the treatment of fixed-sized integers?? (Wrapping it in reverse/'positive' wording of 'focus on unlimited-sized integers' does not imply a different issue.)
If, by your own words, the issue you brought up is the same as objecting "to my focus on unlimited-size integers for an unlimited-size integer library", then it definitely never came up. The closest I've seen are complaints about the performance of the fixed-size integers.
"Academic bike-shedding". Nonetheless, if we really must, the issue I brought up 'definitely came up'
And why exactly do you refuse to treat fixed-size integers 'properly and equally'?
I'm not well versed in debating terms, but that sounds like a straw man argument, since I've never done so. My position is, and remains, that fixed-size integers are not the primary purpose of an unlimited-length integer library, but that if I can find a way to make them work well, I will do so.
That would be a straw man argument from my side if in fact you've never done so, however in this very paragraph you restate that you do not/will not treat fixed-size integers equally (which is what "primary purpose/focus" "weasel wording" seems to translate to).
If you insist on (mis)translating my words, there's little point in continuing this conversation. My words are perfectly clear without the help.
[...] The fallaciousness is further compounded by the fact that a way to 'make them work well' was already presented to you multiple times and in previous discussions (e.g. I briefly repeated my idea in the first post of this thread which you simply chose to ignore)...
I suppose I'd better add this sentence then, or be accused of ignoring this repetition too.
In any case, you've done what you can to kill the library, you can drop the subject now.
'Killing' the library was never my goal. Because all objective arguments failed to convince you that in general, fixed-sized integers are not second-class citizens and are actually rather trivial to implement, I was left only with unhappy tools of 'subjective arguments' in trying to show you that there is 'something wrong' with your attitude. [...]
Perhaps translation *is* needed, because what I'm hearing is that because I insist on disagreeing with you, there must be something wrong with my attitude.
ps. at one place I saw that you translate std::bad_alloc into a xint specific exception, why?
Because a bad_alloc at that point doesn't necessarily mean out-of-memory, it means that the number is too big for the library to represent.
pps. can you please check the settings in your email client because all of your posts look empty with .txt and .asc attachments to me (Windows Live Mail) making it really difficult to reply to them...
So far as I've been able to determine, Claws Mail has no options that affect that. It sounds like Windows Live Mail is misinterpreting the GPG signature.
...<sorry for the previous post, i accidentally pressed send>... "Chad Nelson" <chad.thecomfychair@gmail.com> wrote in message news:20110315111145.16769868@ubuntu...
I have yet to see any other objection to my focus on unlimited-size integers for an unlimited-size integer library. [+] I don't see that the point ever came up, suggesting that other reviewers had no objection to it.
I can't believe that you deny that others before me objected to the treatment of fixed-sized integers?? (Wrapping it in reverse/'positive' wording of 'focus on unlimited-sized integers' does not imply a different issue.)
If, by your own words, the issue you brought up is the same as objecting "to my focus on unlimited-size integers for an unlimited-size integer library", then it definitely never came up. The closest I've seen are complaints about the performance of the fixed-size integers.
"Academic bike-shedding". Nonetheless, if we really must, the issue I brought up 'definitely came up' as testified by Phil Endecott's "That's odd, because..." response to your very claim that the issue did not came up. That response clarified that his objection, in practice, did imply the same problem as mine even if differently worded. The fact that you, and seemingly Robert Stewart, read something different from it is a simple case of a reading one's own agenda into someone else's words fallacy. Furthermore, if I recall correctly, Mathias Gaunard was also pretty clear on his view of fixed sized integer treatment, going even a step further by asking/demanding that a 'xint<fixed_size<32>>' should produce the same code as a plain int would...and eventually, after being faced with the usual bike-shedding dance, gave up... You are more than free to continue the mentioned vain dance by claiming to see the, in practice non-existent difference, between 'fixed integers perform badly' and 'fixed integers are treated badly'...I'll take a break... ps. the addition of "...for an unlimited-size integer library" (goal-shifting fallacy) will not make, those opposed to the idea, silently and suddenly accept your idea of what a Boost extended integer library should be. Accept that this is also one of the issues on the review debating table. As expressed so many times before, I see no justification for such a direction as, with a 'proper' design, treating fixed and dynamic sized integers equally is AFAICT almost a nop compared to other work required by the library...
That would be a straw man argument from my side if in fact you've never done so, however in this very paragraph you restate that you do not/will not treat fixed-size integers equally (which is what "primary purpose/focus" "weasel wording" seems to translate to).
If you insist on (mis)translating my words, there's little point in continuing this conversation. My words are perfectly clear without the help.
Please, how exactly is that mistranslation? Giving something primary and something secondary focus directly implies _different_ (i.e. _non_equal_) treatment...
[...] The fallaciousness is further compounded by the fact that a way to 'make them work well' was already presented to you multiple times and in previous discussions (e.g. I briefly repeated my idea in the first post of this thread which you simply chose to ignore)...
I suppose I'd better add this sentence then, or be accused of ignoring this repetition too.
How is this a repetition? I simply pointed out an additional issue in your statement, namely that tried to cop out by saying that you will fix things if you find out how yet while many 'hows' have already been presented.
'Killing' the library was never my goal. Because all objective arguments failed to convince you that in general, fixed-sized integers are not second-class citizens and are actually rather trivial to implement, I was left only with unhappy tools of 'subjective arguments' in trying to show you that there is 'something wrong' with your attitude. [...]
Perhaps translation *is* needed, because what I'm hearing is that because I insist on disagreeing with you, there must be something wrong with my attitude.
Obviously, as that is not what I was saying, rather that because you insist on disagreeing, with not just me, on purely subjective/irrational grounds (i.e. with simple refusals decorated with bike-shedding and/or objective argument ignoring) that there is 'something wrong with your attitude'...Again I was not the first to point out this issue...
ps. at one place I saw that you translate std::bad_alloc into a xint specific exception, why?
Because a bad_alloc at that point doesn't necessarily mean out-of-memory, it means that the number is too big for the library to represent.
What else can it mean, what throws bad_alloc for reasons other than a failed allocation?
pps. can you please check the settings in your email client because all of your posts look empty with .txt and .asc attachments to me (Windows Live Mail) making it really difficult to reply to them...
So far as I've been able to determine, Claws Mail has no options that affect that. It sounds like Windows Live Mail is misinterpreting the GPG signature.
Oh well...I guess I'll have to live with it somehow (note that noone else's posts appear that way to me)...please take this into consideration if my replies to you look oddly formatted (as I have to copy-paste and manually indent all of your message)... -- "What Huxley teaches is that in the age of advanced technology, spiritual devastation is more likely to come from an enemy with a smiling face than from one whose countenance exudes suspicion and hate." Neil Postman
AMDG On 03/14/2011 02:35 AM, Domagoj Saric wrote:
"Chad Nelson" <chad.thecomfychair@gmail.com> wrote in message news:20110312020807.3aa7c86f@ubuntu...
The whole point of the library is unlimited-size integers. I plan to improve the fixed-size integers, but they are not the primary focus of the library.
Then my acceptance vote remains a firm no...not just because such a library will not fulfil my needs or satisfy my notion of a 'proper implementation' but because you seem to fixed on the idea of adding a library to Boost that primarily suits your needs in spite of objective and validly argued demands from the Boost community. Your 'whole point of the library' is exactly that, >your< point, I did not see any reviewer agreeing with you on that point. All of this makes the library not Boost.XInt but ChadNelson.XInt...
And why exactly do you refuse to treat fixed-size integers 'properly and equally'? So far the only reasons I could find are: - you have no need for them - a priori irrelevant if you want inclusion in Boost
I don't think fixed size integers are necessary for a Boost bigint proposal to begin with. However, since are provided, I'd like them to be handled as well as possible. Chad has already said that he expects support for them to improve and that's good enough for me, since it won't require breaking the interface.
- you do not have or do not want to spend time 'doing it right' - if you listened to advice, various people repeatedly already gave you way back in the earlier iterations of the library, to decouple orthogonal concepts (namely algorithms from data storage) it would have been trivial to add fixed-size support (i.e. almost as simple as choosing between boost::array and std::vector). Probably a fraction of the time spent arguing about it (and coming up with pointless arguments like that of a 'performant swap')...
Pointless?
The argument against separating algorithms so far has been that it would expose a wider public interface with the addition of SW's arguments against STL-like algorithms specifically. However, none of those arguments apply to the sole idea of algorithm extraction as this does not in any way imply that you have to make them public or STL-like...They can still remain an internal implementation detail...
The fact that you refuse to listen to advice, even such 'ancient truisms' as 'decoupling is always right',
It isn't. If there's one thing I hate more than anything else, it's blindly applying rules, while forgetting the reason that the rules exist to begin with.
and even after your experience and/or knowledge has been shown as lacking, cements the no vote even more because, as Dave Abrahams said, the vote goes to the library and the maintainer...
In Christ, Steven Watanabe
"Steven Watanabe" <watanabesj@gmail.com> wrote in message news:4D7E2D5D.5050304@providere-consulting.com...
I don't think fixed size integers are necessary for a Boost bigint proposal to begin with.
Why? First, AFAIK a significant portion of 'bigint' usage falls into the realm of cryptography and encryption keys which usually have fixed power-of-two sizes and both 'fixed' and 'power-of-two' almost always translate to great simplification/efficiency improvements when one gets to the implementation level. This naturally translates to the question "why should I pay for usage of new, try, catch and throw if all I want is to construct a statically known fixed-size public RSA key and use it to verify a message"? Second, AFAICT they are trivial to implement (with the right internal design of course, which was demanded of XInt long time ago but it never happened).
However, since are provided, I'd like them to be handled as well as possible. Chad has already said that he expects support for them to improve and that's good enough for me, since it won't require breaking the interface.
Maybe I've missed it but I haven't seen concrete ideas as to how exactly Chad plans to do it (especially if he continues to stick with the current design and the attitude of not being bothered that dynamic memory allocation and exception handling are used where there is no really need for either).
Probably a fraction of the time spent arguing about it (and coming up with pointless arguments like that of a 'performant swap')...
Pointless?
Defending dynamic-memory allocation (as opposed to static-sized/stack storage) solely with the argument that it allows for faster swaps is pointless: who designs a class to have a fast swap while paying for it in almost all other operations (i.e. pessimizes real usage for the sake of an auxiliary operation)? Plus, swaping fixed-size integers (PODs) is still pretty trivial (a few rep movs or memcpy calls).
The fact that you refuse to listen to advice, even such 'ancient truisms' as 'decoupling is always right',
It isn't. If there's one thing I hate more than anything else, it's blindly applying rules, while forgetting the reason that the rules exist to begin with.
Juraj probably had a nice laugh seeing me accused of blindly following rules ;-) My statement may have been overly simple, but with all other things being equal (e.g. no efficiency compromises) decoupling can be seen as the opposite of writing spaghetti code, i.e. the opposite of something that is always wrong and in that sense right. It also need not imply an expanded public interface. -- "What Huxley teaches is that in the age of advanced technology, spiritual devastation is more likely to come from an enemy with a smiling face than from one whose countenance exudes suspicion and hate." Neil Postman
On Tue, 15 Mar 2011 14:48:17 +0100 "Domagoj Saric" <domagoj.saric@littleendian.com> wrote:
However, since are provided, I'd like them to be handled as well as possible. Chad has already said that he expects support for them to improve and that's good enough for me, since it won't require breaking the interface.
Maybe I've missed it but I haven't seen concrete ideas as to how exactly Chad plans to do it [...]
<http://permalink.gmane.org/gmane.comp.lib.boost.devel/215984> -- Chad Nelson Oak Circle Software, Inc. * * *
"Chad Nelson" <chad.thecomfychair@gmail.com> wrote in message news:20110315112008.04d53571@ubuntu...
However, since are provided, I'd like them to be handled as well as possible. Chad has already said that he expects support for them to improve and that's good enough for me, since it won't require breaking the interface.
Maybe I've missed it but I haven't seen concrete ideas as to how exactly Chad plans to do it [...]
<http://permalink.gmane.org/gmane.comp.lib.boost.devel/215984>
True, I did miss that one...however AFAICT this is a proposal by Jeffrey Lee Hellrung and it does not quite match what SW was saying ("...since it won't require breaking the interface") as it is a proposal for expanding the interface to accept user defined xint types and, additionally, to which you conclude with "Yes, there's plenty to do before I even seriously think about that." It is also not entirely clear that it would provide 'true fixed-size integer' support (i.e. with near zero overhead) nor that you/XInt would provide a fixed-sized xint type (although, given all the fuss about all of this, I would be content with just the option to be able to provide a fixed-size xint type myself if the library in the end provides no other way of new-virtual-throw-free way of using it). "As said so many times before", it would be a much easier first hand solution to simply separate the algorithms into separate, private, preferably non-template functions. This would benefit even the public-algorithms and concept-modeling-xint-types (to which SW objected) type of design as it would reduce template bloat... -- "What Huxley teaches is that in the age of advanced technology, spiritual devastation is more likely to come from an enemy with a smiling face than from one whose countenance exudes suspicion and hate." Neil Postman
On 25 March 2011 09:30, Domagoj Saric <domagoj.saric@littleendian.com> wrote:
<http://permalink.gmane.org/gmane.comp.lib.boost.devel/215984>
True, I did miss that one...however AFAICT this is a proposal by Jeffrey Lee Hellrung and it does not quite match what SW was saying ("...since it won't require breaking the interface") as it is a proposal for expanding the interface to accept user defined xint types and, additionally, to which you conclude with "Yes, there's plenty to do before I even seriously think about that." It is also not entirely clear that it would provide 'true fixed-size integer' support (i.e. with near zero overhead)
Personally, I'd just supply two different classes and overload the appropriate functions rather than implementing a complicated generic version. It'd probably take less effort and be more pleasant to use (faster compiles and shorter template error messages). Having the two implementations to compare would also be an aid for more ambitious people. If Chad doesn't wish to implement an efficient fixed size integer, and his existing one is consider unacceptable then it could be removed from xint, and left for someone else to implement. They don't need to share code to be interchangeable and if it's as important as you say, I'm sure someone will be willing to put the effort in. IMO requirements for a fast fixed size integer shouldn't deny those who want a dynamically sized integer. Daniel
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Daniel James Sent: Friday, March 25, 2011 9:56 AM To: boost@lists.boost.org Subject: Re: [boost] [xint] quick review
On 25 March 2011 09:30, Domagoj Saric <domagoj.saric@littleendian.com> wrote:
<http://permalink.gmane.org/gmane.comp.lib.boost.devel/215984>
True, I did miss that one...however AFAICT this is a proposal by Jeffrey Lee Hellrung and it does not quite match what SW was saying ("...since it won't require breaking the interface") as it is a proposal for expanding the interface to accept user defined xint types and, additionally, to which you conclude with "Yes, there's plenty to do before I even seriously think about that." It is also not entirely clear that it would provide 'true fixed-size integer' support (i.e. with near zero overhead)
Personally, I'd just supply two different classes and overload the appropriate functions rather than implementing a complicated generic version. It'd
probably
take less effort and be more pleasant to use (faster compiles and shorter template error messages). Having the two implementations to compare would also be an aid for more ambitious people.
If Chad doesn't wish to implement an efficient fixed size integer, and his existing one is consider unacceptable then it could be removed from xint, and left for someone else to implement. They don't need to share code to be interchangeable and if it's as important as you say, I'm sure someone will be willing to put the effort in.
IMO requirements for a fast fixed size integer shouldn't deny those who want a dynamically sized integer.
+1 Paul --- Paul A. Bristow, Prizet Farmhouse, Kendal LA8 8AB UK +44 1539 561830 07714330204 pbristow@hetp.u-net.com
On 25 March 2011 10:56, Daniel James <dnljms@gmail.com> wrote:
Personally, I'd just supply two different classes and overload the appropriate functions rather than implementing a complicated generic version.
The reason I would not do this is because in practice it'll mean yet another incompatible interface, because there will be no requirement to keep two separate libraries in sync. There is a definite need for the fixed but larger than the machine word of my current machine type. If it is part of the implementation of a Boost extended integer library, it remains interface compatible. Plus, it can be a performance win because no dynamic allocation is required, with another win when the fixed size matches the size of a machine word. With only a dynamically sized integer, people who want larger fixed size integers will of course use it if they don't have performance needs (since it is usually easier to adapt something which doesn't quite meet your needs than to implement something from scratch), and may or may not migrate with much pain to some different fixed integer library should it appear in the future. I'd rather we eliminate that potential pain, with the secondary benefit being a performance win. I really do believe that fixed sized integers should be a part of this library. -- Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404
On 25 March 2011 11:41, Nevin Liber <nevin@eviloverlord.com> wrote:
On 25 March 2011 10:56, Daniel James <dnljms@gmail.com> wrote:
Personally, I'd just supply two different classes and overload the appropriate functions rather than implementing a complicated generic version.
The reason I would not do this is because in practice it'll mean yet another incompatible interface, because there will be no requirement to keep two separate libraries in sync.
Why not? You can use well a defined interface and generic unit tests to keep them consistent (it's hard to write sufficiently comprehensive generic unit tests, so they should be used in conjunction with tests written for the individual libraries). Defining robust concepts is very important.
There is a definite need for the fixed but larger than the machine word of my current machine type.
I hope it was clear that I deliberately didn't argue either for or against such a need.
I really do believe that fixed sized integers should be a part of this library.
I disagree. Fixed sized integers would be best implemented by someone who shares your enthusiasm for them. I suppose you could group different implementations by different people under a common banner if that would make you happy. Daniel
On Fri, Mar 25, 2011 at 2:56 AM, Daniel James <dnljms@gmail.com> wrote: [...]
Personally, I'd just supply two different classes and overload the appropriate functions rather than implementing a complicated generic version. It'd probably take less effort and be more pleasant to use (faster compiles and shorter template error messages). Having the two implementations to compare would also be an aid for more ambitious people.
If Chad doesn't wish to implement an efficient fixed size integer, and his existing one is consider unacceptable then it could be removed from xint, and left for someone else to implement. They don't need to share code to be interchangeable and if it's as important as you say, I'm sure someone will be willing to put the effort in.
IMO requirements for a fast fixed size integer shouldn't deny those who want a dynamically sized integer.
+1 to all 3 of above. - Jeff
AMDG On 03/15/2011 06:48 AM, Domagoj Saric wrote:
"Steven Watanabe" <watanabesj@gmail.com> wrote in message news:4D7E2D5D.5050304@providere-consulting.com...
I don't think fixed size integers are necessary for a Boost bigint proposal to begin with.
Why?
A Boost library does not need to be all things to all people. It does need to have a clearly defined scope, and it does need to do it well. I would not generally vote against a library because it is missing feature X, even if X is something that I actually need.
First, AFAIK a significant portion of 'bigint' usage falls into the realm of cryptography and encryption keys which usually have fixed power-of-two sizes and both 'fixed' and 'power-of-two' almost always translate to great simplification/efficiency improvements when one gets to the implementation level. This naturally translates to the question "why should I pay for usage of new, try, catch and throw if all I want is to construct a statically known fixed-size public RSA key and use it to verify a message"?
And of course these things are so much more expensive than the modular exponentiation required by RSA...
Second, AFAICT they are trivial to implement (with the right internal design of course, which was demanded of XInt long time ago but it never happened).
In Christ, Steven Watanabe
"Steven Watanabe" <watanabesj@gmail.com> wrote in message news:4D7F8B1B.8050502@providere-consulting.com...
On 03/15/2011 06:48 AM, Domagoj Saric wrote:
"Steven Watanabe" <watanabesj@gmail.com> wrote in message news:4D7E2D5D.5050304@providere-consulting.com...
I don't think fixed size integers are necessary for a Boost bigint proposal to begin with.
Why?
A Boost library does not need to be all things to all people. It does need to have a clearly defined scope, and it does need to do it well. I would not generally vote against a library because it is missing feature X, even if X is something that I actually need.
Does it need to be "80%" to "80%" of the people? It is not that "I need X", but that many people need/want X _and_ it is relatively trivial to provide X and to, while providing X, implicitly make the library better in other ways (easier extensibility and maintainability, reduced template bloat and compile times...)... But, most importantly, the core issue is the "to begin with"...If the current design and interface (and the author's attitude) left room for 'proper fixed sized integers support' later, without breaking the interface (not that I would object to breaking it but simply know that otherwise change would never happen), then my objections would be vastly toned down (maybe even to an acceptance vote)...However this is not the case here...
First, AFAIK a significant portion of 'bigint' usage falls into the realm of cryptography and encryption keys which usually have fixed power-of-two sizes and both 'fixed' and 'power-of-two' almost always translate to great simplification/efficiency improvements when one gets to the implementation level. This naturally translates to the question "why should I pay for usage of new, try, catch and throw if all I want is to construct a statically known fixed-size public RSA key and use it to verify a message"?
And of course these things are so much more expensive than the modular exponentiation required by RSA...
That's just an overly simplistic argument used just way to often to justify premature pessimization and the production of bloatware. And it really saddens me when I see it used by "prominent boosters"... Of course these things are not "so much more expensive", unless of course they cause a page fault (which sadly is not such a rare event even 'these days' precisely because of the mass production of bloatware...no matter how much RAM you install 'Bill' always finds a way to take it away)... They do however slow down the 'modular exponentiation' itself (additional indirection, worse locality of reference, fragmentation, etc.) but most importantly they induce code bloat and as such affect the whole application (and the entire system in fact). This reasoning is not the fallacious type of the slippery slope argument because the compounded bloat effect is plain obviously demonstrated every day by user computers with OSs that simply idle at the desktop with near 1GB of RAM usage... I see no objective foundation for even having to defend certain efficiency concerns that are IMO really self-evident. For example, if I write an audio application, and I need, as an auxiliary operation, to verify a message, is it so unusual to expect the crypto library used not to add more code to my binary than all of the many dozens of DSP algorithms that make the core and purpose of the application in question? See here http://boost.2283326.n4.nabble.com/Re-Crypto-Proposal-td2671858.html for my analysis of exactly such a problem with real world numbers that demonstrate where does injudicious/by default usage of new, virtual and throw (or their higher level monster-friends, like std::streams) lead... -- "What Huxley teaches is that in the age of advanced technology, spiritual devastation is more likely to come from an enemy with a smiling face than from one whose countenance exudes suspicion and hate." Neil Postman
participants (12)
-
Chad Nelson -
Daniel James -
Domagoj Saric -
Domagoj Saric -
Gordon Woodhull -
Jeffrey Lee Hellrung, Jr. -
Julian Gonggrijp -
Nevin Liber -
Paul A. Bristow -
Phil Endecott -
Steven Watanabe -
Stewart, Robert