All streams
Search
Write a publication
Pull to refresh
-30
@LordDarklightread⁠-⁠only

Пользователь

Send message

Что первичнее - материя или энергия, и насколько вообще корркеткно ставить такой вопрос.

Но сначала надо всё-так и определиться - чем принципиально отличается материя от энергии! Пока квантовые физики плавают в этом вопросе. Да - придумали Бозон хигса - но, по сути, так и не определили в чём же главная суть этой эээ скажу грубо "частицы - задающей массу покоя" от того же "фотона". Но простите, я не разбираюсь в теории поля Хигса - не знаю как оно определяет массу! И надо ли считать что наличие массы - и задаёт материю (хотя частицы с массой всё равно ещё будут связаны и с энергией - ведь в покое они не могут быть). И, всё-таки, у всех ли частиц, кроме фотона, таки есть масса (даже с нейтрино пока до конца не разобрались)!

Есть формула Эйнштейна = E=mc2 - из которой прямо следует - что масса - это фикция (ну если она априори верна для всей вселенной) - обратное опровергается - тем же фотоном - у которого есть энергия без массы (хотя... опять же мы не знаем это наверняка) - поэтому нельзя сказать, что энергия - это фикция! Тогда как берётся масса! Поле хигса - для меня это очень абстрактно!

Вот, теория струн, вполне себе понятно объясняет - что масса - это особый колебательный процесс одномерной струны (правда сейчас уже говорят про многомерные браны - но на мой взгляд это просто разные уровни абстракции одного и того же - просто с одномерными струнами пока математика просто запредельная и не работает, а с бранами - она ещё запредельнее - но, кажется, не работает лучше). Но не суть. А суть в том - что есть колебания - это и есть энергия - это изменения величин свойств информационного пространства - то есть та пресловутая масса покоя - это тоже движения - т.е. периодическое изменение свойств пространства! Но это я так - просто порассуждал.

С массой есть ещё одна важная связь - опять же постулируемая Эйнштейном - это зависимость скорости времени (дифференциал изменения времени) от массы (честно - лень искать сложную формулу). Тут уже надо ставить вопрос - а что есть время? Очень сложный вопрос - ещё сложнее чем вопрос про массу! Я отвечаю так - время - это всего-лишь "скорость изменения процессов" - т.е. это альтернатива скорости - а скорость - это метрика пространства - в которой и ведётся, условно, "измерение" физ величин. То есть пространство, заданное информационным полем, определяет течение времени и все процессы! И можно представить, опять же, условно, применяя теорию струн (для простоты, я не постулирую - что она верна в своём нынешнем виде) - что колебательные процессы элементарных частиц задают эти свойства пространства - т.к. сами колебательные процессы константны - то только их сочетания влияют на эти свойства - и, как следствие - на изменения величин в протекающих процессах - и на ход времени - что будет лишь абстрактным измерением, которые мы, по своей природе, можем легко (но относительно) измерять!

В конце замечу, что я ничего не постулирую и не утверждаю! Это просто моё мнение и мои рассуждения. Если в чём-то явно ошибаюсь - поправьте меня, пожалуйста

Это очень спорно.

Питон активно начали применять для машинного обучения и биг дата - а там нужна как раз производительность, и бережное обращение с ресурсами компьютера (от чего и возник Mojo). И если на Питоне можно что-то делать заметно быстрее - то об этом, хотя бы, надо знать - и применять когда потребуется!

А насчёт высокой читаемости... без аннотации типов (хотя в Питоне как раз есть, прилепленные абы-как, декораторы типов - но их читаемость просто кошмарна) и с отступами - как границы блоков - Питон никак не может претендовать на лидерство по показателю читаемости.

Хотя изучать Питон действительно не сложно, по сравнению с абсолютным большинством других современных ЯП - но Вы же сделали акцент на читаемости...

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

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

Тоже решение....

Yо по моим замерам (для 100000 эл и условием < 5)

Elapsed time1: 0.00193721
Elapsed time2: 0.00345866
Elapsed time2 faster: -78.5383 % (slower)

time2 c "comprehension" медленнее, чем

for i in reversed(numbers):
if i < 5:
numbers.remove(i)

(для 1000 эл и условием < 5)

Elapsed time1: 0.00003276
Elapsed time2: 0.00004120
Elapsed time2 faster: -25.7631 % (slower)

time2 c "comprehension" медленнее, чем

code_to_test ="""
for i in reversed(numbers):
if i < 5:
numbers.remove(i)
"""

Но если нужно удалить много элементов (для 100000 эл и условием < 99900)

Elapsed time1: 48.81116155
Elapsed time2: 0.00183190
Elapsed time2 faster: 2664410.1563 %

Разница огромна!

Конечно - это классика - когда убрать нужно больше, чем оставить - всегда будут более эффективны методы, которые не удаляют а копируют!

Даже такой код проиграет вашему варианту "comprehension" (для 100000 эл и условием < 99900)

for i in range(1-sz,0):
if numbers[-i] < 5:
del numbers[-i]

Elapsed time1: 0.00863603
Elapsed time2: 0.00179269
Elapsed time2 faster: 381.7358 %

P.S.

Расчёт %

percent = 100*elapsed_time1/elapsed_time2-100 if elapsed_time1 >=elapsed_time2 else -100*elapsed_time2/elapsed_time1+100

