Вышло издание 2,92 книги «Программирование: введение в профессию» А. В. Столярова

там достаточно понимать позиционную нотацию

которую вдалбливают в началке без требования к пониманию обходятся привитием навыка получать правильные ответы «механическим» столбиком :)

не подглядывая - почему нечётные длины требуют дополнительного чека?

Вы на нем не совершите тех ошибок, которые вы должны совершить, когда учитесь программировать.

Только в программировании учат ошибкам, а не тому, как их избежать.

ТП это модула

у Вирта реально не маркетинг

так что все его языки это «выдержанный» Algol-60 c ароматами той тары за 50 лет в которой созревала идея универсального императивного языка - апогеем которого стал «Active» Oberon - т.е Oberon (чьё определение 17 страниц в отличии от стандарта на поцкаль в 1к страниц) + та или иная модель конкуреннтности (зависит от реализации) - ибо сама классическая Среда Oberon тех врёмён когда прогресс не упёрса в на пальцах одной руки гигагерцы.

к Вышло издание 2,92 книги «Программирование: введение в профессию» А. В. Столярова (комментарий) ну тот же Вирт отказался во многих местах Oberon'а от повсеместного begin - который атавизм ещё из IPL-58 Algol 60

Для трёхзначных чисел: если 0 ≤ r < 101 и r % 10 = 0, то есть возможность, что r = 100, что всё портит.

там ещё +

div(т.е см где показали что просто цепочки модов не достаточно для нечётных длин тогда перед последним мод стоит сохранить и неполное частное для проверки что оно меньше базы нотации позиционной)

вопрос почему так ? :)

вот какому Паскалю стоит учить и какой Паскаль стоит форсит автору того ролика

https://wiki.oberon.org/ob/docu

а по факту Автор собирает урожай с того факта что до сих пор много где Паскаль(Тупо и Бормо) жив в мозгах училок и прочих хозы которым не пилятся новые бюджеты поэтому посконо имеющееся (нищиту за добродетель)

Не совсем понял вопрос. Вроде бы пример трёхзначных чисел это поясняет: r = 100 это как раз случай, когда неполное частное (r / 10) равно базе (10). В таком случае число заведомо не палиндром, но как раз эта проверка и нужна.

там была @теорема@ :

Вышло издание 2,92 книги «Программирование: введение в профессию» А. В. Столярова (комментарий)

её опровержение : Вышло издание 2,92 книги «Программирование: введение в профессию» А. В. Столярова

и воскрешение для нечётных Вышло издание 2,92 книги «Программирование: введение в профессию» А. В. Столярова (комментарий)

Вопрос - почему достаточно( и как вылезает необходимость для нечётных длин) проверка на размер последнего неполного частного - т.е почему на чётных длинах последнее неполное частное (ну если считать что мы получаем дерево через ряд divmod где неполные частные нам не особо интересны кроме случая терминального на нечётной длине) всегда меньше базы

Но с точки зрения того, чтобы научиться программированию, Python недостаточно.

Да, поэтому следом за ним должен идти си.

Pascal гораздо лучше, потому что его разработал Николас Вирт, человек, который прямо в обучении программирования очень много чего понимал

Пошло-поехало.

Ничего нового я тут не вижу. Ложные аналогии и использование устоявшихся в СНГ практик.

Ты на него именно что глядишь.

Менее очевиден, чем сравнение цифр.

Нет.

Он на самом деле тоже тривиален, и не требует упомянутой теоремы об остатках.

Требует комментария.

от которой начинает болеть голова

Очевидно, организм отторгает несвойственную для тебя деятельность. Программирование - не твоё, не надо себя мучить, займись чем-нить другим.

психуешь от злости

Да, не твоё. Программисты не «психуют».

задаёшь 1000 вопросов клоду,

Общаться с бредогенераторами это вообще 🤦.

там была @теорема@

А, ну я просто её не читал, и вывел доказательство самостоятельно. Могу расписать, но не хочу спойлерить Xenius решение (он ещё не ответил на мой вопрос).

Вопрос - почему достаточно( и как вылезает необходимость для нечётных длин) проверка на размер последнего неполного частного

На примере четырёхзначных чисел: 110 * 10 = 1100 ≥ 1001, и потому не может быть остатком от деления на 1001. Так что результат деления на 110 не больше девяти.
То же рассуждение обобщается на все случаи кроме случаев вида 10, 100, и так далее. Это как раз последний шаг у чисел нечётной длины.

