Содержание

Рекурсивная связь — Энциклопедия по экономике

Рекурсивная связь позволяет определить, какое явление, происходящее в системе, причина, а какое — следствие, какая в системе величина аргумент, а какая — функция.  [c.32]

Одним из случаев успешного применения МНК для оценки структурных коэффициентов модели является его использование для рекурсивных (треугольных) моделей. В этих моделях эндогенные переменные последовательно (рекурсивно) связаны друг с другом. А именно, первая эндогенная переменная YI зависит лишь от экзогенных переменных Хь i = 1, 2,. .., m и случайного отклонения Si. Вторая эндогенная переменная Y2 определяется лишь значениями экзогенных переменных Х i = 1, 2,. .., m случайным отклонением 82, а также эндогенной переменной YI. Третья эндогенная переменная Y3 зависит от тех же переменных, что и Y2, случайного отклонения з, а также от предыдущих эндогенных переменных (Yi, Y2) и т. д.  [c.326]

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

Здесь j указывает на объясняющую переменную, связь которой с объясняемой переменной / раскрывается в структурной модели, к пробегает по подмножеству всех переменных, непосредственно влияющих на j-ю переменную (на графе эти вершины связаны с вершиной / дугами). Соотношение (4.20) справедливо для любой рекурсивной системы.  [c.221]

Модель включает как рекурсивные, так и одновременно решаемые уравнения, причем наличие последних позволяет учесть и некоторые обратные связи процесса энергопотребления. Это делает модель адекватной реальным взаимосвязям, что, в свою очередь, повышает надежность и достоверность прогнозных расчетов.  [c.201]

Возникает задача вычислительной оценки с предварительным исключением абсурдных и неконкурентоспособных вариантов. Методы решения такой задачи находим, например в [31 ]. В основу их положен принцип представления процесса решения в виде многоступенчатой структуры. Каждая ступень связана с проверкой наличия тех или иных свойств у подмножества вариантов, по которым либо непосредственно сокращается исходное множество, либо подготавливается возможность такого сокращения в будущем. Одним из правил отсева бесперспективных вариантов является принцип монотонной рекурсивности, применяемый для решения задач дискретной оптимизации при пошаговом конструировании вариантов.  [c.169]

Необходимость рассматривать системы, отличные от рекурсивных, возникает в связи с тем, что исследователь обычно располагает некоторыми усредненными (агрегированными) данными. Например, данные о рыночной конъюнктуре могут быть усреднены по недельным или месячным периодам. Предположим, что известны величины Pt — средняя цена за неделю t и Qt — средний объем ежедневных продаж за неделю /. Если считать время реакции рынка, как и раньше, равным одному дню, то соотношение Pt = a0 + a j. + UL вряд ли можно признать разумным. В этой ситуации рассмотренная в 14.1 модель представляется более естественной.  [c.414]

Связи могут быть синергетическими и рекурсивными.  [c.32]

МОДЕЛЬ РЕКУРСИВНАЯ — одна из эконометрических моделей, в которой причинно-следственные связи эндогенных переменных находятся в строгой односторонней последовательности. В данной модели матрица параметров представлена в виде треугольника, а отклонения случайных величин не находятся в прямой или обратной корреляции.  [c.385]

Эта модель рекурсивна, так как pt и qt — текущие значения эндогенных переменных, а t-i — предопределенная переменная, участвующая в последовательности причинных связей  [c.379]

РЕКУРСИВНАЯ СВЯЗЬ [ re ursive relation] — необходимая связь между экономическими явлениями и объектами, при которой ясно, где причина и где следствие. Напр., затраты в экономике всегда выступают в качестве причины, а их результаты— в качестве следствия. Между затратами и результатами Р.с.  [c.307]

РЕКУРСИВНАЯ СВЯЗЬ (re ursive link) — вид связей в системе, при котором ясно, какое явление является причиной и какое — следствием, какая величина является аргументом и какая — ф-цией  [c.220]

И последнее модель может быть включена в качестве составной части в многосетевую среду принятия решений, а полученная общая производительность — измеряться, исходя из заданного решающего правила (см. [290]). Наконец, более динамичные подходы можно получить, используя рекурсивные сети с механизмами обратной связи.  [c.227]

Методы корреляций и регрессий создавались как методы описания совместных изменений двух и более переменных. Совместные изменения переменных могут не означать наличия причинных связей между ними. Потребность в причинном объяснении корреляции привела американского генетика С. Райта к созданию метода путевого анализа (1910—1920) как одного из разновидностей структурного моделирования. Путевой анализ основан на изучении всей структуры причинных связей между переменными, т. е. на построении графа связей и изоморфной ему рекурсивной системы уравнений. Его основным положением является то, что оценки стандартизированных коэффициентов рекурсивной с истемы уравнений, которые интерпретируются как коэффициенты влияния (путевые коэффициенты), рассчитываются на основе коэффициентов парной корреляции. Это позволяет проанализировать структуру корреляционной связи с точки зрения причинности. Каждый коэффициент парной корреляции рассматривается как мера полной связи двух переменных.  [c.18]

Для формальной верификации гипотез необходимо соответствие между графом и системой уравнений, его описывающей. Алгебраическая система, соответствующая графу без контуров (петель), является рекурсивной системой, позволяющей рекур-рентно определять значения входящих в нее переменных. В такой системе в уравнения для признака xt включаются все переменные, за исключением расположенных выше его по графу связей. Формулировка гипотез в структуре рекуррентной модели обычно не вызывает затруднений при использовании данных в динамике. Если же анализируются статистические данные, то следует учитывать зависимость системы от ее прошлых состояний.  [c.213]

СВЯЗИ В СИСТЕМЕ [system linkages] — то, что объединяет элементы системы в одно целое. Связи между элементами системы могут быть жесткими (таковы они обычно в технике) и гибкими, изменяющимися в процессе функционирования системы (таковы они в живых существах, в экономике, в обществе), а также непосредственными и опосредованными. С точки зрения кибернетики связь — это относительно устойчивый процесс обмена информацией, который регулирует поведение систем (т.е. управляет ими). Наиболее важными считаются следующие виды связей прямые, обратные, рекурсивные, синергические и циклические.  [c.317]

СВЯЗИ (в системе) (system links) — отношения общности и взаимной зависимости, объединяющие элементы системы в одно целое С между элементами системы могут быть жесткими и гибкими, изменяющимися в процессе функционирования системы, а также непосредственными и опосредованными К оси видам С относятся прямая С, обратная С, рекурсивная С, синергическая С и циклическая С  [c.228]

Программа SEE Гузмана в соответствии с геометрией соединений линий устанавливает связи между областями этих соединений. (Связи устанавливаются также и между областями, которые не являются соседними. Для этого необходимо, чтобы в каждой области были соединения линий, удовлетворяющие специальным критериям сходства.) Две области (или, следуя рекурсивному определению, ядра) образуют ядро, если между ними установлено не менее двух связей. В конечном итоге ядра отождествляются с телами. Таким образом, в рамках программы телом считается совокупность областей, характер объединения которых выражен связями . В описанном здесь алгоритме в явном виде определено, что представляют собой эти объединения это дало возможность сформулировать более детальные описания сцены. Важное отличие данной работы состоит в выяснении того обстоятельства, что характеризующие тела объединения — это объединения не областей, а поверхностей, которые на рисунке выражены этими областями. Гузман вообще не различает термины поверхность и область .  [c.122]

И главный фактор успеха здесь — это понимание того, что такое рациональное инвестиционное поведение, плюс качественная и количественная математическая модель такого поведения. Много сил в науке было отдано тому, чтобы описать рациональный инвестиционный выбор (например, через функцию инвестиционной полезности). Однако, если исследование аспектов рационального инвестиционного поведения не опирается на детальный анализ фондового рынка и макроэкономической обстановки в стране, где осуществляются инвестиции, то такой анализ рационального инвестиционного поведения является бесполезным. А в такой постановке задача практически не звучит. Приятным исключением является подход, применяемый компанией Latti e Finan ial [129], где прослеживается детальная модельная связь между макроэкономическими факторами и количественными оценками тенденций фондового рынка. Но здесь другая крайность слишком велика в моделях [129] доля механистического понимания связей на макро- и микроуровне, когда возникает прямой соблазн рекурсивного прогнозирования , где будущее с точностью до вероятностно расред елейного случайного сигнала определяется настоящим. Фактор рационализации выбора совершенно выпадает из моделей такого сорта.  [c.95]

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

I am getting this error because I try to INSERT into a table but the foreign key has no other entries to refer to because I am trying to make a recursive relationship in MySQL workbench. It looks like this:

It is a relationship between the user table and the message table.

A message entry needs to have a from_id and a to_id to be able to know who sent to who. That is fine. But then I needed a recursive relationship on the message table where a message could be a reply to another message, but it does not have to be a reply because the first message can never be a reply to another message because it is the first message. So When I try to insert into this table I get this error:

#1452 - Cannot add or update a child row: a foreign key constraint fails (`message`, CONSTRAINT `fk_message_message1` FOREIGN KEY (`reply_to`) REFERENCES `message` (`id`) ON DELETE NO ACTION ON UPDATE NO ACTION) 

Here is the message table:

