0 мне нужен отдельно в новой идее кода, который я ещё не доделал. Чтобы не вводить ещё один булевый массив.
что-то вы такое странное пишете.... Какая разница, ноль или нет? - ноль такое же число, как любое другое. Я в своей программе никак ноль не обыгрываю, работает как любой другой размер
0 мне нужен отдельно в новой идее кода, который я ещё не доделал. Чтобы не вводить ещё один булевый массив.
что-то вы такое странное пишете.... Какая разница, ноль или нет? - ноль такое же число, как любое другое. Я в своей программе никак ноль не обыгрываю, работает как любой другой размер
Слушал я вас долго и внимательно.... Для программы конечно всё равно. А в жизни как мне кажется ноль соответствует рожковому ключу у которого "рога" только с одной стороны. Есть у меня такие. Вот входят ли они в условие - это Евгений может сказать.
А в жизни как мне кажется ноль соответствует рожковому ключу у которого "рога" только с одной стороны. Есть у меня такие. Вот входят ли они в условие - это Евгений может сказать.
пожалуй , Вы правы. Я как-то за алгоритмами совершенно забыл о реальной задаче...
Слушал я вас долго и внимательно.... Для программы конечно всё равно. А в жизни как мне кажется ноль соответствует рожковому ключу у которого "рога" только с одной стороны. Есть у меня такие. Вот входят ли они в условие - это Евгений может сказать.
В данном случае 0 это не размер ключа, а цифровая метка для размера ключа.
Немного оптимизировал код для "ветвей и границ", переписал узкие места, добавил больше входных проверок. В итоге время для тестового набора ЕП даже чуть выросло - было 2.8 мс, стало порядка 3.1мс. Зато время для набора kolyn из сообщения #173 уменьшилось почти вдвое - с 7.9мс до 4.1мс.
Код не выкладываю, потому что пока не могу справится с главной проблемой - нехваткой памяти. На невырожденных наборах более чем с 25-30 уникальными ключами глубина рекурсии, необходимой для решения, оказывается 5-6 уровней... память заканчивается и программа крашится...
Думаю, что повысить этот предел в несколько раз у меня точно не выйдет, хорошо если удастся поднять на 30-50%. В связи с этим вопрос к ЕП - по условиям программа должна работать на "любом разумном числе ключей". Разумное в этой фразе - это сколько? :)
Гаечные ключи относятся к изделиям, размеры которых строго регламентированы ГОСТ и не могут быть нарушены... от 3.3 мм до 155мм (39 размеров)
Вот на хрена ты влазишь в темы, в которых тебе нечего сказать по делу? Только свою глупость выносишь на люди. Информация по ГОСТ конечно интересная, но если бы ты поработал немножко головой, то вспомнил, что ключи бывают разные. На разных сторонах ключа могут быть разные типоразмеры, например 12-12 12-13 12-14, и тогда во сколько разных ключей превратятся 39 размеров?
слушай, тебе правда лишь бы что вякнуть? или ты в программировании совсем по нулям, хуже новичка?
Ты вот это
//
// Тип данных для хранения ключа
//
struct Spanner : public Printable {
uint32_t price;// цена в копейках
uint8_t size1; // размер 1
uint8_t size2; // размер 2
uint8_t included; // если 1, то включается в результирующий набор
Не знаю, что тут будет с памятью, но решение этого набора методом перебора займет годы :)
Напомню, совсем простенький набор kolyn из сообщения #173 потребовал на одной программе перебора порядка 3х минут, а на другой все 12... а сложность перебора с числом вариантов как растет? Факториал?
Предлагаю, кстати, поставить верхнее ограничение времени работы программы... ну точно не более 15 минут.
Возможно, Вам попалась неудачная литература. На самом деле там все предельно просто и, главное, целиком ложится в обычный здравый смысл.
Просто и известно с детства. Это ситуация с Иваном - дураком, когда он перед камнем стоит. "Налево пойдешь - профит найдешь, направо - коня потеряешь". Только у Ивана надпись на камне уже готова - бери и читай, а для решения этой задачи ее самому придумать и нацарапать необходимо... И в этом основная засада.
b707 пишет:
Подходите с точки зрения здравого смысла. Любой ключ (кроме очевидных вариантов) - может либо входить в набор, либо нет. Вот вам и две ветви... А границы - это когда вы откидываете заведо проигрышные пути, например те, что дороже текущего минимума.
Уж куда я этот здравый смысл не пытался приложить, так и не сумел сформулировать эти "границы" , другими словами степень полезности (бесполезности) включения конкретного ключа в конечный результат.
Только не подумайте, что клянчу очередную подсказку:). Просто мой уровень - метод полного перебора, до большего не дорос(((
поправил, код, канпилятор видимо сам в правильный формат данные ключей приводил )))
PS и чё тут еще не так?
//
// Тип данных для хранения ключа
//
struct Spanner : public Printable {
uint32_t price;// цена в копейках
uint8_t size1; // размер 1
uint8_t size2; // размер 2
uint8_t included; // если 1, то включается в результирующий набор,0 - возможно будет включен,10 - исключен из перебора
//ТУТ НЕ ТАК,КАК В ВАС! included МОЖЕТ ПРИНИМАТЬ: если 1 (оn), то включается в результирующий набор,0 (off) - возможно будет включен,
Spanner(const uint8_t s1, const uint8_t s2, const uint32_t p, const uint8_t ini = 0)
: price(p), size1(s1), size2(s2), included(ini) {}
size_t printTo(Print & p) const {
size_t res = p.print(size1);
res += p.print('-');
res += p.print(size2);
res += p.print(": ");
res += printPrice(p, price);
return res;
}
static size_t printPrice(Print & p, const uint32_t priceCop) {
size_t res = p.print(priceCop / 100);
res += p.print(" руб. ");
res += p.print(priceCop % 100);
res += p.print(" коп.");
return res;
}
};
//
// Массив всех ключей
//
static Spanner spanners[] = {
{2, 3, 10000},
{3, 4, 2},
{3, 5, 3},
{4, 5, 4},
{5, 6, 5},
{6, 7, 6},
{6, 7, 7},
{7, 8, 8},
{8, 9 , 41520},
{8, 10, 43054},
{9, 11, 9},
{10, 11, 10},
{10, 12, 51455},
{10, 13, 11},
{11, 12, 12},
{11, 13, 13},
{12, 13, 56544},
{12, 14, 57675},
{13, 14, 15},
{13, 15, 62845},
{13, 16, 16},
{13, 17, 17},
{14, 15, 61714},
{14, 17, 70276},
{16, 17, 76496},
{16, 18, 81989},
{17, 19, 82312},
{17, 22, 18},
{18, 19, 82877},
{18, 21, 19},
{19, 22, 110826},
{19, 24, 20},
{21, 22, 21},
{21, 24, 22},
{22, 24, 145560},
{22, 27, 23},
{24, 27, 171570},
{24, 30, 24},
{27, 30, 25},
{27, 32, 26},
{30, 32, 27},
{30, 34, 28},
{30, 36, 29},
{32, 34, 30},
{32, 36, 31},
{34, 36, 32},
{36, 41, 33},
{41, 46, 34},
{46, 50, 35},
{50, 55, 36},
{55, 60, 37},
{65, 70, 38},
{70, 80, 39}
};
static constexpr uint8_t totalSpanners = sizeof(spanners) / sizeof(spanners[0]);
const uint8_t on = 1, off = 0, excluded = 10;// если 1, то включается в результирующий набор,0 - возможно будет включен,10 - исключен из перебора
Экий Вы нетерпеливый. Это же полный перебор, Вам же писали выше - время пропорционально ФАКТОРИАЛУ от кол-ва ключей. Так что одно из двух - либо решит, либо у Вас электричество в розетке кончится:)
Для начала напишем простой полный перебор. Выглядит он для N ключей вот так:
Solution current(0); // "Текущее решение" изначально пустое
Solution theBest(UINT32_MAX); // "Наилучшее" на данный момент решение. Изначально имеет огромную цену.
//
// При любом вызове эта функция перебирает
// N-start вариантов
//
void britishMuseum(int start = 0) {
for (int i = start; i < N; i++) {
current.add(spanner[i]); // добавить i-ый ключ в текущее решение
if (current.isCompleted()) { // ЕСЛИ текущее решения полное (все размеры есть)
if (current.cheaper(theBest)) { // ЕСЛИ текущее решение дешевле наилучшего
theBest = current;
}
}
if (start + 1 < N) britishMuseum(start + 1); // здесь добавится следующий(ие) ключ(и)
current.remove(spanner[i]); // удалим этот ключ
}
}
// ВЫЗОВ
britishMuseum();
После такого вызова наилучшее решение останется theBest. При этом функция честно переберёт все N! вариантов решений.
Прежде, чем переходить к ветвям и границам, убедитесь, что эту программу Вы полностью понимаете, т.к. сейчас мы будем её править.
Давайте включим здравый смысл и скажем себе: если мы уже нашли полное решение, то какой нам смысл пытаться добавлять к нему какие-то ещё ключи? Новых размеров это не даст, они и так все присутствуют, только цену увеличит, так ведь? Давайте не будем проваливаться рекурсию в том случае, если полное решение уже найдено.
//
//
void britishMuseum(int start = 0) {
for (int i = start; i < N; i++) {
current.add(spanner[i]); // добавить i-ый ключ в текущее решение
if (current.isCompleted()) { // ЕСЛИ текущее решения полное (все размеры есть)
if (current.cheaper(theBest)) { // ЕСЛИ текущее решение дешевле наилучшего
theBest = current;
}
}
else if (start + 1 < N) britishMuseum(start + 1); // здесь добавится следующий(ие) ключ(и)
current.remove(spanner[i]); // удалим этот ключ
}
}
// ВЫЗОВ
britishMuseum();
Как видите, мы добавили единственное слово else в строке №11 и уже избавились от части рекурсивных вызовов.
Давайте думать дальше. А если мы заранее отсортируем массив ключей в порядке возрастания цены ключа? Тогда ведь мы сможем сделать вот что: как только цена текущего решения (пусть ещё неполного) сравнялась (или превысила) с ценой нашего наилучшего на данный момент решения, дальше можно не смотреть, т.к. цена решения будет только расти с добавлением каждого ключа, а значит, всё, что мы сможем получить на этой ветке заведомо будет хуже того решения, что у нас уже есть! Давайте это напишем:
Solution current(0); // "Текущее решение" изначально пустое
Solution theBest(UINT32_MAX); // "Наилучшее" на данный момент решение. Изначально имеет огромную цену.
//
// При любом вызове эта функция перебирает
// N-start вариантов
//
void britishMuseum(int start = 0) {
for (int i = start; i < N; i++) {
current.add(spanner[i]); // добавить i-ый ключ в текущее решение
if (current.cheaper(theBest)) { // ЕСЛИ текущее решение дешевле наилучшего
if (current.isCompleted()) { // ЕСЛИ текущее решения полное (все размеры есть)
theBest = current;
current.remove(spanner[i]); // удалим этот ключ
return; // Здесь больше нечего ловить
}
}
else { // Ага, цена текущего решения достигла (превысила) лучшее на данный момент
current.remove(spanner[i]); // удалим этот ключ
return; // Здесь больше нечего ловить
}
if (start + 1 < N) britishMuseum(start + 1); // здесь добавится следующий(ие) ключ(и)
current.remove(spanner[i]); // удалим этот ключ
}
}
// ВЫЗОВ
britishMuseum();
Давайте порассуждаем, что мы получили. Всякий раз, когда стоимость текущего решения сравняется или превысит стоимость наилучшего на данный момент решения, мы прекращаем перебор на данном уровне (и, уж тем более, не ныряем глубже в рекурсию) т.к. это бесперспективно, а возвращаемся на уровень выше. А вот пока цена меньше текущей наилучшей (условие в строке №11 ложно), мы проверяем, а не получилось ли у нас полное решение (проверка в строке №12). Если получилось, то запоминаем его как наилучшее и выходим на предыдущий уровень рекурсии. А вот если не получилось (условие в строке №12 ложно), то попадаем на строку №22 - т.е. ныряем на следующий уровень рекурсии.
Это и называется метод ветвей и границ. Как только цена превысила установленную границу (текущую наилучшую), мы тут же отрезаем всю дальнейшую ветвь перебора.
Кажется не сложным, если дано решение, да еще с подробными комментариями :) У меня даже полный перебор с помощью рекурсии написать не получилось, вернее после 26-и ключей ломалось. Пришлось "сочетание без повторений" сколипастить и встраивать в код.
И если
ЕвгенийП пишет:
мы уже нашли полное решение, то какой нам смысл пытаться добавлять к нему какие-то ещё ключи? Новых размеров это не даст, они и так все присутствуют, только цену увеличит, так ведь?
на это еще соображалки хватило и в моем варианте решения применяется, то
ЕвгенийП пишет:
как только цена текущего решения (пусть ещё неполного) сравнялась (или превысила) с ценой нашего наилучшего на данный момент решения, дальше можно не смотреть
это уже никак не сложилось в целую картинку. Какие-то обрывки мелькали, когда разбирал задачу о рюкзаке, но то такое. В любом случае мое честное решение в #150
Незачет. В строке 7 значение 5.5 описано как 5, а в строке 9 как 6
Завидую белой завистью. Вот КАК на это можно было внимание обратить?
не парься колян, это он второй раз троллит, описано было ранее с запятой И, зная прекрасно, что при присвоении, когда компилятор будет засовывать в структуру переменную он её усечет до целого в младшую сторону, разразился там выше гневной тирадой )))
PS кстати, компилятор даже не ругнулся на ошибку и прекрасно скетч скомпилировал
PPS время в миллисекундах это для твоего алгоритма
кстати, компилятор даже не ругнулся на ошибку и прекрасно скетч скомпилировал
так ошибки синтаксиса тут и нет, тут ошибка смысла - а такое компилятор не ловит.
Проблема не в том, что 5.5 обрезается до 5, а в том что в наборе уже есть такой размер. В итоге у тебя ключи с размером 5.5 становятся дублями ключей 5.
А все просто - выбери для замены 5.5 какой-то целый размер, незанятый в начальном наборе. Например 56
такой цели не было, показал все стандартизованные ключи, а уж как с долями миллиметров поступать решайте сами, в теме пасусь только из-за того, что интересно посмотреть алгоритм, что ЕП предложит, сам бы решал точно не перебором, а используя "социальную инженерию"
Перебором там должно быть на несколько порядков больше.
Проверил, цифры до миллисекунд не сходятся, но порядок верный. Время расчёта: 129867 миллисекунд против {17, 22, 18}, // за 102724 миллисекунд
Дело в том,что у меня не совсем "честный" перебор. Он начинается с н-ключей, которые определяются по кол-ву размеров и заканчивается, если при добавлении очередного ключа не меняется мин. сумма.
такой цели не было, показал все стандартизованные ключи, а уж как с долями миллиметров поступать решайте сами, в теме пасусь только из-за того, что интересно посмотреть алгоритм, что ЕП предложит, сам бы решал точно не перебором, а используя "социальную инженерию"
(выделено мною)
Интересно, а какая цель была?
Дело в том, что эта "неопределенность с долями" сокращает количество типоразмеров и искажает исходную задачу до полной неузнаваемости. В частности, для такой (искаженной) задачи решение будет совершенно другим.
0 мне нужен отдельно в новой идее кода, который я ещё не доделал. Чтобы не вводить ещё один булевый массив.
Это тоже правильный прием.
0 мне нужен отдельно в новой идее кода, который я ещё не доделал. Чтобы не вводить ещё один булевый массив.
что-то вы такое странное пишете.... Какая разница, ноль или нет? - ноль такое же число, как любое другое. Я в своей программе никак ноль не обыгрываю, работает как любой другой размер
0 мне нужен отдельно в новой идее кода, который я ещё не доделал. Чтобы не вводить ещё один булевый массив.
что-то вы такое странное пишете.... Какая разница, ноль или нет? - ноль такое же число, как любое другое. Я в своей программе никак ноль не обыгрываю, работает как любой другой размер
Слушал я вас долго и внимательно.... Для программы конечно всё равно. А в жизни как мне кажется ноль соответствует рожковому ключу у которого "рога" только с одной стороны. Есть у меня такие. Вот входят ли они в условие - это Евгений может сказать.
пожалуй , Вы правы. Я как-то за алгоритмами совершенно забыл о реальной задаче...
Слушал я вас долго и внимательно.... Для программы конечно всё равно. А в жизни как мне кажется ноль соответствует рожковому ключу у которого "рога" только с одной стороны. Есть у меня такие. Вот входят ли они в условие - это Евгений может сказать.
В данном случае 0 это не размер ключа, а цифровая метка для размера ключа.
Немного оптимизировал код для "ветвей и границ", переписал узкие места, добавил больше входных проверок. В итоге время для тестового набора ЕП даже чуть выросло - было 2.8 мс, стало порядка 3.1мс. Зато время для набора kolyn из сообщения #173 уменьшилось почти вдвое - с 7.9мс до 4.1мс.
Код не выкладываю, потому что пока не могу справится с главной проблемой - нехваткой памяти. На невырожденных наборах более чем с 25-30 уникальными ключами глубина рекурсии, необходимой для решения, оказывается 5-6 уровней... память заканчивается и программа крашится...
Думаю, что повысить этот предел в несколько раз у меня точно не выйдет, хорошо если удастся поднять на 30-50%. В связи с этим вопрос к ЕП - по условиям программа должна работать на "любом разумном числе ключей". Разумное в этой фразе - это сколько? :)
на моей памяти максимальный размер рожковых ключей ограничивался 112 номером
на моей памяти максимальный размер рожковых ключей ограничивался 112 номером
вопрос не о максимальном размере ключа, а о максимальном количестве ключей в наборе.
на моей памяти максимальный размер рожковых ключей ограничивался 112 номером
вопрос не о максимальном размере ключа, а о максимальном количестве ключей в наборе.
Гаечные ключи относятся к изделиям, размеры которых строго регламентированы ГОСТ и не могут быть нарушены... от 3.3 мм до 155мм (39 размеров)
Гаечные ключи относятся к изделиям, размеры которых строго регламентированы ГОСТ и не могут быть нарушены... от 3.3 мм до 155мм (39 размеров)
хм... мне третий раз просить тебя вникнуть в то, о чем я пишу? - или нет смысла уже?
хм... мне третий раз просить тебя вникнуть в то, о чем я пишу? - или нет смысла уже?
По ГОСТ 80 года если не ограничиваться рядами и ограничиться размером 80мм - 54 разных ключа (так устроит?)
По ГОСТ 80 года если не ограничиваться рядами и ограничиться размером 80мм - 54 разных ключа (так устроит?)
нет
Гаечные ключи относятся к изделиям, размеры которых строго регламентированы ГОСТ и не могут быть нарушены... от 3.3 мм до 155мм (39 размеров)
Вот на хрена ты влазишь в темы, в которых тебе нечего сказать по делу? Только свою глупость выносишь на люди. Информация по ГОСТ конечно интересная, но если бы ты поработал немножко головой, то вспомнил, что ключи бывают разные. На разных сторонах ключа могут быть разные типоразмеры, например 12-12 12-13 12-14, и тогда во сколько разных ключей превратятся 39 размеров?
Надо было таки определиться! Ну, раз уж не определился. выставляйте что выставите. Здесь ведь интересен подход к решению.
kolyn! На этом наборе не взлетает:
kolyn! На этом наборе не взлетает:
слушай, тебе правда лишь бы что вякнуть? или ты в программировании совсем по нулям, хуже новичка?
Ты вот это
с тем что ты пытаешься задавать
сравнивать не пробовал?
kolyn! На этом наборе не взлетает:
Выше обсуждались цифровые метки, размеры можно немного переделать. Тогда корректный набор будет таким:
Ноль я не использовал, он мне отдельно нужен.
думаю, что переделывать этот набор смысла нет.
Не знаю, что тут будет с памятью, но решение этого набора методом перебора займет годы :)
Напомню, совсем простенький набор kolyn из сообщения #173 потребовал на одной программе перебора порядка 3х минут, а на другой все 12... а сложность перебора с числом вариантов как растет? Факториал?
Предлагаю, кстати, поставить верхнее ограничение времени работы программы... ну точно не более 15 минут.
поправил, код, канпилятор видимо сам в правильный формат данные ключей приводил )))
PS и чё тут еще не так?
Возможно, Вам попалась неудачная литература. На самом деле там все предельно просто и, главное, целиком ложится в обычный здравый смысл.
Просто и известно с детства. Это ситуация с Иваном - дураком, когда он перед камнем стоит. "Налево пойдешь - профит найдешь, направо - коня потеряешь". Только у Ивана надпись на камне уже готова - бери и читай, а для решения этой задачи ее самому придумать и нацарапать необходимо... И в этом основная засада.
Подходите с точки зрения здравого смысла. Любой ключ (кроме очевидных вариантов) - может либо входить в набор, либо нет. Вот вам и две ветви... А границы - это когда вы откидываете заведо проигрышные пути, например те, что дороже текущего минимума.
Уж куда я этот здравый смысл не пытался приложить, так и не сумел сформулировать эти "границы" , другими словами степень полезности (бесполезности) включения конкретного ключа в конечный результат.
Только не подумайте, что клянчу очередную подсказку:). Просто мой уровень - метод полного перебора, до большего не дорос(((
поправил, код, канпилятор видимо сам в правильный формат данные ключей приводил )))
PS и чё тут еще не так?
Экий Вы нетерпеливый. Это же полный перебор, Вам же писали выше - время пропорционально ФАКТОРИАЛУ от кол-ва ключей. Так что одно из двух - либо решит, либо у Вас электричество в розетке кончится:)
Гаечные ключи относятся к изделиям, размеры которых строго регламентированы ГОСТ и не могут быть нарушены... от 3.3 мм до 155мм (39 размеров)
Уточните, какой именно ГОСТ действует на Али.
тогда надо менять алгоритм
тогда надо менять алгоритм
Гэниально!
тогда надо менять алгоритм
Гэниально!
на этом сайте только по пятницам приходят гениальные открытия )))
Надо ждать выступления AndreyD... очень заинтересовало, что там у него за алгоритм...
Уж куда я этот здравый смысл не пытался приложить
Давайте, я попробую объяснить смысл метода.
Для начала напишем простой полный перебор. Выглядит он для N ключей вот так:
После такого вызова наилучшее решение останется theBest. При этом функция честно переберёт все N! вариантов решений.
Прежде, чем переходить к ветвям и границам, убедитесь, что эту программу Вы полностью понимаете, т.к. сейчас мы будем её править.
Давайте включим здравый смысл и скажем себе: если мы уже нашли полное решение, то какой нам смысл пытаться добавлять к нему какие-то ещё ключи? Новых размеров это не даст, они и так все присутствуют, только цену увеличит, так ведь? Давайте не будем проваливаться рекурсию в том случае, если полное решение уже найдено.
Как видите, мы добавили единственное слово else в строке №11 и уже избавились от части рекурсивных вызовов.
Давайте думать дальше. А если мы заранее отсортируем массив ключей в порядке возрастания цены ключа? Тогда ведь мы сможем сделать вот что: как только цена текущего решения (пусть ещё неполного) сравнялась (или превысила) с ценой нашего наилучшего на данный момент решения, дальше можно не смотреть, т.к. цена решения будет только расти с добавлением каждого ключа, а значит, всё, что мы сможем получить на этой ветке заведомо будет хуже того решения, что у нас уже есть! Давайте это напишем:
Давайте порассуждаем, что мы получили. Всякий раз, когда стоимость текущего решения сравняется или превысит стоимость наилучшего на данный момент решения, мы прекращаем перебор на данном уровне (и, уж тем более, не ныряем глубже в рекурсию) т.к. это бесперспективно, а возвращаемся на уровень выше. А вот пока цена меньше текущей наилучшей (условие в строке №11 ложно), мы проверяем, а не получилось ли у нас полное решение (проверка в строке №12). Если получилось, то запоминаем его как наилучшее и выходим на предыдущий уровень рекурсии. А вот если не получилось (условие в строке №12 ложно), то попадаем на строку №22 - т.е. ныряем на следующий уровень рекурсии.
Это и называется метод ветвей и границ. Как только цена превысила установленную границу (текущую наилучшую), мы тут же отрезаем всю дальнейшую ветвь перебора.
Как видите, ничего сложного.
Как видите, ничего сложного.
Кажется не сложным, если дано решение, да еще с подробными комментариями :) У меня даже полный перебор с помощью рекурсии написать не получилось, вернее после 26-и ключей ломалось. Пришлось "сочетание без повторений" сколипастить и встраивать в код.
И если
мы уже нашли полное решение, то какой нам смысл пытаться добавлять к нему какие-то ещё ключи? Новых размеров это не даст, они и так все присутствуют, только цену увеличит, так ведь?
на это еще соображалки хватило и в моем варианте решения применяется, то
как только цена текущего решения (пусть ещё неполного) сравнялась (или превысила) с ценой нашего наилучшего на данный момент решения, дальше можно не смотреть
это уже никак не сложилось в целую картинку. Какие-то обрывки мелькали, когда разбирал задачу о рюкзаке, но то такое. В любом случае мое честное решение в #150
это уже никак не сложилось в целую картинку.
До сих пор не сложилось или теперь уже устаканилось? А то в этом и есть вся фишка метода.
Сейчас, после Ваших пояснений
Как видите, ничего сложного.
Спасибо.
Надо ждать выступления AndreyD... очень заинтересовало, что там у него за алгоритм...
Полный набор:
Незачет. В строке 7 значение 5.5 описано как 5, а в строке 9 как 6
Завидую белой завистью. Вот КАК на это можно было внимание обратить?
КАК на это можно было внимание обратить?
специально искал
Завидую белой завистью. Вот КАК на это можно было внимание обратить?
не парься колян, это он второй раз троллит, описано было ранее с запятой И, зная прекрасно, что при присвоении, когда компилятор будет засовывать в структуру переменную он её усечет до целого в младшую сторону, разразился там выше гневной тирадой )))
PS кстати, компилятор даже не ругнулся на ошибку и прекрасно скетч скомпилировал
PPS время в миллисекундах это для твоего алгоритма
кстати, компилятор даже не ругнулся на ошибку и прекрасно скетч скомпилировал
так ошибки синтаксиса тут и нет, тут ошибка смысла - а такое компилятор не ловит.
Проблема не в том, что 5.5 обрезается до 5, а в том что в наборе уже есть такой размер. В итоге у тебя ключи с размером 5.5 становятся дублями ключей 5.
А все просто - выбери для замены 5.5 какой-то целый размер, незанятый в начальном наборе. Например 56
такой цели не было, показал все стандартизованные ключи, а уж как с долями миллиметров поступать решайте сами, в теме пасусь только из-за того, что интересно посмотреть алгоритм, что ЕП предложит, сам бы решал точно не перебором, а используя "социальную инженерию"
время в миллисекундах это для твоего алгоритма
это которого алгоритма, из 154?
время в миллисекундах это для твоего алгоритма
крайняя правленная версия, что на твоем наборе уже не спотыкалась
такой цели не было, показал все стандартизованные ключи, а уж как с долями миллиметров поступать решайте сами
удивительно, насколько ты не замечаешь элементарной логики... зачем тебе алгоритм....
правленная версия, что на твоем наборе уже не спотыкалась
она в ветке выкладывалась? В каком сообщении?
правленная версия, что на твоем наборе уже не спотыкалась
пролистал, не нашёл, колян подскажет
думаю что цифры времени ты выдумал, по крайней мере две последние. Перебором там должно быть на несколько порядков больше. Ну или это не тот алгоритм
Если речь о моем варианте - то #150 последнее, что выкладывал
Проверил, цифры до миллисекунд не сходятся, но порядок верный. Время расчёта: 129867 миллисекунд против
{17, 22, 18},
// за 102724 миллисекунд
Дело в том,что у меня не совсем "честный" перебор. Он начинается с н-ключей, которые определяются по кол-ву размеров и заканчивается, если при добавлении очередного ключа не меняется мин. сумма.
Kolyn, Вам - верю. Тогда по числу ключей вы меня явно обходите. Мой алгоритм до 30 строчки не доберется.
Это лишь потому, что что я рекурсию ниасилил;)
такой цели не было, показал все стандартизованные ключи, а уж как с долями миллиметров поступать решайте сами, в теме пасусь только из-за того, что интересно посмотреть алгоритм, что ЕП предложит, сам бы решал точно не перебором, а используя "социальную инженерию"
(выделено мною)
Интересно, а какая цель была?
Дело в том, что эта "неопределенность с долями" сокращает количество типоразмеров и искажает исходную задачу до полной неузнаваемости. В частности, для такой (искаженной) задачи решение будет совершенно другим.
Так какова же была цель такого искажения?
да уж...полёт фантазии с утра...цифры реальные с монитора порта...почему у коляна несколько не те - не знаю...ядро минисоре оптимизация включена