Записи Друзья Комментарии
eugene20237
Аватар eugene20237

 -Поиск по дневнику

Поиск сообщений в eugene20237

 -Подписка по e-mail

 
Аноним

eugene20237: LINUX: настройка MC и BASH

07-02-2017 12:07 (ссылка)   Удалить
Зачем нужен баш, когда есть прекрасный ZSH? ;)
 Перейти к комментарию С цитатой В цитатник
eugene20237 [вложенный комментарий]

eugene20237: Концептуальные проблемы ООП

11-05-2013 17:38 (ссылка)   Удалить
Я хочу понять как в принципе можно (и можно ли) отрефакторить такой класс. Например, как в последнем примере: где управлющее свойство используется и на чтение и на запись. Думаю, что можно было выделить новый класс и вынести в него один из методов, в котором либо читается, либо записывается управляющее поле. Но это долго. А быстрого решения я так и не нашёл, где, например, можно было бы не создавать такого свойства, которое в одном месте устанавливается, а в другом используется.
 Перейти к комментарию С цитатой В цитатник
Аноним [вложенный комментарий]

eugene20237: Концептуальные проблемы ООП

11-05-2013 08:50 (ссылка)   Удалить
Согласен. Это проблема и она называется сложность, ООП тут не причем. Во первых надо сначала решить, что будет делать класс, а потом уже его создавать. Но если класс уже есть, то придется потратить время и разобраться, как он работает. Название класса и методов должно в этом помогать. Когда станет понятно, что класс делает, это знание надо отобразить в модульном тесте. Если для этого нужно немного порефакторить класс, это отлично, так как это улучшит архитектуру. Так-же нет ничего плохого в разносе функциональности по разным классам, если это упростит понимание.
Есть мнение, что если нет тестов, то система не работает. Это мнение как раз появилось из-за описанной тобой проблемы.
 Перейти к комментарию С цитатой В цитатник
eugene20237

eugene20237: Концептуальные проблемы ООП

10-05-2013 15:10 (ссылка)   Удалить
В первом случае очень легко сказать как работает метод "аdd". Т.е. как он изменит данные. Во втором случае представить себе работу метода "add" очень сложно и невозможно предугадать как он изменит данные. Теперь масштабируем проблему и представляем что таких параметров в классе много. Далее пробуем себе представить его поведение и описать словами "что он делает?". Потом добавляем в класс новую функциональность и понимаем что это уже опасно, потому что неизвестно как должен вести себя объект в текущем состоянии. Ну а дальше ошибки. На мой взгляд это проблема.
 Перейти к комментарию С цитатой В цитатник
Аноним

eugene20237: Концептуальные проблемы ООП

10-05-2013 14:09 (ссылка)   Удалить
А в чем собственно проблема? Есть состояние, от него зависит поведение. Чтоб это уместилось в голове, надо аккуратно пользоваться инкапсуляцией и правильно называть методы. Это не совсем проблема ООП, тоже самое можно сказать про процедуры, или даже про функции, где вычисления сильно и не понятно зависят от значения аргументов. Возможно просто не правильно выбрана семантика внутреннего состояния.
 Перейти к комментарию С цитатой В цитатник
Аноним

eugene20237: IEEE754 - вдруг кто-то ещё не знает...

20-03-2013 22:48 (ссылка)   Удалить
Незачто. А вот если бы исторически сложилось так, что у человека было восемь пальцев, все бы жили счасливо ;)
 Перейти к комментарию С цитатой В цитатник
eugene20237

eugene20237: IEEE754 - вдруг кто-то ещё не знает...

20-03-2013 16:22 (ссылка)   Удалить
Спасибо большое за комментарий! BCD - это интересно!
 Перейти к комментарию С цитатой В цитатник
Аноним

eugene20237: IEEE754 - вдруг кто-то ещё не знает...

20-03-2013 07:51 (ссылка)   Удалить
Это не проблема, а нормальное поведение.
Вся суть в том что почти никаую десчтичную дродь нельзя точно записать в двоичном виде, и даже если просто написать в коде 0.1 то полученная константа будет записана с погрешностью. Точно записываются только дроби, которые можно представить в виде суммы чисел (1/2^n1+1/2^n2+1/2^n3…) где n — натуральное число.
Одно из возможных решений на других языках, это использование BCD (вычисления BCD поддерживаются CPU), но боюсь в as3 для этого стандартных средств нет.
 Перейти к комментарию С цитатой В цитатник
