Системы с модулем как решать: Ошибка 403 — доступ запрещён

Основы компьютерной алгебры с приложениями

Основы компьютерной алгебры с приложениями
  

Акритас А. Основы компьютерной алгебры с приложениями: Пер. с англ. — М., Мир, 1994. — 544 с.

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

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



Оглавление

ОТ ПЕРЕВОДЧИКА
ПРЕДИСЛОВИЕ
Часть I. ВВЕДЕНИЕ
1.1. Компьютерная алгебра и численный анализ
1.2 Компьютерная алгебра: точная целочисленная и полиномиальная арифметики
Списочное представление целых чисел.
Структуры данных.
Алгоритмы и их сложность.
Классические алгоритмы целочисленной арифметики и их сложность.
Списочное представление полиномов.
Классические алгоритмы полиномиальной арифметики и их сложность.
1.3 Системы компьютерной алгебры
Упражнения
Часть II. МАТЕМАТИЧЕСКИЕ ОСНОВАНИЯ И ОСНОВНЫЕ АЛГОРИТМЫ
2.1.2. Отношения эквивалентности
2.1.3. Функции и алгебраические системы
2.2. Наибольшие общие делители целых чисел
2.2.2. Алгоритм Евклида и теорема Ламе
2.2.3. Расширенный алгоритм Евклида
2.2.4. Алгоритм Евклида и цепные дроби
2.3. Разложение целых чисел на множители
2.3.2. Целые числа по модулю m и алгоритм в грекокитайской теореме об остатках
Применения линейных сравнений по модулю m.
Вычисление мультипликативных обратных.
Малая теорема Ферма (1640). r)
Упражнения
Упражнения по программированию
Литература
Часть III. ПРИЛОЖЕНИЯ И СОВРЕМЕННЫЕ МЕТОДЫ
Глава 4. Коды, исправляющие ошибки, и криптография
4.1.1. Коды Хэмминга
4.1.2. БЧХ-коды
4.2. Криптография — общие понятия
4.2.1. Симметричные криптосистемы (единого ключа)
4.2.2. Асимметричные криптосистемы (открытого ключа)
Упражнения
Упражнения по программированию
Литература
Глава 5. Наибольшие общие делители полиномов над целыми числами и последовательности полиномиальных остатков
5.1.1. Общий обзор классических алгоритмов PRS
5.1.2. Неклассический подход: модулярный алгоритм для наибольшего общего делителя
5.2. Метод Сильвестра-Габихта псевдоделения субрезультантных PRS
5.2.2. Результант двух полиномов
5.2.3. Алгоритм Габихта субрезультантных PRS
5.3. Метод матричной триангуляризации субрезультантных PRS
5.3.2. Гауссово исключение и результанты в формах Брюно и Труда
5.3.3. Гауссово исключение + результант в форме Сильвестра = метод матричной триангуляризации субрезультантных PRS
5. 4. Эмпирическое сравнение двух методов субрезультантных PRS
Упражнения
Упражнение по программированию
Исторические замечания и литература
Глава 6. Разложение на множители полиномов над целыми числами
6.1.1. Метод Кронекера—Шуберта разложения на множители над целыми числами
6.1.2. Общая схема «окольного» метода разложения над кольцом целых чисел
6.2. Разложение на множители полиномов над конечным полем
6.2.2. Вычисление числа неприводимых полиномов над конечными полями
6.2.3. Разложение полиномов на множители разных степеней (частичное) над конечными полями
6.2.4. Алгоритм Берлекэмпа разложения на множители над конечными полями
6.3. Подъем (mod p) – разложения до разложения над целыми числами
6.3.1. Линейный и квадратичный подъем
6.3.2. Нахсмвдение истинных сомножителей над целыми числами
Упражнения
Исторические замечания и литература
Глава 7. Отделение и аппроксимация вещественных корней полиномиальных уравнений
7.2. Теорема Фурье и метод бисекций Штурма отделения вещественных корней
7. 2.2. Теорема Штурма и метод бисекций Штурма отделения вещественных корней
7.2.3. Вычисление верхней (нижней) границы значений положительных корней полиномиального уравнения
7.2.4. Вычисление нижней границы расстояния между любыми двумя корнями полиномиального уравнения
7.3. Теорема Бюдана и два метода цепных дробей для отделения вещественных корней
7.3.2. Подстановки Мёбиуса и их воздействие на корни уравнения
7.3.3. Теорема Винсента: расширение и приложения
7.3.4. Два метода цепных дробей отделения вещественных корней
7.4. Эмпирическое сравнение двух методов отделения вещественных корней
7.5. Аппроксимация вещественных корней полиномиального уравнения
7.5.2. Аппроксимация вещественного корня с использованием цепных дробей
7.6. Эмпирическое сравнение двух методов аппроксимации вещественных корней
Упражнения
Упражнения по программированию
Исторические замечания и литература
ПРИЛОЖЕНИЕ. ЛИНЕЙНАЯ АЛГЕБРА

