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 1 of 7 [1] 2 3 4 5 6 7 Next page →
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2018-12-04 12:17 +0000 |
| Subject | Big integers |
| Message-ID | <YfuND.286973$lKb.275890@fx15.am4> |
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.)
--
bart
[toc] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2018-12-04 05:58 -0800 |
| Message-ID | <3c1d6c52-bb5a-430f-95ac-d2097459aadb@googlegroups.com> |
| In reply to | #138493 |
W dniu wtorek, 4 grudnia 2018 13:18:09 UTC+1 użytkownik Bart napisał:
> 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.)
>
stap talking aboput 30k lines of build scripr, people really are fed up of your disgusting paranoya.. i feel sick seein
you troll again repeating this depressing stupidity again
otherwiste this bignum small library is just a good topic for a kind of clc contest...im feeling very 'lazy' (fucked up) recently but if such context would take bigger participation maybe i could go into it too
[toc] | [prev] | [next] | [standalone]
| From | Chad <cdalten@gmail.com> |
|---|---|
| Date | 2018-12-04 08:22 -0800 |
| Message-ID | <d86f674c-459a-4a52-81f0-6c2f4e97e98e@googlegroups.com> |
| In reply to | #138494 |
I *think* there is some ambiguity here. This is because a guy who lives by me wrotr about this subject a while back on his blog.. https://www.jwz.org/blog/2008/03/most-positive-bignum/
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2018-12-04 17:04 +0000 |
| Message-ID | <KsyND.426046$kh6.143905@fx32.am4> |
| In reply to | #138495 |
On 04/12/2018 16:22, Chad wrote: > I *think* there is some ambiguity here. This is because a guy who lives by me wrotr about this subject a while back on his blog.. > > > https://www.jwz.org/blog/2008/03/most-positive-bignum/ > That article suggests there is a maximum size of big integer due to some length field. In my program, the field is uint32, which gives the number of 32-bit words, each of which represents 9 decimal digits. So the maximum value in a single big integer is about 38,000,000,000 decimal digits long (ie. 10^38000000000), occupying 16GB of RAM. However, in this C version, that uint32 type interacts with an int or int32 type, which may half that range (in the original code from which this was ported, 'int' was in64), so that really should be fixed. Not a huge priority though as even 19-billion digit numbers (8GB each) are likely to be impractical for other reasons. And on a 32-bit system, it will have 2GB and 4GB limits anyway. -- bart
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2018-12-04 17:19 +0000 |
| Message-ID | <rGyND.439729$oH2.108082@fx10.iad> |
| In reply to | #138498 |
Bart <bc@freeuk.com> writes: >On 04/12/2018 16:22, Chad wrote: >> I *think* there is some ambiguity here. This is because a guy who lives by me wrotr about this subject a while back on his blog.. >> >> >> https://www.jwz.org/blog/2008/03/most-positive-bignum/ >> > >That article suggests there is a maximum size of big integer due to some >length field. > >In my program, the field is uint32, which gives the number of 32-bit >words, each of which represents 9 decimal digits. > >So the maximum value in a single big integer is about 38,000,000,000 >decimal digits long (ie. 10^38000000000), occupying 16GB of RAM. > >However, in this C version, that uint32 type interacts with an int or >int32 type, which may half that range (in the original code from which >this was ported, 'int' was in64), so that really should be fixed. > >Not a huge priority though as even 19-billion digit numbers (8GB each) >are likely to be impractical for other reasons. And on a 32-bit system, >it will have 2GB and 4GB limits anyway. The performance considerations of your library makes it unsuitable for production use, when compared with the excellent and performant gmp library. You perhaps may wish to investigate using base-256 instead.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2018-12-04 08:38 -0800 |
| Message-ID | <01c809d8-12f2-4755-8207-a000f1d6c9c1@googlegroups.com> |
| In reply to | #138493 |
On Tuesday, December 4, 2018 at 12:18:09 PM UTC, Bart wrote: > > * 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.) > If you just want huge integers and don't care overmuch about performance your solution is certainly the easier one. But GMP is carefully written to extract the maximum from the machine. It also does real types, of course.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2018-12-04 17:35 +0000 |
| Message-ID | <%VyND.512769$p%6.229167@fx26.am4> |
| In reply to | #138496 |
On 04/12/2018 16:38, Malcolm McLean wrote: > On Tuesday, December 4, 2018 at 12:18:09 PM UTC, Bart wrote: >> >> * 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.) >> > If you just want huge integers and don't care overmuch about performance > your solution is certainly the easier one. But GMP is carefully written to > extract the maximum from the machine. It also does real types, of course. > An extended precision floating point library would also be intriguing to write. But it can't be arbitrary precision. (How many digits to represent 1/3 exactly in either binary or decimal?) (Rational numbers are something else provided by GMP. But not quite as interesting to me. Such a library could be built on top of the big integer one. Possibly also a floating point version, but I haven't looked into it.)
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2018-12-04 18:13 +0000 |
| Message-ID | <87bm61p3cx.fsf@bsb.me.uk> |
| In reply to | #138502 |
Bart <bc@freeuk.com> writes: > On 04/12/2018 16:38, Malcolm McLean wrote: >> On Tuesday, December 4, 2018 at 12:18:09 PM UTC, Bart wrote: >>> >>> * 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.) >>> >> If you just want huge integers and don't care overmuch about performance >> your solution is certainly the easier one. But GMP is carefully written to >> extract the maximum from the machine. It also does real types, of >> course. I think the floating library is now separate. > An extended precision floating point library would also be intriguing > to write. But it can't be arbitrary precision. (How many digits to > represent 1/3 exactly in either binary or decimal?) It can be arbitrary in the sense that the requested precision is only limited by memory: the user can ask for 100 or 1,000,000 digits. > (Rational numbers are something else provided by GMP. But not quite as > interesting to me. Such a library could be built on top of the big > integer one. Possibly also a floating point version, but I haven't > looked into it.) Or (and I punt this only because it's occurred to me) you could use a linked list of digits and permit loops. 1/3 would then need only one! (This format, and the usual two big ints version of rationals, will both grow in size during typical calculations. If you use them as a substitute for floating point, they rapidly become unmanageable.) -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2018-12-04 10:50 -0800 |
| Message-ID | <3d3c0a29-c1a8-46d9-8bde-5990171e8bd8@googlegroups.com> |
| In reply to | #138503 |
On Tuesday, December 4, 2018 at 1:13:26 PM UTC-5, Ben Bacarisse wrote: > Bart <bc@freeuk.com> writes: > > > On 04/12/2018 16:38, Malcolm McLean wrote: > >> ... But GMP is carefully written to > >> extract the maximum from the machine. It also does real types, of > >> course. > > I think the floating library is now separate. I'm not sure if GMP directly supports floats as part of its own API, but they have created MPFR and MPC libraries for real and complex real. I used MPFR extensively in the 2009/2011 time- frame. -- Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Rosario19 <Ros@invalid.invalid> |
|---|---|
| Date | 2018-12-06 17:56 +0100 |
| Message-ID | <urki0elb00p48ujkhuav8mtcesvjoglvf4@4ax.com> |
| In reply to | #138503 |
On Tue, 04 Dec 2018 18:13:18 +0000, Ben Bacarisse wrote: >It can be arbitrary in the sense that the requested precision is only >limited by memory: the user can ask for 100 or 1,000,000 digits. this above seems to me speak about one float type that has digits or precision assigned... APL with float type and floor and ceil functions for me is ok; or in other words float as int or unsinged all in 1 only type float
[toc] | [prev] | [next] | [standalone]
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2018-12-04 10:22 -0800 |
| Message-ID | <e6f9b514-a695-401d-8b70-53d61e8f52ac@googlegroups.com> |
| In reply to | #138502 |
On Tuesday, December 4, 2018 at 3:36:04 PM UTC-2, Bart wrote: > On 04/12/2018 16:38, Malcolm McLean wrote: > > On Tuesday, December 4, 2018 at 12:18:09 PM UTC, Bart wrote: > >> > >> * 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.) > >> > > If you just want huge integers and don't care overmuch about performance > > your solution is certainly the easier one. But GMP is carefully written to > > extract the maximum from the machine. It also does real types, of course. > > > > An extended precision floating point library would also be intriguing to > write. But it can't be arbitrary precision. (How many digits to > represent 1/3 exactly in either binary or decimal?) Computers can do exactly math if applicable in the context. For instance, we can create fraction types that uses big ints, imaginary , irrational etc, at some point we are at symbolic math. Every float point number is a fraction, but not all fractions can be represented exactly with float point numbers. And of course, irrational number like pi or e cannot be represented by fraction or floating point numbers.
[toc] | [prev] | [next] | [standalone]
| From | Eli the Bearded <*@eli.users.panix.com> |
|---|---|
| Date | 2018-12-04 18:58 +0000 |
| Message-ID | <eli$1812041358@qaz.wtf> |
| In reply to | #138504 |
In comp.lang.c, Thiago Adams <thiago.adams@gmail.com> wrote: > Every float point number is a fraction, How do you reconcile that statement with the definition of an "irrational number"? Elijah ------ just curious
[toc] | [prev] | [next] | [standalone]
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2018-12-04 11:32 -0800 |
| Message-ID | <bbc8abd6-b86a-4bde-b9b2-faddf0b2868e@googlegroups.com> |
| In reply to | #138506 |
On Tuesday, December 4, 2018 at 4:58:57 PM UTC-2, Eli the Bearded wrote:
> In comp.lang.c, Thiago Adams wrote:
> > Every float point number is a fraction,
>
> How do you reconcile that statement with the definition of an
> "irrational number"?
>
I didn't understand your question.
But I will try to answer.
If you look at M_PI you will see.
#define M_PI 3.14159265358979323846 // pi
This is not representing a irrational number
but the fraction:
314159265358979323846 / 100000000000000000000
or
157079632679489661923/50000000000000000000
This fraction is what you write. The compiler
will generate a floating point number near
to this fraction.
If I print the bits for this double using this
http://thradams.com/floatmath.htm
I got:
bits =
0001100010110100001000100010101011011111100001001001000000000010
binary number =
1.1001001000011111101101010100010001000010110100011000 * 2 ^ 1
double = 3.14159
mantissa = 2570638124657944
exponent = 1
signal = 0
The exactly represented number is according with the bits:
representation :
2 ^ 1 + 2 ^ 0 + 2 ^ -3 + 2 ^ -6 + 2 ^ -11 + 2 ^ -12 +
2 ^ -13 + 2 ^ -14 + 2 ^ -15 + 2 ^ -16 + 2 ^ -18 +
2 ^ -19 + 2 ^ -21 + 2 ^ -23 + 2 ^ -25 + 2 ^ -29 +
2 ^ -33 + 2 ^ -38 + 2 ^ -40 + 2 ^ -41 + 2 ^ -43 +
2 ^ -47 + 2 ^ -48
Using this site I can compute:
https://www.wolframalpha.com/
That this number is (exactly):
884279719003555/281474976710656
This is the number (fraction) represented by the
floating point M_PI.
The original number we wrote was.
314159265358979323846 / 100000000000000000000
the distance between then is:
3287315261901/26843545600000000000000000000
or
1.22462036531455814838409423828125 × 10^-16
[toc] | [prev] | [next] | [standalone]
| From | Eli the Bearded <*@eli.users.panix.com> |
|---|---|
| Date | 2018-12-04 22:45 +0000 |
| Message-ID | <eli$1812041745@qaz.wtf> |
| In reply to | #138507 |
In comp.lang.c, Thiago Adams <thiago.adams@gmail.com> wrote: > On Tuesday, December 4, 2018 at 4:58:57 PM UTC-2, Eli the Bearded wrote: >> In comp.lang.c, Thiago Adams wrote: >>> Every float point number is a fraction, >> How do you reconcile that statement with the definition of an >> "irrational number"? > I didn't understand your question. > > But I will try to answer. > > If you look at M_PI you will see. > > #define M_PI 3.14159265358979323846 // pi > > This is not representing a irrational number > but the fraction: That's explains it. You mean "After first replacing all irrational numbers with rational approximations, every float point number is a fraction". Elijah ------ which doesn't help anyone if you want more precision later
[toc] | [prev] | [next] | [standalone]
| From | jameskuyper@alumni.caltech.edu |
|---|---|
| Date | 2018-12-04 14:57 -0800 |
| Message-ID | <97ed8f5e-1976-4df6-b2af-b458db1de7c9@googlegroups.com> |
| In reply to | #138512 |
On Tuesday, December 4, 2018 at 5:45:26 PM UTC-5, Eli the Bearded wrote: > In comp.lang.c, Thiago Adams <thiago.adams@gmail.com> wrote: > > On Tuesday, December 4, 2018 at 4:58:57 PM UTC-2, Eli the Bearded wrote: > >> In comp.lang.c, Thiago Adams wrote: > >>> Every float point number is a fraction, > >> How do you reconcile that statement with the definition of an > >> "irrational number"? > > I didn't understand your question. > > > > But I will try to answer. > > > > If you look at M_PI you will see. > > > > #define M_PI 3.14159265358979323846 // pi > > > > This is not representing a irrational number > > but the fraction: > > That's explains it. You mean "After first replacing all irrational > numbers with rational approximations, every float point number is a > fraction". Floating point numbers can't hold irrational numbers. They can only hold rational approximations. Therefore, no such replacement is necessary.
[toc] | [prev] | [next] | [standalone]
| From | jameskuyper@alumni.caltech.edu |
|---|---|
| Date | 2018-12-04 12:14 -0800 |
| Message-ID | <cc733c3d-46a2-4688-a3df-07599ed4ee16@googlegroups.com> |
| In reply to | #138506 |
On Tuesday, December 4, 2018 at 1:58:57 PM UTC-5, Eli the Bearded wrote: > In comp.lang.c, Thiago Adams <thiago.adams@gmail.com> wrote: > > Every float point number is a fraction, > > How do you reconcile that statement with the definition of an > "irrational number"? What precisely is the problem that you percieve? Every finite number that is representable in any given floating point format compatible with the C standard's requirements is a rational number with a denominator which is an integer power of FLT_RADIX. There's no overlap between irrational numbers and numbers exactly representable in floating point format.
[toc] | [prev] | [next] | [standalone]
| From | chris.m.thomasson.1@gmail.com |
|---|---|
| Date | 2018-12-04 16:58 -0800 |
| Message-ID | <ae11db56-f850-4613-8088-1d85862fb76f@googlegroups.com> |
| In reply to | #138506 |
On Tuesday, December 4, 2018 at 10:58:57 AM UTC-8, Eli the Bearded wrote: > In comp.lang.c, Thiago Adams <thiago.adams@gmail.com> wrote: > > Every float point number is a fraction, > > How do you reconcile that statement with the definition of an > "irrational number"? > > Elijah > ------ > just curious Fwiw, an arbitrary precision real can be the convergent of a continued fraction up to a user provided precision. For instance: ____________________ PI = 3.1415926535897932384626433832795[...] 22/7 = 3.14 ; 2 points of precision 333/106 = 3.1415 ; 4 points of precision 103993/33102 = 3.141592653 ; 9 points of precision ____________________ If a user asks for pi with at least 3 points of precision, we can give them 333/106. ;^) // posting from my gmail account, my Usenet server is acting funny right now.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2018-12-05 03:14 +0000 |
| Message-ID | <8736rc8y2e.fsf@bsb.me.uk> |
| In reply to | #138519 |
chris.m.thomasson.1@gmail.com writes: <snip> > Fwiw, an arbitrary precision real can be the convergent of a continued > fraction up to a user provided precision. (Incidentally, "continued fraction" is a technical term for something else.) > For instance: > ____________________ > PI = 3.1415926535897932384626433832795[...] > 22/7 = 3.14 ; 2 points of precision > 333/106 = 3.1415 ; 4 points of precision > 103993/33102 = 3.141592653 ; 9 points of precision > ____________________ > > If a user asks for pi with at least 3 points of precision, we can give > them 333/106. ;^) There's a better ratio of numbers in that range, and it's easy to remember: double the first three odd numbers (113355) split in half (113 355) and divide the larger by the smaller: 355/113 = 3.1415929... where pi has a 6 in that last shown digit. That's 7 significant digits of accuracy. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid> |
|---|---|
| Date | 2018-12-05 14:27 -0800 |
| Message-ID | <pu9jc2$a16$2@dont-email.me> |
| In reply to | #138523 |
On 12/4/2018 7:14 PM, Ben Bacarisse wrote: > chris.m.thomasson.1@gmail.com writes: > <snip> >> Fwiw, an arbitrary precision real can be the convergent of a continued >> fraction up to a user provided precision. > > (Incidentally, "continued fraction" is a technical term for something else.) > >> For instance: >> ____________________ >> PI = 3.1415926535897932384626433832795[...] >> 22/7 = 3.14 ; 2 points of precision >> 333/106 = 3.1415 ; 4 points of precision >> 103993/33102 = 3.141592653 ; 9 points of precision >> ____________________ >> >> If a user asks for pi with at least 3 points of precision, we can give >> them 333/106. ;^) > > There's a better ratio of numbers in that range, and it's easy to > remember: double the first three odd numbers (113355) split in half (113 > 355) and divide the larger by the smaller: > > 355/113 = 3.1415929... :^) > > where pi has a 6 in that last shown digit. That's 7 significant digits > of accuracy. For some reason, I was measuring the digits of accuracy after the decimal point.
[toc] | [prev] | [next] | [standalone]
| From | Lew Pitcher <lew.pitcher@digitalfreehold.ca> |
|---|---|
| Date | 2018-12-04 20:03 -0500 |
| Message-ID | <pu8q18$2kn$2@dont-email.me> |
| In reply to | #138519 |
chris.m.thomasson.1@gmail.com wrote: > On Tuesday, December 4, 2018 at 10:58:57 AM UTC-8, Eli the Bearded wrote: >> In comp.lang.c, Thiago Adams <thiago.adams@gmail.com> wrote: >> > Every float point number is a fraction, >> >> How do you reconcile that statement with the definition of an >> "irrational number"? >> >> Elijah >> ------ >> just curious > > Fwiw, an arbitrary precision real can be the convergent of a continued > fraction up to a user provided precision. For instance: > ____________________ > PI = 3.1415926535897932384626433832795[...] > 22/7 = 3.14 ; 2 points of precision > 333/106 = 3.1415 ; 4 points of precision 355/113 = 3.141592 ; 6 points of precision > 103993/33102 = 3.141592653 ; 9 points of precision > ____________________ > > If a user asks for pi with at least 3 points of precision, we can give > them 333/106. ;^) > > // posting from my gmail account, my Usenet server is acting funny right > now. -- Lew Pitcher "In Skills, We Trust"
[toc] | [prev] | [next] | [standalone]
Page 1 of 7 [1] 2 3 4 5 6 7 Next page →
Back to top | Article view | comp.lang.c
csiph-web