korvin:
В смысле? А если вместо ключевого слова const в языке используется val — то всё, приплыли?

https://forum.sources.ru/index.php?showtopic=421515&view=findpost&p=3848170

D_KEY:
Ну я тут имел в виду, что оно ещё и во время компиляции гарантировано вычисляется :)

https://forum.sources.ru/index.php?showtopic=421515&view=findpost&p=3848169

korvin:
Это то же самое.


Ага, и хотя это просто абстрактный пример, нормальное имя могло бы сразу дать понять, что место ей не в каком-то безликом Constants, а в соответствующем классе/модуле. )

https://forum.sources.ru/index.php?showtopic=421515&view=findpost&p=3848168

D_KEY:
А я бы предпочел что-то вроде:



Добавлено 14.06.21, 09:46
Хотя само наличие константы с таким названием смущает :)

https://forum.sources.ru/index.php?showtopic=421515&view=findpost&p=3848167

sergioK:
Покажи не велосипед

https://forum.sources.ru/index.php?showtopic=421515&view=findpost&p=3848141

Berbraer: ЫукпШ, слухай, ну я не настолько тупенький чтобы не разобраться как искать по проекту в студии :) Просто сишные передачи указателей немного ломают мозг с непривычки + непонимание, какая функция стандартная и известно что делает, какая - самописная автором.
Но не суть, нашёл.
Окончательное вычисление/форматирование результата происходит в функции
void CDiskMarkDlg::SetMeter(CStaticFx* control, double score, double latency, int blockSize, int unit)
И выводятся в m_TestRead через void CDiskMarkDlg::UpdateScore()

Соответственно, в SetMeter можно перехватывать doble результаты.

Вдруг кому пригодится.

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

https://forum.sources.ru/index.php?showtopic=421488&view=findpost&p=3848140

FasterHarder: В общем понял (прочитав в одном материале), что надо напрочь отказываться от весовой матрицы и переходить на список смежности.
Колоссальной оптимизации можно добиться, если построить список смежности, упорядочив внутри по весу по неубыванию...

На рис.показал, что из себя будет представлять такой список смежности (один из вариантов реализации, далеко не факт, что оптимальный):
_______________________________.png (, : 8)

То есть, если подается на вход весовая матрица (например, считыванием из файла + с клавиатуры обычно не вводят весовые матрицы - неудобно абсолютно+долго), то строим список смежности, добавляя по блоку информации в нужный ЛОС, не теряя при этом отсортированности. По факту возможны 3 операции вставки в ЛОС: в начало, в конец и в "средину". Придется каждую из них программить, эх...итоговая программа вообще разрастется уже до 300+ строк кода

Если происходит ввод с клавиатуры, то требуем формат: <1ая смежная вершина> <2ая смежная вершина> <вес ребра между ними>, то есть 3 числа. И также после этого происходит добавление в таблицу списка смежности, не теряя упорядоченности.

Получив "отсортированный" список смежности, операция поиска минимального веса будет выполняться за время O(n) (n - кол-во вершин графа). Это может в "миллиарды" раз ускорить алгоритм). Правда после этого, надо производить удаление соответствующего узла из начало списка + ведь еще придется удалить симметричного близнеца(!), который будет стоять не в начале списка. Вот эта перестройка списка смежности может быть не оч.быстрой, хотя...

Также благодаря списку смежности и удалению узлов в конце концов может не остаться ни одного элемента в конкретном ЛОС - и это замечательно, в этом случае вершина больше вообще не участвует в обработке (об этом писал ранее).

Единственный момент, если обрабатывается ПОЛНЫЙ ГРАФ, то вроде в этом случае нецелесообразно вообще получать список смежности, хотя...Ведь на построение уйдет кучу времени, но потом это будет окупаться при поиске наименьшего. Здесь непонятка, стоит ли овчинка выделки. С др.стороны ведь неизвестно, какого типа подается на вход граф и надо убедиться, что он является полным + очевидно, что в 99.99% граф будет подаваться неполным, поэтому, независимо от конфигурации графа (полный, разреженный, плотный и пр.) надо всегда получать список смежности и это ДОЛЖНО РЕЗКО увеличить производительность выполнения прожки, вроде)

p.s. тут сплошная динамика и все это надо закодить корректно и будет несколько сотен строк кода...в их примерчиках по 25-30 строк, правда 19 программ из 20, которые я видел были на С++ (в связке с СТЛ-кой приблудой) + на весовых матрицах (без построения списка смежности). Пусть попробуют на Си покодить, создавая с нуля велосипеды))

https://forum.sources.ru/index.php?showtopic=421519&view=findpost&p=3848139