eugene20237

eugene20237: Конец света для админа

25-12-2012 18:43 (ссылка)   Удалить
SSD у меня накрылся через два года работы без всяких холодов. Думаю, они ещё недоработаны или дело ограниченном количестве записей у флеш-памяти. Старые винчестеры 7 летней давности работали в мороз без сбоев. Это первый раз, когда появились проблемы.
 Перейти к комментарию С цитатой В цитатник
Аноним

eugene20237: Конец света для админа

25-12-2012 18:33 (ссылка)   Удалить
Используй NAS с SSD
Если что по сложнее, то пассивное охлаждение и ssd. Ну а если и так не катит, то еще WiFi туда же и в чулан
 Перейти к комментарию С цитатой В цитатник
ka82

eugene20237: Конец света для админа

21-12-2012 16:28 (ссылка)   Удалить
 Перейти к комментарию С цитатой В цитатник
eugene20237

eugene20237: FDT мегасетап

06-01-2012 18:00 (ссылка)   Удалить
Очень приятно, что ты меня нашёл ) Сижу в LI.RU только из-за кое-каких друзей.
 Перейти к комментарию С цитатой В цитатник
Аноним

eugene20237: FDT мегасетап

06-01-2012 15:15 (ссылка)   Удалить
Блин, как неудобно тут все, это был maxmoriss :)
 Перейти к комментарию С цитатой В цитатник
Аноним

eugene20237: FDT мегасетап

06-01-2012 15:13 (ссылка)   Удалить
Sublime Text 2 - наше все! ;)
 Перейти к комментарию С цитатой В цитатник
eugene20237 [вложенный комментарий]

eugene20237: Синглетоны с вайфайем

06-08-2011 13:45 (ссылка)   Удалить 
PHP:


// Маленький класс на нижнем уровне иерархии

class SmallBlaBla:

{

  .........

  private function func(): void

  {

    var main:Main = Main.getInstance(this);

    if (main != null)

    {

      // Работа с данными main

      ............

    }



    var global:Global = Global.getInstance(this);

    if (global != null)

    {

      // Работа с данными global

      ...........

    }



    var dataProvider:DataProvider = DataProvider.getInstance(this);

    if (dataProvider != null)

    {

      // Работа с данными dataProvider

      ...........

    }



    .......

  }

}
font>

Просто более быстрый доступ к единичным объектам, если делать их таким способом. Проверка на null здесь излишняя. Если доступ запрещён, этот синглетон выплюнет исключение.
 Перейти к комментарию С цитатой В цитатник
Акира_Томео

eugene20237: Синглетоны с вайфайем

06-08-2011 05:17 (ссылка)   Удалить
Т.е. к классу-координатору идет запрос типа "дай мне такие данные из Main.as", он сверяется с тем, что мол можно ли давать их, и выдает, если оные имеются? Или ты имеешь ввиду статиц инстансе, ведущий на текущий активный элемент? Кстати насчет класса констант ты ошибся. Класс констант - это класс констант, а класс Global - это класс Global. =) Я в него пихаю не статичные данные, а изменяющиеся во время работы программы или подгружаемые с сервера во время прелоадинга (была мысль сделать для загружаемых данных отдельный класс, но это уже перебор).
 Перейти к комментарию С цитатой В цитатник
eugene20237 [вложенный комментарий]

eugene20237: Синглетоны с вайфайем

06-08-2011 04:28 (ссылка)   Удалить
А идея заключается в том, чтобы получать доступ по точно такой же схеме например к классу Main в AS3.
 Перейти к комментарию С цитатой В цитатник
eugene20237 [вложенный комментарий]

eugene20237: Синглетоны с вайфайем

06-08-2011 04:27 (ссылка)   Удалить
Да, ты абсолютно прав. Действительно в большинстве случаев контроль за состоянием синглетона не нужен, особенно для класса констант. Он нужен для сложных классов, которые содержат динамические массивы других объектов и большое количество разных классов-клиентов.
 Перейти к комментарию С цитатой В цитатник
Акира_Томео

eugene20237: Синглетоны с вайфайем