CREATE TABLE IF NOT EXISTS `message` (
     `id`              INT(11) UNSIGNED NOT NULL AUTO_INCREMENT COMMENT '',
     `message` TEXT    NOT NULL COMMENT '',
     `reply_to`        INT(11) UNSIGNED NOT NULL DEFAULT '1' COMMENT '',
     `from_id`         INT(11) UNSIGNED NOT NULL COMMENT '',
     `to_id`           INT(11) UNSIGNED NOT NULL COMMENT '',
     `is_active`       INT(1) NOT NULL DEFAULT '1' COMMENT '',
     `sent_time`       INT(11) UNSIGNED NOT NULL COMMENT '',
     `is_viewed`       INT(1) NOT NULL DEFAULT '0' COMMENT '',
     PRIMARY KEY (`id`)  COMMENT '',
     INDEX `from_id` (`from_id` ASC)  COMMENT '',
     INDEX `to_id` (`to_id` ASC)  COMMENT '',
     INDEX `sent_time` (`sent_time` ASC)  COMMENT '',
     INDEX `reply_to` (`reply_to` ASC)  COMMENT '',
     CONSTRAINT `fk_message_user1`
       FOREIGN KEY (`from_id`)
       REFERENCES `user` (`id`)
       ON DELETE CASCADE
       ON UPDATE NO ACTION,
     CONSTRAINT `fk_message_user2`
       FOREIGN KEY (`to_id`)
       REFERENCES `user` (`id`)
       ON DELETE CASCADE
       ON UPDATE NO ACTION,
     CONSTRAINT `fk_message_message1`
       FOREIGN KEY (`reply_to`)
       REFERENCES `message` (`id`)
       ON DELETE NO ACTION
       ON UPDATE NO ACTION)
ENGINE = InnoDB
DEFAULT CHARACTER SET = utf8

Now I know what the problem is, but I do not have a solution. I want to be able to model the db like showed in the picture with recursive relationship. So that others can see the recursive relationship and understand that it exists. But When I synchronize on Mysql workbench then the constraint gets added to the database and now I can not do inserts on the message table.

How should I solve this?

Справочник по полям модели — Документация Django 1.8

Параметры поля

Приведенные аргументы доступны для всех полей. Все они не обязательны.

null

Field.null

При True Django сохранит пустое значение как NULL в базе данных. Значение по умолчанию – False.

Избегайте использования null для строковых полей таких, как CharField и TextField, т.к. пустое значение всегда будет сохранено как пустая строка, а не NULL. Если строковое поле содержит null=True, это означает, что оно может содержать два возможных “пустых” значения: NULL и пустую строку. В большинстве случаев избыточно иметь два варианты “пустых” значений. Правило Django использовать пустую строку, вместо NULL.

Для всех типов полей, вы также должны указать blank=True если вы хотите разрешить пустые значения в формах, т.к. параметр null влияет только на сохранение в базе данных (смотрите blank).

Примечание

При использовании Oracle, NULL будет использоваться для пустой строки независимо от значения этого параметра.

Если хотите использовать null для BooleanField, используйте NullBooleanField вместо этого.

blank

Field.blank

При True поле может быть пустым. Значение по умолчанию – False.

Заметим что этот параметр отличается от null. null указывается для базы данных, в то время как blank – для проверки данных. При blank=True, проверка данных в форме позволит сохранять пустое значение в поле. При blank=False поле будет обязательным.

choices

Field.choices

Итератор (например, список или кортеж) двухэлементных кортежей(например, [(A, B), (A, B) …]), который будет использоваться как варианты значений для поля. Если этот параметр указан, в форме будет использоваться select для этого поля.

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

YEAR_IN_SCHOOL_CHOICES = (
    ('FR', 'Freshman'),
    ('SO', 'Sophomore'),
    ('JR', 'Junior'),
    ('SR', 'Senior'),
)

Значения лучше указать в константах внутри модели:

from django.db import models

class Student(models.Model):
    FRESHMAN = 'FR'
    SOPHOMORE = 'SO'
    JUNIOR = 'JR'
    SENIOR = 'SR'
    YEAR_IN_SCHOOL_CHOICES = (
        (FRESHMAN, 'Freshman'),
        (SOPHOMORE, 'Sophomore'),
        (JUNIOR, 'Junior'),
        (SENIOR, 'Senior'),
    )
    year_in_school = models.CharField(max_length=2,
                                      choices=YEAR_IN_SCHOOL_CHOICES,
                                      default=FRESHMAN)

    def is_upperclass(self):
        return self.year_in_school in (self.JUNIOR, self.SENIOR)

Можно указать список значений и не в модели, но так все данные будут связаны с моделью, и к значениям можно легко обратиться (например, Student.SOPHOMORE можно использовать импортировав модель Student).

Вы можете сгруппировать значения в именованные группы:

MEDIA_CHOICES = (
    ('Audio', (
            ('vinyl', 'Vinyl'),
            ('cd', 'CD'),
        )
    ),
    ('Video', (
            ('vhs', 'VHS Tape'),
            ('dvd', 'DVD'),
        )
    ),
    ('unknown', 'Unknown'),
)

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

Для каждой модели с полем содержащим choices, Django добавляет метод для получения названия текущего значения поля. Смотрите get_FOO_display() в документации про API для работы с базой данных.

Отметим что в качестве списка вариантов значений может быть любой итератор – не обязательно список или кортеж. Это позволяет определять варианты значений динамически. Но, если вам необходимо использовать динамический choices, возможно вам следует использовать правильную структуру таблицы базы данных с ForeignKey. choices предназначен для статических данных, которые почти или вообще не изменяются.

Добавлено в Django 1.7.

Если поле содержит blank=False, но default не определен, в поле выбора будет добавлено значение с названием «———«. Чтобы это изменить, добавьте в choices элемент с None, например, (None, ‘Your String For Display’). Также можно использовать пустую строку вместо None, где это имеет смысл, например, для CharField.

db_column

Field.db_column

Имя колонки в базе данных для хранения данных этого поля. Если этот параметр не указан, Django будет использовать название поля.

Если имя колонки это зарезервированное SQL слово, или содержит символы запрещенные в названиях переменной в Python – в частности, дефис – все нормально. Django автоматически экранирует название колонок и таблиц.

db_index

Field.db_index

При True, django-admin sqlindexes добавит CREATE INDEX для этого поля.

db_tablespace

Field.db_tablespace

Имя “tablespace” базы данных используемое для индекса поля, если поле имеет индекс. По-умолчанию используется значение настройки DEFAULT_INDEX_TABLESPACE проекта, если оно указано, иначе db_tablespace модели. Если база данных не поддерживает “tablespace” для индексов, этот параметр будет проигнорирован.

default

Field.default

Значение по умолчанию для поля. Это может быть значение или вызываемый(callable) объект. Если это вызываемый объект, он будет вызван при создании нового объекта.

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

def contact_default():
    return {"email": "[email protected]"}

contact_info = JSONField("ContactInfo", default=contact_default)

Обратите внимание, lambda нельзя использовать в качестве значения для default т.к. она не может быть сериализована для миграций. Подробности смотрите в соответствующем разделе.

Значение по умолчанию используется, если был создан экземпляр модели, а значение для поля не было указано. Если поле является первичным ключом, значение по умолчанию также использует и при указании None.

Изменено в Django 1.8:

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

editable

Field.editable

При False, поле не будет отображаться в админке или любой другой ModelForm для модели. Такие поля также пропускаются при валидации модели. Значение по умолчанию – True.

error_messages

Field.error_messages

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