korvin:
Не удивительно.


Ещё какой велосипед.

https://forum.sources.ru/index.php?showtopic=421515&view=findpost&p=3848138

sergioK:
Это делают те кто не понимает, а в сети таких полно, Я за 15лет ни разу не делал,
То что при прописании констант, интерфейс перестает быть тем чем ему дали с рождения все знают,
Напиши свой язык, где никто ничего не переворачивает все с ног на голову ;)

https://forum.sources.ru/index.php?showtopic=421515&view=findpost&p=3848132

B.V.: :whistle:
S.T.A.L.K.E.R. 2: Heart of Chernobyl — Gameplay Trailer

https://forum.sources.ru/index.php?showtopic=284122&view=findpost&p=3848127

B.V.: А вот и Squadron 42Starfield
Starfield: Official Teaser Trailer

https://forum.sources.ru/index.php?showtopic=371198&view=findpost&p=3848126

scrambrella: Размечающая программа это готовый ИИ. Вряд ли в открытом доступе есть такое.
Зачем вам размечать снимки?

https://forum.sources.ru/index.php?showtopic=421516&view=findpost&p=3848108

D_KEY:
Класс в ООП можно рассматривать в качестве модуля. Интерфейс в этом качестве я бы рассматривать не стал. Ну и кроме того, я думаю, что интерфейс провоцирует делать implements ради констант.

https://forum.sources.ru/index.php?showtopic=421515&view=findpost&p=3848105

applegame: Так же как и к понятию класса. И то и другое просто костыль для обхода ограничения самого языка. Не вижу чем один костыль лучше другого.

https://forum.sources.ru/index.php?showtopic=421515&view=findpost&p=3848101

D_KEY:
А еще могут много чего еще, что не имеет отношения к интерфейсам. Так что нет, в плюсах отдельной языковой конструкции для интерфейсов нет. Я не говорю, что она нужна.


Хороший заход. Но на практике это значит, что просто нужно использовать эту дополнительную возможность разумно. Она вполне может помогать описать интерфейс. Тогда все ок.


Потому, что это не имеет никакого отношения к понятию интерфейса.


Наверно можно представить себе ситуации, когда это разумно. Но в данном случае это не так. Особенно если речь о том, чтобы делать implements для "импорта" констант в том классе, где мы хотим эти константы юзать. Это очевидно переворачивает все с ног на голову.

https://forum.sources.ru/index.php?showtopic=421515&view=findpost&p=3848100

https://forum.sources.ru/index.php?showtopic=421472&view=findpost&p=3848098

applegame: Тогда в плюсах таки есть интерфейсы: абстрактные классы. Они делают именно то, что ты описал. Кроме того, как минимум в Java/C++/D есть возможность пихать константы в интерфейсы/абстрактные классы. А значит определение интерфейсов в этих языках не соответствует твоему идеализированному определению. Ты же скорее описал не интерфейс, а трейт из Rust.
А интерфейс-то почему не может быть использован в качестве неймспейса? Считай эти константы частью интерфейса, примерно как абстрактный класс в C++. Разница скорее философская: "патамушта мне кажется, что так правильнее".
Из объективных аргументов только то, что такое "перечисление" не имеет собственного типа. Но частенько тебе нужен просто набор констант, а не перечисление и тут я не вижу никаких объективных преимуществ класса перед интерфейсом. Писать чуть больше, результат тот же.
А для перечислений, еще раз повторю (почему-то вы все игнорируете эту конструкцию), в жабу ввели enum.

https://forum.sources.ru/index.php?showtopic=421515&view=findpost&p=3848097

FasterHarder: Всем хай! Сходу к делу.

Как известно, алгоритм Прима позволяет получить минимальное остовное дерево. С точки зрения мат.модели и алгоритма вроде там все понятно: берем произвольную вершину, затем берем смежную с минимальным ребром, потом среди отобранных снова смежную с мин. ребром и т.д., пока не будут взяты все вершины. Тут вроде все достаточно просто...

Программу я написал ("чистый" Си, стандарт С89) и вроде все прекрасно работает:
_______________________________.png (, : 19)


пока не переходим на big data, я бы даже сказал medium data). Решил потестировать программу на нормальном кол-ве вершин, вот свел результаты теста в таблицу _ диаграмма:
__________________________________________.png (, : 22)

и вот у меня на данный момент главный вопрос: быстродействие программы нормальное?))
Если никуда не годится, то придется ворошить структуры данных. + у меня у самого есть идея по оптимизации кое-какой там: ведь вершина, которая добавлена в миностов, и для которой добавлены в остов все смежные вершины вообще в дальнейших проверках не участвует, но сначала хочется понять про текущее быстродействие


