- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 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))
Побывать на питоне - это открыть его для себя? Побывал, и очень давно. Что теперь надо делать?
Решил смоделировать на жабе довольно простую, как мне казалось, вещь - числа. Целые, Рациональные, Комплексные, и т.п. При этом хотелось, чтобы операции над рациональными могли возвращать Целые, если знаменатель стал единичным, а комплексные могли превращаться в рациональные или целые. Т.е. чтобы результатом каждой операции было максимально простой тип числа.
В общем, "ООП" подход тут не привёл ни к чему хорошему. Получилась какая-то нерасширяемая жесть и свитчи по типам.
Понятно, что на каком-нибудь Haskell тоже ничего хорошего тут не выйдет - тип возвращаемого значения зависит от рантайм-аргументов. Тут нужна динамическая питузация.
Зато сейчас мне понятно, что тут надо "альтернативное" ООП - подобные отношения легко моделируются и расширяются в CLOS.
Но визитор - тоже нерасширяемое говно. При добавлении нового типа числа нужно идти и править исходники, в которых определены предыдущие типы чисел.
В CLOS есть мультиметоды, что даёт возможность добавлять реализации, практически не изменяя уже написанного кода.
Так основные паттерны - свитч и костыль
wvxvw был прав. Всегда.
1 + i*0.10842021724855044e-00018
ну короче ты понял, да? В дискретных случаях, типа рациональное-целое, это может работать, а когда всё плавает, то хуюшки.
Опять же, многое зависит от реализации функции exp. Можно специализировать в ней логику работы с комплексными числами. Чтобы разруливать штуки вроде exp(ln 5), конечно, уже нужны символьные вычисления.