Ключи ошибок такие: null, blank, invalid, invalid_choice, unique и «unique_for_date`. Дополнительные ошибки указаны для каждого типа поля ниже.

Добавлено в Django 1.7.

Было добавлено сообщение об ошибке unique_for_date.

help_text

Field.help_text

Подсказка, отображаемая под полем в интерфейсе администратора. Это полезно для описания поля, даже если модель не используется в форме.

Заметим, что, при отображении в форме, HTML-символы не экранируются. Это позволяет использовать HTML в help_text если вам необходимо. Например:

help_text="Please use the following format: <em>YYYY-MM-DD</em>."

Также вы можете использовать обычный текст и django.utils.html.escape(), чтобы экранировать HTML. Убедитесь, что вы экранируете все подсказки, которые могут определять непроверенные пользователи, чтобы избежать XSS атак.

primary_key

Field.primary_key

При True это поле будет первичным ключом.

Если вы не укажите primary_key=True для какого-либо поля в модели, Django самостоятельно добавит AutoField для хранения первичного ключа, вы не обязаны указывать primary_key=True, если не хотите переопределить первичный ключ по умолчанию. Подробнее смотрите Первичный ключ по умолчанию.

primary_key=True подразумевает null=False и unique=True. Модель может содержать только один первичный ключ.

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

unique

Field.unique

При True значение поля должно быть уникальным.

Этот параметр учитывается при сохранении в базу данных и при проверке данных в модели. Если вы попытаетесь сохранить повторное значение в поле с unique, будет вызвана ошибка django.db.IntegrityError методом save().

Этот параметр можно использовать для любого типа поля кроме ManyToManyField, OneToOneField и FileField.

Заметим что, при unique равном True, не нужно указывать db_index, т.к. unique создает индекс.

unique_for_date

Field.unique_for_date

Этот параметр должен быть равен названию DateField или DateTimeField поля, для которого значение должно быть уникальным.

Например, если модель имеет поле title с unique_for_date=»pub_date», тогда Django позволит сохранять записи только с уникальной комбинацией title и pub_date.

Если указать этот параметр для DateTimeField, только дата значения будет учитываться. Но при USE_TZ равном True, проверка будет выполнена в текущем часовом поясе во время сохранения объекта.

Проверка выполняется методом Model.validate_unique() во время валидации модели, не на уровне базы данных. Если unique_for_date содержит поля, которые не входят в ModelForm (например, поле было указанно в exclude или содержит editable=False), Model.validate_unique() не будет выполнять эту валидацию.

unique_for_month

Field.unique_for_month

Аналогично unique_for_date, но значение будет уникально для месяца.

verbose_name

Field.verbose_name

Отображаемое имя поля. Если параметр не указан, Django самостоятельно создаст его используя имя атрибута поля, заменяя подчеркивание на пробелы. Смотрите раздел про отображаемые имена полей.

validators

Field.validators

Список проверок(“валидаторов”) выполняемых для этого поля. Смотрите раздел о “валидаторах” для подробной информации.

Типы полей

AutoField

class AutoField(**options)

Автоинкрементное поле IntegerField. Используется для хранения ID. Скорее всего вам не придется использовать это поле, первичный ключ будет автоматически добавлен к модели. Смотрите Первичный ключ по умолчанию.

BigIntegerField

class BigIntegerField([**options])

64-битное целочисленное, аналогично IntegerField но позволяет хранить числа от -9223372036854775808 до 9223372036854775807. Форма будет использовать TextInput для отображения.

BinaryField

class BinaryField([**options])

Поля для хранения бинарных данных. Принимает значение типа bytes. Это поле имеет ограниченный функционал. Например, QuerySet нельзя фильтровать по значению BinaryField.

Злоупотребление BinaryField

Помните, хранение файлов в базе данных в 99% случаях — это плохой подход. Это поле не замена статическим файлам.

BooleanField

class BooleanField(**options)

Поле хранящее значение true/false.

Виджет по умолчанию для этого поля CheckboxInput.

Если вам нужен параметр null, используйте поле NullBooleanField.

Значение по умолчанию для BooleanField None, если Field.default не указан.

CharField

class CharField(max_length=None[, **options])

Строковое поле для хранения коротких или длинных строк.

Для большого количества текстовой информации используйте TextField.

Виджет по умолчанию для этого поля TextInput.

CharField принимает один дополнительный аргумент:

CharField.max_length

Максимальная длинна(в символах) этого поля. max_length используется для проверки данных на уровне базы данных и форм Django.

Примечание

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

Пользователям MySQL

Если вы используете это поле с MySQLdb 1.2.2 и utf8_bin “collation” (которое не является значением по умолчанию), могут быть некоторые проблемы. Смотрите советы при работе с MySQL для подробностей.

CommaSeparatedIntegerField

class CommaSeparatedIntegerField(max_length=None[, **options])

Поле, содержащее целые числа разделенные запятыми. Как и в CharField, необходим параметр max_length. Упомянутые особенности работы с различными типами баз данных актуальны.

DateField

class DateField([auto_now=False, auto_now_add=False, **options])

Дата, представленная в виде объекта datetime.date Python. Принимает несколько дополнительных параметров:

DateField.auto_now

Значение поля будет автоматически установлено в текущую дату при каждом сохранении объекта. Полезно для хранения времени последнего изменения. Заметим, что текущее время будет использовано всегда; это не просто значение по умолчанию, которое вы можете переопределить.

DateField.auto_now_add

Значение поля будет автоматически установлено в текущую дату при создании(первом сохранении) объекта. Полезно для хранения времени создания. Заметим, что текущее время будет использовано всегда; это не просто значение по-умолчанию, которое вы можете переопределить.

В форме поле будет представлено как :class:`~django.forms.TextInput с JavaScript календарем, и кнопкой “Сегодня”. Содержит дополнительную ошибку invalid_date.

Опции auto_now_add, auto_now и default взаимоисключающие. Использование их вместе вызовет ошибку.

Примечание

При использовании auto_now или auto_now_add со значением True будут установлены параметры editable=False и blank=True.

Примечание

Опции«auto_now« и auto_now_add всегда используют дату в часовом поясе по умолчанию в момент создания или изменения объекта. Если такое поведение вам не подходит, вы можете указать свою функцию как значение по умолчанию, или переопределить метод save(), вместо использования auto_now или auto_now_add. Или использовать DateTimeField вместо DateField и выполнять преобразование в дату при выводе значения.

DateTimeField

class DateTimeField([auto_now=False, auto_now_add=False, **options])

Дата и время, представленные объектом datetime.datetime Python. Принимает аналогичные параметры что и DateField.

Виджет по умолчанию в форме для этого поля — TextInput. Интерфейс администратора использует два виджета TextInput и JavaScript.

DecimalField

class DecimalField(max_digits=None, decimal_places=None[, **options])

Десятичное число с фиксированной точностью, представленное объектом Decimal Python. Принимает два обязательных параметра:

DecimalField.max_digits

Максимальное количество цифр в числе. Заметим, что это число должно быть больше или равно decimal_places.

DecimalField.decimal_places

Количество знаков после запятой.

Например, для хранения числа до 999 с двумя знаками после запятой, используйте:

models.DecimalField(..., max_digits=5, decimal_places=2)

Для хранения числа до миллиарда и 10 знаков после запятой:

models.DecimalField(..., max_digits=19, decimal_places=10)

Виджет по умолчанию для этого поля TextInput.

DurationField

Добавлено в Django 1.8.

class DurationField([**options])

Поля для хранения периодов времени — используется объект Python timedelta. Для PostgreSQL используется тип interval, а в Oracle – INTERVAL DAY(9) TO SECOND(6). Иначе используется bigint, в котором хранится количество микросекунд.

Примечание

Арифметика над DurationField работает в большинстве случаев. Однако, для всех баз данных, кроме PostgreSQL, арифметическое сравнение DurationField и DateTimeField работает не как ожидается.

EmailField

class EmailField([max_length=254, **options])

Поле CharField для хранения правильного email-адреса. Использует EmailValidator для проверки значения.

Изменено в Django 1.8:

Значение max_length по умолчанию было увеличено с 75 до 254 для совместимости с RFC3696/5321.

FileField

class FileField([upload_to=None, max_length=100, **options])

Поле для загрузки файла.

Примечание

primary_key и unique не принимаются, и вызовут исключение TypeError при использовании.

Также принимается два дополнительных параметра:

FileField.upload_to
Изменено в Django 1.7:

upload_to был обязателен в предыдущих версиях Django.

Путь в файловой системе относительно значения настройки MEDIA_ROOT для определения url.

Поддерживает форматирование strftime(), которое будет заменено на дату/время загруженного файла (и загружаемые файлы не заполнят один каталог).

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

Аргумент

Описание

instance

Экземпляр модели, для которой определено поле FileField. Точнее, это объект, для которого сохраняется текущий файл.

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

filename

Оригинальное имя файла. Вы можете его учитывать, или проигнорировать при определении окончательного пути к файлу.

FileField.storage

Объект “storage”, который отвечает за хранение и получение файлов. Смотрите Управление файлами для подробной информации.

Виджет форма для этого поля — ClearableFileInput.

Использование FileField или ImageField (смотрите ниже) требует некоторых дополнительных действий:

  1. В файле настроек необходимо определить MEDIA_ROOT, как полный путь к каталогу, куда Django должен сохранять файлы. (Для повышения производительности файлы не хранятся в базе данных.) Определить MEDIA_URL, который является URL-ом к этому каталогу и используется для создания URL-а к файлу. Убедитесь, что пользователь, от которого работает сервер, имеет права записи в этот каталог.

  2. Добавьте FileField или ImageField к модели, определите upload_to, чтобы указать Django в каком подкаталоге в MEDIA_ROOT должны быть сохранены файлы.

  3. Все, что будет сохранено в базе данных, это путь к файлу (относительно MEDIA_ROOT). Скорее всего вы будете использовать url предоставленную Django. Например, если ImageField назван mug_shot, вы можете получить URL к файлу в шаблоне используя {{ object.mug_shot.url }}.

Например, MEDIA_ROOT равен ‘/home/media’, и upload_to равен ‘photos/%Y/%m/%d’. ‘%Y/%m/%d’ часть параметра upload_to это форматирование strftime(); ‘%Y’ – год из 4-х цифр, ‘%m’ – номер месяца из 2-х цифр и ‘%d’ – число месяца из 2-х цифр. Если вы загрузили файл 15 января 2007, он будет сохранен в каталоге /home/media/photos/2007/01/15.

Если вам нужны название файла или его размер, используйте атрибуты name и size соответственно; больше информации о доступных методах и атрибутах вы найдете в справке о File и разделе документации Управление файлами.

Примечание

Процесс сохранения файла – часть процесса сохранения объекта, таким образом имя файла, сохраненного на диске, не будет доступно, пока объект не будет сохранен.

Чтобы получить URL к загруженному файлу, используйте атрибут url. При этом будет вызван метод url() класса Storage.

Заметим, что при загрузке файлов, вы должны обращать внимание, куда вы загружаете файлы и какие типы файлов загружаются, чтобы предотвратить возможные уязвимости в защите системы. Проверяйте все загружаемые файлы. Например, если вы разрешите загрузить файл без проверки в каталог, который обрабатывается сервером, кто-нибудь сможет загрузить CGI или PHP скрипт и выполнить его, посетив его URL на вашем сайте. Не допускайте это.

Также заметим что это относится и к HTML файлам, так как они могу быть выполнены в браузере(хоть и не на сервере), и нести угрозу XSS или CSRF атаки.

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

FileField и FieldFile
class FieldFile

При доступе к FileField модели, вы получаете экземпляр FieldFile как “proxy” для работы с файлом. Этот класс содержит несколько дополнительных атрибутов и методов для работы с файлом, кроме унаследованных от django.core.files.File:

FieldFile.url

read-only свойство для получения URL вызовом метода url() класса Storage.

FieldFile.open(mode=’rb’)

Работает так же как и родной метод Python open() – открывает файл, связанный с объектом, в режиме определенном аргументом mode.

FieldFile.close()