06-08-2011 04:24 (ссылка)   Удалить
Ну я сейчас в тестовой системе чата использую класс Global, в котором лежат все глобальные данные вроде текущей локации, информации о юзере и т.д. Хотя контроля за изменением нет, ввести его можно (допустим чтоб информацию о юзере мог изменять только интерфейс настроек), хотя сейчас и не надо. Или я все-таки не так понял? Во всяком случае, я считаю что такой подход гораздо удобней.
 Перейти к комментарию С цитатой В цитатник
d0rc

eugene20237: Упрощенные вычисления

16-07-2011 00:22 (ссылка)   Удалить
eugene20237, попытка написать несжимаемую программу - это оптимизация, так что - наработок очень много, но универсального решения нет. Были попытки написать супер-компилятор, но они, насколько мне известно, не увенчались успехом. Так или иначе, такого рода оптимизация, скорее всего, потребует полного перебора всех возможных вариантов, в качестве оптимальной стратегии. Не следует, однако, сбрасывать со счетов тот факт, что у нас нет уверенности, что концепция вычислений, которой мы располагаем единственно возможная.

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

eugene20237: Упрощенные вычисления

15-07-2011 06:06 (ссылка)   Удалить
Вот ещё идея. Насмотревшись разных фильмов, подумалось следующее.
Время на разных уровнях системы идёт по разному: чем глубже вложена подсистема, тем быстрее идёт там время. Уточню, что под "временем", я имел в виду среднюю скорость процессов. Например электроны в ядре летают значительно быстрее чем планеты вокруг солнца. Как это можно использовать? Точно не знаю, но ясно что это свойство делает подсистему на уровень ниже труднопредсказуемой, а раз предсказать там ничего нельзя, то можно смело упрощать эти вычисления и нагло сжимать их, оставляя в стороне реальное моделирование. "Компрессия" будет конечно же необратимой.
 Перейти к комментарию С цитатой В цитатник
eugene20237 [вложенный комментарий]

eugene20237: Упрощенные вычисления

12-07-2011 05:54 (ссылка)   Удалить
Теоретически да. Например, там есть случайные события, которые могут возникнуть между ключевыми точками... А вообще интересно, что если написать конвертер heavy-программы, написанной для этого на каком-нибудь специальном языке, в программу, содержащую только несжимаемые вычисления. Это было бы супер... А может уже есть такие наработки в мире?
 Перейти к комментарию С цитатой В цитатник
d0rc [вложенный комментарий]

eugene20237: Упрощенные вычисления

12-07-2011 05:48 (ссылка)   Удалить
Если у тебя есть процессы, описываемые линейными уравнениями, значит, ты можешь вообще не вызывать моделирование, а сразу узнать, когда будут особые точки, и запланировать событие на нужный момент времени, превращая таким образом пустое молотилово процессором в те самые несжимаемые вычисления.
 Перейти к комментарию С цитатой В цитатник
eugene20237 [вложенный комментарий]

eugene20237: Упрощенные вычисления

12-07-2011 05:43 (ссылка)   Удалить
Наверное я использовал не правильные термины. Я вовсе не претендовал на универсальность. Однако, перед тем как я написал этот пост, я попробывал в своей игре (в серверной части) вызывать событие моделирования в 5 раз реже и ничего не ухудшилось вообще (для постоянно наблюдаемого мира!). В игре летают космические корабли между ключевыми точками, развозят грузы, торгуют со станциями, стреляют друг в друга... Потому что полёты, например, отлично описываются приведенным линейным уравнением.

Теперь представим себе какую-нибудь базу, которую игроки будут строить на Богом забытых планетах. Эта игровая логика примерно такая же как в StarCraft и т.п. Выбор маршрутов и движение по ним. Причем большую часть времени только движение. Бои вообще можно переложить на какую-нибудь ролевую систему типа DnD, чтобы не проверять пересечений. Всё будет работать. А когда игрок снова посетит свою любимую базу он увидит, что все юниты находятся в логичных с его точки зрения местах и что мир живёт. Вот вам область применения упрощенных вычислений.
 Перейти к комментарию С цитатой В цитатник
d0rc [вложенный комментарий]

eugene20237: Упрощенные вычисления

12-07-2011 05:23 (ссылка)   Удалить
ты за деревьями не видишь леса - вся сложность скрывается во фразе "Правильно написанный алгоритм всё равно отработает как надо". Если алгоритм представим в виде линейной операции, то действительно нет проблем. И даже не надо так сильно изъебываться и делать system()/subsystem() и проч. Например, x = x0 + v*t + at**2/ - линейное уравнение, мы можем подставить любое значение t и посмотреть какие будут координаты.