К своему ужасу нашёл более серьёзный ляп - примеры с range с фикс границей неверны: второй тест в них вообще ничего не удалял (это два последних сценария)! Да - далеко мне ещё до джуна в питоне...

Но если обновлять - то надо обновлять все тесты - поэтому просто приведу багфикс

Багфикс второго теста для последних двух сценариев
code_to_test =""" 
for i in range(1-sz,0): 
  if  numbers[-i] < 5: 
    del numbers[-i] 
"""

Но тут есть нюанс - т.к. сценариях тестирования выше не учитывается восстановление списка перед следующей итерацией - то вторая итерация уже не пройдёт с таким же размером - т.к. список станет меньше

Сам же об этом вначале написал - сам же и ошибся - а вы тут к джунам придираетесь... Так что пример для тестирования при приёме вполне на работу хороший! Здесь есть о чём поговорить...

Замеры

Тогда для 1000 элементов замеры будут (в 1-ой итерации, чтобы не переделывать весь тест)

Elapsed time1: 0.00001556
Elapsed time2: 0.00004325
Elapsed time2 faster: -177.96 %

"del" продолжает сильно отставать на небольшом числе удаляемых элементов

Для 100000 элементов

Elapsed time1: 0.00133854
Elapsed time2: 0.00375475
Elapsed time2 faster: -180.51 %

Тенденция та же.

Ну а в остальном - надо бы сценарии тестирования переделать (две проблемы я обозначил в предыдущем комментарии) - и тогда можно будет ещё раз всё проанализировать!

Пытался определить профит от второго подхода к удалению (и обходу)

Тестировал тут:

https://www.programiz.com/python-programming/online-compiler/

сразу замечу - что во всех примерах замера есть грубая ошибка - она не влияет на результат, но влияет на точность - о ней в конце комментария (найдёте сами)?

Случайный список на 100 000 эл от 0 до 1 000 удаляем до 5
import numpy as np
import timeit as tm

##numbers = list(range(0, 100000))
numbers = list(np.random.randint(0, 1000, 100000))
numbers2 = numbers.copy()
code_to_test ="""
for i in reversed(numbers):
  if i < 5:        
    numbers.remove(i)
"""
elapsed_time1 = tm.timeit(code_to_test, globals={'numbers':numbers}, number=100, )/100
##print(numbers)
formatted = f"{elapsed_time1:{10}.{8}f}"
print('Elapsed time1: ', formatted)

code_to_test ="""
for i in range(-len(numbers),0):
  if  numbers[i] < 5:        
    del numbers[i]
"""
elapsed_time2 = tm.timeit(code_to_test, globals={'numbers':numbers2}, number=100, )/100
##print(numbers)
formatted = f"{elapsed_time2:{10}.{8}f}"
print('Elapsed time2: ', formatted)

formatted = f"{(100-elapsed_time2/elapsed_time1*100):{4}.{2}f}"
print('Elapsed time2 faster: ', formatted,'%')

Результат получился очень не стабильный

Elapsed time1: 0.00916025
Elapsed time2: 0.00800321
Elapsed time2 faster: 12.63 %

Elapsed time1: 0.00789614
Elapsed time2: 0.00644334
Elapsed time2 faster: 18.40 %

Elapsed time1: 0.01707251
Elapsed time2: 0.00614484
Elapsed time2 faster: 64.01 %

Elapsed time1: 0.01099221
Elapsed time2: 0.01151114
Elapsed time2 faster: -4.72 %

Но профит имеет очень большой разброс: до 70% в лучшую сторону и до -98% в худшую - наверное производительность облачной среда нестабильна... ну или дело в случайном распределении

Но чаще это всё же +20..+30%

Но это очень малое число удаляемых элементов

Случайный список на 100 000 эл от 0 до 1 000 удаляем до 50 000
import numpy as np
import timeit as tm

##numbers = list(range(0, 100000))
numbers = list(np.random.randint(0, 1000, 100000))
numbers2 = numbers.copy()
code_to_test ="""
for i in reversed(numbers):
  if i < 50000:        
    numbers.remove(i)
"""
elapsed_time1 = tm.timeit(code_to_test, globals={'numbers':numbers}, number=100, )/100
##print(numbers)
formatted = f"{elapsed_time1:{10}.{8}f}"
print('Elapsed time1: ', formatted)

code_to_test ="""
for i in range(-len(numbers),0):
  if  numbers[i] < 50000:        
    del numbers[i]
"""
elapsed_time2 = tm.timeit(code_to_test, globals={'numbers':numbers2}, number=100, )/100
##print(numbers)
formatted = f"{elapsed_time2:{10}.{8}f}"
print('Elapsed time2: ', formatted)

formatted = f"{(100-elapsed_time2/elapsed_time1*100):{4}.{2}f}"
print('Elapsed time2 faster: ', formatted,'%')

Увеличили число удалений и...

Elapsed time1: 0.57216662
Elapsed time2: 0.00870751
Elapsed time2 faster: 98.48 %

Elapsed time1: 0.56662485
Elapsed time2: 0.00851610
Elapsed time2 faster: 98.50 %

Elapsed time1: 0.53011499
Elapsed time2: 0.00814618
Elapsed time2 faster: 98.46 %

Elapsed time1: 0.51840861
Elapsed time2: 0.00742513
Elapsed time2 faster: 98.57 %

Elapsed time1: 1.39908564
Elapsed time2: 0.01798840
Elapsed time2 faster: 98.71 %