МРО-2М

Адресный модуль речевого оповещения МРО-2М является программируемым устройством. Конфигурирование МРО-2М осуществляется пользователем с приемно-контрольного прибора (при подключении по технологической адресной линии связи АЛСТ или рабочей линии АЛС) или ПО «FireSec «Администратор». В системе модуль может иметь один из двух статусов – ведущий (управляемый источник сигнала) или ведомый (управляемый усилитель сигнала).

МРО-2М имеет выход на динамические головки и реализует речевую систему оповещения людей при пожаре.

Адресный модуль речевого оповещения МРО-2М обеспечивает:

  • подключение акустических модулей или их сборок, общим сопротивлением не менее 4 Ом;
  • линейный вход, может использоваться как обычный усилитель мощности;
  • линейный выход для подключения ведомого МРО-2М;
  • контроль целостности цепи до акустических модулей на обрыв и КЗ;
  • два выхода для подключения кнопок ПУСК и СТОП с контролем целостности цепей на КЗ и обрыв для локального запуска и прекращения оповещения;
  • возможность записи в память устройства любого голосового сообщения;
  • воспроизведение записанного сообщения бесконечное число раз;
  • автоматический запуск воспроизведения сообщения по сигналу с приемно-контрольного прибора;
  • светодиодную индикацию режимов работы модуля и наличия связи с центральным прибором;

К модулю МРО-2М подключаются только пассивные акустические модули, не содержащие в цепи подключения дополнительных радиоэлементов (конденсаторов, катушек, трансформаторов).

Модуль поставляется с одним заранее записанным речевым сообщением. МРО-2М способен хранить до 8 сообщений (включительно). Обновление ПО и запись сообщений осуществляется с помощью программы «Конфигуратор МРО2М.exe» по каналу USB.

Питание модуля осуществляется от внешнего источника питания. На лицевой стороне модуля расположены индикаторы СВЯЗЬ и НОРМА

Индикатор СВЯЗЬ красного цвета:

  • в дежурном состоянии мигает с частотой 0,2 Гц;
  • при отсутствии связи с приемно-контрольным прибором либо при подключении USB разъема светится постоянно;
  • во время оповещения мигает с частотой 1 Гц;
  • после нажатия кнопки КАЛИБРОВКА (запоминание сопротивления АМ) по истечению 3 с – три коротких мигания, а далее – постоянное свечение индикатора пока удерживается кнопка;
  • при коротком нажатии на кнопку КАЛИБРОВКА (менее 3 с) – постоянное свечение индикатора на время считывания состояния прибора;
  • при передаче данных по каналу USB – частое свечение индикатора.

Индикатор НОРМА зеленого цвета:

  • в дежурном состоянии постоянное свечение индикатора;
  • при обнаружении неисправностей – мигание с частотой 2 Гц;
  • при подключении к разъему USB – отсутствие свечения индикатора.

В процессе работы речевой модуль отслеживает сопротивление акустических модулей. Изменение сопротивления более чем на 0,5 Ом от начального значения расценивается как неисправность. В приложении 2 приведена таблица возможных вариантов подключения сборок колонок и их сопротивления.

Модуль речевого оповещения МРО-2М имеет возможность установки на DIN-рейку с помощью специальной крепежной планки (вкомплект поставки не входит и комплектуется по отдельному заказу).

модуль underworld.systems — документация underworld2

Этот модуль содержит подпрограммы, относящиеся к дифференциальной системе.

Обзор модулей

подмодулей:

  • модуль underworld.systems.sle

функции:

underworld. systems.Solver Этот метод просто возвращает необходимый решатель для предоставленной системы.

классы:

преступный мир.системы.Стокс
Этот класс предоставляет функциональные возможности для дискретного представления уравнений потока Стокса.
нижний мир.системы.SteadyStateHeat Этот класс предоставляет функциональные возможности для дискретного представления стационарного уравнения теплопроводности.
преступный мир.системы.SteadyStateDarcyFlow Этот класс предоставляет функциональные возможности для дискретного представления стационарного уравнения потока Дарси.
underworld.systems.TimeIntegration Абстрактный класс для интегрирования числовых объектов (полей, роев и т. д.) во времени.
подземный мир.системы.AdvectionDiffusion Этот класс предоставляет функциональные возможности для дискретного представления уравнения адвекции-диффузии.
подземный мир.системы.SwarmAdvector Объекты этого класса перемещаются во времени роем, используя предоставленное поле скорости.

