Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #97546 > unrolled thread
| Started by | fir <profesor.fir@gmail.com> |
|---|---|
| First post | 2016-11-26 12:49 -0800 |
| Last post | 2016-12-01 12:33 +0800 |
| Articles | 20 on this page of 567 — 30 participants |
Back to article view | Back to comp.lang.c
absence of max fir <profesor.fir@gmail.com> - 2016-11-26 12:49 -0800
absence of max "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-11-26 15:34 -0800
Re: absence of max BartC <bc@freeuk.com> - 2016-11-27 00:21 +0000
Re: absence of max "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-11-27 04:25 -0800
Re: absence of max Robert Spanjaard <spamtrap@arumes.com> - 2016-11-27 13:54 +0100
Re: absence of max BartC <bc@freeuk.com> - 2016-11-27 13:54 +0000
Re: absence of max supercat@casperkitty.com - 2016-11-27 07:33 -0800
Re: absence of max Melzzzzz <mel@zzzzz.com> - 2016-11-27 14:06 +0100
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-11-27 17:47 +0100
Re: absence of max "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-11-28 07:13 -0800
Re: absence of max BartC <bc@freeuk.com> - 2016-11-28 15:35 +0000
Re: absence of max "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-11-28 07:48 -0800
Re: absence of max "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-11-28 07:53 -0800
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-11-29 00:14 +0000
Re: absence of max BartC <bc@freeuk.com> - 2016-11-29 00:36 +0000
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-11-29 02:03 +0000
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-11-28 23:23 -0800
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-11-28 21:05 -0800
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-11-28 16:53 +0100
Re: absence of max "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-11-28 08:07 -0800
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-11-29 10:37 +0100
Re: absence of max supercat@casperkitty.com - 2016-11-28 08:26 -0800
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-11-29 10:42 +0100
Re: absence of max supercat@casperkitty.com - 2016-11-28 08:16 -0800
Re: absence of max "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-11-28 09:31 -0800
Re: absence of max supercat@casperkitty.com - 2016-11-28 10:38 -0800
Re: absence of max "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-11-28 10:59 -0800
Re: absence of max supercat@casperkitty.com - 2016-11-28 12:09 -0800
Re: absence of max "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-11-28 12:46 -0800
Re: absence of max supercat@casperkitty.com - 2016-11-28 13:05 -0800
Re: absence of max "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-11-28 13:50 -0800
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-11-29 10:52 +0100
Re: absence of max "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-11-29 05:44 -0800
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-11-29 15:12 +0100
Re: absence of max "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-11-29 06:54 -0800
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-11-30 10:37 +0100
Re: absence of max "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-11-30 03:07 -0800
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-11-30 13:28 +0100
Re: absence of max "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-11-30 05:12 -0800
Re: absence of max BartC <bc@freeuk.com> - 2016-11-28 18:57 +0000
Re: absence of max supercat@casperkitty.com - 2016-11-28 11:33 -0800
Re: absence of max Richard Heathfield <rjh@cpax.org.uk> - 2016-11-28 20:09 +0000
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-11-29 10:55 +0100
Re: absence of max Richard Heathfield <rjh@cpax.org.uk> - 2016-11-29 10:06 +0000
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-11-29 11:18 +0100
Re: absence of max Richard Heathfield <rjh@cpax.org.uk> - 2016-11-29 10:28 +0000
Re: absence of max BartC <bc@freeuk.com> - 2016-11-29 10:49 +0000
Re: absence of max Richard Heathfield <rjh@cpax.org.uk> - 2016-11-29 10:51 +0000
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-11-29 11:40 +0000
Re: absence of max BartC <bc@freeuk.com> - 2016-11-29 12:17 +0000
Re: absence of max Richard Heathfield <rjh@cpax.org.uk> - 2016-11-29 15:18 +0000
Re: absence of max Gareth Owen <gwowen@gmail.com> - 2016-11-29 18:30 +0000
Re: absence of max Richard Heathfield <rjh@cpax.org.uk> - 2016-11-29 18:49 +0000
Re: absence of max "James R. Kuyper" <jameskuyper@verizon.net> - 2016-11-29 14:09 -0500
Re: absence of max supercat@casperkitty.com - 2016-11-29 10:56 -0800
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-11-29 11:29 -0800
Re: absence of max BartC <bc@freeuk.com> - 2016-11-29 20:27 +0000
Re: absence of max Richard Heathfield <rjh@cpax.org.uk> - 2016-11-29 20:31 +0000
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-11-30 10:45 +0100
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-11-29 12:54 -0800
Re: absence of max "James R. Kuyper" <jameskuyper@verizon.net> - 2016-11-29 16:21 -0500
Re: absence of max BartC <bc@freeuk.com> - 2016-11-29 21:47 +0000
Re: absence of max BartC <bc@freeuk.com> - 2016-11-29 21:30 +0000
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-11-29 14:12 -0800
Re: absence of max BartC <bc@freeuk.com> - 2016-11-29 22:27 +0000
Re: absence of max Richard Heathfield <rjh@cpax.org.uk> - 2016-11-29 22:33 +0000
Re: absence of max jameskuyper@verizon.net - 2016-11-29 14:52 -0800
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-11-29 15:43 -0800
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-11-29 23:51 +0000
Re: absence of max BartC <bc@freeuk.com> - 2016-11-30 00:51 +0000
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-11-30 02:08 +0000
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-11-29 18:10 -0800
Re: absence of max "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-11-28 12:29 -0800
Re: absence of max BartC <bc@freeuk.com> - 2016-11-28 21:30 +0000
Re: absence of max "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-11-28 13:47 -0800
Re: absence of max supercat@casperkitty.com - 2016-11-28 14:59 -0800
Re: absence of max "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-11-28 15:13 -0800
Re: absence of max BartC <bc@freeuk.com> - 2016-11-29 00:12 +0000
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-11-29 01:11 +0000
Re: absence of max "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-11-28 18:01 -0800
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-11-29 02:19 +0000
Re: absence of max supercat@casperkitty.com - 2016-11-29 13:26 -0800
Re: absence of max "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-11-29 17:09 -0800
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-11-29 00:01 +0000
Re: absence of max BartC <bc@freeuk.com> - 2016-11-29 00:29 +0000
Re: absence of max supercat@casperkitty.com - 2016-11-28 17:02 -0800
Re: absence of max BartC <bc@freeuk.com> - 2016-11-29 01:21 +0000
Re: absence of max supercat@casperkitty.com - 2016-11-28 17:53 -0800
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-11-28 23:11 -0800
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-11-29 02:12 +0000
Re: absence of max BartC <bc@freeuk.com> - 2016-11-29 11:17 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-11-29 09:46 -0500
Re: absence of max BartC <bc@freeuk.com> - 2016-11-29 15:45 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-11-29 17:04 -0500
Re: absence of max supercat@casperkitty.com - 2016-11-29 07:21 -0800
Re: absence of max BartC <bc@freeuk.com> - 2016-11-29 15:50 +0000
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-11-30 00:19 +0000
Re: absence of max BartC <bc@freeuk.com> - 2016-11-30 00:43 +0000
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-11-30 01:51 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-11-29 22:26 -0500
Re: absence of max BartC <bc@freeuk.com> - 2016-11-30 11:25 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-11-30 09:07 -0500
Re: absence of max BartC <bc@freeuk.com> - 2016-11-30 14:22 +0000
Re: absence of max supercat@casperkitty.com - 2016-11-30 09:03 -0800
Re: absence of max BartC <bc@freeuk.com> - 2016-11-30 23:38 +0000
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-11-30 15:49 -0800
Re: absence of max BartC <bc@freeuk.com> - 2016-12-01 00:10 +0000
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-11-30 17:22 -0800
Re: absence of max BartC <bc@freeuk.com> - 2016-12-01 01:40 +0000
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-11-30 18:03 -0800
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-11-30 17:25 -0500
Re: absence of max BartC <bc@freeuk.com> - 2016-11-30 23:29 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-11-30 23:55 -0500
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-12-01 10:05 +0100
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-01 11:20 +0000
Re: absence of max BartC <bc@freeuk.com> - 2016-12-01 11:41 +0000
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-12-01 13:48 +0100
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-12-01 10:43 -0800
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-01 21:23 +0000
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-12-01 14:41 -0800
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-12-02 09:39 +0100
Re: absence of max BartC <bc@freeuk.com> - 2016-12-01 11:35 +0000
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-12-01 14:51 +0100
Re: absence of max BartC <bc@freeuk.com> - 2016-12-01 15:05 +0000
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-12-01 10:49 -0800
Re: absence of max BartC <bc@freeuk.com> - 2016-12-01 20:48 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-01 16:51 -0500
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-01 01:18 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-11-30 23:57 -0500
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-01 11:38 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-01 13:28 -0500
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-02 00:06 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-01 20:02 -0500
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-02 02:22 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-01 21:42 -0500
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-03 01:56 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-02 21:25 -0500
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-03 02:33 +0000
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-12-03 15:20 +0100
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-03 15:40 -0500
Re: absence of max Ian Collins <ian-news@hotmail.com> - 2016-12-02 21:57 +1300
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-02 10:46 -0500
Re: absence of max asetofsymbols@gmail.com - 2016-11-30 06:36 -0800
Re: absence of max BartC <bc@freeuk.com> - 2016-11-30 16:41 +0000
Re: absence of max Ian Collins <ian-news@hotmail.com> - 2016-11-30 20:50 +1300
Re: absence of max BartC <bc@freeuk.com> - 2016-11-30 11:11 +0000
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-11-30 12:00 +0000
Re: absence of max James Kuyper <jameskuyper@verizon.net> - 2016-11-30 11:32 -0500
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-11-30 19:25 +0000
Re: absence of max BartC <bc@freeuk.com> - 2016-11-30 20:45 +0000
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-11-30 12:52 -0800
Re: absence of max supercat@casperkitty.com - 2016-11-30 14:17 -0800
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-12-01 10:14 +0100
Re: absence of max supercat@casperkitty.com - 2016-12-01 07:37 -0800
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-12-01 17:05 +0100
Re: absence of max supercat@casperkitty.com - 2016-12-01 10:06 -0800
Re: absence of max James Kuyper <jameskuyper@verizon.net> - 2016-12-01 13:53 -0500
Re: absence of max supercat@casperkitty.com - 2016-12-01 12:22 -0800
Re: absence of max jameskuyper@verizon.net - 2016-12-01 19:02 -0800
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-12-02 10:05 +0100
Re: absence of max "James R. Kuyper" <jameskuyper@verizon.net> - 2016-12-02 11:01 -0500
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-12-02 17:28 +0100
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-01 21:13 +0000
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-12-01 10:53 -0800
Re: absence of max supercat@casperkitty.com - 2016-12-01 11:51 -0800
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-12-01 12:52 -0800
Re: absence of max supercat@casperkitty.com - 2016-12-01 14:28 -0800
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-12-01 14:48 -0800
Re: absence of max supercat@casperkitty.com - 2016-12-01 15:00 -0800
Re: absence of max jameskuyper@verizon.net - 2016-12-01 19:28 -0800
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-02 10:30 +0000
Re: absence of max supercat@casperkitty.com - 2016-12-02 07:24 -0800
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-02 10:50 -0500
Re: absence of max supercat@casperkitty.com - 2016-12-02 09:39 -0800
Re: absence of max jameskuyper@verizon.net - 2016-12-02 10:17 -0800
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-12-02 11:46 -0800
Re: absence of max "James R. Kuyper" <jameskuyper@verizon.net> - 2016-12-02 15:02 -0500
Re: absence of max supercat@casperkitty.com - 2016-12-02 11:58 -0800
Re: absence of max jameskuyper@verizon.net - 2016-12-02 13:25 -0800
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-02 15:31 -0500
Re: absence of max supercat@casperkitty.com - 2016-12-02 13:34 -0800
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-02 19:32 -0500
Re: absence of max BartC <bc@freeuk.com> - 2016-12-03 01:11 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-02 20:48 -0500
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-03 02:11 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-02 21:27 -0500
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-03 02:50 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-02 22:45 -0500
Re: absence of max BartC <bc@freeuk.com> - 2016-12-03 11:07 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-03 15:46 -0500
Re: absence of max jameskuyper@verizon.net - 2016-12-03 13:46 -0800
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-03 23:29 +0000
Re: absence of max "James R. Kuyper" <jameskuyper@verizon.net> - 2016-12-03 18:42 -0500
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-03 23:59 +0000
Re: absence of max Tim Rentsch <txr@alumni.caltech.edu> - 2016-12-10 08:31 -0800
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-12-10 13:51 -0800
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-10 22:08 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-03 20:19 -0500
Re: absence of max BartC <bc@freeuk.com> - 2016-12-04 01:28 +0000
Re: absence of max Ian Collins <ian-news@hotmail.com> - 2016-12-04 14:34 +1300
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-05 00:02 +0000
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-12-05 10:34 +0100
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-05 08:38 -0500
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-12-05 15:52 +0100
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-05 16:03 -0500
Re: absence of max jameskuyper@verizon.net - 2016-12-03 19:19 -0800
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-04 11:26 -0500
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-03 11:33 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-03 15:48 -0500
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-04 00:59 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-03 20:23 -0500
Re: absence of max "James R. Kuyper" <jameskuyper@verizon.net> - 2016-12-03 10:32 -0500
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-12-03 17:15 +0100
Re: absence of max jameskuyper@verizon.net - 2016-12-03 08:33 -0800
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-12-03 11:08 -0800
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-03 21:31 +0000
Re: absence of max supercat@casperkitty.com - 2016-12-04 08:40 -0800
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-04 19:39 -0500
Re: absence of max supercat@casperkitty.com - 2016-12-05 07:15 -0800
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-05 16:09 -0500
Re: absence of max supercat@casperkitty.com - 2016-12-05 13:38 -0800
Re: absence of max jameskuyper@verizon.net - 2016-12-05 14:12 -0800
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-05 22:21 -0500
Re: absence of max jameskuyper@verizon.net - 2016-12-05 22:05 -0800
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-06 10:46 -0500
Re: absence of max jameskuyper@verizon.net - 2016-12-06 09:45 -0800
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-06 13:25 -0500
Re: absence of max jameskuyper@verizon.net - 2016-12-06 10:33 -0800
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-06 16:25 -0500
Re: absence of max jameskuyper@verizon.net - 2016-12-06 15:10 -0800
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-06 20:48 -0500
Re: absence of max jameskuyper@verizon.net - 2016-12-07 14:43 -0800
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-08 09:26 -0500
Re: absence of max jameskuyper@verizon.net - 2016-12-08 11:32 -0800
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-08 21:56 -0500
Re: absence of max jameskuyper@verizon.net - 2016-12-08 20:28 -0800
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-09 10:10 -0500
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-08 21:17 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-08 22:01 -0500
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-09 20:00 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-09 22:51 -0500
Re: absence of max cross@spitfire.i.gajendra.net (Dan Cross) - 2016-12-10 04:44 +0000
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-05 22:49 +0000
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-12-05 15:24 -0800
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-05 22:25 -0500
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-05 22:24 -0500
Re: absence of max jameskuyper@verizon.net - 2016-12-05 22:47 -0800
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-06 10:51 -0500
Re: absence of max jameskuyper@verizon.net - 2016-12-06 10:25 -0800
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-06 16:26 -0500
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-07 02:09 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-07 09:30 -0500
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-08 01:44 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-08 09:29 -0500
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-08 21:54 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-08 22:05 -0500
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-12-09 11:39 +0100
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-09 10:16 -0500
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-12-09 16:45 +0100
Re: absence of max Robert Spanjaard <spamtrap@arumes.com> - 2016-12-09 21:07 +0100
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-09 22:58 -0500
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-12-10 17:49 +0100
Re: absence of max "James R. Kuyper" <jameskuyper@verizon.net> - 2016-12-09 16:46 -0500
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-09 22:56 -0500
Re: absence of max Robert Spanjaard <spamtrap@arumes.com> - 2016-12-10 14:04 +0100
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-10 08:45 -0500
Re: absence of max Robert Spanjaard <spamtrap@arumes.com> - 2016-12-10 14:54 +0100
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-11 15:40 -0500
Re: absence of max Robert Spanjaard <spamtrap@arumes.com> - 2016-12-11 23:13 +0100
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-11 17:59 -0500
Re: absence of max Robert Spanjaard <spamtrap@arumes.com> - 2016-12-12 18:13 +0100
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-16 16:02 -0500
Re: absence of max Robert Spanjaard <spamtrap@arumes.com> - 2016-12-16 22:47 +0100
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-16 22:38 -0500
Re: absence of max Robert Spanjaard <spamtrap@arumes.com> - 2016-12-17 14:43 +0100
Re: absence of max BartC <bc@freeuk.com> - 2016-12-17 13:52 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-17 10:00 -0500
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-17 09:58 -0500
Re: absence of max Robert Spanjaard <spamtrap@arumes.com> - 2016-12-17 16:39 +0100
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-17 22:48 -0500
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-12-18 16:51 +0100
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-19 11:54 -0500
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-12-19 21:24 +0100
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-19 17:38 -0500
Re: absence of max Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-19 15:11 -0800
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-19 19:12 -0500
Re: absence of max Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-19 17:23 -0800
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-19 21:41 -0500
Re: absence of max supercat@casperkitty.com - 2016-12-17 09:23 -0800
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-17 22:49 -0500
Re: absence of max supercat@casperkitty.com - 2016-12-18 08:26 -0800
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-19 11:56 -0500
Re: absence of max Robert Spanjaard <spamtrap@arumes.com> - 2016-12-19 19:19 +0100
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-19 17:40 -0500
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-12-10 18:03 +0100
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-11 15:44 -0500
Re: absence of max Robert Wessel <robertwessel2@yahoo.com> - 2016-12-10 01:19 -0600
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-09 21:52 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-09 23:02 -0500
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-10 12:59 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-11 15:52 -0500
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-12 03:18 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-11 22:29 -0500
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-12 04:12 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-12 09:44 -0500
Re: absence of max supercat@casperkitty.com - 2016-12-06 06:10 -0800
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-06 10:58 -0500
Re: absence of max supercat@casperkitty.com - 2016-12-06 10:21 -0800
Re: absence of max supercat@casperkitty.com - 2016-12-06 10:25 -0800
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-06 16:28 -0500
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-07 02:48 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-07 09:34 -0500
Re: absence of max supercat@casperkitty.com - 2016-12-07 06:58 -0800
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-07 15:15 -0500
Re: absence of max supercat@casperkitty.com - 2016-12-07 12:30 -0800
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-07 16:25 -0500
Re: absence of max supercat@casperkitty.com - 2016-12-07 13:46 -0800
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-12-07 13:53 -0800
Re: absence of max supercat@casperkitty.com - 2016-12-07 14:03 -0800
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-12-07 14:50 -0800
Re: absence of max Tim Rentsch <txr@alumni.caltech.edu> - 2016-12-10 07:46 -0800
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-12-10 13:44 -0800
Re: absence of max Tim Rentsch <txr@alumni.caltech.edu> - 2016-12-14 22:12 -0800
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-07 17:00 -0500
Re: absence of max supercat@casperkitty.com - 2016-12-07 14:08 -0800
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-07 17:28 -0500
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-07 17:29 -0500
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-12-07 14:49 -0800
Re: absence of max supercat@casperkitty.com - 2016-12-07 16:24 -0800
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-12-07 17:04 -0800
Re: absence of max Tim Rentsch <txr@alumni.caltech.edu> - 2016-12-10 07:29 -0800
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-12-10 13:37 -0800
Re: absence of max me <crisdunbar@gmail.com> - 2016-12-07 14:25 -0800
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-08 02:19 +0000
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-08 02:07 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-08 09:36 -0500
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-12-08 16:22 +0100
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-08 10:52 -0500
Re: absence of max supercat@casperkitty.com - 2016-12-08 08:11 -0800
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-08 22:08 -0500
Re: absence of max jameskuyper@verizon.net - 2016-12-08 12:50 -0800
Re: absence of max Ian Collins <ian-news@hotmail.com> - 2016-12-09 10:14 +1300
Re: absence of max Melzzzzz <mel@zzzzz.com> - 2016-12-08 22:17 +0100
Re: absence of max Ian Collins <ian-news@hotmail.com> - 2016-12-09 10:21 +1300
Re: absence of max Melzzzzz <mel@zzzzz.com> - 2016-12-08 22:24 +0100
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-12-09 13:06 +0100
Re: absence of max Robert Spanjaard <spamtrap@arumes.com> - 2016-12-09 21:15 +0100
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-09 23:05 -0500
Re: absence of max Robert Wessel <robertwessel2@yahoo.com> - 2016-12-10 03:22 -0600
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-12-10 15:12 +0100
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-11 15:57 -0500
Re: absence of max Robert Wessel <robertwessel2@yahoo.com> - 2016-12-12 00:13 -0600
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-12 09:48 -0500
Re: absence of max Robert Spanjaard <spamtrap@arumes.com> - 2016-12-10 14:11 +0100
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-11 15:59 -0500
Re: absence of max Robert Spanjaard <spamtrap@arumes.com> - 2016-12-11 23:18 +0100
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-11 17:59 -0500
Re: absence of max Robert Spanjaard <spamtrap@arumes.com> - 2016-12-12 18:18 +0100
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-16 16:04 -0500
Re: absence of max Robert Spanjaard <spamtrap@arumes.com> - 2016-12-16 22:48 +0100
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-16 22:39 -0500
Re: absence of max Robert Spanjaard <spamtrap@arumes.com> - 2016-12-17 14:45 +0100
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-17 10:01 -0500
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-12-17 11:27 -0800
People who confuse and jumble up the difference between past, present, and future (Was: absence of max) gazelle@shell.xmission.com (Kenny McCormack) - 2016-12-17 20:07 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-09 10:17 -0500
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-08 22:17 -0500
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-08 22:15 -0500
Re: absence of max Richard Heathfield <rjh@cpax.org.uk> - 2016-12-09 08:40 +0000
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-12-09 13:19 +0100
Re: absence of max Richard Heathfield <rjh@cpax.org.uk> - 2016-12-09 12:29 +0000
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-12-09 14:34 +0100
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-09 10:24 -0500
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-12-09 16:58 +0100
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-09 23:09 -0500
Re: absence of max Ian Collins <ian-news@hotmail.com> - 2016-12-11 20:56 +1300
Re: absence of max "James R. Kuyper" <jameskuyper@verizon.net> - 2016-12-09 16:52 -0500
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-09 13:35 +0000
Re: absence of max Richard Heathfield <rjh@cpax.org.uk> - 2016-12-09 13:42 +0000
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-09 13:54 +0000
Re: absence of max Tim Rentsch <txr@alumni.caltech.edu> - 2016-12-10 07:54 -0800
Re: absence of max Richard Heathfield <rjh@cpax.org.uk> - 2016-12-11 16:14 +0000
Re: absence of max Gareth Owen <gwowen@gmail.com> - 2016-12-11 18:11 +0000
Re: absence of max Tim Rentsch <txr@alumni.caltech.edu> - 2016-12-14 21:08 -0800
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-09 10:25 -0500
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-09 10:18 -0500
Re: absence of max Richard Heathfield <rjh@cpax.org.uk> - 2016-12-09 15:55 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-09 23:11 -0500
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-09 10:21 -0500
Re: absence of max Robert Wessel <robertwessel2@yahoo.com> - 2016-12-10 01:48 -0600
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-12-09 13:02 +0100
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-09 10:39 -0500
Re: absence of max cross@spitfire.i.gajendra.net (Dan Cross) - 2016-12-10 04:37 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-10 00:13 -0500
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-08 22:22 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-08 22:19 -0500
Re: absence of max jameskuyper@verizon.net - 2016-12-07 19:40 -0800
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-08 09:38 -0500
Re: absence of max supercat@casperkitty.com - 2016-12-08 07:52 -0800
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-08 19:37 +0000
Re: absence of max supercat@casperkitty.com - 2016-12-08 14:46 -0800
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-12-08 15:46 -0800
Re: absence of max Tim Rentsch <txr@alumni.caltech.edu> - 2016-12-13 13:04 -0800
Re: absence of max supercat@casperkitty.com - 2016-12-13 13:38 -0800
Re: absence of max Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-13 14:07 -0800
Re: absence of max Richard Heathfield <rjh@cpax.org.uk> - 2016-12-13 22:51 +0000
Re: absence of max supercat@casperkitty.com - 2016-12-14 08:17 -0800
Re: absence of max Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-14 11:49 -0800
Re: absence of max supercat@casperkitty.com - 2016-12-14 16:53 -0800
Re: absence of max Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-15 05:14 -0800
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-12-15 15:02 +0100
Re: absence of max supercat@casperkitty.com - 2016-12-15 08:54 -0800
Re: absence of max raltbos@xs4all.nl (Richard Bos) - 2016-12-15 19:55 +0000
Re: absence of max Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-15 13:48 -0800
Re: absence of max supercat@casperkitty.com - 2016-12-15 14:20 -0800
Re: absence of max Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-15 15:32 -0800
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-12-15 23:44 +0100
Re: absence of max Gareth Owen <gwowen@gmail.com> - 2016-12-16 07:00 +0000
Re: absence of max Richard Heathfield <rjh@cpax.org.uk> - 2016-12-16 08:21 +0000
Re: absence of max Gareth Owen <gwowen@gmail.com> - 2016-12-16 21:10 +0000
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-12-16 13:24 -0800
Re: absence of max "D. Aaron Sawyer" <aaron@110.net> - 2016-12-16 18:51 -0400
Re: absence of max raltbos@xs4all.nl (Richard Bos) - 2016-12-20 09:03 +0000
Re: absence of max Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-20 02:21 -0800
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-12-14 19:05 +0100
Re: absence of max Tim Rentsch <txr@alumni.caltech.edu> - 2016-12-14 22:46 -0800
Re: absence of max supercat@casperkitty.com - 2016-12-08 15:58 -0800
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-09 00:18 +0000
Re: absence of max supercat@casperkitty.com - 2016-12-09 07:25 -0800
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-12-09 11:29 -0800
Re: absence of max Tim Rentsch <txr@alumni.caltech.edu> - 2016-12-10 09:07 -0800
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-12-10 14:20 -0800
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-09 21:31 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-09 23:15 -0500
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-10 12:15 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-11 16:04 -0500
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-08 22:27 -0500
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-09 22:11 +0000
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-12-09 15:45 -0800
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-09 23:21 -0500
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-09 23:19 -0500
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-10 12:11 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-11 16:04 -0500
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-12 03:15 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-11 22:31 -0500
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-12 04:14 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-12 09:50 -0500
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-12 23:18 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-16 16:05 -0500
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-17 02:58 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-16 22:40 -0500
Re: absence of max Robert Spanjaard <spamtrap@arumes.com> - 2016-12-12 18:20 +0100
Re: absence of max Richard Heathfield <rjh@cpax.org.uk> - 2016-12-12 17:29 +0000
Re: absence of max Robert Spanjaard <spamtrap@arumes.com> - 2016-12-12 18:53 +0100
Re: absence of max Richard Heathfield <rjh@cpax.org.uk> - 2016-12-12 17:58 +0000
Re: absence of max cross@spitfire.i.gajendra.net (Dan Cross) - 2016-12-12 19:11 +0000
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-12-13 10:31 +0100
Re: absence of max Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-12 15:38 -0800
Re: absence of max raltbos@xs4all.nl (Richard Bos) - 2016-12-15 12:08 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-16 16:06 -0500
Re: absence of max Robert Spanjaard <spamtrap@arumes.com> - 2016-12-16 22:49 +0100
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-16 22:44 -0500
Re: absence of max Robert Spanjaard <spamtrap@arumes.com> - 2016-12-17 14:47 +0100
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-17 10:04 -0500
Re: absence of max Robert Spanjaard <spamtrap@arumes.com> - 2016-12-17 16:45 +0100
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-17 22:51 -0500
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-17 13:52 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-17 22:51 -0500
Re: absence of max Parity Error <kgf@quiscurat.net> - 2016-12-18 09:17 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-08 22:23 -0500
Re: absence of max jameskuyper@verizon.net - 2016-12-08 12:23 -0800
Re: absence of max Gareth Owen <gwowen@gmail.com> - 2016-12-08 20:45 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-08 22:32 -0500
Re: absence of max Richard Heathfield <rjh@cpax.org.uk> - 2016-12-09 08:42 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-09 10:40 -0500
Re: absence of max Richard Heathfield <rjh@cpax.org.uk> - 2016-12-09 16:10 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-09 23:33 -0500
Re: absence of max Richard Heathfield <rjh@cpax.org.uk> - 2016-12-11 15:02 +0000
Re: absence of max "James R. Kuyper" <jameskuyper@verizon.net> - 2016-12-11 13:01 -0500
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-11 16:11 -0500
Re: absence of max Richard Heathfield <rjh@cpax.org.uk> - 2016-12-11 23:11 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-11 18:59 -0500
Re: absence of max Richard Heathfield <rjh@cpax.org.uk> - 2016-12-12 00:09 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-11 20:56 -0500
Re: absence of max Richard Heathfield <rjh@cpax.org.uk> - 2016-12-12 08:04 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-12 09:50 -0500
Re: absence of max jameskuyper@verizon.net - 2016-12-11 16:18 -0800
Re: absence of max "James R. Kuyper" <jameskuyper@verizon.net> - 2016-12-11 19:38 -0500
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-11 21:04 -0500
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-12 03:35 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-12 09:52 -0500
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-12 23:22 +0000
Re: absence of max Ian Collins <ian-news@hotmail.com> - 2016-12-12 17:35 +1300
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-12 09:54 -0500
Re: absence of max Richard Heathfield <rjh@cpax.org.uk> - 2016-12-12 08:17 +0000
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-12 13:01 +0000
Re: absence of max Richard Heathfield <rjh@cpax.org.uk> - 2016-12-12 13:16 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-12 10:05 -0500
Re: absence of max Richard Heathfield <rjh@cpax.org.uk> - 2016-12-12 15:21 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-16 16:09 -0500
Re: absence of max jameskuyper@verizon.net - 2016-12-12 13:12 -0800
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-12 03:01 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-11 22:03 -0500
Re: absence of max "James R. Kuyper" <jameskuyper@verizon.net> - 2016-12-12 12:58 -0500
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-16 16:11 -0500
Re: absence of max Robert Spanjaard <spamtrap@arumes.com> - 2016-12-16 22:53 +0100
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-16 22:46 -0500
Re: absence of max Robert Spanjaard <spamtrap@arumes.com> - 2016-12-17 14:49 +0100
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-17 10:07 -0500
Re: absence of max Robert Spanjaard <spamtrap@arumes.com> - 2016-12-17 16:47 +0100
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-17 22:53 -0500
Re: absence of max Parity Error <kgf@quiscurat.net> - 2016-12-18 09:11 +0000
Re: absence of max Robert Spanjaard <spamtrap@arumes.com> - 2016-12-12 18:32 +0100
Re: absence of max "James R. Kuyper" <jameskuyper@verizon.net> - 2016-12-12 13:26 -0500
Re: absence of max Robert Spanjaard <spamtrap@arumes.com> - 2016-12-12 19:39 +0100
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-12-12 11:31 -0800
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-11 16:07 -0500
Re: absence of max Richard Heathfield <rjh@cpax.org.uk> - 2016-12-11 23:10 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-11 19:01 -0500
Re: absence of max Richard Heathfield <rjh@cpax.org.uk> - 2016-12-12 00:11 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-11 21:06 -0500
Re: absence of max Richard Heathfield <rjh@cpax.org.uk> - 2016-12-12 08:19 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-12 10:07 -0500
Re: absence of max Richard Heathfield <rjh@cpax.org.uk> - 2016-12-12 15:22 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-16 16:13 -0500
Re: absence of max BartC <bc@freeuk.com> - 2016-12-12 15:38 +0000
Re: absence of max jameskuyper@verizon.net - 2016-12-02 08:54 -0800
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-02 17:20 +0000
Re: absence of max supercat@casperkitty.com - 2016-12-02 07:35 -0800
Re: absence of max jameskuyper@verizon.net - 2016-12-02 09:52 -0800
Re: absence of max supercat@casperkitty.com - 2016-12-02 10:44 -0800
Re: absence of max James Kuyper <jameskuyper@verizon.net> - 2016-11-30 16:52 -0500
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-11-30 08:31 -0800
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-11-28 23:15 -0800
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-11-29 10:49 +0100
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-11-27 17:35 +0100
Re: absence of max supercat@casperkitty.com - 2016-11-27 09:39 -0800
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-11-27 20:35 +0100
Re: absence of max BartC <bc@freeuk.com> - 2016-11-27 20:10 +0000
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-11-27 22:07 +0100
Re: absence of max BartC <bc@freeuk.com> - 2016-11-27 22:55 +0000
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-11-28 12:46 +0100
Re: absence of max BartC <bc@freeuk.com> - 2016-11-28 13:16 +0000
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-11-28 14:52 +0100
Re: absence of max jadill33@gmail.com - 2016-11-28 09:41 -0800
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-11-29 11:04 +0100
Re: absence of max BartC <bc@freeuk.com> - 2016-11-27 18:02 +0000
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-11-27 20:52 +0100
Re: absence of max BartC <bc@freeuk.com> - 2016-11-27 20:31 +0000
Re: absence of max BartC <bc@freeuk.com> - 2016-11-27 22:09 +0000
Re: absence of max supercat@casperkitty.com - 2016-11-27 14:14 -0800
Re: absence of max BartC <bc@freeuk.com> - 2016-11-27 23:02 +0000
Re: absence of max Richard Heathfield <rjh@cpax.org.uk> - 2016-11-27 23:26 +0000
Re: absence of max BartC <bc@freeuk.com> - 2016-11-27 23:43 +0000
Re: absence of max Richard Heathfield <rjh@cpax.org.uk> - 2016-11-27 23:46 +0000
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-11-28 12:56 +0100
Re: absence of max jameskuyper@verizon.net - 2016-11-27 16:21 -0800
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-11-28 10:10 -0800
Re: absence of max Tim Prince <tprince@computer.org> - 2016-11-27 07:40 -0500
absence of max asetofsymbols@gmail.com - 2016-11-27 08:46 -0800
Re: absence of max fir <profesor.fir@gmail.com> - 2016-11-27 09:18 -0800
Re: absence of max asetofsymbols@gmail.com - 2016-11-27 09:22 -0800
Re: absence of max fir <profesor.fir@gmail.com> - 2016-11-27 09:27 -0800
Re: absence of max BartC <bc@freeuk.com> - 2016-11-27 17:33 +0000
Re: absence of max Gareth Owen <gwowen@gmail.com> - 2016-11-27 17:51 +0000
Re: absence of max Ken Brody <kenbrody@spamcop.net> - 2016-11-30 13:15 -0500
Re: absence of max "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2016-12-01 12:33 +0800
Page 1 of 29 [1] 2 3 … 29 Next page →
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2016-11-26 12:49 -0800 |
| Subject | absence of max |
| Message-ID | <0e1db67d-0ab8-4971-a319-8aa66a40b873@googlegroups.com> |
classical question maybe someone know that (i realized it clearly quite recently) that there is no max (nor min) anywhere in c standard library (afaik there are fmax fmin for floats in math.h ) this is weird, maybe max from ibrary would be slow (though compilers have intrisinc for that so it could be made fast) and maybe this is a reason but absence of min max got weirld result that it must be defined in each project (no big worry as it is one line but still weird)
[toc] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2016-11-26 15:34 -0800 |
| Message-ID | <ba1ad958-e691-444c-959c-aa78244a0452@googlegroups.com> |
| In reply to | #97546 |
It takes 14 seconds to write your own custom max() function, one capable of handling your unique data/app's needs. That's probably why. Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-11-27 00:21 +0000 |
| Message-ID | <o1d8rg$pn3$1@dont-email.me> |
| In reply to | #97549 |
On 26/11/2016 23:34, Rick C. Hodgin wrote: > It takes 14 seconds to write your own custom max() function, one capable of > handling your unique data/app's needs. > > That's probably why. It takes 14 seconds in Python as well, yet it's a built-in function. While, the way I implement it, I can also write: x max:= y # x := max(x,y) In C, you'd have to write different versions for signed, unsigned, double and pointers (8 functions). If you don't want to always use 64-bit arithmetic, you might want 32-bit versions; that's another 6 functions. So 14 functions so far, and you haven't yet looked at in-place versions. If you try and do it with macros, then you have to think about problems like MAX(a[++i],b). Plus all the usual issues you get when you leave things like this to the creativity of millions of individual programmers. There are benefits to having even apparently trivial features like this supported by the language. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2016-11-27 04:25 -0800 |
| Message-ID | <c3e70455-c1f5-46ee-aa2e-0ab54c603f61@googlegroups.com> |
| In reply to | #97550 |
I wrote a reply last night, but I guess it was lost somehow. It basically said Python's a weakly-typed language, isn't it? If so it would have to have its own built-in min() and max() functions to be able to reliably compare disparate types. I see you also mention this as a need in C, but I would argue to a lesser degree because of casting. We can create a macro with a trinary operator and generate code for every case. The compiler may complain here or there so you apply the appropriate cast. Another thought this morning. Python moves by people needs. C moves by committee choices. If something is not deemed desirable by the committee, it will never officially be added. But, I think that era of fixedness in those maintaining the C Standard will have to change, lest it be ignored as people move on past it. Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Robert Spanjaard <spamtrap@arumes.com> |
|---|---|
| Date | 2016-11-27 13:54 +0100 |
| Message-ID | <o1el1d$16nf$1@gioia.aioe.org> |
| In reply to | #97561 |
On 27-11-16 13:25, Rick C. Hodgin wrote: > I wrote a reply last night, but I guess it was lost somehow. It basically said > Python's a weakly-typed language, isn't it? If so it would have to have its > own built-in min() and max() functions to be able to reliably compare > disparate types. I see you also mention this as a need in C, but I would > argue to a lesser degree because of casting. We can create a macro with > a trinary operator and generate code for every case. The compiler may > complain here or there so you apply the appropriate cast. > > Another thought this morning. Python moves by people needs. C > moves by committee choices. If something is not deemed desirable > by the committee, it will never officially be added. But, I think > that era of fixedness in those maintaining the C Standard will have to > change, lest it be ignored as people move on past it. Also, don't forget we're comparing two completely different languages here. A high-level interpreted language with little optimization benefits from a high number of built-in functions; they're much faster than user-created code. In C the speed gain is much less, often completely non-existant. -- Robert Spanjaard
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-11-27 13:54 +0000 |
| Message-ID | <o1eoh8$66f$1@dont-email.me> |
| In reply to | #97563 |
On 27/11/2016 12:54, Robert Spanjaard wrote:
> On 27-11-16 13:25, Rick C. Hodgin wrote:
>> I wrote a reply last night, but I guess it was lost somehow. It
>> basically said
>> Python's a weakly-typed language, isn't it? If so it would have to
>> have its
>> own built-in min() and max() functions to be able to reliably compare
>> disparate types. I see you also mention this as a need in C, but I would
>> argue to a lesser degree because of casting. We can create a macro with
>> a trinary operator and generate code for every case. The compiler may
>> complain here or there so you apply the appropriate cast.
>>
>> Another thought this morning. Python moves by people needs. C
>> moves by committee choices. If something is not deemed desirable
>> by the committee, it will never officially be added. But, I think
>> that era of fixedness in those maintaining the C Standard will have to
>> change, lest it be ignored as people move on past it.
>
> Also, don't forget we're comparing two completely different languages here.
> A high-level interpreted language with little optimization benefits from a
> high number of built-in functions; they're much faster than user-created
> code. In C the speed gain is much less, often completely non-existant.
Actually, if I write such a function in user-code:
def mymax(a,b):
if a>=b: return a
return b
it's actually *faster* than the built-in 'max'!
(Nearly 50% faster on one Python version. However the specification is
different as built-in 'max' deals with N operands, or can do an
element-by-element compare of N lists returning the 'greater' of all the
lists.
But if you do want to simply compare two numbers, then a user max
function can be faster. And here, you only need to write one such
function (and another for 'min') as the overloading needed is automatic)
But it's not about speed; to me, 'min' and 'max' are almost as basic as
C's built-in, overloaded operators '<', '>', '<=' and '>='.
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-11-27 07:33 -0800 |
| Message-ID | <24b38d8d-43b0-47dd-8ac7-571f27971748@googlegroups.com> |
| In reply to | #97568 |
On Sunday, November 27, 2016 at 7:55:08 AM UTC-6, Bart wrote: > Actually, if I write such a function in user-code: > > def mymax(a,b): > if a>=b: return a > return b > > it's actually *faster* than the built-in 'max'! > > (Nearly 50% faster on one Python version. However the specification is > different as built-in 'max' deals with N operands, or can do an > element-by-element compare of N lists returning the 'greater' of all the > lists. Out of curiosity, how do the semantics compare if one of the operands is NaN? There are some situations where it would be useful to have max(X,NaN) and max(NaN,X) both return X, and cases where it would be helpful to have both return NaN, and some where it wouldn't matter. I can't think of any cases where the semantics of your version would be more desirable than any other. BTW, it's been years since IEEE added a new set of relational comparisons, but I don't yet know of any language including them. What I'd like to see would be for languages to include types that are analogous to "float" and "double", and may be freely converted, but whose relational operators used the new semantics.
[toc] | [prev] | [next] | [standalone]
| From | Melzzzzz <mel@zzzzz.com> |
|---|---|
| Date | 2016-11-27 14:06 +0100 |
| Message-ID | <20161127140600.2afd8b79@maxa-pc> |
| In reply to | #97561 |
On Sun, 27 Nov 2016 04:25:51 -0800 (PST) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> wrote: > I wrote a reply last night, but I guess it was lost somehow. It > basically said Python's a weakly-typed language, isn't it? If so it > would have to have its own built-in min() and max() functions to be > able to reliably compare disparate types. I see you also mention > this as a need in C, but I would argue to a lesser degree because of > casting. We can create a macro with a trinary operator and generate > code for every case. The compiler may complain here or there so you > apply the appropriate cast. > > Another thought this morning. Python moves by people needs. C > moves by committee choices. If something is not deemed desirable > by the committee, it will never officially be added. But, I think > that era of fixedness in those maintaining the C Standard will have to > change, lest it be ignored as people move on past it. > > Best regards, > Rick C. Hodgin Puthon has bad breakage between 2 and 3... -- press any key to continue or any other to quit
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-11-27 17:47 +0100 |
| Message-ID | <o1f2js$7sr$1@dont-email.me> |
| In reply to | #97561 |
On 27/11/16 13:25, Rick C. Hodgin wrote: > I wrote a reply last night, but I guess it was lost somehow. It basically said > Python's a weakly-typed language, isn't it? If so it would have to have its > own built-in min() and max() functions to be able to reliably compare > disparate types. I see you also mention this as a need in C, but I would > argue to a lesser degree because of casting. We can create a macro with > a trinary operator and generate code for every case. The compiler may > complain here or there so you apply the appropriate cast. > Python is a strongly typed language, not a weakly typed language (such as C). But Python is a dynamically typed language, with duck-typing. This means that in effect, every function in Python is a bit like a template in C++. And writing a new "max" function in Python is as simple as: def my_max(a, b) : if (a > b) return a return b When the implementation is so simple, there is very little reason /not/ to put it into the standard library - just as C++ has std::max with a very simple implementation as a template. C, on the other hand, has /no/ possible implementation of a max function or macro that works on all numeric types until C11 _Generic - and even then, the implementation is more than a little ugly. > Another thought this morning. Python moves by people needs. C > moves by committee choices. If something is not deemed desirable > by the committee, it will never officially be added. But, I think > that era of fixedness in those maintaining the C Standard will have to > change, lest it be ignored as people move on past it. > C moves by people needs as well, just a lot more slowly - it needs a lot of people, and a very clear need, to make changes happen. "max" is not needed that much.
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2016-11-28 07:13 -0800 |
| Message-ID | <cefcbabd-ddcd-4f87-ac64-c99c53a828e9@googlegroups.com> |
| In reply to | #97582 |
On Sunday, November 27, 2016 at 11:47:10 AM UTC-5, David Brown wrote:
> On 27/11/16 13:25, Rick C. Hodgin wrote:
> > I wrote a reply last night, but I guess it was lost somehow. It basically said
> > Python's a weakly-typed language, isn't it? If so it would have to have its
> > own built-in min() and max() functions to be able to reliably compare
> > disparate types. I see you also mention this as a need in C, but I would
> > argue to a lesser degree because of casting. We can create a macro with
> > a trinary operator and generate code for every case. The compiler may
> > complain here or there so you apply the appropriate cast.
>
> Python is a strongly typed language, not a weakly typed language (such
> as C).
Are you saying "C is a weakly typed language" or "Python is a strongly
typed language like C?"
> But Python is a dynamically typed language, with duck-typing.
How can a dynamically typed language be a strongly typed language?
I was under the impression in Python you could code this:
n = 5
print n
n = "Hello, world"
print n
The token "n" can be used for multiple variable types. I tested this
using the online test page:
http://mathcs.holycross.edu/~kwalsh/python/
I see on the Python wiki that it answers this question:
https://wiki.python.org/moin/Why%20is%20Python%20a%20dynamic%20language%20and%20also%20a%20strongly%20typed%20language
I disagree with the way the term "strongly typed" is used there because
I consider C to be a strongly typed language. You type "char c" and
that's all C can ever be within that scope.
That's a philosophical difference I suppose.
> This means that in effect, every function in Python is a bit like a
> template in C++. And writing a new "max" function in Python is as
> simple as:
>
> def my_max(a, b) :
> if (a > b) return a
> return b
>
> When the implementation is so simple, there is very little reason /not/
> to put it into the standard library - just as C++ has std::max with a
> very simple implementation as a template.
Python is required, within its own internal processing engine, to compare
disparate types, such as a floating point value to another integer value,
and return correct results, without any custom/fancy casting or other
things required in C.
That's what I was referring to. Python needs this type of built-in
ability because it's weakly typed. A and B come in and they can be
anything. The nuances of the comparison logic has to be able to
handle comparing type x to type y generically, and with correct
results in each case.
Visual FreePro has to do this as well and it was complex to write all
of the code which does this as there are many possible comparisons.
> C, on the other hand, has /no/ possible implementation of a max function
> or macro that works on all numeric types until C11 _Generic - and even
> then, the implementation is more than a little ugly.
>
> > Another thought this morning. Python moves by people needs. C
> > moves by committee choices. If something is not deemed desirable
> > by the committee, it will never officially be added. But, I think
> > that era of fixedness in those maintaining the C Standard will have to
> > change, lest it be ignored as people move on past it.
>
> C moves by people needs as well, just a lot more slowly - it needs a lot
> of people, and a very clear need, to make changes happen. "max" is not
> needed that much.
Python is an open project. If I desire to have x, y, or z added I can
do it, it goes into the main line, and is then available to all. I
can't do that with C. I can do that with GCC or CLANG or some instance
of a C compiler, but not C, not to the standard.
I would argue it doesn't move by people needs, but by committee needs.
Otherwise a lot would've been introduced that, because it wasn't,
spawned off many other languages.
It's why I've more or less ditched C and am proceeding with CAlive. I
will provide support through C99 eventually however. And other people
are free to add additional newer support.
Best regards,
Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-11-28 15:35 +0000 |
| Message-ID | <o1hip8$7hl$1@dont-email.me> |
| In reply to | #97639 |
On 28/11/2016 15:13, Rick C. Hodgin wrote:
> On Sunday, November 27, 2016 at 11:47:10 AM UTC-5, David Brown wrote:
>> On 27/11/16 13:25, Rick C. Hodgin wrote:
>>> I wrote a reply last night, but I guess it was lost somehow. It basically said
>>> Python's a weakly-typed language, isn't it? If so it would have to have its
>>> own built-in min() and max() functions to be able to reliably compare
>>> disparate types. I see you also mention this as a need in C, but I would
>>> argue to a lesser degree because of casting. We can create a macro with
>>> a trinary operator and generate code for every case. The compiler may
>>> complain here or there so you apply the appropriate cast.
>>
>> Python is a strongly typed language, not a weakly typed language (such
>> as C).
>
> Are you saying "C is a weakly typed language" or "Python is a strongly
> typed language like C?"
>
>> But Python is a dynamically typed language, with duck-typing.
>
> How can a dynamically typed language be a strongly typed language?
> I was under the impression in Python you could code this:
>
> n = 5
> print n
> n = "Hello, world"
> print n
> The token "n" can be used for multiple variable types.
C allows this:
char* s = "Hello world";
int n = 5;
printf("%s\n", s + n);
printf("%d\n", s + n);
printf("%p\n", s + n);
So it can add a number to a string (and print the result as a string,
number or pointer). I guess that means C has weak typing; it doesn't try
too hard to stop you getting around its type system.
> The token "n" can be used for multiple variable types.
C can do a bit of that too. And in the same block:
int n=5;
{ printf("%d\n",n); // n is a number
char* n="Hello";
printf("%s\n",n); // n is now a string
}
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2016-11-28 07:48 -0800 |
| Message-ID | <b93b0b74-be08-422a-bafe-1ea0a3162c2c@googlegroups.com> |
| In reply to | #97640 |
On Monday, November 28, 2016 at 10:35:24 AM UTC-5, Bart wrote:
> On 28/11/2016 15:13, Rick C. Hodgin wrote:
> > On Sunday, November 27, 2016 at 11:47:10 AM UTC-5, David Brown wrote:
> >> On 27/11/16 13:25, Rick C. Hodgin wrote:
> >>> I wrote a reply last night, but I guess it was lost somehow. It basically said
> >>> Python's a weakly-typed language, isn't it? If so it would have to have its
> >>> own built-in min() and max() functions to be able to reliably compare
> >>> disparate types. I see you also mention this as a need in C, but I would
> >>> argue to a lesser degree because of casting. We can create a macro with
> >>> a trinary operator and generate code for every case. The compiler may
> >>> complain here or there so you apply the appropriate cast.
> >>
> >> Python is a strongly typed language, not a weakly typed language (such
> >> as C).
> >
> > Are you saying "C is a weakly typed language" or "Python is a strongly
> > typed language like C?"
> >
> >> But Python is a dynamically typed language, with duck-typing.
> >
> > How can a dynamically typed language be a strongly typed language?
> > I was under the impression in Python you could code this:
> >
> > n = 5
> > print n
> > n = "Hello, world"
> > print n
>
> > The token "n" can be used for multiple variable types.
>
> C allows this:
>
> char* s = "Hello world";
> int n = 5;
>
> printf("%s\n", s + n);
> printf("%d\n", s + n);
> printf("%p\n", s + n);
>
> So it can add a number to a string (and print the result as a string,
> number or pointer). I guess that means C has weak typing; it doesn't try
> too hard to stop you getting around its type system.
I don't view that as weak typing in any sense. In that case, you are
providing input to a target which is strongly typed, in that it can
only receive what it's been told to receive.
The C compiler upsizes or downsizes or translates the various types
you specify as input for you, so that they meet the rigid requirements
of the called function. And whereas printf() uses variadic parameters,
they are still dictated by the operands specified in the format string.
Python is not like that. It receives generic parameters and then is
called upon to attempt to conduct operations on them. It will,
internally, resolve the comparison form automatically.
Visual FreePro also does this, and it's nontrivial to implement. But,
it does save a lot of difficult work for every developer who uses it.
C maintains a rigid form that does not change at any point after compile.
"char c" is always "char." It can be cast into other forms, but that's
an operation, not a reinvention of the fundamental type.
> > The token "n" can be used for multiple variable types.
>
> C can do a bit of that too. And in the same block:
>
> int n=5;
>
> { printf("%d\n",n); // n is a number
> char* n="Hello";
> printf("%s\n",n); // n is now a string
> }
New scope. Neither value of "n" has changed, just what the compiler
chooses to reference as by its design when the token "n" is utilized
in each scope.
Best regards,
Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2016-11-28 07:53 -0800 |
| Message-ID | <04252ecc-68be-4744-937f-14a568753116@googlegroups.com> |
| In reply to | #97641 |
On Monday, November 28, 2016 at 10:48:47 AM UTC-5, Rick C. Hodgin wrote:
> On Monday, November 28, 2016 at 10:35:24 AM UTC-5, Bart wrote:
> > On 28/11/2016 15:13, Rick C. Hodgin wrote:
> > > On Sunday, November 27, 2016 at 11:47:10 AM UTC-5, David Brown wrote:
> > > > But Python is a dynamically typed language, with duck-typing.
> > >
> > > How can a dynamically typed language be a strongly typed language?
> > > I was under the impression in Python you could code this:
> > >
> > > n = 5
> > > print n
> > > n = "Hello, world"
> > > print n
> >
> > > The token "n" can be used for multiple variable types.
> >
> > C allows this:
> >
> > char* s = "Hello world";
> > int n = 5;
> >
> > printf("%s\n", s + n);
> > printf("%d\n", s + n);
> > printf("%p\n", s + n);
> >
> > So it can add a number to a string (and print the result as a string,
> > number or pointer). I guess that means C has weak typing; it doesn't try
> > too hard to stop you getting around its type system.
>
> I don't view that as weak typing in any sense. In that case, you are
> providing input to a target which is strongly typed, in that it can
> only receive what it's been told to receive.
And to be a little more precise on this, every piece of strongly typed
data that is used in C goes through transformation mechanisms that are
explicitly designed to receive one type in, and emit another type out.
Everything in C is completely strongly typed I would argue. In fact,
I might even use/coin the term very strongly typed for how C regards its
data.
The C compiler happens to be very adept at manipulating strongly typed
variables into other forms required for input into the other thing,
which is what makes it so desirable.
> The C compiler upsizes or downsizes or translates the various types
> you specify as input for you, so that they meet the rigid requirements
> of the called function. And whereas printf() uses variadic parameters,
> they are still dictated by the operands specified in the format string.
>
> Python is not like that. It receives generic parameters and then is
> called upon to attempt to conduct operations on them. It will,
> internally, resolve the comparison form automatically.
>
> Visual FreePro also does this, and it's nontrivial to implement. But,
> it does save a lot of difficult work for every developer who uses it.
>
> C maintains a rigid form that does not change at any point after compile.
> "char c" is always "char." It can be cast into other forms, but that's
> an operation, not a reinvention of the fundamental type.
>
> > > The token "n" can be used for multiple variable types.
> >
> > C can do a bit of that too. And in the same block:
> >
> > int n=5;
> >
> > { printf("%d\n",n); // n is a number
> > char* n="Hello";
> > printf("%s\n",n); // n is now a string
> > }
>
> New scope. Neither value of "n" has changed, just what the compiler
> chooses to reference as by its design when the token "n" is utilized
> in each scope.
Best regards,
Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-11-29 00:14 +0000 |
| Message-ID | <87inr7i1kv.fsf@bsb.me.uk> |
| In reply to | #97640 |
BartC <bc@freeuk.com> writes:
<snip>
> C allows this:
>
> char* s = "Hello world";
> int n = 5;
>
> printf("%s\n", s + n);
> printf("%d\n", s + n);
> printf("%p\n", s + n);
>
> So it can add a number to a string
No it can't. I think you know it can't but saying it can satisfies some
private propaganda agenda of your. Please stop.
<snip>
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-11-29 00:36 +0000 |
| Message-ID | <o1iige$1s7$1@dont-email.me> |
| In reply to | #97694 |
On 29/11/2016 00:14, Ben Bacarisse wrote:
> BartC <bc@freeuk.com> writes:
> <snip>
>> C allows this:
>>
>> char* s = "Hello world";
>> int n = 5;
>>
>> printf("%s\n", s + n);
>> printf("%d\n", s + n);
>> printf("%p\n", s + n);
>>
>> So it can add a number to a string
>
> No it can't.
Yes it can; that's what the code is doing.
s is used to refer to a string.
n is a number.
The language allows you to add those together using 's + n'.
Of course the actual operation it does, because of how C works, is not
very interesting: it takes the address of the start of the string, and
steps it by 5. It doesn't end up with "Hello world5" or, after trying to
convert "Hello World" to number and getting 0, adding 5 to that.
But then exactly what 'add number to a string' does hasn't been defined.
> I think you know it can't but saying it can satisfies some
> private propaganda agenda of your. Please stop.
The subthread was about strong and weak typing.
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-11-29 02:03 +0000 |
| Message-ID | <877f7nhwkg.fsf@bsb.me.uk> |
| In reply to | #97696 |
BartC <bc@freeuk.com> writes:
> On 29/11/2016 00:14, Ben Bacarisse wrote:
>> BartC <bc@freeuk.com> writes:
>> <snip>
>>> C allows this:
>>>
>>> char* s = "Hello world";
>>> int n = 5;
>>>
>>> printf("%s\n", s + n);
>>> printf("%d\n", s + n);
>>> printf("%p\n", s + n);
>>>
>>> So it can add a number to a string
>>
>> No it can't.
>
> Yes it can; that's what the code is doing.
No. Please don't keep this nonsense up. You know perfectly well that s
is a pointer and the code adds a number to a pointer, not a string.
<snip>
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-11-28 23:23 -0800 |
| Message-ID | <ln8ts2agx4.fsf@kst-u.example.com> |
| In reply to | #97696 |
BartC <bc@freeuk.com> writes:
> On 29/11/2016 00:14, Ben Bacarisse wrote:
>> BartC <bc@freeuk.com> writes:
>> <snip>
>>> C allows this:
>>>
>>> char* s = "Hello world";
>>> int n = 5;
>>>
>>> printf("%s\n", s + n);
>>> printf("%d\n", s + n);
>>> printf("%p\n", s + n);
>>>
>>> So it can add a number to a string
>>
>> No it can't.
>
> Yes it can; that's what the code is doing.
>
> s is used to refer to a string.
Yes, s is used to refer to a string. s is not a string. s is a
pointer. You understand that, but you spread confusion by pretending
not to. Stop it.
> n is a number.
Yup. (More precisely an integer, even more precisely an object of type
int).
> The language allows you to add those together using 's + n'.
Yes, you can add a pointer and an integer, with semantics that have been
discussed at length.
> Of course the actual operation it does, because of how C works, is not
> very interesting: it takes the address of the start of the string, and
> steps it by 5. It doesn't end up with "Hello world5" or, after trying to
> convert "Hello World" to number and getting 0, adding 5 to that.
Oh? I'd call it very interesting. It's at the core of how C deals with
arrays and their elements. Of course you pretend not to understand that
because it helps you spread confusion.
> But then exactly what 'add number to a string' does hasn't been defined.
No, it hasn't, because it doesn't make any sense. Please stop making
things up. C can be confusing enough. Stop trying to make it worse.
[...]
--
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 | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-11-28 21:05 -0800 |
| Message-ID | <lnpolean9m.fsf@kst-u.example.com> |
| In reply to | #97640 |
BartC <bc@freeuk.com> writes:
[...]
> C allows this:
>
> char* s = "Hello world";
> int n = 5;
>
> printf("%s\n", s + n);
> printf("%d\n", s + n);
> printf("%p\n", s + n);
>
> So it can add a number to a string (and print the result as a string,
> number or pointer). I guess that means C has weak typing; it doesn't try
> too hard to stop you getting around its type system.
The first and third examples do not demonstrate weak typing.
The result of adding a char* value and an int value is of type char*.
Permitting operators to have operands of different types is not
weak typing. (Though "%p" requires a void* argument, and s + n
is of type char*.)
The second example does demonstrate weak typing, in a sense.
In fact, that call has undefined behavior. printf is not required
to *enforce* correct types for its arguments.
I don't think there's any rigorous definition of the terms "weak
typing" and "strong typing". I'd call C's typing somewhat "strong"
in the sense that every expression has an unambiguous well-defined
type. The major way in which I'd call C's typing "weak" is its
widespread use of implicit conversions.
[...]
--
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 | 2016-11-28 16:53 +0100 |
| Message-ID | <o1hjrt$asr$1@dont-email.me> |
| In reply to | #97639 |
On 28/11/16 16:13, Rick C. Hodgin wrote: > On Sunday, November 27, 2016 at 11:47:10 AM UTC-5, David Brown wrote: >> On 27/11/16 13:25, Rick C. Hodgin wrote: >>> I wrote a reply last night, but I guess it was lost somehow. It basically said >>> Python's a weakly-typed language, isn't it? If so it would have to have its >>> own built-in min() and max() functions to be able to reliably compare >>> disparate types. I see you also mention this as a need in C, but I would >>> argue to a lesser degree because of casting. We can create a macro with >>> a trinary operator and generate code for every case. The compiler may >>> complain here or there so you apply the appropriate cast. >> >> Python is a strongly typed language, not a weakly typed language (such >> as C). > > Are you saying "C is a weakly typed language" or "Python is a strongly > typed language like C?" I don't think there are any clear and non-controversial definitions of strong and weak typing. But I believe C is usually classified as "weakly typed" because it is relatively easy to mess around with types (some conversions are done implicitly, especially via void*, and enums are particularly weak) and a great deal of data is simply "int". Python is classified as strongly typed because every object has a specific type, and type conversions actually change the data (so if you use a number as a string, a formatting function is called to generate a new string from the number - the language does not merely try to re-interpret the number as though it were a string). > >> But Python is a dynamically typed language, with duck-typing. > > How can a dynamically typed language be a strongly typed language? > I was under the impression in Python you could code this: > > n = 5 > print n > n = "Hello, world" > print n Yes, you can do that - because Python is dynamically typed. But dynamic typing does not mean weak typing. In the Python code above, "n" is just a name - it is not an object. The objects are 5 and "Hello, world", each of which has very clear and definitive types that do not change. All that changes is the binding of the name "n" to those two objects. > > The token "n" can be used for multiple variable types. I tested this > using the online test page: > > http://mathcs.holycross.edu/~kwalsh/python/ > > I see on the Python wiki that it answers this question: > > https://wiki.python.org/moin/Why%20is%20Python%20a%20dynamic%20language%20and%20also%20a%20strongly%20typed%20language > > I disagree with the way the term "strongly typed" is used there because > I consider C to be a strongly typed language. You type "char c" and > that's all C can ever be within that scope. > > That's a philosophical difference I suppose. C is statically typed, while Python is dynamically typed. Those terms are /not/ synonymous with "strongly typed" and "weakly typed" - I think you can have all combinations (though I can't think of any weakly typed dynamically typed language off hand). Once you have your "char c", it is not hard to make an "int *" pointer to point to it and read the same data as a different type - that is what makes it "weak". It is very hard to do something similar in Python. Of course, the terms are not really black and white, and you can reasonably argue that "C with warnings enabled" has stronger typing because it is hard to "cheat" on your types while avoiding warnings. > >> This means that in effect, every function in Python is a bit like a >> template in C++. And writing a new "max" function in Python is as >> simple as: >> >> def my_max(a, b) : >> if (a > b) return a >> return b >> >> When the implementation is so simple, there is very little reason /not/ >> to put it into the standard library - just as C++ has std::max with a >> very simple implementation as a template. > > Python is required, within its own internal processing engine, to compare > disparate types, such as a floating point value to another integer value, > and return correct results, without any custom/fancy casting or other > things required in C. > > That's what I was referring to. Python needs this type of built-in > ability because it's weakly typed. A and B come in and they can be > anything. The nuances of the comparison logic has to be able to > handle comparing type x to type y generically, and with correct > results in each case. No, it is /strongly/ typed. When Python needs to convert an operand (or both operands) in order to carry out an operation like "a > b", it uses well-defined conversion functions. These exist for built-in types - if you are using your own types, you need to define these functions or you will get a run-time error. C is weakly typed, because it will happily (well, maybe unhappily, with a warning) do what you ask here in many cases, even if it makes no sense. > > Visual FreePro has to do this as well and it was complex to write all > of the code which does this as there are many possible comparisons. > >> C, on the other hand, has /no/ possible implementation of a max function >> or macro that works on all numeric types until C11 _Generic - and even >> then, the implementation is more than a little ugly. >> >>> Another thought this morning. Python moves by people needs. C >>> moves by committee choices. If something is not deemed desirable >>> by the committee, it will never officially be added. But, I think >>> that era of fixedness in those maintaining the C Standard will have to >>> change, lest it be ignored as people move on past it. >> >> C moves by people needs as well, just a lot more slowly - it needs a lot >> of people, and a very clear need, to make changes happen. "max" is not >> needed that much. > > Python is an open project. If I desire to have x, y, or z added I can > do it, it goes into the main line, and is then available to all. No, you can't. Python is an open source project - you can download the source, make all the changes you want, and use it yourself. You can publish the modified version as you want. But it will only get back to the mainline if it is approved by the project maintainers, which involves going through a formal process of "Python Enhancement Proposals" to give the main Python developers and the Python community a chance to consider the change and its implications. The change must meet the approval of Python's Benevolent Dictator For Life, Guido van Rossum, before it has a chance to become part of the official mainline Python. Still, you have a far better chance of getting a change into Python than getting a change into C :-) > I > can't do that with C. I can do that with GCC or CLANG or some instance > of a C compiler, but not C, not to the standard. > > I would argue it doesn't move by people needs, but by committee needs. > Otherwise a lot would've been introduced that, because it wasn't, > spawned off many other languages. > > It's why I've more or less ditched C and am proceeding with CAlive. I > will provide support through C99 eventually however. And other people > are free to add additional newer support. > > Best regards, > Rick C. Hodgin >
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2016-11-28 08:07 -0800 |
| Message-ID | <0d008373-ac16-4b7d-990e-c85c2b5fc2ff@googlegroups.com> |
| In reply to | #97643 |
On Monday, November 28, 2016 at 10:54:00 AM UTC-5, David Brown wrote:
> On 28/11/16 16:13, Rick C. Hodgin wrote:
> > On Sunday, November 27, 2016 at 11:47:10 AM UTC-5, David Brown wrote:
> >> On 27/11/16 13:25, Rick C. Hodgin wrote:
> >>> I wrote a reply last night, but I guess it was lost somehow. It basically said
> >>> Python's a weakly-typed language, isn't it? If so it would have to have its
> >>> own built-in min() and max() functions to be able to reliably compare
> >>> disparate types. I see you also mention this as a need in C, but I would
> >>> argue to a lesser degree because of casting. We can create a macro with
> >>> a trinary operator and generate code for every case. The compiler may
> >>> complain here or there so you apply the appropriate cast.
> >>
> >> Python is a strongly typed language, not a weakly typed language (such
> >> as C).
> >
> > Are you saying "C is a weakly typed language" or "Python is a strongly
> > typed language like C?"
>
> I don't think there are any clear and non-controversial definitions of
> strong and weak typing. But I believe C is usually classified as
> "weakly typed" because it is relatively easy to mess around with types
> (some conversions are done implicitly, especially via void*, and enums
> are particularly weak) and a great deal of data is simply "int".
>
> Python is classified as strongly typed because every object has a
> specific type, and type conversions actually change the data (so if you
> use a number as a string, a formatting function is called to generate a
> new string from the number - the language does not merely try to
> re-interpret the number as though it were a string).
>
>
> >
> >> But Python is a dynamically typed language, with duck-typing.
> >
> > How can a dynamically typed language be a strongly typed language?
> > I was under the impression in Python you could code this:
> >
> > n = 5
> > print n
> > n = "Hello, world"
> > print n
>
> Yes, you can do that - because Python is dynamically typed. But dynamic
> typing does not mean weak typing. In the Python code above, "n" is just
> a name - it is not an object. The objects are 5 and "Hello, world",
> each of which has very clear and definitive types that do not change.
> All that changes is the binding of the name "n" to those two objects.
Visual FreePro does the same thing. I have a struct with a discriminating
union which determines the actual type of the data within. It can be
reassigned as needed, as in python (or originally as in other xbase
languages as that's what it's emulating).
The data changes internally, meaning it's weakly typed because the type
goes back to the thing identified by its token name (in my definition).
> > The token "n" can be used for multiple variable types. I tested this
> > using the online test page:
> >
> > http://mathcs.holycross.edu/~kwalsh/python/
> >
> > I see on the Python wiki that it answers this question:
> >
> > https://wiki.python.org/moin/Why%20is%20Python%20a%20dynamic%20language%20and%20also%20a%20strongly%20typed%20language
> >
> > I disagree with the way the term "strongly typed" is used there because
> > I consider C to be a strongly typed language. You type "char c" and
> > that's all C can ever be within that scope.
> >
> > That's a philosophical difference I suppose.
>
> C is statically typed, while Python is dynamically typed. Those terms
> are /not/ synonymous with "strongly typed" and "weakly typed" - I think
> you can have all combinations (though I can't think of any weakly typed
> dynamically typed language off hand).
I think they must be. If something is statically typed it cannot be
altered. It remains that way forever, which means it is strongly typed.
> Once you have your "char c", it is not hard to make an "int *" pointer
> to point to it and read the same data as a different type - that is what
> makes it "weak".
I disagree. "char c" has not changed. It will always still yield the
char value at its location in memory. The new "int *" (be it a cast, or
a variable that's set to the &c address) is a new and discrete thing with
its own ability to act on the thing it's pointing to.
In both cases, both are strongly typed.
> It is very hard to do something similar in Python.
>
> Of course, the terms are not really black and white, and you can
> reasonably argue that "C with warnings enabled" has stronger typing
> because it is hard to "cheat" on your types while avoiding warnings.
Even in the case of explicitly added casts, which are fundamental
operations you've manually injected into an expression to receive a
particular type, and emit another type, I don't see how it could be
viewed as anything other than strongly typed.
Everything in C is nailed down categorically and the correct function
is called based on what is known at compile-time.
In python (and Visual FreePro) it does a test on variable types to
determine which branch to flow to in order to process a particular
type.
> >> This means that in effect, every function in Python is a bit like a
> >> template in C++. And writing a new "max" function in Python is as
> >> simple as:
> >>
> >> def my_max(a, b) :
> >> if (a > b) return a
> >> return b
> >>
> >> When the implementation is so simple, there is very little reason /not/
> >> to put it into the standard library - just as C++ has std::max with a
> >> very simple implementation as a template.
> >
> > Python is required, within its own internal processing engine, to compare
> > disparate types, such as a floating point value to another integer value,
> > and return correct results, without any custom/fancy casting or other
> > things required in C.
> >
> > That's what I was referring to. Python needs this type of built-in
> > ability because it's weakly typed. A and B come in and they can be
> > anything. The nuances of the comparison logic has to be able to
> > handle comparing type x to type y generically, and with correct
> > results in each case.
>
> No, it is /strongly/ typed. When Python needs to convert an operand (or
> both operands) in order to carry out an operation like "a > b", it uses
> well-defined conversion functions.
Of course. But, they are not known at compile-time. They are known
only at runtime with internal tests being made on each type to determine
what internal logic path to flow to.
The same input names "n" and "m" could flow through different paths
based on their internal values at runtime. It's not known at compile-
time, and has no ability to be known outside of a static program with
no variables like:
(pseudo code)
function x() {
if (current_millisecond % 7 == 0)
return "Hello world";
else
return 5;
}
Any python app calling a function like that (in its proper syntax form)
will have variable types being returned, but stored in the same token
name. When you later do a comparison to another, it will flow through
to the proper handler based on the runtime peculiarities of the data,
and not due to anything known at compile time.
At each use / reference, it must be manually examined and then branched
to.
In C, that's not the case. The entire program is completely known at
compile time and there is no ability to change anything. You must use
something like custom logic and variadic functions in order to do those
variable things. But even then, in each case, every flow through every
possible type is already known, with only manual tests on data, not
variable types, determining where flow goes.
I view that as very strongly typed.
> These exist for built-in types - if
> you are using your own types, you need to define these functions or you
> will get a run-time error. C is weakly typed, because it will happily
> (well, maybe unhappily, with a warning) do what you ask here in many
> cases, even if it makes no sense.
>
> >
> > Visual FreePro has to do this as well and it was complex to write all
> > of the code which does this as there are many possible comparisons.
> >
> >> C, on the other hand, has /no/ possible implementation of a max function
> >> or macro that works on all numeric types until C11 _Generic - and even
> >> then, the implementation is more than a little ugly.
> >>
> >>> Another thought this morning. Python moves by people needs. C
> >>> moves by committee choices. If something is not deemed desirable
> >>> by the committee, it will never officially be added. But, I think
> >>> that era of fixedness in those maintaining the C Standard will have to
> >>> change, lest it be ignored as people move on past it.
> >>
> >> C moves by people needs as well, just a lot more slowly - it needs a lot
> >> of people, and a very clear need, to make changes happen. "max" is not
> >> needed that much.
> >
> > Python is an open project. If I desire to have x, y, or z added I can
> > do it, it goes into the main line, and is then available to all.
>
> No, you can't. Python is an open source project - you can download the
> source, make all the changes you want, and use it yourself. You can
> publish the modified version as you want. But it will only get back to
> the mainline if it is approved by the project maintainers, which
> involves going through a formal process of "Python Enhancement
> Proposals" to give the main Python developers and the Python community a
> chance to consider the change and its implications. The change must
> meet the approval of Python's Benevolent Dictator For Life, Guido van
> Rossum, before it has a chance to become part of the official mainline
> Python.
Roughly, how many changes have been allowed since python came about,
compared to how many changes have been allowed to the C Standard?
> Still, you have a far better chance of getting a change into Python than
> getting a change into C :-)
My point exactly.
> > I
> > can't do that with C. I can do that with GCC or CLANG or some instance
> > of a C compiler, but not C, not to the standard.
> >
> > I would argue it doesn't move by people needs, but by committee needs.
> > Otherwise a lot would've been introduced that, because it wasn't,
> > spawned off many other languages.
> >
> > It's why I've more or less ditched C and am proceeding with CAlive. I
> > will provide support through C99 eventually however. And other people
> > are free to add additional newer support.
Best regards,
Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
Page 1 of 29 [1] 2 3 … 29 Next page →
Back to top | Article view | comp.lang.c
csiph-web