Результат стал куда более стабильным (и куда более убедительным) - значить всё-таки дело в случайном распределении и количестве удалений

Линейный список на 100 000 эл от 0 до 100 000 удаляем до 99 900
import numpy as np
import timeit as tm

numbers = list(range(0, 100000))
##numbers = list(np.random.randint(0, 1000, 100000))
numbers2 = numbers.copy()
code_to_test ="""
for i in reversed(numbers):
  if i < 99900:        
    numbers.remove(i)
"""
elapsed_time1 = tm.timeit(code_to_test, globals={'numbers':numbers}, number=100, )/100
##print(numbers)
formatted = f"{elapsed_time1:{10}.{8}f}"
print('Elapsed time1: ', formatted)

code_to_test ="""
for i in range(-len(numbers),0):
  if  numbers[i] < 99900:        
    del numbers[i]
"""
elapsed_time2 = tm.timeit(code_to_test, globals={'numbers':numbers2}, number=100, )/100
##print(numbers)
formatted = f"{elapsed_time2:{10}.{8}f}"
print('Elapsed time2: ', formatted)

formatted = f"{(100-elapsed_time2/elapsed_time1*100):{4}.{2}f}"
print('Elapsed time2 faster: ', formatted,'%')

Для чистоты эксперимента результаты замера для стабильного линейного списка

Elapsed time1: 0.57401052
Elapsed time2: 0.00887311
Elapsed time2 faster: 98.45 %

Elapsed time1: 0.48925159
Elapsed time2: 0.00906931
Elapsed time2 faster: 98.15 %

Elapsed time1: 0.53471360
Elapsed time2: 0.00735231
Elapsed time2 faster: 98.63 %

Elapsed time1: 0.54302151
Elapsed time2: 0.00813783
Elapsed time2 faster: 98.50 %

Elapsed time1: 0.57180185
Elapsed time2: 0.00884042
Elapsed time2 faster: 98.45 %

По сути ничего не изменилось - много удалений - оператор "del" рулит!

Линейный список на 1 000 эл от 0 до 1 000 удаляем до 5
import numpy as np
import timeit as tm

numbers = list(range(0, 1000))
##numbers = list(np.random.randint(0, 1000, 100000))
numbers2 = numbers.copy()
code_to_test ="""
for i in reversed(numbers):
  if i < 5:        
    numbers.remove(i)
"""
elapsed_time1 = tm.timeit(code_to_test, globals={'numbers':numbers}, number=100, )/100
##print(numbers)
formatted = f"{elapsed_time1:{10}.{8}f}"
print('Elapsed time1: ', formatted)

code_to_test ="""
for i in range(-len(numbers),0):
  if  numbers[i] < 5:        
    del numbers[i]
"""
elapsed_time2 = tm.timeit(code_to_test, globals={'numbers':numbers2}, number=100, )/100
##print(numbers)
formatted = f"{elapsed_time2:{10}.{8}f}"
print('Elapsed time2: ', formatted)

formatted = f"{(100-elapsed_time2/elapsed_time1*100):{4}.{2}f}"
print('Elapsed time2 faster: ', formatted,'%')

Но не всё так просто

Elapsed time1: 0.00001946
Elapsed time2: 0.00006619
Elapsed time2 faster: -240.17 %

Elapsed time1: 0.00001747
Elapsed time2: 0.00006330
Elapsed time2 faster: -262.34 %

Elapsed time1: 0.00001142
Elapsed time2: 0.00003949
Elapsed time2 faster: -245.94 %

Elapsed time1: 0.00001370
Elapsed time2: 0.00006343
Elapsed time2 faster: -362.89 %

Elapsed time1: 0.00001156
Elapsed time2: 0.00003530
Elapsed time2 faster: -205.28 %

На небольшом числе удалений - стабильный отрицательный профит - тут уже рулит remove - может я как-то неэффективно написал вариант удаления с "del"? Я крайне удивлён таким поведением питона!!!

Случайный список на 1 000 эл от 0 до 1 000 удаляем до 5
import numpy as np
import timeit as tm

##numbers = list(range(0, 100000))
numbers = list(np.random.randint(0, 1000, 1000))
numbers2 = numbers.copy()
code_to_test ="""
for i in reversed(numbers):
  if i < 50000:        
    numbers.remove(i)
"""
elapsed_time1 = tm.timeit(code_to_test, globals={'numbers':numbers}, number=100, )/100
##print(numbers)
formatted = f"{elapsed_time1:{10}.{8}f}"
print('Elapsed time1: ', formatted)

code_to_test ="""
for i in range(-len(numbers),0):
  if  numbers[i] < 50000:        
    del numbers[i]
"""
elapsed_time2 = tm.timeit(code_to_test, globals={'numbers':numbers2}, number=100, )/100
##print(numbers)
formatted = f"{elapsed_time2:{10}.{8}f}"
print('Elapsed time2: ', formatted)

formatted = f"{(100-elapsed_time2/elapsed_time1*100):{4}.{2}f}"
print('Elapsed time2 faster: ', formatted,'%')

Результат опять удивил

Elapsed time1: 0.00011689
Elapsed time2: 0.00000252
Elapsed time2 faster: 97.84 %

Elapsed time1: 0.00012507
Elapsed time2: 0.00000232
Elapsed time2 faster: 98.14 %

