22(19,25). Наближення функцій. Задача інтерполяції.

  Задача наближення функцій виникає при розв’язанні багатьох задач ( обробка експериментальних даних, чисельне диференціювання та інтегрування функцій, розв’язання диференціальних та інтегральних рівнянь).

Дуже зручною у використанні на практиці функцією є многочлен. Щоб задати многочлен, треба задати тільки скінченну кількість його коефіцієнтів. Значення многочлена просто обчислюються (згадаємо схему Горнера), його легко продиференціювати, проінтегрувати і т.і. Тому алгебраїчні многочлени знайшли широке застосування для наближення (апроксимації) функцій.

Розглянемо декілька задач наближення функцій.

Постановка задачі інтерполяції. Нехай відомі значення деякої функції у різних точках які позначимо

Виникає задача поновлення ( наближеного) функції у довільній точці .

Іноді відомо, що наближену функцію доцільно шукати у вигляді

де вигляд функції відомий, а параметри треба визначити.

Коли параметри визначаються з умови збігу і наближеної функції у точках тобто то такий спосіб наближення називається інтерполяцією. Точки називаються вузлами інтерполяції.

Серед способів інтерполяції найбільш поширеним є випадок лінійної інтерполяції .

де - деякі відомі функції. Значення коефіцієнтів визначаються з умови збігу з вихідною функцією у вузлах інтерполяції

(1)

тобто з системи n +1 лінійних рівнянь з n+1 невідомими

У окремому випадку, коли

(2)

тобто інтерполяція здійснюється многочленом, який називається інтерполяційним.

ТЕОРЕМА. Якщо вузли интерполяції різні, то існує єдиний інтерполяційний многочлен n-го ступеню.

Доведення . Дійсно, система рівнянь (1) у цьому випадку має вигляд

(3)

Її визначник є визначником Вандермонда

(4)

У тому, що має місце права частина рівності (4) , можна переконатися наступним чином.

Віднімаючи перший рядок з усіх наступних, маємо

 

Віднімаючи тепер з кожного стовпця попередній, що множиться на одержуємо

де

теж є визначником Вандермонда, порядок якого на одиницю менше порядку попереднього.

Зробивши з ним те ж, що з попереднім, одержимо

Продовжуючи аналогічні викладки остаточно одержимо рівність (4).

Бачимо, що при Тобто система (3) має єдиний розв’язок. Теорема доведена.

Таким чином, інтерполяційний поліном можна одержати шляхом розв’язання системи лінійних алгебраїчних рівнянь (3).

23. Математичне сподівання випадкової величини, його властивості та формули для обчислювання.

Математи́чне сподіва́ння є однією з найважливіших числових характеристик випадкової величини. Воно вказує на середнє значення випадкової величини, тобто на те, чому ця величина дорівнює «в середньому».

Означення:

Нехай — імовірнісний простір, ξ — випадкова величина. Число (якщо воно існує)

називається математичним сподіванням (середнім значенням) випадкової величини ξ.

Випадкова величина, що має математичне сподівання, називається інтегровною.

Деякі формули для обчислення математичного сподівання

Абстрактний інтеграл, що фігурує в означенні математичного сподівання, можна замінити відповідним інтегралом Лебега-Стілтьєса. Розглянемо випадок композиції борелівської функції f та випадкової величини ξ:

де Fξ(x) — функція розподілу випадкової величини ξ.

З останньої формули випливають всі інші формули:

Якщо випадкова величина ξ є абсолютно неперервною і має щільність pξ(x) то

Якщо випадкова величина ξ є простою, то де xk — можливі значення випадкової величини ξ, а pk — ймовірності їх набуття. Остання сума може містити як скінченну, так і нескінченну кількість доданків.

Властивості:

1Якщо та — незалежні інтегровні випадкові величини, то .

2.Якщо та — інтегровні випадкові величини, то .

3.Якщо — інтегровна випадкова величина, то

24. Принципы моделирования. Моделирование имеет богатую историю во всех инженерных дисциплинах. Длительный опыт его использования позволил сформулировать четыре основных принципа.

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

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

Второй принцип формулируется так: каждая модель может быть воплощена с разной степенью абстракции.

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

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

Третий принцип: лучшие модели - те, что ближе к реальности.

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

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

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

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

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