Сведения о модуле

функции:

преступный мир.систем. Solver ( eqs , type=’BSSCR’ , *args , **kwargs )[источник]

Этот метод просто возвращает необходимый решатель для предоставленной системы.

классы:

класс преступный мир.системы. Стокс ( VelocityField , pressureField , fn_viscosity , fn_bodyforce=None , fn_one_on_lambda=None , fn_lambda=None , fn_source=None , voronoi_swarm=None , conditions=[] , _removeBCs=True .

Базы: подземный мир._stgermain.StgCompoundComponent

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

В частности, класс использует смешанный метод конечных элементов для построить систему линейных уравнений, которую затем можно решить используя объект класса underworld.system.Solver.

Типы базовых элементов определяются поддерживающими сетка, используемая для параметров «velocityField» и «pressureField».

Сильная форма данной краевой задачи для \(f\), \(g\) и \(h\) заданы, равно

\[\begin{split}\begin{align} \sigma_{ij,j} + f_i =& \: 0 & \text{ в } \Omega \\ u_{k,k} + \frac{p}{\lambda} =& \: H & \text{ в } \Omega \\ u_i =& \: g_i & \text{ на } \Gamma_{g_i} \\ \sigma_{ij}n_j =& \: h_i & \text{ on } \Gamma_{h_i} \\ \конец{выравнивание}\конец{разделение}\]

где,

  • \(\sigma_{i,j}\) — тензор напряжений
  • \(u_i\) — скорость,
  • \(p\) — давление,
  • \(f_i\) — объемная сила,
  • \(\лямбда\) объемная вязкость,
  • \(H\) — исходный член уравнения сжимаемости,
  • \(g_i\) — граничные условия скорости (DirichletCondition)
  • \(h_i\) — граничные условия тяги (NeumannCondition). {n_{sd}} \int_{\Gamma_{h_j}} w_i \, h_i \, d \Gamma\]

    , где мы должны найти \(u\), который удовлетворяет приведенному выше для всех \(w\) в некотором вариационном пространстве.

    Параметры:
    • speedField ( underworld.mesh.MeshVariable ) — переменная, используемая для записи скорости системы.
    • pressureField ( underworld.mesh.MeshVariable ) — переменная, используемая для записи давления в системе.
    • fn_viscosity ( underworld.function.Function ) – Функция, которая сообщает значение вязкости. Функция должна возвращать скалярные значения с плавающей запятой.
    • fn_bodyforce ( underworld.function.Function , По умолчанию = Нет ) — Функция, которая сообщает системе силу тела. Функция должна возвращать значения с плавающей запятой одинаковой размерности. к предоставленной переменной скорости.
    • fn_lambda ( Удалено использование , fn_one_on_lambda вместо ) —
    • fn_minus_one_on_lambda ( underworld.function.Function , По умолчанию = None ) — Функция, которая определяет несоленоидальное поле скоростей через соотношение div(velocityField) = -fn_minus_one_on_lambda * поле давления + fn_source Когда это значение оставлено равным None, формируется несжимаемая формулировка уравнения Стокса, т. е. div(velocityField) = 0. fn_minus_one_on_lambda несовместим с решателем «штрафного» Стокса, убедитесь, что «штраф», равный 0, используется, когда используется fn_minus_one_on_lambda. По умолчанию это так.
    • fn_source ( underworld.function.Function , По умолчанию = None ) — Функция, которая определяет несоленоидальное поле скорости через соотношение div(velocityField) = -fn_minus_one_on_lambda * поле давления + fn_source. fn_minus_one_on_lambda несовместим с решателем «штрафного» Стокса, убедитесь, «штраф» 0 используется, когда используется fn_lambda. По умолчанию это так.
    • fn_stresshistory ( underworld.function.Function , По умолчанию = Нет ) — функция, которая определяет термин истории напряжений, используемый для вязкоупругости. Функция — это вектор размера 3 (dim=2) или 6 (dim=3), представляющий симметричный тензор.
    • voronoi_swarm ( underworld.swarm.Swarm ) — если предоставляется voronoi_swarm, выполняется численное интегрирование типа voronoi. используется. Предоставленный рой используется как основа для voronoi интеграция. Если voronoi_swarm не указан, интеграция по Гауссу используется.
    • условия ( underworld.conditions.SystemCondition ) — числовые условия, накладываемые на систему. Это должно быть предоставлено как само условие или объект списка, содержащий условия.

    Примечания

    Конструктор должен вызываться всеми процессами совместно.

    Эк Остатки

    Возвращает невязки уравнений потока Стокса из последнего решения. Остаточные расчеты использовать матрицы и векторы дискретизированной задачи. Невязки соответствуют уравнению количества движения и уравнению неразрывности.

    Возвращает: r1 — невязка уравнения импульса r2 — невязка уравнения неразрывности
    Тип возврата: (r1, r2) — 2 кортежа двойников

    Примечания

    Этот метод должен вызываться всеми процессами совместно.

    fn_bodyforce

    Функция силы тела. Вы можете изменить эту функцию напрямую через этот свойство.

    fn_one_on_lambda

    Параметр объемной вязкости

    fn_source

    Функция термина объемного источника. Вы можете изменить эту функцию напрямую через этот свойство.

    fn_вязкость

    Функция вязкости. Вы можете изменить эту функцию напрямую через этот свойство.

