From: si-units-list@si-units (si-units-digest) To: si-units-digest@si-units Subject: si-units-digest V1 #7 Reply-To: si-units-list@si-units Sender: si-units-list@si-units Errors-To: si-units-list@si-units Precedence: bulk si-units-digest Wednesday, June 26 2002 Volume 01 : Number 007 In this issue: Re: SI Units Project: Display (output) of units Re: SI Units Project: Display (output) of units SI Units Project: First posting RE: SI Units Project: Display (output) of units Re: SI Units Project: Display (output) of units Re: SI Units Project: First posting Re: SI Units Project: First posting RE: SI Units Project: Display (output) of units Re: SI Units Project: Display (output) of units RE: SI Units Project: First posting RE: SI Units Project: Requirements Re: SI Units Project: Requirements Re: SI Units Project: Requirements Re: SI Units Project: Requirements Re: SI Units Project: Requirements ---------------------------------------------------------------------- Date: Sat, 15 Jun 2002 10:03:08 +0000 From: Mark Easterbrook Subject: Re: SI Units Project: Display (output) of units Terje Slettebx wrote: > > >From: "Mark Easterbrook" > > > By the way, be aware that even with defaults, the angle brackets are needed. > That is, if there's no parameters beside the default, it's specified like > this: "Type<> value;". This is like default parameters for functions. Ah, cogs kick in to place. After so many years programming I often get a feel that something won't work, even before trying it. I had this with: length x; as a short cut to length x; Yet I remembered reading somewhere about default arguments to templates. So it was not the default arguments I was wrong on, but the format of the short form! I really must re-read the chapters on templates :) > > Regards, > > Terje - -- mark@si-units ------------------------------ Date: Sat, 15 Jun 2002 15:07:45 +0200 From: Terje Slettebx Subject: Re: SI Units Project: Display (output) of units >From: "Mark Easterbrook" > Terje Slettebx wrote: > > > > By the way, be aware that even with defaults, the angle brackets are needed. > > That is, if there's no parameters beside the default, it's specified like > > this: "Type<> value;". This is like default parameters for functions. > > Ah, cogs kick in to place. :) I had a feeling this might be the reason for the interest in defaults. They are fine for eliminating parameters, but as shown, they don't eliminate the angle brackets. I first came across this a while ago, when reading the docs of the Spirit parser framework. I came across curious things, such as: Rule<> someRule(...); > After so many years programming I often get a feel that something won't > work, even before trying it. I had this with: > > length x; > > as a short cut to > > length x; I thought so, too, until I tried it (and read the mentioned docs), and found it couldn't be done that way. What you _can_ do, is to provide typedefs, of course, or even get the effect of templated typedefs. > Yet I remembered reading somewhere about default arguments to templates. > So it was not the default arguments I was wrong on, but the format of > the short form! > > I really must re-read the chapters on templates :) The rules are so complex, some places, so it has inspired a limerick in the standard (14.7.3/7) (it's separated out, below): "The placement of explicit specialization declarations for function templates, class templates, member functions of class templates, static data members of class templates, member classes of class templates, member class templates of class templates, member function templates of class templates, member functions of member templates of class templates, member functions of member templates of non-template classes, member function templates of member classes of class templates, etc., and the placement of partial specialization declarations of class templates, member class templates of non-template classes, member class templates of class templates, etc., can affect whether a program is well-formed according to the relative positioning of the explicit specialization declarations and their points of instantiation in the translation unit as specified above and below. When writing a specialization, be careful about its location; or to make it compile will be such a trial as to kindle its self-immolation." :) (http://makeashorterlink.com/?T27B12011) As one poster remarked: "Perhaps more standards should be written in this manner! After all, it makes very clear the consequences of failing to observe the constraints. Not "undefined", "ambiguous", etc. but "a trial such as to kindle self- immolation". I like that." Regards, Terje ------------------------------ Date: Tue, 18 Jun 2002 13:32:44 +0100 From: "Watts, Simon (UK)" Subject: SI Units Project: First posting Hello folks, I read with interest the report of this project in the latest CVu (June 2002), and thought that I would sign on. I (and collegues in the past) have been considering a similar dimensioned-units class for a number of years -- it was more appropriate in my previous incarnation (research scientist; maths, physics, computing), but since I sold out to IT I like to keep up the pretence of being a closet scientist ;-) There was a fair bit of over-coffee hand waving, and bits of test code (in MATLAB). In MATLAB, the implimentation toyed with was a pairing of (magnitude, dimension-vector), where dimension-vector contained the powers of the principle dimensions. Operations where implimented as the operation on the magnitude, and the corresponding op on the dimension vector (including an error under addition or subtraction between difference dimensioned values). Under C++, the dimension vector would become template parameters, giving a great opportunity to play with meta/generic programming. (--> compile time checking etc). Java would be back with a dynamic dimension vector (I don't beleve that JR0014/JDK1.5[?] will support value based generics). We had conceptual problems when we came to consider some of the derived units. Example 1: Both Bequerel and Hertz have units s^(-1), but measure different things ("random" events per second, and periodic events per second). If the system relied only on the dimensionality of the data, then it could end up transparently converting between the two. Example 2: Radians and Steradians are defined as (m/m) and (m^2/m^2) respectively. They are dimensionless, but distinct, and not all ratios of distance or area represent rad or sr (though the responsibility for this is up to the users). Now, the units mentioned about are outside the initial scope of the requirements doc (on the project homepage), but the issues will have to be considered at some stage. I think that the part of this that interests me the most at the moment, is the application of meta/generic programming in C++. (My current work project is in Java, so I need to keep the C++ part of my brain ticking over!). I have only started exploring what can be done with this method over the last year or so (esp. after reading the articles in overload on the subject). Anyway, how active is this project? Simon. ------------------------------ Date: Tue, 18 Jun 2002 14:46:32 +0100 From: R.D.Hughes@si-units Subject: RE: SI Units Project: Display (output) of units > >You should be able to, for example(*), divide by 1000 and > > then > > multiply by 1000 and end up effectivily where you started - > you cannot > > do > > this with an integer type > > Whether or not this is a concern, is up to the user, not the library. I do follow this logic but remain unconvinced as it would break all the fundamental tenets of HCI by allowing access to a feature which doesn't function as the 'average' user would expect. We are presenting a feature to the users that doesn't reflect any domain usage they would be experienced with. The difference between types is intuitive to experienced programmers and may not seem to be a problem, but I can assure you that many many scientists who create their own software are not that knowledgeable in what is only a sideline for them (this is particularly true once you move away from the physical, and thus more numerate, sciences). Note that the problem is really with mixed-type arithmetic, but allowing integer types but only in single-type arithmetic is also problematic from an HCI point of view. Essentially you can consider that 'paper' mathematics allows an implicit type conversion between integer and floating point types, so preventing this conversion also presents a system that doesn't function in the expected manner. Rob ------------------------------ Date: Tue, 18 Jun 2002 18:52:28 +0200 From: Terje Slettebx Subject: Re: SI Units Project: Display (output) of units >From: > > >You should be able to, for example(*), divide by 1000 and > > > then > > > multiply by 1000 and end up effectivily where you started - > > you cannot do this with an integer type > > > > Whether or not this is a concern, is up to the user, not the library. > > I do follow this logic but remain unconvinced as it would break all the > fundamental tenets of HCI by allowing access to a feature which doesn't > function as the 'average' user would expect. We are presenting a feature to > the users that doesn't reflect any domain usage they would be experienced > with. The difference between types is intuitive to experienced programmers > and may not seem to be a problem, but I can assure you that many many > scientists who create their own software are not that knowledgeable in what > is only a sideline for them (this is particularly true once you move away > from the physical, and thus more numerate, sciences). > > Note that the problem is really with mixed-type arithmetic, but allowing > integer types but only in single-type arithmetic is also problematic from an > HCI point of view. Essentially you can consider that 'paper' mathematics > allows an implicit type conversion between integer and floating point types, > so preventing this conversion also presents a system that doesn't function > in the expected manner. So how do you propose we do it? I mean, what interface should the type have? Other such libraries are usually parameterized on type, such as the mentioned std::complex, and other such mathematical libraries. Regards, Terje ------------------------------ Date: Tue, 18 Jun 2002 19:47:40 +0000 From: Mark Easterbrook Subject: Re: SI Units Project: First posting "Watts, Simon (UK)" wrote: > > Hello folks, > Thanks for introducing yourself and your background. It looks like you have a lot to bring to the project. > > Anyway, how active is this project? Bursty! Sometimes it is quiet for a few weeks, then someone thinks of something and there is lots of traffic for a few days, then we go back to thinking and perhaps trying out a few things. A couple of developers have some code almost ready to share (hint hint guys!). :) I think a slow start is useful as it allows others such as yourself to come on board without missing too much of the initial discussions (although you can always catch up by reading the archives on the web page). I expect a burst of new members now CVu has hit the doormats. Mine arrived Saturday morning. It will take longer for the overseas members to get their copies. > > Simon. - -- mark@si-units ------------------------------ Date: Tue, 18 Jun 2002 22:25:44 +0200 From: Terje Slettebx Subject: Re: SI Units Project: First posting >From: "Watts, Simon (UK)" Hi and welcome to the project, Simon. :) Just to take your last part, first: > Anyway, how active is this project? It's going fine. It hasn't been done that much here, yet, because people have been busy with various obligations, it seems. Myself, I've been quite busy at school, until recently. A few of us have been playing with some code, Pete and I, and possibly others. Different code, that is. I only had a chance to work on it a few days, about a month ago, before I had to concentrate on exams, but will resume it soon, now. I think there's an excellent requirements specification that have been made. > I read with interest the report of this project in the latest CVu (June > 2002), and thought that I would sign on. > > Under C++, the dimension vector would become template parameters, giving a > great opportunity to play with meta/generic programming. (--> compile time > checking etc). That's exactly the approach I'm taking. :) > Java would be back with a dynamic dimension vector (I don't > beleve that JR0014/JDK1.5[?] will support value based generics). Yeah. That's why the C++ and any Java implementation should be separate. > We had conceptual problems when we came to consider some of the derived > units. > > Example 1: Both Bequerel and Hertz have units s^(-1), but measure different > things ("random" events per second, and periodic events per second). If the > system relied only on the dimensionality of the data, then it could end up > transparently converting between the two. > > Example 2: Radians and Steradians are defined as (m/m) and (m^2/m^2) > respectively. They are dimensionless, but distinct, and not all ratios of > distance or area represent rad or sr (though the responsibility for this is > up to the users). Good points. I've considered this, as well. > Now, the units mentioned about are outside the initial scope of the > requirements doc (on the project homepage), but the issues will have to be > considered at some stage. Yes. One should have an overview of the SI system, so one may avoid a major reorganization of the code, if one were to extend it. > I think that the part of this that interests me the most at the moment, is > the application of meta/generic programming in C++. (My current work > project is in Java, so I need to keep the C++ part of my brain ticking > over!). Oh yeah. :) I worked on a Java applet for a company about half a year ago, too, and I used any excuse I could, for doing something in C++, instead. :) I managed to finish the Java applet, eventually, though. :) > I have only started exploring what can be done with this method > over the last year or so (esp. after reading the articles in overload on the > subject). Metaprogramming is a huge area, yes. Even so many years after I started to learn C++, I'm still amazed of what you can do in C++. There's some amazing libraries being made, now, such as MPL (Metaprogramming Library), Boost Lambda Library, FC++, the Spirit parser framework, etc. These combine paradigms, such as OO and generic programming, in novel ways. By the way, the best book I've read recently is "Multi-Paradigm Design in C++" by Jim Coplien, which deals with this, as well. Regards, Terje ------------------------------ Date: Wed, 19 Jun 2002 09:30:42 +0100 From: R.D.Hughes@si-units Subject: RE: SI Units Project: Display (output) of units > So how do you propose we do it? I mean, what interface should > the type have? > > Other such libraries are usually parameterized on type, such as the > mentioned std::complex, and other such mathematical libraries. There is a slight difference because of the intended domain audience (i.e. anyone using a complex number/mathematical libary is likely to be literate in both maths and programming). I agree that in an ideal world we should parameterize on type, but I worry (given my own experience of the mathematical and computing abilities of many of my former research colleagues, many of whom frequently attempt to write data processing code...), that this could produce something as unintuitive and dangerous as overloading operator+ to perform multiplication... Never confuse mathematicians/physicists with other areas of science when it comes to mathematical ability - many people are in biology and earth science in particular because they lacked the mathematical talents to make it in more numerate disciplines. Perhaps we should just accept it as a case of 'caveat non coepi' or 'caveat profanus' (my latin was never very good), and let the uninitiated beware. I guess if the default type is a double as has been suggested then we have at least provided a minimal level of protection for the most misguided. Rob ------------------------------ Date: Wed, 19 Jun 2002 23:39:15 +0200 From: Terje Slettebx Subject: Re: SI Units Project: Display (output) of units >From: > > So how do you propose we do it? I mean, what interface should > > the type have? > > > > Other such libraries are usually parameterized on type, such as the > > mentioned std::complex, and other such mathematical libraries. > > There is a slight difference because of the intended domain audience (i.e. > anyone using a complex number/mathematical libary is likely to be literate > in both maths and programming). I agree that in an ideal world we should > parameterize on type, but I worry (given my own experience of the > mathematical and computing abilities of many of my former research > colleagues, many of whom frequently attempt to write data processing > code...), that this could produce something as unintuitive and dangerous as > overloading operator+ to perform multiplication... I understand your point. > Never confuse > mathematicians/physicists with other areas of science when it comes to > mathematical ability - many people are in biology and earth science in > particular because they lacked the mathematical talents to make it in more > numerate disciplines. > > Perhaps we should just accept it as a case of 'caveat non coepi' or 'caveat > profanus' (my latin was never very good) Or simply: Quidquid latine dictum sit, altum viditur. ("Anything in Latin sounds profound") :) >, and let the uninitiated beware. I > guess if the default type is a double as has been suggested then we have at > least provided a minimal level of protection for the most misguided. Yes, that's one way. I don't know if that would help much, though. If a user doesn't know the fundamentals of C++, where the library is used, then how would they be able to use such a library, in the first place? Anyway, these things are easy to change, and the way the user specifies the type, shouldn't affect the core library design. Regards, Terje ------------------------------ Date: Thu, 20 Jun 2002 09:20:11 +0100 From: "Watts, Simon (UK)" Subject: RE: SI Units Project: First posting > > Example 1: Both Bequerel and Hertz have units s^(-1), but measure > > different things ... > > Example 2: Radians and Steradians are defined as (m/m) and (m^2/m^2) > > respectively. They are dimensionless, but distinct ... > > Good points. I've considered this, as well. Thinking more on this, there is the general case of "counting `things'" -- a open set of otherwise dimensionless but distinct measurements. In effect, each type of thing would be another element in the `dimension vector'. So Bequerels would be ( Events=1, Seconds=-1 ), Hertz would be ( Oscillations=1, Seconds=-1), Radians would be ( Angle=1 ), Steradians ( SolidAngle=1 ). While there are ways to express lists in C++ metaprogramming, solving and sorting operations on them could be tricky... I can see why the initial reqs are only concerned with the basic SI units! This should not be a problem in a runtime approach though, so maybe leave the `things' counting dimensions as a dynamic vector, and rely on throwing runtime type-mismatch errors where appropriate. Just keep the base units for compile time checks. A slight footnote to this: I was a graph in a stats and/or agriculture book, which plotted "eggs per hen" against "bushels per acre", which would give a gradient measured in "hen-bushels per egg-acre"... Si. ------------------------------ Date: Thu, 20 Jun 2002 12:21:00 -0400 From: "Vaidya, Maulik" Subject: RE: SI Units Project: Requirements Hello all, I should apologise for not being active at all in this project list... I have really been busy with lots of stuff(at work and home)...... :-)(the usual excuse anyone uses to get out of a situation :-) ) Has anyone written some code yet?? If so, could it be posted?? so that i can have an idea as to how to deal with templates etc etc.... (i dont think i know much about them).. My apologies once again Regards ------------------------------ Date: Thu, 20 Jun 2002 18:45:01 +0000 From: Mark Easterbrook Subject: Re: SI Units Project: Requirements "Vaidya, Maulik" wrote: > > Hello all, > > I should apologise for not being active at all in this project list... No problem. The rest of us haven't been very active either (a few bursts of traffic now and again). A slow start is good because we can throw around a few ideas and not rush into a solution. > > I have really been busy with lots of stuff(at work and home)...... :-)(the > usual excuse anyone uses to get out of a situation :-) ) > > Has anyone written some code yet?? If so, could it be posted?? so that i > can have an idea as to how to deal with templates etc etc.... (i dont think > i know much about them).. There is some code "not quite ready yet". :) > > My apologies once again > > Regards - -- mark@si-units ------------------------------ Date: Thu, 20 Jun 2002 21:58:39 +0200 From: Terje Slettebx Subject: Re: SI Units Project: Requirements >From: "Vaidya, Maulik" Hi Vaidya, and the following is a reply to Mark's recent posint, as well. > Has anyone written some code yet?? If so, could it be posted?? so that i > can have an idea as to how to deal with templates etc etc.... (i dont think > i know much about them).. I have written some, about a month ago, but I haven't had a chance to get back to it, yet. I'd like to do some more on it, before posting anything. Part of the reason for this is that I also have the task of porting Loki to Borland C++ Builder, a project that predates my involvement with the SI units project. I had to suspend both, until the beginning of June, because of the school. However, I'll soon get to the SI units project. I had originally planned to resume the SI units project first, because I find it more interesting, than the porting. :) But then I got a mail from Andrei, a few days ago, wondering how the porting went. :) Since I had taken on that project earlier, I feel that I should work on that, first, now, especially since I got a mail about it. Both of these projects are important to me, and I find both interesting. I'll get back to this project as soon as I can. Sorry for this. It shouldn't be that long, now. Regards, Terje ------------------------------ Date: Sun, 23 Jun 2002 20:02:45 -0700 From: Pete and Lana Klier Subject: Re: SI Units Project: Requirements I just came back from vacation. I've been considering throwing out some code... I think it's about the right time to do it. Vaidya, Maulik wrote: > Hello all, > > I should apologise for not being active at all in this project list... > > I have really been busy with lots of stuff(at work and home)...... :-)(the > usual excuse anyone uses to get out of a situation :-) ) > > Has anyone written some code yet?? If so, could it be posted?? so that i > can have an idea as to how to deal with templates etc etc.... (i dont think > i know much about them).. > > My apologies once again > > Regards ------------------------------ Date: Tue, 25 Jun 2002 19:55:09 -0700 From: Pete and Lana Klier Subject: Re: SI Units Project: Requirements This is a multi-part message in MIME format. - --Boundary_(ID_yw33H5zotcXT4MDWL9aHEA) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Here's some code that works on the g++ compiler, although it may be stretching the capabilities of other compilers -- it isn't recognized on an old Borland compiler, for instance. Feel free to port, critique, clean up, merge with your own code etc. This version recognizes everything that can be derived from metres, kilograms, seconds, and coulombs (OK, could be amperes) (no candles or kelvins or anything). The basic parameterized type is mksmeasure. An incorrect type operation will result in a compile-time error but it is ugly (room for improvement). For compilers that aren't as capable as g++, we may need to think of something else. - ---------------------------------------------------------------------------- mksmeasure.h: #ifndef __MKSMEASURE__ #define __MKSMEASURE__ template class mksmeasure { private: T value_; mksmeasure (void); // No default constructor for safety protected: mksmeasure (const T & number) : value_(number) {}; operator const T & (void) const { return value_; }; mksmeasure operator = (const T &rhs) { value_ = number; }; public: static mksmeasure mksmeasure_from_number (const T &number) { return mksmeasure(number); } const T & number_from_mksmeasure (void) const { return value_; }; mksmeasure (const mksmeasure &rhs) : value_(rhs.value_) {}; template mksmeasure(const mksmeasure &rhs) : value_(rhs.number_from_mksmeasure()) {}; template operator mksmeasure (void) const { return mksmeasure(*this); }; // No dtor, let T::operator = handle everything mksmeasure operator = (const mksmeasure &rhs) { value_ = rhs.value_; } mksmeasure operator + (const mksmeasure &rhs) { return mksmeasure(value_ + rhs.value_); }; mksmeasure operator - (const mksmeasure &rhs) { return mksmeasure(value_ - rhs.value_); }; mksmeasure operator += (const mksmeasure &rhs) { value_ += rhs.value_; return mksmeasure(value_); }; mksmeasure operator -= (const mksmeasure &rhs) { value_ += rhs.value_; return mksmeasure(value_); }; // Multiplication and division by dimensionless mksmeasure operator * (const T &rhs) const { return mksmeasure(value_ * rhs); }; mksmeasure pre_multiply (const T &lhs) const { return mksmeasure(lhs * value_); }; mksmeasure operator / (const T &rhs) const { return mksmeasure(value_ / rhs); }; mksmeasure & operator /= (const T &rhs) { value_ /= rhs; return *this; }; mksmeasure & operator *= (const T &rhs) { value_ *= rhs; return *this; }; mksmeasure square (void) const { return (*this) * (*this); }; }; template mksmeasure operator * (const T &lhs, const mksmeasure &rhs) { return rhs.pre_multiply(lhs); }; #endif mksmuldiv: #ifndef __MKSMULDIV__ #define __MKSMULDIV__ // This assumes a mksmeasure of T all around, can be improved template mksmeasure operator * (const mksmeasure &lhs, const mksmeasure &rhs) { return mksmeasure ::mksmeasure_from_number (lhs.number_from_mksmeasure() * rhs.number_from_mksmeasure()) ; } template mksmeasure operator / (const mksmeasure &lhs, const mksmeasure &rhs) { return mksmeasure ::mksmeasure_from_number (lhs.number_from_mksmeasure() / rhs.number_from_mksmeasure()) ; } #endif Pete and Lana Klier wrote: > I just came back from vacation. > > I've been considering throwing out some code... I think it's about the > right time to do it. > > Vaidya, Maulik wrote: > > > Hello all, > > > > I should apologise for not being active at all in this project list... > > > > I have really been busy with lots of stuff(at work and home)...... :-)(the > > usual excuse anyone uses to get out of a situation :-) ) > > > > Has anyone written some code yet?? If so, could it be posted?? so that i > > can have an idea as to how to deal with templates etc etc.... (i dont think > > i know much about them).. > > > > My apologies once again > > > > Regards - --Boundary_(ID_yw33H5zotcXT4MDWL9aHEA) Content-type: application/x-unknown-content-type-CHeaderFile; name=mksmeasure.h Content-transfer-encoding: base64 Content-disposition: inline; filename=mksmeasure.h I2lmbmRlZiBfX01LU01FQVNVUkVfXwojZGVmaW5lIF9fTUtTTUVBU1VSRV9fCgp0ZW1wbGF0 ZSA8Y2xhc3MgVCxpbnQgTSwgaW50IEssIGludCBTLCBpbnQgQz4KY2xhc3MgbWtzbWVhc3Vy ZQp7CnByaXZhdGU6CiAgVCB2YWx1ZV87CgoKICBta3NtZWFzdXJlICh2b2lkKTsgLy8gTm8g ZGVmYXVsdCBjb25zdHJ1Y3RvciBmb3Igc2FmZXR5CgoKcHJvdGVjdGVkOgoKICBta3NtZWFz dXJlIChjb25zdCBUICYgbnVtYmVyKSA6IHZhbHVlXyhudW1iZXIpIHt9OyAKCiAgb3BlcmF0 b3IgY29uc3QgVCAmICh2b2lkKSBjb25zdCB7IHJldHVybiB2YWx1ZV87IH07CiAgCiAgbWtz bWVhc3VyZSBvcGVyYXRvciA9IChjb25zdCBUICZyaHMpIHsgdmFsdWVfID0gbnVtYmVyOyB9 OwoKcHVibGljOgoKICBzdGF0aWMgbWtzbWVhc3VyZSBta3NtZWFzdXJlX2Zyb21fbnVtYmVy IChjb25zdCBUICZudW1iZXIpIAogICAgewogICAgICByZXR1cm4gbWtzbWVhc3VyZShudW1i ZXIpOwogICAgfQoKICBjb25zdCBUICYgbnVtYmVyX2Zyb21fbWtzbWVhc3VyZSAodm9pZCkg Y29uc3QgeyByZXR1cm4gdmFsdWVfOyB9OwoKICBta3NtZWFzdXJlIChjb25zdCBta3NtZWFz dXJlICZyaHMpIDogdmFsdWVfKHJocy52YWx1ZV8pIHt9OwoKICB0ZW1wbGF0ZTxjbGFzcyBV PiBta3NtZWFzdXJlKGNvbnN0IG1rc21lYXN1cmU8VSxNLEssUyxDPiAmcmhzKSAKICAgIDog dmFsdWVfKHJocy5udW1iZXJfZnJvbV9ta3NtZWFzdXJlKCkpIHt9OwoKICB0ZW1wbGF0ZSA8 Y2xhc3MgVT4gb3BlcmF0b3IgbWtzbWVhc3VyZTxVLE0sSyxTLEM+ICh2b2lkKSBjb25zdAog ICAgeyByZXR1cm4gbWtzbWVhc3VyZTxVLE0sSyxTLEM+KCp0aGlzKTsgfTsKCgogIC8vIE5v IGR0b3IsIGxldCBUOjpvcGVyYXRvciA9IGhhbmRsZSBldmVyeXRoaW5nIAogIG1rc21lYXN1 cmUgb3BlcmF0b3IgPSAoY29uc3QgbWtzbWVhc3VyZSAmcmhzKSAKICB7CiAgICB2YWx1ZV8g PSByaHMudmFsdWVfOwogIH0KCiAgbWtzbWVhc3VyZSBvcGVyYXRvciArIChjb25zdCBta3Nt ZWFzdXJlICZyaHMpIAogIHsKICAgIHJldHVybiBta3NtZWFzdXJlKHZhbHVlXyArIHJocy52 YWx1ZV8pOwogIH07CgogIG1rc21lYXN1cmUgb3BlcmF0b3IgLSAoY29uc3QgbWtzbWVhc3Vy ZSAmcmhzKQogIHsKICAgIHJldHVybiBta3NtZWFzdXJlKHZhbHVlXyAtIHJocy52YWx1ZV8p OwogIH07CgogIG1rc21lYXN1cmUgb3BlcmF0b3IgKz0gKGNvbnN0IG1rc21lYXN1cmUgJnJo cykKICB7CiAgICB2YWx1ZV8gKz0gcmhzLnZhbHVlXzsKICAgIHJldHVybiBta3NtZWFzdXJl KHZhbHVlXyk7CiAgfTsKCiAgbWtzbWVhc3VyZSBvcGVyYXRvciAtPSAoY29uc3QgbWtzbWVh c3VyZSAmcmhzKQogIHsKICAgIHZhbHVlXyArPSByaHMudmFsdWVfOwogICAgcmV0dXJuIG1r c21lYXN1cmUodmFsdWVfKTsKICB9OwoKICAvLyBNdWx0aXBsaWNhdGlvbiBhbmQgZGl2aXNp b24gYnkgZGltZW5zaW9ubGVzcwoKICBta3NtZWFzdXJlIG9wZXJhdG9yICogKGNvbnN0IFQg JnJocykgY29uc3QKICAgIHsKICAgICAgcmV0dXJuIG1rc21lYXN1cmUodmFsdWVfICogcmhz KTsKICAgIH07CgogIG1rc21lYXN1cmUgcHJlX211bHRpcGx5IChjb25zdCBUICZsaHMpIGNv bnN0CiAgICB7CiAgICAgIHJldHVybiBta3NtZWFzdXJlKGxocyAqIHZhbHVlXyk7CiAgICB9 OwoKICBta3NtZWFzdXJlIG9wZXJhdG9yIC8gKGNvbnN0IFQgJnJocykgY29uc3QKICAgIHsK ICAgICAgcmV0dXJuIG1rc21lYXN1cmUodmFsdWVfIC8gcmhzKTsKICAgIH07CgogIG1rc21l YXN1cmUgJiBvcGVyYXRvciAvPSAoY29uc3QgVCAmcmhzKSAKICB7CiAgICB2YWx1ZV8gLz0g cmhzOwogICAgcmV0dXJuICp0aGlzOwogIH07CgogIG1rc21lYXN1cmUgJiBvcGVyYXRvciAq PSAoY29uc3QgVCAmcmhzKQogIHsKICAgIHZhbHVlXyAqPSByaHM7CiAgICByZXR1cm4gKnRo aXM7CiAgfTsKCgogIG1rc21lYXN1cmU8VCwyKk0sMipLLDIqUywyKkM+IHNxdWFyZSAodm9p ZCkgY29uc3QKICAgIHsKICAgICAgcmV0dXJuICgqdGhpcykgKiAoKnRoaXMpOwogICAgfTsK fTsKCnRlbXBsYXRlIDxjbGFzcyBULGludCBNLCBpbnQgSywgaW50IFMsIGludCBDPiAKICBt a3NtZWFzdXJlPFQsTSxLLFMsQz4gb3BlcmF0b3IgKiAKICAgIChjb25zdCBUICZsaHMsIGNv bnN0IG1rc21lYXN1cmU8VCxNLEssUyxDPiAmcmhzKQp7CiAgcmV0dXJuIHJocy5wcmVfbXVs dGlwbHkobGhzKTsgCn07CgoKI2VuZGlmCgo= - --Boundary_(ID_yw33H5zotcXT4MDWL9aHEA) Content-type: application/x-unknown-content-type-CHeaderFile; name=mksmuldiv.h Content-transfer-encoding: base64 Content-disposition: inline; filename=mksmuldiv.h I2lmbmRlZiBfX01LU01VTERJVl9fCiNkZWZpbmUgX19NS1NNVUxESVZfXwoKLy8gVGhpcyBh c3N1bWVzIGEgbWtzbWVhc3VyZSBvZiBUIGFsbCBhcm91bmQsIGNhbiBiZSBpbXByb3ZlZAoK dGVtcGxhdGU8Y2xhc3MgVCxpbnQgbWV0ZXIxLGludCBraWxvMSxpbnQgc2VjMSxpbnQgY291 bDEsCiAgICAgICAgICAgICAgICAgaW50IG1ldGVyMixpbnQga2lsbzIsaW50IHNlYzIsaW50 IGNvdWwyPgogIG1rc21lYXN1cmU8VCxtZXRlcjErbWV0ZXIyLGtpbG8xK2tpbG8yLHNlYzEr c2VjMixjb3VsMStjb3VsMj4gCiAgICAgb3BlcmF0b3IgKiAoY29uc3QgbWtzbWVhc3VyZTxU LG1ldGVyMSxraWxvMSxzZWMxLGNvdWwxPiAmbGhzLAogICAgICAgICAgICAgICAgIGNvbnN0 IG1rc21lYXN1cmU8VCxtZXRlcjIsa2lsbzIsc2VjMixjb3VsMj4gJnJocykKewogICAgcmV0 dXJuIAogICAgICBta3NtZWFzdXJlPFQsbWV0ZXIxK21ldGVyMixraWxvMStraWxvMixzZWMx K3NlYzIsY291bDErY291bDI+CiAgICAgICAgICAgOjpta3NtZWFzdXJlX2Zyb21fbnVtYmVy ICAgICAgICAgCiAgICAgICAgICAgIChsaHMubnVtYmVyX2Zyb21fbWtzbWVhc3VyZSgpICog cmhzLm51bWJlcl9mcm9tX21rc21lYXN1cmUoKSkgOwp9Cgp0ZW1wbGF0ZTxjbGFzcyBULGlu dCBtZXRlcjEsaW50IGtpbG8xLGludCBzZWMxLGludCBjb3VsMSwKICAgICAgICAgICAgICAg ICBpbnQgbWV0ZXIyLGludCBraWxvMixpbnQgc2VjMixpbnQgY291bDI+CiAgbWtzbWVhc3Vy ZTxULG1ldGVyMSAtIG1ldGVyMixraWxvMSAtIGtpbG8yLHNlYzEgLSBzZWMyLGNvdWwxIC0g Y291bDI+IAogICAgIG9wZXJhdG9yIC8gKGNvbnN0IG1rc21lYXN1cmU8VCxtZXRlcjEsa2ls bzEsc2VjMSxjb3VsMT4gJmxocywKICAgICAgICAgICAgICAgICBjb25zdCBta3NtZWFzdXJl PFQsbWV0ZXIyLGtpbG8yLHNlYzIsY291bDI+ICZyaHMpCnsKICAgIHJldHVybiAKICAgICAg bWtzbWVhc3VyZTxULG1ldGVyMSAtIG1ldGVyMixraWxvMSAtIGtpbG8yLHNlYzEgLSBzZWMy LGNvdWwxIC0gY291bDI+CiAgICAgICAgIDo6bWtzbWVhc3VyZV9mcm9tX251bWJlciAgICAg CiAgICAgICAgICAgICAobGhzLm51bWJlcl9mcm9tX21rc21lYXN1cmUoKSAvIHJocy5udW1i ZXJfZnJvbV9ta3NtZWFzdXJlKCkpIDsKfQoKI2VuZGlmCg== - --Boundary_(ID_yw33H5zotcXT4MDWL9aHEA)-- ------------------------------ End of si-units-digest V1 #7 ****************************