а еще есть такие вещи, как категории
и в примере в криками зверей их было бы логичнее использовать, а не наследование
Просто расширить класс Animal категорией с реализацией метода возврата крика. И тогда у каждого, кто был Animal в проекте автоматически бы появился этот метод.
если честно, то я еще в далеком детстве 3D печатью занимался (уж точно до 1983 года).
Да и многие из тут присутствующих тоже, когда на пляже «накапывали» (от слова «капля») замки из песка (метод капель и подтеков, когда вы сжимаете в ладони горсть чрезвычайно мокрого песка и держите руку над постройкой, давая песку возможность, капая сверху, создавать причудливые фентезийные башни). В чистом виде 3D печать.
Прочитал и подумал…
а многие ведь Докинза не читали.
Начните с «Эгоистичный ген», а потом уже и другие его книжки.
Так вот, Докинз пишет, что гены это не набор чертежей, а своего рода «рецепт приготовления».
Само же «приготовление» подвергается воздействию многих внешних факторов. Поэтому однояйцевые близнецы могут иметь отличия. Как вариант влияния могу предложить некоторую неравномерность поступления питательных веществ, каких то гормонов от матери. Вот вам и несколько разный результат при приготовлении по одному рецепту.
ПС: немного про отличия «чертежа» и «рецепта». В чертеже можно точно указать, какой элемент на нем соотвествует какому элементу в конструкции… в рецепте же этого указать почти никогда нельзя. По кусочку булки вы не покажите на место в рецепте…
Ну как то так. Хотя, еще раз, советую все таки Докинза почитать.
что то мне подсказывает, что вычисление ХЭШа, как раз таки, операция весьма не сложная.
Именно поэтому скорости вычисления ХЭШей столь велики на видекартах (мегахэшей/сек)
Сложность в другом: сложность найти «правильный» ХЭШ. То есть такой (на примере биткоина), который не превышает определенного значения (содержит определенное кол-во нулей в своем начале. Типа вот такого: 000000000000000kgggjhfsyywG). И чем больше нулей в начале, тем сложнее… Потому как надо «попадать» результатом все время в меньшее множество возможных правильных ХЭШей.
Именно эта сложность и гарантирует то, что никто не сможет изменить прошлые данные ибо ни один участник сети не обладает достаточной скоростью для того, чтобы обогнать остальную сеть, начав изменять что то в прошлом.
надеюсь, что продолжение будет.
Потому что уже достаточно случаев, когда заявлялись циклы статей, но после первой/реже второй все останавливалось.
так что, надеюсь, что автор не бросит писать )
такие, которые хранят на конкретной машине всю цепочку блоков и синхронизуют ее с остальной сетью. В майнинге они могут не участвовать, но цепочку синхронизуют постоянно.
уже сейчас полная цепочка блоков «весит» что то около 160 ГБ… а ведь это только начало…
И ведь она, как энтропия, будет только расти. И отрубить старые блоки нельзя, потому что работать перестанет.
В общем я в этом очень серьезную проблему биткоина вижу.
Это на текущий момент отсекает от локальных кошельков разного рода мобильные устройства.
А хранить «кровные» на сетевых площадках — не каждый решится.
в общем мне не понятно, как у молодого автора процесс/поток (в общем — единица планирования) может переходить из состояния «заблокирован» сразу в состояние «выполняется»
попробуйте, для начала из состояния «собран» на кубике «офлайн» какой нить простенький алгоритм и одновременно его же на Flat Cubik_e. Просто чтобы понять связь между ними.
Все должно работать совершенно одинаково.
С удовольствием наблюдаю, как отдельные пользователи в Гейм Центре упорно продвигаются вверх (по шагам сборки, так и по времени).
1) к сожалению, мой уровень математической подготовки не достаточен, чтобы получать эти самые 20 ходов из любой текущей комбинации. Это исправимо самообразованием. Но есть и второе «но»:
2) мне бы хотелось давать пользователю какие то осмысляемые им ходы. Другими словами, чтобы он понимал логику хода. Почему он сделан именно так. Сильно сомневаюсь, что ходы в соотвествии со стратегией «числа Бога» могут быть осмыслены на уровне бытовой логики.
Человеческий разум легко поймет послойную сборку. Она не оптимальна, но с точки зрения разума она более понятна и может быть не просто понята, но и ей можно научить.
в iOS 9.x некорректно работают некоторые функции в SpriteKit
в iOS 10 (и уже в iOS 11) они работают правильно.
C учетом статистических данных Apple — доля iOS 9 и младше достаточно мала и продолжает уменьшаться.
Кроме того, если бы я принял решение запрашивать версию iOS и потом в зависимости от нее вызывать метод из SK или его самодельный аналог. На данном этапе решил этого не делать. Это если кратко.
Сейчас решил установить симулятор iOS 9, чтобы еще раз посмотреть на то, о чем я говорю. Один и тот же код ведет себя по разному в iOS 9 и iOS 10
спасибо за вопрос, коллега.
отвечаю: программу можно сделать расширяемой. Хоть и не без некоторых трудностей. Другими словами в настоящий момент нельзя просто задать некую переменную, обозначающую кол-во строк/столбцов на каждой грани, но к этому можно привести, если задаться такой целью. Какие то вещи там уже написаны с учетом такой возможности. Какие то надо изменять.
Одна из основных причин, почему данная цель не преследовалась сразу: разрешение плитки. Для iPhone 5/5s/SE это значение 58*58 точек (соотвественно, 29*29 в координатах экрана). Потому что мне надо было разместить 9*12 плиток на экране + некий «защитный интервал» с каждой стороны по горизонтали. По итогу даже в варианте 3*3 на 5/5s/SE выглядит уже мелковато и, я считаю, где то на грани комфортности. Более мелкая плитка (допустим, 4*4) привела бы к трудностям такого плана: надо было разместить 12*16 плиток. Берем физическое разрешение 5/5s/SE 640*1136 и видим, что 640/14 = 45.7 (можем округлить до 46), то есть 46*46 это физический размер в точках для 1 плитки (или 23*23 логический), делитель 14 — с учетом защитного интервала (экран вытянутый по вертикали, поэтому о вертикали тут не беспокоимся). Уже мелковато совсем. 5*5 дало бы еще более мелкую плитку.
Тут другое: тут сразу появляются желающие за 10 рублей откатить эту тележку к месту ее парковки. Ну как то так…
и в примере в криками зверей их было бы логичнее использовать, а не наследование
Просто расширить класс Animal категорией с реализацией метода возврата крика. И тогда у каждого, кто был Animal в проекте автоматически бы появился этот метод.
Да и многие из тут присутствующих тоже, когда на пляже «накапывали» (от слова «капля») замки из песка (метод капель и подтеков, когда вы сжимаете в ладони горсть чрезвычайно мокрого песка и держите руку над постройкой, давая песку возможность, капая сверху, создавать причудливые фентезийные башни). В чистом виде 3D печать.
10 типов структур данных, которые нужно знать + видео и упражнения
кому интересно )
реально это разные вещи!
а многие ведь Докинза не читали.
Начните с «Эгоистичный ген», а потом уже и другие его книжки.
Так вот, Докинз пишет, что гены это не набор чертежей, а своего рода «рецепт приготовления».
Само же «приготовление» подвергается воздействию многих внешних факторов. Поэтому однояйцевые близнецы могут иметь отличия. Как вариант влияния могу предложить некоторую неравномерность поступления питательных веществ, каких то гормонов от матери. Вот вам и несколько разный результат при приготовлении по одному рецепту.
ПС: немного про отличия «чертежа» и «рецепта». В чертеже можно точно указать, какой элемент на нем соотвествует какому элементу в конструкции… в рецепте же этого указать почти никогда нельзя. По кусочку булки вы не покажите на место в рецепте…
Ну как то так. Хотя, еще раз, советую все таки Докинза почитать.
как печатать на старых принтерах???
вообще о людях не думают.
Именно поэтому скорости вычисления ХЭШей столь велики на видекартах (мегахэшей/сек)
Сложность в другом: сложность найти «правильный» ХЭШ. То есть такой (на примере биткоина), который не превышает определенного значения (содержит определенное кол-во нулей в своем начале. Типа вот такого: 000000000000000kgggjhfsyywG). И чем больше нулей в начале, тем сложнее… Потому как надо «попадать» результатом все время в меньшее множество возможных правильных ХЭШей.
Именно эта сложность и гарантирует то, что никто не сможет изменить прошлые данные ибо ни один участник сети не обладает достаточной скоростью для того, чтобы обогнать остальную сеть, начав изменять что то в прошлом.
ну как то так в общем )))
Потому что уже достаточно случаев, когда заявлялись циклы статей, но после первой/реже второй все останавливалось.
так что, надеюсь, что автор не бросит писать )
И ведь она, как энтропия, будет только расти. И отрубить старые блоки нельзя, потому что работать перестанет.
В общем я в этом очень серьезную проблему биткоина вижу.
Это на текущий момент отсекает от локальных кошельков разного рода мобильные устройства.
А хранить «кровные» на сетевых площадках — не каждый решится.
тут вроде как ситуация схожая с перепродажей?
Все должно работать совершенно одинаково.
С удовольствием наблюдаю, как отдельные пользователи в Гейм Центре упорно продвигаются вверх (по шагам сборки, так и по времени).
ПС: спасибо за комментарий
есть пара «но»:
1) к сожалению, мой уровень математической подготовки не достаточен, чтобы получать эти самые 20 ходов из любой текущей комбинации. Это исправимо самообразованием. Но есть и второе «но»:
2) мне бы хотелось давать пользователю какие то осмысляемые им ходы. Другими словами, чтобы он понимал логику хода. Почему он сделан именно так. Сильно сомневаюсь, что ходы в соотвествии со стратегией «числа Бога» могут быть осмыслены на уровне бытовой логики.
Человеческий разум легко поймет послойную сборку. Она не оптимальна, но с точки зрения разума она более понятна и может быть не просто понята, но и ей можно научить.
Так ведь?
в iOS 10 (и уже в iOS 11) они работают правильно.
C учетом статистических данных Apple — доля iOS 9 и младше достаточно мала и продолжает уменьшаться.
Кроме того, если бы я принял решение запрашивать версию iOS и потом в зависимости от нее вызывать метод из SK или его самодельный аналог. На данном этапе решил этого не делать. Это если кратко.
Сейчас решил установить симулятор iOS 9, чтобы еще раз посмотреть на то, о чем я говорю. Один и тот же код ведет себя по разному в iOS 9 и iOS 10
отвечаю: программу можно сделать расширяемой. Хоть и не без некоторых трудностей. Другими словами в настоящий момент нельзя просто задать некую переменную, обозначающую кол-во строк/столбцов на каждой грани, но к этому можно привести, если задаться такой целью. Какие то вещи там уже написаны с учетом такой возможности. Какие то надо изменять.
Одна из основных причин, почему данная цель не преследовалась сразу: разрешение плитки. Для iPhone 5/5s/SE это значение 58*58 точек (соотвественно, 29*29 в координатах экрана). Потому что мне надо было разместить 9*12 плиток на экране + некий «защитный интервал» с каждой стороны по горизонтали. По итогу даже в варианте 3*3 на 5/5s/SE выглядит уже мелковато и, я считаю, где то на грани комфортности. Более мелкая плитка (допустим, 4*4) привела бы к трудностям такого плана: надо было разместить 12*16 плиток. Берем физическое разрешение 5/5s/SE 640*1136 и видим, что 640/14 = 45.7 (можем округлить до 46), то есть 46*46 это физический размер в точках для 1 плитки (или 23*23 логический), делитель 14 — с учетом защитного интервала (экран вытянутый по вертикали, поэтому о вертикали тут не беспокоимся). Уже мелковато совсем. 5*5 дало бы еще более мелкую плитку.