Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #92033 > unrolled thread
| Started by | eva galois <eva.galois@yandex.ru> |
|---|---|
| First post | 2016-08-09 19:37 -0400 |
| Last post | 2016-08-10 08:19 -0700 |
| Articles | 20 on this page of 387 — 27 participants |
Back to article view | Back to comp.lang.c
Difference between these pointer syntaxes eva galois <eva.galois@yandex.ru> - 2016-08-09 19:37 -0400
Re: Difference between these pointer syntaxes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-10 01:12 +0100
Re: Difference between these pointer syntaxes supercat@casperkitty.com - 2016-08-09 23:57 -0700
Re: Difference between these pointer syntaxes mark.bluemel@gmail.com - 2016-08-10 00:29 -0700
Re: Difference between these pointer syntaxes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-10 20:50 +0100
Re: Difference between these pointer syntaxes supercat@casperkitty.com - 2016-08-10 15:54 -0700
Re: Difference between these pointer syntaxes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-11 01:20 +0100
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-10 18:01 -0700
Re: Difference between these pointer syntaxes supercat@casperkitty.com - 2016-08-11 07:40 -0700
Re: Difference between these pointer syntaxes Ike Naar <ike@iceland.freeshell.org> - 2016-08-11 22:43 +0000
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-10 11:51 +0100
Re: Difference between these pointer syntaxes supercat@casperkitty.com - 2016-08-10 08:11 -0700
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-10 17:13 +0100
Re: Difference between these pointer syntaxes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-10 20:57 +0100
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-10 21:21 +0100
Re: Difference between these pointer syntaxes jameskuyper@verizon.net - 2016-08-10 14:38 -0700
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-10 23:16 +0100
Re: Difference between these pointer syntaxes jameskuyper@verizon.net - 2016-08-10 20:19 -0700
Re: Difference between these pointer syntaxes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-11 01:36 +0100
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-11 10:49 +0100
Re: Difference between these pointer syntaxes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-11 11:46 +0100
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-11 13:09 +0100
Re: Difference between these pointer syntaxes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-11 15:45 +0100
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-11 16:46 +0100
Re: Difference between these pointer syntaxes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-11 19:44 +0100
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-11 18:58 +0100
Re: Difference between these pointer syntaxes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-12 01:13 +0100
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-12 11:18 +0100
Re: Difference between these pointer syntaxes Ike Naar <ike@iceland.freeshell.org> - 2016-08-12 16:28 +0000
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-12 18:51 +0100
Re: Difference between these pointer syntaxes Ike Naar <ike@iceland.freeshell.org> - 2016-08-12 18:18 +0000
Re: Difference between these pointer syntaxes Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-12 11:31 -0700
Re: Difference between these pointer syntaxes Ike Naar <ike@iceland.freeshell.org> - 2016-08-12 19:30 +0000
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-12 20:44 +0100
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-12 14:32 -0700
Re: Difference between these pointer syntaxes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-12 23:03 +0100
Re: Difference between these pointer syntaxes Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-12 22:46 -0700
Re: Difference between these pointer syntaxes Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-12 12:37 -0700
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-12 21:07 +0100
Re: Difference between these pointer syntaxes supercat@casperkitty.com - 2016-08-12 13:34 -0700
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-12 22:12 +0100
Re: Difference between these pointer syntaxes Melzzzzz <mel@zzzzz.com> - 2016-08-12 23:24 +0200
Re: Difference between these pointer syntaxes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-13 00:59 +0100
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-13 11:28 +0100
Re: Difference between these pointer syntaxes Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-13 03:56 -0700
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-13 12:52 +0100
Re: Difference between these pointer syntaxes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-13 17:34 +0100
Re: Difference between these pointer syntaxes supercat@casperkitty.com - 2016-08-13 09:44 -0700
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-13 18:35 +0100
Re: Difference between these pointer syntaxes supercat@casperkitty.com - 2016-08-13 11:21 -0700
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-15 12:35 +0100
Re: Difference between these pointer syntaxes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-15 15:10 +0100
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-15 17:07 +0100
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-15 10:03 -0700
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-15 17:26 +0100
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-15 11:42 -0700
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-15 19:04 +0100
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-15 12:27 -0700
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-15 20:04 +0100
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-15 13:32 -0700
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-15 21:32 +0100
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-15 14:50 -0700
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-15 22:38 +0100
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-15 16:03 -0700
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-16 00:32 +0100
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-15 17:57 -0700
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-16 01:28 +0100
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-15 19:13 -0700
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-16 11:01 +0100
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-16 08:35 -0700
Re: Difference between these pointer syntaxes fir <profesor.fir@gmail.com> - 2016-08-16 07:29 -0700
Re: Difference between these pointer syntaxes already5chosen@yahoo.com - 2016-08-16 10:40 -0700
Re: Difference between these pointer syntaxes jameskuyper@verizon.net - 2016-08-16 10:48 -0700
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-16 12:21 -0700
Re: Difference between these pointer syntaxes supercat@casperkitty.com - 2016-08-16 12:19 -0700
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-16 14:03 -0700
Re: Difference between these pointer syntaxes supercat@casperkitty.com - 2016-08-16 13:14 -0700
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-16 21:48 +0100
Re: Difference between these pointer syntaxes supercat@casperkitty.com - 2016-08-16 14:14 -0700
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-16 15:22 -0700
Re: Difference between these pointer syntaxes supercat@casperkitty.com - 2016-08-16 14:46 -0700
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-16 16:41 -0700
Re: Difference between these pointer syntaxes Les Cargill <lcargill99@comcast.com> - 2016-08-17 08:44 -0500
Re: Difference between these pointer syntaxes James Kuyper <jameskuyper@verizon.net> - 2016-08-17 10:12 -0400
Re: Difference between these pointer syntaxes Les Cargill <lcargill99@comcast.com> - 2016-08-17 10:38 -0500
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-17 10:45 -0700
Re: Difference between these pointer syntaxes Les Cargill <lcargill99@comcast.com> - 2016-08-17 17:06 -0500
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-17 17:06 -0700
Re: Difference between these pointer syntaxes supercat@casperkitty.com - 2016-08-17 09:58 -0700
Re: Difference between these pointer syntaxes Les Cargill <lcargill99@comcast.com> - 2016-08-17 16:54 -0500
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-17 09:59 -0700
Re: Difference between these pointer syntaxes Jean-Marc Bourguet <jm@bourguet.org> - 2016-08-17 19:41 +0200
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-17 13:03 -0700
Re: Difference between these pointer syntaxes Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-17 11:45 -0700
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-17 13:10 -0700
Re: Difference between these pointer syntaxes Jean-Marc Bourguet <jm@bourguet.org> - 2016-08-17 23:01 +0200
Re: Difference between these pointer syntaxes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-17 21:09 +0100
Re: Difference between these pointer syntaxes Les Cargill <lcargill99@comcast.com> - 2016-08-17 17:16 -0500
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-17 17:20 -0700
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-18 00:04 +0100
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-17 18:01 -0700
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-18 01:03 +0100
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-17 19:10 -0700
Re: Difference between these pointer syntaxes Jean-Marc Bourguet <jm@bourguet.org> - 2016-08-18 11:11 +0200
Re: Difference between these pointer syntaxes Les Cargill <lcargill99@comcast.com> - 2016-08-18 09:40 -0500
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-18 11:25 -0700
Re: Difference between these pointer syntaxes Les Cargill <lcargill99@comcast.com> - 2016-08-18 12:51 -0500
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-18 13:22 -0700
Re: Difference between these pointer syntaxes Tim Rentsch <txr@alumni.caltech.edu> - 2016-08-19 00:20 -0700
Re: Difference between these pointer syntaxes Les Cargill <lcargill99@comcast.com> - 2016-08-19 17:41 -0500
Re: Difference between these pointer syntaxes Tim Rentsch <txr@alumni.caltech.edu> - 2016-08-20 00:17 -0700
Re: Difference between these pointer syntaxes Les Cargill <lcargill99@comcast.com> - 2016-08-20 13:43 -0500
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-20 21:00 +0100
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-20 16:00 -0700
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-21 00:52 +0100
Re: Difference between these pointer syntaxes fir <profesor.fir@gmail.com> - 2016-08-21 13:04 -0700
Re: Difference between these pointer syntaxes Tim Rentsch <txr@alumni.caltech.edu> - 2016-08-25 18:06 -0700
Re: Difference between these pointer syntaxes James Kuyper <jameskuyper@verizon.net> - 2016-08-26 07:31 -0400
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-26 14:25 +0100
Re: Difference between these pointer syntaxes Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-26 06:36 -0700
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-26 15:37 +0100
Re: Difference between these pointer syntaxes Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-26 07:59 -0700
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-26 09:07 -0700
Re: Difference between these pointer syntaxes Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-26 09:22 -0700
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-26 11:22 -0700
Re: Difference between these pointer syntaxes Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-26 11:21 -0400
Re: Difference between these pointer syntaxes Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-26 08:37 -0700
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-26 09:46 -0700
Re: Difference between these pointer syntaxes supercat@casperkitty.com - 2016-08-26 09:23 -0700
Re: Difference between these pointer syntaxes Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-26 12:52 -0400
Re: Difference between these pointer syntaxes Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-26 10:50 -0700
Re: Difference between these pointer syntaxes Richard Heathfield <rjh@cpax.org.uk> - 2016-08-26 17:46 +0100
Re: Difference between these pointer syntaxes supercat@casperkitty.com - 2016-08-26 10:38 -0700
Re: Difference between these pointer syntaxes Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-26 14:05 -0400
Re: Difference between these pointer syntaxes supercat@casperkitty.com - 2016-08-26 12:01 -0700
Re: Difference between these pointer syntaxes Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-26 15:12 -0400
Re: Difference between these pointer syntaxes supercat@casperkitty.com - 2016-08-26 12:48 -0700
Re: Difference between these pointer syntaxes Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-26 15:55 -0400
Re: Difference between these pointer syntaxes Richard Heathfield <rjh@cpax.org.uk> - 2016-08-26 21:02 +0100
otRe: Difference between these pointer syntaxes Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-26 16:27 -0400
Re: otRe: Difference between these pointer syntaxes Richard Heathfield <rjh@cpax.org.uk> - 2016-08-26 22:20 +0100
Re: otRe: Difference between these pointer syntaxes supercat@casperkitty.com - 2016-08-26 15:15 -0700
Re: otRe: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-26 17:01 -0700
Re: otRe: Difference between these pointer syntaxes supercat@casperkitty.com - 2016-08-26 16:45 -0700
Re: otRe: Difference between these pointer syntaxes Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-26 20:32 -0400
Re: otRe: Difference between these pointer syntaxes Richard Heathfield <rjh@cpax.org.uk> - 2016-08-27 03:09 +0100
Re: otRe: Difference between these pointer syntaxes Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-26 22:32 -0400
Re: otRe: Difference between these pointer syntaxes Richard Heathfield <rjh@cpax.org.uk> - 2016-08-27 04:07 +0100
Re: otRe: Difference between these pointer syntaxes James Kuyper <jameskuyper@verizon.net> - 2016-08-27 00:24 -0400
Re: otRe: Difference between these pointer syntaxes Richard Heathfield <rjh@cpax.org.uk> - 2016-08-27 07:03 +0100
Re: otRe: Difference between these pointer syntaxes "James R. Kuyper" <jameskuyper@verizon.net> - 2016-08-27 12:34 -0400
Re: otRe: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-27 11:46 -0700
Re: otRe: Difference between these pointer syntaxes Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-27 20:04 -0700
Re: otRe: Difference between these pointer syntaxes Tim Rentsch <txr@alumni.caltech.edu> - 2016-08-27 20:25 -0700
Re: otRe: Difference between these pointer syntaxes Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2016-08-27 21:32 -0600
Re: otRe: Difference between these pointer syntaxes Tim Rentsch <txr@alumni.caltech.edu> - 2016-08-27 20:42 -0700
Re: otRe: Difference between these pointer syntaxes Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-27 20:54 -0700
Re: otRe: Difference between these pointer syntaxes Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2016-08-27 23:58 -0400
Re: otRe: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-27 22:53 -0700
Re: otRe: Difference between these pointer syntaxes Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-27 23:29 -0700
Re: otRe: Difference between these pointer syntaxes Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-01 08:21 -0700
Re: otRe: Difference between these pointer syntaxes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-27 19:27 +0100
Re: otRe: Difference between these pointer syntaxes "James R. Kuyper" <jameskuyper@verizon.net> - 2016-08-27 14:46 -0400
Re: otRe: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-27 11:45 +0100
Re: otRe: Difference between these pointer syntaxes Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-27 04:47 -0700
Re: otRe: Difference between these pointer syntaxes supercat@casperkitty.com - 2016-08-27 12:26 -0700
Re: otRe: Difference between these pointer syntaxes Richard Heathfield <rjh@cpax.org.uk> - 2016-08-27 13:06 +0100
Re: otRe: Difference between these pointer syntaxes "James R. Kuyper" <jameskuyper@verizon.net> - 2016-08-27 13:59 -0400
Re: otRe: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-27 11:52 -0700
Re: otRe: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-27 19:31 +0100
Re: otRe: Difference between these pointer syntaxes jameskuyper@verizon.net - 2016-08-27 13:47 -0700
Re: otRe: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-27 22:49 +0100
Re: otRe: Difference between these pointer syntaxes jameskuyper@verizon.net - 2016-08-27 15:07 -0700
Re: otRe: Difference between these pointer syntaxes supercat@casperkitty.com - 2016-08-29 11:11 -0700
Re: otRe: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-27 15:57 -0700
Re: otRe: Difference between these pointer syntaxes Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-27 20:50 -0400
Re: otRe: Difference between these pointer syntaxes Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-27 20:45 -0400
Re: Difference between these pointer syntaxes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-26 21:18 +0100
Re: Difference between these pointer syntaxes James Kuyper <jameskuyper@verizon.net> - 2016-08-27 00:20 -0400
Re: Difference between these pointer syntaxes James Kuyper <jameskuyper@verizon.net> - 2016-08-27 00:27 -0400
Re: Difference between these pointer syntaxes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-26 17:01 +0100
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-26 19:50 +0100
Re: Difference between these pointer syntaxes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-26 21:30 +0100
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-26 22:11 +0100
Re: Difference between these pointer syntaxes James Kuyper <jameskuyper@verizon.net> - 2016-08-26 23:42 -0400
Re: Difference between these pointer syntaxes Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-26 21:15 -0700
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-27 11:37 +0100
Re: Difference between these pointer syntaxes jameskuyper@verizon.net - 2016-08-27 10:47 -0700
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-27 12:20 -0700
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-27 12:07 -0700
Re: Difference between these pointer syntaxes "James R. Kuyper" <jameskuyper@verizon.net> - 2016-08-27 14:52 -0400
Re: Difference between these pointer syntaxes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-27 21:20 +0100
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-27 14:18 -0700
Re: Difference between these pointer syntaxes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-27 23:14 +0100
Re: Difference between these pointer syntaxes Tim Rentsch <txr@alumni.caltech.edu> - 2016-08-27 20:06 -0700
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-27 23:37 -0700
Re: Difference between these pointer syntaxes Tim Rentsch <txr@alumni.caltech.edu> - 2016-08-30 08:51 -0700
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-16 20:36 +0100
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-16 14:10 -0700
Re: Difference between these pointer syntaxes Tim Rentsch <txr@alumni.caltech.edu> - 2016-08-19 00:59 -0700
Re: Difference between these pointer syntaxes Les Cargill <lcargill99@comcast.com> - 2016-08-19 17:53 -0500
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-19 18:25 -0700
Re: Difference between these pointer syntaxes Les Cargill <lcargill99@comcast.com> - 2016-08-19 20:14 -0500
Re: Difference between these pointer syntaxes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-20 14:37 +0100
Re: Difference between these pointer syntaxes Les Cargill <lcargill99@comcast.com> - 2016-08-20 13:27 -0500
Re: Difference between these pointer syntaxes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-20 20:30 +0100
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-20 15:30 -0700
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-20 15:48 +0100
Re: Difference between these pointer syntaxes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-20 17:12 +0100
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-20 22:20 +0100
Re: Difference between these pointer syntaxes Les Cargill <lcargill99@comcast.com> - 2016-08-20 13:31 -0500
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-20 15:02 -0700
Re: Difference between these pointer syntaxes Tim Rentsch <txr@alumni.caltech.edu> - 2016-08-19 17:26 -0700
Re: Difference between these pointer syntaxes Les Cargill <lcargill99@comcast.com> - 2016-08-19 19:47 -0500
Re: Difference between these pointer syntaxes fir <profesor.fir@gmail.com> - 2016-08-16 15:09 -0700
Re: Difference between these pointer syntaxes fir <profesor.fir@gmail.com> - 2016-08-16 15:22 -0700
Re: Difference between these pointer syntaxes Ian Collins <ian-news@hotmail.com> - 2016-08-17 10:45 +1200
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-17 00:11 +0100
Re: Difference between these pointer syntaxes Ian Collins <ian-news@hotmail.com> - 2016-08-17 11:25 +1200
Re: Difference between these pointer syntaxes supercat@casperkitty.com - 2016-08-16 16:12 -0700
Re: Difference between these pointer syntaxes Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-17 00:37 -0700
Re: Difference between these pointer syntaxes "James R. Kuyper" <jameskuyper@verizon.net> - 2016-08-16 19:12 -0400
Re: Difference between these pointer syntaxes Ian Collins <ian-news@hotmail.com> - 2016-08-17 11:22 +1200
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-17 01:23 +0100
Re: Difference between these pointer syntaxes Gareth Owen <gwowen@gmail.com> - 2016-08-17 20:55 +0100
Re: Difference between these pointer syntaxes Les Cargill <lcargill99@comcast.com> - 2016-08-17 17:20 -0500
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-17 17:41 -0700
Re: Difference between these pointer syntaxes supercat@casperkitty.com - 2016-08-17 16:43 -0700
Re: Difference between these pointer syntaxes Jean-Marc Bourguet <jm@bourguet.org> - 2016-08-18 11:59 +0200
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-18 13:20 +0100
Re: Difference between these pointer syntaxes supercat@casperkitty.com - 2016-08-18 07:35 -0700
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-18 16:16 +0100
Re: Difference between these pointer syntaxes supercat@casperkitty.com - 2016-08-18 08:43 -0700
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-18 16:52 +0100
Re: Difference between these pointer syntaxes Tim Rentsch <txr@alumni.caltech.edu> - 2016-08-19 00:35 -0700
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-19 11:22 +0100
Re: Difference between these pointer syntaxes supercat@casperkitty.com - 2016-08-15 13:52 -0700
Re: Difference between these pointer syntaxes "James R. Kuyper" <jameskuyper@verizon.net> - 2016-08-16 16:39 -0400
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-16 22:33 +0100
Re: Difference between these pointer syntaxes jameskuyper@verizon.net - 2016-08-16 15:32 -0700
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-17 00:00 +0100
Re: Difference between these pointer syntaxes jameskuyper@verizon.net - 2016-08-16 17:45 -0700
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-17 10:53 +0100
Re: Difference between these pointer syntaxes jameskuyper@verizon.net - 2016-08-17 07:44 -0700
Re: Difference between these pointer syntaxes supercat@casperkitty.com - 2016-08-17 08:28 -0700
Re: Difference between these pointer syntaxes jameskuyper@verizon.net - 2016-08-17 10:16 -0700
Re: Difference between these pointer syntaxes supercat@casperkitty.com - 2016-08-17 15:23 -0700
Re: Difference between these pointer syntaxes jameskuyper@verizon.net - 2016-08-17 15:33 -0700
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-17 17:29 +0100
Re: Difference between these pointer syntaxes jameskuyper@verizon.net - 2016-08-17 10:52 -0700
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-17 20:18 +0100
Re: Difference between these pointer syntaxes jameskuyper@verizon.net - 2016-08-17 13:16 -0700
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-17 21:34 +0100
Re: Difference between these pointer syntaxes jameskuyper@verizon.net - 2016-08-17 14:45 -0700
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-17 23:19 +0100
Re: Difference between these pointer syntaxes jameskuyper@verizon.net - 2016-08-17 16:03 -0700
Re: Difference between these pointer syntaxes supercat@casperkitty.com - 2016-08-17 16:19 -0700
Re: Difference between these pointer syntaxes supercat@casperkitty.com - 2016-08-17 14:09 -0700
Re: Difference between these pointer syntaxes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-17 19:51 +0100
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-17 20:44 +0100
Re: Difference between these pointer syntaxes jameskuyper@verizon.net - 2016-08-17 13:33 -0700
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-17 21:45 +0100
Re: Difference between these pointer syntaxes Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-17 15:37 -0700
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-17 23:48 +0100
Re: Difference between these pointer syntaxes Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-17 16:25 -0700
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-17 18:07 -0700
Re: Difference between these pointer syntaxes Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-17 17:07 -0700
Re: Difference between these pointer syntaxes supercat@casperkitty.com - 2016-08-17 17:22 -0700
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-17 19:14 -0700
Re: Difference between these pointer syntaxes Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-17 19:03 -0700
Re: Difference between these pointer syntaxes Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-01 08:23 -0700
Re: Difference between these pointer syntaxes Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-01 09:55 -0700
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-09-01 12:39 -0700
Re: Difference between these pointer syntaxes Anand Hariharan <mailto.anand.hariharan@gmail.com> - 2016-09-09 12:48 -0700
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-09-09 15:18 -0700
Re: Difference between these pointer syntaxes Anand Hariharan <mailto.anand.hariharan@gmail.com> - 2016-09-11 09:34 -0700
Re: Difference between these pointer syntaxes Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-04 14:55 -0700
Re: Difference between these pointer syntaxes Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-05 00:05 -0700
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-09-05 01:37 -0700
Re: Difference between these pointer syntaxes Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-11 06:31 -0700
Re: Difference between these pointer syntaxes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-09-05 10:51 +0100
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-09-05 14:13 -0700
Re: Difference between these pointer syntaxes Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-05 16:57 -0700
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-09-06 01:21 +0100
Re: Difference between these pointer syntaxes Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-05 17:31 -0700
Re: Difference between these pointer syntaxes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-09-06 02:12 +0100
Re: Difference between these pointer syntaxes Ike Naar <ike@iceland.freeshell.org> - 2016-09-06 06:42 +0000
Re: Difference between these pointer syntaxes Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-06 01:47 -0700
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-09-06 08:28 -0700
Re: Difference between these pointer syntaxes Richard Heathfield <rjh@cpax.org.uk> - 2016-09-06 13:54 +0100
Re: Difference between these pointer syntaxes Gareth Owen <gwowen@gmail.com> - 2016-09-06 18:06 +0100
Re: Difference between these pointer syntaxes John Bode <jfbode1029@gmail.com> - 2016-09-08 07:09 -0700
Re: Difference between these pointer syntaxes David Brown <david.brown@hesbynett.no> - 2016-09-06 09:29 +0200
Re: Difference between these pointer syntaxes Geoff <geoff@invalid.invalid> - 2016-09-06 09:06 -0700
Re: Difference between these pointer syntaxes Gareth Owen <gwowen@gmail.com> - 2016-09-05 18:21 +0100
Re: Difference between these pointer syntaxes Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-11 06:47 -0700
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-18 13:00 +0100
Re: Difference between these pointer syntaxes supercat@casperkitty.com - 2016-08-17 16:48 -0700
Re: Difference between these pointer syntaxes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-18 12:05 +0100
Re: Difference between these pointer syntaxes Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-18 05:26 -0700
Re: Difference between these pointer syntaxes Richard Heathfield <rjh@cpax.org.uk> - 2016-08-18 13:43 +0100
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-18 14:05 +0100
Re: Difference between these pointer syntaxes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-19 00:27 +0100
Re: Difference between these pointer syntaxes Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-19 02:59 -0700
Re: Difference between these pointer syntaxes David Brown <david.brown@hesbynett.no> - 2016-08-19 14:28 +0200
Re: Difference between these pointer syntaxes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-19 14:25 +0100
Re: Difference between these pointer syntaxes Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-19 06:50 -0700
Re: Difference between these pointer syntaxes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-19 15:45 +0100
Re: Difference between these pointer syntaxes Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-19 08:02 -0700
Re: Difference between these pointer syntaxes supercat@casperkitty.com - 2016-08-19 08:19 -0700
Re: Difference between these pointer syntaxes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-19 17:35 +0100
Re: Difference between these pointer syntaxes supercat@casperkitty.com - 2016-08-19 10:02 -0700
Re: Difference between these pointer syntaxes Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-19 10:24 -0700
Re: Difference between these pointer syntaxes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-19 22:47 +0100
Re: Difference between these pointer syntaxes Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-19 16:08 -0700
Re: Difference between these pointer syntaxes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-20 00:32 +0100
Re: Difference between these pointer syntaxes Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-19 17:17 -0700
Re: Difference between these pointer syntaxes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-20 11:59 +0100
Re: Difference between these pointer syntaxes Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-21 04:55 -0700
Re: Difference between these pointer syntaxes supercat@casperkitty.com - 2016-08-22 07:59 -0700
Re: Difference between these pointer syntaxes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-19 17:14 +0100
O(n log n) in place median algorithm (was: Difference between these pointer syntaxes) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-19 23:38 +0100
Re: Difference between these pointer syntaxes supercat@casperkitty.com - 2016-08-19 08:09 -0700
Re: Difference between these pointer syntaxes supercat@casperkitty.com - 2016-08-18 07:27 -0700
Re: Difference between these pointer syntaxes David Brown <david.brown@hesbynett.no> - 2016-08-18 17:40 +0200
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-18 10:34 -0700
Re: Difference between these pointer syntaxes supercat@casperkitty.com - 2016-08-18 09:49 -0700
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-18 13:04 -0700
Re: Difference between these pointer syntaxes supercat@casperkitty.com - 2016-08-18 12:05 -0700
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-18 13:52 -0700
Re: Difference between these pointer syntaxes supercat@casperkitty.com - 2016-08-18 12:51 -0700
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-18 14:58 -0700
Re: Difference between these pointer syntaxes supercat@casperkitty.com - 2016-08-18 15:36 -0700
Re: Difference between these pointer syntaxes Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-18 09:14 -0700
Re: Difference between these pointer syntaxes supercat@casperkitty.com - 2016-08-18 09:37 -0700
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-17 17:58 -0700
Re: Difference between these pointer syntaxes Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-17 16:46 -0700
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-17 19:03 -0700
Re: Difference between these pointer syntaxes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-18 01:55 +0100
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-18 11:04 +0100
Re: Difference between these pointer syntaxes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-18 23:04 +0100
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-19 00:10 +0100
Re: Difference between these pointer syntaxes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-19 01:08 +0100
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-19 11:04 +0100
Re: Difference between these pointer syntaxes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-19 12:32 +0100
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-19 13:45 +0100
Re: Difference between these pointer syntaxes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-19 14:40 +0100
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-19 15:30 +0100
Re: Difference between these pointer syntaxes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-19 15:54 +0100
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-19 16:24 +0100
Re: Difference between these pointer syntaxes John Bode <jfbode1029@gmail.com> - 2016-08-17 16:04 -0700
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-18 00:41 +0100
Re: Difference between these pointer syntaxes jameskuyper@verizon.net - 2016-08-17 16:59 -0700
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-18 01:24 +0100
Re: Difference between these pointer syntaxes John Bode <jfbode1029@gmail.com> - 2016-08-18 08:30 -0700
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-18 10:49 -0700
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-18 19:20 +0100
Re: Difference between these pointer syntaxes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-18 01:39 +0100
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-18 10:47 +0100
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-18 11:03 -0700
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-18 11:32 -0700
Re: Difference between these pointer syntaxes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-19 00:28 +0100
Re: Difference between these pointer syntaxes jameskuyper@verizon.net - 2016-08-17 12:23 -0700
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-17 21:19 +0100
Re: Difference between these pointer syntaxes Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-17 03:10 -0700
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-17 09:47 -0700
Re: Difference between these pointer syntaxes supercat@casperkitty.com - 2016-08-17 08:33 -0700
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-17 10:12 -0700
Re: Difference between these pointer syntaxes jameskuyper@verizon.net - 2016-08-17 10:04 -0700
Re: Difference between these pointer syntaxes supercat@casperkitty.com - 2016-08-13 09:34 -0700
Re: Difference between these pointer syntaxes Tim Rentsch <txr@alumni.caltech.edu> - 2016-08-18 08:04 -0700
Re: Difference between these pointer syntaxes supercat@casperkitty.com - 2016-08-11 07:51 -0700
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-11 15:57 +0100
Re: Difference between these pointer syntaxes supercat@casperkitty.com - 2016-08-11 09:04 -0700
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-11 09:17 -0700
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-11 19:15 +0100
Re: Difference between these pointer syntaxes supercat@casperkitty.com - 2016-08-11 11:41 -0700
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-11 20:06 +0100
Re: Difference between these pointer syntaxes supercat@casperkitty.com - 2016-08-11 13:42 -0700
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-11 12:38 -0700
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-11 20:15 +0100
Re: Difference between these pointer syntaxes supercat@casperkitty.com - 2016-08-11 13:37 -0700
Re: Difference between these pointer syntaxes Gareth Owen <gwowen@gmail.com> - 2016-08-11 19:54 +0100
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-10 12:04 +0100
Re: Difference between these pointer syntaxes James Kuyper <jameskuyper@verizon.net> - 2016-08-10 11:12 -0400
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-10 17:27 +0100
Re: Difference between these pointer syntaxes John Bode <jfbode1029@gmail.com> - 2016-08-10 08:19 -0700
Page 16 of 20 — ← Prev page 1 … 14 15 [16] 17 18 … 20 Next page →
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-08-18 13:43 +0100 |
| Message-ID | <np4agt$a89$1@dont-email.me> |
| In reply to | #92452 |
On 18/08/16 13:26, Malcolm McLean wrote: > On Thursday, August 18, 2016 at 12:05:18 PM UTC+1, Ben Bacarisse wrote: >> Malcolm McLean <malcolm.mclean5@btinternet.com> writes: >> >> Or double mean(const double *x, int N) if you've got a compiler written >> in the last quarter of a century. You might even consider >> >> double mean(double *x, size_t n); >> > const is mainly clutter. No, it's mainly a guarantee that the object's value cannot be changed. That's a very useful guarantee. > It doesn't really add anything except the > ability to pass a const-qualified pointer, though you can argue > that it helps to document input vs output. You can indeed, and indeed it does, and that is a very useful thing to do. > size-t is very confusing. Not that confusing, surely? It's an arithmetic expression, yielding the result of subtracting t from size. But of course you meant size_t. If you used it more, that might help you to type it properly. > Are you passing the number of elements > or the size of the array in bytes? You're passing a size_t value which you've rather unhelpfully called n. > I'd expect a variable of size_t > to hold the latter. That's probably less useful than the number of elements. But it's easy to clear up the confusion by choosing good identifier names: double calc_arithmetic_mean(const double *data, size_t num_elements) or double calc_arithmetic_mean(const double *data, size_t array_size) according to the semantics of the function. I would suggest that the former choice (passing in the number of elements) is a more useful one, but it's up to you. >> >>> err = mean(&xbar, 100, array) >>> >>> the compiler won't warn and it can go horribly wrong. >> >> It will if you don't reject using const. >> > OK, so make the function median, and specify that it may reorder > the input. Now the problem can't be solved by a const. So solve it with prototypes. double calc_median(const double *data, size_t num_elems) Now, if you have an object double *xbar and you try to pass &xbar as the first argument, the compiler will complain. > It's a genuine issue, I don't see why. -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-08-18 14:05 +0100 |
| Message-ID | <np4brt$epf$1@dont-email.me> |
| In reply to | #92453 |
On 18/08/2016 13:43, Richard Heathfield wrote:
> On 18/08/16 13:26, Malcolm McLean wrote:
>> On Thursday, August 18, 2016 at 12:05:18 PM UTC+1, Ben Bacarisse wrote:
>>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>>>
>>> Or double mean(const double *x, int N) if you've got a compiler written
>>> in the last quarter of a century. You might even consider
>>>
>>> double mean(double *x, size_t n);
>>>
>> const is mainly clutter.
>
> No, it's mainly a guarantee that the object's value cannot be changed.
> That's a very useful guarantee.
Not much of a guarantee:
typedef struct _S { struct _S *prev, *next; int data;} Node;
void fn (const Node* P){
P -> prev -> next -> data = 0;
}
Oops!
Of course I could do this:
typedef struct _S { const struct _S *prev, *next; const int data;} Node;
but that has its own problems.
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-08-19 00:27 +0100 |
| Message-ID | <87a8g9r73i.fsf@bsb.me.uk> |
| In reply to | #92453 |
Richard Heathfield <rjh@cpax.org.uk> writes: > On 18/08/16 13:26, Malcolm McLean wrote: >> On Thursday, August 18, 2016 at 12:05:18 PM UTC+1, Ben Bacarisse wrote: >>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes: >>> >>> Or double mean(const double *x, int N) if you've got a compiler written >>> in the last quarter of a century. You might even consider >>> >>> double mean(double *x, size_t n); >>> >> const is mainly clutter. > > No, it's mainly a guarantee that the object's value cannot be > changed. That's a very useful guarantee. Hmm... const really applies to lvalues (which are expressions), not objects. Even when it is applied directly to an object definition it does not guarantee that the object itself won't change since that object could also be volatile. What it does is limit the lvalue expressions that can modify whatever object the expression refers to. So in const volatile int i = 42; The const means that the lavlue expression "i" can't be used to change the object called i. In the example under discussion, the const means that the lvalue expression "*x" can't be used to change whatever object it refers to, but that object could be changed via other lvalue expressions. I know you know all this. Your reply was a rough approximation made, no doubt, in some frustration at having to explain that const is not "mainly clutter". <snip> >> OK, so make the function median, and specify that it may reorder >> the input. Now the problem can't be solved by a const. > > So solve it with prototypes. > > double calc_median(const double *data, size_t num_elems) > > Now, if you have an object double *xbar and you try to pass &xbar as > the first argument, the compiler will complain. > >> It's a genuine issue, > > I don't see why. Malcolm means that the function is permitted to alter the array contents in the process of finding the median, so you can't use const. It's an odd argument. I suppose he's implying that there are so many cases where you can't use it that it hardly useful at all, but that's not been my experience. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-08-19 02:59 -0700 |
| Message-ID | <20feb7cc-77d8-4ffe-b12b-42c5b2025afb@googlegroups.com> |
| In reply to | #92486 |
On Friday, August 19, 2016 at 12:27:20 AM UTC+1, Ben Bacarisse wrote: > > Malcolm means that the function is permitted to alter the array contents > in the process of finding the median, so you can't use const. > > It's an odd argument. I suppose he's implying that there are so many > cases where you can't use it that it hardly useful at all, but that's > not been my experience. > Bart's general problem is that double *out could refer to an array or a scalar, and unlike most languages there is no syntax for distinguishing them. My view is that whilst it's real issue, it's not a very serious one, since that type of bug is unlikely to survive the first informal test. I gave inverting the parameters of mean() as an example. Ben then said that mean should take a const double * for the input anyway, and the issue disappears. That's fair enough, but it doesn't really answer Bart's point. If we make the example a reordering "median" rather than "mean", Bart's problem reappears.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-08-19 14:28 +0200 |
| Message-ID | <np6u1u$kcs$1@dont-email.me> |
| In reply to | #92492 |
On 19/08/16 11:59, Malcolm McLean wrote: > On Friday, August 19, 2016 at 12:27:20 AM UTC+1, Ben Bacarisse wrote: >> >> Malcolm means that the function is permitted to alter the array contents >> in the process of finding the median, so you can't use const. >> >> It's an odd argument. I suppose he's implying that there are so many >> cases where you can't use it that it hardly useful at all, but that's >> not been my experience. >> > Bart's general problem is that double *out could refer to an array > or a scalar, and unlike most languages there is no syntax for > distinguishing them. My view is that whilst it's real issue, it's > not a very serious one, since that type of bug is unlikely to survive > the first informal test. I gave inverting the parameters of mean() > as an example. > Ben then said that mean should take a const double * for the input > anyway, and the issue disappears. That's fair enough, but it doesn't > really answer Bart's point. If we make the example a reordering "median" > rather than "mean", Bart's problem reappears. > No, the problem does not reappear. If you are making a function that takes an array of doubles and returns its mean without changing the array, then you use a function declaration such as: double mean(const double * data, size_t noOfElms); If you want a function that does a reordering median, you write: double reorderingMedian(double * data, size_t noOfElms); If I see a function written as: double median(double * data, size_t noOfElms); I would assume that the author doesn't understand about "const", but probably meant to write "const double * data". I certainly would not expect the function to start re-ordering the data - that would be a totally different type of function, and I would expect that "feature" to be clear in the function name as well as the documentation. So there is no problem to appear or disappear. Use "const" when you are not going to change the data pointed at. And if you /are/ going to change the data, make sure it is clear in the function name.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-08-19 14:25 +0100 |
| Message-ID | <874m6gq49x.fsf@bsb.me.uk> |
| In reply to | #92496 |
David Brown <david.brown@hesbynett.no> writes: > On 19/08/16 11:59, Malcolm McLean wrote: >> On Friday, August 19, 2016 at 12:27:20 AM UTC+1, Ben Bacarisse wrote: >>> >>> Malcolm means that the function is permitted to alter the array contents >>> in the process of finding the median, so you can't use const. >>> >>> It's an odd argument. I suppose he's implying that there are so many >>> cases where you can't use it that it hardly useful at all, but that's >>> not been my experience. >>> >> Bart's general problem is that double *out could refer to an array >> or a scalar, and unlike most languages there is no syntax for >> distinguishing them. My view is that whilst it's real issue, it's >> not a very serious one, since that type of bug is unlikely to survive >> the first informal test. I gave inverting the parameters of mean() >> as an example. >> Ben then said that mean should take a const double * for the input >> anyway, and the issue disappears. That's fair enough, but it doesn't >> really answer Bart's point. If we make the example a reordering "median" >> rather than "mean", Bart's problem reappears. >> > > No, the problem does not reappear. > > If you are making a function that takes an array of doubles and returns > its mean without changing the array, then you use a function declaration > such as: > > double mean(const double * data, size_t noOfElms); > > If you want a function that does a reordering median, you write: > > double reorderingMedian(double * data, size_t noOfElms); > > > If I see a function written as: > > double median(double * data, size_t noOfElms); > > I would assume that the author doesn't understand about "const", but > probably meant to write "const double * data". I certainly would not > expect the function to start re-ordering the data - that would be a > totally different type of function, and I would expect that "feature" to > be clear in the function name as well as the documentation. > > > So there is no problem to appear or disappear. Use "const" when you are > not going to change the data pointed at. And if you /are/ going to > change the data, make sure it is clear in the function name. But the example was (if I remember correctly) a function that returns int to signal success/failure and takes a double * argument to receive the result. Then you can't use const to signal the in/out parameter distinction and avoid errors. That point is valid but it's not an argument against using const, which seems to be one of Malcolm's personal rules. You can finesse the issue by swapping the return and the success indicator (double reorderingMedian(double *data, size_t n, bool *ok);) but that's less convenient, and, prompted by the other part of this monster thread, there is also a rather non-idiomatic way to keep the argument types distinct: bool reorderingMedian(double (*data)[], size_t n, double &median); but that is also problematic in that you now need a cast to pass a conventional double * in the first position. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-08-19 06:50 -0700 |
| Message-ID | <3089ee96-fae7-4317-bb03-cfc7775d9afa@googlegroups.com> |
| In reply to | #92498 |
On Friday, August 19, 2016 at 2:26:02 PM UTC+1, Ben Bacarisse wrote: > > > If you are making a function that takes an array of doubles and returns > > its mean without changing the array, then you use a function declaration > > such as: > > > > double mean(const double * data, size_t noOfElms); > > > > If you want a function that does a reordering median, you write: > > > > double reorderingMedian(double * data, size_t noOfElms); > > > > > > If I see a function written as: > > > > double median(double * data, size_t noOfElms); > > > > I would assume that the author doesn't understand about "const", but > > probably meant to write "const double * data". I certainly would not > > expect the function to start re-ordering the data - that would be a > > totally different type of function, and I would expect that "feature" to > > be clear in the function name as well as the documentation. > > > > > > So there is no problem to appear or disappear. Use "const" when you are > > not going to change the data pointed at. And if you /are/ going to > > change the data, make sure it is clear in the function name. > > But the example was (if I remember correctly) a function that returns > int to signal success/failure and takes a double * argument to receive > the result. Then you can't use const to signal the in/out parameter > distinction and avoid errors. That point is valid but it's not an > argument against using const, which seems to be one of Malcolm's > personal rules. > const is a bit of a distraction. I dislike it, but for reasons that are not really connected to the rest of the array representation. > > You can finesse the issue by swapping the return and the success > indicator (double reorderingMedian(double *data, size_t n, bool *ok);) > but that's less convenient, and, prompted by the other part of this > monster thread, there is also a rather non-idiomatic way to keep the > argument types distinct: > Some house styles say that every function shall return an integer indicating a success or failure mode. Not something I like. But one of the libraries I am using currently is written with that convention. > > bool reorderingMedian(double (*data)[], size_t n, double &median); > > but that is also problematic in that you now need a cast to pass a > conventional double * in the first position. > It's also unconventional. David Brown is right, and it's pretty awful that median reorders data, especially if it also returns a failure mode flag. (You can write it using binary search, which has the same O(N log N) runtime as the more obvious sort version, and doesn't need extra memory). However it's quite common to see medians that do just that - the first hit on "median C source code" from Google did so.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-08-19 15:45 +0100 |
| Message-ID | <87r39kolzz.fsf@bsb.me.uk> |
| In reply to | #92500 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > On Friday, August 19, 2016 at 2:26:02 PM UTC+1, Ben Bacarisse wrote: <snip> >> bool reorderingMedian(double (*data)[], size_t n, double &median); >> >> but that is also problematic in that you now need a cast to pass a >> conventional double * in the first position. >> > It's also unconventional. Odd. You cut the text were I said the same and then you added this remark. That makes it look like I think it not unconventional. That was, I hope, just an accident. > David Brown is right, and it's pretty > awful that median reorders data, especially if it also returns > a failure mode flag. (You can write it using binary search, > which has the same O(N log N) runtime as the more obvious sort > version, and doesn't need extra memory). You can write it to have O(N) run time if you allow re-ordering. That may be worth the inconvenience of having modified the data so "pretty awful" is a bit OTT. The O(N log N) method using binary search sounds odd -- the description does not seem to match any selection algorithm I know. Can you explain what you meant? <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-08-19 08:02 -0700 |
| Message-ID | <f8b4c402-83db-4044-ba66-6472cb3b402e@googlegroups.com> |
| In reply to | #92502 |
On Friday, August 19, 2016 at 3:46:01 PM UTC+1, Ben Bacarisse wrote: > > The O(N log N) method using binary search sounds odd -- the description > does not seem to match any selection algorithm I know. Can you explain > what you meant? > Pass through the data, taking maximum and minimum. Then use (max + min)/2 as you first guess for the median. Pass through again counting elements above and below, and the nearest in both directions. If you are wrong, use (max (or min) + guess)/2 as your refined guess and repeat, doing a binary search. If you are right, the nearest rather than the guess is the answer. Since the first guess will usually be much closer to the answer than either limit, you might be able to speed it up a bit by biasing the binary search.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-08-19 08:19 -0700 |
| Message-ID | <4bc1ba2c-e879-47b5-82d1-53ec3bf47d71@googlegroups.com> |
| In reply to | #92504 |
On Friday, August 19, 2016 at 10:02:54 AM UTC-5, Malcolm McLean wrote: > Pass through the data, taking maximum and minimum. Then use (max + min)/2 as you first guess for the median. Pass through again counting elements above and below, and the nearest in both directions. If you are wrong, use (max (or min) + guess)/2 as your refined guess and repeat, doing a binary search. > If you are right, the nearest rather than the guess is the answer. That algorithm will have an O(NlgN) runtime if the values of the original are uniformly distributed (or have a bias that matches expectations). As with the quicksearch version, the worst-case time is O(N*N) though such behavior is triggered by distribution rather than permutation.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-08-19 17:35 +0100 |
| Message-ID | <87a8g8ogxh.fsf@bsb.me.uk> |
| In reply to | #92506 |
supercat@casperkitty.com writes: > On Friday, August 19, 2016 at 10:02:54 AM UTC-5, Malcolm McLean wrote: >> Pass through the data, taking maximum and minimum. Then use (max + >> min)/2 as you first guess for the median. Pass through again >> counting elements above and below, and the nearest in both >> directions. If you are wrong, use (max (or min) + guess)/2 as your >> refined guess and repeat, doing a binary search. >> If you are right, the nearest rather than the guess is the answer. > > That algorithm will have an O(NlgN) runtime if the values of the original > are uniformly distributed (or have a bias that matches expectations). As > with the quicksearch version, the worst-case time is O(N*N) though such > behavior is triggered by distribution rather than permutation. That does not match my quick analysis. Do you have an example of quadratic performance? -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-08-19 10:02 -0700 |
| Message-ID | <0c65a74b-a8e7-49af-9d59-495de7ac6bcf@googlegroups.com> |
| In reply to | #92509 |
On Friday, August 19, 2016 at 11:35:32 AM UTC-5, Ben Bacarisse wrote: > That does not match my quick analysis. Do you have an example of > quadratic performance? If numeric range is limited, that would limit the run time, though such constraints would allow a purely linear-time approach by using a histogram. Otherwise, consider what would happen with a list of 157 items: 157!, 156!, 155!, 154!, etc. down to 1!. The average of all 157 numbers is clearly greater than 157!/157 [i.e. 156!], so the first cut eliminates just one number. The average of the remaining 156 numbers is likewise greater than 155!, etc. eliminating only one number each time down to 1!.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-08-19 10:24 -0700 |
| Message-ID | <b9b6548e-1ba7-42bd-88a9-324724f4ddc0@googlegroups.com> |
| In reply to | #92509 |
On Friday, August 19, 2016 at 5:35:32 PM UTC+1, Ben Bacarisse wrote: > supercat@casperkitty.com writes: > > > On Friday, August 19, 2016 at 10:02:54 AM UTC-5, Malcolm McLean wrote: > >> Pass through the data, taking maximum and minimum. Then use (max + > >> min)/2 as you first guess for the median. Pass through again > >> counting elements above and below, and the nearest in both > >> directions. If you are wrong, use (max (or min) + guess)/2 as your > >> refined guess and repeat, doing a binary search. > >> If you are right, the nearest rather than the guess is the answer. > > > > That algorithm will have an O(NlgN) runtime if the values of the original > > are uniformly distributed (or have a bias that matches expectations). As > > with the quicksearch version, the worst-case time is O(N*N) though such > > behavior is triggered by distribution rather than permutation. > > That does not match my quick analysis. Do you have an example of > quadratic performance? > Create 2050 numbers distributed between DBL_MAX and zero, at log two position, then add -DBL_MAX, so DBL_MAX, DBL_MAX/2, DBL_MAX/4 ... DBL_MIN, 0, -DBL_MAX. Now each pass will shave off only a single value, except the first.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-08-19 22:47 +0100 |
| Message-ID | <871t1ko2hz.fsf@bsb.me.uk> |
| In reply to | #92511 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > On Friday, August 19, 2016 at 5:35:32 PM UTC+1, Ben Bacarisse wrote: >> supercat@casperkitty.com writes: >> >> > On Friday, August 19, 2016 at 10:02:54 AM UTC-5, Malcolm McLean wrote: >> >> Pass through the data, taking maximum and minimum. Then use (max + >> >> min)/2 as you first guess for the median. Pass through again >> >> counting elements above and below, and the nearest in both >> >> directions. If you are wrong, use (max (or min) + guess)/2 as your >> >> refined guess and repeat, doing a binary search. >> >> If you are right, the nearest rather than the guess is the answer. >> > >> > That algorithm will have an O(NlgN) runtime if the values of the original >> > are uniformly distributed (or have a bias that matches expectations). As >> > with the quicksearch version, the worst-case time is O(N*N) though such >> > behavior is triggered by distribution rather than permutation. >> >> That does not match my quick analysis. Do you have an example of >> quadratic performance? >> > Create 2050 numbers distributed between DBL_MAX and zero, at > log two position, then add -DBL_MAX, so DBL_MAX, DBL_MAX/2, > DBL_MAX/4 ... DBL_MIN, 0, -DBL_MAX. > > Now each pass will shave off only a single value, except the first. I thought you said the algorithm was O(n log n)? -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-08-19 16:08 -0700 |
| Message-ID | <59361355-dd91-4d4d-bcca-e81bd0c3e297@googlegroups.com> |
| In reply to | #92514 |
On Friday, August 19, 2016 at 10:47:12 PM UTC+1, Ben Bacarisse wrote: > Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > > > On Friday, August 19, 2016 at 5:35:32 PM UTC+1, Ben Bacarisse wrote: > >> supercat@casperkitty.com writes: > >> > >> > On Friday, August 19, 2016 at 10:02:54 AM UTC-5, Malcolm McLean wrote: > >> >> Pass through the data, taking maximum and minimum. Then use (max + > >> >> min)/2 as you first guess for the median. Pass through again > >> >> counting elements above and below, and the nearest in both > >> >> directions. If you are wrong, use (max (or min) + guess)/2 as your > >> >> refined guess and repeat, doing a binary search. > >> >> If you are right, the nearest rather than the guess is the answer. > >> > > >> > That algorithm will have an O(NlgN) runtime if the values of the original > >> > are uniformly distributed (or have a bias that matches expectations). As > >> > with the quicksearch version, the worst-case time is O(N*N) though such > >> > behavior is triggered by distribution rather than permutation. > >> > >> That does not match my quick analysis. Do you have an example of > >> quadratic performance? > >> > > Create 2050 numbers distributed between DBL_MAX and zero, at > > log two position, then add -DBL_MAX, so DBL_MAX, DBL_MAX/2, > > DBL_MAX/4 ... DBL_MIN, 0, -DBL_MAX. > > > > Now each pass will shave off only a single value, except the first. > > I thought you said the algorithm was O(n log n)? > > If you know that the input is likely to have a logarithmic distribution then interpolate in log space instead of using (high + low)/2. Then it goes back to O(n log n). But real distributions are unlikely to contain entries arranged over many orders of magnitude like that. And assuming 11 bits in the exponent, 2048 is the limit on the squaring term. So even worst case is 4 million or so operations, and a modern computer will hardly notice that.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-08-20 00:32 +0100 |
| Message-ID | <8760qwmj2n.fsf@bsb.me.uk> |
| In reply to | #92522 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > On Friday, August 19, 2016 at 10:47:12 PM UTC+1, Ben Bacarisse wrote: >> Malcolm McLean <malcolm.mclean5@btinternet.com> writes: >> >> > On Friday, August 19, 2016 at 5:35:32 PM UTC+1, Ben Bacarisse wrote: >> >> supercat@casperkitty.com writes: >> >> >> >> > On Friday, August 19, 2016 at 10:02:54 AM UTC-5, Malcolm McLean wrote: >> >> >> Pass through the data, taking maximum and minimum. Then use (max + >> >> >> min)/2 as you first guess for the median. Pass through again >> >> >> counting elements above and below, and the nearest in both >> >> >> directions. If you are wrong, use (max (or min) + guess)/2 as your >> >> >> refined guess and repeat, doing a binary search. >> >> >> If you are right, the nearest rather than the guess is the answer. >> >> > >> >> > That algorithm will have an O(NlgN) runtime if the values of the original >> >> > are uniformly distributed (or have a bias that matches expectations). As >> >> > with the quicksearch version, the worst-case time is O(N*N) though such >> >> > behavior is triggered by distribution rather than permutation. >> >> >> >> That does not match my quick analysis. Do you have an example of >> >> quadratic performance? >> >> >> > Create 2050 numbers distributed between DBL_MAX and zero, at >> > log two position, then add -DBL_MAX, so DBL_MAX, DBL_MAX/2, >> > DBL_MAX/4 ... DBL_MIN, 0, -DBL_MAX. >> > >> > Now each pass will shave off only a single value, except the first. >> >> I thought you said the algorithm was O(n log n)? >> >> > If you know that the input is likely to have a logarithmic distribution > then interpolate in log space instead of using (high + low)/2. > Then it goes back to O(n log n). Are you saying that, as originally sketched, the algorithm is o(n^2)? Introducing logs will alter the time complexity (and maybe even the space complexity) in ways that I don't what to get sidelined by. Do you have some source for this? It may be that it's all well explained and analysed already and I could simply read that source. I have not been able to find such a source, but then I don't even have a name for it yet. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-08-19 17:17 -0700 |
| Message-ID | <dfc69f1b-6cae-4749-a62d-41ea534f7e76@googlegroups.com> |
| In reply to | #92523 |
On Saturday, August 20, 2016 at 12:32:08 AM UTC+1, Ben Bacarisse wrote: > Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > > Are you saying that, as originally sketched, the algorithm is o(n^2)? > Introducing logs will alter the time complexity (and maybe even the > space complexity) in ways that I don't what to get sidelined by. > The median is invariant to log transformation, assuming we return the item rather than the value. So log transform your data. It's a standard statistical technique. > > Do you have some source for this? It may be that it's all well > explained and analysed already and I could simply read that source. I > have not been able to find such a source, but then I don't even have a > name for it yet. > The algorithm has been explained. As I said, it's not really optimal as for most inputs our initial guess will be close to the answer, and so the binary search spends most of its time chopping off the top of the upper bound. Data distributed at 2 times positions is an extreme case of that. But that distribution is either contrived or tiny, you're very unlikely to have more than ten or so measurements in a series 2, 4, 8 ... In C, we can't go to N > 2048 because a double won't allow it, and N = 2048 will execute in reasonable wall clock time on a normal modern machine. So unless you need to take a median of an unusual data set in the critical core of an application, there's not much motivation to optimise it, though it's a fair enough problem for an intellectual exercise.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-08-20 11:59 +0100 |
| Message-ID | <87zio7yada.fsf@bsb.me.uk> |
| In reply to | #92525 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > On Saturday, August 20, 2016 at 12:32:08 AM UTC+1, Ben Bacarisse wrote: >> Malcolm McLean <malcolm.mclean5@btinternet.com> writes: >> >> Are you saying that, as originally sketched, the algorithm is o(n^2)? >> Introducing logs will alter the time complexity (and maybe even the >> space complexity) in ways that I don't what to get sidelined by. >> > The median is invariant to log transformation, assuming we return > the item rather than the value. So log transform your data. > It's a standard statistical technique. * You also have to transform the data to make them all >0 which limits the range over which the algorithm works. * Some data might no longer be distinguishable which could result in the wrong result being returned. * To return the median, you either have to calculate very accurate logs or you need to copy the original data. Both alter the complexity analysis. In short, it's a different algorithm. I want to try to understand the complexity measures of one algorithm first. >> Do you have some source for this? It may be that it's all well >> explained and analysed already and I could simply read that source. I >> have not been able to find such a source, but then I don't even have a >> name for it yet. >> > The algorithm has been explained. Yes, but there's been some confusion about the complexity measure. A published source for the algorithm would usually include some analysis but I can't find one. I think we can definitely say o(n^2) worst case, and probably o(n log n) on average. I'm not entirely sure how best to characterise average for this sort of algorithm -- another reason to hope for a source. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-08-21 04:55 -0700 |
| Message-ID | <ff5f3b28-dfd4-42e1-a716-ac0d3b145eba@googlegroups.com> |
| In reply to | #92536 |
On Saturday, August 20, 2016 at 11:59:23 AM UTC+1, Ben Bacarisse wrote: > Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > > > The median is invariant to log transformation, assuming we return > > the item rather than the value. So log transform your data. > > It's a standard statistical technique. > > * You also have to transform the data to make them all >0 which limits > the range over which the algorithm works. > > * Some data might no longer be distinguishable which could result in the > wrong result being returned. > > * To return the median, you either have to calculate very accurate logs > or you need to copy the original data. Both alter the complexity > analysis. > > In short, it's a different algorithm. I want to try to understand the > complexity measures of one algorithm first. > The algorithm shows bad behaviour when data is very non-uniform in distribution. However in those circumstances, it's likely that you'll want to log transform it any way - most statistical tests won't work otherwise. So I'm not suggesting changing the code, just passing the log-transformed data. Generally numerical issues aren't going to be a problem for that kind of function, the log transform might not be strictly monotonic, in fact mathematically it can't be if values are very close, and that could conceivably affect the median. But only by a tiny amount. It could maybe matter in few circumstances. But normally values are measured to only about three significant figures anyway, and a measure like the median is taken because it is understood that there is sampling error. > > Yes, but there's been some confusion about the complexity measure. A > published source for the algorithm would usually include some analysis > but I can't find one. I think we can definitely say o(n^2) worst case, > and probably o(n log n) on average. I'm not entirely sure how best to > characterise average for this sort of algorithm -- another reason to > hope for a source. > For the common situation of half-Gaussian or Gaussian data, it's non-optimal, as the initial guess will be fairly close to the median, then you will spend a few passes shaving off the extreme values. It might be worth gathering a bit more data during the first pass, e.g. mean and standard deviation. I'm not quite sure what the relation between mean, sd and median is, clearly the median is unlikely to go more than a fraction of a standard deviation from the mean, but I don't know the hard limits, given N, the range, mean, and standard deviation.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-08-22 07:59 -0700 |
| Message-ID | <cb6ae21b-4aa7-414f-b424-b5d5c9bf368a@googlegroups.com> |
| In reply to | #92562 |
On Sunday, August 21, 2016 at 6:56:10 AM UTC-5, Malcolm McLean wrote: > The algorithm shows bad behaviour when data is very non-uniform in > distribution. However in those circumstances, it's likely that you'll > want to log transform it any way - most statistical tests won't work > otherwise. So I'm not suggesting changing the code, just passing the > log-transformed data. Sometimes median is used precisely to minimize the effects of weirdly- distributed data. Most big-O specs assume a fully-arbitrary range of inputs, since many algorithms could otherwise be reduced to a purely- linear form (e.g. a radix sort where the number of passes depends upon number of bits in each item to be sorted, rather than the number of items). Making assumptions about the data feeding a median would go against that convention. If the number of significant bits were unlimited, one could replace each item in the aforementioned sequence with 1+(1/n); that would put all values within the range 1..2, but the algorithm would run poorly even with that change. I don't think there's any kind of conditioning that could be done on infinite-precision data that would make the algorithm immune to O(N^2) worst-case behavior. The algorithm is practical with finite floating-point precision, but as with radix sort, it is the limit on the number of possible values that guards against worst-case behavior.
[toc] | [prev] | [next] | [standalone]
Page 16 of 20 — ← Prev page 1 … 14 15 [16] 17 18 … 20 Next page →
Back to top | Article view | comp.lang.c
csiph-web