Elapsed time1: 0.00009823
Elapsed time2: 0.00000226
Elapsed time2 faster: 97.70 %

Elapsed time1: 0.00007285
Elapsed time2: 0.00000222
Elapsed time2 faster: 96.96 %

Elapsed time1: 0.00006729
Elapsed time2: 0.00000138
Elapsed time2 faster: 97.94 %

Оператор "del" опять стабильно в профите! Хотя тут как раз удалений не так много... Значит тут есть какая-то фигня с функцией определения длинны списка?

Линейный список на 1 000 эл от 0 до 1 000 удаляем до 5 с фикс длинной
import numpy as np
import timeit as tm

sz = 1000
numbers = list(range(0, sz))
##numbers = list(np.random.randint(0, 1000, 100000))
numbers2 = numbers.copy()
code_to_test ="""
for i in reversed(numbers):
  if i < 5:        
    numbers.remove(i)
"""
elapsed_time1 = tm.timeit(code_to_test, globals={'numbers':numbers}, number=100, )/100
##print(numbers)
formatted = f"{elapsed_time1:{10}.{8}f}"
print('Elapsed time1: ', formatted)

code_to_test ="""
for i in range(sz,0):
  if  numbers[i] < 5:        
    del numbers[i]
"""
elapsed_time2 = tm.timeit(code_to_test, globals={'numbers':numbers2, 'sz':sz}, number=100, )/100
##print(numbers)
formatted = f"{elapsed_time2:{10}.{8}f}"
print('Elapsed time2: ', formatted)

formatted = f"{(100-elapsed_time2/elapsed_time1*100):{4}.{2}f}"
print('Elapsed time2 faster: ', formatted,'%')

Результат подтвердил догадку:

Elapsed time1: 0.00001942
Elapsed time2: 0.00000018
Elapsed time2 faster: 99.05 %

Elapsed time1: 0.00001346
Elapsed time2: 0.00000011
Elapsed time2 faster: 99.18 %

Elapsed time1: 0.00001175
Elapsed time2: 0.00000017
Elapsed time2 faster: 98.59 %

Elapsed time1: 0.00001605
Elapsed time2: 0.00000011
Elapsed time2 faster: 99.28 %

Elapsed time1: 0.00001168
Elapsed time2: 0.00000011
Elapsed time2 faster: 99.03 %

Elapsed time1: 0.00001393
Elapsed time2: 0.00000016
Elapsed time2 faster: 98.83 %

функция "len(numbers)" очень очень медленная - и если длина списка известна - то "del" оператор эффективен при любой длине списка и числа вызовов удалений!

Случайный список на 100 000 эл от 0 до 1 000 удаляем до 5 с фикс длинной
import numpy as np
import timeit as tm

sz = 100000
##numbers = list(range(0, sz)
numbers = list(np.random.randint(0, 1000, sz))
numbers2 = numbers.copy()
code_to_test ="""
for i in reversed(numbers):
  if i < 50000:        
    numbers.remove(i)
"""
elapsed_time1 = tm.timeit(code_to_test, globals={'numbers':numbers}, number=100, )/100
##print(numbers)
formatted = f"{elapsed_time1:{10}.{8}f}"
print('Elapsed time1: ', formatted)

code_to_test ="""
for i in range(sz,0):
  if  numbers[i] < 50000:        
    del numbers[i]
"""
elapsed_time2 = tm.timeit(code_to_test, globals={'numbers':numbers2, 'sz':sz}, number=100, )/100
##print(numbers)
formatted = f"{elapsed_time2:{10}.{8}f}"
print('Elapsed time2: ', formatted)

formatted = f"{(100-elapsed_time2/elapsed_time1*100):{5}.{2}f}"
print('Elapsed time2 faster: ', formatted,'%')

Elapsed time1: 0.01101148
Elapsed time2: 0.00000012
Elapsed time2 faster: 99.99887663 %

Elapsed time1: 0.01503288
Elapsed time2: 0.00000013
Elapsed time2 faster: 99.99915385 %

Elapsed time1: 0.00992220
Elapsed time2: 0.00000013
Elapsed time2 faster: 99.99873103 %

Elapsed time1: 0.01042059
Elapsed time2: 0.00000012
Elapsed time2 faster: 99.99880909 %

Elapsed time1: 0.00781494
Elapsed time2: 0.00000015
Elapsed time2 faster: 99.99805757 %