Но проблемы начинаются тогда, когда вычисления оказываются плохо разложимы в линейные операции, слово "плохо" здесь означает, что не существует линейного оператора такого, чтобы спектр его собственных значений совпадал со спектром собственных значений оператора, описывающего эволюцию системы. Это может быть, например, какая-нибудь рекурсия. И так далее. Несжимаемые вычисления, то есть такие, что нельзя просто "проскипать" интервал времени. И физическая реальность именно такая, да и 99% задач по моделированию естественным образом такие же.
 Перейти к комментарию С цитатой В цитатник
eugene20237

eugene20237: Упрощенные вычисления

12-07-2011 02:19 (ссылка)   Удалить
Хе-хе, а вот ещё что подумалось. Допустим детальное тяжелое моделирование описывается следующим алгоритмом:
while (true)
{
simulate_subsystem(getTimer() - last_time);
last_time = getTimer();
sleep(10 ms);
}

Упрощённые вычисления могут быть например такими:
while (true)
{
simulate_subsystem(getTimer() - last_time);
last_time = getTimer();
sleep(100 ms);
}

Просто вызываем ту же самую функцию real-time моделирования в 10 раз реже. Правильно написанный алгоритм всё равно отработает как надо, потому что она учитывает разницу по времени. Даже все столкновения правильно определит. Таким образом уже можно свободно моделировать 10 невидимых подсистем, а не одну.
 Перейти к комментарию С цитатой В цитатник
eugene20237 [вложенный комментарий]

eugene20237: Упрощенные вычисления

12-07-2011 02:03 (ссылка)   Удалить
То невидимое, что находится за дверью предлагаю вычислять, но упрощенно. А наблюдатель всё равно не сможет проверить точность этих результатов, да и не важна она.
 Перейти к комментарию С цитатой В цитатник
eugene20237 [вложенный комментарий]

eugene20237: Упрощенные вычисления

11-07-2011 18:06 (ссылка)   Удалить
Это всё не про то )
 Перейти к комментарию С цитатой В цитатник
Акира_Томео

eugene20237: Упрощенные вычисления

11-07-2011 16:50 (ссылка)   Удалить
Вероятно, что даже наш "реальный" мир поступает с нами не совсем честно.

----
Не, он, гад, не по принципу Шредингера работает. Протекшие трубы гарантируют это :)
----
Этот принцип можно использовать для компьютерного моделирования: не важно что там - не вычисляй.

----
Насколько я помню, похожий принцип был использован в Carmageddon (или как-то так, не помню название). Разрушаемые объекты не были разрушаемыми, пока на них не наткнешься.
----
[qupte]вычислять надо только то, что видно в данный момент.[/qupte]
----
Я считаю что видео-карта так и работает. Можно показать на примере слабой машины и мощной игры. Если смотреть вперед, где происходит сложное действо - начнет тормозить, опустишь камеру в пол - часть лагов пройдет, ибо действо выходит за пределы экрана и часть нагрузки спадает.

----
Идея интересная, но частями я не совсем понял о чем идет речь. К тому же такая система будет очень ресурсоемкая (или я ошибаюсь?)
 Перейти к комментарию С цитатой В цитатник
eugene20237

eugene20237: Упрощенные вычисления

10-07-2011 19:37 (ссылка)   Удалить
Исходное сообщение d0rc
Что же касается общей аналогии, то все же более вероятно, что вселенная вычисляет сама себя, и от того у нее нет проблем с производительностью, поскольку она сама и есть этот процесс. В этом смысле, активность взаимодействия - и есть расстояние, отсюда и эффект кривизны пространства-времени "пропорциональный" количеству вещества (ОТО), и эффект редукции квантового состояния тем более вероятный, чем выше вероятность взаимодействия.

Применением этой теории будут распределённые вычисления на клиентах в онлайн играх Кое-где такое уже успешно применяется, вместе с проверкой читерства. По-моему очень правильное направление. Вселенная вычисляет сама себя - сколько игроков, столько и компьютеров в ботнете
 Перейти к комментарию С цитатой В цитатник
Страницы: [1] 2 3 ..
.. 10 		»

О проекте