Переделка солвера #8

New Issue

ParkSuMin · 2025-12-16T21:33:18+01:00

ParkSuMin commented

2025-12-16 21:33:18 +01:00

Плохие вести, коллеги

Обнаружилось то, о чём я совершенно забыл. В js реализации planegcs автор специально сериализовал все примитивы и ограничения. Таким образом в солвер подавался только этот набор.

Что у нас?

В текущей кодовой реализации солвер хранится как объект класса Canvas. Хорошо - скажете Вы. И это будет правдой. Но до тех пор пока мы не узнаём, что координаты привязаны к списку параметров. И вот например мы хотим сделать что-то такое:

sys.addConstraintCircleRadius(circle, radius);
p_parameters.push_back(radius);

Казалось бы - гуляй да радуйся - тем более radius теперь в списке параметров.
Но не тут то было...
Посмотрим на реализацию addConstraintCircleRadius в GCS.cpp:

int System::addConstraintCircleRadius(Circle& c, double* radius, int tagId, bool driving)
{
    return addConstraintEqual(c.rad, radius, tagId, driving);
}

Как Вы можете увидеть - внутри этого ограничения - другое ограничение. Это нормально. Интересно тут другое. Я не знаю с чем это связано, но по какой-то неведомой мне причине addConstraintEqual работает не как c.rad = radius, а как radius = c.rad. То есть при попытке сменить radius нас обратно тянет к c.rad.

Что делать?

Пока что не слишком много идей. Есть два основных варианта:

Пересадка на SolveSpace
Это наиболее древний экземпляр, но старичок всё ещё живой. Из его плюсов - для него есть нормальная документация и примеры (!!). Из минусов - код всё-таки там запутанный и непонятно как вообще собрать там либу без makefile.
Создать отдельный массив для хранения размерных ограничений
В нанокаде я подсмотрел, что размерные ограничения там хранятся в отдельном менеджере. Можно что-то проделать и у нас. Таким образом мы не потеряем данные, и радиус окружности будет изменяться под воздействием radius.

P.S. Возможно стоит ещё оптимизировать немного код, хотя скорее я выделю это в отдельную задачу.

# Плохие вести, коллеги Обнаружилось то, о чём я совершенно забыл. В js реализации planegcs автор специально сериализовал все примитивы и ограничения. Таким образом в солвер подавался только этот набор. # Что у нас? В текущей кодовой реализации солвер хранится как объект класса Canvas. Хорошо - скажете Вы. И это будет правдой. Но до тех пор пока мы не узнаём, что координаты привязаны к списку параметров. И вот например мы хотим сделать что-то такое: ```cpp sys.addConstraintCircleRadius(circle, radius); p_parameters.push_back(radius); ``` Казалось бы - гуляй да радуйся - тем более radius теперь в списке параметров. Но не тут то было... Посмотрим на реализацию addConstraintCircleRadius в GCS.cpp: ```cpp int System::addConstraintCircleRadius(Circle& c, double* radius, int tagId, bool driving) { return addConstraintEqual(c.rad, radius, tagId, driving); } ``` Как Вы можете увидеть - внутри этого ограничения - другое ограничение. Это нормально. Интересно тут другое. Я не знаю с чем это связано, но по какой-то неведомой мне причине addConstraintEqual работает не как c.rad = radius, а как radius = c.rad. То есть при попытке сменить radius нас обратно тянет к c.rad. # Что делать? Пока что не слишком много идей. Есть два основных варианта: 1) Пересадка на SolveSpace Это наиболее древний экземпляр, но старичок всё ещё живой. Из его плюсов - для него есть нормальная документация и примеры (!!). Из минусов - код всё-таки там запутанный и непонятно как вообще собрать там либу без makefile. 2) Создать отдельный массив для хранения размерных ограничений В нанокаде я подсмотрел, что размерные ограничения там хранятся в отдельном менеджере. Можно что-то проделать и у нас. Таким образом мы не потеряем данные, и радиус окружности будет изменяться под воздействием radius. P.S. Возможно стоит ещё оптимизировать немного код, хотя скорее я выделю это в отдельную задачу.

ParkSuMin added the bug enhancement labels 2025-12-16 21:33:18 +01:00

ParkSuMin added reference Circle

2025-12-16 21:37:07 +01:00

ParkSuMin commented

2025-12-22 18:36:29 +01:00

Я тут так подумал - наверное стоит создать отдельный массив

Но в целом я готов переписать под SolveSpace

Я тут так подумал - наверное стоит создать отдельный массив Но в целом я готов переписать под SolveSpace

This repo is archived. You cannot comment on issues.

1 Participants

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: ParkSuMin/DRAwer_2_0#8