Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Задание 1 часть_В1-В34.docx
Скачиваний:
1
Добавлен:
19.09.2019
Размер:
3.05 Mб
Скачать

§ 2. Решение интегральных уравнений с помощью замены ядра на вырожденное

Другой классический способ решения интегральных уравнений, применя­емый в случае задач (1.2), (1.4), состоит в замене К(х,s) — ядра инте­грального оператора на вырожденное.

Вырожденным называется ядро, представимое в виде конечной суммы

Вариант № 30

  1. Отформатировать текст по стп мгупи. Оформить рисунки и программный кода

Управление расположением компонентов в GridBagLayout осуществляется отдельным объектом под названием GridBagConstraints, который полностью описывает расположение компонента в сетке и его особенности. Настроив его, вы передаете его в метод add() вме­сте с добавляемым в контейнер компонентом. К сожалению, именно этот объект делает GridBagLayout такой удобной целью для нападок, а код с его применением напоминает пре­красно перемешанное спагетти. Дело в том, что все настройки хранятся в нем в виде полей (что противоречит концепциям объектно-ориентированного программирования), имена этих полей иногда не соответствуют производимому им эффекту, а количество «волшеб­ных цифр» и избыточной информации поражает воображение и лишает код читаемости.

Давайте начнем с положения компонента в таблице. Его позиция определяется но­мером ячейки по вертикали и горизонтали:

Координаты в таблице, таким образом, хранятся в полях gridx и gridy. Так как указыватъ каждый раз новые координаты несколько утомительно, GridBagConstraints любезно предо­ставляет нам константу RELATIVE, согласно которой компонент будет добавлен в тот же ря; и следующий столбец за последним добавленным компонентов. Такое поведение напомнит нам последовательное расположение FlowLayout, тем более что по умолчанию компонент- придается предпочтительный размер. По умолчанию, если вы не указываете значение по- лей gridx и gridy, как раз RELATIVE и применяется, располагая компоненты в один ряд.

Так как сетка гибкая, мы можем указать, какое количество ячеек занимает компонеь— по вертикали или горизонтали.

  • gridwidth — количество ячеек, занимаемое компонентов по горизонтали, «длина- компонента в ячейках

  • gridheight — количество ячеек, занимаемое компонентов по вертикали, «высота- компонента в ячейках

Очень часто компонент должен занять весь ряд или столбец, независимо от то­го, сколько там ячеек. Для этих случаев предусмотрено значение GridBagConstra “ REMINDER, которое и говорит, что компонент займет все оставшиеся ячейки по о диви из осей или даже по обеим. Это тем более важно, что компонент в этом случае не заь.#- сит от появления большего количества ячеек в каком-то из рядом или столбцов, но ьге равно займет все ячейки.

Ячейки практически никогда не бывают одинакового размера, так как разня-:-» и размеры компонентов, и количество ячеек, ими занимаемое. Положение компоне»- та в самой ячейке таблицы GridBagLayout определяется еще несколькими полями клас -ж GridBagConstraints, и лучше всего увидеть, как они работают, на простой иллюстрации:

Итак, согласно иллюстрации мы получаем следующее:

  • fill — определяет, будет ли компонент заполнять все пространство ячейки, и если будет, то как. Можно применить константы HORIZONTAL, VERTICAL и BOTH, что бу­дет соответственно обозначать заполнение всего размера ячейки по горизонтали, вертикали, или всего пространства ячейки (по обоим направлениям). По умолча­нию значение этого поля в объекте GridBagConstraints равняется NONE, что означа­ет, что компонент остается предпочтительного размера и не желает изменяться вместе с размерами ячейки.

  • anchor — поле, значение которого указывает, к какому краю ячейки компоненту следует «прилепиться». На рисунке показаны наиболее вероятные варианты, ко­торые, как мы видим, названы по сторонам света, к примеру, выравнивание по левому краю называется WEST (выравнивание на запад). Есть также возможность «прилеплять» компоненты к углам ячейки.

  • insets — важные для любого прилично выглядящего интерфейса отступы между компонентами. Отступы задаются в виде объекта Insets, и определяют простран­ство между ячейками сверху, снизу, слева и справа, в пикселях.

