Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > sci.math > #406713 > unrolled thread
| Started by | WM <wolfgang.mueckenheim@hs-augsburg.de> |
|---|---|
| First post | 2018-03-03 00:28 -0800 |
| Last post | 2018-03-08 20:48 +0100 |
| Articles | 20 on this page of 320 — 9 participants |
Back to article view | Back to sci.math
MatheRealism in geometry WM <wolfgang.mueckenheim@hs-augsburg.de> - 2018-03-03 00:28 -0800
Re: MatheRealism in geometry John Gabriel <thenewcalculus@gmail.com> - 2018-03-03 07:04 -0800
Re: MatheRealism in geometry WM <wolfgang.mueckenheim@hs-augsburg.de> - 2018-03-04 01:22 -0800
Re: MatheRealism in geometry John Gabriel <thenewcalculus@gmail.com> - 2018-03-04 04:26 -0800
Re: MatheRealism in geometry WM <wolfgang.mueckenheim@hs-augsburg.de> - 2018-03-04 08:25 -0800
Re: MatheRealism in geometry John Gabriel <thenewcalculus@gmail.com> - 2018-03-04 08:33 -0800
Re: MatheRealism in geometry WM <wolfgang.mueckenheim@hs-augsburg.de> - 2018-03-04 08:39 -0800
Re: MatheRealism in geometry John Gabriel <thenewcalculus@gmail.com> - 2018-03-04 09:18 -0800
Re: MatheRealism in geometry WM <wolfgang.mueckenheim@hs-augsburg.de> - 2018-03-04 10:49 -0800
Re: MatheRealism in geometry John Gabriel <thenewcalculus@gmail.com> - 2018-03-04 11:15 -0800
Re: MatheRealism in geometry John Gabriel <thenewcalculus@gmail.com> - 2018-03-04 04:48 -0800
Re: MatheRealism in geometry John Gabriel <thenewcalculus@gmail.com> - 2018-03-04 04:51 -0800
Re: MatheRealism in geometry WM <wolfgang.mueckenheim@hs-augsburg.de> - 2018-03-04 08:44 -0800
Re: MatheRealism in geometry John Gabriel <thenewcalculus@gmail.com> - 2018-03-04 09:22 -0800
Re: MatheRealism in geometry WM <wolfgang.mueckenheim@hs-augsburg.de> - 2018-03-04 11:10 -0800
Re: MatheRealism in geometry John Gabriel <thenewcalculus@gmail.com> - 2018-03-04 11:22 -0800
Re: MatheRealism in geometry WM <wolfgang.mueckenheim@hs-augsburg.de> - 2018-03-04 13:24 -0800
Re: MatheRealism in geometry John Gabriel <thenewcalculus@gmail.com> - 2018-03-04 13:34 -0800
Re: MatheRealism in geometry WM <wolfgang.mueckenheim@hs-augsburg.de> - 2018-03-04 23:06 -0800
Re: MatheRealism in geometry John Gabriel <thenewcalculus@gmail.com> - 2018-03-05 09:05 -0800
Re: MatheRealism in geometry WM <wolfgang.mueckenheim@hs-augsburg.de> - 2018-03-05 10:07 -0800
Re: MatheRealism in geometry bursejan@gmail.com - 2018-03-05 10:26 -0800
Re: MatheRealism in geometry bursejan@gmail.com - 2018-03-05 10:35 -0800
Re: MatheRealism in geometry bursejan@gmail.com - 2018-03-05 10:45 -0800
Re: MatheRealism in geometry bursejan@gmail.com - 2018-03-05 10:46 -0800
Re: MatheRealism in geometry bursejan@gmail.com - 2018-03-05 11:07 -0800
Re: MatheRealism in geometry WM <wolfgang.mueckenheim@hs-augsburg.de> - 2018-03-05 12:51 -0800
Re: MatheRealism in geometry Python <python@python.invalid> - 2018-03-05 23:17 +0100
Re: MatheRealism in geometry bursejan@gmail.com - 2018-03-06 04:20 -0800
Re: MatheRealism in geometry WM <wolfgang.mueckenheim@hs-augsburg.de> - 2018-03-06 06:12 -0800
Re: MatheRealism in geometry bursejan@gmail.com - 2018-03-06 06:16 -0800
Re: MatheRealism in geometry bursejan@gmail.com - 2018-03-06 06:24 -0800
Re: MatheRealism in geometry bursejan@gmail.com - 2018-03-06 06:27 -0800
Re: MatheRealism in geometry Python <python@python.invalid> - 2018-03-06 17:14 +0100
Re: MatheRealism in geometry John Gabriel <thenewcalculus@gmail.com> - 2018-03-06 09:02 -0800
Re: MatheRealism in geometry bursejan@gmail.com - 2018-03-06 09:17 -0800
Re: MatheRealism in geometry Python <python@python.invalid> - 2018-03-06 18:26 +0100
Re: MatheRealism in geometry John Gabriel <thenewcalculus@gmail.com> - 2018-03-06 09:53 -0800
Re: MatheRealism in geometry bursejan@gmail.com - 2018-03-06 10:31 -0800
Re: MatheRealism in geometry bursejan@gmail.com - 2018-03-06 10:53 -0800
Re: MatheRealism in geometry Python <python@python.invalid> - 2018-03-07 01:49 +0100
Re: MatheRealism in geometry Python <python@python.invalid> - 2018-03-07 02:48 +0100
Re: MatheRealism in geometry John Gabriel <thenewcalculus@gmail.com> - 2018-03-06 21:19 -0800
Re: MatheRealism in geometry Python <python@python.invalid> - 2018-03-07 08:46 +0100
Re: MatheRealism in geometry Python <python@python.invalid> - 2018-03-07 11:02 +0100
Re: MatheRealism in geometry bursejan@gmail.com - 2018-03-07 02:37 -0800
Re: MatheRealism in geometry Python <python@python.invalid> - 2018-03-07 23:49 +0100
Re: MatheRealism in geometry John Gabriel <thenewcalculus@gmail.com> - 2018-03-07 15:24 -0800
Re: MatheRealism in geometry Python <python@python.invalid> - 2018-03-08 02:05 +0100
Re: MatheRealism in geometry Python <python@python.invalid> - 2018-03-08 03:46 +0100
Re: MatheRealism in geometry bursejan@gmail.com - 2018-03-07 19:02 -0800
Re: MatheRealism in geometry John Gabriel <thenewcalculus@gmail.com> - 2018-03-08 05:47 -0800
Re: MatheRealism in geometry Python <python@python.invalid> - 2018-03-08 17:23 +0100
Re: MatheRealism in geometry John Gabriel <thenewcalculus@gmail.com> - 2018-03-08 09:14 -0800
Re: MatheRealism in geometry Python <python@python.invalid> - 2018-03-08 18:26 +0100
Re: MatheRealism in geometry John Gabriel <thenewcalculus@gmail.com> - 2018-03-08 10:13 -0800
Re: MatheRealism in geometry Python <python@python.invalid> - 2018-03-08 19:25 +0100
Re: MatheRealism in geometry John Gabriel <thenewcalculus@gmail.com> - 2018-03-08 11:03 -0800
Re: MatheRealism in geometry bursejan@gmail.com - 2018-03-08 11:07 -0800
Re: MatheRealism in geometry John Gabriel <thenewcalculus@gmail.com> - 2018-03-08 11:07 -0800
Re: MatheRealism in geometry John Gabriel <thenewcalculus@gmail.com> - 2018-03-08 11:12 -0800
Re: MatheRealism in geometry bursejan@gmail.com - 2018-03-08 11:16 -0800
Re: MatheRealism in geometry bursejan@gmail.com - 2018-03-08 11:19 -0800
Re: MatheRealism in geometry Python <python@python.invalid> - 2018-03-08 20:22 +0100
Re: MatheRealism in geometry bursejan@gmail.com - 2018-03-08 11:22 -0800
Re: MatheRealism in geometry bursejan@gmail.com - 2018-03-08 11:28 -0800
Re: MatheRealism in geometry Python <python@python.invalid> - 2018-03-08 20:17 +0100
Re: MatheRealism in geometry Python <python@python.invalid> - 2018-03-08 20:15 +0100
Re: MatheRealism in geometry Python <python@python.invalid> - 2018-03-08 20:12 +0100
Re: MatheRealism in geometry bursejan@gmail.com - 2018-03-08 10:29 -0800
Re: MatheRealism in geometry Python <python@python.invalid> - 2018-03-08 19:37 +0100
Re: MatheRealism in geometry bursejan@gmail.com - 2018-03-08 10:53 -0800
Re: MatheRealism in geometry bursejan@gmail.com - 2018-03-08 11:04 -0800
Re: MatheRealism in geometry Python <python@python.invalid> - 2018-03-08 20:08 +0100
Re: MatheRealism in geometry bursejan@gmail.com - 2018-03-08 11:15 -0800
Re: MatheRealism in geometry John Gabriel <thenewcalculus@gmail.com> - 2018-03-08 11:06 -0800
Re: MatheRealism in geometry WM <wolfgang.mueckenheim@hs-augsburg.de> - 2018-03-07 04:18 -0800
Re: MatheRealism in geometry Python <python@python.invalid> - 2018-03-07 15:40 +0100
Re: MatheRealism in geometry WM <wolfgang.mueckenheim@hs-augsburg.de> - 2018-03-07 23:40 -0800
Re: MatheRealism in geometry John Gabriel <thenewcalculus@gmail.com> - 2018-03-08 05:50 -0800
Re: MatheRealism in geometry bursejan@gmail.com - 2018-03-08 06:08 -0800
Re: MatheRealism in geometry WM <wolfgang.mueckenheim@hs-augsburg.de> - 2018-03-08 07:40 -0800
Re: MatheRealism in geometry bursejan@gmail.com - 2018-03-08 09:15 -0800
Re: MatheRealism in geometry bursejan@gmail.com - 2018-03-08 09:22 -0800
Re: MatheRealism in geometry WM <wolfgang.mueckenheim@hs-augsburg.de> - 2018-03-08 11:34 -0800
Re: MatheRealism in geometry bursejan@gmail.com - 2018-03-08 11:41 -0800
Re: MatheRealism in geometry Python <python@python.invalid> - 2018-03-08 20:41 +0100
Re: MatheRealism in geometry John Gabriel <thenewcalculus@gmail.com> - 2018-03-08 12:55 -0800
Re: MatheRealism in geometry WM <wolfgang.mueckenheim@hs-augsburg.de> - 2018-03-08 13:25 -0800
Re: MatheRealism in geometry WM <wolfgang.mueckenheim@hs-augsburg.de> - 2018-03-08 13:31 -0800
Re: MatheRealism in geometry FredJeffries <fredjeffries@gmail.com> - 2018-03-08 14:37 -0800
Re: MatheRealism in geometry "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid> - 2018-03-08 14:42 -0800
Re: MatheRealism in geometry FredJeffries <fredjeffries@gmail.com> - 2018-03-08 15:35 -0800
Re: MatheRealism in geometry "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid> - 2018-03-08 14:46 -0800
Re: MatheRealism in geometry FredJeffries <fredjeffries@gmail.com> - 2018-03-08 15:34 -0800
Re: MatheRealism in geometry "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid> - 2018-03-08 15:54 -0800
Re: MatheRealism in geometry "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid> - 2018-03-08 15:57 -0800
Re: MatheRealism in geometry "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid> - 2018-03-08 16:03 -0800
Re: MatheRealism in geometry bursejan@gmail.com - 2018-03-08 16:31 -0800
Re: MatheRealism in geometry bursejan@gmail.com - 2018-03-08 16:37 -0800
Re: MatheRealism in geometry "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid> - 2018-03-08 17:19 -0800
Re: MatheRealism in geometry bursejan@gmail.com - 2018-03-08 17:41 -0800
Re: MatheRealism in geometry bursejan@gmail.com - 2018-03-08 16:39 -0800
Re: MatheRealism in geometry FredJeffries <fredjeffries@gmail.com> - 2018-03-08 16:44 -0800
Re: MatheRealism in geometry Python <python@python.invalid> - 2018-03-09 01:59 +0100
Re: MatheRealism in geometry bursejan@gmail.com - 2018-03-08 17:21 -0800
Re: MatheRealism in geometry bursejan@gmail.com - 2018-03-08 17:30 -0800
Re: MatheRealism in geometry Python <python@python.invalid> - 2018-03-09 02:45 +0100
Re: MatheRealism in geometry bursejan@gmail.com - 2018-03-08 17:53 -0800
Re: MatheRealism in geometry Python <python@python.invalid> - 2018-03-09 02:57 +0100
Re: MatheRealism in geometry bursejan@gmail.com - 2018-03-08 18:05 -0800
Re: MatheRealism in geometry Python <python@python.invalid> - 2018-03-09 03:18 +0100
Re: MatheRealism in geometry Python <python@python.invalid> - 2018-03-09 06:25 +0100
Re: MatheRealism in geometry bursejan@gmail.com - 2018-03-08 21:33 -0800
Re: MatheRealism in geometry Python <python@python.invalid> - 2018-03-09 06:36 +0100
Re: MatheRealism in geometry bursejan@gmail.com - 2018-03-08 21:40 -0800
Re: MatheRealism in geometry bursejan@gmail.com - 2018-03-08 21:43 -0800
Re: MatheRealism in geometry bursejan@gmail.com - 2018-03-08 21:46 -0800
Re: MatheRealism in geometry bursejan@gmail.com - 2018-03-08 21:52 -0800
Re: MatheRealism in geometry Python <python@python.invalid> - 2018-03-09 06:57 +0100
Re: MatheRealism in geometry Python <python@python.invalid> - 2018-03-09 06:53 +0100
Re: MatheRealism in geometry bursejan@gmail.com - 2018-03-08 22:00 -0800
Re: MatheRealism in geometry bursejan@gmail.com - 2018-03-08 22:06 -0800
Re: MatheRealism in geometry Python <python@python.invalid> - 2018-03-09 07:13 +0100
Re: MatheRealism in geometry bursejan@gmail.com - 2018-03-08 22:15 -0800
Re: MatheRealism in geometry bursejan@gmail.com - 2018-03-08 22:21 -0800
Re: MatheRealism in geometry Python <python@python.invalid> - 2018-03-09 07:27 +0100
Re: MatheRealism in geometry Python <python@python.invalid> - 2018-03-09 07:22 +0100
Re: MatheRealism in geometry "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid> - 2018-03-09 00:00 -0800
Re: MatheRealism in geometry "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid> - 2018-03-10 14:32 -0800
Re: MatheRealism in geometry John Gabriel <thenewcalculus@gmail.com> - 2018-03-10 15:40 -0800
Re: MatheRealism in geometry John Gabriel <thenewcalculus@gmail.com> - 2018-03-10 15:41 -0800
Re: MatheRealism in geometry "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid> - 2018-03-10 15:53 -0800
Re: MatheRealism in geometry Jonas Thörnvall <jonas.thornvall@gmail.com> - 2018-03-10 17:57 -0800
Re: MatheRealism in geometry John Gabriel <thenewcalculus@gmail.com> - 2018-03-11 07:02 -0700
Re: MatheRealism in geometry "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid> - 2018-03-11 13:03 -0700
Re: MatheRealism in geometry "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid> - 2018-03-11 13:21 -0700
Re: MatheRealism in geometry Python <python@python.invalid> - 2018-03-12 17:54 +0100
Re: MatheRealism in geometry bursejan@gmail.com - 2018-03-12 10:07 -0700
Re: MatheRealism in geometry bursejan@gmail.com - 2018-03-12 10:12 -0700
Re: MatheRealism in geometry "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid> - 2018-03-12 13:56 -0700
Re: MatheRealism in geometry "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid> - 2018-03-12 14:00 -0700
Re: MatheRealism in geometry "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid> - 2018-03-12 14:37 -0700
Re: MatheRealism in geometry "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid> - 2018-03-12 14:54 -0700
Re: MatheRealism in geometry Python <python@python.invalid> - 2018-03-12 23:04 +0100
Re: MatheRealism in geometry "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid> - 2018-03-12 15:13 -0700
Re: MatheRealism in geometry John Gabriel <thenewcalculus@gmail.com> - 2018-03-12 15:21 -0700
Re: MatheRealism in geometry "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid> - 2018-03-12 15:41 -0700
Re: MatheRealism in geometry John Gabriel <thenewcalculus@gmail.com> - 2018-03-12 16:01 -0700
Re: MatheRealism in geometry John Gabriel <thenewcalculus@gmail.com> - 2018-03-12 16:06 -0700
Re: MatheRealism in geometry Python <python@python.invalid> - 2018-03-13 00:24 +0100
Re: MatheRealism in geometry John Gabriel <thenewcalculus@gmail.com> - 2018-03-12 17:07 -0700
Re: MatheRealism in geometry "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid> - 2018-03-12 16:51 -0700
Re: MatheRealism in geometry John Gabriel <thenewcalculus@gmail.com> - 2018-03-12 17:08 -0700
Re: MatheRealism in geometry "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid> - 2018-03-12 20:19 -0700
Re: MatheRealism in geometry Python <python@python.invalid> - 2018-03-11 00:53 +0100
Re: MatheRealism in geometry WM <wolfgang.mueckenheim@hs-augsburg.de> - 2018-03-09 03:14 -0800
Re: MatheRealism in geometry Python <python@python.invalid> - 2018-03-09 06:42 +0100
Re: MatheRealism in geometry bursejan@gmail.com - 2018-03-08 18:20 -0800
Re: MatheRealism in geometry bursejan@gmail.com - 2018-03-08 18:29 -0800
Re: MatheRealism in geometry Python <python@python.invalid> - 2018-03-09 03:39 +0100
Re: MatheRealism in geometry Python <python@python.invalid> - 2018-03-09 03:30 +0100
Re: MatheRealism in geometry bursejan@gmail.com - 2018-03-08 18:48 -0800
Re: MatheRealism in geometry bursejan@gmail.com - 2018-03-08 18:58 -0800
Re: MatheRealism in geometry Python <python@python.invalid> - 2018-03-09 04:29 +0100
Re: MatheRealism in geometry bursejan@gmail.com - 2018-03-08 20:35 -0800
Re: MatheRealism in geometry bursejan@gmail.com - 2018-03-08 20:40 -0800
Re: MatheRealism in geometry Python <python@python.invalid> - 2018-03-09 05:47 +0100
Re: MatheRealism in geometry bursejan@gmail.com - 2018-03-08 20:50 -0800
Re: MatheRealism in geometry bursejan@gmail.com - 2018-03-08 20:58 -0800
Re: MatheRealism in geometry Python <python@python.invalid> - 2018-03-09 06:01 +0100
Re: MatheRealism in geometry Python <python@python.invalid> - 2018-03-09 05:59 +0100
Re: MatheRealism in geometry bursejan@gmail.com - 2018-03-08 21:20 -0800
Re: MatheRealism in geometry Python <python@python.invalid> - 2018-03-09 03:09 +0100
Re: MatheRealism in geometry "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid> - 2018-03-13 17:27 -0700
Re: MatheRealism in geometry "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid> - 2018-03-13 17:29 -0700
Re: MatheRealism in geometry Jonas Thörnvall <jonas.thornvall@gmail.com> - 2018-03-13 20:57 -0700
Re: MatheRealism in geometry Jonas Thörnvall <jonas.thornvall@gmail.com> - 2018-03-13 21:00 -0700
Re: MatheRealism in geometry Jonas Thörnvall <jonas.thornvall@gmail.com> - 2018-03-13 21:02 -0700
Re: MatheRealism in geometry Jonas Thörnvall <jonas.thornvall@gmail.com> - 2018-03-14 05:15 -0700
Re: MatheRealism in geometry Jonas Thörnvall <jonas.thornvall@gmail.com> - 2018-03-14 06:28 -0700
Re: MatheRealism in geometry John Gabriel <thenewcalculus@gmail.com> - 2018-03-14 06:41 -0700
Re: MatheRealism in geometry Jonas Thörnvall <jonas.thornvall@gmail.com> - 2018-03-14 06:54 -0700
Re: MatheRealism in geometry John Gabriel <thenewcalculus@gmail.com> - 2018-03-14 07:12 -0700
Re: MatheRealism in geometry Jonas Thörnvall <jonas.thornvall@gmail.com> - 2018-03-14 07:16 -0700
Re: MatheRealism in geometry Jonas Thörnvall <jonas.thornvall@gmail.com> - 2018-03-14 07:28 -0700
Re: MatheRealism in geometry Jonas Thörnvall <jonas.thornvall@gmail.com> - 2018-03-14 07:32 -0700
Re: MatheRealism in geometry John Gabriel <thenewcalculus@gmail.com> - 2018-03-14 07:47 -0700
Re: MatheRealism in geometry "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid> - 2018-03-08 19:45 -0800
Re: MatheRealism in geometry Python <python@python.invalid> - 2018-03-09 05:00 +0100
Re: MatheRealism in geometry bursejan@gmail.com - 2018-03-08 17:06 -0800
Re: MatheRealism in geometry "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid> - 2018-03-08 22:17 -0800
Re: MatheRealism in geometry bursejan@gmail.com - 2018-03-08 22:24 -0800
Re: MatheRealism in geometry "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid> - 2018-03-08 23:27 -0800
Re: MatheRealism in geometry "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid> - 2018-03-08 23:35 -0800
Re: MatheRealism in geometry "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid> - 2018-03-08 23:43 -0800
Re: MatheRealism in geometry Python <python@python.invalid> - 2018-03-09 01:44 +0100
Re: MatheRealism in geometry WM <wolfgang.mueckenheim@hs-augsburg.de> - 2018-03-09 02:35 -0800
Re: MatheRealism in geometry Python <python@python.invalid> - 2018-03-09 01:42 +0100
Re: MatheRealism in geometry John Gabriel <thenewcalculus@gmail.com> - 2018-03-08 17:04 -0800
Re: MatheRealism in geometry WM <wolfgang.mueckenheim@hs-augsburg.de> - 2018-03-09 02:35 -0800
Re: MatheRealism in geometry Python <python@python.invalid> - 2018-03-09 16:50 +0100
Re: MatheRealism in geometry Python <python@python.invalid> - 2018-03-09 16:51 +0100
Re: MatheRealism in geometry WM <wolfgang.mueckenheim@hs-augsburg.de> - 2018-03-09 08:52 -0800
Re: MatheRealism in geometry Python <python@python.invalid> - 2018-03-09 18:10 +0100
Re: MatheRealism in geometry WM <wolfgang.mueckenheim@hs-augsburg.de> - 2018-03-09 10:08 -0800
Re: MatheRealism in geometry Python <python@python.invalid> - 2018-03-09 19:17 +0100
Re: MatheRealism in geometry WM <wolfgang.mueckenheim@hs-augsburg.de> - 2018-03-09 13:55 -0800
Re: MatheRealism in geometry John Gabriel <thenewcalculus@gmail.com> - 2018-03-09 15:32 -0800
Re: MatheRealism in geometry Python <python@python.invalid> - 2018-03-10 03:17 +0100
Re: MatheRealism in geometry John Gabriel <thenewcalculus@gmail.com> - 2018-03-09 19:37 -0800
Re: MatheRealism in geometry Python <python@python.invalid> - 2018-03-10 03:11 +0100
Re: MatheRealism in geometry WM <wolfgang.mueckenheim@hs-augsburg.de> - 2018-03-10 02:46 -0800
Re: MatheRealism in geometry John Gabriel <thenewcalculus@gmail.com> - 2018-03-10 04:01 -0800
Re: MatheRealism in geometry Python <python@python.invalid> - 2018-03-12 18:19 +0100
Re: MatheRealism in geometry Python <python@python.invalid> - 2018-03-10 03:21 +0100
Re: MatheRealism in geometry WM <wolfgang.mueckenheim@hs-augsburg.de> - 2018-03-10 02:40 -0800
Re: MatheRealism in geometry John Gabriel <thenewcalculus@gmail.com> - 2018-03-10 03:58 -0800
Re: MatheRealism in geometry Python <python@python.invalid> - 2018-03-12 18:19 +0100
Re: MatheRealism in geometry "John Gabriel at age 50." <genmailus@gmail.com> - 2018-03-09 09:23 -0800
Re: MatheRealism in geometry Python <python@python.invalid> - 2018-03-09 18:27 +0100
Re: MatheRealism in geometry Python <python@python.invalid> - 2018-03-09 18:34 +0100
Re: MatheRealism in geometry WM <wolfgang.mueckenheim@hs-augsburg.de> - 2018-03-09 10:02 -0800
Re: MatheRealism in geometry Python <python@python.invalid> - 2018-03-09 19:22 +0100
Re: MatheRealism in geometry John Gabriel <thenewcalculus@gmail.com> - 2018-03-09 13:15 -0800
Re: MatheRealism in geometry John Gabriel <thenewcalculus@gmail.com> - 2018-03-09 13:14 -0800
Re: MatheRealism in geometry WM <wolfgang.mueckenheim@hs-augsburg.de> - 2018-03-09 13:37 -0800
Re: MatheRealism in geometry John Gabriel <thenewcalculus@gmail.com> - 2018-03-09 15:29 -0800
Re: MatheRealism in geometry John Gabriel <thenewcalculus@gmail.com> - 2018-03-08 12:55 -0800
Re: MatheRealism in geometry WM <wolfgang.mueckenheim@hs-augsburg.de> - 2018-03-08 11:32 -0800
Re: MatheRealism in geometry bursejan@gmail.com - 2018-03-08 11:40 -0800
Re: MatheRealism in geometry WM <wolfgang.mueckenheim@hs-augsburg.de> - 2018-03-08 13:38 -0800
Re: MatheRealism in geometry bursejan@gmail.com - 2018-03-08 13:44 -0800
Re: MatheRealism in geometry John Gabriel <thenewcalculus@gmail.com> - 2018-03-05 10:27 -0800
Re: MatheRealism in geometry WM <wolfgang.mueckenheim@hs-augsburg.de> - 2018-03-05 13:00 -0800
Re: MatheRealism in geometry John Gabriel <thenewcalculus@gmail.com> - 2018-03-05 14:45 -0800
Re: MatheRealism in geometry WM <wolfgang.mueckenheim@hs-augsburg.de> - 2018-03-06 03:59 -0800
Re: MatheRealism in geometry John Gabriel <thenewcalculus@gmail.com> - 2018-03-06 06:18 -0800
Re: MatheRealism in geometry John Gabriel <thenewcalculus@gmail.com> - 2018-03-06 06:19 -0800
Re: MatheRealism in geometry bursejan@gmail.com - 2018-03-04 15:07 -0800
Re: MatheRealism in geometry bursejan@gmail.com - 2018-03-04 15:19 -0800
Re: MatheRealism in geometry FredJeffries <fredjeffries@gmail.com> - 2018-03-04 15:48 -0800
Re: MatheRealism in geometry WM <wolfgang.mueckenheim@hs-augsburg.de> - 2018-03-04 23:24 -0800
Re: MatheRealism in geometry WM <wolfgang.mueckenheim@hs-augsburg.de> - 2018-03-04 23:25 -0800
Re: MatheRealism in geometry bursejan@gmail.com - 2018-03-04 10:04 -0800
Re: MatheRealism in geometry bursejan@gmail.com - 2018-03-04 10:06 -0800
Re: MatheRealism in geometry bursejan@gmail.com - 2018-03-04 10:11 -0800
Re: MatheRealism in geometry WM <wolfgang.mueckenheim@hs-augsburg.de> - 2018-03-04 11:20 -0800
Re: MatheRealism in geometry Python <python@python.invalid> - 2018-03-04 20:35 +0100
Re: MatheRealism in geometry John Gabriel <thenewcalculus@gmail.com> - 2018-03-04 12:50 -0800
Re: MatheRealism in geometry Python <python@python.invalid> - 2018-03-04 22:53 +0100
Re: MatheRealism in geometry WM <wolfgang.mueckenheim@hs-augsburg.de> - 2018-03-04 23:36 -0800
Re: MatheRealism in geometry WM <wolfgang.mueckenheim@hs-augsburg.de> - 2018-03-05 00:24 -0800
Re: MatheRealism in geometry Python <python@python.invalid> - 2018-03-05 14:58 +0100
Re: MatheRealism in geometry WM <wolfgang.mueckenheim@hs-augsburg.de> - 2018-03-05 07:28 -0800
Re: MatheRealism in geometry Python <python@python.invalid> - 2018-03-05 16:47 +0100
Re: MatheRealism in geometry WM <wolfgang.mueckenheim@hs-augsburg.de> - 2018-03-05 08:18 -0800
Re: MatheRealism in geometry Python <python@python.invalid> - 2018-03-05 17:26 +0100
Re: MatheRealism in geometry WM <wolfgang.mueckenheim@hs-augsburg.de> - 2018-03-05 10:06 -0800
Re: MatheRealism in geometry Python <python@python.invalid> - 2018-03-05 23:05 +0100
Re: MatheRealism in geometry WM <wolfgang.mueckenheim@hs-augsburg.de> - 2018-03-06 03:29 -0800
Re: MatheRealism in geometry John Gabriel <thenewcalculus@gmail.com> - 2018-03-06 06:17 -0800
Re: MatheRealism in geometry WM <wolfgang.mueckenheim@hs-augsburg.de> - 2018-03-06 06:33 -0800
Re: MatheRealism in geometry bursejan@gmail.com - 2018-03-06 06:49 -0800
Re: MatheRealism in geometry WM <wolfgang.mueckenheim@hs-augsburg.de> - 2018-03-07 04:08 -0800
Re: MatheRealism in geometry bursejan@gmail.com - 2018-03-07 04:26 -0800
Re: MatheRealism in geometry bursejan@gmail.com - 2018-03-07 04:33 -0800
Re: MatheRealism in geometry bursejan@gmail.com - 2018-03-07 04:49 -0800
Re: MatheRealism in geometry WM <wolfgang.mueckenheim@hs-augsburg.de> - 2018-03-08 00:16 -0800
Re: MatheRealism in geometry John Gabriel <thenewcalculus@gmail.com> - 2018-03-07 04:44 -0800
Re: MatheRealism in geometry Python <python@python.invalid> - 2018-03-07 15:36 +0100
Re: MatheRealism in geometry bursejan@gmail.com - 2018-03-07 06:46 -0800
Re: MatheRealism in geometry bursejan@gmail.com - 2018-03-07 06:53 -0800
Re: MatheRealism in geometry bursejan@gmail.com - 2018-03-07 07:01 -0800
Re: MatheRealism in geometry bursejan@gmail.com - 2018-03-07 07:11 -0800
Re: MatheRealism in geometry Python <python@python.invalid> - 2018-03-07 16:16 +0100
Re: MatheRealism in geometry bursejan@gmail.com - 2018-03-07 07:21 -0800
Re: MatheRealism in geometry Python <python@python.invalid> - 2018-03-07 16:26 +0100
Re: MatheRealism in geometry bursejan@gmail.com - 2018-03-07 07:27 -0800
Re: MatheRealism in geometry bursejan@gmail.com - 2018-03-07 07:31 -0800
Re: MatheRealism in geometry Python <python@python.invalid> - 2018-03-07 16:35 +0100
Re: MatheRealism in geometry bursejan@gmail.com - 2018-03-07 07:37 -0800
Re: MatheRealism in geometry Python <python@python.invalid> - 2018-03-07 16:41 +0100
Re: MatheRealism in geometry bursejan@gmail.com - 2018-03-07 07:48 -0800
Re: MatheRealism in geometry bursejan@gmail.com - 2018-03-07 08:06 -0800
Re: MatheRealism in geometry bursejan@gmail.com - 2018-03-07 08:26 -0800
Re: MatheRealism in geometry bursejan@gmail.com - 2018-03-07 08:31 -0800
Re: MatheRealism in geometry WM <wolfgang.mueckenheim@hs-augsburg.de> - 2018-03-08 00:05 -0800
Re: MatheRealism in geometry WM <wolfgang.mueckenheim@hs-augsburg.de> - 2018-03-08 00:02 -0800
Re: MatheRealism in geometry bursejan@gmail.com - 2018-03-08 03:38 -0800
Re: MatheRealism in geometry bursejan@gmail.com - 2018-03-08 03:40 -0800
Re: MatheRealism in geometry bursejan@gmail.com - 2018-03-08 03:51 -0800
Re: MatheRealism in geometry bursejan@gmail.com - 2018-03-08 04:02 -0800
Re: MatheRealism in geometry WM <wolfgang.mueckenheim@hs-augsburg.de> - 2018-03-08 07:38 -0800
Re: MatheRealism in geometry Python <python@python.invalid> - 2018-03-07 16:32 +0100
Re: MatheRealism in geometry WM <wolfgang.mueckenheim@hs-augsburg.de> - 2018-03-07 23:54 -0800
Re: MatheRealism in geometry John Gabriel <thenewcalculus@gmail.com> - 2018-03-07 08:14 -0800
Re: MatheRealism in geometry Python <python@python.invalid> - 2018-03-07 17:17 +0100
Re: MatheRealism in geometry John Gabriel <thenewcalculus@gmail.com> - 2018-03-07 08:25 -0800
Re: MatheRealism in geometry John Gabriel <thenewcalculus@gmail.com> - 2018-03-07 08:32 -0800
Re: MatheRealism in geometry bursejan@gmail.com - 2018-03-07 08:34 -0800
Re: MatheRealism in geometry bursejan@gmail.com - 2018-03-07 07:18 -0800
Re: MatheRealism in geometry John Gabriel <thenewcalculus@gmail.com> - 2018-03-06 07:25 -0800
Re: MatheRealism in geometry bursejan@gmail.com - 2018-03-06 07:49 -0800
Re: MatheRealism in geometry bursejan@gmail.com - 2018-03-06 07:50 -0800
Re: MatheRealism in geometry WM <wolfgang.mueckenheim@hs-augsburg.de> - 2018-03-07 04:11 -0800
Re: MatheRealism in geometry Python <python@python.invalid> - 2018-03-05 15:02 +0100
Re: MatheRealism in geometry WM <wolfgang.mueckenheim@hs-augsburg.de> - 2018-03-05 07:36 -0800
Re: MatheRealism in geometry Python <python@python.invalid> - 2018-03-05 16:49 +0100
Re: MatheRealism in geometry WM <wolfgang.mueckenheim@hs-augsburg.de> - 2018-03-05 08:02 -0800
Re: MatheRealism in geometry Python <python@python.invalid> - 2018-03-05 17:10 +0100
Re: MatheRealism in geometry WM <wolfgang.mueckenheim@hs-augsburg.de> - 2018-03-08 07:34 -0800
Re: MatheRealism in geometry Python <python@python.invalid> - 2018-03-08 18:44 +0100
Re: MatheRealism in geometry WM <wolfgang.mueckenheim@hs-augsburg.de> - 2018-03-08 11:42 -0800
Re: MatheRealism in geometry bursejan@gmail.com - 2018-03-08 11:46 -0800
Re: MatheRealism in geometry WM <wolfgang.mueckenheim@hs-augsburg.de> - 2018-03-08 12:04 -0800
Re: MatheRealism in geometry Python <python@python.invalid> - 2018-03-08 21:15 +0100
Re: MatheRealism in geometry WM <wolfgang.mueckenheim@hs-augsburg.de> - 2018-03-08 12:58 -0800
Re: MatheRealism in geometry j4n bur53 <janburse@fastmail.fm> - 2018-03-08 21:55 +0100
Re: MatheRealism in geometry Python <python@python.invalid> - 2018-03-08 20:48 +0100
Page 8 of 16 — ← Prev page 1 … 6 7 [8] 9 10 … 16 Next page →
| From | "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid> |
|---|---|
| Date | 2018-03-12 13:56 -0700 |
| Message-ID | <p86pha$io8$1@dont-email.me> |
| In reply to | #408057 |
On 3/12/2018 10:07 AM, bursejan@gmail.com wrote: > There is some problem with native (lets say C or Java) > recursion. Its bound by the native stack size, which > is usually a size per thread. > > And for non-linear recursion, where tail recursion > doesn't have some stack reducing impact, this is > really a problem. Yeah. I remember a while ago when taking a look at some code created by another person. I raised a question about how deep it can recurse. Well.... It was fine in the test beds. Then, it blew up a threads stack because a users input made it recuse too deep. A thread hit a stack overflow and crashed the damn process. Yikes! > > If you have deep recursion, you can easilly kill > the stack of your current thread. Like in a web > server, where there are many threads, > > and you cannot give them all large stack space. > > One way that this is mittigated, is that some > languages have their own stack management. Or > that for some applications, a proprietary > > stack management is explicitly implemented. > (Trampolin Pattern, or so). So somehow John > Gabriel is correct, but he is also wrong. > > He is also wrong, since even with these > measures in place, the native stack space is > just traded to some other space, > > like the heap. So that in general its just > limitation of the machine. Irrespectie what > model is used. Stack language, or not you > > anyway run into limitations. To shed more > light on these limitations, we would need to > dig deeper into recursion theory and > > complexity theory... > > Am Montag, 12. März 2018 17:54:34 UTC+1 schrieb Python: >> John Gabriel wrote: >> ... >>> Recursion is very problematic. No sound application uses recursion. >>> No matter what you do to make it better, it can always fail for a >>> multitude of reasons. >> >> This claim from John Gabriel, allegedly software engineer, is >> outrageously wrong. >> >> - There are, amongst functional languages, a whole class of >> programming languages where no loop statements exists >> (e.g. Haskell) or are considered as a bad practice (Scheme). >> These languages are used to build industrial grade >> application (as their correctness can be proven). Most >> (if not all) of this language are implementing tail >> recursion (something John Gabriel has clearly never >> heard of) in order to make a whole category of >> recursive calls as efficient as a loop in an imperative >> language (i.e. no stack consumption) >> >> - A lot of non-functional languages has interpreters or >> compilers implementing tail recursion (C with gcc for >> instance) >> >> - Any software who has to deal with a arbitrarily deep >> nested structure (say a hierarchical filesystem or >> an XML tree like for HTML parsing) will be written >> far more easily using explicit recursion. Using a >> loop there implies to basically manage a stack >> like structure to keep track of the elements having >> been parsed at a given time (i.e. SAX style XML >> event driven parsing) >> >> It makes absolutely no doubt that Mr Gabriel is as bad >> as a programmer as he is as a mathematician: worse than >> you'd ever think. >
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid> |
|---|---|
| Date | 2018-03-12 14:00 -0700 |
| Message-ID | <p86pp8$l01$1@dont-email.me> |
| In reply to | #408057 |
On 3/12/2018 10:07 AM, bursejan@gmail.com wrote: > There is some problem with native (lets say C or Java) > recursion. Its bound by the native stack size, which > is usually a size per thread. > > And for non-linear recursion, where tail recursion > doesn't have some stack reducing impact, this is > really a problem. > > If you have deep recursion, you can easilly kill > the stack of your current thread. Like in a web > server, where there are many threads, > > and you cannot give them all large stack space. Fwiw, there should not be a shi% load of threads in a web server. Usually, a couple of threads per cpu is enough. A thread per connection model will not scale. Nevertheless, large amount of threads or not, an unexpected deep recursion can overflow the stack of a thread. > > One way that this is mittigated, is that some > languages have their own stack management. Or > that for some applications, a proprietary > > stack management is explicitly implemented. > (Trampolin Pattern, or so). So somehow John > Gabriel is correct, but he is also wrong. > > He is also wrong, since even with these > measures in place, the native stack space is > just traded to some other space, > > like the heap. So that in general its just > limitation of the machine. Irrespectie what > model is used. Stack language, or not you > > anyway run into limitations. To shed more > light on these limitations, we would need to > dig deeper into recursion theory and > > complexity theory... > > Am Montag, 12. März 2018 17:54:34 UTC+1 schrieb Python: >> John Gabriel wrote: >> ... >>> Recursion is very problematic. No sound application uses recursion. >>> No matter what you do to make it better, it can always fail for a >>> multitude of reasons. >> >> This claim from John Gabriel, allegedly software engineer, is >> outrageously wrong. >> >> - There are, amongst functional languages, a whole class of >> programming languages where no loop statements exists >> (e.g. Haskell) or are considered as a bad practice (Scheme). >> These languages are used to build industrial grade >> application (as their correctness can be proven). Most >> (if not all) of this language are implementing tail >> recursion (something John Gabriel has clearly never >> heard of) in order to make a whole category of >> recursive calls as efficient as a loop in an imperative >> language (i.e. no stack consumption) >> >> - A lot of non-functional languages has interpreters or >> compilers implementing tail recursion (C with gcc for >> instance) >> >> - Any software who has to deal with a arbitrarily deep >> nested structure (say a hierarchical filesystem or >> an XML tree like for HTML parsing) will be written >> far more easily using explicit recursion. Using a >> loop there implies to basically manage a stack >> like structure to keep track of the elements having >> been parsed at a given time (i.e. SAX style XML >> event driven parsing) >> >> It makes absolutely no doubt that Mr Gabriel is as bad >> as a programmer as he is as a mathematician: worse than >> you'd ever think. >
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid> |
|---|---|
| Date | 2018-03-12 14:37 -0700 |
| Message-ID | <p86ruf$5al$1@dont-email.me> |
| In reply to | #408056 |
On 3/12/2018 9:54 AM, Python wrote: > John Gabriel wrote: > ... >> Recursion is very problematic. No sound application uses recursion. >> No matter what you do to make it better, it can always fail for a >> multitude of reasons. > > This claim from John Gabriel, allegedly software engineer, is > outrageously wrong. I would say that recursion can be problematic. Notice my C++ code... Luckily, it had a single recursive call to ct_fwave that only modified the wave parameter. This particular type of recursion does not need to be there at all. So, I converted it to a purely iterative function that does not need any allocations. Now, sometimes, based on the "nature" of the recursion, well, the fix that I used for my code does not apply in all cases. Sometimes, we need to create an artificial stack to store nodes in an iterative algorithm in order to replace the actual recursion. Heck, I would rather iterate over a n-ary tree stored in a 1-d array than go through any recursive tree traversal. Compiler driven optimization techniques aside for a moment, I still agree with John in the sense that iteration can be safer than recursion. > > - There are, amongst functional languages, a whole class of > programming languages where no loop statements exists > (e.g. Haskell) or are considered as a bad practice (Scheme). > These languages are used to build industrial grade > application (as their correctness can be proven). Most > (if not all) of this language are implementing tail > recursion (something John Gabriel has clearly never > heard of) in order to make a whole category of > recursive calls as efficient as a loop in an imperative > language (i.e. no stack consumption) > > - A lot of non-functional languages has interpreters or > compilers implementing tail recursion (C with gcc for > instance) > > - Any software who has to deal with a arbitrarily deep > nested structure (say a hierarchical filesystem or > an XML tree like for HTML parsing) will be written > far more easily using explicit recursion. Using a > loop there implies to basically manage a stack > like structure to keep track of the elements having > been parsed at a given time (i.e. SAX style XML > event driven parsing) > > It makes absolutely no doubt that Mr Gabriel is as bad > as a programmer as he is as a mathematician: worse than > you'd ever think. > > >
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid> |
|---|---|
| Date | 2018-03-12 14:54 -0700 |
| Message-ID | <p86stm$bb4$2@dont-email.me> |
| In reply to | #408071 |
On 3/12/2018 2:37 PM, Chris M. Thomasson wrote: > On 3/12/2018 9:54 AM, Python wrote: >> John Gabriel wrote: >> ... >>> Recursion is very problematic. No sound application uses recursion. >>> No matter what you do to make it better, it can always fail for a >>> multitude of reasons. >> >> This claim from John Gabriel, allegedly software engineer, is >> outrageously wrong. > > I would say that recursion can be problematic. GLSL shaders do not allow any recursive calls. > Notice my C++ code... > Luckily, it had a single recursive call to ct_fwave that only modified > the wave parameter. This particular type of recursion does not need to > be there at all. So, I converted it to a purely iterative function that > does not need any allocations. > > Now, sometimes, based on the "nature" of the recursion, well, the fix > that I used for my code does not apply in all cases. Sometimes, we need > to create an artificial stack to store nodes in an iterative algorithm > in order to replace the actual recursion. Heck, I would rather iterate > over a n-ary tree stored in a 1-d array than go through any recursive > tree traversal. > > Compiler driven optimization techniques aside for a moment, I still > agree with John in the sense that iteration can be safer than recursion. > > >> >> - There are, amongst functional languages, a whole class of >> programming languages where no loop statements exists >> (e.g. Haskell) or are considered as a bad practice (Scheme). >> These languages are used to build industrial grade >> application (as their correctness can be proven). Most >> (if not all) of this language are implementing tail >> recursion (something John Gabriel has clearly never >> heard of) in order to make a whole category of >> recursive calls as efficient as a loop in an imperative >> language (i.e. no stack consumption) >> >> - A lot of non-functional languages has interpreters or >> compilers implementing tail recursion (C with gcc for >> instance) >> >> - Any software who has to deal with a arbitrarily deep >> nested structure (say a hierarchical filesystem or >> an XML tree like for HTML parsing) will be written >> far more easily using explicit recursion. Using a >> loop there implies to basically manage a stack >> like structure to keep track of the elements having >> been parsed at a given time (i.e. SAX style XML >> event driven parsing) >> >> It makes absolutely no doubt that Mr Gabriel is as bad >> as a programmer as he is as a mathematician: worse than >> you'd ever think. >> >> >> >
[toc] | [prev] | [next] | [standalone]
| From | Python <python@python.invalid> |
|---|---|
| Date | 2018-03-12 23:04 +0100 |
| Message-ID | <5aa6f988$0$3299$426a74cc@news.free.fr> |
| In reply to | #408072 |
Chris M. Thomasson wrote: ... >>> John Gabriel wrote: >>> ... >>>> Recursion is very problematic. No sound application uses recursion. >>>> No matter what you do to make it better, it can always fail for a >>>> multitude of reasons. >>> >>> This claim from John Gabriel, allegedly software engineer, is >>> outrageously wrong. >> >> I would say that recursion can be problematic. I didn't object to that claim, I objected to this one, from Mr Gabriel: >> No sound application uses recursion. >> No matter what you do to make it better, it can always fail for a >> multitude of reasons. > GLSL shaders do not allow any recursive calls. So what?
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid> |
|---|---|
| Date | 2018-03-12 15:13 -0700 |
| Message-ID | <p86u1m$gof$1@dont-email.me> |
| In reply to | #408073 |
On 3/12/2018 3:04 PM, Python wrote: > Chris M. Thomasson wrote: > ... >>>> John Gabriel wrote: >>>> ... >>>>> Recursion is very problematic. No sound application uses recursion. >>>>> No matter what you do to make it better, it can always fail for a >>>>> multitude of reasons. >>>> >>>> This claim from John Gabriel, allegedly software engineer, is >>>> outrageously wrong. >>> >>> I would say that recursion can be problematic. > > I didn't object to that claim, I objected to this one, from Mr Gabriel: > >>> No sound application uses recursion. >>> No matter what you do to make it better, it can always fail for a >>> multitude of reasons. Ahh. Okay. >> GLSL shaders do not allow any recursive calls. > > So what? Touche.
[toc] | [prev] | [next] | [standalone]
| From | John Gabriel <thenewcalculus@gmail.com> |
|---|---|
| Date | 2018-03-12 15:21 -0700 |
| Message-ID | <8047b613-2955-404d-b9b7-0bc94ff016bc@googlegroups.com> |
| In reply to | #408073 |
On Monday, 12 March 2018 18:05:03 UTC-4, Python wrote: > Chris M. Thomasson wrote: > ... > >>> John Gabriel wrote: > >>> ... > >>>> Recursion is very problematic. No sound application uses recursion. > >>>> No matter what you do to make it better, it can always fail for a > >>>> multitude of reasons. > >>> > >>> This claim from John Gabriel, allegedly software engineer, is > >>> outrageously wrong. > >> > >> I would say that recursion can be problematic. > > I didn't object to that claim, I objected to this one, from Mr Gabriel: > > >> No sound application uses recursion. > >> No matter what you do to make it better, it can always fail for a > >> multitude of reasons. You can object all you like, but it won't change the fact that you are wrong! As always. > > > > GLSL shaders do not allow any recursive calls. > > So what?
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid> |
|---|---|
| Date | 2018-03-12 15:41 -0700 |
| Message-ID | <p86vn8$v9s$1@dont-email.me> |
| In reply to | #408076 |
On 3/12/2018 3:21 PM, John Gabriel wrote: > On Monday, 12 March 2018 18:05:03 UTC-4, Python wrote: >> Chris M. Thomasson wrote: >> ... >>>>> John Gabriel wrote: >>>>> ... >>>>>> Recursion is very problematic. No sound application uses recursion. >>>>>> No matter what you do to make it better, it can always fail for a >>>>>> multitude of reasons. >>>>> >>>>> This claim from John Gabriel, allegedly software engineer, is >>>>> outrageously wrong. >>>> >>>> I would say that recursion can be problematic. >> >> I didn't object to that claim, I objected to this one, from Mr Gabriel: >> >>>> No sound application uses recursion. >>>> No matter what you do to make it better, it can always fail for a >>>> multitude of reasons. > > You can object all you like, but it won't change the fact that you are wrong! As always. It is not fun when a threads stack actually does blow up. One time, the recursion was not even that deep, however, prior functions that called it used a lot of stack space already. And, well, that made the recursion very scary. > >> >> >>> GLSL shaders do not allow any recursive calls. >> >> So what? >
[toc] | [prev] | [next] | [standalone]
| From | John Gabriel <thenewcalculus@gmail.com> |
|---|---|
| Date | 2018-03-12 16:01 -0700 |
| Message-ID | <1030a85b-a2cb-4970-b4bc-f436f634124c@googlegroups.com> |
| In reply to | #408077 |
On Monday, 12 March 2018 18:41:51 UTC-4, Chris M. Thomasson wrote: > On 3/12/2018 3:21 PM, John Gabriel wrote: > > On Monday, 12 March 2018 18:05:03 UTC-4, Python wrote: > >> Chris M. Thomasson wrote: > >> ... > >>>>> John Gabriel wrote: > >>>>> ... > >>>>>> Recursion is very problematic. No sound application uses recursion. > >>>>>> No matter what you do to make it better, it can always fail for a > >>>>>> multitude of reasons. > >>>>> > >>>>> This claim from John Gabriel, allegedly software engineer, is > >>>>> outrageously wrong. > >>>> > >>>> I would say that recursion can be problematic. > >> > >> I didn't object to that claim, I objected to this one, from Mr Gabriel: > >> > >>>> No sound application uses recursion. > >>>> No matter what you do to make it better, it can always fail for a > >>>> multitude of reasons. > > > > You can object all you like, but it won't change the fact that you are wrong! As always. > > It is not fun when a threads stack actually does blow up. One time, the > recursion was not even that deep, however, prior functions that called > it used a lot of stack space already. And, well, that made the recursion > very scary. The main problem with recursion is that it is implemented differently by different compilers. So you may think it is doing what it was on a different compiler when in fact it is not. In an enterprise scenario (the real world, not the Mickey Mouse world of jean pierre messager who lives at school!), you will never use recursion because i) there is no need ii) it can lead to many problems iii) it is difficult to maintain iv) you cannot simply change the parameter list of a recursive function and expect it to work flawlessly - you can do this if the function code needs no modification v) if you are using abstract data structures such as linked lists, then you may end up in hell. vi) if you are allocating/deallocating memory the program can fail because of memory leaks even if your recursive routine doesn't fail. See, recursion is for college school boys. They react: "Wow. Isn't this cool?" "Let's do everything with recursion!" But obviously they are stupid and wet behind the ears. Chuckle. End of computer science lesson. > > > > > >> > >> > >>> GLSL shaders do not allow any recursive calls. > >> > >> So what? > >
[toc] | [prev] | [next] | [standalone]
| From | John Gabriel <thenewcalculus@gmail.com> |
|---|---|
| Date | 2018-03-12 16:06 -0700 |
| Message-ID | <b29c5d78-6e5b-42dd-84d4-a28f9ad56a70@googlegroups.com> |
| In reply to | #408080 |
On Monday, 12 March 2018 19:02:00 UTC-4, John Gabriel wrote: > On Monday, 12 March 2018 18:41:51 UTC-4, Chris M. Thomasson wrote: > > On 3/12/2018 3:21 PM, John Gabriel wrote: > > > On Monday, 12 March 2018 18:05:03 UTC-4, Python wrote: > > >> Chris M. Thomasson wrote: > > >> ... > > >>>>> John Gabriel wrote: > > >>>>> ... > > >>>>>> Recursion is very problematic. No sound application uses recursion. > > >>>>>> No matter what you do to make it better, it can always fail for a > > >>>>>> multitude of reasons. > > >>>>> > > >>>>> This claim from John Gabriel, allegedly software engineer, is > > >>>>> outrageously wrong. > > >>>> > > >>>> I would say that recursion can be problematic. > > >> > > >> I didn't object to that claim, I objected to this one, from Mr Gabriel: > > >> > > >>>> No sound application uses recursion. > > >>>> No matter what you do to make it better, it can always fail for a > > >>>> multitude of reasons. > > > > > > You can object all you like, but it won't change the fact that you are wrong! As always. > > > > It is not fun when a threads stack actually does blow up. One time, the > > recursion was not even that deep, however, prior functions that called > > it used a lot of stack space already. And, well, that made the recursion > > very scary. > > The main problem with recursion is that it is implemented differently by different compilers. So you may think it is doing what it was on a different compiler when in fact it is not. > > In an enterprise scenario (the real world, not the Mickey Mouse world of jean pierre messager who lives at school!), you will never use recursion because i) there is no need ii) it can lead to many problems iii) it is difficult to maintain iv) you cannot simply change the parameter list of a recursive function and expect it to work flawlessly - you can do this if the function code needs no modification v) if you are using abstract data structures such as linked lists, then you may end up in hell. vi) if you are allocating/deallocating memory the program can fail because of memory leaks even if your recursive routine doesn't fail. > > See, recursion is for college school boys. They react: "Wow. Isn't this cool?" > > "Let's do everything with recursion!" > > But obviously they are stupid and wet behind the ears. Chuckle. > > End of computer science lesson. > > > > > > > > > > >> > > >> > > >>> GLSL shaders do not allow any recursive calls. > > >> > > >> So what? > > > If I were asked the following question, how do you think I would answer? "Mr. Gabriel, will you feel safer if you wrote the code for this self-flying airplane or a team of engineers from the best corporations in the world?" Chuckle. The answer is obvious: I would feel safer if I wrote it! I don't trust compilers or other programmers - they suffer from Computer Dunning Kruger Syndrome. It's pathetic how stupid morons like python, burse, etc think they can use computer code as proof of a mathematical statement. Stupid, very stupid. Tsk, tsk.
[toc] | [prev] | [next] | [standalone]
| From | Python <python@python.invalid> |
|---|---|
| Date | 2018-03-13 00:24 +0100 |
| Message-ID | <5aa70c38$0$3322$426a74cc@news.free.fr> |
| In reply to | #408083 |
John Gabriel wrote: > On Monday, 12 March 2018 19:02:00 UTC-4, John Gabriel wrote: >> On Monday, 12 March 2018 18:41:51 UTC-4, Chris M. Thomasson wrote: >>> On 3/12/2018 3:21 PM, John Gabriel wrote: >>>> On Monday, 12 March 2018 18:05:03 UTC-4, Python wrote: >>>>> Chris M. Thomasson wrote: >>>>> ... >>>>>>>> John Gabriel wrote: >>>>>>>> ... >>>>>>>>> Recursion is very problematic. No sound application uses recursion. >>>>>>>>> No matter what you do to make it better, it can always fail for a >>>>>>>>> multitude of reasons. >>>>>>>> >>>>>>>> This claim from John Gabriel, allegedly software engineer, is >>>>>>>> outrageously wrong. >>>>>>> >>>>>>> I would say that recursion can be problematic. >>>>> >>>>> I didn't object to that claim, I objected to this one, from Mr Gabriel: >>>>> >>>>>>> No sound application uses recursion. >>>>>>> No matter what you do to make it better, it can always fail for a >>>>>>> multitude of reasons. >>>> >>>> You can object all you like, but it won't change the fact that you are wrong! As always. >>> >>> It is not fun when a threads stack actually does blow up. One time, the >>> recursion was not even that deep, however, prior functions that called >>> it used a lot of stack space already. And, well, that made the recursion >>> very scary. >> >> The main problem with recursion is that it is implemented differently by different compilers. So you may think it is doing what it was on a different compiler when in fact it is not. >> >> In an enterprise scenario (the real world, not the Mickey Mouse world of jean pierre messager who lives at school!), you will never use recursion because i) there is no need ii) it can lead to many problems iii) it is difficult to maintain iv) you cannot simply change the parameter list of a recursive function and expect it to work flawlessly - you can do this if the function code needs no modification v) if you are using abstract data structures such as linked lists, then you may end up in hell. vi) if you are allocating/deallocating memory the program can fail because of memory leaks even if your recursive routine doesn't fail. >> >> See, recursion is for college school boys. They react: "Wow. Isn't this cool?" >> >> "Let's do everything with recursion!" >> >> But obviously they are stupid and wet behind the ears. Chuckle. >> >> End of computer science lesson. >> >>> >>> >>>> >>>>> >>>>> >>>>>> GLSL shaders do not allow any recursive calls. >>>>> >>>>> So what? >>>> > > If I were asked the following question, how do you think I would answer? > > "Mr. Gabriel, will you feel safer if you wrote the code for this self-flying airplane or a team of engineers from the best corporations in the world?" > > Chuckle. The answer is obvious: I would feel safer if I wrote it! > > I don't trust compilers or other programmers - they suffer from Computer Dunning Kruger Syndrome. > > It's pathetic how stupid morons like python, burse, etc think they can use computer code as proof of a mathematical statement. You'd better avoid taking an Airbus plane, Mr Gabriel. Navigation software embedded in a lot of these planes has been validated by software proving software in Grenoble (France) using a lot of recursion techniques. Even the C compiler used to build part of the embedded flight software has been validated by the COQ theorem prover. > Stupid, very stupid. Tsk, tsk. You talking about CS is almost as much as a joke as you talking about mathematics, Mr Gabriel.
[toc] | [prev] | [next] | [standalone]
| From | John Gabriel <thenewcalculus@gmail.com> |
|---|---|
| Date | 2018-03-12 17:07 -0700 |
| Message-ID | <4d64a04c-f813-4a80-bfd4-539feed207dc@googlegroups.com> |
| In reply to | #408084 |
On Monday, 12 March 2018 19:24:47 UTC-4, Python wrote: > John Gabriel wrote: > > On Monday, 12 March 2018 19:02:00 UTC-4, John Gabriel wrote: > >> On Monday, 12 March 2018 18:41:51 UTC-4, Chris M. Thomasson wrote: > >>> On 3/12/2018 3:21 PM, John Gabriel wrote: > >>>> On Monday, 12 March 2018 18:05:03 UTC-4, Python wrote: > >>>>> Chris M. Thomasson wrote: > >>>>> ... > >>>>>>>> John Gabriel wrote: > >>>>>>>> ... > >>>>>>>>> Recursion is very problematic. No sound application uses recursion. > >>>>>>>>> No matter what you do to make it better, it can always fail for a > >>>>>>>>> multitude of reasons. > >>>>>>>> > >>>>>>>> This claim from John Gabriel, allegedly software engineer, is > >>>>>>>> outrageously wrong. > >>>>>>> > >>>>>>> I would say that recursion can be problematic. > >>>>> > >>>>> I didn't object to that claim, I objected to this one, from Mr Gabriel: > >>>>> > >>>>>>> No sound application uses recursion. > >>>>>>> No matter what you do to make it better, it can always fail for a > >>>>>>> multitude of reasons. > >>>> > >>>> You can object all you like, but it won't change the fact that you are wrong! As always. > >>> > >>> It is not fun when a threads stack actually does blow up. One time, the > >>> recursion was not even that deep, however, prior functions that called > >>> it used a lot of stack space already. And, well, that made the recursion > >>> very scary. > >> > >> The main problem with recursion is that it is implemented differently by different compilers. So you may think it is doing what it was on a different compiler when in fact it is not. > >> > >> In an enterprise scenario (the real world, not the Mickey Mouse world of jean pierre messager who lives at school!), you will never use recursion because i) there is no need ii) it can lead to many problems iii) it is difficult to maintain iv) you cannot simply change the parameter list of a recursive function and expect it to work flawlessly - you can do this if the function code needs no modification v) if you are using abstract data structures such as linked lists, then you may end up in hell. vi) if you are allocating/deallocating memory the program can fail because of memory leaks even if your recursive routine doesn't fail. > >> > >> See, recursion is for college school boys. They react: "Wow. Isn't this cool?" > >> > >> "Let's do everything with recursion!" > >> > >> But obviously they are stupid and wet behind the ears. Chuckle. > >> > >> End of computer science lesson. > >> > >>> > >>> > >>>> > >>>>> > >>>>> > >>>>>> GLSL shaders do not allow any recursive calls. > >>>>> > >>>>> So what? > >>>> > > > > If I were asked the following question, how do you think I would answer? > > > > "Mr. Gabriel, will you feel safer if you wrote the code for this self-flying airplane or a team of engineers from the best corporations in the world?" > > > > Chuckle. The answer is obvious: I would feel safer if I wrote it! > > > > I don't trust compilers or other programmers - they suffer from Computer Dunning Kruger Syndrome. > > > > It's pathetic how stupid morons like python, burse, etc think they can use computer code as proof of a mathematical statement. > > You'd better avoid taking an Airbus plane, Mr Gabriel. Navigation > software embedded in a lot of these planes has been validated by > software proving software in Grenoble (France) using a lot of > recursion techniques. Even the C compiler used to build > part of the embedded flight software has been validated by the > COQ theorem prover. You talking about AirBus is quite hilarious. > > > Stupid, very stupid. Tsk, tsk. > > You talking about CS is almost as much as a joke as you talking about > mathematics, Mr Gabriel. And yet every time you end up looking a fool. Chuckle.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid> |
|---|---|
| Date | 2018-03-12 16:51 -0700 |
| Message-ID | <p873pu$n89$1@dont-email.me> |
| In reply to | #408083 |
On 3/12/2018 4:06 PM, John Gabriel wrote: > On Monday, 12 March 2018 19:02:00 UTC-4, John Gabriel wrote: >> On Monday, 12 March 2018 18:41:51 UTC-4, Chris M. Thomasson wrote: >>> On 3/12/2018 3:21 PM, John Gabriel wrote: >>>> On Monday, 12 March 2018 18:05:03 UTC-4, Python wrote: >>>>> Chris M. Thomasson wrote: >>>>> ... >>>>>>>> John Gabriel wrote: >>>>>>>> ... >>>>>>>>> Recursion is very problematic. No sound application uses recursion. >>>>>>>>> No matter what you do to make it better, it can always fail for a >>>>>>>>> multitude of reasons. >>>>>>>> >>>>>>>> This claim from John Gabriel, allegedly software engineer, is >>>>>>>> outrageously wrong. >>>>>>> >>>>>>> I would say that recursion can be problematic. >>>>> >>>>> I didn't object to that claim, I objected to this one, from Mr Gabriel: >>>>> >>>>>>> No sound application uses recursion. >>>>>>> No matter what you do to make it better, it can always fail for a >>>>>>> multitude of reasons. >>>> >>>> You can object all you like, but it won't change the fact that you are wrong! As always. >>> >>> It is not fun when a threads stack actually does blow up. One time, the >>> recursion was not even that deep, however, prior functions that called >>> it used a lot of stack space already. And, well, that made the recursion >>> very scary. >> >> The main problem with recursion is that it is implemented differently by different compilers. So you may think it is doing what it was on a different compiler when in fact it is not. >> >> In an enterprise scenario (the real world, not the Mickey Mouse world of jean pierre messager who lives at school!), you will never use recursion because i) there is no need ii) it can lead to many problems iii) it is difficult to maintain iv) you cannot simply change the parameter list of a recursive function and expect it to work flawlessly - you can do this if the function code needs no modification v) if you are using abstract data structures such as linked lists, then you may end up in hell. vi) if you are allocating/deallocating memory the program can fail because of memory leaks even if your recursive routine doesn't fail. >> >> See, recursion is for college school boys. They react: "Wow. Isn't this cool?" >> >> "Let's do everything with recursion!" >> >> But obviously they are stupid and wet behind the ears. Chuckle. >> >> End of computer science lesson. >> >>> >>> >>>> >>>>> >>>>> >>>>>> GLSL shaders do not allow any recursive calls. >>>>> >>>>> So what? >>>> > > If I were asked the following question, how do you think I would answer? > > "Mr. Gabriel, will you feel safer if you wrote the code for this self-flying airplane or a team of engineers from the best corporations in the world?" > > Chuckle. The answer is obvious: I would feel safer if I wrote it! > > I don't trust compilers or other programmers - they suffer from Computer Dunning Kruger Syndrome. Check this out: http://www.stroustrup.com/JSF-AV-rules.pdf > It's pathetic how stupid morons like python, burse, etc think they can use computer code as proof of a mathematical statement. > > Stupid, very stupid. Tsk, tsk. > Code is not a "proof", but rather a means to actually implement something. The code can be used in conjunction with a proof.
[toc] | [prev] | [next] | [standalone]
| From | John Gabriel <thenewcalculus@gmail.com> |
|---|---|
| Date | 2018-03-12 17:08 -0700 |
| Message-ID | <7851ea52-4d89-405b-8642-637d3d36cdac@googlegroups.com> |
| In reply to | #408086 |
On Monday, 12 March 2018 19:51:33 UTC-4, Chris M. Thomasson wrote: > On 3/12/2018 4:06 PM, John Gabriel wrote: > > On Monday, 12 March 2018 19:02:00 UTC-4, John Gabriel wrote: > >> On Monday, 12 March 2018 18:41:51 UTC-4, Chris M. Thomasson wrote: > >>> On 3/12/2018 3:21 PM, John Gabriel wrote: > >>>> On Monday, 12 March 2018 18:05:03 UTC-4, Python wrote: > >>>>> Chris M. Thomasson wrote: > >>>>> ... > >>>>>>>> John Gabriel wrote: > >>>>>>>> ... > >>>>>>>>> Recursion is very problematic. No sound application uses recursion. > >>>>>>>>> No matter what you do to make it better, it can always fail for a > >>>>>>>>> multitude of reasons. > >>>>>>>> > >>>>>>>> This claim from John Gabriel, allegedly software engineer, is > >>>>>>>> outrageously wrong. > >>>>>>> > >>>>>>> I would say that recursion can be problematic. > >>>>> > >>>>> I didn't object to that claim, I objected to this one, from Mr Gabriel: > >>>>> > >>>>>>> No sound application uses recursion. > >>>>>>> No matter what you do to make it better, it can always fail for a > >>>>>>> multitude of reasons. > >>>> > >>>> You can object all you like, but it won't change the fact that you are wrong! As always. > >>> > >>> It is not fun when a threads stack actually does blow up. One time, the > >>> recursion was not even that deep, however, prior functions that called > >>> it used a lot of stack space already. And, well, that made the recursion > >>> very scary. > >> > >> The main problem with recursion is that it is implemented differently by different compilers. So you may think it is doing what it was on a different compiler when in fact it is not. > >> > >> In an enterprise scenario (the real world, not the Mickey Mouse world of jean pierre messager who lives at school!), you will never use recursion because i) there is no need ii) it can lead to many problems iii) it is difficult to maintain iv) you cannot simply change the parameter list of a recursive function and expect it to work flawlessly - you can do this if the function code needs no modification v) if you are using abstract data structures such as linked lists, then you may end up in hell. vi) if you are allocating/deallocating memory the program can fail because of memory leaks even if your recursive routine doesn't fail. > >> > >> See, recursion is for college school boys. They react: "Wow. Isn't this cool?" > >> > >> "Let's do everything with recursion!" > >> > >> But obviously they are stupid and wet behind the ears. Chuckle. > >> > >> End of computer science lesson. > >> > >>> > >>> > >>>> > >>>>> > >>>>> > >>>>>> GLSL shaders do not allow any recursive calls. > >>>>> > >>>>> So what? > >>>> > > > > If I were asked the following question, how do you think I would answer? > > > > "Mr. Gabriel, will you feel safer if you wrote the code for this self-flying airplane or a team of engineers from the best corporations in the world?" > > > > Chuckle. The answer is obvious: I would feel safer if I wrote it! > > > > I don't trust compilers or other programmers - they suffer from Computer Dunning Kruger Syndrome. > > Check this out: > > http://www.stroustrup.com/JSF-AV-rules.pdf > > > > It's pathetic how stupid morons like python, burse, etc think they can use computer code as proof of a mathematical statement. > > > > Stupid, very stupid. Tsk, tsk. > > > > Code is not a "proof", but rather a means to actually implement > something. The code can be used in conjunction with a proof. Nope. Code cannot be used as proof of anything. It can be used to support proof but can never be part of a proof.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid> |
|---|---|
| Date | 2018-03-12 20:19 -0700 |
| Message-ID | <p87g1j$r0j$1@dont-email.me> |
| In reply to | #408090 |
On 3/12/2018 5:08 PM, John Gabriel wrote: > On Monday, 12 March 2018 19:51:33 UTC-4, Chris M. Thomasson wrote: >> On 3/12/2018 4:06 PM, John Gabriel wrote: >>> On Monday, 12 March 2018 19:02:00 UTC-4, John Gabriel wrote: >>>> On Monday, 12 March 2018 18:41:51 UTC-4, Chris M. Thomasson wrote: >>>>> On 3/12/2018 3:21 PM, John Gabriel wrote: >>>>>> On Monday, 12 March 2018 18:05:03 UTC-4, Python wrote: >>>>>>> Chris M. Thomasson wrote: >>>>>>> ... >>>>>>>>>> John Gabriel wrote: >>>>>>>>>> ... >>>>>>>>>>> Recursion is very problematic. No sound application uses recursion. >>>>>>>>>>> No matter what you do to make it better, it can always fail for a >>>>>>>>>>> multitude of reasons. >>>>>>>>>> >>>>>>>>>> This claim from John Gabriel, allegedly software engineer, is >>>>>>>>>> outrageously wrong. >>>>>>>>> >>>>>>>>> I would say that recursion can be problematic. >>>>>>> >>>>>>> I didn't object to that claim, I objected to this one, from Mr Gabriel: >>>>>>> >>>>>>>>> No sound application uses recursion. >>>>>>>>> No matter what you do to make it better, it can always fail for a >>>>>>>>> multitude of reasons. >>>>>> >>>>>> You can object all you like, but it won't change the fact that you are wrong! As always. >>>>> >>>>> It is not fun when a threads stack actually does blow up. One time, the >>>>> recursion was not even that deep, however, prior functions that called >>>>> it used a lot of stack space already. And, well, that made the recursion >>>>> very scary. >>>> >>>> The main problem with recursion is that it is implemented differently by different compilers. So you may think it is doing what it was on a different compiler when in fact it is not. >>>> >>>> In an enterprise scenario (the real world, not the Mickey Mouse world of jean pierre messager who lives at school!), you will never use recursion because i) there is no need ii) it can lead to many problems iii) it is difficult to maintain iv) you cannot simply change the parameter list of a recursive function and expect it to work flawlessly - you can do this if the function code needs no modification v) if you are using abstract data structures such as linked lists, then you may end up in hell. vi) if you are allocating/deallocating memory the program can fail because of memory leaks even if your recursive routine doesn't fail. >>>> >>>> See, recursion is for college school boys. They react: "Wow. Isn't this cool?" >>>> >>>> "Let's do everything with recursion!" >>>> >>>> But obviously they are stupid and wet behind the ears. Chuckle. >>>> >>>> End of computer science lesson. >>>> >>>>> >>>>> >>>>>> >>>>>>> >>>>>>> >>>>>>>> GLSL shaders do not allow any recursive calls. >>>>>>> >>>>>>> So what? >>>>>> >>> >>> If I were asked the following question, how do you think I would answer? >>> >>> "Mr. Gabriel, will you feel safer if you wrote the code for this self-flying airplane or a team of engineers from the best corporations in the world?" >>> >>> Chuckle. The answer is obvious: I would feel safer if I wrote it! >>> >>> I don't trust compilers or other programmers - they suffer from Computer Dunning Kruger Syndrome. >> >> Check this out: >> >> http://www.stroustrup.com/JSF-AV-rules.pdf >> >> >>> It's pathetic how stupid morons like python, burse, etc think they can use computer code as proof of a mathematical statement. >>> >>> Stupid, very stupid. Tsk, tsk. >>> >> >> Code is not a "proof", but rather a means to actually implement >> something. The code can be used in conjunction with a proof. > > Nope. Code cannot be used as proof of anything. It can be used to support proof but can never be part of a proof. > Imho, a proof along with some example code that supports it by actually implementing algorithms based on it, is a good thing. :^)
[toc] | [prev] | [next] | [standalone]
| From | Python <python@python.invalid> |
|---|---|
| Date | 2018-03-11 00:53 +0100 |
| Message-ID | <5aa46fd9$0$3836$426a74cc@news.free.fr> |
| In reply to | #407915 |
John Gabriel wrote: ... >> Actually, afaict, this does not need to be recursive in nature. An outer >> loop will do. Will have some more time later on today to get rid of any >> recursion. > > Of course not. Recursion can be very problematic. A compiler handles recursive calls to a function by using the stack - lots of PUSH and POP operations which can lead to stack overflow. > > You can implement controlled recursion as follows: > > 1. Allocate arrays for stack variables with maximum size allowable or a boundary that you know it must not exceed. > 2. Maintain an index starting at 0. Each time you PUSH (invoke the function or sub-routine), increment index. Each time you POP (exit function or subroutine), decrement index. > 3. You can prevent stack overflow by monitoring the index. Well... John Gabriel, allegedly software developer, has never heard about tail recursion? How come I'm not surprised?
[toc] | [prev] | [next] | [standalone]
| From | WM <wolfgang.mueckenheim@hs-augsburg.de> |
|---|---|
| Date | 2018-03-09 03:14 -0800 |
| Message-ID | <68416341-2d89-414c-a82b-052a5ea53177@googlegroups.com> |
| In reply to | #407691 |
Am Freitag, 9. März 2018 07:06:58 UTC+1 schrieb burs...@gmail.com: > You just need to reduce the amplitude more > stronger, then you elarge the period, Not the period but the frequency, here by 2. > then > you can create something: > - monotonic > - smooth Correct. But this is not the case here. And even by taking another factor, it cannot be accomplished. Regards, WM
[toc] | [prev] | [next] | [standalone]
| From | Python <python@python.invalid> |
|---|---|
| Date | 2018-03-09 06:42 +0100 |
| Message-ID | <5aa21eca$0$3319$426a74cc@news.free.fr> |
| In reply to | #407681 |
bursejan@gmail.com wrote: > Do you have some presonal problem with fractals > or what? U f_n is simply this picture: > > https://www.wolframalpha.com/input/?i=abs%28t-floor%28t%2B1%2F2%29%29,+1%2F2*abs%28t*2-floor%28t*2%2B1%2F2%29%29,+1%2F4*abs%28t*4-floor%28t*4%2B1%2F2%29%29,+1%2F8*abs%28t*8-floor%28t*8%2B1%2F2%29%29+from+0+to+2 > > And you can extract the lim from the picture, > by taking the glb. Thats all. Fractal are fancy, but this is true for any monotonic pointwise convergent sequence of functions. It works for the staircase sequence, but not for the sequences of sines. Big deal.
[toc] | [prev] | [next] | [standalone]
| From | bursejan@gmail.com |
|---|---|
| Date | 2018-03-08 18:20 -0800 |
| Message-ID | <518cd0d2-c714-4dc0-81ac-c3f33cc87d73@googlegroups.com> |
| In reply to | #407657 |
With partial order on functions, we could
do it as follows, when f_1 >= f_2 >= f_3 ...:
lim n->oo f_n = lub { f_n }
But to invoke the fractal picture, especially
since FredJeffreys, didn't accept a single
stair case as a fractal, we superimpose, and
can also do, for a exact definition see
previous post, resp. text below, the following:
lim n->oo f_n = lub U graph(f_n)
BTW: I would like to call this the potpurry
theorem. Didn't expect it to come out this way,
that we can blow up a set { f_n }.
Am Freitag, 9. März 2018 03:05:57 UTC+1 schrieb burs...@gmail.com:
> if you want it order theoretic, then a lub
> would be needed that does not operate on points,
> but on functions. So you have this order:
>
> u =<_2 v :<=> forall x (u(x) =<_1 v(x))
>
> if =<_1 is a partial order so is =<_2
>
> Then lets do it again. We just pick functions
> out of the graph union:
>
> lub { u | u subset U graph(f_n), u functional }
>
> Which we allow as shorthand:
>
> lub U graph(f_n)
>
> So any horizontal path u inside U graph(f_n)
> would be picked. You then have, when
> f_1 >= f_2 >= f_3 ...:
>
> lim n->oo f_n = lub U graph(f_n)
>
> Am Freitag, 9. März 2018 02:53:51 UTC+1 schrieb burs...@gmail.com:
> > Well the U graph(f_n) fractal is here,
> > just do visually the tripple dots ...:
> >
> > https://www.wolframalpha.com/input/?i=abs%28t-floor%28t%2B1%2F2%29%29,+1%2F2*abs%28t*2-floor%28t*2%2B1%2F2%29%29,+1%2F4*abs%28t*4-floor%28t*4%2B1%2F2%29%29,+1%2F8*abs%28t*8-floor%28t*8%2B1%2F2%29%29+from+0+to+2
> >
> > And lub along the y-axis of U graph(f_n)
> > gives the straight line f(x)=0.
> >
> > Thats all pretty trivial stuff.
[toc] | [prev] | [next] | [standalone]
| From | bursejan@gmail.com |
|---|---|
| Date | 2018-03-08 18:29 -0800 |
| Message-ID | <408820d3-6070-4593-b231-727ab0509b90@googlegroups.com> |
| In reply to | #407661 |
If you can give a counterexample (to the
now baptized potpurri theorem), feel free
to post it here. I am waiting, I am not
in a hurry. Maybe something is wrong, who
knows? This is just a newsgroup, not a
proof assistant. But you don't need to
lookup topology, the crucial definition:
u =<_2 v :<=> forall x (u(x) =<_1 v(x))
Is from lattice theory, see here:
https://math.stackexchange.com/q/657711/4414
But I am not requiring u,v continous. Who
knows what the limit will be?
Am Freitag, 9. März 2018 03:20:11 UTC+1 schrieb burs...@gmail.com:
> With partial order on functions, we could
> do it as follows, when f_1 >= f_2 >= f_3 ...:
>
> lim n->oo f_n = lub { f_n }
>
> But to invoke the fractal picture, especially
> since FredJeffreys, didn't accept a single
> stair case as a fractal, we superimpose, and
>
> can also do, for a exact definition see
> previous post, resp. text below, the following:
>
> lim n->oo f_n = lub U graph(f_n)
>
> BTW: I would like to call this the potpurry
> theorem. Didn't expect it to come out this way,
> that we can blow up a set { f_n }.
>
> Am Freitag, 9. März 2018 03:05:57 UTC+1 schrieb burs...@gmail.com:
> > if you want it order theoretic, then a lub
> > would be needed that does not operate on points,
> > but on functions. So you have this order:
> >
> > u =<_2 v :<=> forall x (u(x) =<_1 v(x))
> >
> > if =<_1 is a partial order so is =<_2
> >
> > Then lets do it again. We just pick functions
> > out of the graph union:
> >
> > lub { u | u subset U graph(f_n), u functional }
> >
> > Which we allow as shorthand:
> >
> > lub U graph(f_n)
> >
> > So any horizontal path u inside U graph(f_n)
> > would be picked. You then have, when
> > f_1 >= f_2 >= f_3 ...:
> >
> > lim n->oo f_n = lub U graph(f_n)
> >
> > Am Freitag, 9. März 2018 02:53:51 UTC+1 schrieb burs...@gmail.com:
> > > Well the U graph(f_n) fractal is here,
> > > just do visually the tripple dots ...:
> > >
> > > https://www.wolframalpha.com/input/?i=abs%28t-floor%28t%2B1%2F2%29%29,+1%2F2*abs%28t*2-floor%28t*2%2B1%2F2%29%29,+1%2F4*abs%28t*4-floor%28t*4%2B1%2F2%29%29,+1%2F8*abs%28t*8-floor%28t*8%2B1%2F2%29%29+from+0+to+2
> > >
> > > And lub along the y-axis of U graph(f_n)
> > > gives the straight line f(x)=0.
> > >
> > > Thats all pretty trivial stuff.
[toc] | [prev] | [next] | [standalone]
Page 8 of 16 — ← Prev page 1 … 6 7 [8] 9 10 … 16 Next page →
Back to top | Article view | sci.math
csiph-web