класс преступный мир.системы. SteadyStateHeat ( Demchfield , FN_DIFFUSIVE , FN_HEATING = 0,0 , Voronoi_SWARM = NOT , Условия = , , , , , , , , , , , , .

Базы: underworld._stgermain.StgCompoundComponent

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

Класс использует стандартный метод конечных элементов Галеркина для построить систему линейных уравнений, которую затем можно решить используя объект класса underworld.system.Solver.

Типы базовых элементов определяются поддерживающими сетка, используемая для «temporaryField».

Сильная форма данной краевой задачи для \(f\), \(h\) и \(h\) задано, равно

\[\begin{split}\begin{align} q_i =& — \alpha \, u_{,i} & \\ q_{i,i} =& \: f & \text{ в } \Omega \\ u =& \: g & \text{ on } \Gamma_g \\ -q_i n_i =& \: h & \text{ на } \Gamma_h \\ \end{выравнивание}\end{split}\]

где \(\alpha\) — коэффициент диффузии, \(u\) — температура, \(f\) — исходный термин, \(g\) — условие Дирихле, а \(h\) — условие Неймана. Граница проблемы, \(\Gamma\), допускает разложение \(\Gamma=\Gamma_g\cup\Gamma_h\), где \(\emptyset=\Gamma_g\cap\Gamma_h\). Эквивалентная слабая форма:

\[-\int_{\Omega} w_{,i} \, q_i \, d \Omega = \int_{\Omega} w \, f \, d\Omega + \int_{\Gamma_h} w \, h \, д \Гамма\]

, где мы должны найти \(u\), который удовлетворяет приведенному выше для всех \(w\) в некотором вариационном пространстве.

Параметры:
  • TemperatureField ( underworld. mesh.MeshVariable ) — Поле решения для температуры.
  • fn_diffusivity ( underworld.function.Function ) — функция, определяющая коэффициент диффузии в домене.
  • fn_heating ( underworld.function.Function ) — функция, определяющая нагрев в домене. Необязательный.
  • voronoi_swarm ( underworld.swarm.Swarm ) — если предоставляется voronoi_swarm, выполняется численное интегрирование типа voronoi. используется. Предоставленный рой используется как основа для voronoi интеграция. Если voronoi_swarm не указан, интеграция по Гауссу используется.
  • условия ( underworld.conditions.SystemCondition ) — числовые условия, накладываемые на систему. Это должно быть предоставлено как само условие или объект списка, содержащий условия.

Примечания

Конструктор должен вызываться всеми процессами совместно.

Пример

Настройка базовой тепловой системы:

 >>> linearMesh = uw.mesh.FeMesh_Cartesian( elementType='Q1/dQ0', elementRes=(4,4), minCoord=(0.,0.), maxCoord=(1.,1.))
>>> tField = uw.mesh.MeshVariable( linearMesh, 1 )
>>> topNodes = linearMesh.specialSets["MaxJ_VertexSet"]
>>> нижние узлы = linearMesh.specialSets["MinJ_VertexSet"]
>>> tbcs = uw.conditions.DirichletCondition (tField, верхние узлы + нижние узлы)
>>> tField.data[topNodes.data] = 0.0
>>> tField.data[нижние узлы.данные] = 1.0
>>> tSystem = uw.systems.SteadyStateHeat(temperatureField=tField, fn_diffusivity=1.0, условия=[tbcs])
 

Пример без диффузии:

 >>> k = tField + 1.0
>>> tSystem = uw.systems.SteadyStateHeat(temperatureField=tField, fn_diffusivity=k, условия=[tbcs])
>>> решатель = uw.systems.Solver(tSystem)
>>> решатель.решить()
Traceback (последний последний вызов):
...
RuntimeError: Обнаружена нелинейность.
Функция диффузии зависит от температурного поля, подаваемого в систему. 
Чтобы продолжить, установите для параметра решения nonLinearIterate значение «True» или «False».
>>> Solver.solve(nonLinearIterate=True)
 
fn_diffusivity

Функция диффузии. Вы можете изменить эту функцию напрямую через этот свойство.

fn_heating

Функция обогрева. Вы можете изменить эту функцию напрямую через этот свойство.

класс преступный мир.системы. SteadyStateDarcyFlow ( PressureField , fn_diffusivity , fn_bodyforce = none , voronoi_swarm = none , Условия = [] , Velocityfield = None , Swarmvarvelocity = None , _Removebcs = TrueMvarvelocity = None , _Removebcs = TrueM99 **, , , , , , , , , , , , , , , , , , *.

Базы: underworld. _stgermain.StgCompoundComponent

Этот класс предоставляет функциональные возможности для дискретного представления стационарного уравнения потока Дарси.

Класс использует стандартный метод конечных элементов Галеркина для построить систему линейных уравнений, которую затем можно решить используя объект класса underworld.system.Solver.

Типы базовых элементов определяются поддерживающими сетка, используемая для «поля давления».

Сильная форма данной краевой задачи для \(f\), \(q\) и \(h\) задано, равно

\[\begin{split}\begin{align} q_i =& \каппа\, (-u_{,i} + S_i) & \\ q_{i,i} =& \: f & \text{ в } \Omega \\ u =& \: q & \text{ on } \Gamma_q \\ -q_i n_i =& \: h & \text{ на } \Gamma_h \\ \конец{выравнивание}\конец{разделение}\]

где,

  • \(\каппа\) — коэффициент диффузии, \(u\) — давление,
  • \(S\) — тело-источник потока, например за счет силы тяжести,
  • \(f\) — исходный термин, \(q\) — условие Дирихле,
  • \(h\) — условие Неймана.

Граница задачи \(\Gamma\) допускает разложение \(\Gamma=\Gamma_q\cup\Gamma_h\), где \(\emptyset=\Gamma_q\cap\Gamma_h\). Эквивалентная слабая форма:

\[-\int_{\Omega} w_{,i} \, q_i \, d \Omega = \int_{\Omega} w \, f \, d\Omega + \int_{\Gamma_h} w \, h \, д \Гамма\]

, где мы должны найти \(u\), который удовлетворяет приведенному выше для всех \(w\) в некотором вариационном пространстве.

Параметры:
  • pressureField ( underworld.mesh.MeshVariable ) — Поле решения для давления.
  • fn_diffusivity ( underworld.function.Function ) — функция, определяющая коэффициент диффузии в домене.
  • fn_bodyforce ( подземный мир.функция.Функция ) — функция, определяющая объемную силу потока через область, например гравитация. Должен быть вектор. Необязательный.
  • voronoi_swarm ( underworld. swarm.Swarm ) — Должен быть предоставлен рой только с одной частицей в каждой ячейке. Это позволяет избежать оценки скорости по узлам и неточностей возникающие из-за изменения диффузии внутри клеток. Если задан рой, выполняется численное интегрирование типа Вороного. используется. Предоставленный рой используется как основа для voronoi интеграция. Если voronoi_swarm не указан, интеграция по Гауссу используется.
  • условия ( underworld.conditions.SystemCondition ) — числовые условия, накладываемые на систему. Это должно быть предоставлено как само условие или объект списка, содержащий условия.
  • speedField ( underworld.mesh.MeshVariable ) – Поле решения для скорости потока по Дарси. Необязательный.
  • swarmVarVelocity ( undeworld.swarm.SwarmVariable ) — если указана переменная роя, скорость, рассчитанная для роя, будет сохранена. Это наиболее репрезентативный объект данных скорости, так как вычисление скорости происходит на рое, вдали от узлов сетки. Необязательный.

Примечания

Конструктор должен вызываться всеми процессами совместно.

fn_bodyforce

Функция обогрева. Вы можете изменить эту функцию напрямую через этот свойство.

fn_diffusivity

Функция диффузии. Вы можете изменить эту функцию напрямую через этот свойство.

класс преступный мир.системы. TimeIntegration ( порядок , ** kwargs )[источник]

Базы: underworld._stgermain.StgCompoundComponent

Абстрактный класс для интегрирования числовых объектов (полей, роев и т. д.) во времени.

Алгоритм интегрирования представляет собой модифицированный метод Рунге-Кутты, который оценивает только информация о средней точке, изменяющаяся в пространстве — с использованием только текущего временного решения. Порядок интегрирования может быть 1,2,4

Parameters: order ( int {1 , 2 , 4} ) – Defines the numerical order ‘in space’ of the Runge Kutta like integration scheme.
дт

Размер временного шага интегратора времени.

время

Значение времени интегратора времени.

класс преступный мир.системы. AdvectionDiffusion ( Phifield , Phidotfield , Velocityfield , FN_DIFFUSIVE , FN_SOURCETERM = NOTE , Условия = [] , : , , , , , , , , , , , , , , , , , , , , .

Базы: underworld. _stgermain.StgCompoundComponent

Этот класс предоставляет функциональные возможности для дискретного представления уравнения адвекции-диффузии.

В классе используется метод Streamline Upwind Петров Галеркин SUPG интегрировать во времени.

\[\frac{\partial\phi}{\partial t} + {\bf u } \cdot \nabla \phi= \nabla {(k \nabla \phi)} + H\]

Параметры:
  • phiField ( underworld.mesh.MeshVariable ) – Поле концентрации, обычно поле температуры
  • phiDotField ( underworld.mesh.MeshVariable ) — MeshVariable, определяющая начальную производную по времени от phiField. Обычно 0 в начале модели, т.е. phiDotField.data[:]=0 При использовании phiField, загруженного с диска, следует также загрузить phiDotField, чтобы гарантировать метод решения имеет информацию о производной по времени для плавного перезапуска. Никаких условий Дирихле для этого поля не требуется, так как степени свободы фиполя сопоставить точно с условиями Дирихле этого поля, значение которых должно быть 0 для постоянных значений фи.
  • speedField ( underworld.mesh.MeshVariable ) — Поле скоростей.
  • fn_diffusivity ( underworld.function.Function ) — функция, определяющая коэффициент диффузии в домене.
  • fn_sourceTerm ( underworld.function.Function ) — функция, определяющая нагрев в домене. Необязательный.
  • условия ( underworld.conditions.SystemCondition ) – Численные условия, накладываемые на систему. Это должно быть предоставлено как само условие или объект списка, содержащий условия.

Примечания

Конструктор должен вызываться всеми процессами совместно.

get_max_dt ()[источник]

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

Возвраты: Размер временного шага.
Тип возврата: с плавающей запятой
интегрировать ( dt )[источник]

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

Параметры: dt ( float ) – Используемый временной интервал
класс преступный мир.системы. SwarmAdvector ( speedField , рой , order=2 , **kwargs )[источник]

Базы: underworld. systems._timeintegration.TimeIntegration

Объекты этого класса перемещаются во времени роем, используя заданное поле скоростей.

Параметров:
  • speedField ( underworld.mesh.MeshVariable ) — Поле MeshVariable, используемое для оценки поля скорости, которое продвигает частицы роя
  • рой ( underworld.swarm.Рой ) — рой частиц, который будет переноситься данным полем скоростей
интегрировать ( dt , update_owners=True )[источник]

Интегрировать связанный рой во времени по dt, используя поле скоростей, связанное с этим классом

Параметры:
  • dt ( double ) – Шаг времени для использования в интеграции
  • update_owners ( bool ) — если установлено значение False, владение частицами (какой элемент владеет конкретной частицы) не обновляется после адвекции. Это часто необходимо, когда и сетка, и частицы перемещаются одновременно.

Пример

 >>> импортировать подземный мир как uw
>>> импортировать numpy как np
>>> импортировать numpy.testing как npt
>>> из функции импорта подземного мира как fn
>>> тусклый=2;
>>> elementMesh = uw.mesh.FeMesh_Cartesian(elementType="Q1/dQ0", elementRes=(9,9), minCoord=(-1.,-1.), maxCoord=(1.,1.))
>>> VelocityField = uw.mesh.MeshVariable(mesh=elementMesh, nodeDofCount=dim)
>>> рой = uw.swarm.Swarm(mesh=elementMesh)
>>> частица = np.zeros((1,2))
>>> частица[0] = [0,2,-0,2]
>>> swarm.add_particles_with_coordinates(частица)
массив ([0], dtype = int32)
>>> VelocityField.data[:]=[1.0,1.0]
>>> swarmAdvector = uw.systems.SwarmAdvector(velocityField=velocityField, рой=рой, порядок=2)
>>> dt=1.0
>>> swarmAdvector.integrate(dt)
>>> npt.assert_allclose(swarm.particleCoordinates.data[0], [1.2,0.8], rtol=1e-8, verbose=True)
 

Понимание модулей Java 9

Java 9 | Отрывок

Что это такое и как их использовать

Пол Дейтель

Пол Дейтель

В этой статье я познакомлю вас с системой платформенных модулей Java 9 (JPMS), самой важной новой технологией разработки программного обеспечения на Java с момента ее создания. . Модульность — результат Project Jigsaw — помогает разработчикам на всех уровнях работать более продуктивно при создании, обслуживании и развитии программных систем, особенно больших систем.

Что такое модуль?

Модульность добавляет более высокий уровень агрегации над пакетами. Ключевым новым языковым элементом является модуль — повторно используемая группа связанных пакетов с уникальным именем, а также ресурсов (таких как изображения и XML-файлы) и дескриптор модуля , определяющий

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

Платформа Java SE существует с 1995 года. В настоящее время около 10 миллионов разработчиков используют ее для создания всего: от небольших приложений до устройств с ограниченными ресурсами, таких как Интернет вещей (IoT) и других встроенных устройств. — к крупномасштабным критически важным для бизнеса и критически важным системам. Существует огромное количество устаревшего кода, но до сих пор платформа Java в основном представляла собой монолитное универсальное решение. За прошедшие годы были предприняты различные усилия, направленные на модульность Java, но ни одна из них не получила широкого распространения — и ни одна из них не могла быть использована для модульности платформы Java.

Модуляризация платформы Java SE была сложной задачей, и на это ушло много лет. JSR 277: Система модулей Java была первоначально предложена в 2005 году для Java 7. Позже этот JSR был заменен JSR 376: Система модулей платформы Java и предназначен для Java 8. Платформа Java SE теперь модульная в Java 9, но только после Java 9. был отложен до сентября 2017 года.

Цели

Каждый модуль должен явно указывать свои зависимости.

Согласно JSR 376, ключевыми целями модуляризации платформы Java SE являются

  • Надежная конфигурация. Модульность предоставляет механизмы для явного объявления зависимостей между модулями таким образом, чтобы они распознавались как во время компиляции, так и во время выполнения. Система может просмотреть эти зависимости, чтобы определить подмножество всех модулей, необходимых для поддержки вашего приложения.
  • Сильная инкапсуляция — пакеты в модуле доступны другим модулям только в том случае, если модуль явно экспортирует их. Даже в этом случае другой модуль не может использовать эти пакеты, если только в нем явно не указано, что ему требуются возможности другого модуля. Это повышает безопасность платформы, поскольку меньшее количество классов доступно для потенциальных злоумышленников. Возможно, вы обнаружите, что рассмотрение модульности помогает вам создавать более чистые и логичные проекты.
  • Масштабируемая платформа Java. Ранее платформа Java представляла собой монолит, состоящий из огромного количества пакетов, что усложняло ее разработку, обслуживание и развитие. Это не могло быть легко подмножество. Платформа теперь состоит из 95 модулей (это число может измениться по мере развития Java). Вы можете создавать собственные среды выполнения, состоящие только из модулей, необходимых для ваших приложений или устройств, на которые вы ориентируетесь. Например, если устройство не поддерживает графический интерфейс, вы можете создать среду выполнения, не включающую модули графического интерфейса, что значительно уменьшит размер среды выполнения.
  • Повышенная целостность платформы. До появления Java 9 в платформе можно было использовать многие классы, которые не предназначались для использования классами приложения. Благодаря строгой инкапсуляции эти внутренние API действительно инкапсулированы и скрыты от приложений, использующих платформу. Это может сделать проблематичным перенос устаревшего кода на модульную Java 9, если ваш код зависит от внутренних API.
  • Повышенная производительность — JVM использует различные методы оптимизации для повышения производительности приложений. JSR 376 указывает, что эти методы более эффективны, когда заранее известно, что требуемые типы расположены только в определенных модулях.
Перечисление модулей JDK

JEP 200: Модульный JDK

JEP 201: Модульный исходный код

JEP 220: модульный время пробега

JEP 220: Encapl Nearture Mose Aptaul

JEP 260: Ecp 220: Encapl Nate Most Appure 2600: Ecp 220: Encapl Nective Aptor Nate Most Appure 2600: Encapl NectulAl.

JEP 261: модульная система

JEP 275: Модульная упаковка Java Application

JEP 282: JLink: Java Linker

JSR 376: Платформа Java.0099

JSR 379: JAVA SE 9

Таблица 1. JEP и JSR Модульность Java

Важным аспектом Java 9 является разделение JDK на модули для поддержки различных конфигураций. (См. «JEP 200: The Modular JDK». Все модульные JEP и JSR для Java показаны в Table 1 .) Использование команды java из папки bin JDK с параметром --list-modules , например:

java --list-modules

перечисляет набор модулей JDK, который включает стандартные модули, реализующие спецификацию Java Language SE (имена, начинающиеся с java ), модули JavaFX (имена, начинающиеся с javafx ), модули, специфичные для JDK (имена, начинающиеся с jdk ) и модули, специфичные для Oracle (имена, начинающиеся с oracle ). За каждым именем модуля следует строка версии — @9 указывает, что модуль относится к Java 9.

Объявления модуля

Как мы уже упоминали, модуль должен предоставлять дескриптор модуля — метаданные, которые определяют зависимости модуля, пакеты модуль делает доступными для других модулей и многое другое. Дескриптор модуля — это скомпилированная версия объявления модуля, определенного в файле с именем 9. 0022 модуль-info.java . Каждое объявление модуля начинается с ключевого слова module , за которым следует уникальное имя модуля и тело модуля, заключенное в фигурные скобки, например:

Ключевым мотивом модульной системы является строгая инкапсуляция.

модуль имя модуля
}

Тело объявления модуля может быть пустым или может содержать различные директивы модуля , в том числе требует , экспортирует , предоставляет … 90 09 с0023, использует , а открывает (каждый из которых мы обсуждаем). Как вы увидите позже, компиляция объявления модуля создает дескриптор модуля, который хранится в файле с именем module-info.class в корневой папке модуля. Здесь мы кратко представляем каждую директиву модуля. После этого мы представим фактические объявления модулей.

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

требуется. Директива модуля требует указывает, что этот модуль зависит от другого модуля — эта связь называется зависимостью модуля . Каждый модуль должен явно указывать свои зависимости. Когда модуль А требует модуль B, модуль A считается считываемым модулем B, а модуль B считывается модулем A. Чтобы указать зависимость от другого модуля, используйте требует , например:

требует имя модуля ;

Существует также директива require static , указывающая, что модуль требуется во время компиляции, но является необязательным во время выполнения. Это известно как необязательная зависимость и не будет обсуждаться в этом введении.

требует переходной — подразумеваемой удобочитаемости . Чтобы указать зависимость от другого модуля и убедиться, что другие модули, читающие ваш модуль, также читают эту зависимость (известную как подразумеваемая читаемость ), используйте требует транзитивного , например:

требует транзитивного имя_модуля ;

Рассмотрим следующую директиву из объявления модуля java.desktop :

требует транзитивного java.xml ;

В этом случае любой модуль, который читает java.desktop , также неявно читает java.xml . Например, если метод из модуля java.desktop возвращает тип из модуля java.xml , код в модулях, которые читают java.desktop , становится зависимым от java.xml . Без требует транзитивной директивы в объявлении модуля java.desktop , такие зависимые модули не будут компилироваться, если они не будут явно читать java. xml .

В соответствии с JSR 379 стандартные модули Java SE должны обеспечивать подразумеваемую читаемость во всех случаях, подобных описанному здесь. Кроме того, хотя стандартный модуль Java SE может зависеть от нестандартных модулей, он не должен предоставлять им подразумеваемую читаемость. Это гарантирует переносимость кода, зависящего только от стандартных модулей Java SE, между реализациями Java SE.

экспорт и экспорт… в. Ан экспорт 9Директива модуля 0023 указывает один из пакетов модуля, чьи типы public (и их вложенные типы public и protected ) должны быть доступны для кода во всех других модулях. Директива exports…to позволяет указать в списке, разделенном запятыми, код какого модуля или модулей может получить доступ к экспортируемому пакету — это называется экспортом с указанием .

использования. Директива модуля uses определяет службу, используемую этим модулем, что делает модуль потребителем службы. А сервис — это объект класса, который реализует интерфейс или расширяет абстрактный класс , указанный в директиве use .

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

открывать, открывать и открывать… до. До Java 9 отражение можно было использовать для изучения всех типов в пакете и всех членов типа — даже его частных членов — независимо от того, хотели вы разрешить эту возможность или нет. Таким образом, ничего не было действительно инкапсулировано.

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

Разрешение доступа к пакету только во время выполнения. Директива модуля opens вида

открывает пакет

указывает, что конкретный Пакет 's общедоступные типы (и их вложенные общедоступные и защищенные типы ) доступны для кода в других модулях только во время выполнения. Кроме того, все типы в указанном пакете (и все члены типов) доступны через отражение.

Разрешение доступа к пакету только во время выполнения для определенных модулей. Директива модуля open…to вида

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

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

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

открыть модуль имя модуля {
   // директивы модуля

Отражение по умолчанию типы public
(и их вложенные типы public и protected ). Однако код в других модулях может получить доступ к всем типам в открытом пакете и ко всем членам этих типов, включая частные члена через setAccessible , как в более ранних версиях Java.

Дополнительные сведения о setAccessible и отражении см. в документации Oracle.


Пол Дейтель, Генеральный директор и главный технический директор Deitel & Associates, выпускник Массачусетского технологического института с 35-летним опытом работы в области вычислительной техники.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *