dmshar

"Грокаем алгоритмы". Насколько она хороша? - хороша. Изучайте.

Что можете посоветовать ещё? - ну,например, https://superstudy.guide/algorithms-data-structure... Достаточно сжато, понятно, все необходимое на месте и без заумствования.

На что обратить большее внимание при ознакомлении? - странный вопрос. Вы выбираете книгу и учите. А не "обращаете внимание" и торгуетесь "что больше, что меньше, а что может вообще пропустить" .

Уважаемый mayton2019 дал в общем-то почти исчерпывающий ответ. Но раз вы задали этот вопрос "из возникшего интереса", то есть шанс, что и другим ответы данной темы будут интересы, потому попробую еще чуть-чуть дополнить упомянутый ответ.

Возможно многие и не слышали, но тем не менее существуют т.н. In-memory database (по-русски это, кажется, называется "Резидентная база данных", но я не уверен). Применяются такие системы как правило в высоконагруженных приложениях - в системах провайдеров телекоммуникационных услуг, когда-то читал - что в системах он-лайн биржевой торговли и пр. Там где данных очень много и доступ к ним нужен очень быстро. И главное - владелец таких данных оччччеееень богатенький, что-бы позволить себе приобрести оборудование с объемом оперативной памяти сопоставимым с объемом внешней памяти для "обычных" серверов баз данных. И вот тогда, для таких задач все данные СУБД, включая все индексы и другой служебно-вспомогательной информации, загоняются в оперативную память, обеспечивая и нужную скорость доступа и удобство доступа, которое обычно присуще СУБД.
Главнейшая проблема, которую решают разработчики таких систем - как обеспечить целостности базы данных при внезапной перезагрузке систем. Это влияет на производительность In-memory database, заставляя тратить часть вычислительных ресурсов на синхронизацию данных в ОП и резервных копий на внешней памяти.
Список таких систем можно, кстати, найти даже в Википедии:
https://en.wikipedia.org/wiki/List_of_in-memory_da...

Если же "спуститься" с небес на землю и учесть финансовые возможности "нормального" пользователя, то например, в языке программирования Python есть такой модуль - Pandas. По сути он дает удобство доступа к данным, почти такое-же (а может и еще большее) как SQL, сохраняя таблицы в ОП. А скорость обработки - сопоставимую с реализацией на "голых" массивах, а для сложных поисковых запросов - и еще большую. Естественно, что объем таблиц (DataFrame в терминологии Pandas) не может быть слишком большим. И не смотря на то, что есть прямой шлюз для перехода от DataFrame к SQL-структурам СУБД и обратно, скорость работы "в памяти" на много выше, чем скорость работы с теми-же данными, выгруженными в БД. Поэтом программист может комбинировать работу DataFrame для скорости обработки и СУБД для долговременно энергонезависимого хранения, найдя приемлемый для своего приложения компромисс.

А какое-бы значение атрибута вы бы хотели получить, обращаясь к классу, а не к объекту??

А вообще-то, например, вот так:

import numpy as np
arr=np.empty(10)
for item in dir(arr):
    print(item, getattr(arr,item))

Ну, или что-бы хоть немного просеять тот шлак, который от такого весьма странного действия вы получите, можно сделать вот так:

interesting_methods = [method for method in dir(arr) if method.startswith('__') is False]   
for item in interesting_methods:
    print(item, getattr(arr,item))

Тоже, конечно, не понятно, что вы с этой информацией делать то собираетесь, но в выдаче, если порыться, можно найти осмысленную информацию, которую вы как бы проверяете.

Встречались мне такое понятие, даже в Википедии оно присутствует:
https://ru.wikipedia.org/wiki/Нейро-нечёткие_системы
или вот даже книжечка на этот счет есть
https://studme.org/133119/informatika/intellektual...

Если лично мое мнение, то несмотря на то, что первую вышедшею на русском языке книгу Лотфи Заде про нечеткие множества, логику, лингвистические переменные и прочее я прочитал еще в 1977 году, и потом достаточно долго этой темой увлекался - постепенно мое отношение стало абсолютно скептическим. Не вижу прикладных задач, в которых этот аппарат позволил бы решить хоть какую-то задачу быстрее, красивее, проще и пр., чем без ее применения.
Но если надо посмотреть - то ссылочки вверху. Копайте.

У вас ошибка связана с импортом.

import datetime as dt
print(dt.datetime.now()+dt.timedelta(seconds=1))

Результат:
2023-03-26 14:16:33.012528

Непонятно все-же, в чем вопрос?
Вы написали свое видение разбивки времени суток на неформальные интервалы так, как вы это видите. У кото-то может быть другое видение (например - только "первая половина дня", "вторая половина дня", "ночь" или любая другая. Единой разбивки нет и быть не может. Значит, это не вопрос.
Второе, вы написали, что хотите добавить столбец в датафрейм. Как это сделать - причем так, что-бы он заполнялся по вашему условию - показываю ниже. Я НЕ решаю вашу задачу, я показываю принцип решения. А уж подправить его так, что-бы он и на вашем датафрейме и на ваших данных работал, у условие ваше проверял - оставляю вам. Надеюсь, справитесь.

df=pd.DataFrame({'A':[1,2,3,4,5,6,7,8,9,10]})
def foo(dt):
    if dt<=3:
        ret='A'
    elif dt<=7:
        ret='B'
    else: 
        ret='C'
    print (ret)
    return ret
df['B']=df.apply(lambda x: foo(x['A']), axis= 1 )

P.S.И да, Jupiter файл сюда не загружают, загружают чистый код, составленный так, что-бы каждый мог его себе скопировать, запустить, получить результат и возможно как-то его подправить.