Нет.

В качестве упражнения, я предлагаю тебе формально доказать корректность каждого из алгоритмов, и затем сравнить доказательства. Понятно, что свой код кажется проще, но длина доказательства это объективная метрика, в отличие от «я так вижу».

abs нельзя, есть риск устроить переполнение при вычитании.

как чуть выше пояснено

нет ибо проблема у нечётных чисто от того что последний делитель чистая степень базы - если смесь то частное всегда меньше базы

Что сохранил то и напечатает - побайтово. А всякие кодировки это уже проблемы редактора и консоли, а никак не языка программирования.

Код норм по сравнению с вариантом Xenius, но мусорные {} и целых 4 лишние строки.

мысль ваще что код это данные ( и даже без необходимости самомодификации)

т.е при наличие функции sign и индексов всякий if ( и изначальный трёхпутный фортрана )

это call

[proc_1,proc0,proc1][sign(SomeExpretion)]  # что то на псевдо коде почти Python

Это не «закидоны», это основы составления алгоритмов. Надо с самого начала показывать именно их, а не «декларативно» обрезанный код, иначе плохому научишь и это будет сложно исправить потом.

Не надо учить плохим стратегиям, даже временно, иначе их запомнят и потом будут применять в проде. Вообще, раньше программирование начинали с блок-схем, и так вот, на блок-схеме (где в одном узле только одно сравнение) странность твоего кода стала бы очевидной и до реализации на языке программирования бы не дожила вообще.

при правильном обучении стоит синхроно(и даже чуть раньше чем seq/if/loop - хотя по мне лучше seq/def/call/вычислимый_call) ознакамливать с концепцией хранимой и модифицируемой памяти и из этого переменных тогда через модификацию состояние более внятный подход формируется

как одно путевой конвеер с модификацией по ходу

чем дерево конвееров с выполнением всего действия на терминальных состояниях

т.е. лулз что синтаксическая хохлома проверок для первоначальной классификации для однократного применения это атавизм из «патерн-мэтчинга» когда сначала классифицируй потом действуй

а ряд модификаций состояния это более программисткий подход

По-моему у тебя браузер глючит - не учитывает кодировку сайтов при копировании между вкладками. Программирование тут ни при чём. Кстати, в фф весьма давно сломали нормальный выбор кодировки, и частично сломали её определение, это очень плохо с их стороны.

Никак нет, лучше начать с выбора другого рода занятий. Если ему не 5 или меньше лет, конечно.

Могу расписать, но не хочу спойлерить Xenius решение (он ещё не ответил на мой вопрос).

По-моему я и так всё доказал. Чтобы число делилось на 110, оно должно делиться и на 11 и на 10, а остаток от деления четырёхзначного на 1001 не будет делиться на 10, если первая и последняя цифра не одинаковые, так как нахождение остатка можно представить как последовательное вычитание 1001. Если первая цифра меньше, то она исчерпается раньше, в конце что-то останется, если она больше, то в конце получится ноль, но вычитание будет повторяться пока первая цифра не обнулится и в последней будет опять не ноль. Значит mod 1001 сбривает первую и последнюю цифру тогда и только тогда, когда они равны. А дальше mod 110 сравнивает две оставшиеся цифры.

С пятизначным числом будет (n>=10000) and (n<100000) and (n mod 10001 mod 1010 = 0) и вроде тогда выловятся только палиндромы.

тогда вопрос

можно ли так разбить ряд 1(единиц) длины изучаемых палиндромов (для чётных достаточно ряда пар -но может есть меньшее количество подходящих делителей?) на группы позиций возможно различных количеств что бы последовательным примененим mod к остаткам всегда иметь нулевой для палиндомов и иное для не.

ну и минимизировать размеры таких наборов - т.е обойтись наименьшим количеством mod

выше чисто пример что можно для длины 2n достаточно n пар Для 4 это 41 и 23 в позициях для 2 это 12 для 6 это 61 25 34

можно ли обойтись меньшим набором - например для 6 (чисто для пояснения это не подходящий набор) 631 и 542 т.е. 100101 и 11010

Круто, ещё задачка. Но её мне решать уже лень.

а вдруг Перельмано?

