Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > pl.comp.programming > #30172 > unrolled thread
| Started by | godek.maciek@gmail.com |
|---|---|
| First post | 2017-08-12 14:07 -0700 |
| Last post | 2017-09-03 08:40 -0700 |
| Articles | 20 on this page of 206 — 15 participants |
Back to article view | Back to pl.comp.programming
Co jest nie tak z C++ (było: Rust) godek.maciek@gmail.com - 2017-08-12 14:07 -0700
Re: Co jest nie tak z C++ (było: Rust) slawek <fake@fakeemail.com> - 2017-08-12 23:55 +0200
Re: Co jest nie tak z C++ (było: Rust) godek.maciek@gmail.com - 2017-08-12 15:43 -0700
Re: Co jest nie tak z C++ (było: Rust) slawek <fake@fakeemail.com> - 2017-08-13 07:04 +0200
Re: Co jest nie tak z C++ (było: Rust) "M.M." <mmarszik@gmail.com> - 2017-08-12 20:17 -0700
Re: Co jest nie tak z C++ (było: Rust) godek.maciek@gmail.com - 2017-08-12 22:44 -0700
Re: Co jest nie tak z C++ (było: Rust) "M.M." <mmarszik@gmail.com> - 2017-08-13 02:23 -0700
Re: Co jest nie tak z C++ (było: Rust) slawek <fake@fakeemail.com> - 2017-08-13 15:01 +0200
Re: Co jest nie tak z C++ (było: Rust) "M.M." <mmarszik@gmail.com> - 2017-08-13 07:16 -0700
Re: Co jest nie tak z C++ (było: Rust) w systemie siła 'POPIS/EU <NOSPAMtestowanije@go2.pl> - 2017-08-13 16:52 +0200
Re: Co jest nie tak z C++ (było: Rust) slawek <fake@fakeemail.com> - 2017-08-13 18:15 +0200
Re: Co jest nie tak z C++ (było: Rust) w systemie siła 'POPIS/EU <NOSPAMtestowanije@go2.pl> - 2017-08-13 18:44 +0200
Re: Co jest nie tak z C++ (było: Rust) slawek <fake@fakeemail.com> - 2017-08-13 20:32 +0200
Re: Co jest nie tak z C++ (było: Rust) w systemie siła 'POPIS/EU <NOSPAMtestowanije@go2.pl> - 2017-08-13 21:23 +0200
Re: Co jest nie tak z C++ (było: Rust) Wojciech Muła <wojtek.mula@gmail.com> - 2017-08-16 09:47 -0700
Re: Co jest nie tak z C++ (było: Rust) slawek <fake@fakeemail.com> - 2017-08-16 20:28 +0200
Re: Co jest nie tak z C++ (było: Rust) Mateusz Bogusz <mabakay@o2.pl> - 2017-08-16 20:35 +0200
Re: Co jest nie tak z C++ (było: Rust) slawek <fake@fakeemail.com> - 2017-08-16 22:21 +0200
Re: Co jest nie tak z C++ (było: Rust) Mateusz Bogusz <mabakay@o2.pl> - 2017-08-18 18:46 +0200
Re: Co jest nie tak z C++ (było: Rust) szykcech@gmail.com - 2017-08-21 13:15 -0700
Re: Co jest nie tak z C++ (było: Rust) godek.maciek@gmail.com - 2017-08-21 14:49 -0700
Re: Co jest nie tak z C++ (było: Rust) "AK" <nobody@nowhere.net> - 2017-08-22 01:03 +0200
Re: Co jest nie tak z C++ (było: Rust) "M.M." <mmarszik@gmail.com> - 2017-08-22 00:42 -0700
Re: Co jest nie tak z C++ (było: Rust) godek.maciek@gmail.com - 2017-08-22 01:21 -0700
Re: Co jest nie tak z C++ (było: Rust) Maciej Sobczak <see.my.homepage@gmail.com> - 2017-08-22 04:13 -0700
Re: Co jest nie tak z C++ (było: Rust) godek.maciek@gmail.com - 2017-08-22 05:24 -0700
Re: Co jest nie tak z C++ (było: Rust) Maciej Sobczak <see.my.homepage@gmail.com> - 2017-08-22 05:54 -0700
Re: Co jest nie tak z C++ (było: Rust) godek.maciek@gmail.com - 2017-08-22 06:12 -0700
Re: Co jest nie tak z C++ (było: Rust) Maciej Sobczak <see.my.homepage@gmail.com> - 2017-08-23 02:01 -0700
Re: Co jest nie tak z C++ (było: Rust) godek.maciek@gmail.com - 2017-08-23 02:29 -0700
Re: Co jest nie tak z C++ (było: Rust) Maciej Sobczak <see.my.homepage@gmail.com> - 2017-08-23 03:14 -0700
Re: Co jest nie tak z C++ (było: Rust) godek.maciek@gmail.com - 2017-08-23 04:42 -0700
Re: Co jest nie tak z C++ (było: Rust) Maciej Sobczak <see.my.homepage@gmail.com> - 2017-08-24 01:25 -0700
Re: Co jest nie tak z C++ (było: Rust) godek.maciek@gmail.com - 2017-08-24 02:38 -0700
Re: Co jest nie tak z C++ (było: Rust) "M.M." <mmarszik@gmail.com> - 2017-08-24 03:20 -0700
Re: Co jest nie tak z C++ (było: Rust) godek.maciek@gmail.com - 2017-08-24 04:02 -0700
Re: Co jest nie tak z C++ (było: Rust) fir <profesor.fir@gmail.com> - 2017-08-24 06:42 -0700
Re: Co jest nie tak z C++ (było: Rust) "M.M." <mmarszik@gmail.com> - 2017-08-24 08:32 -0700
Re: Co jest nie tak z C++ (było: Rust) fir <profesor.fir@gmail.com> - 2017-08-24 09:10 -0700
Re: Co jest nie tak z C++ (było: Rust) fir <profesor.fir@gmail.com> - 2017-08-24 12:24 -0700
Re: Co jest nie tak z C++ (było: Rust) "AK" <nobody@nowhere.net> - 2017-08-25 06:37 +0200
Re: Co jest nie tak z C++ (było: Rust) fir <profesor.fir@gmail.com> - 2017-08-25 01:13 -0700
Re: Co jest nie tak z C++ (było: Rust) godek.maciek@gmail.com - 2017-08-24 12:32 -0700
Re: Co jest nie tak z C++ (było: Rust) Adam M <amorawski@magna-power.com> - 2017-08-24 14:48 -0700
Re: Co jest nie tak z C++ (było: Rust) godek.maciek@gmail.com - 2017-08-24 15:23 -0700
Re: Co jest nie tak z C++ (było: Rust) Adam M <amorawski@magna-power.com> - 2017-08-25 07:04 -0700
Re: Co jest nie tak z C++ (było: Rust) godek.maciek@gmail.com - 2017-08-25 07:27 -0700
Re: Co jest nie tak z C++ (było: Rust) godek.maciek@gmail.com - 2017-08-25 07:40 -0700
Re: Co jest nie tak z C++ (było: Rust) slawek <fake@fakeemail.com> - 2017-08-25 20:04 +0200
Re: Co jest nie tak z C++ (było: Rust) Adam M <amorawski@magna-power.com> - 2017-08-25 11:57 -0700
Re: Co jest nie tak z C++ (było: Rust) slawek <fake@fakeemail.com> - 2017-08-25 22:52 +0200
Re: Co jest nie tak z C++ (było: Rust) "M.M." <mmarszik@gmail.com> - 2017-08-26 03:57 -0700
Re: Co jest nie tak z C++ (było: Rust) Adam M <amorawski@magna-power.com> - 2017-08-26 10:32 -0700
Re: Co jest nie tak z C++ (było: Rust) slawek <fake@fakeemail.com> - 2017-08-27 10:18 +0200
Re: Co jest nie tak z C++ (było: Rust) slawek <fake@fakeemail.com> - 2017-08-25 23:04 +0200
Re: Co jest nie tak z C++ (było: Rust) Wojciech Muła <wojtek.mula@gmail.com> - 2017-08-25 13:22 -0700
Re: Co jest nie tak z C++ (było: Rust) slawek <fake@fakeemail.com> - 2017-08-25 23:09 +0200
Re: Co jest nie tak z C++ (było: Rust) "AK" <nobody@nowhere.net> - 2017-08-25 07:08 +0200
Re: Co jest nie tak z C++ (było: Rust) "M.M." <mmarszik@gmail.com> - 2017-08-24 16:12 -0700
Re: Co jest nie tak z C++ (było: Rust) godek.maciek@gmail.com - 2017-08-25 02:35 -0700
Re: Co jest nie tak z C++ (było: Rust) fir <profesor.fir@gmail.com> - 2017-08-25 06:45 -0700
Re: Co jest nie tak z C++ (było: Rust) "AK" <nobody@nowhere.net> - 2017-08-25 18:01 +0200
Re: Co jest nie tak z C++ (było: Rust) "AK" <nobody@nowhere.net> - 2017-08-25 18:26 +0200
Re: Co jest nie tak z C++ (było: Rust) fir <profesor.fir@gmail.com> - 2017-08-26 03:12 -0700
Re: Co jest nie tak z C++ (było: Rust) "AK" <nobody@nowhere.net> - 2017-08-26 14:42 +0200
Re: Co jest nie tak z C++ (było: Rust) fir <profesor.fir@gmail.com> - 2017-08-26 06:07 -0700
Re: Co jest nie tak z C++ (było: Rust) "AK" <nobody@nowhere.net> - 2017-08-26 15:13 +0200
Re: Co jest nie tak z C++ (było: Rust) fir <profesor.fir@gmail.com> - 2017-08-26 06:40 -0700
Re: Co jest nie tak z C++ (było: Rust) "AK" <nobody@nowhere.net> - 2017-08-26 16:03 +0200
Re: Co jest nie tak z C++ (było: Rust) fir <profesor.fir@gmail.com> - 2017-08-26 08:44 -0700
Re: Co jest nie tak z C++ (było: Rust) "AK" <nobody@nowhere.net> - 2017-08-26 19:30 +0200
Re: Co jest nie tak z C++ (było: Rust) "M.M." <mmarszik@gmail.com> - 2017-08-26 00:18 -0700
Re: Co jest nie tak z C++ (było: Rust) "AK" <nobody@nowhere.net> - 2017-08-26 11:59 +0200
Re: Co jest nie tak z C++ (było: Rust) "M.M." <mmarszik@gmail.com> - 2017-08-26 04:20 -0700
Re: Co jest nie tak z C++ (było: Rust) "AK" <nobody@nowhere.net> - 2017-08-26 15:01 +0200
Re: Co jest nie tak z C++ (było: Rust) "M.M." <mmarszik@gmail.com> - 2017-08-26 13:29 -0700
Re: Co jest nie tak z C++ (było: Rust) "AK" <nobody@nowhere.net> - 2017-08-27 08:07 +0200
Re: Co jest nie tak z C++ (było: Rust) fir <profesor.fir@gmail.com> - 2017-08-27 01:53 -0700
Re: Co jest nie tak z C++ (było: Rust) "AK" <nobody@nowhere.net> - 2017-08-27 12:21 +0200
Re: Co jest nie tak z C++ (było: Rust) fir <profesor.fir@gmail.com> - 2017-08-27 04:47 -0700
Re: Co jest nie tak z C++ (było: Rust) fir <profesor.fir@gmail.com> - 2017-08-27 04:56 -0700
Re: Co jest nie tak z C++ (było: Rust) "M.M." <mmarszik@gmail.com> - 2017-08-27 04:53 -0700
Re: Co jest nie tak z C++ (było: Rust) fir <profesor.fir@gmail.com> - 2017-08-27 05:56 -0700
Re: Co jest nie tak z C++ (było: Rust) Adam M <amorawski@magna-power.com> - 2017-08-28 07:29 -0700
Re: Co jest nie tak z C++ (było: Rust) "M.M." <mmarszik@gmail.com> - 2017-08-28 08:29 -0700
Re: Co jest nie tak z C++ (było: Rust) Adam M <amorawski@magna-power.com> - 2017-08-28 08:49 -0700
Re: Co jest nie tak z C++ (było: Rust) "AK" <nobody@nowhere.net> - 2017-08-30 00:49 +0200
Re: Co jest nie tak z C++ (było: Rust) "M.M." <mmarszik@gmail.com> - 2017-08-29 23:00 -0700
Re: Co jest nie tak z C++ (było: Rust) Adam M <amorawski@magna-power.com> - 2017-08-30 06:35 -0700
Re: Co jest nie tak z C++ (było: Rust) "AK" <nobody@nowhere.net> - 2017-08-30 18:35 +0200
Re: Co jest nie tak z C++ (było: Rust) "AK" <nobody@nowhere.net> - 2017-08-30 18:38 +0200
Re: Co jest nie tak z C++ (było: Rust) slawek <fake@fakeemail.com> - 2017-08-30 10:46 +0200
Re: Co jest nie tak z C++ (było: Rust) "M.M." <mmarszik@gmail.com> - 2017-08-30 06:32 -0700
Re: Co jest nie tak z C++ (było: Rust) "AK" <nobody@nowhere.net> - 2017-08-30 18:46 +0200
Re: Co jest nie tak z C++ (było: Rust) "AK" <nobody@nowhere.net> - 2017-08-30 00:46 +0200
Re: Co jest nie tak z C++ (było: Rust) slawek <fake@fakeemail.com> - 2017-08-30 10:45 +0200
Re: Co jest nie tak z C++ (było: Rust) Szyk Cech <szyk100@o2.pl> - 2017-08-30 10:46 +0200
Re: Co jest nie tak z C++ (było: Rust) "AK" <nobody@nowhere.net> - 2017-08-30 18:40 +0200
Re: Co jest nie tak z C++ (było: Rust) Adam M <amorawski@magna-power.com> - 2017-08-30 07:09 -0700
Re: Co jest nie tak z C++ (było: Rust) slawek <fake@fakeemail.com> - 2017-08-30 16:30 +0200
Re: Co jest nie tak z C++ (było: Rust) Adam M <amorawski@magna-power.com> - 2017-08-30 07:42 -0700
Re: Co jest nie tak z C++ (było: Rust) slawek <fake@fakeemail.com> - 2017-08-30 16:53 +0200
Re: Co jest nie tak z C++ (było: Rust) slawek <fake@fakeemail.com> - 2017-08-30 17:02 +0200
Re: Co jest nie tak z C++ (było: Rust) Adam M <amorawski@magna-power.com> - 2017-08-30 08:12 -0700
Re: Co jest nie tak z C++ (było: Rust) "AK" <nobody@nowhere.net> - 2017-08-30 19:17 +0200
Re: Co jest nie tak z C++ (było: Rust) slawek <fake@fakeemail.com> - 2017-08-30 20:48 +0200
Re: Co jest nie tak z C++ (było: Rust) "AK" <nobody@nowhere.net> - 2017-08-30 19:12 +0200
Re: Co jest nie tak z C++ (było: Rust) "AK" <nobody@nowhere.net> - 2017-08-30 19:09 +0200
Re: Co jest nie tak z C++ (było: Rust) slawek <fake@fakeemail.com> - 2017-08-30 20:46 +0200
Re: Co jest nie tak z C++ (było: Rust) Adam M <amorawski@magna-power.com> - 2017-08-30 12:20 -0700
Re: Co jest nie tak z C++ (było: Rust) slawek <fake@fakeemail.com> - 2017-08-30 21:59 +0200
Re: Co jest nie tak z C++ (było: Rust) Wojciech Muła <wojtek.mula@gmail.com> - 2017-08-30 13:15 -0700
Re: Co jest nie tak z C++ (było: Rust) Adam M <amorawski@magna-power.com> - 2017-08-30 13:18 -0700
Re: Co jest nie tak z C++ (było: Rust) Adam M <amorawski@magna-power.com> - 2017-08-30 13:16 -0700
Re: Co jest nie tak z C++ (było: Rust) slawek <fake@fakeemail.com> - 2017-08-30 22:45 +0200
Re: Co jest nie tak z C++ (było: Rust) Adam M <amorawski@magna-power.com> - 2017-08-30 14:09 -0700
Re: Co jest nie tak z C++ (było: Rust) slawek <fake@fakeemail.com> - 2017-08-31 09:50 +0200
Re: Co jest nie tak z C++ (było: Rust) Maciej Sobczak <see.my.homepage@gmail.com> - 2017-08-31 01:52 -0700
Re: Co jest nie tak z C++ (było: Rust) Maciej Sobczak <see.my.homepage@gmail.com> - 2017-08-31 01:56 -0700
Re: Co jest nie tak z C++ (było: Rust) Adam M <amorawski@magna-power.com> - 2017-08-31 07:05 -0700
Re: Co jest nie tak z C++ (było: Rust) Maciej Sobczak <see.my.homepage@gmail.com> - 2017-08-31 09:28 -0700
Re: Co jest nie tak z C++ (było: Rust) slawek <fake@fakeemail.com> - 2017-08-31 19:35 +0200
Re: Co jest nie tak z C++ (było: Rust) Adam M <amorawski@magna-power.com> - 2017-08-31 11:09 -0700
Re: Co jest nie tak z C++ (było: Rust) Adam M <amorawski@magna-power.com> - 2017-08-31 10:54 -0700
Re: Co jest nie tak z C++ (było: Rust) "AK" <nobody@nowhere.net> - 2017-08-31 19:19 +0200
Re: Co jest nie tak z C++ (było: Rust) slawek <fake@fakeemail.com> - 2017-08-31 19:37 +0200
Re: Co jest nie tak z C++ (było: Rust) godek.maciek@gmail.com - 2017-08-29 07:03 -0700
Re: Co jest nie tak z C++ (było: Rust) godek.maciek@gmail.com - 2017-08-27 13:20 -0700
Re: Co jest nie tak z C++ (było: Rust) "M.M." <mmarszik@gmail.com> - 2017-08-28 09:39 -0700
Re: Co jest nie tak z C++ (było: Rust) godek.maciek@gmail.com - 2017-08-29 06:26 -0700
Re: Co jest nie tak z C++ (było: Rust) "M.M." <mmarszik@gmail.com> - 2017-08-29 08:32 -0700
Re: Co jest nie tak z C++ (było: Rust) slawek <fake@fakeemail.com> - 2017-08-29 18:46 +0200
Re: Co jest nie tak z C++ (było: Rust) "M.M." <mmarszik@gmail.com> - 2017-08-29 11:26 -0700
Re: Co jest nie tak z C++ (było: Rust) "AK" <nobody@nowhere.net> - 2017-08-25 06:29 +0200
Re: Co jest nie tak z C++ (było: Rust) "AK" <nobody@nowhere.net> - 2017-08-25 06:05 +0200
Re: Co jest nie tak z C++ (było: Rust) "AK" <nobody@nowhere.net> - 2017-08-25 06:08 +0200
Re: Co jest nie tak z C++ (było: Rust) godek.maciek@gmail.com - 2017-08-24 06:46 -0700
Re: Co jest nie tak z C++ (było: Rust) "AK" <nobody@nowhere.net> - 2017-08-25 06:14 +0200
Re: Co jest nie tak z C++ (było: Rust) Maciej Sobczak <see.my.homepage@gmail.com> - 2017-08-25 01:20 -0700
Re: Co jest nie tak z C++ (było: Rust) godek.maciek@gmail.com - 2018-01-01 15:18 -0800
Re: Co jest nie tak z C++ (było: Rust) Maciej Sobczak <see.my.homepage@gmail.com> - 2018-01-01 23:28 -0800
Re: Co jest nie tak z C++ (było: Rust) godek.maciek@gmail.com - 2018-01-02 01:45 -0800
Re: Co jest nie tak z C++ (było: Rust) Maciej Sobczak <see.my.homepage@gmail.com> - 2018-01-02 08:27 -0800
Re: Co jest nie tak z C++ (było: Rust) godek.maciek@gmail.com - 2018-01-02 12:27 -0800
Re: Co jest nie tak z C++ (było: Rust) Maciej Sobczak <see.my.homepage@gmail.com> - 2018-01-03 01:58 -0800
Re: Co jest nie tak z C++ (było: Rust) godek.maciek@gmail.com - 2018-01-03 03:24 -0800
Re: Co jest nie tak z C++ (było: Rust) slawek <fake@fakeemail.com> - 2018-01-03 14:17 +0100
Re: Co jest nie tak z C++ (było: Rust) Maciej Sobczak <see.my.homepage@gmail.com> - 2018-01-04 01:52 -0800
Re: Co jest nie tak z C++ (było: Rust) godek.maciek@gmail.com - 2018-01-04 03:08 -0800
Re: Co jest nie tak z C++ (było: Rust) Maciej Sobczak <see.my.homepage@gmail.com> - 2018-01-05 02:51 -0800
Re: Co jest nie tak z C++ (było: Rust) godek.maciek@gmail.com - 2018-01-05 05:09 -0800
Re: Co jest nie tak z C++ (było: Rust) Maciej Sobczak <see.my.homepage@gmail.com> - 2018-01-07 13:30 -0800
Re: Co jest nie tak z C++ (było: Rust) godek.maciek@gmail.com - 2018-01-07 14:00 -0800
Re: Co jest nie tak z C++ (było: Rust) Maciej Sobczak <see.my.homepage@gmail.com> - 2018-01-08 05:20 -0800
Re: Co jest nie tak z C++ (było: Rust) godek.maciek@gmail.com - 2018-01-08 11:25 -0800
Re: Co jest nie tak z C++ (było: Rust) Maciej Sobczak <see.my.homepage@gmail.com> - 2018-01-09 04:35 -0800
Re: Co jest nie tak z C++ (było: Rust) Roman Tyczka <noemail@because.no> - 2018-01-03 20:13 +0100
Re: Co jest nie tak z C++ (było: Rust) Maciej Sobczak <see.my.homepage@gmail.com> - 2018-01-04 01:36 -0800
Re: Co jest nie tak z C++ (było: Rust) Roman Tyczka <noemail@because.no> - 2018-01-05 22:57 +0100
Re: Co jest nie tak z C++ (było: Rust) Maciej Sobczak <see.my.homepage@gmail.com> - 2018-01-07 13:19 -0800
Re: Co jest nie tak z C++ (było: Rust) Tomasz Kaczanowski <kaczus@poczta.onet.pl> - 2018-01-02 14:32 +0100
Re: Co jest nie tak z C++ (było: Rust) "AK" <nobody@nowhere.net> - 2017-08-25 06:04 +0200
Re: Co jest nie tak z C++ (było: Rust) Maciej Sobczak <see.my.homepage@gmail.com> - 2017-08-25 00:45 -0700
Re: Co jest nie tak z C++ (było: Rust) slawek <fake@fakeemail.com> - 2017-08-25 12:54 +0200
Re: Co jest nie tak z C++ (było: Rust) "AK" <nobody@nowhere.net> - 2017-08-25 17:55 +0200
Re: Co jest nie tak z C++ (było: Rust) slawek <fake@fakeemail.com> - 2017-08-23 15:22 +0200
Re: Co jest nie tak z C++ (było: Rust) slawek <fake@fakeemail.com> - 2017-08-23 17:31 +0200
Re: Co jest nie tak z C++ (było: Rust) "AK" <nobody@nowhere.net> - 2017-08-23 22:33 +0200
Re: Co jest nie tak z C++ (było: Rust) godek.maciek@gmail.com - 2017-08-23 14:33 -0700
Re: Co jest nie tak z C++ (było: Rust) "AK" <nobody@nowhere.net> - 2017-08-24 00:14 +0200
Re: Co jest nie tak z C++ (było: Rust) godek.maciek@gmail.com - 2017-08-23 23:45 -0700
Re: Co jest nie tak z C++ (było: Rust) "AK" <nobody@nowhere.net> - 2017-08-25 06:06 +0200
Re: Co jest nie tak z C++ (było: Rust) slawek <fake@fakeemail.com> - 2017-08-25 12:39 +0200
Re: Co jest nie tak z C++ (było: Rust) slawek <fake@fakeemail.com> - 2017-08-23 15:24 +0200
Re: Co jest nie tak z C++ (było: Rust) godek.maciek@gmail.com - 2017-08-23 08:05 -0700
Re: Co jest nie tak z C++ (było: Rust) slawek <fake@fakeemail.com> - 2017-08-23 17:35 +0200
Re: Co jest nie tak z C++ (było: Rust) slawek <fake@fakeemail.com> - 2017-08-23 15:13 +0200
Re: Co jest nie tak z C++ (było: Rust) godek.maciek@gmail.com - 2017-08-23 08:18 -0700
Re: Co jest nie tak z C++ (było: Rust) slawek <fake@fakeemail.com> - 2017-08-23 17:38 +0200
Re: Co jest nie tak z C++ (było: Rust) "AK" <nobody@nowhere.net> - 2017-08-23 22:35 +0200
Re: Co jest nie tak z C++ (było: Rust) godek.maciek@gmail.com - 2017-08-24 01:06 -0700
[OT, SPAM] Re: Co jest nie tak z C++ (było: Rust) "AK" <nobody@nowhere.net> - 2017-08-25 06:07 +0200
Re: [OT, SPAM] Re: Co jest nie tak z C++ (było: Rust) godek.maciek@gmail.com - 2017-08-24 22:51 -0700
Re: [OT, SPAM] Re: Co jest nie tak z C++ (było: Rust) "AK" <nobody@nowhere.net> - 2017-08-25 17:41 +0200
Re: [OT, SPAM] Re: Co jest nie tak z C++ (było: Rust) godek.maciek@gmail.com - 2017-08-25 08:52 -0700
Re: Co jest nie tak z C++ (było: Rust) slawek <fake@fakeemail.com> - 2017-08-25 13:05 +0200
Re: Co jest nie tak z C++ (było: Rust) "AK" <nobody@nowhere.net> - 2017-08-25 18:00 +0200
Re: Co jest nie tak z C++ (było: Rust) Piotr Chamera <piotr_chamera@poczta.onet.pl> - 2017-08-23 18:15 +0200
Re: Co jest nie tak z C++ (było: Rust) "AK" <nobody@nowhere.net> - 2017-08-23 22:17 +0200
Re: Co jest nie tak z C++ (było: Rust) "AK" <nobody@nowhere.net> - 2017-08-23 22:11 +0200
Re: Co jest nie tak z C++ (było: Rust) Mateusz Bogusz <mabakay@o2.pl> - 2017-08-24 20:11 +0200
Re: Co jest nie tak z C++ (było: Rust) Maciej Sobczak <see.my.homepage@gmail.com> - 2017-08-25 00:42 -0700
Re: Co jest nie tak z C++ (było: Rust) Mateusz Bogusz <mabakay@o2.pl> - 2017-08-25 22:53 +0200
Re: Co jest nie tak z C++ (było: Rust) slawek <fake@fakeemail.com> - 2017-08-25 13:12 +0200
Re: Co jest nie tak z C++ (było: Rust) "M.M." <mmarszik@gmail.com> - 2017-08-22 04:49 -0700
Re: Co jest nie tak z C++ (było: Rust) godek.maciek@gmail.com - 2017-08-22 05:16 -0700
Re: Co jest nie tak z C++ (było: Rust) "AK" <nobody@nowhere.net> - 2017-08-23 22:02 +0200
Re: Co jest nie tak z C++ (było: Rust) slawek <fake@fakeemail.com> - 2017-08-25 12:35 +0200
Re: Co jest nie tak z C++ (było: Rust) "AK" <nobody@nowhere.net> - 2017-08-25 17:49 +0200
Re: Co jest nie tak z C++ (było: Rust) "AK" <nobody@nowhere.net> - 2017-08-25 18:54 +0200
Re: Co jest nie tak z C++ (było: Rust) slawek <fake@fakeemail.com> - 2017-08-25 20:20 +0200
Re: Co jest nie tak z C++ (było: Rust) "AK" <nobody@nowhere.net> - 2017-08-23 21:00 +0200
Re: Co jest nie tak z C++ (było: Rust) Wojciech Muła <wojtek.mula@gmail.com> - 2017-08-21 23:43 -0700
Re: Co jest nie tak z C++ (było: Rust) "AK" <nobody@nowhere.net> - 2017-08-23 20:52 +0200
Re: Co jest nie tak z C++ (było: Rust) Wojciech Muła <wojtek.mula@gmail.com> - 2017-09-03 01:15 -0700
Re: Co jest nie tak z C++ (było: Rust) "M.M." <mmarszik@gmail.com> - 2017-09-03 08:40 -0700
Page 8 of 11 — ← Prev page 1 … 6 7 [8] 9 10 11 Next page →
| From | Maciej Sobczak <see.my.homepage@gmail.com> |
|---|---|
| Date | 2018-01-01 23:28 -0800 |
| Message-ID | <e9a86571-3597-4add-9b8e-3f851e0bfa1d@googlegroups.com> |
| In reply to | #31340 |
> Mój przodek to albo mój rodzic, albo rodzic jakiegoś mojego przodka. > > Czy jest w tym coś trudnego do zrozumienia? Nic, oprócz może tego, że samo pojęcie przodka zdefiniowane w ten sposób jest mało użyteczne. W naturze liczba użytecznych przodków jest tak mała, że mieszczą się przy jednym (wigilijnym?) stole i całkiem łatwo można ich zdefiniować przez wyliczenie (tata Piotr, dziadek Zbigniew i pradziadek Eustachy), co nawet ułatwia codzienne interakcje - np. "Krzysiu, podaj pradziadkowi bigos, bo niedowidzi". Chyba nie sądzisz, że Krzysiu poda bigos najpierw tacie, tylko po to, żeby ten podał dziadkowi a ten dalej pradziadkowi (i skąd pradziadek będzie wiedział, że to dla niego)? > Czy dałoby się to jakoś łatwiej wyrazić w formie iteracyjnej? Oczywiście, zwłaszcza jeśli w dyskusji pojawia się pojęcie stopnia pokrewieństwa albo inne limity liczbowe, przy których sztuczna i potencjalna nieskończoność mechanizmu rekurencji jest tylko przeszkodą. Każ komuś wymienić potomków kogośtam w trzecim pokoleniu i zobacz, jak to zrobi. Rekurencja jest sztuczna i nienaturalna. Ani ludzie tak nie myślą ani komputery tak nie działają. No i żeby zrozumieć rekurencję, trzeba najpierw zrozumieć rekurencję... -- Maciej Sobczak * http://www.inspirel.com
[toc] | [prev] | [next] | [standalone]
| From | godek.maciek@gmail.com |
|---|---|
| Date | 2018-01-02 01:45 -0800 |
| Message-ID | <ec173ffd-c826-4f2c-961e-6c03fe3d1d7b@googlegroups.com> |
| In reply to | #31341 |
W dniu wtorek, 2 stycznia 2018 08:28:31 UTC+1 użytkownik Maciej Sobczak napisał: > > Mój przodek to albo mój rodzic, albo rodzic jakiegoś mojego przodka. > > > > Czy jest w tym coś trudnego do zrozumienia? > > Nic, oprócz może tego, że samo pojęcie przodka zdefiniowane w ten sposób jest mało użyteczne. To, czy coś jest użyteczne, czy nie jest, zależy od celu, który się przed sobą stawia. Podana przeze mnie definicja jest użyteczna do wyjaśnienia tego, w jaki sposób rozumiemy pojęcie przodka. Może też być użyteczna dla osób zajmujących się genealogią. Moje wyzwanie nie jest takie, żebyś wskazał różne obszary, w których pojęcie przodka nie jest użyteczne - bo takich obszarów jest wiele (np. ciesielstwo albo kowalstwo artystyczne), tylko takie, żebyś zdefiniował pojęcie przodka w sposób, który będzie równoważny powyższemu (tzn. będzie uchwytywało naszą intuicję odnośnie tego, co to znaczy być czyimś przodkiem), a który będzie nierekurencyjny. > > Czy dałoby się to jakoś łatwiej wyrazić w formie iteracyjnej? > > Oczywiście, zwłaszcza jeśli w dyskusji pojawia się pojęcie stopnia pokrewieństwa albo inne limity liczbowe, przy których sztuczna i potencjalna nieskończoność mechanizmu rekurencji jest tylko przeszkodą. Każ komuś wymienić potomków kogośtam w trzecim pokoleniu i zobacz, jak to zrobi. Pewnie to zależy od tego, z kim będę rozmawiał, i od okoliczności, w jakich będę to robił. > Rekurencja jest sztuczna i nienaturalna. Ani ludzie tak nie myślą ani komputery tak nie działają. No i żeby zrozumieć rekurencję, trzeba najpierw zrozumieć rekurencję... Rzecz w tym, że otóż właśnie ludzie tak myślą. Peano sformułował swoją aksjomatykę przed powstaniem komputerów. Wskazówka: Peano był człowiekiem. Spróbuj zaimplementować quicksorta albo mergesorta bez użycia rekurencji. Nawet szybką transformatę Fouriere'a dużo łatwiej zrozumieć w jej zapisie rekurencyjnym, który jest podstawą do konwersji do postaci iteracyjnej (której celem jest optymalizacja).
[toc] | [prev] | [next] | [standalone]
| From | Maciej Sobczak <see.my.homepage@gmail.com> |
|---|---|
| Date | 2018-01-02 08:27 -0800 |
| Message-ID | <7fa4184e-21f4-42ef-8e66-ea454ffe8cec@googlegroups.com> |
| In reply to | #31343 |
> Moje wyzwanie nie jest takie, żebyś wskazał różne obszary, w których > pojęcie przodka nie jest użyteczne - bo takich obszarów jest wiele > (np. ciesielstwo albo kowalstwo artystyczne), tylko takie, żebyś zdefiniował > pojęcie przodka w sposób, który będzie równoważny powyższemu (tzn. będzie > uchwytywało naszą intuicję odnośnie tego, co to znaczy być czyimś przodkiem), > a który będzie nierekurencyjny. Przodek to rodzic lub jego rodzic, itd. Słowo kluczowe "itd." pełni rolę pętli. Ta definicja jest iteracyjna, jest nawet gramatycznie krótsza i nie używa definiowanego słowa po prawej stronie, więc łatwiej się ją parsuje. Dla mnie OK. > Rzecz w tym, że otóż właśnie ludzie tak myślą. W takim razie to są jacyś inni ludzie, niż ci, którzy piszą definicje zawodowo: https://sjp.pwn.pl/slowniki/przodek.html Jest pewna wartość w tym, że po prawej stronie definicji nie ma definiowanego pojęcia. Myślę, że ta wartość przyświeca twórcom słowników. > Spróbuj zaimplementować quicksorta albo mergesorta bez użycia rekurencji. Tak, ja wiem, że rekurencja przydaje się do implementacji rekurencyjnych algorytmów. Sztuczne i nienaturalne narzędzie do rozwiązywania sztucznych i nienaturalnych problemów. :-) (Naturalnym mechanizmem sortowania są bąbelki, stąd właśnie ta nazwa.) > Nawet szybką transformatę Fouriere'a dużo łatwiej zrozumieć w jej zapisie > rekurencyjnym, Przy czym jest to szczególny przypadek transformaty Fouriera, która sama jest zdefiniowana wzorem wcale nie rekurencyjnym a związek szybkiej transformaty z ogólną wcale nie jest intuicyjny: https://pl.wikipedia.org/wiki/Szybka_transformacja_Fouriera Czyli znowu mamy ten sam schemat: rekurencja okazuje się być narzędziem do realizacji rekurencyjnych algorytmów, co wcale nie jest odkrywcze. Ciekawe by było dopiero stwierdzenie, że rekurencja jest procesem naturalnym a tak nie jest, ani w sortowaniu, ani nawet w transformacie Fouriera. -- Maciej Sobczak * http://www.inspirel.com
[toc] | [prev] | [next] | [standalone]
| From | godek.maciek@gmail.com |
|---|---|
| Date | 2018-01-02 12:27 -0800 |
| Message-ID | <710fa751-d1c0-4350-9949-6186f3ef0b72@googlegroups.com> |
| In reply to | #31347 |
W dniu wtorek, 2 stycznia 2018 17:27:52 UTC+1 użytkownik Maciej Sobczak napisał: > > Moje wyzwanie nie jest takie, żebyś wskazał różne obszary, w których > > pojęcie przodka nie jest użyteczne - bo takich obszarów jest wiele > > (np. ciesielstwo albo kowalstwo artystyczne), tylko takie, żebyś zdefiniował > > pojęcie przodka w sposób, który będzie równoważny powyższemu (tzn. będzie > > uchwytywało naszą intuicję odnośnie tego, co to znaczy być czyimś przodkiem), > > a który będzie nierekurencyjny. > > Przodek to rodzic lub jego rodzic, itd. > > Słowo kluczowe "itd." pełni rolę pętli. Ta definicja jest iteracyjna, jest nawet gramatycznie krótsza i nie używa definiowanego słowa po prawej stronie, więc łatwiej się ją parsuje. > Dla mnie OK. Jeżeli już, to raczej bym napisał to jako "przodek to rodzic, albo rodzic rodzica, albo rodzic rodzica rodzica, itd." (w Twojej definicji jest amfibolia) Ale OK, to jest dobra definicja, i użycie wielokropka czy też operatora generalizacji ma jak najbardziej sens. Mogę się nawet zgodzić, że tego rodzaju definicja jest łatwiejsza do zrozumienia, ale nie jest prostsza, ze względu na to, że samo działanie operatora "itd" jest czymś raczej skomplikowanym. Najwidoczniej mówimy tutaj o dwóch porządkach, bo kiedy ja mówię o prostocie, mam na myśli prostotę pojęciową, a nie łatwość rozumienia. > > Rzecz w tym, że otóż właśnie ludzie tak myślą. > > W takim razie to są jacyś inni ludzie, niż ci, którzy piszą definicje zawodowo: Podejrzewam, że to raczej zależy od zawodu i lokalnych idiosynkrazji. Ale tak, w ogólności ludzie różnią się między sobą. > > Spróbuj zaimplementować quicksorta albo mergesorta bez użycia rekurencji. > > Tak, ja wiem, że rekurencja przydaje się do implementacji rekurencyjnych algorytmów. Sztuczne i nienaturalne narzędzie do rozwiązywania sztucznych i nienaturalnych problemów. :-) > > (Naturalnym mechanizmem sortowania są bąbelki, stąd właśnie ta nazwa.) Jaka nazwa? Nazwa "sortować" wzięła się od łacińskiego słowa "sors", oznaczającego przeznaczenie albo wyrok, i nie ma nic wspólnego z bąbelkami. Nazwa "sortowanie bąbelkowe" wzięła się od pewnej metafory, zaś kwestia, czy metafory są, czy nie są czymś "naturalnym" jest zupełnie niejasna. > Czyli znowu mamy ten sam schemat: rekurencja okazuje się być narzędziem do realizacji rekurencyjnych algorytmów, co wcale nie jest odkrywcze. Ciekawe by było dopiero stwierdzenie, że rekurencja jest procesem naturalnym a tak nie jest, ani w sortowaniu, ani nawet w transformacie Fouriera. Nie do końca rozumiem, co masz na myśli mówiąc o "procesach naturalnych". Jeżeli mamy kurę, która składa jajko, z którego wykluwa się kura, która składa jajko, z którego wykluwa się ..., to czy to nie jest proces reKUREncyjny par excellence? Podobnie jest zresztą z opisem języków. Hierarcha Chomsky'ego zrodziła się przy okazji badań nad językami naturalnymi, i pewne cechy języków uniwersalnych -- zarówno mówionych, jak i tych używanych do programowania, znajdują najprostszy wyraz w opisie rekurencyjnym. Praktycznie wszystkie języki programowania opisuje się rekurencyjnie przy pomocy BNF. Taki opis jest zrozumiały, i nie wydaje się, żebyśmy dysponowali do tego celu jakimś lepszym narzędziem. Nie rozumiem Twojego argumentu odnośnie tego, czy "rekurencja jest procesem naturalnym", i co to w ogóle wg. Ciebie znaczy "proces naturalny", i ogólniej - czym jest "naturalność".
[toc] | [prev] | [next] | [standalone]
| From | Maciej Sobczak <see.my.homepage@gmail.com> |
|---|---|
| Date | 2018-01-03 01:58 -0800 |
| Message-ID | <1ebbf758-e3de-4a93-bdf1-5e836419e7df@googlegroups.com> |
| In reply to | #31349 |
> > (Naturalnym mechanizmem sortowania są bąbelki, stąd właśnie ta nazwa.) > > Jaka nazwa? https://stackoverflow.com/questions/31059479/why-bubble-sort-is-called-bubble-sort > Nazwa "sortowanie bąbelkowe" wzięła się od pewnej metafory, Z obserwacji natury. :-) > Nie do końca rozumiem, co masz na myśli mówiąc o "procesach naturalnych". Takich, które występują w naturze. Wliczamy w to procesy fizyczne, chemiczne, itp. > Jeżeli mamy kurę, która składa jajko, z którego wykluwa się kura, która > składa jajko, z którego wykluwa się ..., to czy to nie jest proces > reKUREncyjny par excellence? Ciekawy przykład, ale Słońce też wschodzi i zachodzi i znowu wschodzi. Deszcz pada, potem woda paruje a potem z tej pary robią się chmury i znowu pada. Itd. Jeśli coś się powtarza, to mówimy, że jest to cykl. Pojęcie rekurencji nie jest do tego potrzebne ani nie ułatwia rozumienia tych zjawisk. Z jakiegoś powodu wszystkie takie zjawisko omawia się w przedszkolach, na szczęście dla przedszkolaków bez rekurencji. > Podobnie jest zresztą z opisem języków. Ten przykład jest już ciekawszy. Możesz mnie przekonać, że nawet tak prostą rzecz jak wyrażenie arytmetyczne łatwiej opisać pozwalając na rekurencję. > Praktycznie wszystkie > języki programowania opisuje się rekurencyjnie przy pomocy BNF. Języki programowania nie są naturalne. A języków naturalnych nie opisuje się w BNF. I tu wracamy do starego argumentu. > Taki opis jest zrozumiały, i nie wydaje się, żebyśmy dysponowali > do tego celu jakimś lepszym narzędziem. W odniesieniu do wielu obecnych języków programowania, zgadzam się - i tam też stosuję rozwiązania rekurencyjne. -- Maciej Sobczak * http://www.inspirel.com
[toc] | [prev] | [next] | [standalone]
| From | godek.maciek@gmail.com |
|---|---|
| Date | 2018-01-03 03:24 -0800 |
| Message-ID | <0bfd0370-d45e-47d5-8645-c37316872ab6@googlegroups.com> |
| In reply to | #31350 |
W dniu środa, 3 stycznia 2018 10:58:12 UTC+1 użytkownik Maciej Sobczak napisał: > > Nie do końca rozumiem, co masz na myśli mówiąc o "procesach naturalnych". > > Takich, które występują w naturze. Wliczamy w to procesy fizyczne, chemiczne, itp. A procesy myślowe występują w naturze? Czy produkcja samochodów jest procesem występującym w naturze? I dlaczego to miałoby być istotne? > > Jeżeli mamy kurę, która składa jajko, z którego wykluwa się kura, która > > składa jajko, z którego wykluwa się ..., to czy to nie jest proces > > reKUREncyjny par excellence? > > Ciekawy przykład, ale Słońce też wschodzi i zachodzi i znowu wschodzi. Deszcz pada, potem woda paruje a potem z tej pary robią się chmury i znowu pada. Itd. Jeśli coś się powtarza, to mówimy, że jest to cykl. Pojęcie rekurencji nie jest do tego potrzebne ani nie ułatwia rozumienia tych zjawisk. Z jakiegoś powodu wszystkie takie zjawisko omawia się w przedszkolach, na szczęście dla przedszkolaków bez rekurencji. Jest zasadnicza różnica pomiędzy biologiczną reprodukcją, a obrotem słońca dookoła ziemi. Kura tworzy swoje (zmodyfikowane) kopie (co w świecie cybernetyki określane jest mianem "autopoiesis"), zaś Słońce cały czas jest jedno. Z jakiegoś powodu pytanie "co było pierwsze, kura czy jajko?" stanowi dla nas zagwozdkę, zaś pytanie "co było pierwsze, dzień czy noc?" już raczej nie. Zauważ również, że w samym tym pytaniu manifestuje się myślenie rekurencyjne, czyli potrzeba ustalenia przypadku bazowego (którym miałaby być kura albo jajko) i kroku (czyli znoszenie jajka albo wykluwanie się, w zależności od tego, na jakim etapie jesteśmy). > > Podobnie jest zresztą z opisem języków. > > Ten przykład jest już ciekawszy. Możesz mnie przekonać, że nawet tak prostą rzecz jak wyrażenie arytmetyczne łatwiej opisać pozwalając na rekurencję. > > > Praktycznie wszystkie > > języki programowania opisuje się rekurencyjnie przy pomocy BNF. > > Języki programowania nie są naturalne. A języków naturalnych nie opisuje się w BNF. I tu wracamy do starego argumentu. BNF jest wariantem gramatyki bezkontekstowej (typ 3 w hierarchii Chomsky'ego), i to stamtąd pochodzi. Choć Chomsky używał aparatury pojęciowej teorii informacji, motywacją do rozwinięcia jego teorii było opisywanie języków naturalnych właśnie. > > Taki opis jest zrozumiały, i nie wydaje się, żebyśmy dysponowali > > do tego celu jakimś lepszym narzędziem. > > W odniesieniu do wielu obecnych języków programowania, zgadzam się - i tam też stosuję rozwiązania rekurencyjne. Cieszę się.
[toc] | [prev] | [next] | [standalone]
| From | slawek <fake@fakeemail.com> |
|---|---|
| Date | 2018-01-03 14:17 +0100 |
| Message-ID | <almarsoft.5215126445876839177@news.v.pl> |
| In reply to | #31351 |
Rekurencja jest o jedno piętro abstrakcji wyżej niż interacja. Źle użyta może mieć złe skutki. Ale dobrze użyta jest ok. Np. trywializuje obliczanie wielomianów Czebyszewa. Lęk przed rekurencją to lęk przed abstrakcją. Z drugiej strony w wielu programach, zwłaszcza aplikacjach Windows, pojawia się w niekontrolowany sposób rekurencja pośrednia. Czyli a woła b, b woła c, ..., x woła a. To może być jakiś tercet update-invalidate-paint. Takiej rekurencji mówimy stanowcze nie.
[toc] | [prev] | [next] | [standalone]
| From | Maciej Sobczak <see.my.homepage@gmail.com> |
|---|---|
| Date | 2018-01-04 01:52 -0800 |
| Message-ID | <4c3831cd-7939-4220-ae28-d59af9ad7028@googlegroups.com> |
| In reply to | #31351 |
> A procesy myślowe występują w naturze? Występują. Ale na moje oko nie są rekurencyjne. Tu wkraczamy na śliski teren, bo nie możemy udowodnić, że wszyscy myślą tak samo. Jak się uprzesz, że myślisz rekurencyjnie, to nic na to nie poradzę. :-) > Czy produkcja samochodów jest procesem występującym w naturze? Tak. Raczej jest to proces iteracyjny. > I dlaczego to miałoby być istotne? Bo twierdzisz, że rekurencja jest *łatwiejsza* do zrozumienia. Łatwość czegokolwiek jest subiektywna, ale jeśli małbym ją jakoś obiektywizować, to właśnie przez odwołanie do natury. W sensie - jeśli jakieś zjawisko występuje w naturze, to czuję się zupełnie racjonalnie, jeśli rozumiem je lepiej, niż jakieś inne zjawisko, któro w naturze nie występuje. Niemniej, jeśli się uprzesz, że myślisz inaczej (w sensie - inaczej, niż natura chciała), to ja nie mam narzędzi, żeby dyskutować dalej. Będziemy musieli te nasze różnice po prostu zaakceptować. :-) > Jest zasadnicza różnica pomiędzy biologiczną reprodukcją, a obrotem > słońca dookoła ziemi. Ale deszcz jest z chmury, czy chmura z wody po deszczu? Co było wcześniej? Dla mnie to jest cykl a nie jakaś rekurencja. > Zauważ również, że w samym tym pytaniu manifestuje się > myślenie rekurencyjne, czyli potrzeba ustalenia przypadku bazowego Potrzeba ustalenia przypadku bazowego wynika tylko z tego, że rekurencja tego potrzebuje (czyli jest to sztuczna potrzeba, tak jak rekurencja jest sztucznym mechanizmem, wetkniętym tu na siłę). Natura wcale tego nie potrzebowała: https://en.wikipedia.org/wiki/Emergence Dla ludzi, którzy nie wpychają rekurencji wszędzie gdzie popadnie, nie jest to żadną niespodzianką. -- Maciej Sobczak * http://www.inspirel.com
[toc] | [prev] | [next] | [standalone]
| From | godek.maciek@gmail.com |
|---|---|
| Date | 2018-01-04 03:08 -0800 |
| Message-ID | <da54f929-57ed-4589-9ea8-34dfb4038d59@googlegroups.com> |
| In reply to | #31365 |
W dniu czwartek, 4 stycznia 2018 10:52:07 UTC+1 użytkownik Maciej Sobczak napisał: > > A procesy myślowe występują w naturze? > > Występują. Ale na moje oko nie są rekurencyjne. > Tu wkraczamy na śliski teren, bo nie możemy udowodnić, że wszyscy myślą tak samo. Jak się uprzesz, że myślisz rekurencyjnie, to nic na to nie poradzę. :-) Otóż to ;) > > Czy produkcja samochodów jest procesem występującym w naturze? > > Tak. Raczej jest to proces iteracyjny. A wymyślanie algorytmów występuje w naturze? :) > > I dlaczego to miałoby być istotne? > > Bo twierdzisz, że rekurencja jest *łatwiejsza* do zrozumienia. Rzeczywiście w tej kwestii wyraziłem się nieprecyzyjnie, ale nie powiedziałem, że rekurencja jest łatwiejsza do zrozumienia, tylko że jest prostsza do zrozumienia. Ale wycofałbym się z tego twierdzenia, bo ono jest niejasne. Raczej powiedziałbym, że rekurencja jest pojęciowo prostsza, albo bardziej pierwotna czy elementarna, niż iteracja. I mówiąc to, mam na myśli, że przy pomocy rekurencji można zdefiniować iterację, natomiast przy pomocy iteracji nie można zdefiniować rekurencji. I w tym sensie iteracja jest prostsza od rekurencji, że ma mniejszą siłę wyrazu (można przy jej pomocy zrobić mniej) Na marginesie, pozwoliłem sobie wczorajużyć Twojej definicji przodka w odpowiedzi na pytanie o funkcję "unfold": https://www.quora.com/Why-is-an-unfold-function-useful/answer/Panicz-Godek > Łatwość czegokolwiek jest subiektywna, Tak, łatwość jest subiektywna, ale prostota/złożoność nie jest. > ale jeśli małbym ją jakoś obiektywizować, to właśnie przez odwołanie do natury. W sensie - jeśli jakieś zjawisko występuje w naturze, to czuję się zupełnie racjonalnie, jeśli rozumiem je lepiej, niż jakieś inne zjawisko, któro w naturze nie występuje. Ja uważam, że jest dokładnie na odwrót. W naturze występuje wiele skomplikowanych zjawisk, które są niezgodne z intuicją. Na przykład splątanie kwantowe, określone przez Einsteina, Rosena i Podolsky'ego mianem "spooky action at a distance". W naturze w ogóle nie ma czegoś takiego, jak zależności liniowe, ale my je na siłę wpychamy do naszych analiz zjawisk naturalnych, bo w taki sposób łatwiej nam rozumieć świat: toteż mamy na przykład stałe przyspieszenie w polu grawitacyjnym Ziemi, albo siłę sprężystości sprężyny liniowo proporcjonalną do wychylenia od "położenia naturalnego", albo pojęcie "ruchu jednostajnego prostoliniowego". > Niemniej, jeśli się uprzesz, że myślisz inaczej (w sensie - inaczej, niż natura chciała), to ja nie mam narzędzi, żeby dyskutować dalej. Będziemy musieli te nasze różnice po prostu zaakceptować. :-) Moim zdaniem temat jest bardzo ciekawy, i wciąż ma duży potencjał do dyskusji. Wydaje mi się, że już z samym pojęciem natury jest pewien problem, mianowicie taki, że trudno by było wskazać część świata, która nie jest naturą. Z drugiej strony, czasem używa się go w tym celu, żeby odróżnić to, co zostało zrobione przez człowieka (które są "sztuczne") od pozostałych rzeczy (które są "naturalne"). Co więcej, nawet jeśli spojrzymy na język naturalny jako na wytwór naturalny, to definicja - jako próba uchwycenia intuicji stojącej za użyciem jakiegoś słowa - jest w jakimś sensie inherentnie sztuczna. W tym oczywiście zarówno definicja rekurencyjna, jak i iteracyjna. Na przykład, mówi się o takim czymś, jak "liczby naturalne", mając na myśli pewien konstrukt, który przychodzi ludziom do głowy w sposób naturalny. Aksjomatyka Peano mówi tyle, że - zero jest liczbą naturalną - następnik liczby naturalnej jest liczbą naturalną Pomijając kwestię tego, jak przełomowym osiągnięciem było wynalezienie zera, i tego, że moglibyśmy używać liczb zupełnie nie zastanawiając się nad tym, czym w istocie jest liczba, wydaje mi się, że trudno o prostsze wyjaśnienie tego, czym jest liczba. I nie mam tutaj na myśli łatwości, bo taka definicja rzeczywiście nie daje wskazówek odnośnie tego, dlaczego liczby są użyteczne (np. do tego, żebyśmy mogli wiedziec, ile mamy krów, albo czy obsiany areał wystarczy do tego, żeby wioska przetrwała zimę). Zresztą, czy pytanie, czym są dane rzeczy, nie jest dla człowieka naturalne? > > Jest zasadnicza różnica pomiędzy biologiczną reprodukcją, a obrotem > > słońca dookoła ziemi. > > Ale deszcz jest z chmury, czy chmura z wody po deszczu? Co było wcześniej? > Dla mnie to jest cykl a nie jakaś rekurencja. To tylko woda zmieniająca stan skupienia. Woda, cały czas ta sama. > > Zauważ również, że w samym tym pytaniu manifestuje się > > myślenie rekurencyjne, czyli potrzeba ustalenia przypadku bazowego > > Potrzeba ustalenia przypadku bazowego wynika tylko z tego, że rekurencja tego potrzebuje (czyli jest to sztuczna potrzeba, tak jak rekurencja jest sztucznym mechanizmem, wetkniętym tu na siłę). Natura wcale tego nie potrzebowała: Ja nie mówię o naturze, tylko o ludzkim myśleniu.
[toc] | [prev] | [next] | [standalone]
| From | Maciej Sobczak <see.my.homepage@gmail.com> |
|---|---|
| Date | 2018-01-05 02:51 -0800 |
| Message-ID | <f34ce238-a71a-4591-85bf-e4cd9929f302@googlegroups.com> |
| In reply to | #31366 |
> I mówiąc to, mam na myśli, że przy pomocy rekurencji można zdefiniować > iterację, natomiast przy pomocy iteracji nie można zdefiniować rekurencji. Tak. Rekurencja jest bardziej ogólnym mechanizmem w tym sensie, że uogólnia pojęcie powtórzenia. I to wcale nie sprawia, że jest łatwiejsza do zrozumienia. > I w tym sensie iteracja jest prostsza od rekurencji, że ma mniejszą > siłę wyrazu (można przy jej pomocy zrobić mniej) Zgadza się. Ale iteracja ma jedną gigantyczną zaletę: można przy pomocy iteracji zrobić iterację. I tam, gdzie potrzebna/wystarczajaca jest iteracja, wybór iteracji jako narzędzia jest bardziej właściwy - prostszy mechanizm, który potrafi mniej, jest wtedy łatwiejszy do zrozumienia. Bywa, że jest wtedy też bardziej wydajny. Dlatego używanie rekurencji do robienia iteracji jest przerostem formy, być często nawet zwykłym snobizmem. Analogia warsztatowa: zwykły młotek może zrobić mniej, niż kombajn ogólnego przeznaczenia func'o'matic. I dlatego do wielu zastosowań młotek będzie lepszym wyborem. A warsztat, który w ogóle nie ma młotka, jest po prostu nieużyteczny, nawet jeśli ma kombajn func'o'matic. Używajmy właściwych narzędzi do ich najbardziej naturalnych zastosowań, gdzie słowo "naturalne" zostawię już bez rozwinięcia, bo rozgrzebywanie takich definicji nie jest moją intencją na tej grupie. -- Maciej Sobczak * http://www.inspirel.com
[toc] | [prev] | [next] | [standalone]
| From | godek.maciek@gmail.com |
|---|---|
| Date | 2018-01-05 05:09 -0800 |
| Message-ID | <8cc632f9-2f2a-4b48-98b2-0dc2b9753554@googlegroups.com> |
| In reply to | #31378 |
W dniu piątek, 5 stycznia 2018 11:51:07 UTC+1 użytkownik Maciej Sobczak napisał:
> > I mówiąc to, mam na myśli, że przy pomocy rekurencji można zdefiniować
> > iterację, natomiast przy pomocy iteracji nie można zdefiniować rekurencji.
>
> Tak. Rekurencja jest bardziej ogólnym mechanizmem w tym sensie, że uogólnia pojęcie powtórzenia. I to wcale nie sprawia, że jest łatwiejsza do zrozumienia.
Nie sprawia. Ale nie sprawia też, że jest trudniejsza do zrozumienia.
Jak wspominałem w toku naszej dyskusji, są zagadnienia, których nie
potrafimy zrozumieć inaczej, niż rekurencyjnie.
> > I w tym sensie iteracja jest prostsza od rekurencji, że ma mniejszą
> > siłę wyrazu (można przy jej pomocy zrobić mniej)
>
> Zgadza się. Ale iteracja ma jedną gigantyczną zaletę: można przy pomocy iteracji zrobić iterację. I tam, gdzie potrzebna/wystarczajaca jest iteracja, wybór iteracji jako narzędzia jest bardziej właściwy - prostszy mechanizm, który potrafi mniej, jest wtedy łatwiejszy do zrozumienia. Bywa, że jest wtedy też bardziej wydajny. Dlatego używanie rekurencji do robienia iteracji jest przerostem formy, być często nawet zwykłym snobizmem.
Co do istoty, iteracja nie jest bardziej wydajna, niż rekurencja,
bo iteracja jest tylko specjalizacją rekurencji.
Dobrze jest to wyjasnione w "Strukturze i Interpretacji Programów
Komputerowych", gdzie odróżnia się rekurencyjne i iteracyjne procesy
obliczeniowe od rekurenyjnych i iteracyjnych definicji (środka wyrazu).
> Analogia warsztatowa: zwykły młotek może zrobić mniej, niż kombajn ogólnego przeznaczenia func'o'matic. I dlatego do wielu zastosowań młotek będzie lepszym wyborem. A warsztat, który w ogóle nie ma młotka, jest po prostu nieużyteczny, nawet jeśli ma kombajn func'o'matic.
Analogia jest o tyle nietrafna, że w przypadku dyskusji "rekurencja
vs. iteracja" mamy do czynienia nie tylko z aspektem możliwości, ale również
złożoności. Młotek może mniej niż kombain func'o'matic, ale młotek jest też
prostszy (mniej złożony) od takiego kombajnu.
Rekurencja natomiast zarówno może więcej (jest mniej wyspecjalizowana),
jak również jest prostsza (w sensie złożoności) od iteracji.
To jest istotne o tyle, że gdyby ktoś trzymał się dwóch zasad:
"stosuj najprostsze narzędzia dla osiągnięcia danego celu"
oraz
"do danego celu stosuj narzędzia wymagające jak najmniejszej mocy",
to te dwie raczej (wg. mnie) rozsądnie brzmiące maksymy mogą w wielu
sytuacjach stać ze sobą w sprzeczności.
Istotna wydaje się też kwestia przypadkowej złożoności.
W przypadku podanego przez Ciebie przykładu, zrozumienie zapisu x[[1 ;; ;; 2]]
wymaga odwołania do dokumentacji - składnia Mathematiki jest źródłem
przypadkowej złożoności, bo jej znaczenia nie da się wywnioskować
z "pierwszych zasad". W rozwiązaniu Kaya jedyna przypadkowa złożoność
jest w nazwach. Ale w tej kwestii z pomocą przychodzi nam dorobek
Burstalla, który rozszerzył ISWIM o pattern-matching, i teraz
np. w takim Haskellu zamiast
where odds(x) = if null(x) ∨ null(tl(x)) then x
else hd(x) & odds(ttl(x))
evens(x) = if null(x) ∨ null(tl(x)) then nil
else odds(tl(x))
napisalibyśmy raczej coś w stylu
where odds(o:e:xs) = o:odds(xs)
odds(xs) = xs
evens(o:xs) = odds(xs)
evens(xs) = []
W tym przypadku złożoność przypadkowa została praktycznie wyrugowana
do minimum: zasadniczo wszystko można wywnioskować z "pierwszych zasad"
> Używajmy właściwych narzędzi do ich najbardziej naturalnych zastosowań, gdzie słowo "naturalne" zostawię już bez rozwinięcia, bo rozgrzebywanie takich definicji nie jest moją intencją na tej grupie.
Myślę, że nikt tutaj nie będzie się spierał o to, żeby używać narzędzi
do ich najbardziej naturalnych zastosowań, i jedynym, o co można się
spierać, jest to jak należy rozumieć słowo "naturalne".
[toc] | [prev] | [next] | [standalone]
| From | Maciej Sobczak <see.my.homepage@gmail.com> |
|---|---|
| Date | 2018-01-07 13:30 -0800 |
| Message-ID | <1bae2f2d-dea7-474c-bb13-afa7e8757807@googlegroups.com> |
| In reply to | #31380 |
> Co do istoty, iteracja nie jest bardziej wydajna, niż rekurencja, > bo iteracja jest tylko specjalizacją rekurencji. Ale ja do ich uruchomienia używam nie "istoty", tylko procesora. A tam iteracja działa szybciej. > Dobrze jest to wyjasnione w "Strukturze i Interpretacji Programów > Komputerowych", A jeszcze lepiej w dokumentacji procesora. > Rekurencja natomiast zarówno może więcej (jest mniej wyspecjalizowana), > jak również jest prostsza (w sensie złożoności) od iteracji. Tego nie pokazałeś. Moja iteracyjna definicja przodka była prostsza od Twojej rekurencyjnej. Moja iteracyjna metoda wyboru elementów z listy też była prostsza. > W przypadku podanego przez Ciebie przykładu, zrozumienie zapisu x[[1 ;; ;; 2]] > wymaga odwołania do dokumentacji Tak. > W rozwiązaniu Kaya jedyna przypadkowa złożoność > jest w nazwach. Ale w tej kwestii z pomocą przychodzi nam dorobek > Burstalla, I teraz zrozumienie Twojego przykładu wymaga odwołania się do dorobku Burstalla. Nie przekonałeś mnie, że jest to prostsze. A mój zapis dalej jest krótszy. Co więcej, jeśli będę chciał mieć nie co drugi element, tylko co dziesiąty, to zmienię 2 na 10 i działa: x[[1;; ;;10]]. Złożoność tego zapisu się nie zmieniła. Co musisz zmienić w swoim przykładzie, żeby wybrać z listy co dziesiąty element? -- Maciej Sobczak * http://www.inspirel.com
[toc] | [prev] | [next] | [standalone]
| From | godek.maciek@gmail.com |
|---|---|
| Date | 2018-01-07 14:00 -0800 |
| Message-ID | <a056ef30-5c33-4d81-bfec-818e5058f9c0@googlegroups.com> |
| In reply to | #31385 |
W dniu niedziela, 7 stycznia 2018 22:30:41 UTC+1 użytkownik Maciej Sobczak napisał: > > Co do istoty, iteracja nie jest bardziej wydajna, niż rekurencja, > > bo iteracja jest tylko specjalizacją rekurencji. > > Ale ja do ich uruchomienia używam nie "istoty", tylko procesora. A tam iteracja działa szybciej. Mylisz się. Pewne strategie implementacji rekurencji działają wolniej (i zużywają więcej zasobów) od typowych strategii implementacji iteracji, i tyle. Istnieją strategie, pozwalające implementować rekurencję ogonową (czyli taką, która realizuje iterację) bez narzutu. > > Dobrze jest to wyjasnione w "Strukturze i Interpretacji Programów > > Komputerowych", > > A jeszcze lepiej w dokumentacji procesora. W dokumentacji procesora nie używa się takich pojęć, jak "proces obliczeniowy". > > Rekurencja natomiast zarówno może więcej (jest mniej wyspecjalizowana), > > jak również jest prostsza (w sensie złożoności) od iteracji. > > Tego nie pokazałeś. Nie pokazałem, ale mógłbym łatwo pokazać, definiując funkcję, której Ty użyłeś, za pomocą rekurencji. > Moja iteracyjna definicja przodka była prostsza od Twojej rekurencyjnej. W jaki sposób chciałbyś uzasadnić, że była prostsza? > Moja iteracyjna metoda wyboru elementów z listy też była prostsza. W jaki sposób chciałbyś uzasadnić, że była prostsza? > > W przypadku podanego przez Ciebie przykładu, zrozumienie zapisu x[[1 ;; ;; 2]] > > wymaga odwołania do dokumentacji > > Tak. > > > W rozwiązaniu Kaya jedyna przypadkowa złożoność > > jest w nazwach. Ale w tej kwestii z pomocą przychodzi nam dorobek > > Burstalla, > > I teraz zrozumienie Twojego przykładu wymaga odwołania się do dorobku Burstalla. Nie wymaga. > Nie przekonałeś mnie, że jest to prostsze. A mój zapis dalej jest krótszy. Co więcej, jeśli będę chciał mieć nie co drugi element, tylko co dziesiąty, to zmienię 2 na 10 i działa: x[[1;; ;;10]]. Złożoność tego zapisu się nie zmieniła. Co musisz zmienić w swoim przykładzie, żeby wybrać z listy co dziesiąty element? Pewnie musiałbym zmienić więcej. Co nie oznacza, że Twoje rozwiązanie jest prostsze, tylko to, że Twoje rozwiązanie można łatwiej dostosować do pewnej klasy zmian wymagań (z czym się zasadniczo zgadzam)
[toc] | [prev] | [next] | [standalone]
| From | Maciej Sobczak <see.my.homepage@gmail.com> |
|---|---|
| Date | 2018-01-08 05:20 -0800 |
| Message-ID | <d2715967-9a0e-420a-9806-197f03ea5a74@googlegroups.com> |
| In reply to | #31386 |
> Mylisz się. > Pewne strategie implementacji rekurencji działają wolniej > (i zużywają więcej zasobów) od typowych strategii implementacji > iteracji, i tyle. > Istnieją strategie, pozwalające implementować rekurencję > ogonową (czyli taką, która realizuje iterację) bez narzutu. Tak, jak kompilator zamieni rekurencję na iterację, to działa tak szybko, jak iteracja. Nie jest jednak prawdą, że bez narzutu, bo tym narzutem może być też większy koszt kompilacji i optymalizacji kodu. Bo co przepłacać? Natomiast iteracja zawsze działa tak szybko, jak iteracja. I zawsze jest tak tania, jak iteracja. > > Moja iteracyjna definicja przodka była prostsza od Twojej rekurencyjnej. > > W jaki sposób chciałbyś uzasadnić, że była prostsza? Już pisałem: mniej liter, krótsza gramatycznie, nie odwołuje się do definiowanego pojęcia. > > Moja iteracyjna metoda wyboru elementów z listy też była prostsza. > > W jaki sposób chciałbyś uzasadnić, że była prostsza? Ma mniej liter? Mniej razy się pomylę? Mniej bugów będę tam poprawiał? > > Co musisz zmienić w swoim przykładzie, żeby wybrać z listy co dziesiąty element? > > Pewnie musiałbym zmienić więcej. To zmień i pokaż. Bo szczerze mówiąc nie za bardzo mi się chce szarpać w nieskończoność o filozofię natury, istoty, prostoty, czy czego tam. Na razie niczego użytecznego w tej dyskusji nie ustaliliśmy. > Co nie oznacza, że Twoje rozwiązanie > jest prostsze, tylko to, że Twoje rozwiązanie można łatwiej dostosować > do pewnej klasy zmian wymagań (z czym się zasadniczo zgadzam) To też jest użyteczna miara prostoty. Jeśli coś można łatwiej do czegoś dostosować, to chyba dobrze, co? Po co przepłacać? Jeszcze raz, co dziesiąty z szeregu wystąp: x[[1;; ;;10]]. Pokaż wersję rekurencyjną i uzasadnij, że zawsze będzie to rekurencja ogonowa, bo przecież nie chcemy, żeby tak prosta rzecz działała wolniej, niż potrzeba. -- Maciej Sobczak * http://www.inspirel.com
[toc] | [prev] | [next] | [standalone]
| From | godek.maciek@gmail.com |
|---|---|
| Date | 2018-01-08 11:25 -0800 |
| Message-ID | <b148f2cc-9cc1-4cf7-b333-2b9d17ce5d74@googlegroups.com> |
| In reply to | #31387 |
W dniu poniedziałek, 8 stycznia 2018 14:21:00 UTC+1 użytkownik Maciej Sobczak napisał: > > Mylisz się. > > Pewne strategie implementacji rekurencji działają wolniej > > (i zużywają więcej zasobów) od typowych strategii implementacji > > iteracji, i tyle. > > Istnieją strategie, pozwalające implementować rekurencję > > ogonową (czyli taką, która realizuje iterację) bez narzutu. > > Tak, jak kompilator zamieni rekurencję na iterację, to działa tak szybko, jak iteracja. Nie jest jednak prawdą, że bez narzutu, bo tym narzutem może być też większy koszt kompilacji i optymalizacji kodu. Bo co przepłacać? Jest dokładnie odwrotnie. Jeżeli przyjmiesz strategię kompilacji polegającą na tym, że adres powrotu przekazujesz przez rejestr, a nie przez stos (i to kompilowana funkcja ma wiedzieć, czy wartość rejestru ma być odłożona na stosie), to nie dość, że masz mniej odwołań do pamięci i koszt wywołania funkcji Ci maleje, to optymalizację rekurencji ogonowej masz w zasadzie za darmo. Mówienie w tym kontekście o "wyższym koszcie kompilacji i optymalizacji kodu" jest pretensjonalne, zważywszy na to, jakich innych optymalizacji dokonują współczesne kompilatory. > Natomiast iteracja zawsze działa tak szybko, jak iteracja. I zawsze jest tak tania, jak iteracja. Nie ma czegoś takiego, jak "zawsze". Jeżeli w Pythonie 2.0 iterujesz po range(n), to w skład kosztu iteracji wchodzi zainicjalizowanie n komórek pamięci na wektor, sama iteracja plus odśmiecenie tej pamięci. > > > Moja iteracyjna definicja przodka była prostsza od Twojej rekurencyjnej. > > > > W jaki sposób chciałbyś uzasadnić, że była prostsza? > > Już pisałem: mniej liter, krótsza gramatycznie, nie odwołuje się do definiowanego pojęcia. Ale odwołuje się do frazy "i tak dalej", która - w przeciwieństwie do rekurencji - nie jest zrozumiała sama przez się. Tak samo jak x[[1 ;; ;; 10]] nie jest zrozumiałe samo przez się. > > > Moja iteracyjna metoda wyboru elementów z listy też była prostsza. > > > > W jaki sposób chciałbyś uzasadnić, że była prostsza? > > Ma mniej liter? Mniej razy się pomylę? Mniej bugów będę tam poprawiał? Jeżeli elementy są indeksowane od 0, to już się pomyliłeś i będziesz musiał poprawić buga. > > > Co musisz zmienić w swoim przykładzie, żeby wybrać z listy co dziesiąty element? > > > > Pewnie musiałbym zmienić więcej. > > To zmień i pokaż. Bo szczerze mówiąc nie za bardzo mi się chce szarpać w nieskończoność o filozofię natury, istoty, prostoty, czy czego tam. > Na razie niczego użytecznego w tej dyskusji nie ustaliliśmy. Jeżeli nie będziemy definiować używanych przez siebie pojęć, to raczej niczego użytecznego nie ustalimy. Jeżeli pod pojęciem prostoty będziemy rozumieć ilość znaków, to nagle okaże się, że programy w APLu są najprostsze, albo że Perl jest zasadniczo jakieś 30% prostszy od Pythona. > > Co nie oznacza, że Twoje rozwiązanie > > jest prostsze, tylko to, że Twoje rozwiązanie można łatwiej dostosować > > do pewnej klasy zmian wymagań (z czym się zasadniczo zgadzam) > > To też jest użyteczna miara prostoty. Jeśli coś można łatwiej do czegoś dostosować, to chyba dobrze, co? Po co przepłacać? Nikt nie mówi, że to źle. Ale to, że coś łatwo do czegoś dostosować, niekoniecznie jest miarą prostoty. Na przykład łatwo dostosować telewizor do tego, żeby wyświetlił jakiś obraz, niż namalować taki obraz na ścianie. A jednak ściana jest czymś prostszym, niż telewizor. > Jeszcze raz, co dziesiąty z szeregu wystąp: x[[1;; ;;10]]. > > Pokaż wersję rekurencyjną i uzasadnij, że zawsze będzie to rekurencja ogonowa, bo przecież nie chcemy, żeby tak prosta rzecz działała wolniej, niż potrzeba. Ja widzę, że zupełnie nie rozumiesz, o co mi chodzi. Jeżeli nie chcesz nawet spróbować zrozumieć, i będziesz się w kółko upierał z jakąś niezdefiniowaną naturalnością i prostotą rozumianą jako ilość znaków, to dalsza dyskusja raczej nie ma sensu.
[toc] | [prev] | [next] | [standalone]
| From | Maciej Sobczak <see.my.homepage@gmail.com> |
|---|---|
| Date | 2018-01-09 04:35 -0800 |
| Message-ID | <99d5db96-95ae-4a3a-8f44-3fd4fe563c0c@googlegroups.com> |
| In reply to | #31388 |
> > Jeszcze raz, co dziesiąty z szeregu wystąp: x[[1;; ;;10]]. > > Ja widzę, że zupełnie nie rozumiesz, o co mi chodzi. > Jeżeli nie chcesz nawet spróbować zrozumieć, i będziesz się > w kółko upierał z jakąś niezdefiniowaną naturalnością i prostotą > rozumianą jako ilość znaków, to dalsza dyskusja raczej nie ma sensu. Ale zapomniałeś pokazać swoją wersję, czy nie chciałeś jej pokazać? Dla mnie pojęcie prostoty w programowaniu jest użyteczne tylko w takim kontekście, w jakim pomaga mi podejmować decyzje projektowe i implementacyjne. Nie użyję rekurencji do tego zadania, bo iteracja jest... prostsza. A fakt, że wolałeś napisać kolejny nierozstrzygalny post na ileś zdań zamiast pokazać przykład kodu jest częścią miary prostoty tych rozwiązań. Proste jest coś, co można prosto użyć. x[[1;; ;;10]] -- Maciej Sobczak * http://www.inspirel.com
[toc] | [prev] | [next] | [standalone]
| From | Roman Tyczka <noemail@because.no> |
|---|---|
| Date | 2018-01-03 20:13 +0100 |
| Message-ID | <1u79aslzhdaug$.dlg@tyczka.com> |
| In reply to | #31350 |
On Wed, 3 Jan 2018 01:58:10 -0800 (PST), Maciej Sobczak wrote: >> Nazwa "sortowanie bąbelkowe" wzięła się od pewnej metafory, > > Z obserwacji natury. :-) > >> Nie do końca rozumiem, co masz na myśli mówiąc o "procesach naturalnych". > > Takich, które występują w naturze. Wliczamy w to procesy fizyczne, chemiczne, itp. > >> Jeżeli mamy kurę, która składa jajko, z którego wykluwa się kura, która >> składa jajko, z którego wykluwa się ..., to czy to nie jest proces >> reKUREncyjny par excellence? > > Ciekawy przykład, ale Słońce też wschodzi i zachodzi i znowu wschodzi. Deszcz pada, potem woda paruje a potem z tej pary robią się chmury i znowu pada. Itd. Jeśli coś się powtarza, to mówimy, że jest to cykl. Pojęcie rekurencji nie jest do tego potrzebne ani nie ułatwia rozumienia tych zjawisk. Z jakiegoś powodu wszystkie takie zjawisko omawia się w przedszkolach, na szczęście dla przedszkolaków bez rekurencji. A może weźmy pod uwagę fraktale? W naturze jest ich multum. Czy taki przykład jest ok? -- pozdrawiam Roman Tyczka
[toc] | [prev] | [next] | [standalone]
| From | Maciej Sobczak <see.my.homepage@gmail.com> |
|---|---|
| Date | 2018-01-04 01:36 -0800 |
| Message-ID | <98f60067-6840-4078-8b5f-e2f474896da8@googlegroups.com> |
| In reply to | #31357 |
> A może weźmy pod uwagę fraktale? W naturze jest ich multum. Czy taki > przykład jest ok? W naturze nie ma fraktali. Ani jednego. Istnieją struktury, które były inspiracją albo wywołują jakieś skojarzenia fraktalowe, np. liść paproci. Ale problem w tym, że te struktury powstają iteracyjnie, dzięki zupełnie lokalnym procesom komórkowym, które o naszych rekurencyjnych skojarzeniach nic nie wiedzą. Tu jest fajny przykład: https://en.wikipedia.org/wiki/Rule_90 Zjedź trochę niże do "Sierpiński triangle" i zobacz obrazek. Ten automat zdefiniowany jest banalną *lokalną* regułą na trzech sąsiednich komórkach jednowymiarowej tablicy, i rozwija się iteracyjnie, linia po linii (to kolejne wartości całej tablicy). Jednak w efekcie powstaje struktura, która *globalnie* kojarzy się nam z fraktalem. Trójkąt Sierpińskiego można oczywiście zrobić rekurencyjnie, ale rekurencja wcale nie jest potrzebna, żeby go zrobić. Podobnie jest z paprotkami. Właśnie dlatego upieram się, że iteracja jest procesem naturalnym. Bo w naturze nie ma mechanizmu, który by stworzył fraktal metodą rekurencyjną, natomiast lokalne procesy iteracyjne (np. przyrost kolejnych wartstw komórek w roślinach) jak najbardziej są. Rekurencja to nasz wymysł i propaganda. :-) -- Maciej Sobczak * http://www.inspirel.com
[toc] | [prev] | [next] | [standalone]
| From | Roman Tyczka <noemail@because.no> |
|---|---|
| Date | 2018-01-05 22:57 +0100 |
| Message-ID | <uds6iew2xdgk.dlg@tyczka.com> |
| In reply to | #31364 |
On Thu, 4 Jan 2018 01:36:35 -0800 (PST), Maciej Sobczak wrote: >> A może weźmy pod uwagę fraktale? W naturze jest ich multum. Czy taki >> przykład jest ok? > > W naturze nie ma fraktali. Ani jednego. https://ciekawe.org/2015/11/02/fraktalne-wzory-w-przyrodzie/ I to wszystko nie ma nic wspólnego z fraktalami? > Istnieją struktury, które były inspiracją albo wywołują jakieś > skojarzenia fraktalowe, np. liść paproci. Ale problem w tym, że te > struktury powstają iteracyjnie, dzięki zupełnie lokalnym procesom > komórkowym, które o naszych rekurencyjnych skojarzeniach nic nie wiedzą. Jak one powstają i co "wiedzą" to ja nie wiem, nie jestem botanikiem, a nawet myślę, że i botanicy nie wszystko jeszcze wiedzą. -- pozdrawiam Roman Tyczka
[toc] | [prev] | [next] | [standalone]
| From | Maciej Sobczak <see.my.homepage@gmail.com> |
|---|---|
| Date | 2018-01-07 13:19 -0800 |
| Message-ID | <82987c06-7230-4f2b-af54-1e44a5bf4f67@googlegroups.com> |
| In reply to | #31382 |
> > W naturze nie ma fraktali. Ani jednego. > > https://ciekawe.org/2015/11/02/fraktalne-wzory-w-przyrodzie/ > > I to wszystko nie ma nic wspólnego z fraktalami? Przypomniał mi się taki dowcip: Lekarz pokazuje pacjentowi jakiegoś kleksa na obrazku i pyta, co to jest. Pacjent mówi, że goła baba. Lekarz pokazuje kilka kolejnych kleksów a pacjent dalej zeznaje, że widzi gołe baby. Lekarz diagnozuje: panie, pan jesteś zboczony! A pacjent na to: ja? a kto mi tu ciągle gołe baby pokazuje? Polecam "New Kind Of Science" Wolframa albo od razu obrazki: https://www.google.pl/search?q=new+kind+of+science+images To jest książka o wielu różnych ciekawych rzeczach (zwłaszcza dla programistów), ale między innymi o tym, jak bardzo rekurencja nie jest potrzebna do zrobienia takich wzorów. Przykładowo, płatki śniegu, które były wspomniane w Twoim linku, nie rosną rekurencyjnie, tylko przez *nawarstwianie*. Ten proces nie ma w sobie ani grama rekurencji, bardziej przypomina ten wcześniejszy przykład z automatem tworzącym kolejne warstwy z tablicy a w wyniku coś, co nam się kojarzy z trójkątem Sierpińskiego. Może taki argument się przyda: fraktale są strukturami w przestrzeni ciągłej (co objawia się np. tym, że można je dowolnie powiększać). Takie nie są ani paprotka ani brokuł ani płatek śniegu. > myślę, że i botanicy nie wszystko jeszcze wiedzą. Za to my wiemy lepiej od nich, co? :-) -- Maciej Sobczak * http://www.inspirel.com
[toc] | [prev] | [next] | [standalone]
Page 8 of 11 — ← Prev page 1 … 6 7 [8] 9 10 11 Next page →
Back to top | Article view | pl.comp.programming
csiph-web