И тут в конце тестирования я заметил 2 проблемы
  1. Грубая ошибка - я прогонял замеры через timeit по 100 раз - но не учёл, что после первого прогона все удаляемые элементы из списка уже удалены - и все последующие прогоны не приведут к удалению - замеры получаются не особо чистыми - так как я далёк до джуна в питоне - пока не вижу красивого решения замера через timeit - только как вставку формирования копии списка перед циклом (но тогда и копирование будет входить в замер - для данного теста это не так уж важно - т.к. в обоих случаях оно будет одинаково присутствовать)

    import numpy as np
    import timeit as tm
    
    sz = 1000
    numbers = list(range(0, sz))
    ##numbers = list(np.random.randint(0, 1000, 100000))
    numbers2 = numbers.copy()
    code_to_test ="""
    numbers_ = numbers.copy()
    for i in reversed(numbers_):
      if i < 5:        
        numbers_.remove(i)
    """
    elapsed_time1 = tm.timeit(code_to_test, globals={'numbers':numbers}, number=100, )/100
    ##print(numbers)
    formatted = f"{elapsed_time1:{10}.{8}f}"
    print('Elapsed time1: ', formatted)
    
    code_to_test ="""
    numbers_ = numbers.copy()
    for i in range(sz,0):
      if  numbers_[i] < 5:        
        del numbers_[i]
    """
    elapsed_time2 = tm.timeit(code_to_test, globals={'numbers':numbers2, 'sz':sz}, number=100, )/100
    ##print(numbers)
    formatted = f"{elapsed_time2:{10}.{8}f}"
    print('Elapsed time2: ', formatted)
    
    formatted = f"{(100-elapsed_time2/elapsed_time1*100):{4}.{2}f}"
    print('Elapsed time2 faster: ', formatted,'%')

  2. Формула расчёта процента профита какая-то е шибко удачная: "100-elapsed_time2/elapsed_time1*100" и плохо отражает реальный прирост скорости. Тут нужно скорее что-то такое "percent = 100elapsed_time1/elapsed_time2-100 if elapsed_time1 >=elapsed_time2 else -100elapsed_time/elapsed_time1+100"

##formatted = f"{(100-elapsed_time2/elapsed_time1*100):{4}.{2}f}"
percent = 100*elapsed_time1/elapsed_time2-100 if elapsed_time1 >=elapsed_time2 else -100*elapsed_time/elapsed_time1+100
formatted = f"{percent:{2}.{4}f}"

Торопился - поэтому сделал досадные ляпы - не связанные с незнанием мной Питона - но честное слов - лень переделывать тесты

Списки могут быть очень большие - но тогда и к строке numbers.remove(i) можно придраться - тогда уж надо через del удалять

нужно обходить список в обратном порядке

Решение без копий
for i in reversed(numbers):
  if i < 5:        
    numbers.remove(i)

Честно - код проверил - но уже после того как написал - правки в него не вносил. Но вдруг я что-то упустил?

Наверное более эффективное (и мне более привычное решение) для удаления
for i in range(-len(numbers),0):
  if  numbers[i] < 5:        
    del numbers[i]
print(numbers)

Честно - не знаю будет ли тут ощутимый профит у питона. Но по логике на очень больших списках должен быть!

P.S.

В питоне мне далеко до джуна (до конца ни одной книжки ещё не прочитал). Но зато я Сеньёр в других ЯП :-D

Я ничего не путаю. И про тёмную энергию ни слова не говорил

Но в целом - вопрос что считать энергией а что материей - это хороший вопрос

Интересно - почему космологи считаю, что в ранней вселенной было больше материи чем энергии?

Почему бы именно материи не начать формироваться из чистой энергии именно в процессе условий большого взрыва!

И может ли вообще что-то материальное сжаться до безразмерной сущности!

Но это прелюдия - а сейчас задайтесь лучше двумя вопросами:

  1. Существовала ли вообще гравитация в начале большого взрыва! Ну ту по разному можно смотреть на гравитацию - если по стандартной квантовой модели - то это часть силы, которая первой отделилась от единой силы (которая потом поэтапно распалась на слабое/сильное/электромагнитное взаимодействия). Но, не отсутствие ли гравитации, при крайне высоких энергия как раз и дало скачок инфляционного расширения! Даже сейчас учёные не знаю наверняка - есть ли масса (и как следствие гравитационное воздействие) а некоторых частиц стандартной модели. Правда таки всё меньше и меньше - массу постепенно находят (и нейтрино вроде бы уже у всех нашли). И её ищут даже у фотона!

  2. Не является ли (ускоренное) расширение пространства частью самого этого пространства (или как вариант - частью чего-то за пределами этого пространства - ниже поясню). То есть - пространства расширяется (условно) само по себе - изначально (две стратегии ниже поясню). И как только бабахнуло - так и понеслись частицы в этом пространстве. Но... возникающая гравитация, с усилением концентрации частиц, начала тормозить этот процесс до определённо стадии, а потом плотность гравитации стала падать - и процесс снова стал ускоряться! То есть - именно на ранней стадии большого взрыва скоростному расширению вселенной просо нечего было предоставить, а потом такие силы возникли!

Две стратегии расширения пространства:

  1. Раздувание - в отсутствии внешнего сопротивления - просто за пределами пространства нет ничего - и пространство раздувается само по себе как газовый шарик в вакууме - внутри которого растёт давление! А вот за счёт чего растёт давление - видимо за счёт самосотоворения самого носителя пространства, чем бы он ни был! А из чего он самосотворяется? Не знаю - свойство самого пространства - из информационного поля! Это уже в другую сторону нужно капать, а не про большой взрыв!

  2. Втягивание - почему все решили что пространство расширяется - это может быть просто локальная видимость только такого процесса на доступных нам масштабах наблюдения! Возможно пространство наоборот - куда-то втягивается (как вариант - это теория тороидальной вселенной, но не обязательно). В этой стратегии я лишь указываю на возможность существования внешней силы - которая тянет пространство в каком-то направлении (вероятно не прямой формы). Условно эту силу можно было бы так же считать гравитацией - но действующей с другой стороны! Ну или антигравитацией, возможно с некоторым иным принципом воздействия - может даже через специальные скрытие измерения и не найденные частицы переносчики взаимодействия! Может это быть и частью нашей же вселенной (или предыдущей вселенной) - где пространство проходит определённую стадию метаморфозы, искровеняя и изменения состава частиц - и, изогнувшись, это изменённая часть тянет к себе неизменённую - где потом, итоге всё перейдёт обратно в процесс сжатия, но с другой стороны опять альтернативно сформируется новая тянущая сила - и всё бабахнет по новой!

 И никто не задается вопросом а можно ли книги писать в Emacs? А можно ли курсовую работу в Vim оформить?

