Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #138493 > unrolled thread
| Started by | Bart <bc@freeuk.com> |
|---|---|
| First post | 2018-12-04 12:17 +0000 |
| Last post | 2018-12-25 15:54 +0000 |
| Articles | 20 on this page of 140 — 29 participants |
Back to article view | Back to comp.lang.c
Big integers Bart <bc@freeuk.com> - 2018-12-04 12:17 +0000
Re: Big integers fir <profesor.fir@gmail.com> - 2018-12-04 05:58 -0800
Re: Big integers Chad <cdalten@gmail.com> - 2018-12-04 08:22 -0800
Re: Big integers Bart <bc@freeuk.com> - 2018-12-04 17:04 +0000
Re: Big integers scott@slp53.sl.home (Scott Lurndal) - 2018-12-04 17:19 +0000
Re: Big integers Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-12-04 08:38 -0800
Re: Big integers Bart <bc@freeuk.com> - 2018-12-04 17:35 +0000
Re: Big integers Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-12-04 18:13 +0000
Re: Big integers "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-12-04 10:50 -0800
Re: Big integers Rosario19 <Ros@invalid.invalid> - 2018-12-06 17:56 +0100
Re: Big integers Thiago Adams <thiago.adams@gmail.com> - 2018-12-04 10:22 -0800
Re: Big integers Eli the Bearded <*@eli.users.panix.com> - 2018-12-04 18:58 +0000
Re: Big integers Thiago Adams <thiago.adams@gmail.com> - 2018-12-04 11:32 -0800
Re: Big integers Eli the Bearded <*@eli.users.panix.com> - 2018-12-04 22:45 +0000
Re: Big integers jameskuyper@alumni.caltech.edu - 2018-12-04 14:57 -0800
Re: Big integers jameskuyper@alumni.caltech.edu - 2018-12-04 12:14 -0800
Re: Big integers chris.m.thomasson.1@gmail.com - 2018-12-04 16:58 -0800
Re: Big integers Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-12-05 03:14 +0000
Re: Big integers "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid> - 2018-12-05 14:27 -0800
Re: Big integers Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2018-12-04 20:03 -0500
Re: Big integers "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid> - 2018-12-05 14:25 -0800
Re: Big integers jacob navia <jacob@jacob.remcomp.fr> - 2018-12-04 23:45 +0100
Re: Big integers Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-12-04 23:29 +0000
Re: Big integers Bart <bc@freeuk.com> - 2018-12-05 00:30 +0000
Re: Big integers "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid> - 2018-12-05 14:28 -0800
Re: Big integers Jens Stuckelberger <Jens_Stuckelberger@nowhere.net> - 2018-12-05 17:50 +0000
Re: Big integers jacobnavia <jacob@jacob.remcomp.fr> - 2018-12-05 20:03 +0100
Re: Big integers Keith Thompson <kst-u@mib.org> - 2018-12-05 13:46 -0800
Re: Big integers jacobnavia <jacob@jacob.remcomp.fr> - 2018-12-06 06:41 +0100
Re: Big integers Keith Thompson <kst-u@mib.org> - 2018-12-05 22:40 -0800
Re: Big integers "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-12-04 09:08 -0800
Re: Big integers Bart <bc@freeuk.com> - 2018-12-04 19:41 +0000
Re: Big integers "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-12-04 12:00 -0800
Re: Big integers Bart <bc@freeuk.com> - 2018-12-08 11:28 +0000
Re: Big integers Ian Collins <ian-news@hotmail.com> - 2018-12-05 15:19 +1300
Re: Big integers Bart <bc@freeuk.com> - 2018-12-05 11:58 +0000
Re: Big integers David Brown <david.brown@hesbynett.no> - 2018-12-05 14:35 +0100
Re: Big integers Bart <bc@freeuk.com> - 2018-12-05 14:35 +0000
Re: Big integers Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-12-05 07:39 -0800
Re: Big integers Thiago Adams <thiago.adams@gmail.com> - 2018-12-05 07:45 -0800
Re: Big integers Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-12-05 17:51 +0000
Re: Big integers David Brown <david.brown@hesbynett.no> - 2018-12-05 22:19 +0100
Re: Big integers "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid> - 2018-12-05 14:55 -0800
Re: Big integers jameskuyper@alumni.caltech.edu - 2018-12-05 15:19 -0800
Re: Big integers "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid> - 2018-12-05 16:13 -0800
Re: Big integers David Brown <david.brown@hesbynett.no> - 2018-12-06 09:35 +0100
Re: Big integers "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid> - 2018-12-07 14:26 -0800
Re: Big integers "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid> - 2018-12-07 19:56 -0800
Re: Big integers James Kuyper <jameskuyper@alumni.caltech.edu> - 2018-12-09 12:01 -0500
Re: Big integers "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid> - 2018-12-10 14:47 -0800
Re: Big integers scott@slp53.sl.home (Scott Lurndal) - 2018-12-11 00:50 +0000
Re: Big integers "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid> - 2018-12-10 17:37 -0800
Re: Big integers "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid> - 2018-12-14 21:18 -0800
Re: Big integers Thiago Adams <thiago.adams@gmail.com> - 2018-12-05 07:57 -0800
Re: Big integers Bart <bc@freeuk.com> - 2018-12-05 15:59 +0000
Re: Big integers Bart <bc@freeuk.com> - 2018-12-05 22:59 +0000
Re: Big integers jameskuyper@alumni.caltech.edu - 2018-12-05 15:31 -0800
Re: Big integers Robert Wessel <robertwessel2@yahoo.com> - 2018-12-05 20:03 -0600
Re: Big integers scott@slp53.sl.home (Scott Lurndal) - 2018-12-05 23:42 +0000
Re: Big integers James Kuyper <jameskuyper@alumni.caltech.edu> - 2018-12-05 20:15 -0500
Re: Big integers Ike Naar <ike@iceland.freeshell.org> - 2018-12-10 07:26 +0000
Re: Big integers Bart <bc@freeuk.com> - 2018-12-10 18:38 +0000
Re: Big integers scott@slp53.sl.home (Scott Lurndal) - 2018-12-10 19:10 +0000
Re: Big integers Bart <bc@freeuk.com> - 2018-12-10 21:23 +0000
Re: Big integers Ike Naar <ike@iceland.freeshell.org> - 2018-12-10 22:47 +0000
Re: Big integers David Brown <david.brown@hesbynett.no> - 2018-12-05 22:15 +0100
Re: Big integers Bart <bc@freeuk.com> - 2018-12-06 13:43 +0000
Re: Big integers Thiago Adams <thiago.adams@gmail.com> - 2018-12-06 07:50 -0800
Re: Big integers Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-12-05 15:19 +0000
Re: Big integers luser droog <luser.droog@gmail.com> - 2018-12-10 23:19 -0800
Re: Big integers David Brown <david.brown@hesbynett.no> - 2018-12-11 08:45 +0100
Re: Big integers Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-12-11 11:15 +0000
Re: Big integers Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-12-11 04:36 -0800
Re: Big integers David Brown <david.brown@hesbynett.no> - 2018-12-11 14:35 +0100
Re: Modules again (was: Big integers) Bart <bc@freeuk.com> - 2018-12-11 12:53 +0000
Re: Modules again David Brown <david.brown@hesbynett.no> - 2018-12-11 14:45 +0100
Re: Modules again Bart <bc@freeuk.com> - 2018-12-11 16:08 +0000
Re: Modules again David Brown <david.brown@hesbynett.no> - 2018-12-11 21:37 +0100
Re: Modules again Thiago Adams <thiago.adams@gmail.com> - 2018-12-11 08:59 -0800
Re: Modules again Bart <bc@freeuk.com> - 2018-12-11 17:49 +0000
Re: Modules again David Brown <david.brown@hesbynett.no> - 2018-12-11 21:44 +0100
Re: Modules again scott@slp53.sl.home (Scott Lurndal) - 2018-12-11 18:02 +0000
Re: Modules again Thiago Adams <thiago.adams@gmail.com> - 2018-12-11 10:10 -0800
Re: Modules again scott@slp53.sl.home (Scott Lurndal) - 2018-12-11 18:54 +0000
Re: Modules again Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2018-12-11 13:14 -0500
Re: Modules again scott@slp53.sl.home (Scott Lurndal) - 2018-12-11 18:54 +0000
Re: Modules again Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2018-12-11 14:42 -0500
Re: Modules again David Brown <david.brown@hesbynett.no> - 2018-12-11 21:54 +0100
Re: Modules again Keith Thompson <kst-u@mib.org> - 2018-12-11 14:53 -0800
Re: Modules again David Brown <david.brown@hesbynett.no> - 2018-12-12 08:24 +0100
Re: Modules again David Brown <david.brown@hesbynett.no> - 2018-12-11 21:51 +0100
Re: Modules again scott@slp53.sl.home (Scott Lurndal) - 2018-12-11 23:24 +0000
Re: Modules again Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2018-12-11 18:44 -0500
Re: Modules again Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2018-12-11 18:45 -0500
Re: Modules again Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-12-12 06:39 +0000
Re: Modules again James Kuyper <jameskuyper@alumni.caltech.edu> - 2018-12-12 07:59 -0500
Re: Modules again mark.bluemel@gmail.com - 2018-12-12 05:43 -0800
Re: Modules again scott@slp53.sl.home (Scott Lurndal) - 2018-12-12 14:20 +0000
Re: Modules again David Brown <david.brown@hesbynett.no> - 2018-12-12 17:10 +0100
Re: Modules again James Kuyper <jameskuyper@alumni.caltech.edu> - 2018-12-12 13:39 -0800
Re: Modules again scott@slp53.sl.home (Scott Lurndal) - 2018-12-12 14:19 +0000
Re: Modules again Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2018-12-12 10:28 -0500
Re: Big integers Ian Collins <ian-news@hotmail.com> - 2018-12-06 08:10 +1300
Re: Big integers Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-12-05 20:57 +0000
Re: Big integers Ian Collins <ian-news@hotmail.com> - 2018-12-06 10:16 +1300
Re: Big integers Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-12-05 23:15 +0000
Re: Big integers scott@slp53.sl.home (Scott Lurndal) - 2018-12-05 23:44 +0000
Re: Big integers Robert Wessel <robertwessel2@yahoo.com> - 2018-12-05 02:51 -0600
Re: Big integers antispam@math.uni.wroc.pl - 2018-12-07 15:26 +0000
Re: Big integers Bart <bc@freeuk.com> - 2018-12-07 16:27 +0000
Re: Big integers scott@slp53.sl.home (Scott Lurndal) - 2018-12-07 16:36 +0000
Re: Big integers Bart <bc@freeuk.com> - 2018-12-07 17:01 +0000
Re: Big integers Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-12-07 17:55 +0000
Re: Big integers antispam@math.uni.wroc.pl - 2018-12-07 19:26 +0000
Re: Big integers Bart <bc@freeuk.com> - 2018-12-07 21:39 +0000
Re: Big integers Ian Collins <ian-news@hotmail.com> - 2018-12-08 10:51 +1300
Re: Big integers Anton Shepelev <anton.txt@gmail.com> - 2018-12-08 00:43 +0300
Re: Big integers Bart <bc@freeuk.com> - 2018-12-08 01:08 +0000
Re: Big integers David Brown <david.brown@hesbynett.no> - 2018-12-08 15:13 +0100
Re: Big integers David Brown <david.brown@hesbynett.no> - 2018-12-08 15:15 +0100
Re: Big integers Bart <bc@freeuk.com> - 2018-12-08 14:48 +0000
Re: Big integers Thiago Adams <thiago.adams@gmail.com> - 2018-12-10 05:10 -0800
Re: Big integers Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-12-10 05:22 -0800
Re: Big integers David Brown <david.brown@hesbynett.no> - 2018-12-10 15:27 +0100
Re: Big integers scott@slp53.sl.home (Scott Lurndal) - 2018-12-10 15:59 +0000
Re: Big integers antispam@math.uni.wroc.pl - 2018-12-11 21:14 +0000
Re: Big integers Bart <bc@freeuk.com> - 2018-12-10 14:56 +0000
Re: Big integers Ike Naar <ike@iceland.freeshell.org> - 2018-12-10 17:46 +0000
Re: Big integers Bart <bc@freeuk.com> - 2018-12-10 18:24 +0000
Re: Big integers Thiago Adams <thiago.adams@gmail.com> - 2018-12-10 11:12 -0800
Re: Big integers Thiago Adams <thiago.adams@gmail.com> - 2018-12-10 11:23 -0800
Re: Big integers Bart <bc@freeuk.com> - 2018-12-10 21:44 +0000
Re: Big integers Thiago Adams <thiago.adams@gmail.com> - 2018-12-11 10:20 -0800
Re: Big integers "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid> - 2018-12-11 13:15 -0800
Re: Big integers Keith Thompson <kst-u@mib.org> - 2018-12-08 12:14 -0800
Re: Big integers David Brown <david.brown@hesbynett.no> - 2018-12-09 13:31 +0100
Re: Big integers "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid> - 2018-12-08 15:52 -0800
Re: Big integers Bart <bc@freeuk.com> - 2018-12-16 19:29 +0000
Re: Big integers "Tristan B. Kildaire" <deavmi@disroot.org> - 2018-12-25 12:59 +0000
Re: Big integers Bart <bc@freeuk.com> - 2018-12-25 15:54 +0000
Page 6 of 7 — ← Prev page 1 2 3 4 5 [6] 7 Next page →
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2018-12-12 14:19 +0000 |
| Subject | Re: Modules again |
| Message-ID | <HN8QD.963411$lM2.305538@fx39.iad> |
| In reply to | #138682 |
Lew Pitcher <lew.pitcher@digitalfreehold.ca> writes: >Scott Lurndal wrote: >[snip] > >> All true, and we found it so. At the beginning of the first OS (1989), > >Quote: > "The first operating system used for real work was GM-NAA I/O, produced in > 1956 by General Motors' Research division for its IBM 704." > >That's 33 years before your "first OS". And, GM-NAA IO wasn't the "first >operating system" either, by about 10 years. I'm sorry that you didn't read and understand the parts of the article you are responding to. Just for your information, the 'first os' above, applies to the portion of the article you snipped where I mentioned working on two operating systems written in C++.
[toc] | [prev] | [next] | [standalone]
| From | Lew Pitcher <lew.pitcher@digitalfreehold.ca> |
|---|---|
| Date | 2018-12-12 10:28 -0500 |
| Subject | Re: Modules again |
| Message-ID | <pur9ev$k5u$1@dont-email.me> |
| In reply to | #138688 |
Scott Lurndal wrote: > Lew Pitcher <lew.pitcher@digitalfreehold.ca> writes: >>Scott Lurndal wrote: >>[snip] >> >>> All true, and we found it so. At the beginning of the first OS (1989), >> >>Quote: >> "The first operating system used for real work was GM-NAA I/O, produced >> in >> 1956 by General Motors' Research division for its IBM 704." >> >>That's 33 years before your "first OS". And, GM-NAA IO wasn't the "first >>operating system" either, by about 10 years. > > I'm sorry that you didn't read and understand the parts of the article > you are responding to. Just for your information, the 'first os' > above, applies to the portion of the article you snipped where I mentioned > working on two operating systems written in C++. My apologies. I missed that part. -- Lew Pitcher "In Skills, We Trust"
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2018-12-06 08:10 +1300 |
| Message-ID | <g6qm4uF2giqU2@mid.individual.net> |
| In reply to | #138526 |
On 06/12/2018 00:58, Bart wrote: > On 05/12/2018 02:19, Ian Collins wrote: >> On 05/12/2018 01:17, Bart wrote: > >>> * Keeps use of typedefs to a minimum (used to declare some aliases for >>> int32_t etc, and to make the one struct used, into a type) >> >> Looks tidy, but I would keep those aliases out of the header - the _t >> names were partly picked to minimise the risk of name clashes. > > You mean, /I/ shouldn't use int32 so that someone else can? You shouldn't use int32 (in a header) because someone else may have already used it. >> Also >> they are slightly ironic coming from someone who decries C's plethora of >> types.... > > It should have a list of types such that people shouldn't want to make > up their own. It already does.... > I will look at getting rid of both stdint.h and the typedefs, although > the use of 'long long int' and 'unsigned int' will make things much less > tidy. Just stick with the standard types from stdint.h. -- Ian.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2018-12-05 20:57 +0000 |
| Message-ID | <87zhtj669r.fsf@bsb.me.uk> |
| In reply to | #138551 |
Ian Collins <ian-news@hotmail.com> writes: > On 06/12/2018 00:58, Bart wrote: >> On 05/12/2018 02:19, Ian Collins wrote: >>> On 05/12/2018 01:17, Bart wrote: >> >>>> * Keeps use of typedefs to a minimum (used to declare some aliases for >>>> int32_t etc, and to make the one struct used, into a type) >>> >>> Looks tidy, but I would keep those aliases out of the header - the _t >>> names were partly picked to minimise the risk of name clashes. >> >> You mean, /I/ shouldn't use int32 so that someone else can? > > You shouldn't use int32 (in a header) because someone else may have > already used it. I don't follow what you are saying here. What names /can/ I use in a header, if I am to avoid all those that someone else may have used? >>> Also >>> they are slightly ironic coming from someone who decries C's plethora of >>> types.... >> >> It should have a list of types such that people shouldn't want to make >> up their own. > > It already does.... It (the C language) includes various lists of reserved identifiers. Is that what you mean? If so, int32 is no on any of those lists. >> I will look at getting rid of both stdint.h and the typedefs, although >> the use of 'long long int' and 'unsigned int' will make things much less >> tidy. > > Just stick with the standard types from stdint.h. I agree with this advice, but I am puzzled by your other remarks. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2018-12-06 10:16 +1300 |
| Message-ID | <g6qtibF2giqU3@mid.individual.net> |
| In reply to | #138552 |
On 06/12/2018 09:57, Ben Bacarisse wrote: > Ian Collins <ian-news@hotmail.com> writes: > >> On 06/12/2018 00:58, Bart wrote: >>> On 05/12/2018 02:19, Ian Collins wrote: >>>> On 05/12/2018 01:17, Bart wrote: >>> >>>>> * Keeps use of typedefs to a minimum (used to declare some aliases for >>>>> int32_t etc, and to make the one struct used, into a type) >>>> >>>> Looks tidy, but I would keep those aliases out of the header - the _t >>>> names were partly picked to minimise the risk of name clashes. >>> >>> You mean, /I/ shouldn't use int32 so that someone else can? >> >> You shouldn't use int32 (in a header) because someone else may have >> already used it. > > I don't follow what you are saying here. What names /can/ I use in a > header, if I am to avoid all those that someone else may have used? I was expanding upon my original comment regarding the _t names; they were chosen in part to minimise the risk of clashing with existing user code. int32 and the like are way more likely to have been used in existing code than int32_t. >>>> Also >>>> they are slightly ironic coming from someone who decries C's plethora of >>>> types.... >>> >>> It should have a list of types such that people shouldn't want to make >>> up their own. >> >> It already does.... > > It (the C language) includes various lists of reserved identifiers. Is > that what you mean? If so, int32 is no on any of those lists. Yes, just use the types in stdint.h. >>> I will look at getting rid of both stdint.h and the typedefs, although >>> the use of 'long long int' and 'unsigned int' will make things much less >>> tidy. >> >> Just stick with the standard types from stdint.h. > > I agree with this advice, but I am puzzled by your other remarks. -- Ian
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2018-12-05 23:15 +0000 |
| Message-ID | <877egn5zw4.fsf@bsb.me.uk> |
| In reply to | #138554 |
Ian Collins <ian-news@hotmail.com> writes: > On 06/12/2018 09:57, Ben Bacarisse wrote: >> Ian Collins <ian-news@hotmail.com> writes: >> >>> On 06/12/2018 00:58, Bart wrote: >>>> On 05/12/2018 02:19, Ian Collins wrote: >>>>> On 05/12/2018 01:17, Bart wrote: >>>> >>>>>> * Keeps use of typedefs to a minimum (used to declare some aliases for >>>>>> int32_t etc, and to make the one struct used, into a type) >>>>> >>>>> Looks tidy, but I would keep those aliases out of the header - the _t >>>>> names were partly picked to minimise the risk of name clashes. >>>> >>>> You mean, /I/ shouldn't use int32 so that someone else can? >>> >>> You shouldn't use int32 (in a header) because someone else may have >>> already used it. >> >> I don't follow what you are saying here. What names /can/ I use in a >> header, if I am to avoid all those that someone else may have used? > > I was expanding upon my original comment regarding the _t names; they > were chosen in part to minimise the risk of clashing with existing > user code. int32 and the like are way more likely to have been used > in existing code than int32_t. Ah, you mean that int32 fails some rule of thumb indicating likely names that others will have used? If so, OK. It was the form of the "because" clause that threw me. I'd have said "because that's too likely to have already been used". That some name /may/ have been used pretty much rules out everything! -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2018-12-05 23:44 +0000 |
| Message-ID | <6pZND.200567$Ol2.130601@fx17.iad> |
| In reply to | #138564 |
Ben Bacarisse <ben.usenet@bsb.me.uk> writes: >Ian Collins <ian-news@hotmail.com> writes: > >> On 06/12/2018 09:57, Ben Bacarisse wrote: >>> Ian Collins <ian-news@hotmail.com> writes: >>> >>>> On 06/12/2018 00:58, Bart wrote: >>>>> On 05/12/2018 02:19, Ian Collins wrote: >>>>>> On 05/12/2018 01:17, Bart wrote: >>>>> >>>>>>> * Keeps use of typedefs to a minimum (used to declare some aliases for >>>>>>> int32_t etc, and to make the one struct used, into a type) >>>>>> >>>>>> Looks tidy, but I would keep those aliases out of the header - the _t >>>>>> names were partly picked to minimise the risk of name clashes. >>>>> >>>>> You mean, /I/ shouldn't use int32 so that someone else can? >>>> >>>> You shouldn't use int32 (in a header) because someone else may have >>>> already used it. >>> >>> I don't follow what you are saying here. What names /can/ I use in a >>> header, if I am to avoid all those that someone else may have used? >> >> I was expanding upon my original comment regarding the _t names; they >> were chosen in part to minimise the risk of clashing with existing >> user code. int32 and the like are way more likely to have been used >> in existing code than int32_t. > >Ah, you mean that int32 fails some rule of thumb indicating likely names >that others will have used? If so, OK. It was the form of the >"because" clause that threw me. I'd have said "because that's too >likely to have already been used". That some name /may/ have been used >pretty much rules out everything! > Although, those names are quite commonly used: typedef unsigned char uint8; typedef signed char int8; typedef unsigned short uint16; typedef signed short int16; typedef unsigned int uint32; typedef signed int int32; typedef unsigned long long uint64; typedef signed long long int64; typedef __uint128_t uint128; typedef __int128_t int128; This is not uncommon in several of the codebases I've worked with over last few decades, particulary prior to <stdint.h>
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2018-12-05 02:51 -0600 |
| Message-ID | <f84f0epc57ev5k49m8vp36fue0d7gqr368@4ax.com> |
| In reply to | #138493 |
On Tue, 4 Dec 2018 12:17:58 +0000, Bart <bc@freeuk.com> wrote:
>
>Bart [A modular build system for C]:
> > Some people don't want to do that because they strongly object to
> > having to run a 31,000-line bash script in a Linux emulation just to
> > compile a C library. It is just crazy.
>
>The complexities of building an arbitrary precision library like gmp
>were discussed recently.
>
>I've just put together a very simple such library, of the kind that I
>might have used myself if it was available:
>
> https://github.com/sal55/mx/blob/master/bigint.h
> https://github.com/sal55/mx/blob/master/bigint.c
>
>This library, although providing the most basic functions and using the
>simplest algorithms, nevertheless ticks quite a few of my boxes:
>
>* It's compactly presented as one module. (About 800 lines; just the
> configure script for gmp is 30,000 lines, and in all gmp has over
> 1900 files in total, when you have to build from source.)
>
>* Comes in a matching .h/.c pair, so would be compatible with the option
> on my compiler that auto-locates the bodies of included headers:
>
> C:\c>bcc -auto main
> 1 Compiling main.c to main.asm (Pass 1)
> * 2 Compiling bigint.c to bigint.asm (Pass 2)
> Assembling to main.exe
>
>* Keeps use of typedefs to a minimum (used to declare some aliases for
> int32_t etc, and to make the one struct used, into a type)
>
>* Does not use 'struct T' types, only 'T'
>
>* Does not use macros at all
>
>* Does not use conditional code
>
>* Makes strict use of 'extern' and 'static' for functions
>
>* Always uses {...} braces around statements
>
>* Will work with almost any C compiler. (Needs stdint.h and a 64-bit
> type. Linux systems may not like the "%lld"; in that case, since I
> can't fix C's type system, just define int64 in terms of long long
> int.)
>
>* Does not need makefiles or configuration steps
>
>* Simple test (using the demo main() in bigint.h) tested on a dozen
> compilers on 3 OSes.
>
>* Can be statically linked in to any program; just add the bigint.c
> module.
>
>* To build as a shared library, use for example:
>
> gcc -shared bigint.c -obigint.dll
>
>
>(This is version 0.0 derived from a version in my language
>(https://github.com/sal55/mx/blob/master/bigint.m), which was itself
>derived as a standalone library from the big integer routines in my
>interpreter.)
This would be much better in binary. IOW, base 2**32, rather than
base 10**9.
[toc] | [prev] | [next] | [standalone]
| From | antispam@math.uni.wroc.pl |
|---|---|
| Date | 2018-12-07 15:26 +0000 |
| Message-ID | <pue3fg$ihs$1@z-news.wcss.wroc.pl> |
| In reply to | #138493 |
Bart <bc@freeuk.com> wrote:
>
> Bart [A modular build system for C]:
> > Some people don't want to do that because they strongly object to
> > having to run a 31,000-line bash script in a Linux emulation just to
> > compile a C library. It is just crazy.
>
> The complexities of building an arbitrary precision library like gmp
> were discussed recently.
>
> I've just put together a very simple such library, of the kind that I
> might have used myself if it was available:
>
> https://github.com/sal55/mx/blob/master/bigint.h
> https://github.com/sal55/mx/blob/master/bigint.c
>
> This library, although providing the most basic functions and using the
> simplest algorithms, nevertheless ticks quite a few of my boxes:
>
Since you like benchmarks, can you say how much time your
library need to multiply 3^(10^7) and 3^(10^7) + 1 (that is
3 to power ten million time 3 to power ten million plus one).
One my machine using piles of bloatware on top on GMP this
computation needs 0.23 sec (less than one fourth to a second).
To isoleate time of multiplication I stored 3^(10^7) in variable a,
3^(10^7) + 1 in variable a1, and multipled a by a1 storing result
in variable b (but avoiding printing it).
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2018-12-07 16:27 +0000 |
| Message-ID | <8cxOD.372639$Nt6.46513@fx19.am4> |
| In reply to | #138591 |
On 07/12/2018 15:26, antispam@math.uni.wroc.pl wrote:
> Bart <bc@freeuk.com> wrote:
>>
>> Bart [A modular build system for C]:
>>> Some people don't want to do that because they strongly object to
>>> having to run a 31,000-line bash script in a Linux emulation just to
>>> compile a C library. It is just crazy.
>>
>> The complexities of building an arbitrary precision library like gmp
>> were discussed recently.
>>
>> I've just put together a very simple such library, of the kind that I
>> might have used myself if it was available:
>>
>> https://github.com/sal55/mx/blob/master/bigint.h
>> https://github.com/sal55/mx/blob/master/bigint.c
>>
>> This library, although providing the most basic functions and using the
>> simplest algorithms, nevertheless ticks quite a few of my boxes:
>>
>
> Since you like benchmarks, can you say how much time your
> library need to multiply 3^(10^7) and 3^(10^7) + 1 (that is
> 3 to power ten million time 3 to power ten million plus one).
> One my machine using piles of bloatware on top on GMP this
> computation needs 0.23 sec (less than one fourth to a second).
> To isoleate time of multiplication I stored 3^(10^7) in variable a,
> 3^(10^7) + 1 in variable a1, and multipled a by a1 storing result
> in variable b (but avoiding printing it).
It would take ages. Since 3**(10**7) is around 5 million digits, then a
simple nested multiple loop over both numbers would involve 25 trillion
digit multiplies. Mine is not quite as bad, but is still 250 billion
inner loops (I haven't tried it; just getting 3**10000000 would take
forever).
I would ask you to verify your timings however.
I tried this this program on four Python versions (including Py 3.7.1
and PyPy):
a = 3**10000000
b = 3**10000000+1
print("multiplying..")
c = a*b
print("done")
and they all took around 100 seconds. The multiply was about 50 seconds,
200 times slower than your claimed time.
I doubt that your machine is /that/ much faster than mine, nor that none
of my Python versions use that different numeric routines.
Anyway I'm not claiming that my library is fast, but that it is small
and simple. If it is not that fast, then that just means there is a much
lower limit to how 'big' the numbers can be that you can practically
work with.
(My library produced a result using 3**10**6 (not 3**10**7) in about 30
seconds for the multiply (uing gcc-O3). The result had 954,243 digits.
How many had your result?)
Somebody may want to multiply numbers 2-3 magnitudes bigger than yours,
then even gmp might take too long.
The benefit of my library to me is that it is 100% available, and
completely effortless to incorporate. (Building my interpreter from
source, of which the bigint library is about 2%, takes 0.25 seconds.)
--
bart
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2018-12-07 16:36 +0000 |
| Message-ID | <AkxOD.810884$Ac3.79322@fx45.iad> |
| In reply to | #138594 |
Bart <bc@freeuk.com> writes:
>On 07/12/2018 15:26, antispam@math.uni.wroc.pl wrote:
>> Bart <bc@freeuk.com> wrote:
>> Since you like benchmarks, can you say how much time your
>> library need to multiply 3^(10^7) and 3^(10^7) + 1 (that is
>> 3 to power ten million time 3 to power ten million plus one).
>> One my machine using piles of bloatware on top on GMP this
>> computation needs 0.23 sec (less than one fourth to a second).
>> To isoleate time of multiplication I stored 3^(10^7) in variable a,
>> 3^(10^7) + 1 in variable a1, and multipled a by a1 storing result
>> in variable b (but avoiding printing it).
>
>I would ask you to verify your timings however.
>
>I tried this this program on four Python versions (including Py 3.7.1
>and PyPy):
>
> a = 3**10000000
> b = 3**10000000+1
>
> print("multiplying..")
>
> c = a*b
>
> print("done")
>
>and they all took around 100 seconds. The multiply was about 50 seconds,
>200 times slower than your claimed time.
He didn't say anything about python. He said GMP.
$ ldd /usr/bin/python
linux-vdso.so.1 => (0x00007ffdc55ee000)
libpython2.6.so.1.0 => /usr/lib64/libpython2.6.so.1.0 (0x0000003d8a000000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x0000003d76a00000)
libdl.so.2 => /lib64/libdl.so.2 (0x0000003d76200000)
libutil.so.1 => /lib64/libutil.so.1 (0x0000003d86800000)
libm.so.6 => /lib64/libm.so.6 (0x0000003d77200000)
libc.so.6 => /lib64/libc.so.6 (0x0000003d76600000)
/lib64/ld-linux-x86-64.so.2 (0x0000003d75e00000)
Python doesn't use libgmp.
>
>The benefit of my library to me is that it is 100% available, and
>completely effortless to incorporate. (Building my interpreter from
>source, of which the bigint library is about 2%, takes 0.25 seconds.)
GMP is 100% available, effortless to incorporate for everyone _except_
you apparently. And really, build time is hardly relevent, since
libgmp is built once by someone else and included in pretty much
every distribution of interest.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2018-12-07 17:01 +0000 |
| Message-ID | <nHxOD.185511$eX5.176656@fx06.am4> |
| In reply to | #138595 |
On 07/12/2018 16:36, Scott Lurndal wrote: > Bart <bc@freeuk.com> writes: >> The benefit of my library to me is that it is 100% available, and >> completely effortless to incorporate. (Building my interpreter from >> source, of which the bigint library is about 2%, takes 0.25 seconds.) > > GMP is 100% available, effortless to incorporate for everyone _except_ > you apparently. And really, build time is hardly relevent, since > libgmp is built once by someone else and included in pretty much > every distribution of interest. So why doesn't CPython use it? (If I used gmp (within my interpreter), it would be called for from the executable, which means that gmp.dll MUST be installed on the computer, and be within a suitable search path, or the program won't run, whether it needs to make any gmp calls or not: "The program can't start because gmp.dll is missing from your computer." Big integers are used too rarely to risk screwing up 99% of applications because gmp.dll doesn't exist. My interpreter and the programs it runs are generally portable. They wouldn't be so portable with a gmp.dll dependency (or whatever the equivalent is on Linux).)
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2018-12-07 17:55 +0000 |
| Message-ID | <87in051asv.fsf@bsb.me.uk> |
| In reply to | #138594 |
Bart <bc@freeuk.com> writes: > On 07/12/2018 15:26, antispam@math.uni.wroc.pl wrote: <snip> >> Since you like benchmarks, can you say how much time your >> library need to multiply 3^(10^7) and 3^(10^7) + 1 (that is >> 3 to power ten million time 3 to power ten million plus one). >> One my machine using piles of bloatware on top on GMP this >> computation needs 0.23 sec (less than one fourth to a second). >> To isoleate time of multiplication I stored 3^(10^7) in variable a, >> 3^(10^7) + 1 in variable a1, and multipled a by a1 storing result >> in variable b (but avoiding printing it). > > It would take ages. Since 3**(10**7) is around 5 million digits, then > a simple nested multiple loop over both numbers would involve 25 > trillion digit multiplies. Mine is not quite as bad, but is still 250 > billion inner loops (I haven't tried it; just getting 3**10000000 > would take forever). > > I would ask you to verify your timings however. It looks like a plausible time. A quick check with ghci (a Haskell interpreter which does use GMP) gives: Prelude> even (3^10^7 * (3^10^7 + 1)) True (0.38 secs, 17,513,600 bytes) I ask whether the result is even to force something to be calculated without having to convert the whole number to decimal for printing. Even converting to decimal only takes 3 seconds: Prelude> length $ show $ 3^10^7 * (3^10^7 + 1) 9542426 (3.04 secs, 622,005,224 bytes) > Anyway I'm not claiming that my library is fast, but that it is small > and simple. If it is not that fast, then that just means there is a > much lower limit to how 'big' the numbers can be that you can > practically work with. There is certainly a use for simple but not fast, though I'd want a few more features myself. Linux's bc calculator uses it's own simple implementation because it is defined to use fixed precision floating point. bc would take ages just to calculate the exponential. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | antispam@math.uni.wroc.pl |
|---|---|
| Date | 2018-12-07 19:26 +0000 |
| Message-ID | <puehgl$qjh$1@z-news.wcss.wroc.pl> |
| In reply to | #138594 |
Bart <bc@freeuk.com> wrote:
> On 07/12/2018 15:26, antispam@math.uni.wroc.pl wrote:
> > Bart <bc@freeuk.com> wrote:
> >>
> >> Bart [A modular build system for C]:
> >>> Some people don't want to do that because they strongly object to
> >>> having to run a 31,000-line bash script in a Linux emulation just to
> >>> compile a C library. It is just crazy.
> >>
> >> The complexities of building an arbitrary precision library like gmp
> >> were discussed recently.
> >>
> >> I've just put together a very simple such library, of the kind that I
> >> might have used myself if it was available:
> >>
> >> https://github.com/sal55/mx/blob/master/bigint.h
> >> https://github.com/sal55/mx/blob/master/bigint.c
> >>
> >> This library, although providing the most basic functions and using the
> >> simplest algorithms, nevertheless ticks quite a few of my boxes:
> >>
> >
> > Since you like benchmarks, can you say how much time your
> > library need to multiply 3^(10^7) and 3^(10^7) + 1 (that is
> > 3 to power ten million time 3 to power ten million plus one).
> > One my machine using piles of bloatware on top on GMP this
> > computation needs 0.23 sec (less than one fourth to a second).
> > To isoleate time of multiplication I stored 3^(10^7) in variable a,
> > 3^(10^7) + 1 in variable a1, and multipled a by a1 storing result
> > in variable b (but avoiding printing it).
>
> It would take ages. Since 3**(10**7) is around 5 million digits, then a
> simple nested multiple loop over both numbers would involve 25 trillion
> digit multiplies. Mine is not quite as bad, but is still 250 billion
> inner loops (I haven't tried it; just getting 3**10000000 would take
> forever).
>
> I would ask you to verify your timings however.
FYI, bignum computation are significant part of what I compute.
I care about speed of bignum computations and I know what to expect.
> I tried this this program on four Python versions (including Py 3.7.1
> and PyPy):
>
> a = 3**10000000
> b = 3**10000000+1
>
> print("multiplying..")
>
> c = a*b
>
> print("done")
>
> and they all took around 100 seconds. The multiply was about 50 seconds,
> 200 times slower than your claimed time.
>
> I doubt that your machine is /that/ much faster than mine, nor that none
> of my Python versions use that different numeric routines.
There are _huge_ speed differences between various bignum libraries.
My machine (1.7GHz i5) is probably slower than yours.
> Anyway I'm not claiming that my library is fast, but that it is small
> and simple. If it is not that fast, then that just means there is a much
> lower limit to how 'big' the numbers can be that you can practically
> work with.
Yes. And I need _big_ numbers.
> (My library produced a result using 3**10**6 (not 3**10**7) in about 30
> seconds for the multiply (uing gcc-O3). The result had 954,243 digits.
> How many had your result?)
31699251 bits, that is 9542426 digits. The first six are 124277...
> Somebody may want to multiply numbers 2-3 magnitudes bigger than yours,
> then even gmp might take too long.
Actually, memory is more problematic: for interesting computations
one needs several numbers and with 4Mb each you can have reasonably
many numbers even on small machine like the one I am using now.
3 magnitudes bigger means 4Gb per number and that would definitely
require much larger machine. FYI, going to 3^(10^8) multiplication
needs 3.12 sec so time scales reasonably well. Scaling is supposed
to be quasi-linear with GMP method, but as numbers grow smaller part
fits in cache and that is probably responsible for extra time.
The size was choosen to get easily measurable run time and be small
enough to still represent realistic (in _my_ practice) use case.
3^(10^6) is hard to measure alone, repeating multiplication 100 times
gives 1.71 sec, that is 17.1 miliseconds per multiplication.
> The benefit of my library to me is that it is 100% available, and
> completely effortless to incorporate. (Building my interpreter from
> source, of which the bigint library is about 2%, takes 0.25 seconds.)
Well, our needs are different. I have computations that can take
days or weeks using GMP. Slower library could change this to
months or years. Compared to this difference in compile time
is negilgible.
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2018-12-07 21:39 +0000 |
| Message-ID | <vMBOD.927889$8Q.288956@fx36.am4> |
| In reply to | #138602 |
On 07/12/2018 19:26, antispam@math.uni.wroc.pl wrote: > Bart <bc@freeuk.com> wrote: > There are _huge_ speed differences between various bignum libraries. Apparently. >> (My library produced a result using 3**10**6 (not 3**10**7) in about 30 >> seconds for the multiply (uing gcc-O3). The result had 954,243 digits. >> How many had your result?) > > 31699251 bits, that is 9542426 digits. The first six are 124277... Well, my library seems to be on the right lines at least. My code uses decimal representation, which has some penalty (involving divide and mod ops in the inner loop of the already naive multiply). But changing it to binary, while keeping the same algorithm, will probably have little impact. Since decimal has some advantages, I will keep it like that for the time being, and perhaps get back to the algorithms at some later point. At the minute I've started a floating point version, also decimal. >> Somebody may want to multiply numbers 2-3 magnitudes bigger than yours, >> then even gmp might take too long. > > Actually, memory is more problematic: for interesting computations > one needs several numbers and with 4Mb each you can have reasonably > many numbers even on small machine like the one I am using now. > 3 magnitudes bigger means 4Gb per number No, I meant each number might be 100 or 1000 times bigger (so any 10 extra bits). But I now see this won't much much difference, not for multiply. So I really mean calculations big enough you have to wait a while for the results. But apparently you work with those too. > Well, our needs are different. I have computations that can take > days or weeks using GMP. Slower library could change this to > months or years. Compared to this difference in compile time > is negilgible. The biggest factorial on my Casio is 69!, and it only gives a result to 10 figures (which takes half a second) Even my toy library can instantly give the exact answer. As it can for 10000! So for this undemanding stuff it's adequate.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2018-12-08 10:51 +1300 |
| Message-ID | <g708b9Fc5e9U2@mid.individual.net> |
| In reply to | #138606 |
On 08/12/2018 10:39, Bart wrote: > On 07/12/2018 19:26, antispam@math.uni.wroc.pl wrote: >> Bart <bc@freeuk.com> wrote: > > >> There are _huge_ speed differences between various bignum libraries. > > Apparently. Which is to be expected... What you have written is something that does what you need it to get done. For your use case of occasional bignums, further optimisation is probably as waste of effort. Now you have a stable interface and tests, you can look at optimisations if and when you need them. -- Ian.
[toc] | [prev] | [next] | [standalone]
| From | Anton Shepelev <anton.txt@gmail.com> |
|---|---|
| Date | 2018-12-08 00:43 +0300 |
| Message-ID | <20181208004345.ead1fdc61650a34f07b48220@gmail.com> |
| In reply to | #138493 |
Bart: > The complexities of building an arbitrary precision > library like gmp were discussed recently. > > I've just put together a very simple such library, of the > kind that I might have used myself if it was available: > > https://github.com/sal55/mx/blob/master/bigint.h > https://github.com/sal55/mx/blob/master/bigint.c Great job of making it lean and clean! You decision to abort on errors imposes is a severe limitaiton on the usability of the library, whereas status returns would make it clumsier. Have you considered errno.h? -- () ascii ribbon campaign -- against html e-mail /\ http://preview.tinyurl.com/qcy6mjc [archived]
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2018-12-08 01:08 +0000 |
| Message-ID | <qQEOD.860813$wF4.745234@fx27.am4> |
| In reply to | #138607 |
On 07/12/2018 21:43, Anton Shepelev wrote:
> Bart:
>
>> The complexities of building an arbitrary precision
>> library like gmp were discussed recently.
>>
>> I've just put together a very simple such library, of the
>> kind that I might have used myself if it was available:
>>
>> https://github.com/sal55/mx/blob/master/bigint.h
>> https://github.com/sal55/mx/blob/master/bigint.c
>
> Great job of making it lean and clean!
>
> You decision to abort on errors imposes is a severe
> limitaiton on the usability of the library, whereas status
> returns would make it clumsier. Have you considered
> errno.h?
It's difficult to know what suits everyone. Arithmetic using such
functions, especially needing to use intermediate values and having to
free them after use, is already very fiddly. (A bolted-on garbage
collector might help.)
But it's also useful to have a simple enough library that you can work
with easily and adapt to needs.
I've had a quick look at how gmp does this, and the first thing I found
was a simple example of using gmp
(https://www.cs.colorado.edu/~srirams/courses/csci2824-spr14/gmpTutorial.html,
about half-way down).
I thought it would be interesting to get my library to emulate the small
set of gmp functions used, so that they can be used in the same way.
This is the main() function pretty much as downloaded:
------------------------------------------------
int main(void){
char inputStr[1024];
/*
mpz_t is the type defined for GMP integers.
It is a pointer to the internals of the GMP integer data structure
*/
mpz_t n;
int flag;
printf ("Enter your number: ");
scanf("%1023s" , inputStr); /* NOTE: <snip> */
/* 1. Initialize the number */
mpz_init(&n);
mpz_set_ui(n,0);
/* 2. Parse the input string as a base 10 number */
flag = mpz_set_str(n,inputStr, 10);
assert (flag == 0); /* If flag is not 0 then the operation failed */
/* Print n */
printf ("n = ");
mpz_out_str(stdout,10,n);
printf ("\n");
/* 3. Add one to the number */
mpz_add_ui(n,n,1); /* n = n + 1 */
/* 4. Print the result */
printf (" n +1 = ");
mpz_out_str(stdout,10,n);
printf ("\n");
/* 5. Square n+1 */
mpz_mul(n,n,n); /* n = n * n */
printf (" (n +1)^2 = ");
mpz_out_str(stdout,10,n);
printf ("\n");
/* 6. Clean up the mpz_t handles or else we will leak memory */
mpz_clear(n);
}
------------------------------------------------
It seems to work - without gmp! (I don't know what the actual type of
mpz_t st, or how mpz_init manages to initialise the variable in the
caller; I had to change this to use a reference parameter.)
Anyway, one example of how it does error handling for input strings is
shown above, and that was copied. (I had to get bigint.c to return a
error value for errors in strings passed to bn_make(). The other two
errors: divide by zero and out of memory, work as before.)
The gmp approach also simplifies the memory management in the user code.
The program above requires this initial part, with these partial
emulations of gmp functions, to work:
------------------------------------------------
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <assert.h>
#include "bigint.h"
typedef Bigint* mpz_t;
mpz_t make_mpz(Bigint a){
mpz_t p;
p=malloc(sizeof(Bigint));
*p=a;
return p;
}
void mpz_init(mpz_t *a) {
*a = make_mpz(bn_makeint(0));
}
void mpz_set_ui(mpz_t a, long long int n) {
bn_free(*a);
*a=bn_makeint(n);
}
int mpz_set_str(mpz_t a, char* s, int base) {
*a = bn_make(s);
return *a==NULL;
}
void mpz_out_str(FILE* f, int base, mpz_t a) {
bn_print(*a);
}
void mpz_add_ui(mpz_t c, mpz_t a, long long int n) {
Bigint b,dest;
b=bn_makeint(n);
dest=bn_add(*a,b); // (c and a may be the same)
bn_free(*c);
*c=dest;
bn_free(b);
}
void mpz_mul(mpz_t c, mpz_t a, mpz_t b) {
Bigint dest;
dest=bn_mul(*a,*b);
bn_free(*c);
*c=dest;
}
void mpz_clear(mpz_t a) {
bn_free(*a);
free(a);
}
------------------------------------------------
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-12-08 15:13 +0100 |
| Message-ID | <pugjht$pja$1@dont-email.me> |
| In reply to | #138607 |
On 07/12/2018 22:43, Anton Shepelev wrote: > Bart: > >> The complexities of building an arbitrary precision >> library like gmp were discussed recently. >> >> I've just put together a very simple such library, of the >> kind that I might have used myself if it was available: >> >> https://github.com/sal55/mx/blob/master/bigint.h >> https://github.com/sal55/mx/blob/master/bigint.c > > Great job of making it lean and clean! > > You decision to abort on errors imposes is a severe > limitaiton on the usability of the library, whereas status > returns would make it clumsier. Have you considered > errno.h? > IMHO, the only thing you should consider about errno is that it was a terrible idea. Using a global variable as a return vale /really/ limits things. Suddenly you have all sorts of complications about side-effects of your otherwise "pure" or "const" functions, trouble when multi-threading, no chance of constexpr functions (if Bart ever wants to take that route), etc. Bart's latest thoughts of using an interface style "bm_add(x, a, b);" rather than "x = bm_add(a, b);" is a good one, and it opens for the idea of a status return if that suits his needs.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-12-08 15:15 +0100 |
| Message-ID | <pugjm7$pja$2@dont-email.me> |
| In reply to | #138617 |
On 08/12/2018 15:13, David Brown wrote: > On 07/12/2018 22:43, Anton Shepelev wrote: >> Bart: >> >>> The complexities of building an arbitrary precision >>> library like gmp were discussed recently. >>> >>> I've just put together a very simple such library, of the >>> kind that I might have used myself if it was available: >>> >>> https://github.com/sal55/mx/blob/master/bigint.h >>> https://github.com/sal55/mx/blob/master/bigint.c >> >> Great job of making it lean and clean! >> >> You decision to abort on errors imposes is a severe >> limitaiton on the usability of the library, whereas status >> returns would make it clumsier. Have you considered >> errno.h? >> > > IMHO, the only thing you should consider about errno is that it was a > terrible idea. Using a global variable as a return vale /really/ limits > things. Suddenly you have all sorts of complications about side-effects > of your otherwise "pure" or "const" functions, trouble when > multi-threading, no chance of constexpr functions (if Bart ever wants to > take that route), etc. > > Bart's latest thoughts of using an interface style "bm_add(x, a, b);" > rather than "x = bm_add(a, b);" is a good one, and it opens for the idea > of a status return if that suits his needs. > Another possibility (which occurred to me after pressing "send") is that the BigInt struct currently has a 32-bit field for the "minus" flag. This could contain other flags, such as a "NaN" or "error" flag, with as many other details (infinities, overflow, underflow, etc.) as desired.
[toc] | [prev] | [next] | [standalone]
Page 6 of 7 — ← Prev page 1 2 3 4 5 [6] 7 Next page →
Back to top | Article view | comp.lang.c
csiph-web