1. Python / Говнокод #18929

    −11

    1. 01
    2. 02
    3. 03
    4. 04
    5. 05
    6. 06
    7. 07
    8. 08
    9. 09
    10. 10
    11. 11
    12. 12
    def lkm(seed, a, c, m, l, pre=lambda e:e, post=lambda e:e):
        v = [pre(seed)]
        
        for i in range(l - 1):
            v += [pre((a*v[i]+c)%m)]
            
        for i in range(l):
            v[i] = post(v[i])
            
        return v
        
    print (lkm(42, 42, 4242, 424242, 100, post=lambda e:e>>4))

    Линейный конгруэнтный генератор случайных чисел с изменяемыми параметрами от ведущих говнокриптографов!

    Запостил: gost, 28 Октября 2015

    Комментарии (22) RSS

    • И самое главное, что на Питоне!
      Ответить
    • Чуть-чуть улучшим показатели...
      class GPSCH:
          def __init__(self, seed):
              self._index = 0
              self._MT = [seed]
              
              for i in range(1, 624):
                  self._MT += [(0x6c078965 * (self._MT[i - 1] ^ (self._MT[i - 1] >> 30)) + i) & 0xFFFFFFFF]
              
          def _mix(self):
              for i in range(624):
                  y = (self._MT[i] & 0x80000000) + (self._MT[(i + 1) % 624] & 0x7fffffff)
                  self._MT[i] = self._MT[(i + 397) % 624] ^ (y >> 1)
                  
                  if (y % 2) != 0:
                      self._MT[i] = self._MT[i] ^ 0x9908b0df
                  
          def get_number(self):
              if self._index == 0:
                  self._mix()
                  
              y = self._MT[self._index]
      
              y = y ^ (y >> 11)
              y = y ^ ((y << 7) & 0x9d2c5680)
              y = y ^ ((y << 15) & 0xefc60000)
              y = y ^ (y >> 18)
      
              self._index = (self._index + 1) % 624
              return y
              
      gen = GPSCH(42)
      for _ in range(99):
          print(gen.get_number(), ', ', end = '', sep = '')
          
      print(gen.get_number())
      Ответить
      • Нафиг ты это пишешь, тем более на питоне?
        Ответить
        • Пока не побывал напитоне - не поймешь.
          Ответить
          • А ты уже побывал? Расскажи как оно.

            Побывать на питоне - это открыть его для себя? Побывал, и очень давно. Что теперь надо делать?
            Ответить
            • Побывать - это сходить напитон.
              Ответить
              • И как, сходил?
                Ответить
                • Как может человек, сходивший напитон, писать такое говно, как в этом ГК (и в комментарии выше)?
                  Ответить
      • На пистоне такие вещи лучше делать функцией генератором, ооп тут нинужно
        Ответить
        • Я даже в матлабе иногда ООП использую, лол.
          Ответить
          • Я отчётливо помню один из первых своих экспериментов в ООП...

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

            В общем, "ООП" подход тут не привёл ни к чему хорошему. Получилась какая-то нерасширяемая жесть и свитчи по типам.

            Понятно, что на каком-нибудь Haskell тоже ничего хорошего тут не выйдет - тип возвращаемого значения зависит от рантайм-аргументов. Тут нужна динамическая питузация.

            Зато сейчас мне понятно, что тут надо "альтернативное" ООП - подобные отношения легко моделируются и расширяются в CLOS.
            Ответить
            • Паттерн какой-нибудь вроде визитора подойти должен.
              Ответить
              • Тут нужен типичный double dispatch engine, способов реализации которого довольно много. В частности, visitor, да.
                Но визитор - тоже нерасширяемое говно. При добавлении нового типа числа нужно идти и править исходники, в которых определены предыдущие типы чисел.

                В CLOS есть мультиметоды, что даёт возможность добавлять реализации, практически не изменяя уже написанного кода.
                Ответить
            • >> Получилась какая-то нерасширяемая жесть и свитчи по типам.

              Так основные паттерны - свитч и костыль
              Ответить
            • >Зато сейчас мне понятно, что тут надо "альтернативное" ООП - подобные отношения легко моделируются и расширяются в CLOS.

              wvxvw был прав. Всегда.
              Ответить
            • Сама идея говно, вот вычисли exp(2*i*pi), ну и нихрена эта штука не кастанётся в целое, потому что это будет что-то типа
              1 + i*0.10842021724855044e-00018
              ну короче ты понял, да? В дискретных случаях, типа рациональное-целое, это может работать, а когда всё плавает, то хуюшки.
              Ответить
              • Я хотел ограничиться базовой алгеброй, без экспонент и прочих сложностей, понятно, что с питухом всё уплывёт. Тут гораздо важнее была именно образовательная составляющая.

                Опять же, многое зависит от реализации функции exp. Можно специализировать в ней логику работы с комплексными числами. Чтобы разруливать штуки вроде exp(ln 5), конечно, уже нужны символьные вычисления.
                Ответить
              • Опять плавающий питух все портит
                Ответить
            • в PHP что-то подобное из коробки
              Ответить

    Добавить комментарий