Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #123045 > unrolled thread
| Started by | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| First post | 2017-11-20 12:14 +0100 |
| Last post | 2017-11-22 10:58 +0100 |
| Articles | 6 on this page of 86 — 24 participants |
Back to article view | Back to comp.lang.c
High level programming in C jacobnavia <jacob@jacob.remcomp.fr> - 2017-11-20 12:14 +0100
Re: High level programming in C David Brown <david.brown@hesbynett.no> - 2017-11-20 12:52 +0100
Re: High level programming in C Robert Wessel <robertwessel2@yahoo.com> - 2017-11-20 06:07 -0600
Re: High level programming in C David Brown <david.brown@hesbynett.no> - 2017-11-20 13:38 +0100
Re: High level programming in C jacobnavia <jacob@jacob.remcomp.fr> - 2017-11-20 14:23 +0100
Re: High level programming in C David Brown <david.brown@hesbynett.no> - 2017-11-20 16:56 +0100
Re: High level programming in C Spiros Bousbouras <spibou@gmail.com> - 2017-11-20 17:14 +0000
Re: High level programming in C Spiros Bousbouras <spibou@gmail.com> - 2017-11-20 17:21 +0000
Re: High level programming in C "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2017-11-20 22:45 +0800
Re: High level programming in C Ian Collins <ian-news@hotmail.com> - 2017-11-21 07:30 +1300
Re: High level programming in C gazelle@shell.xmission.com (Kenny McCormack) - 2017-11-20 18:32 +0000
Re: High level programming in C jameskuyper@verizon.net - 2017-11-20 11:05 -0800
Re: High level programming in C Öö Tiib <ootiib@hot.ee> - 2017-11-20 12:59 -0800
Re: High level programming in C BGB <cr88192@hotmail.com> - 2017-11-22 10:47 -0600
Re: High level programming in C fir <profesor.fir@gmail.com> - 2017-11-20 13:17 -0800
Re: High level programming in C Thiago Adams <thiago.adams@gmail.com> - 2017-11-21 03:26 -0800
Re: High level programming in C jacobnavia <jacob@jacob.remcomp.fr> - 2017-11-21 14:54 +0100
Re: High level programming in C scott@slp53.sl.home (Scott Lurndal) - 2017-11-21 14:51 +0000
Re: High level programming in C David Brown <david.brown@hesbynett.no> - 2017-11-21 16:43 +0100
Re: High level programming in C Thiago Adams <thiago.adams@gmail.com> - 2017-11-21 07:58 -0800
Re: High level programming in C jacobnavia <jacob@jacob.remcomp.fr> - 2017-11-21 17:35 +0100
Re: High level programming in C Spiros Bousbouras <spibou@gmail.com> - 2017-11-21 16:38 +0000
Re: High level programming in C Thiago Adams <thiago.adams@gmail.com> - 2017-11-21 08:47 -0800
Re: High level programming in C jacobnavia <jacob@jacob.remcomp.fr> - 2017-11-21 17:55 +0100
Re: High level programming in C Thiago Adams <thiago.adams@gmail.com> - 2017-11-21 09:06 -0800
Re: High level programming in C Thiago Adams <thiago.adams@gmail.com> - 2017-11-21 09:13 -0800
Re: High level programming in C Keith Thompson <kst-u@mib.org> - 2017-11-21 11:29 -0800
Re: High level programming in C supercat@casperkitty.com - 2017-11-21 11:59 -0800
Re: High level programming in C Keith Thompson <kst-u@mib.org> - 2017-11-21 12:52 -0800
Re: High level programming in C supercat@casperkitty.com - 2017-11-21 13:43 -0800
Re: High level programming in C Keith Thompson <kst-u@mib.org> - 2017-11-21 14:17 -0800
Re: High level programming in C supercat@casperkitty.com - 2017-11-21 15:00 -0800
Re: High level programming in C Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2017-11-21 15:17 -0700
Re: High level programming in C supercat@casperkitty.com - 2017-11-21 15:09 -0800
Re: High level programming in C jacobnavia <jacob@jacob.remcomp.fr> - 2017-11-22 00:55 +0100
Re: High level programming in C "James R. Kuyper" <jameskuyper@verizon.net> - 2017-11-21 18:58 -0500
Re: High level programming in C jacobnavia <jacob@jacob.remcomp.fr> - 2017-11-22 01:19 +0100
Re: High level programming in C Spiros Bousbouras <spibou@gmail.com> - 2017-11-22 01:47 +0000
Re: High level programming in C Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2017-11-21 21:48 -0700
Re: High level programming in C Spiros Bousbouras <spibou@gmail.com> - 2017-11-22 07:36 +0000
Re: High level programming in C "James R. Kuyper" <jameskuyper@verizon.net> - 2017-11-22 12:45 -0500
Re: High level programming in C supercat@casperkitty.com - 2017-11-22 14:00 -0800
Re: High level programming in C Keith Thompson <kst-u@mib.org> - 2017-11-22 14:25 -0800
Re: High level programming in C supercat@casperkitty.com - 2017-11-22 15:14 -0800
Re: High level programming in C Keith Thompson <kst-u@mib.org> - 2017-11-22 16:08 -0800
Re: High level programming in C supercat@casperkitty.com - 2017-11-23 16:42 -0800
Re: High level programming in C bartc <bc@freeuk.com> - 2017-11-24 01:37 +0000
Re: High level programming in C supercat@casperkitty.com - 2017-11-24 14:33 -0800
Re: High level programming in C Thiago Adams <thiago.adams@gmail.com> - 2017-11-21 16:20 -0800
Re: High level programming in C David Brown <david.brown@hesbynett.no> - 2017-11-22 10:39 +0100
Re: High level programming in C Thiago Adams <thiago.adams@gmail.com> - 2017-11-23 02:59 -0800
Re: High level programming in C David Brown <david.brown@hesbynett.no> - 2017-11-23 12:24 +0100
Re: High level programming in C Thiago Adams <thiago.adams@gmail.com> - 2017-11-23 04:49 -0800
Re: High level programming in C scott@slp53.sl.home (Scott Lurndal) - 2017-11-22 15:42 +0000
Re: High level programming in C Keith Thompson <kst-u@mib.org> - 2017-11-22 08:57 -0800
Re: High level programming in C Keith Thompson <kst-u@mib.org> - 2017-11-21 09:19 -0800
Re: High level programming in C Thiago Adams <thiago.adams@gmail.com> - 2017-11-21 09:28 -0800
Re: High level programming in C supercat@casperkitty.com - 2017-11-21 09:22 -0800
Re: High level programming in C scott@slp53.sl.home (Scott Lurndal) - 2017-11-21 16:29 +0000
Re: High level programming in C jacobnavia <jacob@jacob.remcomp.fr> - 2017-11-21 17:43 +0100
Re: High level programming in C jacobnavia <jacob@jacob.remcomp.fr> - 2017-11-21 17:40 +0100
Re: High level programming in C Thiago Adams <thiago.adams@gmail.com> - 2017-11-21 08:52 -0800
Re: High level programming in C Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-11-21 09:28 -0800
Re: High level programming in C Thiago Adams <thiago.adams@gmail.com> - 2017-11-21 09:34 -0800
Re: High level programming in C Robert Wessel <robertwessel2@yahoo.com> - 2017-11-21 11:37 -0600
Re: High level programming in C jacobnavia <jacob@jacob.remcomp.fr> - 2017-11-21 20:28 +0100
Re: High level programming in C Spiros Bousbouras <spibou@gmail.com> - 2017-11-21 19:45 +0000
Re: High level programming in C "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-11-21 11:51 -0800
Re: High level programming in C jacobnavia <jacob@jacob.remcomp.fr> - 2017-11-21 20:55 +0100
Re: High level programming in C Spiros Bousbouras <spibou@gmail.com> - 2017-11-21 20:07 +0000
Re: High level programming in C Ian Collins <ian-news@hotmail.com> - 2017-11-22 09:13 +1300
Re: High level programming in C scott@slp53.sl.home (Scott Lurndal) - 2017-11-22 15:38 +0000
Re: High level programming in C Robert Wessel <robertwessel2@yahoo.com> - 2017-11-21 15:17 -0600
Re: High level programming in C Ian Collins <ian-news@hotmail.com> - 2017-11-22 10:25 +1300
Re: High level programming in C Robert Wessel <robertwessel2@yahoo.com> - 2017-11-21 15:41 -0600
Re: High level programming in C gordonb.fqrzr@burditt.org (Gordon Burditt) - 2017-12-10 21:24 -0600
Re: High level programming in C David Kleinecke <dkleinecke@gmail.com> - 2017-12-10 20:03 -0800
Re: High level programming in C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-12-11 17:49 +0000
Re: High level programming in C David Kleinecke <dkleinecke@gmail.com> - 2017-12-11 10:32 -0800
Re: High level programming in C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-12-12 01:33 +0000
Re: High level programming in C David Kleinecke <dkleinecke@gmail.com> - 2017-12-11 18:34 -0800
Re: High level programming in C jacobnavia <jacob@jacob.remcomp.fr> - 2017-12-11 20:09 +0100
Re: High level programming in C Keith Thompson <kst-u@mib.org> - 2017-12-11 11:23 -0800
Re: High level programming in C David Brown <david.brown@hesbynett.no> - 2017-11-22 11:01 +0100
Re: High level programming in C antispam@math.uni.wroc.pl - 2017-11-21 20:11 +0000
Re: High level programming in C David Brown <david.brown@hesbynett.no> - 2017-11-22 10:58 +0100
Page 5 of 5 — ← Prev page 1 2 3 4 [5]
| From | David Kleinecke <dkleinecke@gmail.com> |
|---|---|
| Date | 2017-12-11 18:34 -0800 |
| Message-ID | <ed9ecf73-a6cd-41ad-a7c8-56eaa0319292@googlegroups.com> |
| In reply to | #124201 |
On Monday, December 11, 2017 at 5:33:41 PM UTC-8, Ben Bacarisse wrote: > David Kleinecke <dkleinecke@gmail.com> writes: > > > On Monday, December 11, 2017 at 9:49:46 AM UTC-8, Ben Bacarisse wrote: > >> David Kleinecke <dkleinecke@gmail.com> writes: > <snip> > >> > One way to get involved with large integers is to try to > >> > build an API for rational numbers. So far as I know there > >> > is none readily available. > <snip> > >> > But conceptually the job is > >> > rather easy. I know of no "practical" problems that require > >> > a solution in rationals and that probably explains why they > >> > get no attention from programmers. > >> > >> Computer algebra systems need them. > >> > >> For general numerical work, they suffer from the fact that they can grow > >> to use a lot of storage quite quickly (even when the rational value > >> remains small). > <snip> > > But per your last paragraph my point remains valid. > > Then I don't think I get what your point is. I don't see how the fact > that they are not generally the right solution relates to them getting > no attention from programmers. (I admit I'm guessing, but can't see how > my last paragraph relates to the other point at all.) I offered rational calculations as an example of a field that required a very large amount of computer resources.
[toc] | [prev] | [next] | [standalone]
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2017-12-11 20:09 +0100 |
| Message-ID | <p0ml4c$c62$1@dont-email.me> |
| In reply to | #124123 |
Le 11/12/2017 à 05:03, David Kleinecke a écrit :
> One way to get involved with large integers is to try to
> build an API for rational numbers.
All floating point numbers are rational numbers
Let's take a concrete example: the number 178.125.
Suppose this program:
#include <stdio.h>
// No compiler alignment
#pragma pack(1)
// In this structure we describe a simple precision floating point
// number.
typedef union {
float fl;
struct {
unsigned f:23; // fraction part
unsigned e:8; // exponent part
unsigned sign:1; // sign
};
} number;
// This function prints the parts of a floating point number
// in binary and decimal notation.
void pfloat(number t)
{
printf("Sign %d, exponent %d (-127= %d), fraction: %023b\n",
t.sign,t.e,t.e-127,t.f);
}
int main(void)
{
number t;
t.fl = 178.125;
pfloat(t);
return 0;
}
This will produce the output:
Sign 0, exponent 134 (-127= 7), fraction: 01100100010000000000000
To calculate the fraction we do:
fraction = 01100100001 =
0 * 1/2 +
1 * 1/4 +
1 * 1/8 +
0 * 1/16+
0 * 1/32+
1 * 1/64 +
... +
1 * 1/1024
This is:
0.25+0.125+0.015625+0.0009765625 = 0.3916015625
Then, we add 1 to 0.3916015625 obtaining 1.3916015625.
This number, we multiply it by 2^7 = 128:
1,3916015625 * 128 = 178.125.
Note that by choosing the appropiate number I avoided the horrible
problem of rounding :-)
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-12-11 11:23 -0800 |
| Message-ID | <lnr2s1oyqf.fsf@kst-u.example.com> |
| In reply to | #124167 |
jacobnavia <jacob@jacob.remcomp.fr> writes:
> Le 11/12/2017 à 05:03, David Kleinecke a écrit :
>> One way to get involved with large integers is to try to
>> build an API for rational numbers.
>
> All floating point numbers are rational numbers
True (ignoring infinities and NaNs), but not all rational numbers are
floating point numbers. The floating point numbers are a subset of the
rational numbers, and that subset excludes a lot of useful values.
A library that supports rational numbers will be able to represent 1/3
exactly. (And it's been pointed out that such libraries do exist.)
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-11-22 11:01 +0100 |
| Message-ID | <ov3ht8$r13$1@dont-email.me> |
| In reply to | #123199 |
On 21/11/17 20:55, jacobnavia wrote: > Le 21/11/2017 à 20:45, Spiros Bousbouras a écrit : >> On Tue, 21 Nov 2017 20:28:32 +0100 >> jacobnavia <jacob@jacob.remcomp.fr> wrote: >>> In another matter, I am implementing ARM64 128 bit maths. It is quite >>> difficult, since there aren't any 128 bit ops, except multiply, that >>> gives you the higher 64 bits. It is still very embryonary but I have >>> managed the four operations (division and modulous call assembler >>> routines) >> >> If one wants 128 bit (or above) maths why wouldn't they use the GNU >> multiprecision library ? >> > > Because GNU multiple precision library is a multiple precision library > and my 128 bit maths are fixed, so MUCH faster than a multi precision > library. That is a very good reason. > > A second reason is that they could like lcc rather than gcc, but I do > not want to offense your religious feelings > That is not quite so good a reason, since gcc has (on most targets) supported an __int128 type with arithmetic operations for a great many years. Lcc has some nice features that gcc does not have - but this is not one of them. > :-)
[toc] | [prev] | [next] | [standalone]
| From | antispam@math.uni.wroc.pl |
|---|---|
| Date | 2017-11-21 20:11 +0000 |
| Message-ID | <ov21a1$10f$1@z-news.wcss.wroc.pl> |
| In reply to | #123195 |
Spiros Bousbouras <spibou@gmail.com> wrote:
> On Tue, 21 Nov 2017 20:28:32 +0100
> jacobnavia <jacob@jacob.remcomp.fr> wrote:
> > In another matter, I am implementing ARM64 128 bit maths. It is quite
> > difficult, since there aren't any 128 bit ops, except multiply, that
> > gives you the higher 64 bits. It is still very embryonary but I have
> > managed the four operations (division and modulous call assembler routines)
>
> If one wants 128 bit (or above) maths why wouldn't they use the GNU
> multiprecision library ?
To gain some extra speed? GMP is hard to beat for larger numbers,
say bigger than 20 machine words. But for fixed length moderate
precisions (2-20 machine words) one can do better. Fist, one
wants static allocation (possible with GMP, but in such case
one can only call lowest-level GMP functions). Secondly,
specializing for specific length (like 2 or 3 words) gives
measurable speedup compared to routine handling all lengths.
In particular, 2 words operations in many cases can be done
by inline code which is simpler than calling sequence of
library routine.
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-11-22 10:58 +0100 |
| Message-ID | <ov3hnf$pkj$1@dont-email.me> |
| In reply to | #123195 |
On 21/11/17 20:45, Spiros Bousbouras wrote: > On Tue, 21 Nov 2017 20:28:32 +0100 > jacobnavia <jacob@jacob.remcomp.fr> wrote: >> In another matter, I am implementing ARM64 128 bit maths. It is quite >> difficult, since there aren't any 128 bit ops, except multiply, that >> gives you the higher 64 bits. It is still very embryonary but I have >> managed the four operations (division and modulous call assembler routines) > > If one wants 128 bit (or above) maths why wouldn't they use the GNU > multiprecision library ? You might want 128 bit, but not need anything higher. 128 bit maths can be done orders of magnitude more efficiently with fixed sizes than with multiprecision libraries. On a 64-bit platform, 128-bit maths is pretty easy to implement - it's exactly the same as doing 32-bit maths on a 16-bit platform or 16-bit maths on an 8-bit platform. (Getting high efficiency out of a division routine here can be more challenging.) > >> I am running at 76% of fully optimized gcc in normal code. > > What are you measuring and what mathematical operation between the two > gives 76% ? >
[toc] | [prev] | [standalone]
Page 5 of 5 — ← Prev page 1 2 3 4 [5]
Back to top | Article view | comp.lang.c
csiph-web