По-моему у тебя браузер глючит - не учитывает кодировку сайтов при копировании между вкладками. Программирование тут ни при чём. Кстати, в фф весьма давно сломали нормальный выбор кодировки, и частично сломали её определение, это очень плохо с их стороны.

Я скопировал из консоли, там же видно. Там специально cat без iconv чтобы показать, что кириллица в коде — зло.

Не надо учить плохим стратегиям, даже временно, иначе их запомнят и потом будут применять в проде.

Не знаю. Я вон в статейке понял, что подход тормозной, но не стал сразу исправлять намеренно, чтобы проверить, насколько он тормозной.

Почему нет? Не у всех мания обновляторства, и если проект писался под данный компилятор то лучше его им и компилировать, чем тратить потенциально кучу времени на отлов багов после переезда.

Ну VLA то и правда муть. Если так уж хочется переменный массив в стеке разместить - можно alloca использовать, более алгоритмически прозрачное, и с возможностью проверить «длину массива» на корректность перед тем как вслепую его аллоцировать.

На это есть разные причины. Основная — так исторически сложилось.

Нет. Основная и единственная - что иначе вместо страницы формул у тебя будет 10 страниц формул, которые во всех отношениях сложнее в поддержке.

UINT64_MAX * 10

Что-то у меня подозрение что тут будет арифметическое переполнение, а в переменную с тайпкастом до 128 бит запишется уже обрезанное ранее до 64 бит значение.

Не нужно пытаться натянуть сову на глобус.

Там комментарий будет в 5-10 раз длиннее формулы. Формула, конечно, не очевидна прямо сразу, но если чуть подумать (отвлечься от серьёзной математики и рассмотреть её с позиций начальной школы) то как раз всё становится понятно.

Я принципиальлно ставлю лишние {}, чтобы исключить возможность дописать еще одну строку, которая по ошибке не войдет в условие, и минимизировать размер диффов при следующих изменениях. Это уже привычка.

Я скопировал из консоли, там же видно. Там специально cat без iconv чтобы показать, что кириллица в коде — зло.

Ну значит не браузер а комбинация браузера+эмулятора терминала (не знаю кто там должен отвечать за сопоставление кодировок, но обе проги точно знают какая у них сейчас выбрана).

Это если код на отдельной строке, а если вся строка одна if(...) ...; то ещё одну строку некуда дописывать. Учитывая что тут всё максимально короткое, делить на 2 строки странно.

Ну разве что для диффов понятно, но по мне так неоправданная плата за такое. Хотя с другой стороны этот if на отдельной строке съест 1 строку контекста диффа, что в некоторых случаях может привести к двусмысленному патчу (когда его можно применить в разным местам кода, если номера строк сдвинулись).

Это всё справедливо, но это же не повод клеймить стандарт целиком.

Я в какой-то момент почти перестал однострочные конструкции с ифами писать - только прям в ооочень редких случаях для проверки кучи чего-то однотипного. Не вижу смысла экономить строчки, если честно.

не знаю кто там должен отвечать за сопоставление кодировок, но обе проги точно знают какая у них сейчас выбрана

В обоих UTF-8, зато файл в cp1251, неужели не понятно?

Достаточно просто камент со ссылкой на википедию оставить. Или вообще название теоремы - и всё.

Ну вот qulinxao3 так и сделал, только теорема об остатках у него почему-то крестьянская, а не китайская и к тому же к этому решению не относится.

Ну значит ты неправильно вывел файл в терминале. И файлы локализаций, даже если отдельные, точно так же могут оказаться в не той кодировке.

Ссылкой куда? Какая ещё теорема? Он тупо через остаток от деления убирает одинаковые цифры с двух концов. Это арифметика 2-3 класса школы.

С пятизначным числом будет (n>=10000) and (n<100000) and (n mod 10001 mod 1010 = 0) и вроде тогда выловятся только палиндромы.

Ага, только не все, ещё надо сделать mod 100, но тогда ловятся лишние. Вот так правильно:

Program palindrome_test;

Var
	i, j: longint;

Begin
	for i := 10000 to 99999 do begin
		j := i mod 10001 mod 1010;
		if (j<1000) and (j mod 100 = 0) then
			writeln(i)
	end
End.

Он тупо

всегда я

а можно ли для случая чётной длины большей 4 обойтись при длине 2n числом делителей меньшем n ?