А Вы уверены что не задаются?

Например в этих редакторах вполне себе и профессионально можно писать и книги и курсовые в скриптовых типогравских языках (язык компьютерной вёрстки). Я тут не спец и очень давно этого дела касался - но VIM как и Emacs или VS Code (с плагином) точно поддерживает хотя бы LaTeX.

Но в чём была подколка - я не понял - это всё текстовый процессинг. Как и тои же MS Word.

Я слышал к Qt Creator есть что-то более серьезное, плагин или что-то там. Позволяет прямо полноценный редактор Vim запускается внутри Qt Creator, и пользовательский конфиг вима работает в этом всем

Мне кажется, это вполне интересный подход. В бОльшей системе Нужно расширять/заменять какую-то её отдельную составляющую!

Не знаю почему эволюция инструментов разработки не пошла таким путем, может время еще не пришло, и однажды увидим MS Visual Studio [Vim]. А может оно никому не надо. Я думаю что второе.

Не падайте духом! IDE сейчас активно развиваются - так что у них всё впереди! Прочитай-те лучше ещё раз вторую часть моего предыдущего комментария - там полно прямых намёков! Просто развитие оно многогранно - и то, что есть сейчас в VIM - тоже будет развиваться дальше - и lfkmit гибридизировать с IDE

И уверен - к середине и к концу века "мы увидим" ещё много интересны и новаторских подходов к кодированию - которых вообще нет сейчас!

Например - как я уже выше намекнул: очень назрела идея параллельного потока команд при программировании! Сейчас их два: клавиатуру и, условно, мышь - но руки только две - и параллельно оба потока не получается эффективно использовать! Отсюда и родилась концепция "vi".

Но если развитие технологий в ближайшие десятилетия - таки даст возможность эффективно вести ввод команд в несколько параллельных потоков - это будет прорыв. Один из вариантов я озвучил - это голосовой ввод!

Или ещё пробовали ногами!

Другой вариант - это управление взглядом!

Далее - силой мысли!

А развитие автокодинга, AI-ассистентов вместе с инструментарием IDE - который будет адаптироваться к новым возможностям ввода и рефакторинга - будут формировать новые стратегии по вводу программного кода - да и вообще любому вводу и дизайну данных и графических (или ещё каких, например звуковых) представлений!

Да и сам кодинг (или ввод любого текста и не текста) существенно изменится (далее для простоты буду про программирование говорить) - появится новые ЯП, адаптированные под AI ассиситирование и кодогенерацию. Не нужны будут изощрённые средства текстового рефакторинга* - кодирование будет более компактным - декларативным - а AI-ассистент будет выполнять всю черновую работу - а программист далее будет только его направлять и просить переделать с учётом новых замечаний! Изредка только детально вмешиваясь в сам процесс кодинга!

* Важное замечание - я говорю о потери интереса именно к прямому текстовому рефакторингу - в отличии от того, что лексический контекстный интеллектуальный рефакторинг будет наоборот, набирать обороты!

Всё-так, не совсем корректное сравнение IDE и текстовых процессоров!

Да, модальный текстовый редактор - это своя особая философия - но это именно философия просто текстового процессинга с небольшой приправой альтернативного управления командами редактора, вместо горячих клавиш.

IDE - это куда большее приложение - в котором текстовый процессинг лишь одна из составляющих IDE - тесно интегрируется с API ключевых приложений, которые и обеспечивают взаимодействие текста и выходной продукции - условно бинарный результирующий поток; IDE всецело управляет этим не только формированием этого потока, но и его дальнейшим использованием (условно я про отладку и профилирование, но не только про это).

Но да - для современных IDE текстовый процессинг это очень важная составляющая (но не более 20%), и в дополнении к ней активно растут пять сопутствующих составляющих:

  1. Глубокий, в т.ч. машинный, анализ кода

  2. копилотинг- умная runtime-автоподстановка, рефакторинг и преобразование шаблонного кода к контекстно зависимый; умный поиск готовых решений и их адаптация по контест

  3. Глубокий тестинг - на неявные ошибки и просто выполнение тестов прямо в rutime design в IDE

  4. Препроцессинг и макропроцессинг - выполнение кода в design, в т.ч. в runtime прямо в IDE видеть предполагаемый результат

  5. Автогенерацая дополнительных форм по написанным текстам - от банальной кодогенерации до автодокументирования и генерации автотестов

Которые расширяют текстовый процессинг в IDE уже до 60% всех его ключевых составляющих!

Ну и, само собой, средства отладки, профилирования и реверсинженирования (рефлексия в код) тоже сейчас активно развиваются - и дадут ещё 20-25% ключевого функционала IDE.

Что там ещё останется.... версионирование и некоторые мелочёвки (как подключение к СУБД, спец. редакторы ресурсов), если ничего важного не забыл!

Ах... да.... конечно же - визуальный редактор и предпросмотр как выходных форм, так и прочих схем - это всё тоже прерогатива IDE! Это ещё 5-10% её функционала!

И где-то пара процентов - интеграция с внешними платформами - например с игровой Unity!

