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 7 of 16 — ← Prev page 1 … 5 6 [7] 8 9 … 16 Next page →
| From | Python <python@python.invalid> |
|---|---|
| Date | 2018-03-09 06:53 +0100 |
| Message-ID | <5aa2216f$0$3856$426a74cc@news.free.fr> |
| In reply to | #407686 |
Le 09/03/2018 à 06:46, bursejan@gmail.com a écrit : > If you arrange the sins as follows: > > f_n(x) = 1/2^n (1 + sin(2^n*x)) > > You get also montonocity. I don't think so. It is not true that for all x f_(n+1)(x) <= f_n(x) https://www.wolframalpha.com/input/?i=1%2F2%5E2+(1+%2B+sin(2%5E2*x)),+1%2F2%5E3+(1+%2B+sin(2%5E3*x))+from+0+to+pi Here you can keep monotonicity: https://www.wolframalpha.com/input/?i=abs(1%2F2%5E2+*+sin(2%5E2*x)),+abs(1%2F2%5E3+*+sin(2%5E3*x))+from+0+to+pi but we loose smoothness. IMHO it's still irrelevant.
[toc] | [prev] | [next] | [standalone]
| From | bursejan@gmail.com |
|---|---|
| Date | 2018-03-08 22:00 -0800 |
| Message-ID | <ed9f4e13-f294-4db0-986d-10e1e1bffee1@googlegroups.com> |
| In reply to | #407688 |
This one wurks: https://www.wolframalpha.com/input/?i=|sin%28t%29|,+1%2F2+|sin%282*t%29|,+1%2F4+|sin%284*t%29|,+1%2F8+|sin%288*t%29|+from+0+to+2*pi But since it is not smooth, something else needs to be tried. I already got an idea. BTW: I want desperatly need a iranian rug out of that! Am Freitag, 9. März 2018 06:53:57 UTC+1 schrieb Python: > Le 09/03/2018 à 06:46, bursejan@gmail.com a écrit : > > If you arrange the sins as follows: > > > > f_n(x) = 1/2^n (1 + sin(2^n*x)) > > > > You get also montonocity. > > I don't think so. It is not true that for all x > f_(n+1)(x) <= f_n(x) > > https://www.wolframalpha.com/input/?i=1%2F2%5E2+(1+%2B+sin(2%5E2*x)),+1%2F2%5E3+(1+%2B+sin(2%5E3*x))+from+0+to+pi > > Here you can keep monotonicity: > > https://www.wolframalpha.com/input/?i=abs(1%2F2%5E2+*+sin(2%5E2*x)),+abs(1%2F2%5E3+*+sin(2%5E3*x))+from+0+to+pi > > but we loose smoothness. > > IMHO it's still irrelevant.
[toc] | [prev] | [next] | [standalone]
| From | bursejan@gmail.com |
|---|---|
| Date | 2018-03-08 22:06 -0800 |
| Message-ID | <eb4bcdef-2d72-4732-8e49-930e2afad626@googlegroups.com> |
| In reply to | #407690 |
You just need to reduce the amplitude more stronger, then you elarge the period, then you can create something: - monotonic - smooth But the arc length is then a problem, that you don't get an arc length, that is in the limit same as the straight line. This would happen if: lim n->oo f_n' = 0 But there is not really a bet to find such a montonic sequence. Where is this implied that we would need this, montonicity? Also without monoticity of the f_1,f_2,... the U f_n could be self similar? For example this here is a fractal, right? https://www.wolframalpha.com/input/?i=1+-+cos%28t%29,+1%2F2+%281+-+cos%282*t%29%29,+1%2F4+%281+-+cos%284*t%29%29,+1%2F8+%281+-+cos%288*t%29%29+from+0+to+2*pi Am Freitag, 9. März 2018 07:00:15 UTC+1 schrieb burs...@gmail.com: > This one wurks: > > https://www.wolframalpha.com/input/?i=|sin%28t%29|,+1%2F2+|sin%282*t%29|,+1%2F4+|sin%284*t%29|,+1%2F8+|sin%288*t%29|+from+0+to+2*pi > > But since it is not smooth, something else > needs to be tried. I already got an idea. > > BTW: I want desperatly need a iranian rug > out of that! > > Am Freitag, 9. März 2018 06:53:57 UTC+1 schrieb Python: > > Le 09/03/2018 à 06:46, bursejan@gmail.com a écrit : > > > If you arrange the sins as follows: > > > > > > f_n(x) = 1/2^n (1 + sin(2^n*x)) > > > > > > You get also montonocity. > > > > I don't think so. It is not true that for all x > > f_(n+1)(x) <= f_n(x) > > > > https://www.wolframalpha.com/input/?i=1%2F2%5E2+(1+%2B+sin(2%5E2*x)),+1%2F2%5E3+(1+%2B+sin(2%5E3*x))+from+0+to+pi > > > > Here you can keep monotonicity: > > > > https://www.wolframalpha.com/input/?i=abs(1%2F2%5E2+*+sin(2%5E2*x)),+abs(1%2F2%5E3+*+sin(2%5E3*x))+from+0+to+pi > > > > but we loose smoothness. > > > > IMHO it's still irrelevant.
[toc] | [prev] | [next] | [standalone]
| From | Python <python@python.invalid> |
|---|---|
| Date | 2018-03-09 07:13 +0100 |
| Message-ID | <5aa2260a$0$20422$426a74cc@news.free.fr> |
| In reply to | #407691 |
bursejan@gmail.com wrote: > You just need to reduce the amplitude more > stronger, then you elarge the period, then > you can create something: > - monotonic > - smooth > > But the arc length is then a problem, that > you don't get an arc length, that is in the > limit same as the straight line. > > This would happen if: > > lim n->oo f_n' = 0 > > But there is not really a bet to find such > a montonic sequence. Where is this implied > that we would need this, montonicity? I really don't know yet. I was playing with a few examples on wolfram and cas software, and I ended up with exactly the same conclusions as yours, creating monotonic and smooth at the same time is doable, but making the amplitude going down too fast is likely to make the arc length going too low, so converging to the length of the limit line. At the same time, if amplitude is going down too fast, we may be able to make the frequency going up faster, so that the length stays far from the limit.
[toc] | [prev] | [next] | [standalone]
| From | bursejan@gmail.com |
|---|---|
| Date | 2018-03-08 22:15 -0800 |
| Message-ID | <fc7cb170-ad91-448c-b5be-850c8e274505@googlegroups.com> |
| In reply to | #407691 |
This is "Elephant Foot": https://www.wolframalpha.com/input/?i=1+-+cos%28t%29,+1%2F4+%281+-+cos%282*t%29%29,+1%2F16+%281+-+cos%284*t%29%29,+1%2F64+%281+-+cos%288*t%29%29+from+0+to+2*pi Smooth, montonic, unfortunately length converges to length of straight line. Good Night P.S.: If we can pack more arc length into the toes of the elephant, we can possibly recreate the paradox with smooth AND monotonic. 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, then > you can create something: > - monotonic > - smooth > > But the arc length is then a problem, that > you don't get an arc length, that is in the > limit same as the straight line. > > This would happen if: > > lim n->oo f_n' = 0 > > But there is not really a bet to find such > a montonic sequence. Where is this implied > that we would need this, montonicity? > > Also without monoticity of the f_1,f_2,... > the U f_n could be self similar? For example > this here is a fractal, right? > > https://www.wolframalpha.com/input/?i=1+-+cos%28t%29,+1%2F2+%281+-+cos%282*t%29%29,+1%2F4+%281+-+cos%284*t%29%29,+1%2F8+%281+-+cos%288*t%29%29+from+0+to+2*pi > > Am Freitag, 9. März 2018 07:00:15 UTC+1 schrieb burs...@gmail.com: > > This one wurks: > > > > https://www.wolframalpha.com/input/?i=|sin%28t%29|,+1%2F2+|sin%282*t%29|,+1%2F4+|sin%284*t%29|,+1%2F8+|sin%288*t%29|+from+0+to+2*pi > > > > But since it is not smooth, something else > > needs to be tried. I already got an idea. > > > > BTW: I want desperatly need a iranian rug > > out of that! > > > > Am Freitag, 9. März 2018 06:53:57 UTC+1 schrieb Python: > > > Le 09/03/2018 à 06:46, bursejan@gmail.com a écrit : > > > > If you arrange the sins as follows: > > > > > > > > f_n(x) = 1/2^n (1 + sin(2^n*x)) > > > > > > > > You get also montonocity. > > > > > > I don't think so. It is not true that for all x > > > f_(n+1)(x) <= f_n(x) > > > > > > https://www.wolframalpha.com/input/?i=1%2F2%5E2+(1+%2B+sin(2%5E2*x)),+1%2F2%5E3+(1+%2B+sin(2%5E3*x))+from+0+to+pi > > > > > > Here you can keep monotonicity: > > > > > > https://www.wolframalpha.com/input/?i=abs(1%2F2%5E2+*+sin(2%5E2*x)),+abs(1%2F2%5E3+*+sin(2%5E3*x))+from+0+to+pi > > > > > > but we loose smoothness. > > > > > > IMHO it's still irrelevant.
[toc] | [prev] | [next] | [standalone]
| From | bursejan@gmail.com |
|---|---|
| Date | 2018-03-08 22:21 -0800 |
| Message-ID | <83048ca1-9d7a-4a38-8828-e770a9316f35@googlegroups.com> |
| In reply to | #407693 |
Or there is a proof somewhere that monotonic and smooth isn't possible, with a different outcome for the arc length. Am Freitag, 9. März 2018 07:15:45 UTC+1 schrieb burs...@gmail.com: > This is "Elephant Foot": > > https://www.wolframalpha.com/input/?i=1+-+cos%28t%29,+1%2F4+%281+-+cos%282*t%29%29,+1%2F16+%281+-+cos%284*t%29%29,+1%2F64+%281+-+cos%288*t%29%29+from+0+to+2*pi > > Smooth, montonic, unfortunately length > converges to length of straight line. > > Good Night > > P.S.: If we can pack more arc length > into the toes of the elephant, we can > possibly recreate the paradox with > smooth AND monotonic. > > 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, then > > you can create something: > > - monotonic > > - smooth > > > > But the arc length is then a problem, that > > you don't get an arc length, that is in the > > limit same as the straight line. > > > > This would happen if: > > > > lim n->oo f_n' = 0 > > > > But there is not really a bet to find such > > a montonic sequence. Where is this implied > > that we would need this, montonicity? > > > > Also without monoticity of the f_1,f_2,... > > the U f_n could be self similar? For example > > this here is a fractal, right? > > > > https://www.wolframalpha.com/input/?i=1+-+cos%28t%29,+1%2F2+%281+-+cos%282*t%29%29,+1%2F4+%281+-+cos%284*t%29%29,+1%2F8+%281+-+cos%288*t%29%29+from+0+to+2*pi > > > > Am Freitag, 9. März 2018 07:00:15 UTC+1 schrieb burs...@gmail.com: > > > This one wurks: > > > > > > https://www.wolframalpha.com/input/?i=|sin%28t%29|,+1%2F2+|sin%282*t%29|,+1%2F4+|sin%284*t%29|,+1%2F8+|sin%288*t%29|+from+0+to+2*pi > > > > > > But since it is not smooth, something else > > > needs to be tried. I already got an idea. > > > > > > BTW: I want desperatly need a iranian rug > > > out of that! > > > > > > Am Freitag, 9. März 2018 06:53:57 UTC+1 schrieb Python: > > > > Le 09/03/2018 à 06:46, bursejan@gmail.com a écrit : > > > > > If you arrange the sins as follows: > > > > > > > > > > f_n(x) = 1/2^n (1 + sin(2^n*x)) > > > > > > > > > > You get also montonocity. > > > > > > > > I don't think so. It is not true that for all x > > > > f_(n+1)(x) <= f_n(x) > > > > > > > > https://www.wolframalpha.com/input/?i=1%2F2%5E2+(1+%2B+sin(2%5E2*x)),+1%2F2%5E3+(1+%2B+sin(2%5E3*x))+from+0+to+pi > > > > > > > > Here you can keep monotonicity: > > > > > > > > https://www.wolframalpha.com/input/?i=abs(1%2F2%5E2+*+sin(2%5E2*x)),+abs(1%2F2%5E3+*+sin(2%5E3*x))+from+0+to+pi > > > > > > > > but we loose smoothness. > > > > > > > > IMHO it's still irrelevant.
[toc] | [prev] | [next] | [standalone]
| From | Python <python@python.invalid> |
|---|---|
| Date | 2018-03-09 07:27 +0100 |
| Message-ID | <5aa22935$0$3703$426a74cc@news.free.fr> |
| In reply to | #407695 |
bursejan@gmail.com wrote: > Or there is a proof somewhere that monotonic > and smooth isn't possible, with a different > outcome for the arc length. I don't think so. The staircase example or the abs(...) example can be slightly changed in order to be smooth. Remember that we are only trying to find functions defined by an explicit formula (whatever that means, what is explicit about sin or cos ?) because retarded Gabriel do not recognize anything else as functions (what he calls "rules", which is meaningless). Well another reason to find out a explicit formula is because of elegance.
[toc] | [prev] | [next] | [standalone]
| From | Python <python@python.invalid> |
|---|---|
| Date | 2018-03-09 07:22 +0100 |
| Message-ID | <5aa2280b$0$4818$426a74cc@news.free.fr> |
| In reply to | #407693 |
bursejan@gmail.com wrote > > https://www.wolframalpha.com/input/?i=1+-+cos%28t%29,+1%2F4+%281+-+cos%282*t%29%29,+1%2F16+%281+-+cos%284*t%29%29,+1%2F64+%281+-+cos%288*t%29%29+from+0+to+2*pi > very nice! > Smooth, montonic, unfortunately length > converges to length of straight line. can be done IMO: add a another sine function to that amplitude only grows in between the Elephant toes, not enough to break monotony, but strong enough to get arbitrary high arc length. > Good Night Sogni d'oro.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid> |
|---|---|
| Date | 2018-03-09 00:00 -0800 |
| Message-ID | <p7tevk$rre$1@dont-email.me> |
| In reply to | #407696 |
On 3/8/2018 10:22 PM, Python wrote: > bursejan@gmail.com wrote >> >> https://www.wolframalpha.com/input/?i=1+-+cos%28t%29,+1%2F4+%281+-+cos%282*t%29%29,+1%2F16+%281+-+cos%284*t%29%29,+1%2F64+%281+-+cos%288*t%29%29+from+0+to+2*pi >> >> > > very nice! Fwiw, check out the following rendering: https://plus.google.com/101799841244447089430/posts/gp7F7sP5swj Fractal waves contained in the unit circle generated by a simple recursive parametric function. I posted the code in a response to Jan, who inspired me to create it in the first place: https://groups.google.com/d/msg/sci.math/uKj8GM0uRZU/Vk_LqPv8BAAJ > > >> Smooth, montonic, unfortunately length >> converges to length of straight line. > > can be done IMO: add a another sine function to that amplitude > only grows in between the Elephant toes, not enough to break > monotony, but strong enough to get arbitrary high arc length. > >> Good Night > > Sogni d'oro. > > >
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid> |
|---|---|
| Date | 2018-03-10 14:32 -0800 |
| Message-ID | <p81mds$7o7$1@dont-email.me> |
| In reply to | #407709 |
On 3/9/2018 12:00 AM, Chris M. Thomasson wrote: > On 3/8/2018 10:22 PM, Python wrote: >> bursejan@gmail.com wrote >>> >>> https://www.wolframalpha.com/input/?i=1+-+cos%28t%29,+1%2F4+%281+-+cos%282*t%29%29,+1%2F16+%281+-+cos%284*t%29%29,+1%2F64+%281+-+cos%288*t%29%29+from+0+to+2*pi >>> >>> >> >> very nice! > > Fwiw, check out the following rendering: > > https://plus.google.com/101799841244447089430/posts/gp7F7sP5swj > > Fractal waves contained in the unit circle generated by a simple > recursive parametric function. I posted the code in a response to Jan, > who inspired me to create it in the first place: > > https://groups.google.com/d/msg/sci.math/uKj8GM0uRZU/Vk_LqPv8BAAJ 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. > >> >> >>> Smooth, montonic, unfortunately length >>> converges to length of straight line. >> >> can be done IMO: add a another sine function to that amplitude >> only grows in between the Elephant toes, not enough to break >> monotony, but strong enough to get arbitrary high arc length. >> >>> Good Night >> >> Sogni d'oro. >> >> >> >
[toc] | [prev] | [next] | [standalone]
| From | John Gabriel <thenewcalculus@gmail.com> |
|---|---|
| Date | 2018-03-10 15:40 -0800 |
| Message-ID | <5c2193f3-e275-447e-b7eb-fdc9dbcfec04@googlegroups.com> |
| In reply to | #407910 |
On Saturday, 10 March 2018 17:32:35 UTC-5, Chris M. Thomasson wrote: > On 3/9/2018 12:00 AM, Chris M. Thomasson wrote: > > On 3/8/2018 10:22 PM, Python wrote: > >> bursejan@gmail.com wrote > >>> > >>> https://www.wolframalpha.com/input/?i=1+-+cos%28t%29,+1%2F4+%281+-+cos%282*t%29%29,+1%2F16+%281+-+cos%284*t%29%29,+1%2F64+%281+-+cos%288*t%29%29+from+0+to+2*pi > >>> > >>> > >> > >> very nice! > > > > Fwiw, check out the following rendering: > > > > https://plus.google.com/101799841244447089430/posts/gp7F7sP5swj > > > > Fractal waves contained in the unit circle generated by a simple > > recursive parametric function. I posted the code in a response to Jan, > > who inspired me to create it in the first place: > > > > https://groups.google.com/d/msg/sci.math/uKj8GM0uRZU/Vk_LqPv8BAAJ > > 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. Simple as this. :-)) > > > > >> > >> > >>> Smooth, montonic, unfortunately length > >>> converges to length of straight line. > >> > >> can be done IMO: add a another sine function to that amplitude > >> only grows in between the Elephant toes, not enough to break > >> monotony, but strong enough to get arbitrary high arc length. > >> > >>> Good Night > >> > >> Sogni d'oro. > >> > >> > >> > >
[toc] | [prev] | [next] | [standalone]
| From | John Gabriel <thenewcalculus@gmail.com> |
|---|---|
| Date | 2018-03-10 15:41 -0800 |
| Message-ID | <e6aa6281-8092-4876-a9f1-0c7f7bf60cd8@googlegroups.com> |
| In reply to | #407915 |
On Saturday, 10 March 2018 18:40:18 UTC-5, John Gabriel wrote: > On Saturday, 10 March 2018 17:32:35 UTC-5, Chris M. Thomasson wrote: > > On 3/9/2018 12:00 AM, Chris M. Thomasson wrote: > > > On 3/8/2018 10:22 PM, Python wrote: > > >> bursejan@gmail.com wrote > > >>> > > >>> https://www.wolframalpha.com/input/?i=1+-+cos%28t%29,+1%2F4+%281+-+cos%282*t%29%29,+1%2F16+%281+-+cos%284*t%29%29,+1%2F64+%281+-+cos%288*t%29%29+from+0+to+2*pi > > >>> > > >>> > > >> > > >> very nice! > > > > > > Fwiw, check out the following rendering: > > > > > > https://plus.google.com/101799841244447089430/posts/gp7F7sP5swj > > > > > > Fractal waves contained in the unit circle generated by a simple > > > recursive parametric function. I posted the code in a response to Jan, > > > who inspired me to create it in the first place: > > > > > > https://groups.google.com/d/msg/sci.math/uKj8GM0uRZU/Vk_LqPv8BAAJ > > > > 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. > > Simple as this. :-)) You'll also need to store the argument list every time. > > > > > > > > >> > > >> > > >>> Smooth, montonic, unfortunately length > > >>> converges to length of straight line. > > >> > > >> can be done IMO: add a another sine function to that amplitude > > >> only grows in between the Elephant toes, not enough to break > > >> monotony, but strong enough to get arbitrary high arc length. > > >> > > >>> Good Night > > >> > > >> Sogni d'oro. > > >> > > >> > > >> > > >
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid> |
|---|---|
| Date | 2018-03-10 15:53 -0800 |
| Message-ID | <p81r5h$92i$1@dont-email.me> |
| In reply to | #407916 |
On 3/10/2018 3:41 PM, John Gabriel wrote: > On Saturday, 10 March 2018 18:40:18 UTC-5, John Gabriel wrote: >> On Saturday, 10 March 2018 17:32:35 UTC-5, Chris M. Thomasson wrote: >>> On 3/9/2018 12:00 AM, Chris M. Thomasson wrote: >>>> On 3/8/2018 10:22 PM, Python wrote: >>>>> bursejan@gmail.com wrote >>>>>> >>>>>> https://www.wolframalpha.com/input/?i=1+-+cos%28t%29,+1%2F4+%281+-+cos%282*t%29%29,+1%2F16+%281+-+cos%284*t%29%29,+1%2F64+%281+-+cos%288*t%29%29+from+0+to+2*pi >>>>>> >>>>>> >>>>> >>>>> very nice! >>>> >>>> Fwiw, check out the following rendering: >>>> >>>> https://plus.google.com/101799841244447089430/posts/gp7F7sP5swj >>>> >>>> Fractal waves contained in the unit circle generated by a simple >>>> recursive parametric function. I posted the code in a response to Jan, >>>> who inspired me to create it in the first place: >>>> >>>> https://groups.google.com/d/msg/sci.math/uKj8GM0uRZU/Vk_LqPv8BAAJ >>> >>> 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. >> >> Simple as this. :-)) > > You'll also need to store the argument list every time. I do not want to blow up the stack: Yikes! ;^) Fwiw, I think it can be accomplished without allocating anything. Just adding an extra outer loop to take care of the single recursive call should work out nicely. I will have more time after dinner. >> >>> >>>> >>>>> >>>>> >>>>>> Smooth, montonic, unfortunately length >>>>>> converges to length of straight line. >>>>> >>>>> can be done IMO: add a another sine function to that amplitude >>>>> only grows in between the Elephant toes, not enough to break >>>>> monotony, but strong enough to get arbitrary high arc length. >>>>> >>>>>> Good Night >>>>> >>>>> Sogni d'oro. >>>>> >>>>> >>>>> >>>> >
[toc] | [prev] | [next] | [standalone]
| From | Jonas Thörnvall <jonas.thornvall@gmail.com> |
|---|---|
| Date | 2018-03-10 17:57 -0800 |
| Message-ID | <cd172232-6a8e-4dc3-9a4a-83bb84c13b9e@googlegroups.com> |
| In reply to | #407920 |
Den söndag 11 mars 2018 kl. 00:53:26 UTC+1 skrev Chris M. Thomasson: > On 3/10/2018 3:41 PM, John Gabriel wrote: > > On Saturday, 10 March 2018 18:40:18 UTC-5, John Gabriel wrote: > >> On Saturday, 10 March 2018 17:32:35 UTC-5, Chris M. Thomasson wrote: > >>> On 3/9/2018 12:00 AM, Chris M. Thomasson wrote: > >>>> On 3/8/2018 10:22 PM, Python wrote: > >>>>> bursejan@gmail.com wrote > >>>>>> > >>>>>> https://www.wolframalpha.com/input/?i=1+-+cos%28t%29,+1%2F4+%281+-+cos%282*t%29%29,+1%2F16+%281+-+cos%284*t%29%29,+1%2F64+%281+-+cos%288*t%29%29+from+0+to+2*pi > >>>>>> > >>>>>> > >>>>> > >>>>> very nice! > >>>> > >>>> Fwiw, check out the following rendering: > >>>> > >>>> https://plus.google.com/101799841244447089430/posts/gp7F7sP5swj > >>>> > >>>> Fractal waves contained in the unit circle generated by a simple > >>>> recursive parametric function. I posted the code in a response to Jan, > >>>> who inspired me to create it in the first place: > >>>> > >>>> https://groups.google.com/d/msg/sci.math/uKj8GM0uRZU/Vk_LqPv8BAAJ > >>> > >>> 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. > >> > >> Simple as this. :-)) > > > > You'll also need to store the argument list every time. > > I do not want to blow up the stack: Yikes! ;^) > > Fwiw, I think it can be accomplished without allocating anything. Just > adding an extra outer loop to take care of the single recursive call > should work out nicely. I will have more time after dinner. > > > >> > >>> > >>>> > >>>>> > >>>>> > >>>>>> Smooth, montonic, unfortunately length > >>>>>> converges to length of straight line. > >>>>> > >>>>> can be done IMO: add a another sine function to that amplitude > >>>>> only grows in between the Elephant toes, not enough to break > >>>>> monotony, but strong enough to get arbitrary high arc length. > >>>>> > >>>>>> Good Night > >>>>> > >>>>> Sogni d'oro. > >>>>> > >>>>> > >>>>> > >>>> > > https://www.youtube.com/watch?v=o1cRTW9AGVo
[toc] | [prev] | [next] | [standalone]
| From | John Gabriel <thenewcalculus@gmail.com> |
|---|---|
| Date | 2018-03-11 07:02 -0700 |
| Message-ID | <8290aa60-3661-4371-8821-175491585e58@googlegroups.com> |
| In reply to | #407920 |
On Saturday, 10 March 2018 18:53:26 UTC-5, Chris M. Thomasson wrote: > On 3/10/2018 3:41 PM, John Gabriel wrote: > > On Saturday, 10 March 2018 18:40:18 UTC-5, John Gabriel wrote: > >> On Saturday, 10 March 2018 17:32:35 UTC-5, Chris M. Thomasson wrote: > >>> On 3/9/2018 12:00 AM, Chris M. Thomasson wrote: > >>>> On 3/8/2018 10:22 PM, Python wrote: > >>>>> bursejan@gmail.com wrote > >>>>>> > >>>>>> https://www.wolframalpha.com/input/?i=1+-+cos%28t%29,+1%2F4+%281+-+cos%282*t%29%29,+1%2F16+%281+-+cos%284*t%29%29,+1%2F64+%281+-+cos%288*t%29%29+from+0+to+2*pi > >>>>>> > >>>>>> > >>>>> > >>>>> very nice! > >>>> > >>>> Fwiw, check out the following rendering: > >>>> > >>>> https://plus.google.com/101799841244447089430/posts/gp7F7sP5swj > >>>> > >>>> Fractal waves contained in the unit circle generated by a simple > >>>> recursive parametric function. I posted the code in a response to Jan, > >>>> who inspired me to create it in the first place: > >>>> > >>>> https://groups.google.com/d/msg/sci.math/uKj8GM0uRZU/Vk_LqPv8BAAJ > >>> > >>> 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. > >> > >> Simple as this. :-)) > > > > You'll also need to store the argument list every time. > > I do not want to blow up the stack: Yikes! ;^) That's exactly the reason you would do it the way I suggested. > > Fwiw, I think it can be accomplished without allocating anything. Just > adding an extra outer loop to take care of the single recursive call > should work out nicely. I will have more time after dinner. 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. > > > >> > >>> > >>>> > >>>>> > >>>>> > >>>>>> Smooth, montonic, unfortunately length > >>>>>> converges to length of straight line. > >>>>> > >>>>> can be done IMO: add a another sine function to that amplitude > >>>>> only grows in between the Elephant toes, not enough to break > >>>>> monotony, but strong enough to get arbitrary high arc length. > >>>>> > >>>>>> Good Night > >>>>> > >>>>> Sogni d'oro. > >>>>> > >>>>> > >>>>> > >>>> > >
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid> |
|---|---|
| Date | 2018-03-11 13:03 -0700 |
| Message-ID | <p8422l$sh5$1@dont-email.me> |
| In reply to | #407941 |
On 3/11/2018 7:02 AM, John Gabriel wrote:
> On Saturday, 10 March 2018 18:53:26 UTC-5, Chris M. Thomasson wrote:
>> On 3/10/2018 3:41 PM, John Gabriel wrote:
>>> On Saturday, 10 March 2018 18:40:18 UTC-5, John Gabriel wrote:
>>>> On Saturday, 10 March 2018 17:32:35 UTC-5, Chris M. Thomasson wrote:
>>>>> On 3/9/2018 12:00 AM, Chris M. Thomasson wrote:
>>>>>> On 3/8/2018 10:22 PM, Python wrote:
>>>>>>> bursejan@gmail.com wrote
>>>>>>>>
>>>>>>>> https://www.wolframalpha.com/input/?i=1+-+cos%28t%29,+1%2F4+%281+-+cos%282*t%29%29,+1%2F16+%281+-+cos%284*t%29%29,+1%2F64+%281+-+cos%288*t%29%29+from+0+to+2*pi
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> very nice!
>>>>>>
>>>>>> Fwiw, check out the following rendering:
>>>>>>
>>>>>> https://plus.google.com/101799841244447089430/posts/gp7F7sP5swj
>>>>>>
>>>>>> Fractal waves contained in the unit circle generated by a simple
>>>>>> recursive parametric function. I posted the code in a response to Jan,
>>>>>> who inspired me to create it in the first place:
>>>>>>
>>>>>> https://groups.google.com/d/msg/sci.math/uKj8GM0uRZU/Vk_LqPv8BAAJ
>>>>>
>>>>> 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.
>>>>
>>>> Simple as this. :-))
>>>
>>> You'll also need to store the argument list every time.
>>
>> I do not want to blow up the stack: Yikes! ;^)
>
> That's exactly the reason you would do it the way I suggested.
Agreed. Iteration is safer than recursion.
>> Fwiw, I think it can be accomplished without allocating anything. Just
>> adding an extra outer loop to take care of the single recursive call
>> should work out nicely. I will have more time after dinner.
>
> 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.
Well, I managed to get rid of the recursion. It was pretty easy, now
that I think about it. Here is the pure iterative function of my fractal
wave scheme:
___________________________________
// Fractal Parametric Wave Plotter
void ct_fwave_mpara(
ct::plot2d& plot,
unsigned int n,
ct_complex p0,
ct_complex p1,
unsigned int nr
) {
ct_complex dif = p1 - p0;
// Build the Fractal wave
ct_float abase = 1.0 / n;
ct_float abase_wave = CT_PI * 1 / n;
for (unsigned int i = 0; i < n; i++)
{
ct_float angle = abase * i;
ct_float angle_wave = abase_wave * i * nr;
ct_float y_temp = abs(sin(angle_wave)) * 1.0 / nr + (p0.imag()
+ (dif.imag() * angle));
// Fractal Wave High
ct_complex wp0 = {
p0.real() + (dif.real() * angle),
y_temp
};
// Fractal Wave Low
ct_complex wp1 = {
p0.real() + (dif.real() * angle),
-y_temp
};
plot.set_pixelf(wp0, CT_RGBF(1., 1., 0.));
plot.set_pixelf(wp1, CT_RGBF(0., 1., 1.));
}
}
// Fractal Parametric Wave Function
void ct_fwave(
ct::plot2d& plot,
unsigned int n,
ct_complex p0,
ct_complex p1,
unsigned int nr
) {
// For every level
for (unsigned int recur_i = 0; recur_i < n; ++recur_i)
{
// Plot the wave
ct_fwave_mpara(plot, 3072, p0, p1, nr);
// Compute next wave
nr = nr * (recur_i + 2);
}
}
___________________________________
I am hard coding the number of points plotted per wave via
ct_fwave_mpara for now. If we plot a small amount of points, say 10 or
20, well, we can join them with lines and create some interesting
structures.
The outer loop and the function that computes the next wave wrt the nr
variable in ct_fwave replaces the recursion.
Nice!
[...]
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid> |
|---|---|
| Date | 2018-03-11 13:21 -0700 |
| Message-ID | <p8434u$5bg$1@dont-email.me> |
| In reply to | #407956 |
On 3/11/2018 1:03 PM, Chris M. Thomasson wrote:
> On 3/11/2018 7:02 AM, John Gabriel wrote:
>> On Saturday, 10 March 2018 18:53:26 UTC-5, Chris M. Thomasson wrote:
>>> On 3/10/2018 3:41 PM, John Gabriel wrote:
>>>> On Saturday, 10 March 2018 18:40:18 UTC-5, John Gabriel wrote:
>>>>> On Saturday, 10 March 2018 17:32:35 UTC-5, Chris M. Thomasson wrote:
>>>>>> On 3/9/2018 12:00 AM, Chris M. Thomasson wrote:
>>>>>>> On 3/8/2018 10:22 PM, Python wrote:
>>>>>>>> bursejan@gmail.com wrote
>>>>>>>>>
>>>>>>>>> https://www.wolframalpha.com/input/?i=1+-+cos%28t%29,+1%2F4+%281+-+cos%282*t%29%29,+1%2F16+%281+-+cos%284*t%29%29,+1%2F64+%281+-+cos%288*t%29%29+from+0+to+2*pi
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> very nice!
>>>>>>>
>>>>>>> Fwiw, check out the following rendering:
>>>>>>>
>>>>>>> https://plus.google.com/101799841244447089430/posts/gp7F7sP5swj
>>>>>>>
>>>>>>> Fractal waves contained in the unit circle generated by a simple
>>>>>>> recursive parametric function. I posted the code in a response to
>>>>>>> Jan,
>>>>>>> who inspired me to create it in the first place:
>>>>>>>
>>>>>>> https://groups.google.com/d/msg/sci.math/uKj8GM0uRZU/Vk_LqPv8BAAJ
>>>>>>
>>>>>> 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.
>>>>>
>>>>> Simple as this. :-))
>>>>
>>>> You'll also need to store the argument list every time.
>>>
>>> I do not want to blow up the stack: Yikes! ;^)
>>
>> That's exactly the reason you would do it the way I suggested.
>
> Agreed. Iteration is safer than recursion.
>
>
>>> Fwiw, I think it can be accomplished without allocating anything. Just
>>> adding an extra outer loop to take care of the single recursive call
>>> should work out nicely. I will have more time after dinner.
>>
>> 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.
>
> Well, I managed to get rid of the recursion. It was pretty easy, now
> that I think about it. Here is the pure iterative function of my fractal
> wave scheme:
> ___________________________________
> // Fractal Parametric Wave Plotter
> void ct_fwave_mpara(
> ct::plot2d& plot,
> unsigned int n,
> ct_complex p0,
> ct_complex p1,
> unsigned int nr
> ) {
> ct_complex dif = p1 - p0;
>
> // Build the Fractal wave
> ct_float abase = 1.0 / n;
> ct_float abase_wave = CT_PI * 1 / n;
>
> for (unsigned int i = 0; i < n; i++)
> {
> ct_float angle = abase * i;
> ct_float angle_wave = abase_wave * i * nr;
> ct_float y_temp = abs(sin(angle_wave)) * 1.0 / nr + (p0.imag()
> + (dif.imag() * angle));
>
> // Fractal Wave High
> ct_complex wp0 = {
> p0.real() + (dif.real() * angle),
> y_temp
> };
>
> // Fractal Wave Low
> ct_complex wp1 = {
> p0.real() + (dif.real() * angle),
> -y_temp
> };
>
> plot.set_pixelf(wp0, CT_RGBF(1., 1., 0.));
> plot.set_pixelf(wp1, CT_RGBF(0., 1., 1.));
> }
> }
>
> // Fractal Parametric Wave Function
> void ct_fwave(
> ct::plot2d& plot,
> unsigned int n,
> ct_complex p0,
> ct_complex p1,
> unsigned int nr
> ) {
> // For every level
> for (unsigned int recur_i = 0; recur_i < n; ++recur_i)
> {
> // Plot the wave
> ct_fwave_mpara(plot, 3072, p0, p1, nr);
>
> // Compute next wave
> nr = nr * (recur_i + 2);
> }
> }
> ___________________________________
>
> I am hard coding the number of points plotted per wave via
> ct_fwave_mpara for now. If we plot a small amount of points, say 10 or
> 20, well, we can join them with lines and create some interesting
> structures.
>
>
> The outer loop and the function that computes the next wave wrt the nr
> variable in ct_fwave replaces the recursion.
>
> Nice!
>
> [...]
Fwiw, I posted an example rendering of a triangle wave form:
https://plus.google.com/101799841244447089430/posts/12cPLAM5cdc
Generated by the two functions ct_fwave_mpara and ct_fwave above.
[toc] | [prev] | [next] | [standalone]
| From | Python <python@python.invalid> |
|---|---|
| Date | 2018-03-12 17:54 +0100 |
| Message-ID | <5aa6b0c4$0$3296$426a74cc@news.free.fr> |
| In reply to | #407941 |
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 | bursejan@gmail.com |
|---|---|
| Date | 2018-03-12 10:07 -0700 |
| Message-ID | <ce262d8c-ec6c-47ab-84d3-6e2a94f6743d@googlegroups.com> |
| In reply to | #408056 |
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. 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 | bursejan@gmail.com |
|---|---|
| Date | 2018-03-12 10:12 -0700 |
| Message-ID | <f0b45b6f-f209-4907-b598-86889dd657cb@googlegroups.com> |
| In reply to | #408057 |
With CPU native stack which is the thread stack You dont get an OOM (out of memory) exception, but simply a SO (stack overflow) error, although there is still plenty of memory. Am Montag, 12. März 2018 18:07:21 UTC+1 schrieb burs...@gmail.com: > 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. > > 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]
Page 7 of 16 — ← Prev page 1 … 5 6 [7] 8 9 … 16 Next page →
Back to top | Article view | sci.math
csiph-web