Работает так же как и метод file.close() в Python и закрывает файл связанный с объектом.

FieldFile.save(name, content, save=True)

Этот метод принимает имя файла и содержимое и передает его в экземпляр класса “storage” этого поля, потом добавляет файл в модель. Если вы хотите самостоятельно добавить содержимое файла в поле FileField вашей модели, метод save() то, что вам нужно.

Принимает два аргумента: name – название файла, и content – содержимое файла. Дополнительный аргумент save указывает сохранять ли объект после изменения поля. По-умолчанию True.

Заметим, что аргумент content должен быть экземпляром django.core.files.File, а не встроенный объект файла в Python. Вы можете создать объект File из существующего объекта файла Python:

from django.core.files import File
# Open an existing file using Python's built-in open()
f = open('/tmp/hello.world')
myfile = File(f)

Или же создать из строки с содержимым файла:

from django.core.files.base import ContentFile
myfile = ContentFile("hello world")

Подробности в Управление файлами.

FieldFile.delete(save=True)

Удаляет файл связанный с объектом и очищает все атрибуты поля. Заметка: этот метод закрывает файл, если он был открыт во время вызова delete().

Дополнительный аргумент save указывает сохранять ли модель после удаления файла. По-умолчанию True.

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

FilePathField

class FilePathField(path=None[, match=None, recursive=False, max_length=100, **options])

Поле CharField значение которого ограничено именем файла из определенного каталога. Принимает три дополнительных аргумента, первый из них обязателен:

FilePathField.path

Обязательно. Абсолютный путь к каталогу, из которого FilePathField принимает значение. Например: «/home/images».

FilePathField.match

Необязательный. Регулярное выражение как строка, которое FilePathField использует как фильтр названий. Регулярное выражение применяется к названию файла, а не к полному пути. Например: «foo.*\.txt$», соответствует foo23.txt но отфильтрует bar.txt или foo23.gif.

FilePathField.recursive

Необязательный. Принимает True или False. По-умолчанию False. Определяет, должны ли быть включены подкаталоги path.

FilePathField.allow_files

Необязательный. Принимает True или False. По-умолчанию True. Определяет, должны ли быть включены указанные подкаталоги. Этот параметр или allow_folders должен быть True.

FilePathField.allow_folders

Необязательный. Принимает True или False. По-умолчанию False. Определяет, должны ли быть включены указанные подкаталоги. Этот параметр или allow_files должен быть True.

Конечно же можно использовать все аргумента вместе.

Следует помнить, что match применяется к имени файла, а не абсолютному пути. Таким образом:

FilePathField(path="/home/images", match="foo.*", recursive=True)

…распознает /home/images/foo.png, но не /home/images/foo/bar.png, т.к. match применяется к имени файла (foo.png и bar.png).

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

FloatField

class FloatField([**options])

Число с плавающей точкой представленное объектом float.

Виджет по умолчанию для этого поля TextInput.

FloatField или DecimalField

FloatField иногда путают с DecimalField. Хоть оба и представляют вещественные числа, они делают это по разному. FloatField использует тип float в Python, в то время как DecimalField использует тип Decimal. Подробности смотрите в документации Python модуля decimal.

ImageField

class ImageField([upload_to=None, height_field=None, width_field=None, max_length=100, **options])

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

В дополнение к атрибутам поля FileField ImageField содержит также height и width.

Для определения этих аргументов ImageField принимает дополнительные аргументы:

ImageField.height_field

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

ImageField.width_field

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

Требуется библиотека Pillow.

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

Виджет форма для этого поля — ClearableFileInput.

IntegerField

class IntegerField([**options])

Число. Значение от -2147483648 до 2147483647 для всех поддерживаемых баз данных Django. Форма использует виджет TextInput.

IPAddressField

class IPAddressField([**options])

Не рекомендуется, начиная с версии 1.7: Это поле устарело. Используйте GenericIPAddressField.

IP адрес в виде строки(например, “192.0.2.30”). Форма использует виджет TextInput.

GenericIPAddressField

class GenericIPAddressField([protocol=both, unpack_ipv4=False, **options])

Адрес IPv4 или IPv6 в виде строки (например, 192.0.2.30 или 2a02:42fe::4). Форма использует виджет TextInput.

Преобразование адреса IPv6 происходит в соответствии с RFC 4291 раздел 2.2, включая рекомендации по форматированию IPv4 в параграфа 3 этого раздела, таких как ::ffff:192.0.2.0. Например, 2001:0::0:01 будет преобразован 2001::1, а ::ffff:0a0a:0a0a в ::ffff:10.10.10.10. Все символы будут преобразованы в нижний регистр.

GenericIPAddressField.protocol

Определяет формат IP адреса. Принимает значение ‘both’ (по умолчанию), ‘IPv4’ или ‘IPv6’. Значение не чувствительно регистру.

GenericIPAddressField.unpack_ipv4

Преобразует адрес IPv4. Если эта опция установлена, адрес ::ffff::192.0.2.1 будет преобразован в 192.0.2.1. По-умолчанию отключена. Может быть использовано, если protocol установлен в ‘both’.

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

NullBooleanField

class NullBooleanField([**options])

Как и BooleanField, но принимает значение NULL. Используете его вместо BooleanField с null=True. Форма использует виджет NullBooleanSelect.

PositiveIntegerField

class PositiveIntegerField([**options])

Как и поле IntegerField, но значение должно быть больше или равно нулю (0). Можно использовать значение от 0 до 2147483647. Значение 0 принимается для обратной совместимости.

PositiveSmallIntegerField

class PositiveSmallIntegerField([**options])

Как и поле PositiveIntegerField, но принимает значения в определенном диапазоне(зависит от типа базы данных). Для баз данных поддерживаемых Django можно использовать значения от 0 до 32767.

SlugField

class SlugField([max_length=50, **options])

Slug – газетный термин. “Slug” – это короткое название-метка, которое содержит только буквы, числа, подчеркивание или дефис. В основном используются в URL.

Как и для CharField, можно указать max_length (упомянутые особенности работы с различными типами баз данных актуальны). Если max_length не указан, Django будет использовать значение 50.

Устанавливает Field.db_index в True, если аргумент явно не указан.

Обычно значение SlugField создается на основе какого-то другого значения(например, название статьи). Это может работать автоматически в интерфейсе администрации благодаря параметру prepopulated_fields.

SmallIntegerField

class SmallIntegerField([**options])

Как и поле IntegerField, но принимает значения в определенном диапазоне(зависит от типа базы данных). Для баз данных поддерживаемых Django можно использовать значения от -32768 до 32767.

TextField

class TextField([**options])

Большое текстовое поле. Форма использует виджет Textarea.

Изменено в Django 1.7:

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

Пользователям MySQL

Если вы используете это поле с MySQLdb 1.2.1p2 и utf8_bin “collation” (которое не является значением по умолчанию), могут быть некоторые проблемы. Смотрите советы при работе с MySQL для подробностей.

TimeField

class TimeField([auto_now=False, auto_now_add=False, **options])

Время, представленное объектом datetime.time Python. Принимает те же аргументы, что и DateField.

Форма использует виджет TextInput. Интерфейс администратора также использует немного JavaScript.

URLField

class URLField([max_length=200, **options])

Поле CharField для URL.

Виджет по умолчанию для этого поля TextInput.

Как подкласс CharField URLField принимает необязательный аргумент max_length. Если вы не укажите max_length, будет использовано значение – 200.

UUIDField

Добавлено в Django 1.8.

class UUIDField([**options])

Поля для сохранения UUID. Использует класс Python UUID. Для PostgreSQL используется тип uuid, иначе char(32).

UUID является хорошей альтернативой AutoField с primary_key. База данных не сгенерирует UUID за вас, по этому следует использовать default:

import uuid
from django.db import models

class MyUUIDModel(models.Model):
    id = models.UUIDField(primary_key=True, default=uuid.uuid4, editable=False)
    # other fields

Обратите внимание, указана функция (без скобок) в default, а не объект UUID.

big-o — Как выводится асимптотическая сложность рекурсивных функций

Я не нашел общего ответа на этот вопрос на веб-сайте

Например

Если у меня есть алгоритм; скажем, двоичный поиск, как мне получить (математически показать) его сложность O(log(n)).

Но в более общем плане как мне получить асимптотическую сложность любого рекурсивного алгоритма?

2

Artemis 10 Авг 2017 в 18:55

2 ответа

Лучший ответ

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

T(N) = [sum of T(N_i) for recursive call i] + [sum of other work done in the function]

Например, двоичный поиск имеет очень простую рекурсивную связь: для каждого рекурсивного вызова 1) пространство поиска уменьшается вдвое и 2) выполняется постоянный объем работы.m)) = 0.

Таким образом, временная сложность равна O(m) = O(log N). (База журнала не имеет значения, как и C, поскольку они оба являются мультипликативными константами)

3

meowgoesthedog 10 Авг 2017 в 16:41

Для наиболее распространенных рекуррентных соотношений ваш ответ — основная теорема. См .: https://en.wikipedia.org/wiki/Master_theorem

Вы также найдете это объяснение в CRLS — Введение в алгоритмы.

0

Bill Province 10 Авг 2017 в 21:12

45618366

bash — Символьная рекурсия ссылки — что заставляет ее «сбрасывать»?

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

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

Теперь, как пользователю, вам иногда хочется знать, где находится этот каталог в дереве каталогов. В большинстве Unix дерево каталогов представляет собой дерево без цикла. То есть существует только один путь от корня дерева (/) к любому заданному файлу. Этот путь обычно называют каноническим.

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