Безусловно - многое из названного можно и в текстовых процессорах а-ля VIM, Sublime или VS Code, плагинами реализовать - но это само по себе будет большое искусство и труд, и как такие монстры (которые собраны из кучи заплаток) будут вместе работать - никто не предскажет - в отличие от целостных IDE - где всё это сразу разрабатывается и тестируется как единое целое!

А запустил современную продвинутую IDE - и.... тебе тут же копилотинг код начал дополнять (не надо только это превращать к холивор - кому-то нравится, кому-то нет - это просто пример, да и явно эта тема будет в ближайшие десятилетия/столетия активно развиваться и совершенствоваться; уже очень интересно что нового будет тут в следующей Visual studio - уверен на AI помощника и лингво-генеративное программирование будут делать ключевую ставку в новой IDE)!

Но... IDE ведь тоже расширяемы... так почему бы не расширять их текстовый процессинг - внедряя модельное управление внутрь IDE! Вроде как IDEA отчасти это умеет, но поправьте меня если я не прав - не спец по IDEA, не адепт модальной философии

А что до модального подхода... это было интересно на рубеже XX/XXI веков!*

А на рубеже XXI/XXII рулить будет уже как минимум голосовое управление - и, как вариант, особый матерный сленговый язык - когда программист будет параллельно с относительно классическим текстовым набором кратко общаться с умным AI помощником, который будет его понимать с полуслова, а адаптируясь к его модели общения!

Да что там конец века - уже в середине XXI века AI помошник станет ключевым инструментом в кодинге, рефакторинге, кодогенерации, отладке, тестировании и профилировании!

* но - возможно я ошибаюсь, этот сленговый подход как раз и приведёт к тому, что большинство программистов перейдёт именно к модальному походу - и буду управлять процессами IDE через нечленораздельные короткие фразы. А интеллектуальные помощники и продвинутые IDE будут помогать легко осваивать такой подход - поэтапно к нему подготавливая программистов - через освоение промежуточных инструментариев и адаптации к сленговым командам управления!

Так она неспроста зашла с твоего ноут! Вот тебе целый месяц и намёки показываются!

Если общение сразу не заладилось - оно не заладится и далее! Подстроить начало общения под каждого кандидата не обладая почти никакими знаниями о нём - практически невозможно!

И даже стратегию - аналитического прощупывания с разных сторон (и разных эккаунтов) не провернуть - из-за привязки к фотографиям на этих эккаунтах!

Так все эти современные дейтинг сервисы - это просто бездушные автоматы с такой же бездушной аудиторией! Так что и работать с ними всеми надо максимально бездушно! Пока среди всего этого "пластика" вдруг не проскользнёт алмаз хотя бы в полкарата! Ну или дейтинг сервисы не изменятся...

Но, опять же - говоря об продолжающемся общении - смотрите на постскриптум в моём предыдущем сообщении - в нём 50% всей сути (остальные 50% - это 25 + 25 = "Бездушная система и аудитория, с бездушным же подходом к тем, кто уделил им толику своего бесценного внимания" + "Только бизнес ничего личного"... ну есть ещё некоторый % как "Развод лохов", хотя в целом это часть "Только бизнес ничего личного", просто в другой плоскости)

Всё что не является прямым взаимодействием с человеком всё этично! Один робот - взламывает другого робота, который как раз ведёт себя очень неэтично по сравнению с клиентом человеком - так что так ему и надо!

Что до общения.... тут сложнее... но я скажу так - если бы сервис изначально мог предоставлять обширные сведения о каждом кандидате, которые можно было бы статистически обработать и сопоставить с необходимым шаблоном - то и общаться-то не пришлось бы - 99.8... % (в зависимости от глубины шаблона и данных) кандидатов сразу бы отсеялись! А так как такого сервиса ни у кого нет - все претензии прошу предъявлять именно дейтинг сервису - который не про удобство и любовь - а просто бизнес и ничего личного! Так что тут я тоже за интеллектуальное автоматизированное "продолжение банкета" - во всех самых жёстких формах - пусть дейтинг сервисы завалят жалобами - иначе они и вовсе не изменятся!

P.S.

Но вообще завидую тем - у кого проблема со временем самостоятельно пообщаться с первично отобранными кандидатами - т.е. объём тех, кто хотя бы ответить, и длинна диалога превысит 3-4 сообщения настолько велик, что будет отнимать больше времени чем постоянный тюнинг такой вот системы!

Если мне показывают - что мне интересно прямо сейчас - это здорово! Вот только:

  1. Что мне интересно - обычно либо не продаётся, либо не приносит много прибыли, либо я не собираюсь это покупать - это 98% всего что мне интересно

  2. Что мне интересно сейчас - а что вчера и что завтра - всё разные вещи - и часто не шибко совпадающие - так что что было интересно вчера - сегодня уже просто информационный мусор!

  3. Если мне показывают что мне интересно - первая мысль - они следят за мной! Вторая - они мне навязывают мои интересы! Обе приводят к тому - что следующая мысль - поскорее отгородиться от тех, кто мне это предлагает и добавить всё в чёрный список!

  4. А что мне интересно? Не то ли что мне просто навязывают, и манипулируют моим сознанием - взламывая его тонким нейролингвистическим способом или грузя тупым флудом! Отвлекая от чего-то, что мне не просто интересно - а действительно важно именно сию минуту!

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

  6. Если кто-то точно знает что тебе нравится и как правильно это тебе преподносить - считай он уже знает как тобой полностью управлять на 50%! Особенно на фоне того как собираются эти данные - и там будет не только то что тебе нравится.... но и куда больше - о полной карты твоей личности и жизни до всех страхов и "тёмных дел" (условно) - а это остальные 50% - а 100% управление - и ты превращаешься просто в робота, даже не подозревая этого!

