Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #120124 > unrolled thread
| Started by | David Kleinecke <dkleinecke@gmail.com> |
|---|---|
| First post | 2017-09-21 20:50 -0700 |
| Last post | 2017-09-22 09:12 -0700 |
| Articles | 20 on this page of 178 — 26 participants |
Back to article view | Back to comp.lang.c
Something C might need David Kleinecke <dkleinecke@gmail.com> - 2017-09-21 20:50 -0700
Re: Something C might need Robert Wessel <robertwessel2@yahoo.com> - 2017-09-22 01:15 -0500
Re: Something C might need Robert Wessel <robertwessel2@yahoo.com> - 2017-09-22 01:21 -0500
Re: Something C might need fir <profesor.fir@gmail.com> - 2017-09-22 00:44 -0700
Re: Something C might need Noob <root@127.0.0.1> - 2017-09-22 11:02 +0200
Re: Something C might need Robert Wessel <robertwessel2@yahoo.com> - 2017-09-22 12:35 -0500
Re: Something C might need Richard Damon <Richard@Damon-Family.org> - 2017-09-22 13:46 -0400
Re: Something C might need David Kleinecke <dkleinecke@gmail.com> - 2017-09-22 11:47 -0700
Re: Something C might need supercat@casperkitty.com - 2017-09-22 12:16 -0700
Re: Something C might need Richard Damon <Richard@Damon-Family.org> - 2017-09-22 18:10 -0400
Re: Something C might need Keith Thompson <kst-u@mib.org> - 2017-09-22 15:24 -0700
Re: Something C might need supercat@casperkitty.com - 2017-09-22 15:52 -0700
Re: Something C might need David Brown <david.brown@hesbynett.no> - 2017-09-23 12:29 +0200
Re: Something C might need supercat@casperkitty.com - 2017-09-23 08:29 -0700
Re: Something C might need Keith Thompson <kst-u@mib.org> - 2017-09-23 18:06 -0700
Re: Something C might need David Brown <david.brown@hesbynett.no> - 2017-09-24 12:28 +0200
Re: Something C might need David Kleinecke <dkleinecke@gmail.com> - 2017-09-22 16:17 -0700
Re: Something C might need Keith Thompson <kst-u@mib.org> - 2017-09-22 18:20 -0700
Re: Something C might need David Kleinecke <dkleinecke@gmail.com> - 2017-09-22 22:45 -0700
Re: Something C might need David Brown <david.brown@hesbynett.no> - 2017-09-23 12:22 +0200
Re: Something C might need bartc <bc@freeuk.com> - 2017-09-23 11:29 +0100
Re: Something C might need Jerry Stuckle <jstucklex@attglobal.net> - 2017-09-23 10:25 -0400
Re: Something C might need Reinhardt Behm <rbehm@hushmail.com> - 2017-09-24 22:09 +0800
Re: Something C might need bartc <bc@freeuk.com> - 2017-09-24 15:32 +0100
Re: Something C might need supercat@casperkitty.com - 2017-09-24 13:17 -0700
Re: Something C might need bartc <bc@freeuk.com> - 2017-09-24 21:53 +0100
Re: Something C might need supercat@casperkitty.com - 2017-09-24 14:54 -0700
Re: Something C might need bartc <bc@freeuk.com> - 2017-09-24 23:10 +0100
Re: Something C might need supercat@casperkitty.com - 2017-09-24 16:14 -0700
Re: Something C might need bartc <bc@freeuk.com> - 2017-09-25 01:04 +0100
Re: Something C might need supercat@casperkitty.com - 2017-09-24 17:23 -0700
Re: Something C might need David Brown <david.brown@hesbynett.no> - 2017-09-25 08:48 +0200
Re: Something C might need David Kleinecke <dkleinecke@gmail.com> - 2017-09-25 11:50 -0700
Re: Something C might need David Brown <david.brown@hesbynett.no> - 2017-09-25 21:59 +0200
Re: Something C might need David Kleinecke <dkleinecke@gmail.com> - 2017-09-25 14:25 -0700
Re: Something C might need David Brown <david.brown@hesbynett.no> - 2017-09-26 09:39 +0200
Re: Something C might need David Kleinecke <dkleinecke@gmail.com> - 2017-09-26 11:50 -0700
Re: Something C might need Robert Wessel <robertwessel2@yahoo.com> - 2017-09-25 15:44 -0500
Re: Something C might need Jerry Stuckle <jstucklex@attglobal.net> - 2017-09-24 18:57 -0400
Re: Something C might need bartc <bc@freeuk.com> - 2017-09-25 00:08 +0100
Re: Something C might need Jerry Stuckle <jstucklex@attglobal.net> - 2017-09-24 20:51 -0400
Re: Something C might need bartc <bc@freeuk.com> - 2017-09-25 02:10 +0100
Re: Something C might need Jerry Stuckle <jstucklex@attglobal.net> - 2017-09-24 22:22 -0400
Re: Something C might need Thiago Adams <thiago.adams@gmail.com> - 2017-09-25 06:35 -0700
Re: Something C might need David Brown <david.brown@hesbynett.no> - 2017-09-25 16:16 +0200
Re: Something C might need Thiago Adams <thiago.adams@gmail.com> - 2017-09-25 07:47 -0700
Re: Something C might need Thiago Adams <thiago.adams@gmail.com> - 2017-09-25 13:38 -0700
Re: Something C might need Robert Wessel <robertwessel2@yahoo.com> - 2017-09-24 23:29 -0500
Re: Something C might need Robert Wessel <robertwessel2@yahoo.com> - 2017-09-25 17:40 -0500
Re: Something C might need Robert Wessel <robertwessel2@yahoo.com> - 2017-09-24 23:30 -0500
Re: Something C might need Jerry Stuckle <jstucklex@attglobal.net> - 2017-09-25 08:58 -0400
Re: Something C might need supercat@casperkitty.com - 2017-09-23 08:41 -0700
Re: Something C might need bartc <bc@freeuk.com> - 2017-09-23 17:32 +0100
Re: Something C might need supercat@casperkitty.com - 2017-09-23 11:32 -0700
Re: Something C might need Jorgen Grahn <grahn+nntp@snipabacken.se> - 2017-09-25 14:43 +0000
Re: Something C might need David Brown <david.brown@hesbynett.no> - 2017-09-25 22:07 +0200
Re: Something C might need supercat@casperkitty.com - 2017-09-25 13:34 -0700
Re: Something C might need Ian Collins <ian-news@hotmail.com> - 2017-09-26 10:04 +1300
Re: Something C might need Jorgen Grahn <grahn+nntp@snipabacken.se> - 2017-09-26 14:31 +0000
Re: Something C might need Ian Collins <ian-news@hotmail.com> - 2017-09-27 08:38 +1300
Re: Something C might need Keith Thompson <kst-u@mib.org> - 2017-09-23 17:49 -0700
Re: Something C might need gordonb.w32iq@burditt.org (Gordon Burditt) - 2017-09-23 21:21 -0500
Re: Something C might need supercat@casperkitty.com - 2017-09-24 11:27 -0700
Re: Something C might need gordonb.woyvd@burditt.org (Gordon Burditt) - 2017-09-25 01:08 -0500
Re: Something C might need supercat@casperkitty.com - 2017-09-25 09:38 -0700
Re: Something C might need supercat@casperkitty.com - 2017-09-25 10:00 -0700
Re: Something C might need Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-09-23 11:32 +0100
Re: Something C might need David Kleinecke <dkleinecke@gmail.com> - 2017-09-23 12:29 -0700
Re: Something C might need Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-09-23 20:38 +0100
Re: Something C might need David Kleinecke <dkleinecke@gmail.com> - 2017-09-23 15:25 -0700
Re: Something C might need Richard Damon <Richard@Damon-Family.org> - 2017-09-23 20:36 -0400
Re: Something C might need Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-09-24 01:42 +0100
Re: Something C might need Keith Thompson <kst-u@mib.org> - 2017-09-23 18:03 -0700
Re: Something C might need David Kleinecke <dkleinecke@gmail.com> - 2017-09-23 22:47 -0700
Re: Something C might need Keith Thompson <kst-u@mib.org> - 2017-09-24 12:03 -0700
Re: Something C might need David Kleinecke <dkleinecke@gmail.com> - 2017-09-24 15:10 -0700
Re: Something C might need Keith Thompson <kst-u@mib.org> - 2017-09-24 16:20 -0700
Re: Something C might need David Kleinecke <dkleinecke@gmail.com> - 2017-09-24 16:44 -0700
Re: Something C might need David Brown <david.brown@hesbynett.no> - 2017-09-25 09:00 +0200
Re: Something C might need supercat@casperkitty.com - 2017-09-24 16:51 -0700
Re: Something C might need David Brown <david.brown@hesbynett.no> - 2017-09-25 09:11 +0200
Re: Something C might need David Brown <david.brown@hesbynett.no> - 2017-09-25 09:04 +0200
Re: Something C might need bartc <bc@freeuk.com> - 2017-09-23 22:10 +0100
Re: Something C might need Ian Collins <ian-news@hotmail.com> - 2017-09-24 10:19 +1300
Re: Something C might need Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-09-24 01:38 +0100
Re: Something C might need bartc <bc@freeuk.com> - 2017-09-24 02:14 +0100
Re: Something C might need Keith Thompson <kst-u@mib.org> - 2017-09-23 18:41 -0700
Re: Something C might need bartc <bc@freeuk.com> - 2017-09-24 11:16 +0100
Re: Something C might need bartc <bc@freeuk.com> - 2017-09-24 11:41 +0100
Re: Something C might need Keith Thompson <kst-u@mib.org> - 2017-09-24 12:15 -0700
Re: Something C might need Keith Thompson <kst-u@mib.org> - 2017-09-24 12:23 -0700
Re: Something C might need David Brown <david.brown@hesbynett.no> - 2017-09-24 14:03 +0200
Re: Something C might need bartc <bc@freeuk.com> - 2017-09-24 13:59 +0100
Re: Something C might need bartc <bc@freeuk.com> - 2017-09-24 16:08 +0100
Re: Something C might need David Brown <david.brown@hesbynett.no> - 2017-09-24 21:50 +0200
Re: Something C might need bartc <bc@freeuk.com> - 2017-09-24 21:40 +0100
Re: Something C might need David Brown <david.brown@hesbynett.no> - 2017-09-25 09:28 +0200
Re: Something C might need luser droog <luser.droog@gmail.com> - 2017-09-26 06:28 -0700
Re: Something C might need supercat@casperkitty.com - 2017-09-26 07:47 -0700
Re: Something C might need David Brown <david.brown@hesbynett.no> - 2017-09-27 08:26 +0200
Re: Something C might need supercat@casperkitty.com - 2017-09-27 07:22 -0700
Re: Something C might need Keith Thompson <kst-u@mib.org> - 2017-09-27 09:01 -0700
Re: Something C might need supercat@casperkitty.com - 2017-09-27 09:42 -0700
Re: Something C might need David Brown <david.brown@hesbynett.no> - 2017-09-28 10:42 +0200
Re: Something C might need bartc <bc@freeuk.com> - 2017-09-27 19:22 +0100
Re: Something C might need David Brown <david.brown@hesbynett.no> - 2017-09-28 10:48 +0200
Re: Something C might need scott@slp53.sl.home (Scott Lurndal) - 2017-09-28 17:31 +0000
Re: Something C might need Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-09-24 22:09 +0100
Re: Something C might need bartc <bc@freeuk.com> - 2017-09-24 22:44 +0100
Re: Something C might need Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-09-25 01:57 +0100
Re: Something C might need bartc <bc@freeuk.com> - 2017-09-25 02:02 +0100
Re: Something C might need Keith Thompson <kst-u@mib.org> - 2017-09-24 19:10 -0700
Re: Something C might need bartc <bc@freeuk.com> - 2017-09-27 16:27 +0100
Re: Something C might need Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-09-27 09:26 -0700
Re: Something C might need David Brown <david.brown@hesbynett.no> - 2017-09-28 10:53 +0200
Re: Something C might need Keith Thompson <kst-u@mib.org> - 2017-09-27 10:52 -0700
Re: Something C might need bartc <bc@freeuk.com> - 2017-09-27 19:20 +0100
Re: Something C might need supercat@casperkitty.com - 2017-09-27 11:44 -0700
Re: Something C might need David Brown <david.brown@hesbynett.no> - 2017-09-28 10:57 +0200
Re: Something C might need James Kuyper <jameskuyper@verizon.net> - 2017-09-24 14:49 -0400
Re: Something C might need David Brown <david.brown@hesbynett.no> - 2017-09-24 22:06 +0200
Re: Something C might need bartc <bc@freeuk.com> - 2017-09-24 20:09 +0100
Re: Something C might need Keith Thompson <kst-u@mib.org> - 2017-09-24 12:12 -0700
Re: Something C might need bartc <bc@freeuk.com> - 2017-09-24 20:46 +0100
Re: Something C might need David Brown <david.brown@hesbynett.no> - 2017-09-25 09:41 +0200
Re: Something C might need Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-09-24 21:05 +0100
Re: Something C might need gordonb.r273i@burditt.org (Gordon Burditt) - 2017-09-23 21:34 -0500
Re: Something C might need Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-09-24 09:01 +0100
Re: Something C might need Noob <root@127.0.0.1> - 2017-09-24 19:34 +0200
Re: Something C might need Robert Wessel <robertwessel2@yahoo.com> - 2017-09-24 23:53 -0500
Re: Something C might need "James R. Kuyper" <jameskuyper@verizon.net> - 2017-09-25 12:27 -0400
Re: Something C might need Noob <root@127.0.0.1> - 2017-09-25 20:33 +0200
Re: Something C might need Robert Wessel <robertwessel2@yahoo.com> - 2017-09-25 15:52 -0500
Re: Something C might need Noob <root@127.0.0.1> - 2017-09-25 23:23 +0200
Re: Something C might need Keith Thompson <kst-u@mib.org> - 2017-09-25 15:15 -0700
Re: Something C might need Robert Wessel <robertwessel2@yahoo.com> - 2017-09-25 17:49 -0500
Re: Something C might need David Brown <david.brown@hesbynett.no> - 2017-09-26 09:46 +0200
Re: Something C might need supercat@casperkitty.com - 2017-09-26 07:32 -0700
Re: Something C might need David Brown <david.brown@hesbynett.no> - 2017-09-26 21:50 +0200
Re: Something C might need supercat@casperkitty.com - 2017-09-26 14:32 -0700
Re: Something C might need Noob <root@127.0.0.1> - 2017-09-26 22:34 +0200
Re: Something C might need supercat@casperkitty.com - 2017-09-26 14:39 -0700
Re: Something C might need Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-09-25 19:38 +0100
Re: Something C might need "James R. Kuyper" <jameskuyper@verizon.net> - 2017-09-25 15:00 -0400
Re: Something C might need Keith Thompson <kst-u@mib.org> - 2017-09-25 12:29 -0700
Re: Something C might need David Brown <david.brown@hesbynett.no> - 2017-09-25 22:12 +0200
Re: Something C might need bartc <bc@freeuk.com> - 2017-09-22 11:38 +0100
Re: Something C might need Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-09-22 04:21 -0700
Re: Something C might need David Brown <david.brown@hesbynett.no> - 2017-09-22 14:54 +0200
Re: Something C might need Keith Thompson <kst-u@mib.org> - 2017-09-22 08:02 -0700
Re: Something C might need "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-09-22 06:49 -0700
Re: Something C might need Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-09-22 20:24 +0100
Re: Something C might need "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-09-22 12:45 -0700
Re: Something C might need Ian Collins <ian-news@hotmail.com> - 2017-09-23 09:00 +1200
Re: Something C might need "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-09-22 17:34 -0400
Re: Something C might need Ian Collins <ian-news@hotmail.com> - 2017-09-23 10:49 +1200
Re: Something C might need "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-09-22 19:25 -0400
Re: Something C might need "James R. Kuyper" <jameskuyper@verizon.net> - 2017-09-22 19:35 -0400
Re: Something C might need Ian Collins <ian-news@hotmail.com> - 2017-09-23 11:52 +1200
Re: Something C might need "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-09-22 18:25 -0700
Re: Something C might need Ian Collins <ian-news@hotmail.com> - 2017-09-23 13:36 +1200
Re: Something C might need "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-09-22 20:20 -0700
Rick says C is a dying language. (Was: Something C might need) gazelle@shell.xmission.com (Kenny McCormack) - 2017-09-23 09:15 +0000
Re: Rick says C is a dying language. (Was: Something C might need) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-09-23 04:40 -0700
Re: Something C might need bartc <bc@freeuk.com> - 2017-09-23 13:00 +0100
Re: Something C might need "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-09-23 10:28 -0400
Re: Something C might need James Kuyper <jameskuyper@verizon.net> - 2017-09-22 23:22 -0400
Re: Something C might need Ian Collins <ian-news@hotmail.com> - 2017-09-23 18:01 +1200
Re: Something C might need Jerry Stuckle <jstucklex@attglobal.net> - 2017-09-22 20:31 -0400
Re: Something C might need jladasky@itu.edu - 2017-09-22 16:27 -0700
Re: Something C might need "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-09-22 16:34 -0700
Re: Something C might need scott@slp53.sl.home (Scott Lurndal) - 2017-09-26 21:44 +0000
Re: Something C might need "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-09-26 14:53 -0700
Re: Something C might need Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-09-23 02:14 +0100
Re: Something C might need bartc <bc@freeuk.com> - 2017-09-22 21:31 +0100
Re: Something C might need supercat@casperkitty.com - 2017-09-22 14:02 -0700
Re: Something C might need "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-09-22 17:29 -0400
Re: Something C might need supercat@casperkitty.com - 2017-09-22 09:12 -0700
Page 8 of 9 — ← Prev page 1 2 3 4 5 6 7 [8] 9 Next page →
| From | Noob <root@127.0.0.1> |
|---|---|
| Date | 2017-09-26 22:34 +0200 |
| Message-ID | <oqedlf$p0d$1@dont-email.me> |
| In reply to | #120338 |
On 26/09/2017 00:49, Robert Wessel wrote:
> On Mon, 25 Sep 2017 23:23, Noob wrote:
>
>> On 25/09/2017 22:52, Robert Wessel wrote:
>>
>>> [ The __int128 type ] is not supported by all GCC targets.
>>
>> Why would you need __int128 on all GCC targets?
>>
>> It is useful on platforms that provide widening instructions,
>> such as imulq on amd64.
>
> It was being presented as a "standard" way of requesting a double
> width multiplication result. My point was that this is a GCC
> extension, and not even implemented for all GCC targets.
>
> Even fairly small systems now implement encryption, usually to support
> SSL, which requires arithmetic on large integers. Implementing a
> bignum multiplication routine efficiently in C difficult to do without
> knowing something about the underlying machine and possibly using
> non-standard extensions (like being able to get the result of a
> widening multiplication instruction). Often we just implement the
> limbs ("digits") used to implement the bignum library as half the size
> of the biggest conveniently available type (long long, these days). On
> some processors it might be best to do 16-bit limbs, on others
> 64x64->128 bit multiplications are available in the ISA, and we'd want
> to use those (and 64-bit limbs). Half-sized limbs also make handling
> carry propagation easier.
If I were to write an efficient AND portable bignum lib
in C, I would definitely write different code on 32-bit
platforms (with a native 32x32->64 mul) and 64-bit
platforms (with a native 64x64->128 mul) -- different
but probably very similar, though. Likewise, the size of
a limb would be dictated by the platform.
My assertion is: because GCC (and other compilers) recognize
the "widening multiply pattern", it is possible to write
efficient (i.e. close to hand-coded ASM) bignum code in C.
And that's why I don't think the universality of __int128
is relevant. It is available where it is needed, i.e.
on 64-bit platforms. On 32-bit platforms, when writing
"bare-metal" code, a 128-bit type is too high-level for
the task.
Regards.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-09-26 14:39 -0700 |
| Message-ID | <b905e165-7675-4a2b-aba7-ab62c8c9f267@googlegroups.com> |
| In reply to | #120350 |
On Tuesday, September 26, 2017 at 3:35:14 PM UTC-5, Noob wrote: > And that's why I don't think the universality of __int128 > is relevant. It is available where it is needed, i.e. > on 64-bit platforms. On 32-bit platforms, when writing > "bare-metal" code, a 128-bit type is too high-level for > the task. A lot of code is used in context where performance essentially doesn't matter; anything that's within an order of magnitude or two of optimal would be equally good. It shouldn't be particularly difficult for a compiler to support 128-bit types by simply using a few basic library functions. Any argument that could be made against having a 32-bit system support such types could be made equally well against having 8-bit or 16-bit controllers support 64-bit types (IMHO, those should have been an optional feature, but one that quality implementations should support when practical; for better or for worse, making those types optional might have allowed the development of a ones'-complement implementation of C99.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-09-25 19:38 +0100 |
| Message-ID | <87o9py1v5h.fsf@bsb.me.uk> |
| In reply to | #120312 |
"James R. Kuyper" <jameskuyper@verizon.net> writes: <snip> > Support for uint_fast128_t is optional, but it should be available on > any platform where your u128 is - a statement I'll stick with even > though it fails in the only place I can easily test. Some > experimenting shows that the gcc I'm using supports __int128, but > neither __uint128, nor uint_least128_t. That strikes me as quite odd. I suspect that this is, in part, because the gcc people did not want intmax_t to be 128 bits. That would force preprocessor arithmetic to done in 128 bits. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | "James R. Kuyper" <jameskuyper@verizon.net> |
|---|---|
| Date | 2017-09-25 15:00 -0400 |
| Message-ID | <31ab7483-b29f-4a65-5631-52ffb12a4f28@verizon.net> |
| In reply to | #120318 |
On 2017-09-25 14:38, Ben Bacarisse wrote: > "James R. Kuyper" <jameskuyper@verizon.net> writes: > <snip> >> Support for uint_fast128_t is optional, but it should be available on >> any platform where your u128 is - a statement I'll stick with even >> though it fails in the only place I can easily test. Some >> experimenting shows that the gcc I'm using supports __int128, but >> neither __uint128, nor uint_least128_t. That strikes me as quite odd. > > I suspect that this is, in part, because the gcc people did not want > intmax_t to be 128 bits. That would force preprocessor arithmetic to > done in 128 bits. That seems counter-intuitive. If I'm writing code that relies upon 128 bit integers, I would both want and expect [u]intmax_t to be a 128 bit type, with all of the corresponding inefficiency (which, in the case of pre-processor arithmetic, would only occur at compile time, which matters very little to me).
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-09-25 12:29 -0700 |
| Message-ID | <lnefqu1ssa.fsf@kst-u.example.com> |
| In reply to | #120320 |
"James R. Kuyper" <jameskuyper@verizon.net> writes:
> On 2017-09-25 14:38, Ben Bacarisse wrote:
>> "James R. Kuyper" <jameskuyper@verizon.net> writes:
>> <snip>
>>> Support for uint_fast128_t is optional, but it should be available on
>>> any platform where your u128 is - a statement I'll stick with even
>>> though it fails in the only place I can easily test. Some
>>> experimenting shows that the gcc I'm using supports __int128, but
>>> neither __uint128, nor uint_least128_t. That strikes me as quite odd.
>>
>> I suspect that this is, in part, because the gcc people did not want
>> intmax_t to be 128 bits. That would force preprocessor arithmetic to
>> done in 128 bits.
>
> That seems counter-intuitive. If I'm writing code that relies upon 128
> bit integers, I would both want and expect [u]intmax_t to be a 128 bit
> type, with all of the corresponding inefficiency (which, in the case of
> pre-processor arithmetic, would only occur at compile time, which
> matters very little to me).
As someone else mentioned, gcc's unsigned 128-bit type is called
"unsigned __int128". Apparently __int128 is treated as a type
specifier, not as a typedef.
As for not defining [u]intmax_t to be 128 bits, gcc's __int128 and
unsigned __int128 types are not treated as integer types, not even as
extended integer types. The rationale, as I understand it, is that it
making [u]intmax_t 128 bits would directly or indirectly break some
APIs. Note in particular that a compiler and runtime library have to
agree on the width of intmax_t so that the "%jd" and "%ju" printf
formats will work correctly. I suppose some other functions (outside
the C standard library might use [u]intmax and could break if it were
changed.
https://stackoverflow.com/q/29927562/827263
--
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-09-25 22:12 +0200 |
| Message-ID | <oqbo02$ou$1@dont-email.me> |
| In reply to | #120318 |
On 25/09/17 20:38, Ben Bacarisse wrote: > "James R. Kuyper" <jameskuyper@verizon.net> writes: > <snip> >> Support for uint_fast128_t is optional, but it should be available on >> any platform where your u128 is - a statement I'll stick with even >> though it fails in the only place I can easily test. Some >> experimenting shows that the gcc I'm using supports __int128, but >> neither __uint128, nor uint_least128_t. That strikes me as quite odd. > > I suspect that this is, in part, because the gcc people did not want > intmax_t to be 128 bits. That would force preprocessor arithmetic to > done in 128 bits. > That is the answer I got from the gcc folks when I asked them. They are not allowed to define uint128_t and int128_t unless they have an integer type of that size. If the platform has 128 bit long long, that's fine (I don't know if any gcc target /does/ have 128-bit long long, but they are ready for it!). Failing that, they would have to make __int128 into an extended integer type - and that means intmax_t would have to be 128 bit, which would conflict with the ABI's of all their current targets, and mess up things like printf. It is much easier to say they have __int128 and unsigned __int128, and that you can use them for arithmetic and such like, but they are not extended integers and uint128_t and int128_t are not defined.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-09-22 11:38 +0100 |
| Message-ID | <gK5xB.1543529$tu4.847413@fx35.am4> |
| In reply to | #120124 |
On 22/09/2017 04:50, David Kleinecke wrote: > I look upon the addition of two integers as the > philosophical prototype of computing. I see the > concept of "int" in C as indicating the size of > the integers in the prototypical addition. > > There is no reason not to do all integer additions > in registers that are the normal maximum size. So > we may want the concepts of "short" and "char" for > smaller integer types that are extended to "int" > when actually added. > > But these ideal ints fail when we multiple. The > product of two ints is - conceptually - twice the > size of an int. Actually, you have the same problem with add. Adding two 32-bit values may need 33 bits to represent the result. And multiplying two 32-bit values may need 64 bits. But this is C; it's low level and you expect things to silently overflow or be truncated. Otherwise you'd have to worry about the possibility of: a*b*c*d*e requiring 160 bits to represent. > Hence we need "long". "long" in C is not guaranteed to give you a wider type than "int". "long long" I think is. But C, as > it stands, does not implement that situation. > > What we seem to need is operators, call them > ":=" and "=:" with the semantics and constraints: > a := b > means a is an int, b is a long int and the > execution is to assign the value in the > upper half of b to a. Conversely > b =: a > assigns the value in a to the upper half of b. Apart from the poor choice of ":=" as operator (I think it's the next most popular choice for assignment after "="), these operations aren't intuitive. And a := b can be replaced by a = b>>32 for example. Or you can do it via macro: a = MSW(b). > In the case of division "b / a" b is a long or > a smaller int extended to long. It is possible > for b / a to extend larger than an int so > it is long but b % a is always an int. You've lost me here. -- bartc
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2017-09-22 04:21 -0700 |
| Message-ID | <5c736b16-b601-4270-a5bd-f0b7537663de@googlegroups.com> |
| In reply to | #120132 |
On Friday, September 22, 2017 at 11:38:24 AM UTC+1, Bart wrote: > On 22/09/2017 04:50, David Kleinecke wrote: > > Actually, you have the same problem with add. > > Adding two 32-bit values may need 33 bits to represent the result. And > multiplying two 32-bit values may need 64 bits. > > But this is C; it's low level and you expect things to silently overflow > or be truncated. Otherwise you'd have to worry about the possibility of: > > a*b*c*d*e > > requiring 160 bits to represent. > It's not really a problem with add or multiply. The value presumably represents something. If that something cannot be held in an "int" then you mustn't use int to hold it. However the problem is that exceptionally many real life values can go over 2 billion, eg the number of pixels in an image, whilst usually being comfortably less than that number, and on many architectures int, which is a default integer type, is only 32 bits for efficiency reasons.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-09-22 14:54 +0200 |
| Message-ID | <oq315u$rv5$1@dont-email.me> |
| In reply to | #120132 |
On 22/09/17 12:38, bartc wrote: > On 22/09/2017 04:50, David Kleinecke wrote: >> I look upon the addition of two integers as the >> philosophical prototype of computing. I see the >> concept of "int" in C as indicating the size of >> the integers in the prototypical addition. >> >> There is no reason not to do all integer additions >> in registers that are the normal maximum size. So >> we may want the concepts of "short" and "char" for >> smaller integer types that are extended to "int" >> when actually added. >> >> But these ideal ints fail when we multiple. The >> product of two ints is - conceptually - twice the >> size of an int. > > Actually, you have the same problem with add. > > Adding two 32-bit values may need 33 bits to represent the result. And > multiplying two 32-bit values may need 64 bits. > > But this is C; it's low level and you expect things to silently overflow > or be truncated. Otherwise you'd have to worry about the possibility of: > > a*b*c*d*e > > requiring 160 bits to represent. > >> Hence we need "long". > > "long" in C is not guaranteed to give you a wider type than "int". "long > long" I think is. Nope. "long long" is guaranteed to be at least 64 bits, and but there is nothing to say that "int" cannot be just as big (it can't be bigger). There are certainly C implementations in which "int" is 64 bit. I don't know details about "long long" on such systems, however. On most modern systems, int is 32-bit, long long is 64-bit, and long is either 32-bit (such as Windows 32-bit and 64-bit, and *nix 32-bit) or 64-bit (such as *nix 64-bit). > > But C, as >> it stands, does not implement that situation. >> >> What we seem to need is operators, call them >> ":=" and "=:" with the semantics and constraints: >> a := b >> means a is an int, b is a long int and the >> execution is to assign the value in the >> upper half of b to a. Conversely >> b =: a >> assigns the value in a to the upper half of b. > > Apart from the poor choice of ":=" as operator (I think it's the next > most popular choice for assignment after "="), these operations aren't > intuitive. > > And a := b can be replaced by a = b>>32 for example. Or you can do it > via macro: a = MSW(b). This gets messy very quickly when you have signed integer types. It's best to stick to unsigned types, use compiler builtins, or accept that this stuff is usually easier or more efficient with some implementation-specific assumptions. > >> In the case of division "b / a" b is a long or >> a smaller int extended to long. It is possible >> for b / a to extend larger than an int so >> it is long but b % a is always an int. > > You've lost me here. >
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-09-22 08:02 -0700 |
| Message-ID | <lnefqy4w05.fsf@kst-u.example.com> |
| In reply to | #120132 |
bartc <bc@freeuk.com> writes:
[...]
> "long" in C is not guaranteed to give you a wider type than "int". "long
> long" I think is.
[...]
No, long long can be the same width as int (if int is at least 64 bits).
It would be legal for char, short, int, long, and long long *all* to be
the same width, as long as that width is at least 64 bits.
--
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 | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2017-09-22 06:49 -0700 |
| Message-ID | <5e839fa6-953f-4306-894a-fba9cc66e1c6@googlegroups.com> |
| In reply to | #120124 |
On Thursday, September 21, 2017 at 11:51:05 PM UTC-4, David Kleinecke wrote:
> But these ideal ints fail when we multiple. The
> product of two ints is - conceptually - twice the
> size of an int. Hence we need "long". But C, as
> it stands, does not implement that situation.
CAlive handles this by automatically up-sizing the operands in
expressions to their larger form, so as to guarantee that the
value computed will be the one the human expected to see, and
not the one a truncated computation might erroneously yield
due to it not containing enough bits for the correct answer.
This necessarily decreases performance, and it has the ability
through use of a cask to override the auto-upsizing, but it is
the form that should be used.
In addition, CAlive introduces explicitly sized variables as
a native type:
s8,u8 -- signed and unsigned 8-bit quantities
s16,u16 -- Signed and unsigned 16-bit quantities
s32,u32 -- Signed and unsigned 32-bit quantities
s64,u64 -- Signed and unsigned 64-bit quantities
f32,f64 -- 32-bit and 64-bit floating point
I also introduce arbitrary types:
bi,bfp -- Big integer, big floating point
And I also introduce variable sizes for storing in memory to a
particular bit size that are auto-upsized to the next largest
size in computation. These are also signed saturating in the
store:
as8,au8 -- Auto-upsizing 8-bit to 32-bit quantities
as16,au16 -- Auto-upsizing 16-bit to 32-bit quantities
as24,au24 -- Auto-upsizing 24-bit to 32-bit quantities
xs8,xu8 -- Auto-upsizing 8-bit to 64-bit quantities
xs16,xu16 -- Auto-upsizing 16-bit to 64-bit quantities
xs24,xu24 -- Auto-upsizing 24-bit to 64-bit quantities
xs32,xu32 -- Auto-upsizing 32-bit to 64-bit quantities
xs40,xu40 -- Auto-upsizing 40-bit to 64-bit quantities
xs48,xu48 -- Auto-upsizing 48-bit to 64-bit quantities
xs56,xu56 -- Auto-upsizing 56-bit to 64-bit quantities
Note: These are used primarily for data translation from
other systems, and aren't generally intended to be
used internally save the standard forms of 8,16,32.
In this way, you have control over whether or not the values
should be upsized, or whether they should remain, and with
the ability to inject <|overflow?|> and <|underflow?|> casks,
you can handle the exact condition you're looking for.
CAlive looks to be incredible. The more I throw stuff at it
to try and break it, the more I see it being solid. I cannot
wait until it's completed.
I could use help in its development. If you're willing to
look within yourself, and look up to God, and come to Him
asking forgiveness for your sin, and then looking to Him for
how to use the skills you possess in this world ... then this
project could use your skills. I look forward to hearing from
you.
Thank you,
Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-09-22 20:24 +0100 |
| Message-ID | <871smycza9.fsf@bsb.me.uk> |
| In reply to | #120138 |
"Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes: <snip> > CAlive handles this ... Please stop plugging your personal language. <snip> > CAlive looks to be incredible. Yup. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2017-09-22 12:45 -0700 |
| Message-ID | <a01cbc7a-987b-4c96-a879-b099ff1bf418@googlegroups.com> |
| In reply to | #120152 |
On Friday, September 22, 2017 at 3:24:26 PM UTC-4, Ben Bacarisse wrote: > "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes: > <snip> > > CAlive handles this ... > > Please stop plugging your personal language. As I've told you repeatedly, these ideas I have for enhancements to C are encapsulated in CAlive. They are NOT exclusive to it. They will work for C were it to be augmented. I am providing the example of my time and thought and energy in work- king on developing specific ideas. I am responding with the fruit of that time spent in contemplative labor pursuing things that cor- relate to the similar ideas other people are posting in this clc group regarding aspects of software development related to C, which includes enhancements, changes, and extensions needed in C to address their perceived shortcomings. The subject material I am bringing up is not off-topic, and I would like to ask you to stop harassing me regarding CAlive. The ONLY reason I'm working on CAlive is because I met nothing but resistance from men like you when I came to these groups in 2014, and 2015, and 2016, asking, and in many cases begging, for C to be extended in some of these ways. You flatly refused me then, and now you are trying to curtail my ongoing efforts to reach out with the knowledge and experience and creativity I have, that I've poured into this language to make C better, all culminating in a new product called CAlive ... the very name of which is an injection of new life into C. You are exerting efforts toward ruining the advancement of this dying language, and I find it absolutely deplorable behavior, Ben, both then in 2014-2016 and now. > <snip> > > CAlive looks to be incredible. > > Yup. If you can legitimately find something to break the design ideas I propose, or find flaws in the details of the design at various points as I post them, then I would absolutely welcome your contribution because it will help everybody, including me. But if not, then kindly sit down, be quiet, and cease your constant refutation of my posts simply because they are not exclusive to C. My posts are valid and poignant ideas that can be used to improve C. They give other people things to think about, alternate ideas to consider. Even in many cases a documented syntax that can be examined, understood, and then improved upon or tweaked to help their idea bear more fruit. FWIW, I am flatly amazed that CAlive is shaping up the way it has. It's like this thing that keeps building itself. I am literally in the middle of doing other things, of coding regular coding, and idea after idea pops into my head about some new features I could into C, but since that's not possible with the inflexible C Standard body attendants, I incorporate into CAlive where I do have free rein. I go and write about it in that moment, and over time this whole new creation is being produced largely outside of my influence, as I am not the author of these ideas, but merely the conveyer. I welcome everybody's attempts to refute my thinking in design, and in my methods of improving the language ... even yours, Ben. But I will not listen to your attempts to silence me simply because you are willing only to look as far as your myopic vision of C extends. The world is a far more diverse and interesting place, and C needs to evolve or it's going to die a slow, painful death. The sooner your realize that, and the sooner you start contributing to that thing C must migrate into, the better off we'll all be. Thank you, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2017-09-23 09:00 +1200 |
| Message-ID | <f2lbujF4nmbU1@mid.individual.net> |
| In reply to | #120154 |
On 09/23/17 07:45 AM, Rick C. Hodgin wrote: > > You are exerting efforts toward ruining the advancement of this > dying language, and I find it absolutely deplorable behavior, Ben, > both then in 2014-2016 and now. Which dying language would that be? I can see an elderly but healthy one and a pipe dream.... -- Ian
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2017-09-22 17:34 -0400 |
| Message-ID | <oq3vl3$6v1$1@dont-email.me> |
| In reply to | #120159 |
On 09/22/2017 05:00 PM, Ian Collins wrote:
> On 09/23/17 07:45 AM, Rick C. Hodgin wrote:
>>
>> You are exerting efforts toward ruining the advancement of this
>> dying language, and I find it absolutely deplorable behavior, Ben,
>> both then in 2014-2016 and now.
>
> Which dying language would that be? I can see an elderly but healthy
> one and a pipe dream....
I think you use Solaris, so you might not be able to see graphics in
your web browser LOL, but if you look at the graph in this page:
https://www.tiobe.com/tiobe-index/
...you'll see C and Java both descending rapidly from 2014 at around
18% or so, through until the present time, dropping down to about 8%
or so as many other new languages are coming up, those which offer
easier syntax than C, and less restrictions on data processing than
Java.
Perhaps it's a two+ year burb as C does appear to be turning up
a blip there in recent weeks.
There is too much computing power available to make C worth coding
for in most cases anymore. If it wants to survive, it needs to
get with the times and implement some compiler features that may
take longer to compile, but provide developer with time-saving
additions.
Thank you,
Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2017-09-23 10:49 +1200 |
| Message-ID | <f2lickF4nmbU3@mid.individual.net> |
| In reply to | #120163 |
On 09/23/17 09:34 AM, Rick C. Hodgin wrote: > On 09/22/2017 05:00 PM, Ian Collins wrote: >> On 09/23/17 07:45 AM, Rick C. Hodgin wrote: >>> >>> You are exerting efforts toward ruining the advancement of this >>> dying language, and I find it absolutely deplorable behavior, Ben, >>> both then in 2014-2016 and now. >> >> Which dying language would that be? I can see an elderly but healthy >> one and a pipe dream.... > > I think you use Solaris, so you might not be able to see graphics in > your web browser LOL, but if you look at the graph in this page: > > https://www.tiobe.com/tiobe-index/ > > ....you'll see C and Java both descending rapidly from 2014 at around > 18% or so, through until the present time, dropping down to about 8% > or so as many other new languages are coming up, those which offer > easier syntax than C, and less restrictions on data processing than > Java. At first glance, the maths in those tables doesn't add up with a 15% net drop in the top 20 languages.. > There is too much computing power available to make C worth coding > for in most cases anymore. If it wants to survive, it needs to > get with the times and implement some compiler features that may > take longer to compile, but provide developer with time-saving > additions. One quote of note on that page is "Applications that are written in a single programming language are getting rarer nowadays." which is very true. Each language has it's niche on a big project, so there's no need for any one language to provide the kitchen sink. Contemporary software projects are more akin to UNIX, with many small parts making up the whole, than the monolithic Windows world view! -- Ian
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2017-09-22 19:25 -0400 |
| Message-ID | <oq464e$dco$1@dont-email.me> |
| In reply to | #120167 |
On 09/22/2017 06:49 PM, Ian Collins wrote:
> On 09/23/17 09:34 AM, Rick C. Hodgin wrote:
>> On 09/22/2017 05:00 PM, Ian Collins wrote:
>>> On 09/23/17 07:45 AM, Rick C. Hodgin wrote:
>>>>
>>>> You are exerting efforts toward ruining the advancement of this
>>>> dying language, and I find it absolutely deplorable behavior, Ben,
>>>> both then in 2014-2016 and now.
>>>
>>> Which dying language would that be? I can see an elderly but healthy
>>> one and a pipe dream....
>>
>> I think you use Solaris, so you might not be able to see graphics in
>> your web browser LOL, but if you look at the graph in this page:
>>
>> https://www.tiobe.com/tiobe-index/
>>
>> ....you'll see C and Java both descending rapidly from 2014 at around
>> 18% or so, through until the present time, dropping down to about 8%
>> or so as many other new languages are coming up, those which offer
>> easier syntax than C, and less restrictions on data processing than
>> Java.
>
> At first glance, the maths in those tables doesn't add up with a 15% net
> drop in the top 20 languages..
It's possible. They may have changed their algorithm or language
inclusion search criteria in recent years.
>> There is too much computing power available to make C worth coding
>> for in most cases anymore. If it wants to survive, it needs to
>> get with the times and implement some compiler features that may
>> take longer to compile, but provide developer with time-saving
>> additions.
>
> One quote of note on that page is "Applications that are written in a
> single programming language are getting rarer nowadays." which is very
> true. Each language has it's niche on a big project, so there's no need
> for any one language to provide the kitchen sink.
I think there are purposes for various types of software development.
One of the things I've tried to bring into CAlive is the ability to
do many types of low-level data processing.
> Contemporary software
> projects are more akin to UNIX, with many small parts making up the
> whole, than the monolithic Windows world view!
I agree. It's one reason I made the decision to create RDC, and to
incorporate the basic _language_name { .. } block to include source
code from multiple different languages in a singe source file. At
their fundamental level the data gets processed similarly, but there
are different ways to get to those low-level portions.
With RDC and the planned many languages it will support, we will be
able to code several different ways in a single source file, with
each obeying its own language rules. That's the plan at least (James
4:15 "Lord willing").
Thank you,
Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | "James R. Kuyper" <jameskuyper@verizon.net> |
|---|---|
| Date | 2017-09-22 19:35 -0400 |
| Message-ID | <709024e4-08e2-0f9c-64dd-2f4c0610571c@verizon.net> |
| In reply to | #120167 |
On 2017-09-22 18:49, Ian Collins wrote: > On 09/23/17 09:34 AM, Rick C. Hodgin wrote: ... >> https://www.tiobe.com/tiobe-index/ ... > At first glance, the maths in those tables doesn't add up with a 15% net > drop in the top 20 languages.. I wouldn't argue for the absolute accuracy of Tiobe's numbers, nor for the validity of their algorithms - those are highly debatable issues. But you seem to be objecting based upon some internal inconsistency in those numbers, and I don't see that they provide enough information to perform such a consistency check. For instance, they show the ratings for Sep 2017, and the change since Sep 2016, but they don't say what the ratings in Sep 2016 were, so you can't validate the change. Since it only shows the ratings for the top 50 languages, their total shouldn't add up to 100%, and it doesn't. Since it only shows the changes for the top 20 languages, the total change doesn't have to add up to 0%, and it doesn't, either. Are you comparing these numbers with some alternative source of information? If so, which one?
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2017-09-23 11:52 +1200 |
| Message-ID | <f2lm1oF4nmbU4@mid.individual.net> |
| In reply to | #120173 |
On 09/23/17 11:35 AM, James R. Kuyper wrote: > On 2017-09-22 18:49, Ian Collins wrote: >> On 09/23/17 09:34 AM, Rick C. Hodgin wrote: > .... >>> https://www.tiobe.com/tiobe-index/ > .... >> At first glance, the maths in those tables doesn't add up with a 15% net >> drop in the top 20 languages.. > > I wouldn't argue for the absolute accuracy of Tiobe's numbers, nor for > the validity of their algorithms - those are highly debatable issues. > But you seem to be objecting based upon some internal inconsistency in > those numbers, and I don't see that they provide enough information to > perform such a consistency check. > For instance, they show the ratings for Sep 2017, and the change since > Sep 2016, but they don't say what the ratings in Sep 2016 were, so you > can't validate the change. Since it only shows the ratings for the top > 50 languages, their total shouldn't add up to 100%, and it doesn't. > Since it only shows the changes for the top 20 languages, the total > change doesn't have to add up to 0%, and it doesn't, either. > Are you comparing these numbers with some alternative source of > information? If so, which one? I'm saying I find it highly unlikely that the top 5 languages can loose over 12% between them without some other language in the top 20 making a significant gain. None do. -- Ian
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2017-09-22 18:25 -0700 |
| Message-ID | <71cfb4e2-bc50-4096-b2d4-2366f23cf4d6@googlegroups.com> |
| In reply to | #120174 |
On Friday, September 22, 2017 at 7:52:43 PM UTC-4, Ian Collins wrote:
> On 09/23/17 11:35 AM, James R. Kuyper wrote:
> > On 2017-09-22 18:49, Ian Collins wrote:
> >> On 09/23/17 09:34 AM, Rick C. Hodgin wrote:
> > ....
> >>> https://www.tiobe.com/tiobe-index/
> > ....
> >> At first glance, the maths in those tables doesn't add up with a 15% net
> >> drop in the top 20 languages..
> >
> > I wouldn't argue for the absolute accuracy of Tiobe's numbers, nor for
> > the validity of their algorithms - those are highly debatable issues.
> > But you seem to be objecting based upon some internal inconsistency in
> > those numbers, and I don't see that they provide enough information to
> > perform such a consistency check.
> > For instance, they show the ratings for Sep 2017, and the change since
> > Sep 2016, but they don't say what the ratings in Sep 2016 were, so you
> > can't validate the change. Since it only shows the ratings for the top
> > 50 languages, their total shouldn't add up to 100%, and it doesn't.
> > Since it only shows the changes for the top 20 languages, the total
> > change doesn't have to add up to 0%, and it doesn't, either.
> > Are you comparing these numbers with some alternative source of
> > information? If so, which one?
>
> I'm saying I find it highly unlikely that the top 5 languages can loose
> over 12% between them without some other language in the top 20 making a
> significant gain. None do.
The RedMonk Programming Language Rankings for June 2017 show C at #9
based on references in GitHub and Stack Overflow:
http://redmonk.com/sogrady/2017/06/08/language-rankings-6-17/
For IEEE Spectrum readers, C's at #2 behind Python:
https://spectrum.ieee.org/computing/software/the-2017-top-programming-languages
Raw data taken from Google Trends shows C at #7 at 6.1% down 1.1%:
http://pypl.github.io/PYPL.html
GitHut shows the ranking based solely on GitHub software, showing
C 13K repositories behind C++ at 73K active repositories:
http://githut.info
Thank you,
Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
Page 8 of 9 — ← Prev page 1 2 3 4 5 6 7 [8] 9 Next page →
Back to top | Article view | comp.lang.c
csiph-web