Мне хотелось обсудить некоторые детали по алгоритму Прима.
Говорится, что Прима будет работать на взвешенном неориентированном связном графе.

вопрос №1: То есть, перед тем, как запускать построение мин.остова надо убедиться, что граф связный? То есть содержит ровно 1 компоненту связности. Если компонент связности БОЛЬШЕ 1ой, то решения нет? Или для каждой компоненты строим мин.остов. Склоняюсь к тому, что решения нет.

момент №2: Если граф является ориентированным, то Прима не сможет работать всегда! Т к алгоритм может легко уйти в тупик, взяв минимальный вес, а там тупик) Понятно, что можно подобрать конфигурации орграфа, когда Прима построить верный миностов, но в данном случае алгоритм не соот-ет свойству массовости ---> не является алгоритмом...

вопрос №3: Хорошо, когда веса все уникальны! В этом случае, как понимаю, миностов существует в единственном экземпляре. А, если есть дубликатные веса...Ну, например, 3 ребра имеют равный вес = 17, а остальные все уникальные. Ведь в этом случае существует более одного миностова. Здесь ведь какая-то комбинаторика замешана, вроде? Может перестановки с повторениями или около того? Есть формула, которая позволяет узнать, сколько всего возможно миностовов, зная частотности появления весов? (или просто перемножить эти частотности, хм...) Кстати, если пытаться получить ВСЕ возможные миностовы (когда есть дубликаты весов), то, ИМХО, сложность решения по экспоненте увеличивается) (хотя может и нет и там все на рекурсии как-то мутить надо)

момент №4: Как известно, многие графовые алгоритмы чувствительны к отрицательным величинам (весам). Как понимаю, Приму побоку это. Прекрасно отработает.

момент №5: Допустим, что граф взвешенный, связный, неорграф и веса любые целые числа (как +, так и -). Если рассматривать задание графа через матрицу весов, то отсутствие веса, как можно обозначить, например, если данные считываются из файла текстового?? Например, в текущей программе я ставлю 0, но у меня все веса НАТУРАЛЬНЫЕ числа и проблем никаких...Брать какое-то +inf/-inf, но теоретически вес может иметь любое допустимое разрешенное типом данных число, в том числе и пограничные значения. 0 ставить тоже нельзя, т к допустимы отрицательные веса. Вижу решение проблемы только через переход структуры данных, отвечающей за весовую матрицу на тип дробный (например, double), double >> long int > int. Но в этом случае резко возрастает объем динамической памяти, т к sizeof(double) / sizeof(int) >= 2. Или вообще надо работать через списки смежности в этом случае и про задание через весовую матрицу следует забыть??



Добавлено 13.06.21, 06:42
забыл еще дописать, что, когда тестировалось на разном кол-ве вершин, то появление ребра (веса) было с вероятностью 50%. Т е каждая вершина графа связывалась с половиной всех вершин остальных...наверное, можно считать, что неорграф сильно связный, но НЕ полный. Вероятность того, что при генерации весов будет больше 1ой компоненты связности ----> 0 при увеличении числа вершин

https://forum.sources.ru/index.php?showtopic=421519&view=findpost&p=3848096

sergioK:
Оно, как бы это сказать, ну слишком теоритическое,

Добавлено 13.06.21, 05:17

Я не видел что бы их кто-то использовал.

Добавлено 13.06.21, 05:20

В Яве интерфайс это класс без состояния, stateless.

Добавлено 13.06.21, 05:24

В понятиях Явы это не велосипед, его придумывают те кто пишет
класс с private конструктором, хорошо еще double checking не имплементируют ;)

Добавлено 13.06.21, 05:27

Говно не Java/С++/D а мозг людей не способных понять как оно работает, ;)
и делающих такие выводы.

https://forum.sources.ru/index.php?showtopic=421515&view=findpost&p=3848095

FasterHarder: Вот пост №2 двоякий: с одной стороны его полезность ---> к 0, с другой примерно это мне и нужно

Т е планируется ручная разметка, затем программная разметка, а затем сравнение точности.

Нужен КОНКРЕТНЫЙ алгоритм семантической сегментации изображений, ну, если такой есть, а вроде есть
А в целом "шапка не по Ваньке", на хрен я полез в эту хрень, явно, что здесь с наскока ни хрена толкового не сделать, лол

В общем, если НЕТ алгоритма, который можно понять дубу с 0 за 8-10 часов, то в пень эту задачу - закину в самый черный угол до лучших времен (на несколько миллионов лет)

https://forum.sources.ru/index.php?showtopic=421516&view=findpost&p=3848091