Какие функциональные методы языка могут использоваться на императивных языках?
Используйте apply с лямбда-функцией и index с обратным lists, это хорошо работает, потому что списки основаны на 0, проиндексированы в python:
df['count'] = df['A'].apply(lambda x: x[::-1].index('DePe*'))
print (df)
A count
0 [ch*, co*, DePe*, DePe*, DePe*, pm*, tpm*, lep*] 3
1 [ch*, co*, DePe*, DePe*, DePe*, am*, te*, qe*,... 4
2 [ch*, co*, DePe*, ch*, DePe*, DePe*, tpm*, lep*] 2
3 [ch*, DePe*, eeae*, ps*, er*] 3
Если возможно, какое-то значение не существует, возможно укажите значение в выражении try-except:
def f(x):
try:
return x[::-1].index('DePe*')
except ValueError:
return np.nan #or return 0
df['count'] = df['A'].apply(f)
4 ответа
В большой степени все они?
Если Вы понимаете функциональные языки, можно записать обязательные программы, которым "сообщает" функциональный стиль. Это уведет Вас от побочных эффектов, и к программам, в которых чтение текста программы в какой-то конкретной точке достаточно, чтобы позволить Вам действительно знать то, что значение программы в той точке.
Назад в Рассвет Времени мы раньше волновались о "связи" и "сцеплении". Изучение FP приведет Вас писать системы с оптимальной (минимальной) связью и высокую связность.
Вот вещи, которые мешают выполнению FP на языке неFP:
- Если язык не поддерживает лямбду/закрытия и не имеет никакого синтаксического сахара к легко главным образом взлому это, Вы мертвы в воде. Вы не называете карту/фильтр без закрытий.
- Если язык со статическим контролем типов и не поддерживает дженериков, Вы мертвы в воде. Весь хороший FP наполняет степень универсальности использования.
- Если язык не поддерживает хвостовую рекурсию, Вам препятствуют. Можно записать реализации, например, 'отобразиться' многократно; также часто Ваши данные не могут быть слишком большими, и рекурсия будет в порядке.
- Если язык не будет поддерживать алгебраические типы данных и сопоставление с образцом, то Вам мягко препятствуют. Это является просто раздражающим, чтобы не иметь их, после того как Вы испытали их.
- Если язык не может выразить классов типа, ну, в общем, о, хорошо... Вы будете продвигаться, но чинить, если это не будет просто awesomest функцией никогда, но и Haskell является единственным удаленно популярным языком с хорошей поддержкой.
Я успешно использовал функции высшего порядка много, особенно вид, которые передаются в, а не вид, которые возвращаются. Вид, которые возвращаются, может быть немного утомительным, но может быть моделирован.
Все виды применимых структур данных и рекурсивных функций работают хорошо на императивных языках.
Вещи я отсутствую больше всего:
Почти никакие императивные языки не гарантируют, что оптимизировали каждый последний вызов.
Я не знаю ни о каком императивном языке, который поддерживает анализ случая сопоставлением с образцом.
Не наличие в первом классе функционирует, действительно помещает увлажнитель на запись функциональных программ, но существует несколько вещей, которые можно сделать, которые не требуют их. Первое должно сторониться изменяемого состояния - пытаются иметь больше всего, или все Ваши классы возвращают новые объекты, которые представляют измененное состояние вместо того, чтобы внести изменение внутренне. Как пример, если Вы писали связанный список с add операция, Вы хотели бы возвратить новый связанный список из add в противоположность изменению объекта.
В то время как это может сделать Ваши программы менее эффективными (из-за увеличенного числа объектов, создаваемых, и уничтоженных) Вы получите способность более легко отладить программу, потому что состояние и операция объектов становятся более предсказуемыми, не говоря уже о способности вложить вызовы функции более глубоко, потому что у них есть вводы и выводы состояния.