Таргетированная реклама и слежка за интересами и деятельностью пользователей сети Интернет - это бич XXI века! Если отказ от куки уменьшит её объём - то возрадуемся! Но это вряд ли - владельцы платформ, соцсети, почтовые серверы по-прежнему будут активно нас всех таргетировать! Просто идёт обычный передел рынка душ информации пользователей! Как всегда богатые и власть имущее хотят стать ещё богаче и ещё могущественнее! Продолжая доить простых смертных!

Жалко, что статья не разбирает другие проблемы - кроме как проблемы рекламодателей!

Два последних ограничения вебинара очень странные - очень сильно сужают эффективную применимость Лучше было бы оформить это опциями. Особенно на фоне закрытия вебинара если его покинут все модераторы - а покинуть они могут и не по своей воли и завершении вебинара

Третьему варкрафту не нужен мягкий перезапуск ремейка - ему нужен 4-ый номер - а уже потом - на абсолютно новом и современном движке имело бы смысл сделать DLC с кампаниями 3-го (а в идеале 1 и 2 - существенно расширив повествование и фракции) варкрафта - и продать их именно как дополнения (а может и как отдельные игры - просто на том же движке)!
Ну а на фоне выхода 4-й части вполне целесообразно было бы перезапустить и киновселенную варика (в идеале в виде сериала - как это и было бы правильно делать для такого большого фэнтезийного мира, и именно с 1-й части варика) - и оба медиапроекта бы подстёгивали популярность друг друга! Параллельно можно было бы и WoW компанию выпустить - идеи две:

  1. Параллельное повествование в рамках основных компаний RTS Warcraf 4

  2. Тотальный перезапуск WoW Classic - в виде WoW Retrospective - перенесясь в эпоху сначала даже до вторжения орков - (до 1-го варкрафта, Лор то уже давно есть) - а потом уже развивать эпохи 1-3 варкфрат, и далее, возможно, очередной перезапуск кампаний WoW Classic

Второй вариант предпочтителен - т.к. ему активно бы содействовал перезапуск кинофраншизы, которая бы плавно бы охватила бы все части Warctraft 1-3 затем WoW и затем Warcraft 4 - а это задел больше чем на 10-12 лет - популярности всей франшизы, ярды ежегодной прибыли (ну если не налажать - как с первым фильмом "Варкрафт" - а налажали там как-будто делали всё впопыхах - хоть и проект делался 10 лет, собственно он и опоздал на эти 10 лет; ну и то что не было плавного подробного повествования - не фанаты не врубились и захейтили проект, со специфических CGI, стремительным и мутным повествованием) - вот Лор у вселенной Варкрафта проработан хорошо - и если грамотно снимать именно сериал - вполне можно сделать не хуже Игры престолов (правда бюджет потребуется побольше - CGI для Варкрафта нужно больше, но если будмать о длинной сериальной франшизе - то ярд первоначалных вложений будет дальше размываться чуть меньшими вложениями от сезона к сезону, с прибылью, измеряемой ярдами от сезона к сезону)!

Первая игра в каком классе / списке?

Не Pong ли была первая? Вернее одной из первых - т.к. вместе с ней вроде вышло ещё несколько менее известных игр! Хотя... это я наверное про класс игр для домашних приставок говорю. а во что там играли на первых компьютерах на перфокартах я не знаю.... вроде слышал про игру про запуск космической ракеты - там само собой никакой графики даже не было... одни цифры и расчёты (чист текстовая игра); или ещё ранее - Nimatron для игры в "Ним" - но это всё уже совсем другая история. Как то, какая была первая графическая (видео) игра.... возможно "Bertie the Brain" ли "OXO", или "Tennis for Two" (все выпущены ещё до Pong) - что работала вообще на осциллографе

Навряд ли. Тетрис выпускался на очень большом числе мобильных устройств (ещё до смартфонов, в т.ч. на телефонах - как там появилось встроенное ПО). В отличии от астеройдс, арканойд, змейки (лайнс)...

У игры Тетрис был очень мощный маркетинг и продвижение!

Даже сейчас, скорее на смартфонах (и прочих компьютерных устройствах) можно найти именно Тетрис, чем вышеупомянутые игры или шахматы/шашки/го/нарды/маджонг/карты...

Тетрис вполне ещё популярен до сих пор.... а вот астеройдс скорее уже в истории... в арканойд и змейку ещё играют, но меньше, чем в Тетрис.

Думаю, что Тетрис ещё очень долго будет иметь высокую популярность.... но, наверняка, со временем его вытеснит какая-нибудь другая игра. Да сейчас, думаю, что в Гранд зефт ауто или в Фортнайт / Пабг /Дота2 или в какой-нибудь клон Сокровища Монтесумы (правильнее назвать прародителя "Bejeweled"/"Diamond Mine") играют куда чаще, чем в Тетрис.

Information

Rating
Does not participate
Location
Москва, Москва и Московская обл., Россия
Date of birth
Registered
Activity