Лаборатория Амфилохия

Пока все тут развлекаются бредофренией соседа, я решил потешить свое самолюбие и создать тему со своим именем. Увы, у меня все скучнее и, кто бы мог подумать, про Руби. И что я делаю? Ставлю сомнительные эксперименты и извлекаю факты. Зачем?


Листинг пилотного бреда:



Числа с плавающей запятой в программировании имеют интересное строение - бит отводится под знак, n бит под мантиссу и m бит под степень. В итоге мы можем получить числа 2.5e+100 и 2.5e-100 (очень большое и очень малое), но при сложении обоих получим лишь 2.5e+100, т.к. такое незначительное изменение не вмещается в мантиссу.


Обычно значения степени варьируются в области (n^2)-1..-n^2 (например 1023..-1024, не забывайте что ваша память работает с двоичными числами). Однако эту надбавку степени для очень малых чисел можно объяснить тем, что мантисса для при очень малых числах уменьшается (последние 2 printf'a).


Я в шоке господа. То, что если постоянно делить число на 2, то оно станет нулем, я знал, но умножением на два дойти до бесконечности для меня стало настоящим подвигом.

На этом эксперимент завершаю. Не стесняйтесь выкладывать свои эксперименты или соображения. Главное, не задавайте вопросов, для этого у вас есть Сосед!

Проверено, да


Собственно, насчет бесконечности - она вообще во многих современных языках очень даже есть (где проверял - там точно есть)

---

Вы доведете форум со своими ляпаниями (лепнинами?) и лабораториями до того, что он заставит эльфа писать сюда что-то вроде блога (который все равно никто не будет читать)

Эльф, ты главное не выкладывай фотографии еды, не все поймут. Сюда могут с работы голодные заходить.
Я вот с бесконечностью только сегодня встретился, немного удивился. Но из языков то я знаю Lua да C++.

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

Амфи, я знаю, чем отличается блог от инстаграмов

Ты, кстати, так и не написал статейку про треды, фиберы и прочее? (имеются ввиду классы Thread и Fiber)

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



Не очень то и неизвестный факт. Если мы сделаем две переменные с одним объектом, то работая с одной переменной мы изменим это значение и для другой переменной.


Это значит что присваивая переменным одинаковые значение не через другие переменные (такие как :symb или 3) им все равно будут присваиваться одинаковые объекты.


Те, кто пытался менять значение в играх на RPG Maker с помощью cheat engine наверное знают, что именно по этой формуле ищутся настоящие значения. Дело в том, что в этом случае вы меняете id переменной, а не сам объект.


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

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

Немного лень доводить до ума свой проект, так что опубликую здесь это. Собственно слабые ссылки:


Принцип прост как 2 пальца. Я храню лишь id объекта, следовательно сборщик мусора не знает, что я указываю на объект, и ничто не мешает сборщику собрать объект. При этом я объявляю finalizer для объекта через ObjectSpace.define_finalizer (который, в свою очередь, не создает один единственный метод при сборке, а добавляет еще один). Финалайзер является проком, который знает id объекта который задавался в тот момент (это должно предотвратить затирание ссылки после того, как ссылке переназначили значение). Само значение берется с помощью ObjectSpace._id2ref.

Собственно парочка вопросов по этому поводу:
- Никто не знает зачем вообще могут быть нужны слабые ссылки? (я к тому, что эта тема волнует только меня)
- Есть ли в данной наработке дыры?
- Как сделать ультимативный краш тэст?

Зачем нужны слабые ссылки? Для реализации подписки на событие, например.
Есть у тебя независимый модуль, который, к примеру, занимается управлением анимацией.
И есть другой модуль, который занимается отработкой логики столкновений.

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

Вот и стало мне скучновато, все либо тихо в сторонке что-то умное делают, либо чешут языками в чате. А я, решив себя развлечь, вспомнил о своей задумке, смысл которой заключался в том, чтобы использовать хэши в оптимизационных вопросах. Остается только понять - как от размера хэш таблицы зависит время доступа к элементам? Учитывая, что это хэш (не буду вдаваться в принцип работы онных), я предположил, что зависимость слабая, вся соль в коллизиях (при определенном размере начнут нарастать временные затраты). Листинг эксперимента:

На своих 2.3 GHz выдал такие результаты:

Эксперимент прост - создаем файбер (я все еще считаю, что эксперимент прост), который при каждом вызове заполняет хэш до размера степени десятки (т.е. 10, 100, 1000 ... 10 000 000), затем высчитываем эталонное время прогона массива из 10 000 000 ключей (просто проходимся по массиву, ничего не делаем), затем с каждым вызовом файбера создаем массив из 10 000 000 ключей и под замером времени проходимся по массиву с ключами и достаем объекты из таблицы. Из полученного времени вычитаем эталон времени прохождения по массиву с ключами.

Результаты в целом радуют. Хэш функция работает быстрее, чем проход по массиву, а скачок временных затрат наблюдается примерно после 10 000 элементов. Весь эксперимент проводится около минуты (большая часть времени занимает заполнения таблицы и массива ключей).

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

Амфи, бенчмарки тебе deadelf79.blogspot.ru/2013/09/blog-post_28.html

Эльф, сижу с [strike]микроволновки[/strike] RPG Maker, там бенчмарков, без отдельной скачки, и в помине нет. Тем не менее результат, вроде бы, не сильно изменился. Но может я еще чего-то пока не понял.

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

Слабые кучи. Вот как-то так будут именоваться у меня слабые таблицы. Решив, что пересобрать хэш, да еще и со слабостью, мне концентрации не хватит, я пришел к этому:

Для начала стоит упомянуть, что я опираюсь на слабые ссылки, описанные мною ранее в лаборатории. Принцип кучи прост - ты кидаешь в него значения, как в хэш. Но чтобы получить значение, придется вызвать метод to_hash который вернет нормальный хэш со значениями. Во время возврата все пустые пары (по ключу или значению) собираются. Ну и конструктор, он принимает 2-3 значения:

1. Ключи слабые? (Булева)
2. Значения слабые? (Булева)
3. Начальные значения (Хэш, необяз.)

Что еще не упомянул? Ну, придется запомнить две вещи: полученный хэш при себе держать, естественно, не стоит. А так-же если постоянно заполнять кучу, но не брать из него ничего, то он все же потеряет свою функцию. За сим все, благодарю за внимание.

Сколько тут пыли то скопилось. Но о чем это я... Ах, да! Выполнить протокол безумия! Поднять рубиновые катушки!... Оно живое!!!
А вообще я тут наткнулся на очень печальную часть скриптовой архитектуры Эйса, и конкретно меня печалит загрузка карты...

Все хорошо, но что если я хочу сделать фабрику карт (а я, допустим, хочу), то у меня возникает пара нехороших вопросов. Во первых - как передать айди? Ну, я могу передать строку с префиксом, но тогда все поляжет на методе sprintf. Вытекает 2й вопрос - как предотвратить загрузку карты? Вообще выкинуть эту строчку, или... еще лучше - заменить ее.
И тут я вспомнил вот что - в Рубях функций по сути нету. А что есть? методы. Казалось бы в чем разница, но раз sprintf и load_data - методы, то он вызываются из некого предка (1й точно Kernel). Я думаю вы понимаете куда клонит мысль... Я просто переопределю этим методы для Game_Map с вызовом супер, но добавлю очень специфичные случаи...

В сухом остатке - я "заменил глобальные методы" в отдельно взятом классе, ибо хотел добавить немножко совместимости, вместо полного переопределения метода. Все спасибо разнице между функцией и методом, иго-го-го-го-го!!!

Время 3 ночи, мучает бессонница, почему бы не накатать статейку? Вам когда-нибудь требовалось делать те же самые изменения в нескольких классах одновременно? Редкое явление, но всякое бывает. И что бы вы сделали в этом случае? Если что-то вроде

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

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

Главное не злоупотребляйте, чтобы сберечь нервы от сюрпризов.

Итак, рубисты светлой. Я хочу сыграть с вами в одну игру. Тот кто правильно ответит на вопрос получит ничего. У нас есть переопределение метода method_missing, в котором мы выводим имя вызываемого метода и его аргументы. И теперь мы пытаемся запустить 2 строки: и Кто сможет полностью объяснить мне результаты вывода сообщений в консоль?

Видимо без запятой интерпретатор разделяет комманды как разные методы, а с запятой как аргументы передстоящего метода

Лови лойс

Так уж случилось, что я сейчас переодически мучаю XP. Версия 1.04 (пиратка ессено). И наткнулся на очень интересное поведение исполнения скрипта. И пока моя пятая точка плавит льды, быстро тающих от неслабого нагрева, опишу в чем же суть:
Давайте представим, что вы сделали событие, выполняющее скрипт одной строчкой, например такое

Говорим с этим персонажем и попадаем в лимбо вечного цикла. Меняем строчку на И у нас все в шоколаде. Окей, а что будет, если написать вот так И вы угадали! Мы снова можем ходить! Почему? Ну, потому что. Давайте окунемся в принцип исполнения команд интерпретатором. Interpreter1 метод update, строки 198-203: Если команда вернула true, то идем к следующей. Если false, остаемся на этой. Но погодите, разве предыдущий пример из 2 строк не вернул false? Вернул.
Давайте посмотрим как интерпретатор исполняет скрипт:

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

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