Б. Наращиваем формы по шагам. Изменяется всегда только первый глагол, хвост остаётся как есть.
1) Нужен passive? Заменяем глагол на страдательное причастие и добавляем вначале глагол be
2) Нужен continuous? Заменяем глагол на действительное причастие, добавляем вначале be
3) Нужен perfect? Заменяем глагол на страдательное причастие, добавляем вначале have
4) Нужен future? Добавляем вначале will
5) Нужен past? Ставим глагол в форму прошедшего времени.
В. Ставим глагол в нужную личную форму, ежели таковая имеется
Всё.
Пример:
Строим, допустим, пассивный past perfect от того же install:
1) install => be + (installed)
2) пропускаем, не continuous
3) be (installed) => have + (been installed)
4) пропускаем, не future
5) have (been installed) => had been installed
(в скобках хвост, который не поменяется на дальнейших шагах)
Представьте, как было бы хорошо, если роутер не был «бутылочным горлышком», и в случае его отказа все участники домашней сети могли выйти в интернет через умный телевизор, соседские беспроводные сети и в конце концов через ваш смартфон, и всё это без какой-либо дополнительной конфигурации после поломки роутера!
Но если всё это работает поверх IP, то как это возможно?
Пример, как кажется, не вполне показателен, поскольку по Вашей же ссылке на Википедию я прочитал, что само это обозначение «Серебряный век» появилось ещё в конце века девятнадцатого.
Но, кажется, я понял, что Вы имели в виду. Вы утверждаете, что для проверки какого-либо, скажем так, сложившегося мнения о каком-либо предмете нам бесполезно изучать сам этот предмет, это так? При этом мнение само может быть как и реалистичным, так и совершенно фантастическим.
Пример с Серебрянным веком, как кажется, требует пояснений. Если мир-с-серебрянным-веком и мир-без-серебрянного-века ничем не различаются, откуда мы вообще знаем, что это такое? Общественный консенсус по поводу этого термина, выходит, — не часть мира? Равно как и консенсус о том, где Эльбрус, а где Эверест? Прошу пояснений в этой области. Возможно, я пропустил что-то в других статьях цикла?
1) Если как-то оптимизировать вычисление плотности вероятности, жертвуя точностью в угоду скорости, то легко пропустить локальный минимум. А если считать всё точно, то даже для крайних значений для каждого веса объём вычислений вырастет как 2^N, где N — количество нейронов.
2) Обучение базируется на том, чтобы корректировать веса с помощью обратного распространения ошибки, который, в свою очередь, требует того, чтобы функция активации была дифференцируема. Вопрос — как это считать в случае с использованием плотностей вероятности?
convert, вроде бы, по умолчанию пытается ещё раз пережимать картинки. img2pdf, ссылку на который я положил ниже, по умолчанию пакует картинки в PDF в том же виде, в котором они есть (мне было нужно именно это).
Если очень хочется, то смешивать декларации (кстати, откуда в статье взялись "логические заключения кода"?) и выражения с побочными эффектами — можно
Свойства — в camelCase
С нетерпением ждём обзора на PSR-12, Symfony Coding Standard (предвижу что-то в духе "всё годится, кроме yoda conditions").
А если серьёзно, то не хватает хотя бы готовых файлов стиля для PHP-CS-Fixer, phpcbf, возможно, для встроенных инспекций phpStorm, и т. п. Хотите свой стандарт — двигайте его!
Union-типы — ужасная ошибка. Вместо них должны быть Generic Types, а их лучше бы и не вводить. Это ненормально, когда функция принимает непонятно что и возвращает непонятно что.
Union'ы — это как раз-таки способ превратить непонятно что в нечто гораздо более определённое и понятное. Между mixed, в котором может быть что угодно, и int|string — большая разница. Например, int|string точно можно конкатенировать с другой строкой. int|float — это вообще прекрасно — гарантирует корректную работу почти любой математики.
Вместо них должны быть Generic Types
Generic Types по факту можно сделать с помощью статического анализа, например, у Psalm'а очень неплохие возможности по этому поводу, Phan и phpstan, кажется, тоже умеют дженерики, и синтаксис у них, кстати, очень похожий. Может быть, в PHP 9 это просто сделают официальной частью языка, как с union и атрибутами, которые тоже выросли из аннотаций?
Перегрузка операторов не нужна
Тут я согласен с Вами и с сообществом, которое фичу не поддержало
Null-safe
Сахар он и есть сахар, равно как и объявление свойств в конструкторе, который выглядит для меня куда мене очевидным, чем ?->
Пример с иммутабельными переменными выглядит неудачно.
И здесь тоже согласен. Вот специфицировать тип переменной было бы полезно (по аналогии с типизацией свойств в 7.4)
В целом почти все замечания справедливы, но уж вывод какой-то слишком пессимистичный. Нелогичностей в PHP и так хватает, и, кстати, часть из перечисленного в этой статье уже исправлена. Ну и я не могу согласиться с тем, что синтаксис стал сильно сложнее для освоения новичками. Вот, например, строгий синтаксис для атрибутов позволяет не иметь головной боли с Doctrine 2, а просто пользоваться автокомплитом, и т. п.
Совершенно неясно, в чём состояла проблема с упомянутым одно- и двух-табличным хранением объектов, и что это за структура, которой свет не видывал. Это же самое интересное, расскажите нам!
А без такого пояснения ORM-на-коленке действительно выглядит вредным велосипедом.
Почему-то, увы, Shadertoy меня не хочет регистрировать, но я добавил поддержку масштаба с опциональным уменьшением со временем и поддержку первых трёх/последних трёх hex-цифр для чисел больше 0xFFFFFF:
Код шейдера
void mainImage( out vec4 fragColor, in vec2 fragCoord )
{
vec2 coord = fragCoord - (iResolution.xy/vec2(2.0));
float factor = 50.0;
// WARNING: weird zooming out
factor = float(int(iTime*25.0) + 1) / 5.0;
coord *= factor;
int x = int(coord.x);
int y = int(coord.y);
int a = x*x + y*y;
// WARNING: flashing
// a += int(iTime * 5000.0);
// a -= int(iTime * 1000.0);
// emulating JS: a.toString(16) + "0".repeat(6 - a.toString(16).length)
if (a < 0x100000) a = a << 4;
if (a < 0x100000) a = a << 4;
if (a < 0x100000) a = a << 4;
if (a < 0x100000) a = a << 4;
if (a < 0x100000) a = a << 4;
// emulating JS: c.substring(0, 3) + c.substring(c.length-3);
while (a > 0xFFFFFF) {
a = ((a ^ (a & 0xFFF)) >> 4) | (a & 0xFFF);
}
fragColor = vec4(
float((a >> 16) & 255) / 255.0,
float((a >> 8) & 255) / 255.0,
float((a >> 0) & 255) / 255.0,
1.0
);
}
Там нет никакой интерференции. С бесконечным разрешением это были бы просто концентрические круги (поскольку по факту цвет точки зависит от расстояния до центра, точнее, квадрата расстояния). Но именно наложение пиксельной сетки даёт красивые дополнительные окружности.
Подождите, если длина произведения (в hex) выходит больше 6, то Вы берёте первые три цифры и последние три. Выходит, что красная компонента и старшая часть зелёной кодируют одно, а младшая часть зелёной и синяя — другое. Зачем так? Тем более, что для радиуса менее 4096 произведение всё равно меньше, чем #ffffff.
И ещё дополняете нулями не слева, как это было бы более логично, а справа. Если дополнять нулями слева, то выходит иначе, и на радиусе 1024 почти без красного, потому что максимальное значение — #0FF801, (0xFF * 0xFF).
Больше нейронных сетей богу нейронных сетей! Я однажды сделал "Морской бой" на свёрточных сетях, а оказалось, что тупой алгоритм ровно на одной свёртке играет лучше. А про 2048 было тут (даже до 8192, по утверждению автора). Ещё что-то было интерактивное с минимаксом, но сходу не нашёл.
А почему в улучшенном алгоритме нужен первый шаг со сложением цифр? Нельзя ли сразу взять остаток от деления на 9?
Хотите действительно простую схему?
А. Берём глагол
Б. Наращиваем формы по шагам. Изменяется всегда только первый глагол, хвост остаётся как есть.
1) Нужен passive? Заменяем глагол на страдательное причастие и добавляем вначале глагол
be2) Нужен continuous? Заменяем глагол на действительное причастие, добавляем вначале
be3) Нужен perfect? Заменяем глагол на страдательное причастие, добавляем вначале
have4) Нужен future? Добавляем вначале
will5) Нужен past? Ставим глагол в форму прошедшего времени.
В. Ставим глагол в нужную личную форму, ежели таковая имеется
Всё.
Пример:
Строим, допустим, пассивный past perfect от того же
install:1)
install=>be+(installed)2) пропускаем, не continuous
3)
be (installed)=>have+(been installed)4) пропускаем, не future
5)
have (been installed)=>had been installed(в скобках хвост, который не поменяется на дальнейших шагах)
А у вас специально в этом фрагменте форматирование чёрт знает какое? Или просто криво вставилось?
Но если всё это работает поверх IP, то как это возможно?
Спасибо, я получил ответ на свои вопросы
Пример, как кажется, не вполне показателен, поскольку по Вашей же ссылке на Википедию я прочитал, что само это обозначение «Серебряный век» появилось ещё в конце века девятнадцатого.
Но, кажется, я понял, что Вы имели в виду. Вы утверждаете, что для проверки какого-либо, скажем так, сложившегося мнения о каком-либо предмете нам бесполезно изучать сам этот предмет, это так? При этом мнение само может быть как и реалистичным, так и совершенно фантастическим.
Пример с Серебрянным веком, как кажется, требует пояснений. Если мир-с-серебрянным-веком и мир-без-серебрянного-века ничем не различаются, откуда мы вообще знаем, что это такое? Общественный консенсус по поводу этого термина, выходит, — не часть мира? Равно как и консенсус о том, где Эльбрус, а где Эверест? Прошу пояснений в этой области. Возможно, я пропустил что-то в других статьях цикла?
Реквестирую проверку LilyPond! Там, правда, часть кода на Scheme, но ядро на плюсах.
1) Если как-то оптимизировать вычисление плотности вероятности, жертвуя точностью в угоду скорости, то легко пропустить локальный минимум. А если считать всё точно, то даже для крайних значений для каждого веса объём вычислений вырастет как 2^N, где N — количество нейронов.
2) Обучение базируется на том, чтобы корректировать веса с помощью обратного распространения ошибки, который, в свою очередь, требует того, чтобы функция активации была дифференцируема. Вопрос — как это считать в случае с использованием плотностей вероятности?
convert, вроде бы, по умолчанию пытается ещё раз пережимать картинки.img2pdf, ссылку на который я положил ниже, по умолчанию пакует картинки в PDF в том же виде, в котором они есть (мне было нужно именно это).img2pdf
img2pdf img1.jpg img2.jpg -o out.pdfКраткий пересказ статьи:
С нетерпением ждём обзора на PSR-12, Symfony Coding Standard (предвижу что-то в духе "всё годится, кроме yoda conditions").
А если серьёзно, то не хватает хотя бы готовых файлов стиля для PHP-CS-Fixer, phpcbf, возможно, для встроенных инспекций phpStorm, и т. п. Хотите свой стандарт — двигайте его!
Union'ы — это как раз-таки способ превратить непонятно что в нечто гораздо более определённое и понятное. Между
mixed, в котором может быть что угодно, иint|string— большая разница. Например,int|stringточно можно конкатенировать с другой строкой.int|float— это вообще прекрасно — гарантирует корректную работу почти любой математики.Generic Types по факту можно сделать с помощью статического анализа, например, у Psalm'а очень неплохие возможности по этому поводу, Phan и phpstan, кажется, тоже умеют дженерики, и синтаксис у них, кстати, очень похожий. Может быть, в PHP 9 это просто сделают официальной частью языка, как с union и атрибутами, которые тоже выросли из аннотаций?
Тут я согласен с Вами и с сообществом, которое фичу не поддержало
Сахар он и есть сахар, равно как и объявление свойств в конструкторе, который выглядит для меня куда мене очевидным, чем
?->И здесь тоже согласен. Вот специфицировать тип переменной было бы полезно (по аналогии с типизацией свойств в 7.4)
В целом почти все замечания справедливы, но уж вывод какой-то слишком пессимистичный. Нелогичностей в PHP и так хватает, и, кстати, часть из перечисленного в этой статье уже исправлена. Ну и я не могу согласиться с тем, что синтаксис стал сильно сложнее для освоения новичками. Вот, например, строгий синтаксис для атрибутов позволяет не иметь головной боли с Doctrine 2, а просто пользоваться автокомплитом, и т. п.
Совершенно неясно, в чём состояла проблема с упомянутым одно- и двух-табличным хранением объектов, и что это за структура, которой свет не видывал. Это же самое интересное, расскажите нам!
А без такого пояснения ORM-на-коленке действительно выглядит вредным велосипедом.
И ещё дополняете нулями не слева, как это было бы более логично, а справа. Если дополнять нулями слева, то выходит иначе, и на радиусе 1024 почти без красного, потому что максимальное значение — #0FF801, (0xFF * 0xFF).
Больше нейронных сетей богу нейронных сетей! Я однажды сделал "Морской бой" на свёрточных сетях, а оказалось, что тупой алгоритм ровно на одной свёртке играет лучше. А про 2048 было тут (даже до 8192, по утверждению автора). Ещё что-то было интерактивное с минимаксом, но сходу не нашёл.