Например, процесс, пытающийся определить, что его текущий каталог — / a / b / c , откроет каталог .. (относительный путь, поэтому .. — это запись в текущем каталоге) и найдите файл типа directory с тем же номером inode, что и . , выясняется, что c совпадает, затем открывается ../ .. и так далее, пока не будет найдено /. Тут нет двусмысленности.

Это то, что функции C getwd () или getcwd () делают или, по крайней мере, делали раньше.

В некоторых системах, таких как современный Linux, есть системный вызов для возврата канонического пути к текущему каталогу, который выполняет этот поиск в пространстве ядра (и позволяет вам найти текущий каталог, даже если у вас нет доступа для чтения ко всем его компонентам. ), и это то, что там вызывает getcwd () . В современном Linux вы также можете найти путь к текущему каталогу через readlink () на / proc / self / cwd .

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

В вашем случае вы можете звонить cd a сколько угодно раз, потому что это символическая ссылка на . , текущий каталог не меняется, поэтому все getcwd () , pwd -P , python -c 'import os; print os.getcwd () ', perl -MPOSIX -le' print getcwd ' вернет вам $ {HOME} .

Так вот, все это усложнили символические ссылки.

символических ссылок разрешают переходы в дереве каталогов. В / a / b / c , если / a или / a / b или / a / b / c является символической ссылкой, то канонический путь / a / b / c будет что-то совсем другое.В частности, запись .. в / a / b / c не обязательно / a / b .

В оболочке Bourne, если вы это сделаете:

  кд / а / б / с
CD ..
  

Или даже:

  cd / a / b / c / ..
  

Нет гарантии, что вы попадете в / a / b .

Так же, как:

  vi /a/b/c/../d
  

не обязательно то же самое, что:

  ви / а / б / д
  

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

Для встроенных команд cd и pwd ( и только для них (хотя также для popd / pushd в оболочках, в которых они есть)) оболочка поддерживает собственное представление о текущем рабочем каталоге. Он хранится в специальной переменной $ PWD .

Когда вы это сделаете:

  кд к / д
  

, даже если c или c / d являются символическими ссылками, а $ PWD содержит / a / b , он добавляет c / d в конец, поэтому $ PWD становится / a / b / с / д .И когда вы это сделаете:

  компакт-диск ../e
  

Вместо chdir ("../ e") , он выполняет chdir ("/ a / b / c / e") .

И команда pwd возвращает только содержимое переменной $ PWD .

Это полезно в интерактивных оболочках, потому что pwd выводит путь к текущему каталогу, который дает информацию о том, как вы туда попали, и пока вы используете только .. в аргументах для cd , а не другие команды, это менее вероятно чтобы вас удивить, потому что cd a; CD .. или cd a / .. обычно вернет вас туда, где вы были.

Теперь $ PWD не изменяется, если вы не сделаете cd . Пока вы в следующий раз не позвоните cd или pwd , многое может произойти, любой из компонентов $ PWD может быть переименован. Текущий каталог никогда не меняется (это всегда один и тот же индексный дескриптор, хотя его можно удалить), но его путь в дереве каталогов может полностью измениться. getcwd () вычисляет текущий каталог каждый раз, когда он вызывается путем обхода дерева каталогов, поэтому его информация всегда точна, но для логического каталога, реализованного оболочками POSIX, информация в $ PWD может стать устаревшей.Таким образом, при запуске cd или pwd некоторые оболочки могут захотеть принять меры против этого.

В этом конкретном случае вы видите разное поведение с разными оболочками.

Некоторые, например ksh93 , полностью игнорируют проблему, поэтому будут возвращать неверную информацию даже после того, как вы позвоните cd (и вы не увидите там поведения, которое вы наблюдаете с bash ).

Некоторые, например bash или zsh , проверяют, что $ PWD все еще является путем к текущему каталогу на cd , но не на pwd .

pdksh проверяет как pwd , так и cd (но при pwd не обновляет $ PWD )

ash (по крайней мере, тот, который есть в Debian) не проверяет, и когда вы делаете cd a , он фактически делает cd "$ PWD / a" , поэтому, если текущий каталог изменился и $ PWD больше не указывает на текущий каталог, он фактически не изменится на каталог и в текущем каталоге, а на тот, который находится в $ PWD (и вернет ошибку, если он не существует).

Если вы хотите поиграть с ним, вы можете:

  кд
mkdir -p a / b
cd a
pwd
мв ~ / а ~ / б
pwd
эхо "$ PWD"
cd b
pwd; echo "$ PWD"; pwd -P # (и обратите внимание на ошибку в ksh93)
  

в различных корпусах.

В вашем случае, поскольку вы используете bash , после cd , bash проверяет, что $ PWD все еще указывает на текущий каталог. Для этого он вызывает stat () для значения $ PWD , чтобы проверить его номер inode и сравнить его с номером ..

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

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

  рм -ф а б
ln -s a b
ln -s b a
  

Без этого защитного устройства при cd a / x системе пришлось бы найти, куда ссылается a , найти его b и символическую ссылку, которая ссылается на a , и это будет продолжаться бесконечно. . Самый простой способ защититься от этого — сдаться после разрешения более чем произвольного количества символических ссылок.

Теперь вернемся к текущему логическому рабочему каталогу и тому, почему это не очень хорошая функция.Важно понимать, что это только для cd в оболочке, а не для других команд.

Например:

  cd - "$ dir" && vi - "$ file"
  

не всегда совпадает с:

  vi - "$ dir / $ file"
  

Вот почему вы иногда обнаруживаете, что люди рекомендуют всегда использовать cd -P в сценариях, чтобы избежать путаницы (вы не хотите, чтобы ваше программное обеспечение обрабатывало аргумент ../x иначе, чем другие команды только потому, что это написано в оболочке вместо другого языка).

Параметр -P должен отключить обработку логического каталога , поэтому cd -P - "$ var" действительно вызывает chdir () для содержимого $ var (по крайней мере, пока $ CDPATH он не установлен, за исключением случая, когда $ var равно - (или, возможно, -2 , +3 … в некоторых оболочках), но это уже другая история). И после cd -P , $ PWD будет содержать канонический путь.

cp — Как рекурсивно копировать каталог с использованием жестких ссылок для каждого файла

POSIXly, вы должны использовать pax в режиме чтения + записи с опцией -l :

  pax -rwlpe -s / A / B / dirA. 

( -pe сохраняет все возможные атрибуты файлов (в данном случае только каталоги), которые копируются, как это делает GNU cp -a ).

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

Во-первых, многие системы на базе GNU / Linux не включают pax по умолчанию (даже если это не необязательная утилита POSIX).

Затем ряд ошибок и несоответствий с некоторыми реализациями вызывает ряд проблем с этим кодом.

  • из-за ошибки Solaris 10 pax (по крайней мере) не работает при использовании -rwl в сочетании с -s . По какой-то причине кажется, что подстановка применяется как к исходному, так и к скопированному пути. Итак, выше, он попытается сделать некоторую ссылку ("dirB / file", "dirB / file") вместо ссылки ("dirA / file", "dirB / file") .
  • на FreeBSD, pax не создает жестких ссылок для файлов типа символическая ссылка (поведение, разрешенное POSIX).Не только это, но также применяется подстановка к целям символических ссылок (поведение , а не , разрешенное POSIX). Так, например, если есть символическая ссылка foo -> AA в dirA , она станет foo -> BA в dirB .

Кроме того, если вы хотите сделать то же самое, но с произвольными путями к файлам, содержимое которых хранится в $ src и $ dst , важно понимать, что pax -rwl - "$ src" "$ dst" создает полную структуру каталогов $ src внутри $ dst (которая должна существовать и быть каталогом).Например, если $ src равно foo / bar , то создается $ dst / foo / bar .

Если вместо этого вы хотите, чтобы $ dst был копией $ src , проще всего сделать это как:

  absolute_dst = $ (umask 077 && mkdir -p - "$ dst" && cd -P - "$ dst" && pwd -P) &&
(cd -P - "$ src" && pax -rwlpe. "$ absolute_dst")
  

(который также может обойти большинство проблем, упомянутых выше, но не сработает, если абсолютный путь $ dst заканчивается символами новой строки).

Теперь это не поможет в системах GNU / Linux, где нет pax .

Интересно отметить, что pax был создан POSIX для объединения функций команд tar и cpio .

cpio — это историческая команда Unix (с 1977 года) в отличие от изобретения POSIX, а также есть реализация GNU (не pax ). Таким образом, хотя это уже не стандартная команда (хотя она была в SUSv2), она по-прежнему очень распространена, и есть основной набор функций, на которые вы обычно можете положиться.

Эквивалент pax -rwl будет cpio -pl . Однако:

  1. cpio принимает список входного файла на stdin, а не аргументы (разделены новой строкой, что означает, что имена файлов с символами новой строки не поддерживаются)
  2. Все файлы должны быть указаны (обычно вы передаете ему вывод find ( find и cpio были разработаны совместно одними и теми же людьми)).
  3. Метаданные
  4. не сохраняются (в некоторых реализациях cpio есть опции для сохранения некоторых, но ничего переносимого).

Так с cpio :

  absolute_dst = $ (umask 077 && mkdir -p - "$ dst" && cd -P - "$ dst" && pwd -P) &&
(cd -P - "$ src" && find. | cpio -pl "$ absolute_dst")
  

Оценка рекурсивной логит-модели на основе каналов и потоков каналов в сети, оснащенной датчиками

Автор

Включено в список:
  • ван Ойен, Тим П.
  • Даамен, Винни
  • Hoogendoorn, Серж П.

Abstract

