Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #28006 > unrolled thread
| Started by | Mark Wills <markrobertwills@yahoo.co.uk> |
|---|---|
| First post | 2014-01-22 13:52 -0800 |
| Last post | 2014-01-26 01:59 +0100 |
| Articles | 20 on this page of 412 — 34 participants |
Back to article view | Back to comp.lang.forth
CASE mis-understanding? Mark Wills <markrobertwills@yahoo.co.uk> - 2014-01-22 13:52 -0800
Re: CASE mis-understanding? stephenXXX@mpeforth.com (Stephen Pelc) - 2014-01-22 21:57 +0000
Re: CASE mis-understanding? Mark Wills <markrobertwills@yahoo.co.uk> - 2014-01-22 14:10 -0800
Re: CASE mis-understanding? Mark Wills <markrobertwills@yahoo.co.uk> - 2014-01-22 14:11 -0800
Re: CASE mis-understanding? Coos Haak <chforth@hccnet.nl> - 2014-01-23 00:14 +0100
Re: CASE mis-understanding? "Elizabeth D. Rather" <erather@forth.com> - 2014-01-22 14:28 -1000
Re: CASE mis-understanding? "Ed" <invalid@invalid.com> - 2014-01-23 20:22 +1100
Re: CASE mis-understanding? Coos Haak <chforth@hccnet.nl> - 2014-01-23 12:34 +0100
Re: CASE mis-understanding? "Ed" <invalid@invalid.com> - 2014-01-25 22:44 +1100
Re: CASE mis-understanding? "Elizabeth D. Rather" <erather@forth.com> - 2014-01-25 08:49 -1000
Re: CASE mis-understanding? hughaguilar96@yahoo.com - 2014-01-25 19:40 -0800
Re: CASE mis-understanding? "Ed" <invalid@invalid.com> - 2014-01-26 23:01 +1100
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-23 03:43 -0600
Re: CASE mis-understanding? stephenXXX@mpeforth.com (Stephen Pelc) - 2014-01-23 10:10 +0000
Re: CASE mis-understanding? "gareth" <no.spam@thank.you.invalid> - 2014-01-23 10:31 +0000
Re: CASE mis-understanding? stephenXXX@mpeforth.com (Stephen Pelc) - 2014-01-23 11:35 +0000
Re: CASE mis-understanding? "gareth" <no.spam@thank.you.invalid> - 2014-01-23 13:27 +0000
Re: CASE mis-understanding? Mikael Nordman <oh2aun@gmail.com> - 2014-01-23 05:52 -0800
Re: CASE mis-understanding? Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-23 15:50 +0100
Re: CASE mis-understanding? Mark Wills <markrobertwills@yahoo.co.uk> - 2014-01-24 01:51 -0800
Re: CASE mis-understanding? Mark Wills <markrobertwills@yahoo.co.uk> - 2014-01-24 02:00 -0800
Re: CASE mis-understanding? Mark Wills <markrobertwills@yahoo.co.uk> - 2014-01-24 02:08 -0800
Re: CASE mis-understanding? Mark Wills <markrobertwills@yahoo.co.uk> - 2014-01-24 02:26 -0800
Re: CASE mis-understanding? Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-24 14:23 +0100
Re: CASE mis-understanding? Mark Wills <markrobertwills@yahoo.co.uk> - 2014-01-24 05:41 -0800
Re: CASE mis-understanding? "Ed" <invalid@invalid.com> - 2014-01-26 00:49 +1100
Re: CASE mis-understanding? Mikael Nordman <oh2aun@gmail.com> - 2014-01-26 03:01 -0800
Re: CASE mis-understanding? Mikael Nordman <oh2aun@gmail.com> - 2014-01-23 05:52 -0800
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-23 08:21 -0600
Re: CASE mis-understanding? BF <foxaudioresearch@gmail.com> - 2014-01-23 06:54 -0800
Re: CASE mis-understanding? "Alex McDonald" <blog@rivadpm.com> - 2014-01-23 16:00 +0000
Re: CASE mis-understanding? hughaguilar96@yahoo.com - 2014-01-23 20:21 -0800
Re: CASE mis-understanding? hughaguilar96@yahoo.com - 2014-01-23 20:33 -0800
Re: CASE mis-understanding? "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-01-24 04:33 -0500
Re: CASE mis-understanding? "WJ" <w_a_x_man@yahoo.com> - 2014-03-10 23:14 +0000
Re: CASE mis-understanding? Ron Aaron <rambamist@gmail.com> - 2014-01-24 10:49 +0200
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-24 03:26 -0600
Re: CASE mis-understanding? "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-01-24 04:25 -0500
Re: CASE mis-understanding? "Ed" <invalid@invalid.com> - 2014-01-27 22:09 +1100
Re: CASE mis-understanding? hughaguilar96@yahoo.com - 2014-01-28 22:38 -0800
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-01-23 03:22 -0800
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-23 06:52 -0600
Re: CASE mis-understanding? Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-23 16:03 +0100
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-23 10:14 -0600
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-23 17:42 +0000
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-01-23 10:42 -0800
Re: CASE mis-understanding? Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-24 15:01 +0100
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-23 17:21 +0000
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-23 12:16 -0600
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-24 09:25 +0000
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-24 07:16 -0600
Re: CASE mis-understanding? Mark Wills <markrobertwills@yahoo.co.uk> - 2014-01-24 05:43 -0800
Re: CASE mis-understanding? mhx@iae.nl - 2014-01-24 10:57 -0800
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-25 03:58 -0600
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-27 17:24 +0000
Re: CASE mis-understanding? stephenXXX@mpeforth.com (Stephen Pelc) - 2014-01-27 19:25 +0000
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-28 03:34 -0600
Re: CASE mis-understanding? Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-24 14:50 +0100
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-27 17:15 +0000
Re: CASE mis-understanding? hughaguilar96@yahoo.com - 2014-01-24 21:00 -0800
Re: CASE mis-understanding? hughaguilar96@yahoo.com - 2014-01-25 20:47 -0800
Re: CASE mis-understanding? "WJ" <w_a_x_man@yahoo.com> - 2014-03-10 23:36 +0000
Re: CASE mis-understanding? m.a.m.hendrix@tue.nl - 2014-01-24 00:44 -0800
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-24 09:20 +0000
Re: CASE mis-understanding? stephenXXX@mpeforth.com (Stephen Pelc) - 2014-01-23 10:02 +0000
Re: CASE mis-understanding? Elizabeth D Rather <erather@forth.com> - 2014-01-23 09:05 -1000
Re: CASE mis-understanding? "Ed" <invalid@invalid.com> - 2014-01-27 00:43 +1100
Re: CASE mis-understanding? stephenXXX@mpeforth.com (Stephen Pelc) - 2014-01-26 18:04 +0000
Re: CASE mis-understanding? mhx@iae.nl - 2014-01-26 11:27 -0800
Re: CASE mis-understanding? Coos Haak <chforth@hccnet.nl> - 2014-01-26 22:09 +0100
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-26 15:35 -0600
Re: CASE mis-understanding? "Ed" <invalid@invalid.com> - 2014-01-29 01:57 +1100
Re: CASE mis-understanding? mhx@iae.nl - 2014-01-28 13:46 -0800
Re: CASE mis-understanding? "Elizabeth D. Rather" <erather@forth.com> - 2014-01-28 12:12 -1000
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-30 17:19 +0000
Re: CASE mis-understanding? "Ed" <invalid@invalid.com> - 2014-02-01 00:40 +1100
Re: CASE mis-understanding? Mark Wills <markrobertwills@yahoo.co.uk> - 2014-01-31 06:33 -0800
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-31 12:13 -0600
Re: CASE mis-understanding? "Elizabeth D. Rather" <erather@forth.com> - 2014-01-31 08:36 -1000
Re: CASE mis-understanding? hughaguilar96@yahoo.com - 2014-02-01 00:06 -0800
Re: CASE mis-understanding? stephenXXX@mpeforth.com (Stephen Pelc) - 2014-01-31 15:34 +0000
Re: CASE mis-understanding? "Ed" <invalid@invalid.com> - 2014-02-03 16:18 +1100
Re: CASE mis-understanding? mhx@iae.nl - 2014-02-01 03:17 -0800
Re: CASE mis-understanding? "Alex McDonald" <blog@rivadpm.com> - 2014-02-02 13:10 +0000
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-02 16:06 +0000
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-02 10:43 -0600
Re: CASE mis-understanding? Bernd Paysan <bernd.paysan@gmx.de> - 2014-02-02 18:39 +0100
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-03 14:18 +0000
Re: CASE mis-understanding? hughaguilar96@yahoo.com - 2014-02-02 18:49 -0800
Re: CASE mis-understanding? "Alex McDonald" <blog@rivadpm.com> - 2014-02-03 09:35 +0000
Re: CASE mis-understanding? Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2014-02-03 09:56 +0000
Re: CASE mis-understanding? m.a.m.hendrix@tue.nl - 2014-02-03 02:50 -0800
Re: CASE mis-understanding? Mark Wills <markrobertwills@yahoo.co.uk> - 2014-02-03 03:17 -0800
Re: CASE mis-understanding? "Alex McDonald" <blog@rivadpm.com> - 2014-02-03 14:31 +0000
Re: CASE mis-understanding? hughaguilar96@yahoo.com - 2014-02-03 19:17 -0800
Re: CASE mis-understanding? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-02-04 12:23 +0000
Re: CASE mis-understanding? hughaguilar96@yahoo.com - 2014-02-03 19:26 -0800
Re: CASE mis-understanding? "Alex McDonald" <blog@rivadpm.com> - 2014-02-04 08:05 +0000
Re: CASE mis-understanding? hughaguilar96@yahoo.com - 2014-02-02 19:07 -0800
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-30 15:59 +0000
Re: CASE mis-understanding? Coos Haak <chforth@hccnet.nl> - 2014-01-31 02:34 +0100
Re: CASE mis-understanding? Coos Haak <chforth@hccnet.nl> - 2014-01-31 02:38 +0100
Re: CASE mis-understanding? "Elizabeth D. Rather" <erather@forth.com> - 2014-01-30 15:51 -1000
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-03 14:58 +0000
Re: CASE mis-understanding? mhx@iae.nl - 2014-02-03 12:06 -0800
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-09 15:04 +0000
Re: CASE mis-understanding? mhx@iae.nl - 2014-02-09 10:56 -0800
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-10 15:58 +0000
Re: CASE mis-understanding? mhx@iae.nl - 2014-02-10 12:06 -0800
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-11 11:22 +0000
Re: CASE mis-understanding? m.a.m.hendrix@tue.nl - 2014-02-11 05:23 -0800
Re: CASE mis-understanding? mhx@iae.nl - 2014-02-12 10:54 -0800
Re: CASE mis-understanding? "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-02-10 18:12 -0500
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-10 05:13 -0600
Re: CASE mis-understanding? "Alex McDonald" <blog@rivadpm.com> - 2014-02-10 15:44 +0000
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-10 10:40 -0600
Re: CASE mis-understanding? Bernd Paysan <bernd.paysan@gmx.de> - 2014-02-10 17:47 +0100
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-10 16:34 +0000
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-10 11:09 -0600
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-10 17:20 +0000
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-10 12:14 -0600
Re: CASE mis-understanding? stephenXXX@mpeforth.com (Stephen Pelc) - 2014-02-10 22:38 +0000
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-11 03:46 -0600
Re: CASE mis-understanding? stephenXXX@mpeforth.com (Stephen Pelc) - 2014-02-11 10:30 +0000
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-11 18:24 -0600
Re: CASE mis-understanding? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-02-12 15:02 +0000
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-12 11:23 -0600
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-13 09:25 +0000
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-13 04:54 -0600
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-13 13:41 +0000
Re: CASE mis-understanding? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-02-13 14:14 +0000
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-13 08:41 -0600
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-13 15:29 +0000
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-13 12:07 -0600
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-15 16:14 +0000
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-15 13:22 -0600
Re: CASE mis-understanding? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-02-17 12:28 +0000
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-17 14:05 +0000
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-17 09:49 -0600
Re: CASE mis-understanding? Bernd Paysan <bernd.paysan@gmx.de> - 2014-02-17 19:06 +0100
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-17 12:52 -0600
Re: CASE mis-understanding? Bernd Paysan <bernd.paysan@gmx.de> - 2014-02-17 22:51 +0100
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-18 04:36 -0600
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-18 09:34 +0000
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-18 05:01 -0600
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-18 14:19 +0000
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-02-18 08:28 -0800
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-18 17:14 +0000
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-02-18 11:46 -0800
Re: CASE mis-understanding? "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-02-18 18:20 -0500
Re: CASE mis-understanding? Bernd Paysan <bernd.paysan@gmx.de> - 2014-02-19 17:10 +0100
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-02-19 23:17 -0800
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-20 09:55 -0600
Re: CASE mis-understanding? Bernd Paysan <bernd.paysan@gmx.de> - 2014-02-21 20:15 +0100
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-22 12:08 +0000
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-02-22 14:45 -0800
Re: CASE mis-understanding? Bernd Paysan <bernd.paysan@gmx.de> - 2014-02-23 02:29 +0100
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-02-22 21:29 -0800
Re: CASE mis-understanding? Bernd Paysan <bernd.paysan@gmx.de> - 2014-02-23 22:33 +0100
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-02-23 22:13 -0800
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-24 17:30 +0000
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-02-24 14:38 -0800
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-26 12:59 +0000
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-02-26 20:12 -0800
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-27 04:54 -0600
Re: CASE mis-understanding? Lars Brinkhoff <lars.spam@nocrew.org> - 2014-02-27 12:56 +0100
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-27 06:30 -0600
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-02-27 05:29 -0800
Re: CASE mis-understanding? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-02-27 15:48 +0000
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-02-27 08:13 -0800
Re: CASE mis-understanding? "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-02-27 16:23 -0500
Re: CASE mis-understanding? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-02-28 11:21 +0000
Re: CASE mis-understanding? "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-02-28 16:20 -0500
Re: CASE mis-understanding? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-03-01 01:51 +0000
Re: CASE mis-understanding? "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-02-28 23:36 -0500
Re: CASE mis-understanding? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-03-01 12:45 +0000
Re: CASE mis-understanding? Lars Brinkhoff <lars.spam@nocrew.org> - 2014-03-01 13:59 +0100
Re: CASE mis-understanding? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-03-01 13:03 +0000
Re: CASE mis-understanding? "Alex McDonald" <blog@rivadpm.com> - 2014-03-01 07:53 +0000
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-27 10:12 -0600
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-02-27 08:46 -0800
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-27 10:56 -0600
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-02-27 10:08 -0800
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-02-27 11:01 -0800
Re: CASE mis-understanding? "Elizabeth D. Rather" <erather@forth.com> - 2014-02-27 08:12 -1000
Re: CASE mis-understanding? "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-02-27 16:23 -0500
Re: CASE mis-understanding? Lars Brinkhoff <lars.spam@nocrew.org> - 2014-02-27 19:53 +0100
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-02-27 07:48 -0800
Re: CASE mis-understanding? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-02-27 16:05 +0000
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-02-27 08:27 -0800
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-27 10:45 -0600
Re: CASE mis-understanding? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-02-27 20:51 +0000
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-03-01 08:46 -0600
Re: CASE mis-understanding? "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-03-01 16:53 -0500
Re: CASE mis-understanding? "Elizabeth D. Rather" <erather@forth.com> - 2014-03-01 15:06 -1000
Re: CASE mis-understanding? Bernd Paysan <bernd.paysan@gmx.de> - 2014-03-04 01:50 +0100
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-03-03 17:18 -0800
Re: CASE mis-understanding? Bernd Paysan <bernd.paysan@gmx.de> - 2014-03-04 02:51 +0100
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-03-04 03:20 -0600
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-03-04 19:12 -0800
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-03-05 03:51 -0600
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-03-04 10:11 +0000
Re: CASE mis-understanding? Bernd Paysan <bernd.paysan@gmx.de> - 2014-03-05 14:09 +0100
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-03-01 11:20 -0800
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-03-01 15:43 -0600
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-03-01 22:16 -0800
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-03-02 04:56 -0600
Re: CASE mis-understanding? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-03-02 14:07 +0000
Re: CASE mis-understanding? Mark Wills <markwills1970@gmail.com> - 2014-03-03 00:59 -0800
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-03-02 08:20 -0800
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-03-03 03:03 -0600
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-03-06 18:09 +0000
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-03-06 17:26 -0600
WITHIN (was: CASE mis-understanding?) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-03-07 12:51 +0000
Re: WITHIN Paul Rubin <no.email@nospam.invalid> - 2014-03-07 12:13 -0800
Re: WITHIN mhx@iae.nl - 2014-03-08 05:07 -0800
Re: WITHIN anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-03-08 15:43 +0000
Re: WITHIN mhx@iae.nl - 2014-03-08 08:23 -0800
Re: WITHIN anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-03-08 16:37 +0000
Re: WITHIN mhx@iae.nl - 2014-03-08 10:18 -0800
Re: WITHIN mhx@iae.nl - 2014-03-08 10:48 -0800
Re: WITHIN anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-03-08 16:02 +0000
Re: WITHIN Paul Rubin <no.email@nospam.invalid> - 2014-03-09 01:24 -0800
Re: WITHIN anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-03-09 18:16 +0000
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-03-06 21:46 -0800
Re: CASE mis-understanding? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-03-07 09:22 +0000
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-03-07 12:28 +0000
Re: CASE mis-understanding? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-03-07 19:36 +0000
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-03-06 18:25 +0000
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-03-06 23:52 -0800
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-03-07 10:15 +0000
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-03-07 08:38 -0800
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-03-07 09:36 -0800
Re: CASE mis-understanding? hughaguilar96@yahoo.com - 2014-03-02 20:16 -0800
Re: CASE mis-understanding? "Elizabeth D. Rather" <erather@forth.com> - 2014-02-27 08:18 -1000
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-03-07 13:21 +0000
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-03-07 08:26 -0600
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-27 10:37 -0600
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-03-01 11:31 -0800
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-03-07 13:18 +0000
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-03-07 11:17 -0800
Re: CASE mis-understanding? Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2014-03-09 20:49 +0000
Re: CASE mis-understanding? "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-02-27 16:22 -0500
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-28 15:22 +0000
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-28 18:32 +0000
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-03-01 03:39 -0800
Re: CASE mis-understanding? Bernd Paysan <bernd.paysan@gmx.de> - 2014-03-04 02:19 +0100
Re: CASE mis-understanding? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-02-27 13:03 +0000
Re: CASE mis-understanding? "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-02-24 01:25 -0500
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-24 03:36 -0600
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-02-24 02:04 -0800
Re: CASE mis-understanding? Bernd Paysan <bernd.paysan@gmx.de> - 2014-03-04 01:15 +0100
Re: CASE mis-understanding? Julian Fondren <julian.fondren@gmail.com> - 2014-02-22 21:09 -0800
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-02-22 21:55 -0800
Re: CASE mis-understanding? Julian Fondren <julian.fondren@gmail.com> - 2014-02-23 00:47 -0800
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-02-23 01:45 -0800
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-20 17:07 +0000
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-02-20 16:03 -0800
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-21 04:11 -0600
Re: CASE mis-understanding? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-02-21 10:59 +0000
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-02-21 03:26 -0800
Re: CASE mis-understanding? stephenXXX@mpeforth.com (Stephen Pelc) - 2014-02-21 10:34 +0000
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-21 05:49 -0600
Re: CASE mis-understanding? stephenXXX@mpeforth.com (Stephen Pelc) - 2014-02-22 13:52 +0000
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-22 09:13 -0600
Re: CASE mis-understanding? "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-02-22 10:45 -0500
Re: CASE mis-understanding? hughaguilar96@yahoo.com - 2014-02-21 20:18 -0800
Re: CASE mis-understanding? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-02-22 15:24 +0000
Re: CASE mis-understanding? "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-02-22 10:37 -0500
Re: CASE mis-understanding? "WJ" <w_a_x_man@yahoo.com> - 2014-03-11 03:20 +0000
Re: CASE mis-understanding? "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-03-11 16:15 -0400
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-03-12 00:10 -0700
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-22 13:28 +0000
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-22 08:56 -0600
Re: CASE mis-understanding? Bernd Paysan <bernd.paysan@gmx.de> - 2014-02-23 01:27 +0100
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-23 04:33 -0600
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-02-23 08:11 -0800
Re: CASE mis-understanding? Bernd Paysan <bernd.paysan@gmx.de> - 2014-02-23 21:44 +0100
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-02-23 22:48 -0800
Re: CASE mis-understanding? Bernd Paysan <bernd.paysan@gmx.de> - 2014-03-04 02:23 +0100
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-24 16:05 +0000
Re: CASE mis-understanding? Tristan Plumb <firth@trstn.net> - 2014-02-24 18:15 +0000
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-24 18:45 +0000
Re: CASE mis-understanding? Tristan Plumb <firth@trstn.net> - 2014-02-24 19:18 +0000
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-26 12:40 +0000
Re: CASE mis-understanding? Tristan Plumb <st@trstn.net> - 2014-02-26 15:27 +0000
Re: CASE mis-understanding? Bernd Paysan <bernd.paysan@gmx.de> - 2014-03-04 01:31 +0100
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-03-04 16:30 +0000
Re: CASE mis-understanding? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-03-05 11:48 +0000
Re: CASE mis-understanding? hughaguilar96@yahoo.com - 2014-02-22 18:28 -0800
Re: CASE mis-understanding? Gary Bergstrom <forthprgrmr@gmail.com> - 2014-02-24 08:39 -0800
Re: CASE mis-understanding? hughaguilar96@yahoo.com - 2014-02-24 21:29 -0800
Re: CASE mis-understanding? "WJ" <w_a_x_man@yahoo.com> - 2014-03-11 00:44 +0000
Re: CASE mis-understanding? "WJ" <w_a_x_man@yahoo.com> - 2014-03-11 00:45 +0000
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-23 04:35 -0600
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-18 12:31 -0600
Re: CASE mis-understanding? "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-02-18 18:19 -0500
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-18 11:06 -0600
Re: CASE mis-understanding? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-02-18 12:51 +0000
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-18 14:40 +0000
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-18 08:17 +0000
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-18 04:48 -0600
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-18 13:56 +0000
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-18 11:15 -0600
Re: CASE mis-understanding? "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-02-18 18:24 -0500
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-19 03:46 -0600
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-21 15:52 +0000
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-22 09:10 -0600
Re: CASE mis-understanding? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-02-18 13:09 +0000
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-18 15:03 +0000
Re: CASE mis-understanding? hughaguilar96@yahoo.com - 2014-02-13 15:53 -0800
Re: CASE mis-understanding? Bernd Paysan <bernd.paysan@gmx.de> - 2014-02-14 00:39 +0100
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-14 06:38 -0600
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-15 15:37 +0000
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-15 13:33 -0600
Re: CASE mis-understanding? Roelf Toxopeus <rt4all@notthis.hetnet.nl> - 2014-02-11 10:50 +0100
Re: CASE mis-understanding? stephenXXX@mpeforth.com (Stephen Pelc) - 2014-02-11 10:57 +0000
Re: CASE mis-understanding? Paul Rubin <no.email@nospam.invalid> - 2014-02-11 02:35 -0800
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-11 11:47 +0000
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-11 13:08 +0000
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-11 18:42 -0600
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-12 10:54 +0000
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-12 05:31 -0600
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-12 15:52 +0000
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-12 10:41 -0600
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-13 09:27 +0000
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-02-13 04:49 -0600
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-13 13:54 +0000
Re: CASE mis-understanding? mhx@iae.nl - 2014-02-03 12:26 -0800
Re: CASE mis-understanding? "Ed" <invalid@invalid.com> - 2014-02-07 13:41 +1100
Re: CASE mis-understanding? m.a.m.hendrix@tue.nl - 2014-02-07 01:08 -0800
Re: CASE mis-understanding? "Ed" <invalid@invalid.com> - 2014-02-08 09:56 +1100
Re: CASE mis-understanding? "Alex McDonald" <blog@rivadpm.com> - 2014-02-07 12:15 +0000
Re: CASE mis-understanding? "Ed" <invalid@invalid.com> - 2014-02-01 00:39 +1100
Re: CASE mis-understanding? m.a.m.hendrix@tue.nl - 2014-01-31 07:29 -0800
Re: CASE mis-understanding? "Ed" <invalid@invalid.com> - 2014-02-04 23:45 +1100
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-31 16:31 +0000
Re: CASE mis-understanding? "Ed" <invalid@invalid.com> - 2014-02-03 12:35 +1100
Re: CASE mis-understanding? "Alex McDonald" <blog@rivadpm.com> - 2014-02-03 09:32 +0000
Re: CASE mis-understanding? "Ed" <invalid@invalid.com> - 2014-02-08 09:31 +1100
Re: CASE mis-understanding? "Alex McDonald" <blog@rivadpm.com> - 2014-02-08 11:22 +0000
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-02-03 13:54 +0000
Re: CASE mis-understanding? "Elizabeth D. Rather" <erather@forth.com> - 2014-01-31 08:40 -1000
Re: CASE mis-understanding? Mikael Nordman <oh2aun@gmail.com> - 2014-01-26 22:03 -0800
Re: CASE mis-understanding? julian.fondren@gmail.com - 2014-01-29 17:19 -0800
Re: CASE mis-understanding? Mikael Nordman <oh2aun@gmail.com> - 2014-01-30 11:15 -0800
Re: CASE mis-understanding? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-27 13:57 +0000
Re: CASE mis-understanding? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-01-28 14:01 +0000
Re: CASE mis-understanding? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-01-28 14:49 +0000
Re: CASE mis-understanding? "Ed" <invalid@invalid.com> - 2014-01-29 10:07 +1100
Re: CASE mis-understanding? hughaguilar96@yahoo.com - 2014-01-28 21:54 -0800
Re: CASE mis-understanding? Stefan Mauerhofer <smauerhofer@androsoft.ch> - 2014-01-29 00:33 -0800
Re: CASE mis-understanding? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-01-29 03:37 -0600
Re: CASE mis-understanding? hughaguilar96@yahoo.com - 2014-01-30 21:51 -0800
Re: CASE mis-understanding? "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-01-31 18:44 -0500
Re: CASE mis-understanding? David Thompson <dave.thompson2@verizon.net> - 2014-02-09 00:34 -0500
Re: CASE mis-understanding? "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-02-09 22:14 -0500
Re: CASE mis-understanding? "WJ" <w_a_x_man@yahoo.com> - 2014-03-11 01:25 +0000
Re: CASE mis-understanding? Julian Fondren <julian.fondren@gmail.com> - 2014-01-31 17:44 -0800
Re: CASE mis-understanding? "Elizabeth D. Rather" <erather@forth.com> - 2014-01-31 16:03 -1000
Re: CASE mis-understanding? hughaguilar96@yahoo.com - 2014-02-01 01:55 -0800
Re: CASE mis-understanding? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-02-01 11:34 +0000
Re: CASE mis-understanding? "Elizabeth D. Rather" <erather@forth.com> - 2014-02-01 08:11 -1000
Re: CASE mis-understanding? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-02-02 14:28 +0000
Re: CASE mis-understanding? hughaguilar96@yahoo.com - 2014-02-02 18:28 -0800
Re: CASE mis-understanding? "Ed" <invalid@invalid.com> - 2014-02-07 13:34 +1100
Re: CASE mis-understanding? Bernd Paysan <bernd.paysan@gmx.de> - 2014-02-07 03:52 +0100
Re: CASE mis-understanding? "Ed" <invalid@invalid.com> - 2014-02-08 09:41 +1100
Re: CASE mis-understanding? "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-02-07 18:33 -0500
Re: CASE mis-understanding? Coos Haak <chforth@hccnet.nl> - 2014-02-08 00:31 +0100
Re: CASE mis-understanding? "Alex McDonald" <blog@rivadpm.com> - 2014-02-08 11:21 +0000
Re: CASE mis-understanding? Bernd Paysan <bernd.paysan@gmx.de> - 2014-02-08 15:03 +0100
Re: CASE mis-understanding? hughaguilar96@yahoo.com - 2014-02-08 19:58 -0800
Re: CASE mis-understanding? "Alex McDonald" <blog@rivadpm.com> - 2014-02-09 08:33 +0000
Re: CASE mis-understanding? hughaguilar96@yahoo.com - 2014-02-09 19:50 -0800
Re: CASE mis-understanding? "Alex McDonald" <blog@rivadpm.com> - 2014-02-10 08:42 +0000
Re: CASE mis-understanding? hughaguilar96@yahoo.com - 2014-02-13 16:32 -0800
Re: CASE mis-understanding? Coos Haak <chforth@hccnet.nl> - 2014-02-14 02:36 +0100
Re: CASE mis-understanding? hughaguilar96@yahoo.com - 2014-02-13 23:04 -0800
Re: CASE mis-understanding? hughaguilar96@yahoo.com - 2014-02-13 23:40 -0800
Re: CASE mis-understanding? "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-02-14 04:37 -0500
Re: CASE mis-understanding? "Elizabeth D. Rather" <erather@forth.com> - 2014-02-14 09:42 -1000
Re: CASE mis-understanding? hughaguilar96@yahoo.com - 2014-02-15 16:52 -0800
Re: CASE mis-understanding? "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-02-16 07:46 -0500
Re: CASE mis-understanding? "Elizabeth D. Rather" <erather@forth.com> - 2014-02-16 08:11 -1000
Re: CASE mis-understanding? hughaguilar96@yahoo.com - 2014-02-16 16:15 -0800
Re: CASE mis-understanding? Lars Brinkhoff <lars.spam@nocrew.org> - 2014-02-17 09:03 +0100
Re: CASE mis-understanding? "Elizabeth D. Rather" <erather@forth.com> - 2014-02-16 22:12 -1000
Re: CASE mis-understanding? m.a.m.hendrix@tue.nl - 2014-02-17 02:29 -0800
Re: CASE mis-understanding? Alex McDonald <blog@rivadpm.com> - 2014-02-17 04:27 -0800
Re: CASE mis-understanding? "Elizabeth D. Rather" <erather@forth.com> - 2014-02-17 09:36 -1000
Re: CASE mis-understanding? "Elizabeth D. Rather" <erather@forth.com> - 2014-02-17 09:22 -1000
Re: CASE mis-understanding? Alex McDonald <blog@rivadpm.com> - 2014-02-17 12:06 -0800
Re: CASE mis-understanding? hughaguilar96@yahoo.com - 2014-02-17 20:18 -0800
Re: CASE mis-understanding? "WJ" <w_a_x_man@yahoo.com> - 2014-03-11 01:48 +0000
Re: CASE mis-understanding? "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-03-11 16:10 -0400
Re: CASE mis-understanding? "Alex McDonald" <blog@rivadpm.com> - 2014-02-14 13:54 +0000
Re: CASE mis-understanding? "Elizabeth D. Rather" <erather@forth.com> - 2014-02-06 17:03 -1000
Re: CASE mis-understanding? "Ed" <invalid@invalid.com> - 2014-02-08 09:39 +1100
Re: CASE mis-understanding? hughaguilar96@yahoo.com - 2014-02-07 20:12 -0800
Re: CASE mis-understanding? "Alex McDonald" <blog@rivadpm.com> - 2014-02-09 21:33 +0000
Re: CASE mis-understanding? Mark Wills <markrobertwills@yahoo.co.uk> - 2014-01-24 02:38 -0800
Re: CASE mis-understanding? Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2014-01-24 16:17 +0000
Re: CASE mis-understanding? Mark Wills <markrobertwills@yahoo.co.uk> - 2014-01-24 08:54 -0800
Re: CASE mis-understanding? "Elizabeth D. Rather" <erather@forth.com> - 2014-01-24 09:25 -1000
Re: CASE mis-understanding? Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2014-01-24 20:34 +0000
Re: CASE mis-understanding? "Elizabeth D. Rather" <erather@forth.com> - 2014-01-24 11:13 -1000
Re: CASE mis-understanding? "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-01-24 17:39 -0500
Re: CASE mis-understanding? Mark Wills <markrobertwills@yahoo.co.uk> - 2014-01-24 16:05 -0800
Re: CASE mis-understanding? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-01-25 11:46 +0000
Re: CASE mis-understanding? Mark Wills <markrobertwills@yahoo.co.uk> - 2014-01-25 16:15 -0800
Re: CASE mis-understanding? Bernd Paysan <bernd.paysan@gmx.de> - 2014-01-26 01:59 +0100
Page 3 of 21 — ← Prev page 1 2 [3] 4 5 … 21 Next page →
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2014-01-23 03:22 -0800 |
| Message-ID | <7xeh3zhriu.fsf@ruckus.brouhaha.com> |
| In reply to | #28017 |
stephenXXX@mpeforth.com (Stephen Pelc) writes:
> I last checked linear table search performance against the test/jump
> pair performance 10-15 years ago on the then current x86
> implementation. From memory, there was not a lot of difference.
From http://prog21.dadgum.com/166.html :
The possibilities when compiling a switch are much more varied. It
can result in a trivial series of if..else statements. It can result
in a binary search. Or, if the values are consecutive, a jump
table. Or for a complex sequence, some combination of these
techniques. If each case simply assigns a different value to the
same variable, then it can be implemented as a range check and array
lookup. The overall sweep of the solutions, from hundreds of
sequential, mispredicted comparisons to a single memory read, is
substantial.
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-01-23 06:52 -0600 |
| Message-ID | <sKKdnRdNf70RjXzPnZ2dnUVZ_vCdnZ2d@supernews.com> |
| In reply to | #28017 |
Stephen Pelc <stephenXXX@mpeforth.com> wrote: > On Thu, 23 Jan 2014 03:43:23 -0600, Andrew Haley > <andrew29@littlepinkcloud.invalid> wrote: > >>CASE looks nice at first glance, but there are some hidden gotchas. >>I've always been uncomfortable with it. It's evaluated serially by >>definition, so it's less efficient than equivalents in other >>languages. (It's possible for an optimizer to determine that each key >>is constant, unique and has no side effects and evaluate the statement >>with a jump table, but that's a lot of work. I don't know if any >>system does it.) >> >>There are many other ways to do multi-way branches in Forth. However, >>they tend to be rather specific to the problem in question: you might >>have a simple range of 0...N, in which case a simple execution vector >>is needed, or a lookup table if the keys are sparse, or maybe a couple >>of conditional branches if there are few keys, etc, etc. > > I'm surprised to find you espousing complexity before coming back to > the traditional Forth of simple specifics. No, quite the reverse: CASE is rather too complex for my taste. > I last checked linear table search performance against the test/jump > pair performance 10-15 years ago on the then current x86 > implementation. From memory, there was not a lot of difference. > Cache architectures are somewhat different now. Indeed so. I suspect that on highly-pipelined architectures the time is dominated by branch misprediction. > For application programmers, the Eaker CASE has the advantage of > producing simple, reliable and maintainable source code. That depends on who uses it: if it's just a matter of a few cases then a few conditional branches are harmless and may well play nicely with branch prediction. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2014-01-23 16:03 +0100 |
| Message-ID | <lbrb0k$g65$1@online.de> |
| In reply to | #28017 |
Stephen Pelc wrote: > I last checked linear table search performance against the test/jump > pair performance 10-15 years ago on the then current x86 > implementation. From memory, there was not a lot of difference. > Cache architectures are somewhat different now. If you want performance, you have two cases: dense case statements, which can be implemented as jump-table, i.e. O(1), and sparse case statements, which can be implemented as tree search, i.e. O(log n). The typical problem on current architectures is that branch misses cause significant delay, so the constant overhead of both operations is quite large compared to the sequential test jump pair, which has one misspredicted branch (the hit). So the jump table wins (because it has one mispredicted branch in the typical case, and no other branches), but the binary tree search needs a sufficiently large tree to win - and you should use a higher fanout tree to balance correctly predicted missing test/jump sequences with the cost of the one mispredicted branch that takes you one level down the tree. Rule of thumb on a Core i7 would be ~40 test/jump per tree level (i.e. on average 20 test/jumps). That's quite a lot, and certainly more than the average case statement. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-01-23 10:14 -0600 |
| Message-ID | <teGdnWTpFK9ronzPnZ2dnUVZ_u6dnZ2d@supernews.com> |
| In reply to | #28030 |
Bernd Paysan <bernd.paysan@gmx.de> wrote: > Stephen Pelc wrote: > >> I last checked linear table search performance against the test/jump >> pair performance 10-15 years ago on the then current x86 >> implementation. From memory, there was not a lot of difference. >> Cache architectures are somewhat different now. > > If you want performance, you have two cases: dense case statements, > which can be implemented as jump-table, i.e. O(1), and sparse case > statements, which can be implemented as tree search, i.e. O(log n). Or as a hash table, O(1). Andrew. "A Superoptimizer Analysis of Multiway Branch Code Generation" Roger A. Sayle, Proc. GCC summit 2008. www.gccsummit.org/2008/gcc-2008-proceedings.pdf
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-01-23 17:42 +0000 |
| Message-ID | <2014Jan23.184245@mips.complang.tuwien.ac.at> |
| In reply to | #28030 |
Bernd Paysan <bernd.paysan@gmx.de> writes:
>Stephen Pelc wrote:
>
>> I last checked linear table search performance against the test/jump
>> pair performance 10-15 years ago on the then current x86
>> implementation. From memory, there was not a lot of difference.
>> Cache architectures are somewhat different now.
>
>If you want performance, you have two cases: dense case statements, which
>can be implemented as jump-table, i.e. O(1), and sparse case statements,
>which can be implemented as tree search, i.e. O(log n). The typical problem
>on current architectures is that branch misses cause significant delay, so
>the constant overhead of both operations is quite large compared to the
>sequential test jump pair, which has one misspredicted branch (the hit). So
>the jump table wins (because it has one mispredicted branch in the typical
>case, and no other branches), but the binary tree search needs a
>sufficiently large tree to win - and you should use a higher fanout tree to
>balance correctly predicted missing test/jump sequences with the cost of the
>one mispredicted branch that takes you one level down the tree. Rule of
>thumb on a Core i7 would be ~40 test/jump per tree level (i.e. on average 20
>test/jumps). That's quite a lot, and certainly more than the average case
>statement.
In order to make statements on what approach wins, you need to know
something about the values that switch works on. If you assume that
each switch is totally random, then the indirect branch is pretty
good, because it misses at most once, whereas sequential search and
search tree may miss more than once (at least if there are more than
two cases). But if consecutive switch values are correlated, that's
much harder to evaluate, and it depends on how the values correlate
and whether the branch predictors can capture that.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2013: http://www.euroforth.org/ef13/
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2014-01-23 10:42 -0800 |
| Message-ID | <7xob32sfp5.fsf@ruckus.brouhaha.com> |
| In reply to | #28030 |
Bernd Paysan <bernd.paysan@gmx.de> writes: > If you want performance, you have two cases: dense case statements, which > can be implemented as jump-table, i.e. O(1), and sparse case statements, > which can be implemented as tree search, i.e. O(log n). I wonder if anyone uses perfect hashing for sparse case statements, O(1).
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2014-01-24 15:01 +0100 |
| Message-ID | <lbtrq4$nq7$1@online.de> |
| In reply to | #28036 |
Paul Rubin wrote: > Bernd Paysan <bernd.paysan@gmx.de> writes: >> If you want performance, you have two cases: dense case statements, which >> can be implemented as jump-table, i.e. O(1), and sparse case statements, >> which can be implemented as tree search, i.e. O(log n). > > I wonder if anyone uses perfect hashing for sparse case statements, O(1). There's a paper on gperf that shows that some applications gain about 10% in speed with perfect hasing. However, gperf is designed to generate perfect hashes for strings, not for integers. As string comparison takes more time than a simple integer comparison, it really does make sense to optimize this stuff. For integers and perfect hashing, I would use the following generic algorithm: : phash#x#n ( value hashsel -- ) * #n rshift $x and ; $x is the next power of two -1 of the number space, and the search for the best hashsel is to randomly choose values until you find some without colissions. Each matching statement still needs to compare against the desired value and the ELSE case is the default case. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-01-23 17:21 +0000 |
| Message-ID | <2014Jan23.182124@mips.complang.tuwien.ac.at> |
| In reply to | #28015 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Elizabeth D. Rather <erather@forth.com> wrote:
>>
>> Back in the stone ages, the Forth Interest Group held a contest for
>> a case statement. This version, contributed by a man named Eaker,
>> won. Everyone ever since has hated the fact that ENDCASE does a
>> drop (believe me, *everyone* makes this mistake at lease once), but
>> we were all so burned by the gratuitous changes made by Forth83
>> (discussed in the "PICK changed..." thread) that no one has dared
>> change it.
>
>CASE looks nice at first glance, but there are some hidden gotchas.
>I've always been uncomfortable with it. It's evaluated serially by
>definition, so it's less efficient than equivalents in other
>languages.
In my course on efficient programs, this year the students have to
optimize a program that mainly uses flex, which generates switch
statements. A number of students optimized the resulting program by
reordering the cases of the switch statement; apparently their mental
model of the switch statement is that it generates an if cascade
(while my mental model is that it generates an indirect branch (at
least in the dense case), and that the order of cases does not
matter).
So Eaker's CASE matches the expectations that non-compiler people
have, and that's a good property. So if they want an indirect branch,
they can and will code up something with EXECUTE, like we do. Or one
might consider the stuff that PAF
<http://www.complang.tuwien.ac.at/anton/euroforth/ef13/papers/ertl-paf.pdf>
has for indirect branches within a colon definition.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2013: http://www.euroforth.org/ef13/
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-01-23 12:16 -0600 |
| Message-ID | <7eSdneFEM7EVwXzPnZ2dnUVZ_q2dnZ2d@supernews.com> |
| In reply to | #28033 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>Elizabeth D. Rather <erather@forth.com> wrote: >>> >>> Back in the stone ages, the Forth Interest Group held a contest for >>> a case statement. This version, contributed by a man named Eaker, >>> won. Everyone ever since has hated the fact that ENDCASE does a >>> drop (believe me, *everyone* makes this mistake at lease once), but >>> we were all so burned by the gratuitous changes made by Forth83 >>> (discussed in the "PICK changed..." thread) that no one has dared >>> change it. >> >>CASE looks nice at first glance, but there are some hidden gotchas. >>I've always been uncomfortable with it. It's evaluated serially by >>definition, so it's less efficient than equivalents in other >>languages. > > In my course on efficient programs, this year the students have to > optimize a program that mainly uses flex, which generates switch > statements. A number of students optimized the resulting program by > reordering the cases of the switch statement; apparently their mental > model of the switch statement is that it generates an if cascade > (while my mental model is that it generates an indirect branch (at > least in the dense case), and that the order of cases does not > matter). I suppose that's why you're there to educate them. > So Eaker's CASE matches the expectations that non-compiler people > have, and that's a good property. Well, hold on: you can't generalize directly from your students to all non-compiler people. C programmers will usually know, I think, that a switch may generate some kind of a jump table, and that the compiler will pick the best strategy. That's just a guess, and my colleagues may be a cut above the average. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-01-24 09:25 +0000 |
| Message-ID | <2014Jan24.102538@mips.complang.tuwien.ac.at> |
| In reply to | #28035 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> In my course on efficient programs, this year the students have to
>> optimize a program that mainly uses flex, which generates switch
>> statements. A number of students optimized the resulting program by
>> reordering the cases of the switch statement; apparently their mental
>> model of the switch statement is that it generates an if cascade
>> (while my mental model is that it generates an indirect branch (at
>> least in the dense case), and that the order of cases does not
>> matter).
>
>I suppose that's why you're there to educate them.
Really? Nearly everyone loves to abstract away from the low-level
stuff, including C compiler maintainers. I know one who wrote that I
should not expect any particular mapping from C language features to
machine features. So why should I teach them my expectations of what
a C compiler should do?
Anyway, even if I tell them something about C's switch, it will not
help them when they come across some other C feature or other language
feature, library feature, or operating system feature. Most don't
document the performance characteristics of the feature; educators can
only teach about a limited number of features, so I think that putting
the responsibility for distributing that knowledge on them is not a
general solution.
>> So Eaker's CASE matches the expectations that non-compiler people
>> have, and that's a good property.
>
>Well, hold on: you can't generalize directly from your students to all
>non-compiler people. C programmers will usually know, I think, that a
>switch may generate some kind of a jump table, and that the compiler
>will pick the best strategy. That's just a guess, and my colleagues
>may be a cut above the average.
My students are those who are interested in efficient programs
(otherwise they would not have elected to take my course), so I guess
that they are above average in that respect. Maybe this is just a
failure of the courses in my university and every other computer
science program in the world teaches that C's switch is compiled into
an indirect branch on the machine level, but from what I hear, I doubt
it. The trend seems to be not to teach anything about the machine
level at all (and that includes my university).
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2013: http://www.euroforth.org/ef13/
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-01-24 07:16 -0600 |
| Message-ID | <ycWdnUx0-981-n_PnZ2dnUVZ_vednZ2d@supernews.com> |
| In reply to | #28054 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >>> In my course on efficient programs, this year the students have to >>> optimize a program that mainly uses flex, which generates switch >>> statements. A number of students optimized the resulting program by >>> reordering the cases of the switch statement; apparently their mental >>> model of the switch statement is that it generates an if cascade >>> (while my mental model is that it generates an indirect branch (at >>> least in the dense case), and that the order of cases does not >>> matter). >> >>I suppose that's why you're there to educate them. > > Really? Well, yes. You're lecturing to them. > Nearly everyone loves to abstract away from the low-level stuff, > including C compiler maintainers. I know one who wrote that I > should not expect any particular mapping from C language features to > machine features. So why should I teach them my expectations of > what a C compiler should do? Because they have a *false* notion. All you have to say is "It ain't necessarily so." Much harm is done by programmers avoiding constructs because "they're slow": "double-checked locking" is one famous example. Besides, you're perfectly happy to correct people's false notions here, and I can't see any good reason for you to restrict your wisdom to c.l.f. > Anyway, even if I tell them something about C's switch, it will not > help them when they come across some other C feature or other > language feature, library feature, or operating system feature. Yes, it will, if you teach the principle; surely education isn't about teaching all the special cases, but about the concepts. > Most don't document the performance characteristics of the feature; > educators can only teach about a limited number of features, so I > think that putting the responsibility for distributing that > knowledge on them is not a general solution. That's not a good argument against correcting students' untrue ideas, though. >>> So Eaker's CASE matches the expectations that non-compiler people >>> have, and that's a good property. >> >>Well, hold on: you can't generalize directly from your students to all >>non-compiler people. C programmers will usually know, I think, that a >>switch may generate some kind of a jump table, and that the compiler >>will pick the best strategy. That's just a guess, and my colleagues >>may be a cut above the average. > > My students are those who are interested in efficient programs > (otherwise they would not have elected to take my course), so I guess > that they are above average in that respect. Maybe this is just a > failure of the courses in my university and every other computer > science program in the world teaches that C's switch is compiled into > an indirect branch on the machine level, No, I didn't say that. I said it may generate some kind of a jump table. > but from what I hear, I doubt it. The trend seems to be not to > teach anything about the machine level at all (and that includes my > university). Right, but I question whether it makes sense to design everythin on the basis of the inadequacies of universities. To paraphrase Dijkstra, that's like rejecting a surgical technique because it is beyond the capabilities of the barber in his shop around the corner. We're going to need a new generation of people who do understand abstraction and how to apply it from the machine level up. If the universities won't do it, who will? Andrew. http://www.cs.utexas.edu/users/EWD/transcriptions/EWD05xx/EWD512.html
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <markrobertwills@yahoo.co.uk> |
|---|---|
| Date | 2014-01-24 05:43 -0800 |
| Message-ID | <fce62c2e-4361-437b-b93a-edb22aa76e87@googlegroups.com> |
| In reply to | #28062 |
On Friday, January 24, 2014 1:16:24 PM UTC, Andrew Haley wrote: > http://www.cs.utexas.edu/users/EWD/transcriptions/EWD05xx/EWD512.html "In the name of justice and equality, the bright pupils are no longer allowed to understand what the stupid ones cannot grasp..." Oh, there speaks a wise man.
[toc] | [prev] | [next] | [standalone]
| From | mhx@iae.nl |
|---|---|
| Date | 2014-01-24 10:57 -0800 |
| Message-ID | <4ba538c3-e17b-467c-8219-2217594c7487@googlegroups.com> |
| In reply to | #28062 |
On Friday, January 24, 2014 2:16:24 PM UTC+1, Andrew Haley wrote: [..] > http://www.cs.utexas.edu/users/EWD/transcriptions/EWD05xx/EWD512.html I like this one. Sounds familiar, doesn't it ... EWD: "We have to learn to avoid all forms of combinatorial complexity generators that when active rapidly tax our ability to carry out a case-analysis far beyond the limits of our power of reasoning. To recognise the emergence of a combinatorial complexity generator long before it has poisoned your design beyond salvation requires constant vigilance, a vigilance that can and should be taught." -marcel
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-01-25 03:58 -0600 |
| Message-ID | <m6idncNWRKNQF37PnZ2dnUVZ_hqdnZ2d@supernews.com> |
| In reply to | #28073 |
mhx@iae.nl wrote: > > I like this one. Sounds familiar, doesn't it ... > > EWD: > "We have to learn to avoid all forms of combinatorial complexity > generators that when active rapidly tax our ability to carry out > a case-analysis far beyond the limits of our power of reasoning. > To recognise the emergence of a combinatorial complexity generator > long before it has poisoned your design beyond salvation requires > constant vigilance, a vigilance that can and should be taught." It certainly does. Been there, done that, had to pick up the pieces. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-01-27 17:24 +0000 |
| Message-ID | <2014Jan27.182404@mips.complang.tuwien.ac.at> |
| In reply to | #28062 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>>> In my course on efficient programs, this year the students have to
>>>> optimize a program that mainly uses flex, which generates switch
>>>> statements. A number of students optimized the resulting program by
>>>> reordering the cases of the switch statement; apparently their mental
>>>> model of the switch statement is that it generates an if cascade
>>>> (while my mental model is that it generates an indirect branch (at
>>>> least in the dense case), and that the order of cases does not
>>>> matter).
>>>
>>>I suppose that's why you're there to educate them.
>>
>> Really?
>
>Well, yes. You're lecturing to them.
I covered lots of things in my lecture. The implementation of switch
was not among them. Not sure if it's significant enough to include it
next year; what should I throw out instead?
>> Nearly everyone loves to abstract away from the low-level stuff,
>> including C compiler maintainers. I know one who wrote that I
>> should not expect any particular mapping from C language features to
>> machine features. So why should I teach them my expectations of
>> what a C compiler should do?
>
>Because they have a *false* notion.
Really? Does it say so in the C standard? In the compiler's manual?
Anywhere? Why should I teach them what nobody wants to document?
>All you have to say is "It ain't
>necessarily so." Much harm is done by programmers avoiding constructs
>because "they're slow": "double-checked locking" is one famous example.
Not so famous that I knew it before; it's also not clear what
construct it avoids, and if that is not slow.
>Besides, you're perfectly happy to correct people's false notions
>here, and I can't see any good reason for you to restrict your wisdom
>to c.l.f.
Sure, in the appropriate situation I would have done that. But in an
exam-like situation I am more intent on evaluating what the students
say than on talking myself, so in this situation I did not do it.
Anyway, even if I had corrected that notion there and then, this would
have done nothing for all the other students in the world who did not
happen to be in that lecture room at that time.
>> Anyway, even if I tell them something about C's switch, it will not
>> help them when they come across some other C feature or other
>> language feature, library feature, or operating system feature.
>
>Yes, it will, if you teach the principle; surely education isn't about
>teaching all the special cases, but about the concepts.
Yes. So? What general concept do you think I should teach them that
would avoid that misconception.
>> Most don't document the performance characteristics of the feature;
>> educators can only teach about a limited number of features, so I
>> think that putting the responsibility for distributing that
>> knowledge on them is not a general solution.
>
>That's not a good argument against correcting students' untrue ideas,
>though.
It's also not a good argument against drug abuse. It was not intended
to be either.
>> My students are those who are interested in efficient programs
>> (otherwise they would not have elected to take my course), so I guess
>> that they are above average in that respect. Maybe this is just a
>> failure of the courses in my university and every other computer
>> science program in the world teaches that C's switch is compiled into
>> an indirect branch on the machine level,
>
>No, I didn't say that. I said it may generate some kind of a jump
>table.
What do you mean with "jump table"? Is there an indirect branch
involved, as in the Wikipedia entry, or not? If there is, why do you
make this distinction? Red herring?
>> but from what I hear, I doubt it. The trend seems to be not to
>> teach anything about the machine level at all (and that includes my
>> university).
>
>Right, but I question whether it makes sense to design everythin on
>the basis of the inadequacies of universities.
But that inadequacy just reflects the inadequacy of the industry, like
the C compiler maintainer who does not want to have a correspondence
between language features and machine-level features. If most of the
industry (even C compiler maintainers) thinks that this stuff is not
needed, why should the universities teach it?
>We're going to need a new generation of people who do understand
>abstraction and how to apply it from the machine level up. If the
>universities won't do it, who will?
What does "understand abstraction and how to apply it from the machine
level up" mean?
In any case, if you mean that universities should teach how the
higher-level stuff relates to machine-level stuff, then you should let
that be known to the universities (and not just to me, I am already in
favour of that). But you also need to support it in your work; the
documentation of some higher-level feature should not just be
abstract, but should also give an idea about the implementation and
its performance characteristics.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2013: http://www.euroforth.org/ef13/
[toc] | [prev] | [next] | [standalone]
| From | stephenXXX@mpeforth.com (Stephen Pelc) |
|---|---|
| Date | 2014-01-27 19:25 +0000 |
| Message-ID | <52e6b21a.552508148@news.demon.co.uk> |
| In reply to | #28129 |
On Mon, 27 Jan 2014 17:24:04 GMT, anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote: >If most of the >industry (even C compiler maintainers) thinks that this stuff is not >needed, why should the universities teach it? The universities should be teaching wat they believe to be right, even if that is later proven to be wrong. The universities come before industry. Stephen -- Stephen Pelc, stephenXXX@mpeforth.com MicroProcessor Engineering Ltd - More Real, Less Time 133 Hill Lane, Southampton SO15 5AF, England tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691 web: http://www.mpeforth.com - free VFX Forth downloads
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-01-28 03:34 -0600 |
| Message-ID | <D46dnWBmBPBe5HrPnZ2dnUVZ_o2dnZ2d@supernews.com> |
| In reply to | #28129 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >>>>> In my course on efficient programs, this year the students have to >>>>> optimize a program that mainly uses flex, which generates switch >>>>> statements. A number of students optimized the resulting program by >>>>> reordering the cases of the switch statement; apparently their mental >>>>> model of the switch statement is that it generates an if cascade >>>>> (while my mental model is that it generates an indirect branch (at >>>>> least in the dense case), and that the order of cases does not >>>>> matter). >>>> >>> Nearly everyone loves to abstract away from the low-level stuff, >>> including C compiler maintainers. I know one who wrote that I >>> should not expect any particular mapping from C language features to >>> machine features. So why should I teach them my expectations of >>> what a C compiler should do? >> >>Because they have a *false* notion. > > Really? Does it say so in the C standard? In the compiler's manual? > Anywhere? Why should I teach them what nobody wants to document? Because it's your job, I guess. Isn't this what universities are for? >>Besides, you're perfectly happy to correct people's false notions >>here, and I can't see any good reason for you to restrict your wisdom >>to c.l.f. > > Sure, in the appropriate situation I would have done that. But in an > exam-like situation I am more intent on evaluating what the students > say than on talking myself, so in this situation I did not do it. OK, fair enough. I don't know what the situation was. > Anyway, even if I had corrected that notion there and then, this > would have done nothing for all the other students in the world who > did not happen to be in that lecture room at that time. That's true, but it would surely be a start. >>> Anyway, even if I tell them something about C's switch, it will not >>> help them when they come across some other C feature or other >>> language feature, library feature, or operating system feature. >> >>Yes, it will, if you teach the principle; surely education isn't about >>teaching all the special cases, but about the concepts. > > Yes. So? What general concept do you think I should teach them that > would avoid that misconception. That there is no simple mapping from high-level constructs to what happens at the machine level. And, more generally, the "as if" principle as applied to programming languages. >>> My students are those who are interested in efficient programs >>> (otherwise they would not have elected to take my course), so I >>> guess that they are above average in that respect. Maybe this is >>> just a failure of the courses in my university and every other >>> computer science program in the world teaches that C's switch is >>> compiled into an indirect branch on the machine level, >> >>No, I didn't say that. I said it may generate some kind of a jump >>table. > > What do you mean with "jump table"? Is there an indirect branch > involved, as in the Wikipedia entry, or not? If there is, why do you > make this distinction? Red herring? I said that it may, not that it does. >>> but from what I hear, I doubt it. The trend seems to be not to >>> teach anything about the machine level at all (and that includes my >>> university). >> >>Right, but I question whether it makes sense to design everythin on >>the basis of the inadequacies of universities. > > But that inadequacy just reflects the inadequacy of the industry, like > the C compiler maintainer who does not want to have a correspondence > between language features and machine-level features. If most of the > industry (even C compiler maintainers) thinks that this stuff is not > needed, why should the universities teach it? There isn't a simple correspondence between language features and machine-level features. That's what students need to know. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2014-01-24 14:50 +0100 |
| Message-ID | <lbtr3v$md8$1@online.de> |
| In reply to | #28054 |
Anton Ertl wrote: > My students are those who are interested in efficient programs > (otherwise they would not have elected to take my course), so I guess > that they are above average in that respect. Maybe this is just a > failure of the courses in my university and every other computer > science program in the world teaches that C's switch is compiled into > an indirect branch on the machine level, but from what I hear, I doubt > it. The trend seems to be not to teach anything about the machine > level at all (and that includes my university). Ouch. When I studied at TU Munich, machine level was part of the beginner's four semester course. They had a VAX-based architecture for that part of the course, which did run in an awfully slow and bloated emulator (I much preferred optimizing code for the real machines), but this emulator even did a quad-core emulation, so the students could study multithreading (back then, even comparable expensive workstations had only one single CPU, not like today, where even a cheap mobile phone has at least a dual-core CPU...). My advise to your students is to compile the code with the -S switch (stopping at the assembler level), and look at the resulting file. That's what I use to optimize things, and that's what I recommend doing. The students will quickly find out that the case statement is converted to a jump table. For Gforth users, see-code is the word of choice to check what the compiler (in gforth-fast, the engine relevant for performance-sensitive stuff) actually does with the code. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-01-27 17:15 +0000 |
| Message-ID | <2014Jan27.181509@mips.complang.tuwien.ac.at> |
| In reply to | #28067 |
Bernd Paysan <bernd.paysan@gmx.de> writes:
>Anton Ertl wrote:
>> My students are those who are interested in efficient programs
>> (otherwise they would not have elected to take my course), so I guess
>> that they are above average in that respect. Maybe this is just a
>> failure of the courses in my university and every other computer
>> science program in the world teaches that C's switch is compiled into
>> an indirect branch on the machine level, but from what I hear, I doubt
>> it. The trend seems to be not to teach anything about the machine
>> level at all (and that includes my university).
>
>Ouch. When I studied at TU Munich, machine level was part of the beginner's
>four semester course.
At that time my university had such courses, too. But the times are
changing; actually there is still a course that includes some machine
level stuff in the first semester. But that stuff is being squeezed
out by all the new stuff students have to learn (UML, SOA, etc.).
>My advise to your students is to compile the code with the -S switch
>(stopping at the assembler level), and look at the resulting file. That's
>what I use to optimize things, and that's what I recommend doing. The
>students will quickly find out that the case statement is converted to a
>jump table.
Yes. But they have to suspect that their mental model is wrong,
first.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2013: http://www.euroforth.org/ef13/
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@yahoo.com |
|---|---|
| Date | 2014-01-24 21:00 -0800 |
| Message-ID | <d3a8ab16-e67d-43ec-82c0-f26ed44ebf39@googlegroups.com> |
| In reply to | #28054 |
On Friday, January 24, 2014 2:25:38 AM UTC-7, Anton Ertl wrote: > My students are those who are interested in efficient programs > (otherwise they would not have elected to take my course), so I guess > that they are above average in that respect. LOL. Was that intended to be a joke? A series of comparisons is grossly inefficient on any architecture. Use a jump table --- this is a difference between O(n) and O(1). If your CASE is going to be used for emulation of a microprocessor (either a real processor or a VM), then it has to compile into a jump table (Testra had a jump-table CASE for UR/Forth for emulation of microprocessors 20 years ago, and HLA does now). For the most part, emulating a microprocessor is the only thing I've ever used CASE for. It is a violation of Forth thinking to pass a parameter into a function and then do a CASE on it (or to pass a flag in and do an IF ELSE on it) --- functions are supposed to do only one thing (see the book "Thinking Forth," especially the cartoon about the "universal processor" of numbers, text and food). In the rare cases that I do need a CASE, I will make a sub-function and then use a series of IF ... EXIT THEN structures. This is more robust because I can work with any data type (floats, strings, etc.) rather than just integers, and I can make complex tests such as checking for the parameter to be within a range, rather than just equality to a constant. The fact that CASE is restricted to integers implies that it is for emulation of a microprocessor (the parameter is the opcode) or for branching on an enumeration (which I have already said is a bad idea because this implies that the function does more than one thing) --- but the implementation of CASE is the worst possible solution for what it was designed for! ANS-Forth is full of gross stupidities, and CASE is one of them (Bernd Payson's "quotation" implementation that doesn't provide access to the creator function's local variables is the latest and greatest of a long series of stupidities). I think that ANS-Forth is the worst thing that ever happened to the Forth community. This is because ANS-Forth represents itself as the collected wisdom of the whole Forth community --- and this makes the whole Forth community look stupid --- without ANS-Forth we would have to judge Forth programmers individually rather than as a group, and a small fraction of them would be considered to be intelligent (none of the ANS-Forth or Forth-200x technical committees).
[toc] | [prev] | [next] | [standalone]
Page 3 of 21 — ← Prev page 1 2 [3] 4 5 … 21 Next page →
Back to top | Article view | comp.lang.forth
csiph-web