Дробная часть вещественного числа: функция FractionalPart

Пусть х — вещественное число. Тогда его дробную часть {х} можно определить равенством: {х} = х - [х]. По этому, общепринятому в математике определению дробная часть всегда неотрицательна и меньше единицы: 0<{х}<1. Однако в системе Mathematica используется несколько иное определение:

FractionalPart[х] = х - IntegerPart[х].

Поэтому FractionalPart [х] отрицательна для нецелых отрицательных х.

Чтобы освоиться с функцией FractionalPart, напишем программу, которая распечатывает результат применения функции FractionalPart к каждому элементу списка. Прежде всего нам понадобится определить функцию, которая оформляет вывод следующим образом.

FractionalPart[ х ]- результат применения функции FractionalPart к х

Вот как для этого можно определить функцию f.

f=(Print["FractionalPart[",#1,"]=",FractionalPart[#1]] &)

Теперь можем написать программу, в которой функция f применяется к каждому элементу списка.

f/@{x,2.4,0.3999999999999999',2.6,0.6000000000000001\-2.4,

 -0.3999999999999999",-2.6,Pi,10,-Рi^2,2*Sin[1],Ехр[Pi*Sqrt[163]]}

Вот результат

Давайте теперь вычислим

Неужели число

целое. Давайте повторим вычисления.

О, это уже какая-то загадка. Разные результаты при вычислении одного и того же выражения! А вот и разгадка: мы проводили вычисления с разной разрядностью, притом в обоих случаях точность была недостаточна. Давайте повторим вычисления с большей разрядностью.

Теперь мы видим, что

^-13! Между прочим, когда системы компьютерной алгебры не были столь доступны, как сейчас, число е^√163π доставляло немало хлопот не только студентам, но и многим вполне серьезным "дядям и тетям", недостаточно знакомым с признаками трансцендентности чисел. Некоторые шутники с вполне серьезным видом заявляли, что все говорит о том, что число е является целым, но никто этого пока не доказал, и что за доказательство обещана кругленькая сумма и т.д. А ведь чтобы прямым вычислением установить ложность этого высказывания, необходимо было провести вычисления более чем с 30 десятичными знаками! Даже вычислить его целую часть на машинах серии JBM/360 или БЭСМ-6 без ухищрений было невозможно! Конечно, на зарубежных машинах были доступны системы компьютерной алгебры, например MACSYMA на IBM/360. Однако на территории СССР доступ к таким системам имели весьма немногие. Кроме того, в советской системе образования следствием застойных явлений были ориентация на идеологические дисциплины (история КПСС, разнообразный марксизм и т.д.), отсутствие свободно выбираемых (студентом, а не деканатом!) курсов и сохранение подчиненной роли курса алгебры (всего три семестра) на уровне прошлого века. В советских университетах даже для студентов-математиков программой не было предусмотрено знакомство с современной алгеброй. О компьютерной алгебре не слышали и многие преподаватели. Поэтому на территории СССР вера в необходимость прямого вычисления с довольно большим количеством значащих цифр была не простым заблуждением обывателя, а подкреплялась советской системой образования. Поэтому именно те, кто был заинтересован в финансировании произвольноразрядной арифметики, и устраивали такие розыгрыши, предварительно тщательно выискивая потенциальных жертв. Фактически из отечественных машин для проверки гипотезы подходили только машины серии МИР. Но машина МИР-1, во входном языке (Алмир) которой была реализована произвольноразрядная арифметика, имела память объемом всего лишь 4 Кбайт, а машина МИР-2 — 8 Кбайт, причем быстродействие машины МИР-2 из-за частой сборки мусора падало подчас до 200 операций в секунду! Тем не менее благодаря встроенному языку Аналитик, в котором была реализована произвольноразрядная арифметика и элементы компьютерной алгебры, она справлялась с задачами, одна лишь постановка которых на БЭСМ-6 была весьма трудоемка, и потому очередь к этой машине стояла в десятки раз больше, чем за колбасой. А поскольку заранее никто не мог сказать, сколько времени потребуется на вычисление, спланировать его не представлялось возможным. Что же касается машины МИР-3 (особенно модели МИР-32), то фактически она была доступна только разработчикам, из числа которых и находились самые злостные шутники'! Кстати, в те годы системы компьютерной алгебры часто не могли определить, является ли заданное число алгебраическим. Начиная с версии 4 в системе Mathematica не составляет труда записать (и вычислить!) нужный предикат.

Ехр[  Pi*Sqrt[163]]sAlgebraics

False

Всякая история имеет мораль, и эта не исключение: вычисляя дробную часть, не забывайте указывать нужную разрядность и, кроме того, не упускайте из виду цель, ради которой вы проводите вычисления, — подумайте, нельзя ли достичь цели более простым способом. (Мы бы, например, могли сразу спросить систему Mathematica, является ли е^√163^πалгебраическим числом.) Не забывайте также о том, что подчас с помощью систем компьютерной алгебры удается разрешить вопрос, который остается открытым в течение длительного времени. Впрочем, иногда достаточно вспомнить всего лишь несколько теорем.

Упражнение 3.1. Вычислите не менее k десятичных цифр числа я, начиная с n-й после десятичной точки. Можете ли вы провести вычисления, например, для n = 100 000, k = 1000? Иными словами, можете ли вы вычислить сто первую тысячу (после запятой) знаков в представлении этого числа десятичной дробью?

Решение. Вот самое простое решение, которое обычно приходит в голову неискушенному читателю. Сначала нужно вычислить п с разрядностью, которая гарантирует n + k + 1 верную цифру, например n + k + 10, а затем в полученной дроби выбрать нужные десятичные знаки. Что касается вычисления я с разрядностью хотя бы 101001, то оно для системы Mathematica никакого труда не представляет. Но вот что касается отсчитать сто тысяч знаков после запятой... Впрочем, в системе Mathematica и для этого предусмотрены нужные функции! Но если немного поразмыслить, то окажется, что решить поставленную задачу можно с помощью функции FractionalPart, "Ну, я об этом сразу догадался!" — высокомерно воскликнет искушенный читатель. Действительно, чего же можно было еще ожидать, если этот раздел посвящен функции FractionalPart? Ну разве что каких-либо трудностей при составлении программы. Но ее составить как раз совсем нетрудно.

n=100000; k=1000; m= N[FractionalPart[10^ (n-1)*Pi],k+10]

Правда, ее нужно предварительно. проверить. Это совсем просто, достаточно уменьшить значения пик, затем провести вычисления

n=1;   k=5;   m= N[FractionalPart[10^(n-1)*Pi],k+10]

0.141592653589793

n=2;   k=5;   m= N[FractionalPart [10^(n-1)*Pi],k+10]

0.415926535897932

n=10;   k=5;   m= N[FractionalPart[10^(n-1)*Pi],k+10]

0.589793238462643

и сверить результаты с таблицами. Как легко убедиться, результаты совпадают, так что беспокоиться вроде бы не о чем. Но вот если положить n = 50, появляется предупреждение о недостаточной разрядности.

N::meprec: Internal precision limit $MaxExtraPrecision =50.

reached while evaluating -

31415926535897«21»841971693993751«1» «1» .

А при n = 1000 результат выглядит вообще странно: 0.х10³⁴, да и предупреждений целых два! Давайте разберемся, в чем тут дело. Для этого придется проанализировать ход вычислений. Сначала вычисляется Pi с некоторой точностью, притом с запасом (не более $MaxExtraPrecision десятичных знаков, как следует из предупреждения), а затем это число умножается на степень 10, так что в итоге получается 10^ (n-l) *Pi с некоторой точностью, после чего мы пытаемся взять у этого полученного числа его дробную часть. Но вот теперь и оказывается, что число было вычислено с недостаточной точностью, и система Mathematica предупреждает об этом! Впрочем, выход очевиден: нужно просто увеличить значение $MaxExtraPrecision. Но увеличение будет весьма значительным, и потому лучше всего сделать так, чтобы увеличенное значение $MaxExtraPrecision использовалось системой Mathematica только при вычислении результата, нужного для функции FractionalPart. Иными словами, увеличенное значение $MaxExtraPrecision нужно сделать локальным. Для этого достаточно воспользоваться функцией Block. Тогда можно написать следующую тестовую программу.

Do[Block[{k=10},Block[{$MaxExtraPrecision = n+k+10),

Print[n+1,":",N[FractionalPart[10^n*Рi],k+10]]]],{n,0,2030,5}]

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

1  : 0.14159265358979323846

6 : 0.26535897932384626434

11  0.89793238462643383280

16 0.23846264338327950288

21 0.26433832795028841972

26  0.83279502884197169399

31  0.50288419716939937511

36 0.41971693993751058210

Правильность цифр можно проверить по таблицам, имеющимся почти в любом солидном справочнике по математике или в какой-нибудь монографии, посвященной арифметике произвольной разрядности, например во втором томе бессмертного труда Дональда Кнута Искусство программирования. Что касается продолжения распечатки, то в ней правильность цифр проверить уже сложнее. Ведь найти книгу с более чем пятидесятые знаками л существенно сложнее. Из опыта знаю, что на территории СССР научному сотруднику, не связанному со спецслужбами вроде КГБ или ГРУ, получить доступ к серьезному фолианту по истории вычисления я практически было невозможно. Тем больше наша благодарность организатору первых математических олимпиад в Ленинграде (и СССР; первые олимпиады в Москве и Киеве проводились только через год) Василию Августовичу Кречмару, который в последних изданиях своего труда Задачник по алгебре (предназначенного для любознательных школьников!) поместил результат вычисления л с 2035 знаками после запятой. Разрабатывая арифметику произвольной разрядности для различных программных комплексов (в том числе и систем компьютерной алгебры), я при проверке получаемых результатов неоднократно пользовался шестым изданием этого бестселлера. Вполне подойдет эта книга и для проверки (хотя бы и выборочной) результатов, выдаваемых нашей программой. Так что можем читать нашу распечатку дальше.

41      0.69399375105820974945

46      0.37510582097494459231

51      0.58209749445923078164

56      0.74944592307816406286

61      0.59230781640628620900

66      0.78164062862089986280

71      0.062862089986280348253

76      0.20899862803482534212

81      0.86280348253421170680

86      0.34825342117067982148

91      0.34211706798214808651

96      0.70679821480865132823

101   :   0.82148086513282306647

106   :   0.086513282306647093845

Вы заметили, что распечатан один "лишний" знак? А знаете, почему? Продолжаем читать дальше.

111   :   0.32823066470938446096

 116   :   0.066470938446095505822

 121   :   0.093844609550582231725

И вот опять появились "лишние" знаки. Правда, и в этом случае после точки стоит сразу 0. Но не случайность ли это?

126   :   0.46095505822317253594

131   :   0.50582231725359408128

136   :   0.23172535940812848112

141   :   0.53594081284811174503

146   :   0.081284811174502841027

И вот опять появился "лишний" знак. И опять после точки стоит сразу 0. Да не закономерность ли это? Давайте пропустим часть распечатки и поищем еще "лишние" знаки (я выделяю их курсивом, знак после точки — полужирным).

286      0.60726024914127372459

291      0.024914127372458700661

296      0.41273724587006606316

301      0.72458700660631558817

306      0.70066063155881748815

311      0.063155881748815209210

316      0.58817488152092096283

356      0.90360011330530548820

361      0.011330530548820466521

366      0.053054882046652138415

371      0.48820466521384146952

416      0.91953092186117381933

421     0.092186117381932611793

426     0.61173819326117931051

О, действительно, это, должно быть, закономерность. Итак, мы полагаем, что если после точки идет нуль, то вычисляется дополнительная цифра. Ну а если нулей несколько? Может быть, количество ведущих нулей равно количеству "лишних" цифр?

Давайте попробуем подтвердить (или опровергнуть) эту гипотезу.

446       0.18548074462379962750

451       0.074462379962749567352

456       0.23799627495673518858

556       0.70277053921717629318

561       0.053921717629317675234

566       0.17176293176752384675

591       0.76694051320005681271

596       0.051320005681271452636

601       0.00056812714526356082773

606       0.81271452635608277858

741       0.47713099605187072113

746       0.099605187072113500000

751       0.51870721134999999837

776       0.49951059731732816096

781       0.059731732816096318595

786       0.17328160963185950245

851       0.71010003137838752887

856       0.0031378387528865875332

861       0.78387528865875332084

991       0.21642019893809525720

996       0.019893809525720106549

1041   0.82303019520353018530

1046   0.01952035301852968995S

1051   0.035301852968995773623

1111   0.45415069595082953312

1116   0.069595082953311686173

1121   0.50829533116861727856

1166   0.19255060400927701671

1171   0.060400927701671139010

 1176  0.092770167113900984882

 1181  0.016711390098488240129

1266   0.68471040475346462080

1271   0.040475346462080466843

 1276  0.53464620804668425907

1331   0.66024058038150193511

 1336  0.058038150193511253382

1386   0.92726042699227967824

1391   0.042699227967823547816

1516   0.75596023648066549912

1521   0.023648066549911988183

1551 0.63698074265425278626

1556 0.074265425278625518184

1601 0.81647060016145249192

1606 0.060016145249192173217

1756 0.67179049460165346680

1761 0.049460165346680498863

1766 0.01653466804988627232S

1831 0.95068006422512520512

1836 0.00642251252051173929S5

1856 0.84896084128488626946

1861 0.084128488626945604242

1896 0.11863067442786220392

1901 0.067442786220391949450

1916 0.94945047123713786961

1921 0.047123713786960956364

1966 0.41389086583264599581

1971 0.08658326459958133904S

2021 0.98352595709825822621

2026 0.59570982582262052249

2031 0.98258226205224894077

Итак, все говорит о том, что эта гипотеза верна! А знаете, почему? Потому что ведущие нули не учитываются при подсчете значащих цифр (а ведь именно их количество и равно разрядности). "Ну, это я знал с шестого класса, если не с пеленок. Давайте лучше решим задачу до конца, раз уж мы столь тщательно проверили предложенный мною вариант программы и убедились в его правильности!" — воскликнет иной искушенный читатель. Что же, не возражаю. Давайте зададим параметры и получим результат.

Полужирным здесь выделены искомая сто первая тысяча цифр в представлении числа к десятичной дробью, причем первая выделенная цифра является стотысячной после запятой. "Ну вот, и все дела. Я сразу говорил, что нужно применить функцию FractionalPart. А автор все сомневался, проверял тривиальную программу, сравнивал десятичные знаки с предварительно вычисленными значениями я, измышлял гипотезы... Да в этой программе Pi можно заменить любым числом, в конце концов, я такие программы пишу с пеленок!" — возмутится тут искушенный читатель. Ой, не торопитесь делать такие выводы. В математике (и в программировании, и в компьютерной алгебре) есть великие идеи, но нет мелочей. А что касается вещественных чисел, то они свои ловушки расставляют не только на страницах учебников по теории функций вещественного переменного (чтобы изловить ленивых студентов), но и в вполне респектабельных программах (чтобы в эти ловушки на сей раз угодили "искушенные" читатели и нерадивые пользователи). Вспомните, что мы в ходе проверки подтвердили гипотезу о том, что количество ведущих нулей равно количеству "лишних" цифр. Но ведь мы заранее не знаем, сколько ведущих нулей может встретиться при вычислении дробной части FractionalPart [10^n*Pi], так что заранее ручаться за правильный выбор разрядности мы не могли! Нам просто повезло, что выбранное значение разрядности обеспечило нужную точность! В принципе заранее неизвестно, работает ли наша программа для всех натуральных значений n и k. Указанного нами значения $MaxExtraPrecision = n+k+10 может ведь и не хватить для вычисления k+10 значащих цифр дробной части, если она будет начинаться более, чем с десяти нулей! Если бы в десятичном приближении я встречались сколь угодно длинные последовательности нулей, то для каждого k нашлось бы такое n, что программа с задачей не справилась бы! К счастью для "искушенного" читателя в настоящий момент это неизвестно. Зато даже шестиклассник (во всяком случае, участник районных математических олимпиад) без труда может придумать примеры вещественных чисел, для которых эта программа и ей подобные не работают. Нужно просто выбрать число, в десятичной записи которого встречаются все более длинные последовательности нулей. В качестве примера подойдет число 0.1234567891011121314151617181920..., в котором после десятичной точки выписаны последовательно все натуральные числа. Есть, конечно, и более экзотические примеры, что-нибудь вроде

Десятичная запись этого числа содержит только нули и единицы, причем и тех, и других там бесконечно много, но единицы встречаются столь редко, что если наудачу выберешь какую-нибудь цифру, почти наверняка попадешь на последовательность нулей. Так что слухи о том, что придуманная нами программа при тривиальных модификациях может быть применена к любому вещественному числу, были несколько преувеличены...

Да, а как же все-таки решить задачу? Ну, в данном случае это совсем несложно.

Почему же все-таки я подчеркиваю, что решить задачу несложно именно в данном случае? Вспомните пример с е '"". Там проблема была в том, что вычисленные десятичные приближения заканчивались девятками. А если бы и в этом примере цифры в конце оказались девятками, мы бы не смогли решить, верные ли они. (Именно для того, чтобы избежать округления и убедиться, что последняя цифра не девятка, мы и распечатываем k+1 цифру — k требуемых по условию задачи и одну запасную. Если бы запасная цифра оказалась девяткой, пришлось бы выводить еще несколько запасных цифр, пока не обнаружили бы отличную от 9.) Конечно, мы могли бы увеличить разрядность, но что если бы мы повстречали участок, сплошь состоящий из нескольких миллионов девяток? Может быть, это верные цифры, а может быть, нам просто не хватило точности, и в каком-то миллионе затерялась та единичка в переносе, добавление которой превращает все эти миллионы девяток в миллионы нулей? Вот оно коварство бесконечных десятичных дробей!

Из этого можно извлечь несколько уроков. Во-первых, выполняя действия над вещественными числами, нужно тщательно следить за точностью. Во-вторых, для применения таких функций, как FractionalPart, иногда необходима существенно более высокая разрядность, чем та, которая обеспечивается системой автоматически. В-третьих, иногда перестановка функций позволяет упростить программу. И, наконец, в-четвертых, вещественные числа иногда способны преподносить сюрпризы вроде девяток в конце вычисленных значений или необъятного количества ведущих нулей в начале дробной части. Тогда даже на простые вопросы вроде целое ли это число или конечная ли эта десятичная дробь ответить бывает чрезвычайно трудно. Ведь чем точнее удается приблизить бесконечную дробь рациональными числами, тем больше шансов на то, что она представляет собой число трансцендентное...

Упражнение 3.2 (число Пизо). Вычислите 5555 десятичных цифр числа Пизо

Сколько у этого числа нулей следует сразу после десятичной точки? Решение. Вот самое простое решение. Сначала вводим определение числа.

Теперь вычисляем число с указанной точностью.

Ну, как? Не думаете ли вы, что это число заслуживает того, чтобы вычислить его целую и дробную части по отдельности? Сначала вычислим целую часть.

"Ну и что?" — возможно, скажете вы. Тогда присмотритесь внимательнее, где начинаются нули. Да, именно с них и начинается дробная часть.

Из этого видно, что после десятичной точки следует 1831 нуль! Чтобы обнаружить, что это число не целое, нужно вычислить его не менее, чем с 5496 десятичными знаками. Вот это можно было бы устроить розыгрыш!

Упражнение 3.3. Пусть

Сколько у этого числа нулей следует сразу после десятичной точки?

Решение. Вот самое простое решение. Сначала вводим определение дроби fajl.

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

N[FFraction[Sqrt[17]-Sqrt[14],25],50]

 1.0000000000000000000000000000000000000000000000000

Ну и как? А вот еще:

Хотите еще? Пожалуйста.

А пятьдесят тысяч знаков после десятичной точки не хотите ли? Хотите. Тогда пожалуйста, только эффект будет в десять раз сильнее.

Между прочим, если это число целое, то после десятичной точки у него сплошные нули... И все попытки просто приведут к исчерпанию свободной памяти. Ну бывает же, что дроби сокращаются, а радикалы взаимно уничтожаются:

А здесь ведь разность степеней делится на разность степеней... Вот оно, коварство авторов, придумывающих "подленькие" задачи! Возможно, нужно лишь упростить выражение и убедиться, что оно равно какому-нибудь целому числу! Вот если в числителе вычесть и добавить удачно подобранную степень основания:

Конечно, сразу же просится k = 121393, тогда сразу же выделится единица:

Осталось справиться с числом

А ведь разность показателей представляет собой разность последовательных чисел Фибоначчи, и потому опять есть число Фибоначчи! Внимательно следите за моей мыслью? Может, надеетесь на дальнейшие упрощения? Так вот они:

Можно (для удобства исследования) эту дробь обратить и применить к ней тот же прием! И с полученной дробью можно поступить так же! Фактически у нас получатся элементы цепной дроби! После двух десятков (с хвостиком) шагов мы убедимся, что желанного нуля у нас так и не получится. Значит, после десятичной точки все-таки есть цифры, отличные от нуля! Ну вот, а вы говорили о коварстве авторов, придумывающих "подленькие" задачи! Но как же найти эти цифры? Ну, после проделанной работы у вас есть уверенность в наличии таких цифр, и потому вы знаете, что, в конце концов, все время увеличивая точность, вы их найдете. Это важно, ибо вы тем самым убедились в том, что алгоритм, хотя бы теоретически, не зациклится. Но есть и более быстрый способ, ведь мы нашли целую часть и знаем, что дробная не равна нулю. Можем без каких бы то ни было опасений попытаться вычислить логарифм дробной части:

Сразу не получилось... Но можно предпринять и вторую попытку.

Так, оказывается, после запятой 50810 нулей! Убедимся в этом.

Что касается нулей, то, хоть я и вычеркнул подавляющее их число, предварительно я их посчитал в Word! И их оказалось 50810! Между прочим, убедиться в том, что число f_a,nне целое, не так-то просто.

Упражнение 3.4. Пусть

Сколько у этого числа нулей следует сразу после десятичной точки?

Решение. Вот самое простое решение. Сначала вводим определение числа.

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

Да это ж предыдущий случай! Мы уже знаем, как с этим справиться.

Видите ли... Как бы вам это популярнее объяснить, пока продолжаются вычисления... Отличие от предыдущего случая состоит в том, что в предыдущем случае мы убедились, что 1 действительно является целой частью исследуемого числа. В данном же случае мы лишь предполагаем, что число -10 является целой частью числа х. дН-10 может ведь оказаться и отрицательным, а тогда логарифм окажется комплексным. Это, впрочем, совсем не страшно, мы лишь должны будем вычислить логарифм х+11. Вот и всего-то... Да, но что-то наши вычисления слишком затянулись... Понимаете, тут я должен сделать еще одно разъяснение. Видите ли, чтобы вычислить логарифм, нужно проделать некоторые вычисления, и в нашем случае с довольно высокой точностью. И успех эти вычисления принесут лишь тогда, когда будет обнаружено, что аргумент логарифма (число х+10) отличен от нуля... А в данном случае для этого недостаточно даже вычисления более чем двух с половиной миллионов знаков. Видите ли, бывает же, что дроби сокращаются, а радикалы взаимно уничтожаются. Вот в данном случае как раз х+10 = 0, потому что х= -10. Данное число целое! Давайте попробуем убедиться в этом.

Возможно, вы подумали, что автор хотел обвести вас вокруг пальца! Число все-таки оказалось нецелым! Просто система Mathematica не смогла вычислить достаточное количество знаков, и автор решил упростить себе задачу. Увы, если вы согласились с тем, что число нецелое, совершили довольно распространенную ошибку. Не потому, что оно целое, а потому, что так проверять нельзя. Предикат IntegerQ[x] может принимать значение False даже для целого аргумента. Он проверяет не само число, а его внутреннее представление. Этот предикат принимает значение True только в том случае, если внутреннее представление числа имеет заголовок Integer. Вот как лучше проверять.

Как видите, все ответы тавтологичны. И в данном случае вопрос так и не прояснился... Да, система Mathematica не всегда может то, с чем справляется даже школьник:

Теперь уж действительно ясно, что число целое. Конечно, придумать таких примеров можно великое множество. И проблема здесь не в коварстве авторов задачников, а в том, что не существует алгоритма (в классическом смысле), который для любого вещественного числа мог бы решить вопрос о том, равно оно нулю или нет. Существует специально разработанный математиками конструктивный анализ, в котором числовой континуум состоит не из обычных вещественных чисел, а из конструктивных. Для конструктивного вещественного числа всегда разрешим вопрос о том, равно ли оно нулю. Конструктивный континуум — та основа, на которой строятся другие объекты конструктивного анализа, например функции. Однако в конструктивном анализе изучаются не любые функции (отображения конструктивного континуума в себя), а только конструктивные. Несмотря на некоторое сходство, свойства конструктивных объектов отличаются подчас радикально.

Содержание раздела