В этой статье описывается метод оценки параметров рекурсивной логит-модели (RL) на основе ссылок с использованием измерений набора пространственно фиксированных датчиков приближения с ограниченными показателями попаданий, которые могут однозначно идентифицировать людей, например Wi-Fi. Fi-, RFID- или Bluetooth-датчики. Наблюдаемый «маршрут» человека, когда мы фокусируемся на пешеходах в условиях города или события, моделируется как последовательность датчиков, которые идентифицировали человека во время его или ее поездки.Очевидно, что эти «маршруты» содержат большие пробелы, что делает неприменимы традиционные методы оценки. Хотя мы точно не знаем, что происходит внутри этих промежутков, у нас есть некоторые конкретные представления о поведении индивидов между двумя идентификациями; мы знаем с определенной вероятностью, которая связана с частотой срабатывания датчиков, что человек не пересек другой участок датчика между двумя идентификациями. Поэтому в данной статье описывается метод оценки параметров модели RL, в которой конкретно используются эти знания.Эта структура также позволяет нам сформулировать вероятностный метод оценки использования канала, который можно использовать для оценки потоков каналов в сети на основе наблюдений датчиков. Эффективность методологии демонстрируется в моделировании с использованием искусственной сети, после чего методология тестируется на реальном наборе данных, собранных на голландском музыкальном мероприятии.

