Это из разряда "я мыслю значит я существую", на самом деле абстракцией является и электрическая схема, так как физически это металлизация, последствия ионной имплантации и прочих планаризаций. И нет там никаких "0" и "1" а есть переход уровня напряжения. Да и уровень этот тоже абстрактный - измеряемое число. "Объективная реальность данная нам в ощущениях". Как раз речь идёт ширине окна этих абстракций, что есть определённый уровень когда человек уже не может вобрать в себя модель полного поведения, однако есть нюанс - это всякие О большое, которое может сделать прогноз исходя из основополагающих величин. Мне не нужно знать защищённый режим и механизмы кеширования, если есть грубо говоря нечто , где D - запаздывание вычислений, C - размер кода, H - размер кеша, в определённых границах разумеется. То есть любая абстракция может быть сведена к математическим оценкам с точки зрения оценки быстродействия и принятия решений. А на этом уровне уже и выбирается парадигма, инструмент будь то ассемблер или даже VHDL чтобы сделать сопроцессор для ASIC-а, а может это будет такой хитрый алгоритм на обычном Питоне под Pentium Pro который превзойдёт эти все асики вместе взятые. Вот тут и начинается собственно синтез, который вычёркивает любые классы и оставляет только разметку данных и последовательность оптимальной по заданному критерию их обработки. Время таких синтезаторов собственно и подоспело, так как вмещают в себя гораздо большее окно чем человек. Это как оптимизирующий компилятор - на ассемблерном уровне весьма неплох, особенно для ветвлений, что же касается векторных расширений SIMD, там да, необходимо додумывать иногда вручную, так как важен глобальный контекст.
Там проблема была искусственная - это попытка прикрутить ООП к пакетной обработке данных, летящих к интерпретатору. Иерархия и классы - железобетонно прибиты идентификаторами к архитектуре. Веб-поведение динамично, объекты могут мутировать до состояния байта. Тем более это для поведения форм - полуфабрикат, который связывается дополнительно с разметкой документа (декларативное представление), которая как-то должна уживаться со спецификацией. Поэтому он ушёл в чисто поведенческую нишу ФП для разметки, фактически став знаком "=" в эксцеле.
Класс внутри себя ничего не хранит - это абстракция. Хранит физическая ячейка памяти располагаемая в условном массиве, который где-то на листе программиста размечен как класс. Класс может знать о том что он вообще существует, если его ID есть ячейка памяти. Класс может знать что у него есть методы, если есть таблица методов, располагаемых статически или как указатели на функции. Класс знает что он-часть иерархии, если есть таблица виртуальных функций и опять-таки его ID в ней как в линейном массиве или часть switch-case в зависимости от типа объекта при динамическом поведении. В этом случае действительно разнести класс как спецификацию данных и бизнес-логику (оперирует состоянием автоматов и ), которая вообще может не знать какие объекты она использует а работает с их хешами, идентификаторами или правилами обработки типов данных. В этом случае под катом может быть любой язык программирования, так как это всё генерируется автоматически, тем же ИИ-агентом. То что класс может быть в топе - то есть на вершине стека, можно над этим подумать, действительно, иерархия может быть обработана как стек при размещении туда наследуемых объектов.
ООП нужен лишь человеку, чтобы иерархия или глубина вызовов функций влезали в его контекстное окно из 12-15 одновременно располагаемых в голове сущностей. Сложность самой программы от этого не меняется. Любую можно свести на ассемблер. Самое важное что не ввели ни в одном таком языке - это нативная поддержка статического управления, позволяя кодогенераторам или скан-ботам выявлять структуры и управлять ими на этапе разработки, то есть не вручную править классы а соответствующей IDE/редактором по спецификации объектов. По сути все изменения именно в этом механизме. На Питоне по крайней мере что-то сдвинулось с этой точки PEP 729 например. На С++/Java это замороженный 2004 год, когда упёрлись тактовой частотой в потолок и больше одиночным вычислителем уже не подчеркнуть "быстрее, выше, сильнее". Оттого и появилась "компилируемая безопасность" в попытке реализовать эти 5%. В итоге имеем интерпретируемые JSON/XML на все случаи жизни, для виду приправленные ООП, который в контексте пакетной обработки и приведения типов выворачивается наизнанку.
Да именно последовательное применение итераций есть суть кодогенерации с LLM. Не спецификация! Как это принято. А это как из куска глины гончар или скульптор начинает делать то что необходимо. Иными словами, это предсказуемость начальных условий и формирование граничных значений. Если описать всё и сразу - получим парадоксальное поведение (если не влазит в контекстное окно). Вообщем это из разряда энтропия суммы и суммарная энтропия. Диалог фактически устанавливает связи некой микро-виртуальной машины, которая вполне себе реальная в виде элементов памяти весов и пройденных путей активации нейрона по заданному уровню. В этом случае возможен выход из контекстного окна и "забытие" предыдущего результата, однако такая последовательность приводит к синтезу уже гораздо большего кода, причём он может самокорректироваться агентами по ходу генерации а также тестироваться, то есть фактически самособираться. Осталось только добавить в компиляторы вменяемые отклики, пригодные для ИИ (не на человеческом языке) а адаптированные для агентов в виде уже токенизированных идентификаторов.
Не от сеньора, уставшего объяснять, почему Java и JavaScript — это не одно и то же
Уровень синьора - это позвонить разработчикам этих языков и поставить вопрос об унификации требований на основании запросов трудящихся джунов/мидлов всех стран что это одно и то же, организовать симпозиум ISO/IEC с последующим вынесением вопросов на пленарное заседание, голосованием видных деятелей стандартизации метрологии и сертификации по приведению кодовой базы ЭВМ к актуальному уровню. А то как-то не солидно получается.
вот это кстати идея. То есть представлять не цифры, а их заменители, позволяющие быстро считать. Например, треугольники, N-угольники и их пересечение, как некий код который можно преобразовать в число. Кстати интересный вопрос - есть ли не геометрическое доказательство что
Самый хороший тест - это промпт написать виртуальную машину для абстрактного языка и промоделировать её. В принципе +- все модели делают одно и тоже так как датасеты для претрейна одинаковые. Разница в масштабировании, пока что это удаётся, но там есть предел. Много токенов не равно оптимизация большого проекта. Должны быть уже архитектурные изыскания на предмет понимания состояния контекста. Вывод для Гигачата.
make a python script that interpret virtual machine with code "a" add "s" substract, "m" for multiply accumulator and "p" to push var to stack and "u" pop from stack for string "a10s3m6p7p2a3usum" without argument use acc by default and vaue from top of stack
def run_vm(code):
# Initialize accumulator and stack
acc = 0
stack = []
i = 0
while i < len(code):
cmd = code[i]
if cmd == 'a':
num = int(code[i+1])
acc += num
i += 2
elif cmd == 's':
num = int(code[i+1])
acc -= num
i += 2
elif cmd == 'm':
num = int(code[i+1])
acc *= num
i += 2
elif cmd == 'p':
var = int(code[i+1])
stack.append(var)
i += 2
elif cmd == 'u':
popped_value = stack.pop()
acc = popped_value
i += 1
else:
raise ValueError(f'Unknown command {cmd}')
# Calculate sum of remaining values in the stack
final_sum = sum(stack)
return f'Accumulator: {acc}, Final Sum: {final_sum}'
# Example usage
result = run_vm("a10s3m6p7p2a3usum")
print(result)
После чего необходимо "допилить" согласно обратной связи от ошибок интерпретатора, потребовалось 8 итераций. в ходе чего получается... не рабочйи вариант
ВайбVM
def run_vm(code):
# Initialize accumulator and stack
acc = 0
stack = []
i = 0
while i < len(code):
cmd = code[i]
if cmd.isalpha(): # Command character
if cmd == 'a': # Addition
# Attempt to find numeric argument or fallback to stack
arg_start = i + 1
while arg_start < len(code) and code[arg_start].isdigit():
arg_start += 1
if arg_start > i + 1:
num = int(code[i+1:arg_start])
acc += num
i = arg_start
else:
# Fallback to stack-based operation
if stack:
acc += stack.pop()
else:
raise ValueError('No numeric argument found for addition command')
elif cmd == 's': # Subtraction
arg_start = i + 1
while arg_start < len(code) and code[arg_start].isdigit():
arg_start += 1
if arg_start > i + 1:
num = int(code[i+1:arg_start])
acc -= num
i = arg_start
else:
# Fallback to stack-based operation
if stack:
acc -= stack.pop()
else:
raise ValueError('No numeric argument found for subtraction command')
elif cmd == 'm': # Multiplication
arg_start = i + 1
while arg_start < len(code) and code[arg_start].isdigit():
arg_start += 1
if arg_start > i + 1:
num = int(code[i+1:arg_start])
acc *= num
i = arg_start
else:
# Fallback to stack-based operation
if stack:
acc *= stack.pop()
else:
raise ValueError('No numeric argument found for multiplication command')
elif cmd == 'p': # Push to stack
arg_start = i + 1
while arg_start < len(code) and code[arg_start].isdigit():
arg_start += 1
if arg_start > i + 1:
num = int(code[i+1:arg_start])
stack.append(num)
i = arg_start
else:
# Push the current accumulator value
stack.append(acc)
elif cmd == 'u': # Pop from stack
if stack:
acc = stack.pop()
else:
raise ValueError('Stack underflow during pop operation')
i += 1
elif cmd == 'sum': # Compute sum of stack contents
final_sum = sum(stack)
print(f'Stack sum: {final_sum}')
i += len(cmd)
else:
raise ValueError(f'Unknown command {cmd}')
else:
i += 1 # Non-command characters are skipped (digits)
return f'Accumulator: {acc}, Final Sum: {final_sum}' if 'sum' in code else f'Accumulator: {acc}'
# Example usage
result = run_vm("a10s3m6p7p2a3usum")
print(result)
В этом примере есть ключевой момент для ИИ - несмотря на весьма маленький код, имеется генерация кода по описанию и кода по данным (которые необходимо интерпретировать). По всей видимости ИИ-модели крайне неэффективно "представляют" внутри интерпретацию данных, то есть "делай на примере", хотя запрос и сам промпт сформулирован довольно точно чтобы ИИ автоматом определил граничные значения и форматы. Строка-пример, по всей видимости, существенно ломает контекст.
Тут другой ключевой аспект - стандарты ЯП и вот эти самые данные содержат все предыдущие 50+ лет становления IT в том виде котором оно сейчас есть. Фактически привнесение новых элементов в код или данные это синтаксический сахар уровня дообучения или даже RAG. В некотором смысле подведена черта под дальнейшим развитием языков и будет некий промпт-инженеринг, заключающийся просто в мониторинге синтаксических деревьев и синтетических тестов. То есть задача формализуется поведением и границами чем непосредственной её реализацией.
10 ГБ репа из них 99.9% данные, вспомогательный UI и 0.00001% непосредственно математического аппарата (ядра) кода. Так вот ИИ позволит эти микропроценты соптимизировать так, что они будут определять 99% быстродействия и функционала всей системы. Там "коэффициенты усиления" просто колоссальные. А уровень понимания и матаппарата для оптимизации код-данные-память-вычислитель уже практически как PhD Computer Sciense а не джуниор.
Очень важно при этом предоставлять инфу из вывода терминала-логов итд. Мы буквально недавно отладили очевидную ошибку, но скрывшуюся за inlcude. Компилятор не указал что нет прототипа функции и возвращал значение через регистр аккумулятора в DSP, вместо стека или вспомогательного FPU регистра. Скормив ему вывод дизассемблера (с включённой опцией кода), состояние регистров, map-файл размещения в памяти, порядка линковки библиотек удалось выловить комплексную проблему и с памятью, и с тем что инклудить, как вызывать матфункции, какие аргументы double-float итд итп. То есть фактически проблема должна содержать сам тест и результаты теста, а также инлайны от ИИ, которые он предлагает. Желательно инлайны делать не текстом а в виде придуманных для себя идентификаторов тест 0xA,тест 0xB, чтобы сэкономить контекстное окно. Уже не представляю эмбеддед разработку без ИИ. Причём уровень хоть в машинных кодах хоть на ассемблере хоть на питоне для МК. Там могут быть даже чудеса из микса C в контроллере + описание логики на Verilog/VHDL.
Кто бы что не говорил но плагины к VSCode от Сбера (GigaCode) и Яндекса (SourceCraft) вполне себе рабочие решения с приличным окном в 128 килотокенов или ~полмегабайта данных. Сильных глюков не обнаруживается даже на 1000 строках. Отличный вариант для уже структурированных вручную проектов. Контекст можно "скармливать" в виде файлов или вывода терминала. Желательно общаться на английском, так как, естественно, датасеты для претрейнинга это гитхабы, стэкэксченджы итд. Скорее всего даже чаты и форумы со всего мира переводятся на английский автоматом а уже потом идут как трейнингсэт, даже в этом случае вполне приемлемый результат по коду. Вообщем не важно какой язык фактически оперирование идёт с неким пока ещё "виртуальным" абстрактным синтаксическим деревом, включающим общую спецификацию всех языков программирования, включая HDL/SQL релейную логику и прочую экзотику.
Самый краткий пример. Заходим на Сбер-Гигачат и просим сгенерировать объекты в общем виде. Например, задать массив начальных координат окружностей и их диаметров, располагаемых внутри квадрата 640x480, причём диаметры случайные и не превышают от 1/10 до 1/3 величины экранной области. Координаты внутри области. Сетка только целочисленная. Итак.
Промпт 1. Make a python script contains screen size of 640 x 480 with array of array of [x0,y0 and d] of some circles
import matplotlib.pyplot as plt
# Screen resolution (width x height)
screen_width = 640
screen_height = 480
# List of circles, each represented by [x_center, y_center, diameter]
circles_data = [
[100, 100, 50], # Circle at position (100, 100), diameter=50
[200, 200, 70], # Circle at position (200, 200), diameter=70
[300, 300, 30], # Circle at position (300, 300), diameter=30
[400, 400, 60], # Circle at position (400, 400), diameter=60
[500, 50, 40], # Circle at position (500, 50), diameter=40
]
fig, ax = plt.subplots(figsize=(screen_width/100, screen_height/100)) # Convert pixel units to inches for figure size
for data in circles_data:
x, y, d = data
radius = d / 2 # Diameter divided by 2 gives radius
# Create a circle patch object centered at (x, y) with given radius
circle = plt.Circle((x, y), radius, edgecolor='black', facecolor='none')
ax.add_patch(circle)
ax.set_xlim([0, screen_width])
ax.set_ylim([0, screen_height])
plt.axis('equal') # Ensure equal scaling between X and Y axes
plt.title("Circles Visualization")
plt.show()
Вполне рабочий вариант. Мы создали объекты в виде массива в массиве. Теперь просим инкапсулировать данные в объект. Объект - это формальный контейнер для данных, имеющий неявный идентификатор. Методы объекта - имеют неявный идентификатор - указатель на объект (его местоположение). Пишем.
Промпт 2. make cirles as class incapsulate x0 y0 and diameter
import matplotlib.pyplot as plt
class Circle:
def __init__(self, x0, y0, diameter):
self.x0 = x0 # Center coordinate along x-axis
self.y0 = y0 # Center coordinate along y-axis
self.diameter = diameter # Diameter of the circle
@property
def radius(self):
return self.diameter / 2 # Radius calculation (diameter / 2)
def draw(self, ax):
"""
Draws the circle on provided Axes object 'ax'.
"""
circle_patch = plt.Circle(
(self.x0, self.y0),
self.radius,
color="blue",
fill=False,
linewidth=2
)
ax.add_patch(circle_patch)
# Set up the display window dimensions
screen_width = 640
screen_height = 480
# Define some circles with various positions and sizes
circle1 = Circle(x0=100, y0=100, diameter=50)
circle2 = Circle(x0=200, y0=200, diameter=70)
circle3 = Circle(x0=300, y0=300, diameter=30)
circle4 = Circle(x0=400, y0=400, diameter=60)
circle5 = Circle(x0=500, y0=50, diameter=40)
# Prepare the plot
fig, ax = plt.subplots(figsize=(screen_width/100, screen_height/100))
# Add each circle to the plot
for c in [circle1, circle2, circle3, circle4, circle5]:
c.draw(ax)
# Adjust axis limits and aspect ratio
ax.set_xlim(0, screen_width)
ax.set_ylim(0, screen_height)
ax.set_aspect('equal') # Equal scaling ensures circles appear circular not oval
# Show the final visualization
plt.title("Collection of Circles")
plt.show()
Получили всё тоже самое. Теперь модернизируем объекты в иерархию - добавим обычные круги и цветные а также сделаем итерацию по объектам динамическую - то есть вызов функции по указателю, являющимся фактически идентификатором объекта (таблица виртуальных функций с индексом/списком switch-case как угодно)
make a colored circle as subclass to base circle without color and make dynamic behaviour
import matplotlib.pyplot as plt
import numpy as np
# Base class representing non-colored circles
class BaseCircle:
def __init__(self, x0, y0, diameter):
self.x0 = x0 # x-coordinate of center
self.y0 = y0 # y-coordinate of center
self.diameter = diameter # Diameter of the circle
@property
def radius(self):
return self.diameter / 2 # Compute radius from diameter
def draw(self, ax):
"""Draws the outline of the circle."""
circle_outline = plt.Circle(
(self.x0, self.y0),
self.radius,
color="black",
fill=False,
linewidth=2
)
ax.add_patch(circle_outline)
# Subclass extending BaseCircle with color capability
class ColoredCircle(BaseCircle):
def __init__(self, x0, y0, diameter, color):
super().__init__(x0, y0, diameter) # Initialize parent class attributes
self.color = color # Additional color attribute
def draw(self, ax):
"""Draws the filled circle with chosen color."""
circle_filled = plt.Circle(
(self.x0, self.y0),
self.radius,
color=self.color,
fill=True,
alpha=0.7, # Translucent appearance
linewidth=2
)
ax.add_patch(circle_filled)
# Screen settings
screen_width = 640
screen_height = 480
# Colors for ColoredCircle instances
colors = ['red', 'green', 'blue', 'cyan']
# Generate random circles dynamically
base_circles = [] # Collection of BaseCircle instances
colored_circles = [] # Collection of ColoredCircle instances
for _ in range(10): # Total 10 random circles
x0 = np.random.randint(screen_width//10, screen_width-screen_width//10)
y0 = np.random.randint(screen_height//10, screen_height-screen_height//10)
diameter = np.random.uniform(20, 100)
# Decide whether it's a base circle or colored circle
if np.random.rand() > 0.5: # Probability-based decision
# Colored circle
selected_color = np.random.choice(colors)
col_circle = ColoredCircle(x0, y0, diameter, selected_color)
colored_circles.append(col_circle)
else:
# Regular circle
base_circle = BaseCircle(x0, y0, diameter)
base_circles.append(base_circle)
# Drawing procedure
fig, ax = plt.subplots(figsize=(screen_width/100, screen_height/100))
# Render all base circles first
for bc in base_circles:
bc.draw(ax)
# Then render all colored circles
for cc in colored_circles:
cc.draw(ax)
# Configure plot layout
ax.set_xlim(0, screen_width)
ax.set_ylim(0, screen_height)
ax.set_aspect('equal') # Ensures proper scaling
plt.title("Dynamically Generated Base vs Colored Circles")
plt.show()
В этой схеме мне важно указать не абсолютные данные в объекте а относительные, то есть что привносится, а что удаляется (на C++ это private) а то как реализовать поведение - отдельный вопрос. В коде видно, что ИИ разделил поведение без виртуальных функций (и правильно сделал) с отдельными экземплярами контейнеров, заставим собрать "как в учебнике" объекты в единый контейнер. То есть несмотря на наличие иерархии это ещё не ООП (!), т.к. нет поведенческого полиморфизма. ООП = состояние+поведение+идентичность+полиморфизм.
make base_circles and colored as single array with different objects
import matplotlib.pyplot as plt
import numpy as np
# Base class representing non-colored circles
class BaseCircle:
def __init__(self, x0, y0, diameter):
self.x0 = x0 # x-coordinate of center
self.y0 = y0 # y-coordinate of center
self.diameter = diameter # Diameter of the circle
@property
def radius(self):
return self.diameter / 2 # Compute radius from diameter
def draw(self, ax):
"""Draws the outline of the circle."""
circle_outline = plt.Circle(
(self.x0, self.y0),
self.radius,
color="black",
fill=False,
linewidth=2
)
ax.add_patch(circle_outline)
# Subclass extending BaseCircle with color capability
class ColoredCircle(BaseCircle):
def __init__(self, x0, y0, diameter, color):
super().__init__(x0, y0, diameter) # Initialize parent class attributes
self.color = color # Additional color attribute
def draw(self, ax):
"""Draws the filled circle with chosen color."""
circle_filled = plt.Circle(
(self.x0, self.y0),
self.radius,
color=self.color,
fill=True,
alpha=0.7, # Translucent appearance
linewidth=2
)
ax.add_patch(circle_filled)
# Screen settings
screen_width = 640
screen_height = 480
# Available colors for ColoredCircle instances
colors = ['red', 'green', 'blue', 'cyan']
# Single list holding all circle objects (both BaseCircle and ColoredCircle)
all_circles = []
# Dynamic generation of random circles
for _ in range(15): # Total 15 random circles
x0 = np.random.randint(screen_width//10, screen_width-screen_width//10)
y0 = np.random.randint(screen_height//10, screen_height-screen_height//10)
diameter = np.random.uniform(20, 100)
# Decide probabilistically whether it's a base circle or colored circle
if np.random.rand() > 0.5: # Probability-based choice
# Create a ColoredCircle instance
selected_color = np.random.choice(colors)
col_circle = ColoredCircle(x0, y0, diameter, selected_color)
all_circles.append(col_circle)
else:
# Create a BaseCircle instance
base_circle = BaseCircle(x0, y0, diameter)
all_circles.append(base_circle)
# Drawing routine
fig, ax = plt.subplots(figsize=(screen_width/100, screen_height/100))
# Unify iteration over both types of circles
for circle in all_circles:
circle.draw(ax) # Polymorphic call to draw(), handled appropriately per type
# Configuring plot aesthetics
ax.set_xlim(0, screen_width)
ax.set_ylim(0, screen_height)
ax.set_aspect('equal') # Equivalent scaling for perfect circles
plt.title("Mixed Display of Base and Colored Circles")
plt.show()
Теперь если посмотреть то фактически мы описываем не сами объекты, а то что они содержать и как взаимодействовать с окружением. То есть нам без разницы что это - список, класс, иерархия, полиморфизм или нет. Нам важно чтобы это влезло в контекстное окно. Теперь добавим ограничение в сами объекты. Пишем
make restricion of coordinates at each circle object constructor no more than 320x200 by x0 and y0 and saturate these values. Generate circles with random diameter from 1/10 to 1/3 of screen size
import matplotlib.pyplot as plt
import numpy as np
# Simple circle class with coordinate clamping
class BaseCircle:
def __init__(self, x0, y0, diameter):
# Validate and clamp coordinates
self.x0 = np.clip(x0, 0, 320) # Saturation enforced
self.y0 = np.clip(y0, 0, 200) # Saturation enforced
self.diameter = diameter # Assume valid diameter input
@property
def radius(self):
return self.diameter / 2 # Derived radius computation
def draw(self, ax):
"""Draws the outline of the circle."""
circle_outline = plt.Circle(
(self.x0, self.y0),
self.radius,
color="black",
fill=False,
linewidth=2
)
ax.add_patch(circle_outline)
# Extended class supporting color-filling
class ColoredCircle(BaseCircle):
def __init__(self, x0, y0, diameter, color):
super().__init__(x0, y0, diameter) # Parent initialization handles validation
self.color = color # Additional color attribute
def draw(self, ax):
"""Draws the filled circle with chosen color."""
circle_filled = plt.Circle(
(self.x0, self.y0),
self.radius,
color=self.color,
fill=True,
alpha=0.7, # Translucent shading
linewidth=2
)
ax.add_patch(circle_filled)
# Screen specifications
screen_width = 640
screen_height = 480
# Valid diameter range derived from screen size
min_diameter = screen_width / 10
max_diameter = screen_height / 3
# Palette of possible colors
colors = ['red', 'green', 'blue', 'cyan']
# Container for storing circle objects
all_circles = []
# Dynamically generate 15 circles with constrained parameters
for _ in range(15):
# Randomly choose coordinates within saturation limits
x0 = np.random.randint(0, screen_width) # 0 <= x0 <= screen_width
y0 = np.random.randint(0, screen_height) # 0 <= y0 <= screen_height
# Random diameter selection within permissible range
diameter = np.random.uniform(min_diameter, max_diameter)
# Choose between BaseCircle and ColoredCircle probabilistically
if np.random.rand() > 0.5:
# Create a ColoredCircle instance
sel_color = np.random.choice(colors)
col_circle = ColoredCircle(x0, y0, diameter, sel_color)
all_circles.append(col_circle)
else:
# Create a BaseCircle instance
base_circle = BaseCircle(x0, y0, diameter)
all_circles.append(base_circle)
# Setup for drawing
fig, ax = plt.subplots(figsize=(screen_width/100, screen_height/100))
# Draw all circles
for circle in all_circles:
circle.draw(ax) # Invokes respective draw method
# Fine-tune plot settings
ax.set_xlim(0, screen_width)
ax.set_ylim(0, screen_height)
ax.set_aspect('equal') # Equivalent scaling prevents distortion
plt.title("Circling Within Constraints: Mixed Types")
plt.show()
Вообщем теперь любой (!) язык собственно становится ассемблером для промптов, которые рано или поздно будут приведены к поведению некоего универсального языка запросов и формирования данных. А парадигма и всё остальное выбирается исходя из заданных ограничений и архитектурных особенностей. Включая оптимальную по разным критериям оптимизацию (память, быстродействие, отклик, пропускная канала связи итд).
Можно также умножать на 11 - посредине сумма крайних цифр и прочие приёмы, чтобы свести к данным правилам, равно как для цифр, близких к 10 сложением-вычитанием как сумма-разность квадратов итд. Ну и конечно же (логарифмическая линейка), включая поиск по LUT. То есть достаточно запомнить хотя бы 2,4,8,16...65536. Включая метод последовательных итераций с остатками от деления, метод Ньютона применимо к умножению и др. ,, найти приближающее дробь к за минимум итераций.
Визуально все ОС уже в браузере, включая ИИ. Так что как то так незаметно HTML-рендер стал фактически движком для всего остального что есть в ОС для пользователя.
Лучше привести какие-либо численные параметры. Или более точные формулировки. Например, работа по регламенту , или если работа с изменяющимися условиями работодателем то .
Вот тут у многих недопонимание. Программировать - это фактически рисовать элементы абстрактного синтаксического дерева в виде блок-схем по ГОСТ 19.701-90. Вне этого - просто изучение синтаксиса языков программирования для ввода в ЭВМ этой блок-схемы. В подавляющем большинстве бухгалтерских задач хватит Fortran образца конца 50-х, собственно он и есть - транслятор формул. Всё остальное строго говоря программированием не является а есть реализация протоколов и API согласно некоего коллективного ТЗ. Тот же самый С создан Риччи и Керниганом образно говоря в курилке Bell Labs просто как хороший и удобный инструмент. И куда не ткни везде примерно такой подход. Это уже потом накрутили это как общепромышленный или международный стандарт. Вообщем нарочно не придумаешь. Так вот ИИ и предлагает принципиально новую парадигму минуя этап структурирования и проектирования объектов (это в подавляющем большинстве случаев справочный шаблон) а непосредственную реализацию последовательности действий или конечного результата и не важно на какой платформе или фреймворке это сделано.
Самое главное в C23 для эмбеддинга это типизированные enum-ы и битовые поля на их основе. Теперь наверняка можно нормально в отладчике просматривать текст а не цифры регистров.
Стильно, модно, молодежно!
Боюсь это уже несколько старомодно.
Слишком долго изучать то где есть синтаксис, когда проще использовать С-ассемблер
make simple application on C winapi for SDL 1.2 please
Add error and exception catch using C
#include <SDL.h>
#include <windows.h> // Required for SEH and MessageBox
#include <stdio.h>
// Helper to log SDL errors and exit
void CheckSDLError(const char* msg) {
const char* error = SDL_GetError();
if (error && *error != '\0') {
char fullMsg[256];
snprintf(fullMsg, sizeof(fullMsg), "%s: %s", msg, error);
MessageBox(NULL, fullMsg, "SDL Error", MB_OK | MB_ICONERROR);
SDL_Quit();
exit(1);
}
}
int main(int argc, char* argv[]) {
SDL_Surface* screen = NULL;
int running = 1;
// Layer 1: Standard SDL Error Handling
if (SDL_Init(SDL_INIT_VIDEO) < 0) {
CheckSDLError("SDL_Init Failed");
}
screen = SDL_SetVideoMode(640, 480, 32, SDL_HWSURFACE | SDL_DOUBLEBUF);
if (!screen) {
CheckSDLError("Could not set video mode");
}
SDL_WM_SetCaption("Robust SDL 1.2 App (2026)", NULL);
// Layer 2: Win32 Structured Exception Handling (SEH)
// This catches crashes (Access Violations, etc.) during the main loop
__try {
SDL_Event event;
while (running) {
while (SDL_PollEvent(&event)) {
if (event.type == SDL_QUIT) running = 0;
}
// Simulate a potential crash scenario for testing
// int* crash = NULL; *crash = 10;
SDL_FillRect(screen, NULL, SDL_MapRGB(screen->format, 50, 50, 50));
if (SDL_Flip(screen) == -1) {
CheckSDLError("SDL_Flip Failed");
}
SDL_Delay(16);
}
}
__except(EXCEPTION_EXECUTE_HANDLER) {
// This block runs if the program crashes inside the __try block
MessageBox(NULL, "A critical system exception occurred (the app crashed).",
"Fatal Exception", MB_OK | MB_ICONSTOP);
}
SDL_Quit();
return 0;
}
Простой проект уровня например, монитора порта с выводом на экран и общением по usbtty вполне можно теперь делать промптами без единой сточки кода вручную, сам себе сделал несколько мониторов. Плюс по мелочам различного рода генерировалки изображений, парсеры, утилиты, обработчики, тесты. То есть вот эта вся возня и занимает порой пожалуй 95% времени, когда ключевой аспект алгоритма или матаппарат делается за 5 в виде пары формул. ИИ позволяет в существенной мере автоматизировать эту рутину, особенно что касается рефакторинга а уж тем более генерации доков, графиков, обработки данных, приведение данных в формат для последующей итерации. Незаменимый инструмент вот уже более двух месяцев. Перефразируя классику: 128 кБ контекстного окна хватит всем.
Это из разряда "я мыслю значит я существую", на самом деле абстракцией является и электрическая схема, так как физически это металлизация, последствия ионной имплантации и прочих планаризаций. И нет там никаких "0" и "1" а есть переход уровня напряжения. Да и уровень этот тоже абстрактный - измеряемое число. "Объективная реальность данная нам в ощущениях". Как раз речь идёт ширине окна этих абстракций, что есть определённый уровень когда человек уже не может вобрать в себя модель полного поведения, однако есть нюанс - это всякие О большое, которое может сделать прогноз исходя из основополагающих величин. Мне не нужно знать защищённый режим и механизмы кеширования, если есть грубо говоря нечто
, где D - запаздывание вычислений, C - размер кода, H - размер кеша, в определённых границах разумеется. То есть любая абстракция может быть сведена к математическим оценкам с точки зрения оценки быстродействия и принятия решений. А на этом уровне уже и выбирается парадигма, инструмент будь то ассемблер или даже VHDL чтобы сделать сопроцессор для ASIC-а, а может это будет такой хитрый алгоритм на обычном Питоне под Pentium Pro который превзойдёт эти все асики вместе взятые. Вот тут и начинается собственно синтез, который вычёркивает любые классы и оставляет только разметку данных и последовательность оптимальной по заданному критерию их обработки. Время таких синтезаторов собственно и подоспело, так как вмещают в себя гораздо большее окно чем человек. Это как оптимизирующий компилятор - на ассемблерном уровне весьма неплох, особенно для ветвлений, что же касается векторных расширений SIMD, там да, необходимо додумывать иногда вручную, так как важен глобальный контекст.
Там проблема была искусственная - это попытка прикрутить ООП к пакетной обработке данных, летящих к интерпретатору. Иерархия и классы - железобетонно прибиты идентификаторами к архитектуре. Веб-поведение динамично, объекты могут мутировать до состояния байта. Тем более это для поведения форм - полуфабрикат, который связывается дополнительно с разметкой документа (декларативное представление), которая как-то должна уживаться со спецификацией. Поэтому он ушёл в чисто поведенческую нишу ФП для разметки, фактически став знаком "=" в эксцеле.
Класс внутри себя ничего не хранит - это абстракция. Хранит физическая ячейка памяти располагаемая в условном массиве, который где-то на листе программиста размечен как класс. Класс может знать о том что он вообще существует, если его ID есть ячейка памяти. Класс может знать что у него есть методы, если есть таблица методов, располагаемых статически или как указатели на функции. Класс знает что он-часть иерархии, если есть таблица виртуальных функций и опять-таки его ID в ней как в линейном массиве или часть switch-case в зависимости от типа объекта при динамическом поведении.
и 
), которая вообще может не знать какие объекты она использует а работает с их хешами, идентификаторами или правилами обработки типов данных. В этом случае под катом может быть любой язык программирования, так как это всё генерируется автоматически, тем же ИИ-агентом.
В этом случае действительно разнести класс как спецификацию данных и бизнес-логику (оперирует состоянием автоматов
То что класс может быть в топе - то есть на вершине стека, можно над этим подумать, действительно, иерархия может быть обработана как стек при размещении туда наследуемых объектов.
ООП нужен лишь человеку, чтобы иерархия или глубина вызовов функций влезали в его контекстное окно из 12-15 одновременно располагаемых в голове сущностей. Сложность самой программы от этого не меняется. Любую можно свести на ассемблер. Самое важное что не ввели ни в одном таком языке - это нативная поддержка статического управления, позволяя кодогенераторам или скан-ботам выявлять структуры и управлять ими на этапе разработки, то есть не вручную править классы а соответствующей IDE/редактором по спецификации объектов. По сути все изменения именно в этом механизме. На Питоне по крайней мере что-то сдвинулось с этой точки PEP 729 например. На С++/Java это замороженный 2004 год, когда упёрлись тактовой частотой в потолок и больше одиночным вычислителем уже не подчеркнуть "быстрее, выше, сильнее". Оттого и появилась "компилируемая безопасность" в попытке реализовать эти 5%. В итоге имеем интерпретируемые JSON/XML на все случаи жизни, для виду приправленные ООП, который в контексте пакетной обработки и приведения типов выворачивается наизнанку.
Да именно последовательное применение итераций есть суть кодогенерации с LLM. Не спецификация! Как это принято. А это как из куска глины гончар или скульптор начинает делать то что необходимо. Иными словами, это предсказуемость начальных условий и формирование граничных значений. Если описать всё и сразу - получим парадоксальное поведение (если не влазит в контекстное окно). Вообщем это из разряда энтропия суммы и суммарная энтропия. Диалог фактически устанавливает связи некой микро-виртуальной машины, которая вполне себе реальная в виде элементов памяти весов и пройденных путей активации нейрона по заданному уровню. В этом случае возможен выход из контекстного окна и "забытие" предыдущего результата, однако такая последовательность приводит к синтезу уже гораздо большего кода, причём он может самокорректироваться агентами по ходу генерации а также тестироваться, то есть фактически самособираться. Осталось только добавить в компиляторы вменяемые отклики, пригодные для ИИ (не на человеческом языке) а адаптированные для агентов в виде уже токенизированных идентификаторов.
Уровень синьора - это позвонить разработчикам этих языков и поставить вопрос об унификации требований на основании запросов трудящихся джунов/мидлов всех стран что это одно и то же, организовать симпозиум ISO/IEC с последующим вынесением вопросов на пленарное заседание, голосованием видных деятелей стандартизации метрологии и сертификации по приведению кодовой базы ЭВМ к актуальному уровню. А то как-то не солидно получается.
вот это кстати идея. То есть представлять не цифры, а их заменители, позволяющие быстро считать. Например, треугольники, N-угольники и их пересечение, как некий код который можно преобразовать в число. Кстати интересный вопрос - есть ли не геометрическое доказательство что
Самый хороший тест - это промпт написать виртуальную машину для абстрактного языка и промоделировать её. В принципе +- все модели делают одно и тоже так как датасеты для претрейна одинаковые. Разница в масштабировании, пока что это удаётся, но там есть предел. Много токенов не равно оптимизация большого проекта. Должны быть уже архитектурные изыскания на предмет понимания состояния контекста. Вывод для Гигачата.
make a python script that interpret virtual machine with code "a" add "s" substract, "m" for multiply accumulator and "p" to push var to stack and "u" pop from stack for string "a10s3m6p7p2a3usum" without argument use acc by default and vaue from top of stack
После чего необходимо "допилить" согласно обратной связи от ошибок интерпретатора, потребовалось 8 итераций. в ходе чего получается... не рабочйи вариант
ВайбVM
В этом примере есть ключевой момент для ИИ - несмотря на весьма маленький код, имеется генерация кода по описанию и кода по данным (которые необходимо интерпретировать). По всей видимости ИИ-модели крайне неэффективно "представляют" внутри интерпретацию данных, то есть "делай на примере", хотя запрос и сам промпт сформулирован довольно точно чтобы ИИ автоматом определил граничные значения и форматы. Строка-пример, по всей видимости, существенно ломает контекст.
Тут другой ключевой аспект - стандарты ЯП и вот эти самые данные содержат все предыдущие 50+ лет становления IT в том виде котором оно сейчас есть. Фактически привнесение новых элементов в код или данные это синтаксический сахар уровня дообучения или даже RAG. В некотором смысле подведена черта под дальнейшим развитием языков и будет некий промпт-инженеринг, заключающийся просто в мониторинге синтаксических деревьев и синтетических тестов. То есть задача формализуется поведением и границами чем непосредственной её реализацией.
10 ГБ репа из них 99.9% данные, вспомогательный UI и 0.00001% непосредственно математического аппарата (ядра) кода. Так вот ИИ позволит эти микропроценты соптимизировать так, что они будут определять 99% быстродействия и функционала всей системы. Там "коэффициенты усиления" просто колоссальные. А уровень понимания и матаппарата для оптимизации код-данные-память-вычислитель уже практически как PhD Computer Sciense а не джуниор.
Очень важно при этом предоставлять инфу из вывода терминала-логов итд. Мы буквально недавно отладили очевидную ошибку, но скрывшуюся за inlcude. Компилятор не указал что нет прототипа функции и возвращал значение через регистр аккумулятора в DSP, вместо стека или вспомогательного FPU регистра. Скормив ему вывод дизассемблера (с включённой опцией кода), состояние регистров, map-файл размещения в памяти, порядка линковки библиотек удалось выловить комплексную проблему и с памятью, и с тем что инклудить, как вызывать матфункции, какие аргументы double-float итд итп. То есть фактически проблема должна содержать сам тест и результаты теста, а также инлайны от ИИ, которые он предлагает. Желательно инлайны делать не текстом а в виде придуманных для себя идентификаторов тест 0xA,тест 0xB, чтобы сэкономить контекстное окно. Уже не представляю эмбеддед разработку без ИИ. Причём уровень хоть в машинных кодах хоть на ассемблере хоть на питоне для МК. Там могут быть даже чудеса из микса C в контроллере + описание логики на Verilog/VHDL.
Кто бы что не говорил но плагины к VSCode от Сбера (GigaCode) и Яндекса (SourceCraft) вполне себе рабочие решения с приличным окном в 128 килотокенов или ~полмегабайта данных. Сильных глюков не обнаруживается даже на 1000 строках. Отличный вариант для уже структурированных вручную проектов. Контекст можно "скармливать" в виде файлов или вывода терминала. Желательно общаться на английском, так как, естественно, датасеты для претрейнинга это гитхабы, стэкэксченджы итд. Скорее всего даже чаты и форумы со всего мира переводятся на английский автоматом а уже потом идут как трейнингсэт, даже в этом случае вполне приемлемый результат по коду. Вообщем не важно какой язык фактически оперирование идёт с неким пока ещё "виртуальным" абстрактным синтаксическим деревом, включающим общую спецификацию всех языков программирования, включая HDL/SQL релейную логику и прочую экзотику.
Самый краткий пример. Заходим на Сбер-Гигачат и просим сгенерировать объекты в общем виде. Например, задать массив начальных координат окружностей и их диаметров, располагаемых внутри квадрата 640x480, причём диаметры случайные и не превышают от 1/10 до 1/3 величины экранной области. Координаты внутри области. Сетка только целочисленная. Итак.
Промпт 1. Make a python script contains screen size of 640 x 480 with array of array of [x0,y0 and d] of some circles
Вполне рабочий вариант. Мы создали объекты в виде массива в массиве. Теперь просим инкапсулировать данные в объект. Объект - это формальный контейнер для данных, имеющий неявный идентификатор. Методы объекта - имеют неявный идентификатор - указатель на объект (его местоположение). Пишем.
Промпт 2. make cirles as class incapsulate x0 y0 and diameter
Получили всё тоже самое. Теперь модернизируем объекты в иерархию - добавим обычные круги и цветные а также сделаем итерацию по объектам динамическую - то есть вызов функции по указателю, являющимся фактически идентификатором объекта (таблица виртуальных функций с индексом/списком switch-case как угодно)
make a colored circle as subclass to base circle without color and make dynamic behaviour
В этой схеме мне важно указать не абсолютные данные в объекте а относительные, то есть что привносится, а что удаляется (на C++ это private) а то как реализовать поведение - отдельный вопрос. В коде видно, что ИИ разделил поведение без виртуальных функций (и правильно сделал) с отдельными экземплярами контейнеров, заставим собрать "как в учебнике" объекты в единый контейнер. То есть несмотря на наличие иерархии это ещё не ООП (!), т.к. нет поведенческого полиморфизма. ООП = состояние+поведение+идентичность+полиморфизм.
make base_circles and colored as single array with different objects
Теперь если посмотреть то фактически мы описываем не сами объекты, а то что они содержать и как взаимодействовать с окружением. То есть нам без разницы что это - список, класс, иерархия, полиморфизм или нет. Нам важно чтобы это влезло в контекстное окно. Теперь добавим ограничение в сами объекты. Пишем
make restricion of coordinates at each circle object constructor no more than 320x200 by x0 and y0 and saturate these values. Generate circles with random diameter from 1/10 to 1/3 of screen size
Вообщем теперь любой (!) язык собственно становится ассемблером для промптов, которые рано или поздно будут приведены к поведению некоего универсального языка запросов и формирования данных. А парадигма и всё остальное выбирается исходя из заданных ограничений и архитектурных особенностей. Включая оптимальную по разным критериям оптимизацию (память, быстродействие, отклик, пропускная канала связи итд).
Можно также умножать на 11 - посредине сумма крайних цифр
и прочие приёмы, чтобы свести к данным правилам, равно как для цифр, близких к 10 сложением-вычитанием 
как сумма-разность квадратов итд. Ну и конечно же 
(логарифмическая линейка), включая поиск по LUT. То есть достаточно запомнить хотя бы 2,4,8,16...65536. Включая метод последовательных итераций с остатками от деления, метод Ньютона применимо к умножению и др. 
,
, найти 
приближающее дробь к 
за минимум итераций.
Визуально все ОС уже в браузере, включая ИИ. Так что как то так незаметно HTML-рендер стал фактически движком для всего остального что есть в ОС для пользователя.
Лучше привести какие-либо численные параметры. Или более точные формулировки. Например, работа по регламенту
, или если работа с изменяющимися условиями работодателем то 
.
Вот тут у многих недопонимание. Программировать - это фактически рисовать элементы абстрактного синтаксического дерева в виде блок-схем по ГОСТ 19.701-90. Вне этого - просто изучение синтаксиса языков программирования для ввода в ЭВМ этой блок-схемы. В подавляющем большинстве бухгалтерских задач хватит Fortran образца конца 50-х, собственно он и есть - транслятор формул. Всё остальное строго говоря программированием не является а есть реализация протоколов и API согласно некоего коллективного ТЗ. Тот же самый С создан Риччи и Керниганом образно говоря в курилке Bell Labs просто как хороший и удобный инструмент. И куда не ткни везде примерно такой подход. Это уже потом накрутили это как общепромышленный или международный стандарт. Вообщем нарочно не придумаешь. Так вот ИИ и предлагает принципиально новую парадигму минуя этап структурирования и проектирования объектов (это в подавляющем большинстве случаев справочный шаблон) а непосредственную реализацию последовательности действий или конечного результата и не важно на какой платформе или фреймворке это сделано.
Самое главное в C23 для эмбеддинга это типизированные enum-ы и битовые поля на их основе. Теперь наверняка можно нормально в отладчике просматривать текст а не цифры регистров.
Боюсь это уже несколько старомодно.
Слишком долго изучать то где есть синтаксис, когда проще использовать С-ассемблер
make simple application on C winapi for SDL 1.2 please
Add error and exception catch using C
Тот кто составлял маршрут и загружал его в датасет для обучения ИИ скорее всего ехал на FPV-дроне.
Простой проект уровня например, монитора порта с выводом на экран и общением по usbtty вполне можно теперь делать промптами без единой сточки кода вручную, сам себе сделал несколько мониторов. Плюс по мелочам различного рода генерировалки изображений, парсеры, утилиты, обработчики, тесты. То есть вот эта вся возня и занимает порой пожалуй 95% времени, когда ключевой аспект алгоритма или матаппарат делается за 5 в виде пары формул. ИИ позволяет в существенной мере автоматизировать эту рутину, особенно что касается рефакторинга а уж тем более генерации доков, графиков, обработки данных, приведение данных в формат для последующей итерации. Незаменимый инструмент вот уже более двух месяцев. Перефразируя классику: 128 кБ контекстного окна хватит всем.