Итак, основная идея GridBagLayout кажется понятной, и ячейки различных размеров, с полным контролем над их содержимым должны позволять создавать любые интерфей­сы. Рассмотрим простой пример:

// GridBagStart.java

// Первые опыты с расположением GridBagLayout

importjava.awt.*;

import javax.swing.*;

public class GridBagStart extends JFrame { public GridBagStart() { super("GridBagStart");

// выходпризакрытииокнаsetDefaultCloseOperation(EXIT_ON_CLOSE);

Кнопки расположены именно так, как мы и ожидали, а вот с текстовым полем воз­никла некоторая проблема. Оно не растянуто на всю оставшуюся ширину окна, несмотря на то, что мы подходящим образом задали поля gridwidth и fill, и все равно осталось пред­почтительного размера (длиной в 10 символов ввода', что мы задали в конструкторе для поля JTextField). Более того, если вы сделаете окно меньше, выувидите, что при нехватке пространства поле сжимается до минимального размера «прыжком», не уменьшая свои размеры плавно. Пример показывает нам, что по умолчанию менеджер GridBagLayout ве­дет себя следующим образом:

  • компоненты имеют предпочтительный размер и не более

  • компоненты располагаются в центре контейнера

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

Как же заставить GridBagLayout делать компоненты больше их предпочтительного размера? Для этого есть пара несколько загадочных полей, определяющих так называе­мый «вес» ячейки.

  • weightx, weighty — дробные числа, которые указывают менеджеру, сколько свобод­ного места из контейнера следует отдавать ячейке, если таковое имеется. Числа эти нормированные — менеджер GridBagLayout собирает все значения из всех яче­ек и вычисляет процент от максимального значения. Как правило, в качестве максимального значения используется единица — это 100% отдача всего свобод­ного пространства ячейке. Числа от нуля до единицы будут означать процен­ты от свободного пространства, которые отдаются ячейке. Ну а по умолчанию значения полей weightx и weighty равны нулям, а это значит, что ячейка никогда не станет больше предпочтительного размера своего компонента и отступов. Интересным свойством полей weightx и weighty является и то, что если в контейне­ре, управляемом GridBagLayout, содержится хотя бы одна ячейка, в которой зна­чения этих полей отличны от нуля, GridBagLayout займет все место контейнера. В противном случае будет занято лишь то место, которого достаточно для предпо­чтительных размеров компонентов, причем все компоненты будут располагаться по центру контейнера, что мы уже имели возможность наблюдать в нашем первом примере.

  • Теперь, кажется, понятно, что же мы упустили. Если мы хотим чтобы текстовое поле занимало весь остаток места по горизонтали, нам нужно установить поле weightx в 100%, в зависимости от того, какое число вы используете в качестве максимума. Если принять за 100% единицу, то дополнительная строчка кода будет выглядеть так:

  • textFieldConstraints.weightx = l.Of;

  • А результат будет таков:

Изменяя размеры окна, вы сможете убедиться в том, что текстовое поле занимает всю его ширину, и размер его больше не «прыгает» и не зависит от количества набран­ного в нем текста.

Идея GridBagLayoutне так и сложна, и большинство расположений довольно лег­ко поддаются ему. Однако основной проблемой является объект для описания ячеек GridBagConstraints. Названия его полей не всегда ясны (к примеру, gridwidthи weightдоволь­но двусмысленны), а значения для них подстегивают к добавлению к коду цифр (уже упо­мянутые поля, плюс поле insets), и мы сталкиваемся с проблемой «волшебных чисел», когда цифры в коде не несут очевидной смысловой нагрузки.

  1. Отформатировать таблицу по СТП МГУПИ

  1. Отформатировать текст по СТП МГУПИ, ввести формулы с помощью инструмента MSEquation

Если применяется метод из § 1, то при больших т решение системы (1.9) ме­тодом Гаусса может оказаться

Если

Вариант № 31