Рекомендуемая ссылка

  • ван Ойен, Тим П. и Даамен, Винни и Хугендорн, Серж П., 2020. « Оценка рекурсивной логит-модели на основе каналов и потоков каналов в сети, оснащенной датчиками », Транспортные исследования, часть B: методологические, Elsevier, vol.140 (C), страницы 262-281.
  • Обозначение: RePEc: eee: transb: v: 140: y: 2020: i: c: p: 262-281
    DOI: 10.1016 / j.trb.2020.08.003

    Скачать полный текст от издателя

    Поскольку доступ к этому документу ограничен, вы можете поискать его другую версию.

    Ссылки, перечисленные в IDEAS

    1. Менгини Г. и Карраско Н. и Шюсслер Н. и Акхаузен К. В., 2010. « Выбор маршрута велосипедистов в Цюрихе ,» Транспортные исследования, часть A: политика и практика, Elsevier, vol.44 (9), страницы 754-765, ноябрь.
    2. Fosgerau, Mogens & Frejinger, Emma & Karlstrom, Anders, 2013. « Модель выбора маршрута сети на основе канала с неограниченным набором выбора ,» Транспортные исследования, часть B: методологические, Elsevier, vol. 56 (C), страницы 70-80.
      • Fosgerau, Mogens & Frejinger, Emma & Karlstrom, Anders, 2013. « Модель выбора маршрута сети на основе канала с неограниченным набором выбора ,» Бумага MPRA 48707, Университетская библиотека Мюнхена, Германия.
      • Fosgerau, Mogens & Frejinger, Emma & Karlström, Anders, 2013. « Модель выбора маршрута сети на основе канала с неограниченным набором выбора ,» Рабочие документы по экономике транспорта 2013: 10, CTS — Центр транспортных исследований Стокгольма (KTH и VTI).
    3. Mai, Tien & Fosgerau, Mogens & Frejinger, Emma, ​​2015. « Вложенная рекурсивная логит-модель для анализа выбора маршрута ,» Транспортные исследования, часть B: методологические, Elsevier, vol.75 (C), страницы 100-112.
    4. Лу, Вей и Скотт, Даррен М. и Далумпинс, Рон, 2018. « Понимание выбора маршрута велосипедиста для совместного использования с использованием данных GPS: сравнение основных маршрутов и кратчайших путей ,» Журнал транспортной географии, Elsevier, vol. 71 (C), страницы 172-181.
    5. Броуч, Джозеф и Дилл, Дженнифер и Глибе, Джон, 2012 г. « Куда едут велосипедисты? Модель выбора маршрута, разработанная с учетом выявленных данных GPS », Транспортные исследования, часть A: политика и практика, Elsevier, vol.46 (10), страницы 1730-1740.
    6. Тьен Май, Фабиан Бастин и Эмма Фреджингер, 2018. « Метод декомпозиции для оценки моделей выбора маршрута на основе рекурсивного логита ,» Журнал EURO по транспорту и логистике, Springer; EURO — Ассоциация европейских обществ операционных исследований, т. 7 (3), страницы 253-275, сентябрь.
    Полные ссылки (включая те, которые не соответствуют элементам в IDEAS)

    Самые популярные

    Это элементы, которые чаще всего цитируют те же работы, что и эта, и цитируются в тех же работах, что и эта.
    1. Meyer de Freitas, Lucas & Becker, Henrik & Zimmermann, Maëlle & Axhausen, Kay W., 2019. « Моделирование интермодальных путешествий в Швейцарии: рекурсивный логит-подход », Транспортные исследования, часть A: политика и практика, Elsevier, vol. 119 (C), страницы 200-213.
    2. Лю, Шан и Цзян, Хай и Чен, Шуйпин и Е, Цзин и Хэ, Жэньцин и Сунь, Чжичжао, 2020. « Интеграция алгоритма Дейкстры в глубокое обучение с обратным подкреплением для планирования маршрута доставки еды », Транспортные исследования, часть E: Обзор логистики и транспорта, Elsevier, vol.142 (С).
    3. Ояма, Юки и Хато, Эйдзи, 2019. « Ограничение набора путей на основе призмы для решения марковской задачи назначения трафика », Транспортные исследования, часть B: методологические, Elsevier, vol. 122 (C), страницы 528-546.
    4. Anowar, Sabreena & Eluru, Naveen & Hatzopoulou, Marianne, 2017. « Количественная оценка ценности чистой езды: как далеко вы продвинетесь на велосипеде, чтобы избежать воздействия загрязнения воздуха, связанного с дорожным движением? », Транспортные исследования, часть A: политика и практика, Elsevier, vol.105 (C), страницы 66-78.
    5. Эвантия Казальи, Мишель Бирлер и Матье де Лаппарент, 2020. « Методики выбора рабочего маршрута для практического применения », Транспорт, Springer, т. 47 (1), страницы 43-74, февраль.
    6. Макартур, Дэвид Филип и Хонг, Джинхён, 2019. « Визуализация мест, куда едут велосипедисты, используя краудсорсинговые данные ,» Журнал транспортной географии, Elsevier, vol. 74 (C), страницы 233-241.
    7. Kazagli, Evanthia & Bierlaire, Michel & Flötteröd, Gunnar, 2016.« Возвращаясь к проблеме выбора маршрута: модель моделирования, основанная на мысленных представлениях ,» Журнал моделирования выбора, Elsevier, vol. 19 (C), страницы 1-23.
    8. Насир, Нима и Хикман, Марк и Ма, Чжэнь-Лян, 2019. « Основанная на стратегии рекурсивная модель выбора пути для данных смарт-карты общественного транспорта », Транспортные исследования, часть B: методологические, Elsevier, vol. 126 (C), страницы 528-548.
    9. Fitch, Диллон Т. и Хэнди, Сьюзан Л., 2020. « Дорожная среда и выбор маршрута велосипедиста: дела Дэвиса и Сан-Франциско, Калифорния », Журнал транспортной географии, Elsevier, vol.85 (С).
    10. Бхат, Чандра Р. и Дубей, Субод К. и Нагель, Кай, 2015. « Внедрение ненормальности латентных психологических конструкций при моделировании выбора с приложением к выбору маршрута велосипедистом », Транспортные исследования, часть B: методологические, Elsevier, vol. 78 (C), страницы 341-363.
    11. Ведель, Сюзанна Элизабет и Якобсен, Джетте Бредаль и Сков-Петерсен, Ганс, 2017. « Предпочтения велосипедистов в отношении характеристик маршрута и загруженности в Копенгагене — экспериментальное исследование выбора пассажиров пригородных поездов «, Транспортные исследования, часть A: политика и практика, Elsevier, vol.100 (C), страницы 53-64.
    12. Май, Тянь, 2016. « Метод интеграции корреляционных структур для обобщенной рекурсивной модели выбора маршрута », Транспортные исследования, часть B: методологические, Elsevier, vol. 93 (PA), страницы 146-161.
    13. Нуньес, Хавьер Есид Махеча и Бисконсини, Данило Ринальди и Родригеш да Силва, Антониу Нельсон, 2020. « Сочетание оценки экологического качества велосипедной инфраструктуры с измерениями вертикального ускорения ,» Транспортные исследования, часть A: политика и практика, Elsevier, vol.137 (C), страницы 447-458.
    14. Сынкю Рю, 2020. « Матрица отправления и назначения велосипеда на основе двухэтапной процедуры ,» Устойчивое развитие, MDPI, Open Access Journal, vol. 12 (7), страницы 1-14, апрель.
    15. Jiang, Gege & Fosgerau, Mogens & Lo, Hong K., 2020. « Выбор маршрута, непостоянство времени в пути и рациональное невнимание ,» Транспортные исследования, часть B: методологические, Elsevier, vol. 132 (C), страницы 188-207.
    16. Лу, Вей и Скотт, Даррен М.И Dalumpines, Рон, 2018. « Понимание выбора маршрута велосипедиста для совместного использования с использованием данных GPS: сравнение основных маршрутов и кратчайших путей ,» Журнал транспортной географии, Elsevier, vol. 71 (C), страницы 172-181.
    17. Папола, Андреа и Тинесса, Фиоре и Марцано, Витторио, 2018. « Применение комбинации случайных полезных моделей (CoRUM) для выбора маршрута », Транспортные исследования, часть B: методологические, Elsevier, vol. 111 (C), страницы 304-326.
    18. Милакис, Димитрис и Афанасопулос, Константинос, 2014.« А как насчет людей, участвующих в планировании велосипедной сети? Применяя совместный многокритериальный анализ ГИС в случае афинской городской велосипедной сети », Журнал транспортной географии, Elsevier, vol. 35 (C), страницы 120-129.
    19. Даман-Сироис, Габриэль и Эль-Генейди, Ахмед М., 2015. « Кто больше ездит на велосипеде? Определение частоты велосипедного движения с помощью сегментации в Монреале, Канада », Транспортные исследования, часть A: политика и практика, Elsevier, vol. 77 (C), страницы 113-125.
    20. Баглои, Саид Асади и Сарви, Маджид и Уоллес, Марк, 2016 г. « Приоритет велосипедных дорожек: продвижение велосипеда как зеленого вида транспорта даже в густонаселенных городских районах ,» Транспортные исследования, часть A: политика и практика, Elsevier, vol. 87 (C), страницы 102-121.

    Исправления

    Все материалы на этом сайте предоставлены соответствующими издателями и авторами. Вы можете помочь исправить ошибки и упущения. При запросе исправления укажите дескриптор этого элемента: RePEc: eee: transb: v: 140: y: 2020: i: c: p: 262-281 .См. Общую информацию о том, как исправить материал в RePEc.

    По техническим вопросам, касающимся этого элемента, или для исправления его авторов, названия, аннотации, библиографической информации или информации для загрузки, обращайтесь: (Haili He). Общие контактные данные поставщика: http://www.elsevier.com/wps/find/journaldescription.cws_home/548/description#description .

    Если вы создали этот элемент и еще не зарегистрированы в RePEc, мы рекомендуем вам сделать это здесь.Это позволяет связать ваш профиль с этим элементом. Это также позволяет вам принимать потенциальные ссылки на этот элемент, в отношении которых мы не уверены.

    Если CitEc распознал ссылку, но не связал с ней элемент в RePEc, вы можете помочь с этой формой .

    Если вам известно об отсутствующих элементах, цитирующих этот элемент, вы можете помочь нам создать эти ссылки, добавив соответствующие ссылки таким же образом, как указано выше, для каждого ссылочного элемента. Если вы являетесь зарегистрированным автором этого элемента, вы также можете проверить вкладку «Цитаты» в своем профиле службы авторов RePEc, поскольку там могут быть некоторые цитаты, ожидающие подтверждения.

    Обратите внимание, что исправления могут занять пару недель, чтобы отфильтровать различные сервисы RePEc.

    Как избавиться от рекурсивных ссылок в Hugo navigation

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

    Рон Эрдош • Обновлено 28 сентября 2020 г.

    На этой странице

    Почему я удалил рекурсивные ссылки из навигации моего сайта Hugo

    Раньше у меня были рекурсивные ссылки в навигации по сайту.

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

    Точно так же на моей странице «О программе» нижний колонтитул содержал ссылку на ту же страницу «О программе».

    В настоящее время я удалил все такие рекурсивные навигационные ссылки на этом сайте.

    На моей домашней странице логотип заголовка больше не является ссылкой. Это просто логотип.

    А на моей странице «О нас» больше нет рекурсивной ссылки нижнего колонтитула.

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

    И мой нижний колонтитул ссылается на страницу «О программе» на всех страницах, не относящихся к «О программе».Я удалил только те ссылки, где они были рекурсивными.

    Это хороший UX?

    Кто-то может возразить, что это плохой UX, и это может быть правдой.

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

    В любом случае, вот как удалить рекурсивные ссылки в навигации вашего собственного сайта Hugo.

    Я рассмотрю два сценария: использование встроенного логотипа SVG, как на этом сайте; и с использованием традиционного логотипа в формате PNG.

    Встроенные логотипы SVG

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

      {{if .IsHome}}
        {{частичный "logo.html". }}
    {{ еще }}
         {{частичный "logo.html". }} 
    {{ конец }}
      

    Давайте пройдемся по нему:

    {{if .IsHome}} Здесь мы сообщаем Хьюго, что делать при создании домашней страницы. Обратите внимание, что .IsHome — это переменная страницы Hugo, которая поставляется с платформой, вам не нужно ее создавать.

    {{частично "logo.html". }} На главной странице отобразите логотип, используя фрагмент с именем logo.html . В этой части у меня есть SVG-код для моего логотипа MoonBooth, который вы видите вверху этой страницы.

    {{else}} Для любой страницы, кроме главной & mldr;

    {{частичный "logo.html". }} Визуализируйте логотип и сделайте его ссылкой на главную страницу.

    {{end}} Закройте оператор if .

    Логотипы в формате PNG

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

      {{if .IsHome}}
         `
    {{ еще }}
          
    {{ конец }}
      

    Логика кода такая же, как и во встроенной версии SVG выше; Я только что заменил партиал logo.html на прямую ссылку на изображение.

    Я пропустил атрибуты alt text, height и width из img , чтобы упростить пример кода, но вы, очевидно, захотите добавить их в производство.

    Как удалить рекурсивные ссылки из вашей навигации

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

    Ниже я расскажу о двух различных сценариях.

    Для страниц

    Для ссылок на такие страницы, как ваша страница «О программе», ваш код может выглядеть примерно так:

      {{if eq .Path "about.md"}}
         О компании 
    {{ еще }}
         О программе 
    {{ конец }}
      

    Давайте пройдемся по нему:

    {{if eq .Path "about.md"}} Здесь есть кое-что, что нужно распаковать. Во-первых, вы должны знать, что eq означает «равно», и что Hugo, основанный на пакете html / template Go, использует его вместо знака равенства.

    Во-вторых, eq идет с до , две вещи, которые мы сравниваем, например: if eq thing_1 thing_2 . Типа того, как Йода разговаривает.

    В-третьих, .Path , по-видимому, является формой встроенной переменной файла Hugo. Он проверяет относительный путь к файлу Markdown (например, about.md ) в вашем репозитории Hugo относительно папки / content / . Поскольку я храню свой файл about.md в корне моей папки / content / , я просто пишу "about.md ".

    Итак, эта строка кода говорит, что если мы находимся на странице» О нас «, то & mldr;

    About & mldr; покажет слово Около выделено жирным шрифтом (без ссылки).

    {{else}} Однако, если мы находимся на странице , а не , страница «О нас» & mldr;

    About & mldr; затем уже ссылку на проклятую страницу About!

    {{end}} & mldr; и вперед.

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

    Для домашних страниц разделов

    Что делать, если вы хотите удалить рекурсивные ссылки на домашние страницы разделов? (Примером домашней страницы раздела является мой список руководств Hugo.) Это не файл Markdown в моем репо, это папка. Поэтому я не могу использовать .Path для ссылки на него, как это было в примере со страницей «О нас» выше.

    Вот что делать в этом случае:

      {{if and (eq .Section "planets") (.IsNode)}}
         Планеты 
    {{ еще }}
         Планеты 
    {{ конец }}
      

    Давайте рассмотрим код:

    {{if and (eq .Section "planets") (.IsNode)}} Эта первая строка представляет собой проверку «если оба условия верны».Синтаксис для непосвященных: if и (условие 1) (условие 2) . Этот синтаксис, вероятно, немного отличается от других языков программирования, которые вы, возможно, использовали.

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

    Второе условие, которое мы будем проверять, — это то, что страница является узлом, a.k.a папка ( .IsNode ). Мы хотим, чтобы выполнялись оба условия, потому что мы не хотим всех страниц в разделе планет , а также не хотим всех узлов / папок на нашем сайте. Нам просто нужна папка planets , которую я называю домашней страницей раздела.

    Итак, если оба условия верны, то & mldr;

    Планеты & mldr; выделите слово Planets жирным шрифтом (без ссылки).

    {{else}} Однако, если мы находимся на странице , а не , домашняя страница раздела «Планеты» & mldr;

    Планеты & mldr; тогда уже ссылку на домашнюю страницу раздела проклятых планет!

    {{end}} & mldr; и идти своим путем.

    Как вы думаете?

    Что вы думаете об удалении рекурсивных навигационных ссылок? Скорее всего, это тема без единого мнения.Я хотел бы услышать ваши мысли!

    InternalError: слишком много рекурсии — JavaScript

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

      Ошибка: недостаточно места в стеке (край)
    InternalError: слишком много рекурсии (Firefox)
    RangeError: превышен максимальный размер стека вызовов (Chrome)
      

    Функция, которая вызывает сама себя, называется рекурсивной функцией .Когда-то состояние встречается, функция перестает вызывать саму себя. Это называется базовым вариантом .

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

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

      function loop (x) {
      если (x> = 10)
        возвращаться;
      
      петля (х + 1);
    }
    петля (0);  

    Установка очень высокого значения для этого условия не сработает:

      function loop (x) {
      если (x> = 1000000000000)
        возвращаться;
      
      петля (х + 1);
    }
    петля (0);
    
      

    У этой рекурсивной функции отсутствует базовый случай. Поскольку нет условия выхода, функция будет вызывать себя бесконечно.

      function loop (x) {
     
    
    петля (х + 1);
    }
    
    петля (0);
    
      

    Ошибка класса: слишком много рекурсии

      class Person {
    конструктор(){}
    установить имя (имя) {
    это.name = name;
    }
    }
    
    const tony = новый человек ();
    tony.name = "Тониша";
      

    Когда значение присваивается имени свойства (this.name = name;) JavaScript должен установить это свойство. Когда это происходит, запускается функция установки.

      название набора (название) {
    this.name = name;
    }
      

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

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

      получить имя () {
    вернуть this.name;
    }
      

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

      class Person {
    конструктор(){}
    установить имя (имя) {
    this._name = имя;
    }
    получить имя () {
    вернуть this._name;
    }
    }
    const tony = новый человек ();
    Тони.name = "Тониша";
    console.log (Тони);
      

    Рекурсивные пути с React Router v4

    🚨 Обратите внимание, что в этом посте используется React Router v4 . Если вы используете другую версию, найдите ее ниже


    Рекурсивные маршруты — не самая практичная вещь в мире, но они действительно демонстрируют преимущества компонентного подхода React Router v4 к маршрутизации.

    Основная идея здесь в том, что, поскольку React Router v4 — это просто компоненты, теоретически вы можете создавать рекурсивные и, следовательно, бесконечные маршруты.Секрет заключается в настройке правильной структуры данных, которая может привести к бесконечным маршрутам. В этом примере мы будем использовать массив из пользователей , каждый из которых имеет идентификатор , имя и массив друзей .

      const users = [
      {id: 0, имя: 'Мишель', друзья: [1, 2, 3]},
      {id: 1, имя: 'Шон', друзья: [0, 3]},
      {id: 2, имя: 'Ким', друзья: [0, 1, 3],},
      {id: 3, имя: 'Дэвид', друзья: [1, 2]}
    ]  

    Если эта структура данных настроена таким образом, когда мы визуализируем Person , мы будем визуализировать всех их друзей как Link s.Затем при нажатии на ссылку Link мы отобразим всех друзей этого человека как Link и так далее. Каждый раз, когда нажимается ссылка Link , путь к приложению становится все длиннее.

    Изначально мы будем на /, а пользовательский интерфейс будет выглядеть так:

      Друзья Мишель
    
      * Шон
      * Ким
      * Дэвид  

    Если щелкнуть Kim , то URL-адрес изменится на /2 (идентификатор Kim ), а пользовательский интерфейс будет выглядеть так:

      Друзья Мишель
    
      * Шон
      * Ким
      * Дэйвид
    
    Друзья Кима
    
      * Мишель
      * Шон
      * Дэвид  

    Если щелкнуть David , тогда URL изменится на /2/3 (идентификатор Кима , затем идентификатор Дэвида ), и пользовательский интерфейс будет выглядеть так:

      Друзья Мишель
    
      * Шон
      * Ким
      * Дэйвид
    
    Друзья Кима
    
      * Мишель
      * Шон
      * Дэйвид
    
    Друзья Дэвида
    
      * Шон
      * Ким  

    И этот процесс повторяется до тех пор, пока пользователь хочет щелкнуть Link s.

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

    Как в нашем Link , так и в Route нам нужно знать текущий путь к приложению, чтобы мы могли добавлять к нему каждый раз, когда щелкают ссылку Link (как в приведенном выше примере, мы пошли с / 2 /2/3 и далее).К счастью для нас, React Router v4 дает нам путь с match.url . Имея это в виду, начальная часть нашего Link будет выглядеть так:

        

    и Route , которые мы визуализируем, будут соответствовать одному и тому же шаблону, а затем визуализировать один и тот же компонент.

        

    Теперь, когда у нас есть основы, давайте приступим к созданию компонента, который будет рекурсивно визуализирован, Person .

    Помните, что этот компонент должен отвечать за несколько вещей.

    1. Он должен отображать компонент Link для каждого из друзей этого конкретного человека.
    2. Он должен отобразить компонент Route , который будет соответствовать текущему имени пути + /: id.

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

      импортировать React из React
    импорт {
      BrowserRouter как маршрутизатор,
      Маршрут,
      Связь
    } из 'response-router-dom'
    
    const users = [
      {id: 0, имя: 'Мишель', друзья: [1, 2, 3]},
      {id: 1, имя: 'Шон', друзья: [0, 3]},
      {id: 2, имя: 'Ким', друзья: [0, 1, 3],},
      {id: 3, имя: 'Дэвид', друзья: [1, 2]}
    ]
    
    const Person = ({совпадение}) => {
      возвращаться (
        
    ЧЕЛОВЕК
    ) } class App extends React.Component { оказывать() { возвращаться ( <Маршрутизатор> <Человек /> ) } } экспорт приложения по умолчанию

    💻 Играйте с кодом.

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

    Вы можете заметить здесь проблему. В конечном итоге Person будет обработано React Router, поэтому ему будет передано свойство match prop. Именно это свойство match мы будем использовать, чтобы получить текущий путь и (с помощью пользователей ) имя человека и список друзей.Проблема в том, что мы визуализируем Person вручную внутри основного компонента App , чтобы запустить рекурсию. Это означает, что match будет undefined при первом рендеринге Person . Решение этой проблемы проще, чем может показаться. Когда мы сначала вручную визуализируем , нам нужно будет передать ему match prop, как это сделал бы React Router v4.

      class App расширяет React.Component {
      оказывать() {
        возвращаться (
          <Маршрутизатор>
            
          
        )
      }
    }  

    Теперь каждый раз, когда отображается Person , в том числе в первый раз, ему будет передаваться match prop, который будет содержать две вещи, которые нам нужны: url для рендеринга нашего Route и Link s и параметрыid , чтобы мы могли выяснить, какой человек отображается.

    Хорошо, вернемся к главной цели. Человек нужно

    1. отображает компонент Link для каждого из друзей этого конкретного человека.
    2. отображает компонент Route, который будет соответствовать текущему имени пути + /: id.

    Давайте займемся №1. Прежде чем мы сможем визуализировать какие-либо Link s, нам нужно найти друзей человека. Мы уже знаем id человека из совпадения .params.id . Использование этих знаний с методом Array.find означает, что получение информации о друзьях должно быть довольно простым. Мы создадим для него вспомогательную функцию.

      const users = [
      {id: 0, имя: 'Мишель', друзья: [1, 2, 3]},
      {id: 1, имя: 'Шон', друзья: [0, 3]},
      {id: 2, имя: 'Ким', друзья: [0, 1, 3],},
      {id: 3, имя: 'Дэвид', друзья: [1, 2]}
    ]
    
    const find = (id) => users.find (p => p.id == id)
    
    const Person = ({совпадение}) => {
      const person = find (match.params.id)
    
      возвращаться (
        
    ЧЕЛОВЕК
    ) }

    💻 Играйте с кодом.

    Медленно добираюсь. Теперь у нас есть человек, давайте отрендерим пользовательский интерфейс, включая Link для каждого из его друзей.

      const Person = ({match}) => {
      const person = find (match.params.id)
    
      возвращаться (
        
    Друзья

    {person.name}

      {person.friends.map ((id) => (
    • <Ссылка на = {`$ {match.url} / $ {id} `}> {найти (id) .name}
    • ))}
    ) }

    💻 Играйте с кодом.

    Мы так близки к завершению. Теперь, когда у нас есть Link для каждого из друзей человека, как упоминалось в пункте 2, нам нужно убедиться, что мы также визуализируем Route .

      const Person = ({match}) => {
      const person = find (match.params.id)
    
      возвращаться (
        

    {человек.Друзья пользователя name}

      {person.friends.map ((id) => (
    • {найти (id) .name}
    • ))}
    ) }

    💻 Играйте с кодом.

    При первой визуализации Person мы передаем ему объект mock match .Затем Person отображает список из Link , а также Route , соответствующий любому из этих Link . При щелчке по ссылке Link соответствует Route , который отображает другой компонент Person , который отображает список Link s и новый Route . Этот процесс продолжается до тех пор, пока пользователь продолжает нажимать на любую ссылку Link s.

    Оценка рекурсивной логит-модели на основе каналов и потоков каналов в сети, оснащенной датчиками

    В этой статье описывается метод оценки параметров рекурсивной логит-модели (RL) на основе ссылок с использованием измерений набора пространственно фиксированных датчиков приближения с ограниченными показателями попаданий, которые могут однозначно идентифицировать людей, например Wi-Fi-, RFID- или Bluetooth-датчики.Наблюдаемый «маршрут» человека, в котором авторы сосредотачиваются на пешеходах в условиях города или события, моделируется как последовательность датчиков, которые идентифицировали человека во время его или ее поездки. Очевидно, что эти «маршруты» содержат большие пробелы, что делает неприменимы традиционные методы оценки. Хотя авторы точно не знают, что происходит внутри этих промежутков, у них есть некоторые конкретные представления о поведении людей между двумя идентификациями; они знают с определенной вероятностью, которая связана с частотой срабатывания датчиков, что человек не пересек другой участок датчика между двумя идентификациями.Поэтому в данной статье описывается метод оценки параметров модели RL, в которой конкретно используются эти знания. Эта структура также позволяет авторам сформулировать вероятностный метод оценки использования канала, который можно использовать для оценки потоков каналов в сети на основе наблюдений датчиков. Эффективность методологии демонстрируется в моделировании с использованием искусственной сети, после чего методология тестируется на реальном наборе данных, собранных на голландском музыкальном мероприятии.

    • URL записи:
    • URL записи:
    • Наличие:
    • Дополнительные примечания:
      • © 2020 Авторы. Опубликовано Elsevier Ltd. Реферат перепечатан с разрешения Elsevier.
    • Авторов:
      • ван Ойен, Тим П.
      • Даамен, Винни
      • Hoogendoorn, Serge P
    • Дата публикации: 2020-10

    Язык

    Информация для СМИ

    Предмет / указатель терминов

    Информация для подачи

    • Регистрационный номер: 01754289
    • Тип записи: Публикация
    • Файлы: TRIS
    • Дата создания: 15 сен 2020 15:04
    .