galaxy

Для начала, вставляйте код в вопрос через кнопку "Вставить код". Например, сейчас у вас парсер съел http:// в ссылке.

Далее, этот дурацкий сайт возвращает невалидный JSON. Во-первых, он возвращает его в кодировке CP1251 (по стандарту должно быть UTF-8). Во-вторых, переносы строк, как и все контрольные символы, должны кодироваться.

Ну и вы поставили (вторым параметром при вызове json_decode) возвращать результат, как массив. А работать пытаетесь с ним, как с объектом.

$API = "http://rzhunemogu.ru/RandJSON.aspx?CType=1";
$s = iconv("cp1251", "utf-8", file_get_contents($API));
$s = str_replace(["\r", "\n"], ["\\r", "\\n"], $s);
$o = json_decode($s);
print $o->content;

Что-то типа:

preg_match("/^[ a-z0-9а-я,.\/№-]+$/iu", "ывалпорывдл 345 ылваопя №345.2");

Правда оно пропустит пробелы в начале/конце и несколько пробелов подряд.

Есть тип jsonb, из него извлечь можно так:

create table t (f jsonb);
insert into t values ('{"t_in":[0],"t_out":[1]}');

# table t;
              f
-----------------------------
 {"t_in": [0], "t_out": [1]}

# select f->'t_in' from t;
 ?column?
----------
 [0]
(1 row)

Если поле имеет строковый тип:
select '{"t_in":[0],"t_out":[1]}'::jsonb->'t_in';

Ответ будет сильно зависеть от модели соударения.

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

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

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

Даже при центральном ударе (лоб в лоб, прицельный параметр = 0, раскручивания шаров нет, силы трения не имеют значения) все непросто. Закон сохранения энергии может и не выполняться даже в случае упругого материала шаров. В этой хорошей книжке начиная со стр 101 рассматриваются соударения длинных упругих стержней. Если длины (и материал) стержней одинаковы, результат получается, как в школьном учебнике (стержни обменяются скоростями). Когда один из стержней длиннее, макроскопический закон сохранения энергии "перестает" выполняться, т.к. часть кинетической энергии после соударения остается в более длинном стержне в виде упргуих волн.

Думаю, от вас требуется только рассмотреть первый случай.

Не знаю, что именно вам нужно. Следующая функция возвращает произвольную строку длины len из символов алфавита chars:

create or replace function rand_str(len int, chars text default '0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz') returns text language sql as $$
  SELECT string_agg (substr(chars, ceil (random() * length(chars))::integer, 1), '')
  FROM generate_series(1, len)
$$;

postgres=# select rand_str(10);
  rand_str
------------
 wmIn59AeiS
(1 row)

postgres=# select rand_str(50, 'абвгдежзиклмнопрстуфхцчшщъыьэюя');
                      rand_str
----------------------------------------------------
 дломчяочэатьщсдмллянблнцммюгььжзетшбзвшлежлэщдечют
(1 row)

Если не хотите руками собирать запросы (или с помощью модуля sql), можно использовать списки:

v = {'_id': 10, 'param_name': None}
c.mogrify("SELECT * FROM table_name WHERE %(param_name)s IS NULL OR id = ANY(%(param_name)s)", v)
# b'SELECT * FROM table_name WHERE NULL IS NULL OR id = ANY(NULL)'

v = {"_id": 10, "param_name": [1, 2, 3]}
# b'SELECT * FROM table_name WHERE ARRAY[1,2,3] IS NULL OR id = ANY(ARRAY[1,2,3])'

Вместо None можно и под пустой список подогнать (немного больше возни):

v = {"_id": 10, "param_name": []}
c.mogrify("SELECT * FROM table_name WHERE cardinality(%(param_name)s::int[]) = 0 OR id = ANY(%(param_name)s)", v)
# b"SELECT * FROM table_name WHERE cardinality('{}'::int[]) = 0 OR id = ANY('{}')"

Специального механизма, как в некоторых других СУБД, для этого нет. Можно, в зависимости от конкретной задачи, использовать:

1. Анонимные блоки plpgsql

do $$
declare
  list int[] := array[2619,1247,4159];
  r text;
begin
  select string_agg(relname, ',') into r from pg_class where oid = any(list);
  raise notice '%', r;
end;
$$;

# NOTICE:  pg_statistic,pg_type,pg_toast_2600

(вернуть результат запроса из такого блока нельзя, поэтому там raise notice)

2. Psql переменные
(разумеется, только если работаете в программе-клиенте psql)

> \set list 2619,1247,4159
> select * from pg_class where oid in (:list);

3. Временная (или даже не временная) таблица. Тут, думаю, примеры не требуются.

Неважно. Какой удобнее, такой и используйте.
Customs и directory форматы позволяют восстанавливать объекты выборочно, поддерживают параллельное восстановление и по умолчанию сжаты. Архитектура машины и ОС не имеют значения.
Проблемы могут быть только при восстановлении на сервере с более старой (мажорной) версией PG, тогда лучше использовать plain (даже в этом случае могут быть трудности). При заливке на новую версию проблем быть не должно.

Проверки на границы массивов кто будет делать?
Допустим, a = SIZE - 1. В первом if-блоке эта строчка какое поле проверяет:
if (field[a + 1][b - 1] == char(206))
?

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