у ключа есть ещё и тело, к примеру с одной стороны на 112 а с другой 7 )))
Ну я же перебираю комбинацию ключей, а не размеров.
как раз тот случай, когда программист не понимает прикладной задачи, тело ключа и грани рассчитываются на максимальное усилие, разброс размеров в паре имеет свои пределы...я конечно видел и рожковые ключи с отломанными рожками и тех клоунов, что это сделали, но это же исключительный случай - механик не умеющий обращаться с гаечным ключом это клиника
Ну я всё-таки за идею перебора сочетаний ключей без повторений с последующей проверкой на наличие всех размеров и сравнению стоимости полученных наборов.
Первый фундаментальный вопрос как обозначать наборы и желательно в цифрах, так как все же МК считает в цифрах. Допустим в условии даны 3 гаечных ключа. Сколько наборов из их можно собрать. Правильно 8 наборов. От набора когда ключей нет 000 , до того когда состоят из трех ключей 111. Думаю вам будет понятно. что позиция это номер ключа в задании а 1-испльзуется/0 -нет. Дальше создается тип данных набор, стоимость набора, на сколько гаек он применим. И две функции определение стоимости по набору и определение количества гаек по набору. Ну а дальше уже проявляйте навыки эффективного программирования.
ПС: Так как в условии дано 17 ключей, то на описания набора хватит 3-х байтов. всего вариантов набора будет 2^17=131072 включая когда все ключи в наборе отсутсвуют. Так что достаточно их перебрать сохранив тот вариант когда при большем количестве гаек будет меньшая цена.
Я думал это риторический вопрос. Порядок вывода в условии задачи не определён, так что делайте какой хотите. Выкладывайте, а я проверю на нескольких различных исходных наборах. Буду благодарен. если прокомментируете структуры исходных данных, чтобы мне меньше в ней разбираться.
kolyn - исходный набор ключей, если я понял - дан в условии Конкурса.
Нет, там, наоборот, сказано:
ЕвгенийП пишет:
Разумеется, программа не должна зависеть ни от количества ключей (в разумных пределах), ни от цен на них - она должна работать для любого набора. В случае, если размеры ни разу не повторяются, она должна выдать изначальный набор. В случае, если набор состоит из одинаковых ключей, она должна выдать поднабор из одного ключа (самого дешёвого). Ну, и так далее.
kolyn - исходный набор ключей, если я понял - дан в условии Конкурса.
Откуда вы другие наборы взяли? Если придумали сами - зачем их публиковать в этой ветке?
Если бы Вы конкретнее изложили свою просьбу, а именно показать результат выполнения программы с набором ключей, заданных в условиях конкурса, я бы так и сделал;)
Разумеется, программа не должна зависеть ни от количества ключей (в разумных пределах), ни от цен на них - она должна работать для любого набора. В случае, если размеры ни разу не повторяются, она должна выдать изначальный набор. В случае, если набор состоит из одинаковых ключей, она должна выдать поднабор из одного ключа (самого дешёвого). Ну, и так далее.
прошу прощения, значит недочитал :)
Тем не менее, для упрощения сравнения эффективности решений участников, лучше указывать время разбора одного единственного набора - приведенного в условиях
Тем не менее, для упрощения сравнения эффективности решений участников, лучше указывать время разбора одного единственного набора - приведенного в условиях
Не согласен.
По сути, интересной является исключительно асимптотическая сложность, а для нее исходный набор слишком мелок.
Есть и другое соображение - возможность "заточки" программы на конкретный набор, т.е. если программа "узнает" предпочтительный набор, он выдает заранее подготовленный вариант мгновенно, а на всех остальных наборах дает правильное, но неоптимальное (очень долгое) решение. По Вашему предложению именно такая программа должна стать победителем.
По моему мнению, программа, подводящая итоги, должна либо пытаться восстановить асимптотическую сложность на основе нескольких примеров, либо брать результаты самого "тяжелого" варианта (естественно того, который заранее не известен участникам).
Есть и другое соображение - возможность "заточки" программы на конкретный набор, т.е. если программа "узнает" предпочтительный набор, он выдает заранее подготовленный вариант мгновенно, а на всех остальных наборах дает правильное, но неоптимальное (очень долгое) решение. По Вашему предложению именно такая программа должна стать победителем.
то что вы описываете - это читерство :) и оно легко видно в исходном коде.
но такое поведение может обьясняться не только "заточкой" программы под конкретные данные. Очевидно, что практически любой набор может быть предварительно упрощен путем отбрасывания очевидных вариантов. Некоторые наборы, например, по мере последовательного упрощения могут решены и чисто аналитически, вообще без перебора. Тогда та программа, алгоритм которой в состоянии разпознать эти закономерности - найдет решение на порядок быстрее, чем та что всегда работает перебором.
Чем больше подобных правил реализовано в программе, тем меньше остается вариантов для перебора и быстрее работает алгоритм в целом. При этом вполне может сложится ситуация, что на одних наборах программа обгоняет всех, а на других отстает... и при этом никакого "читерства" нет.
Это я к тому. что оценивать результаты "вообще" довольно сложно - одна программа на половине наборов выдает ответ мгновенно. а на другой ползет черепашьим шагом, другая работает "очень средне" на всех... и какую признать победителем?
ИМХО, без какого-то тестового набора или нескольких наборов нет четкого критерия первенства.
Некоторые наборы, например, по мере последовательного упрощения могут решены и чисто аналитически, вообще без перебора. Тогда та программа, алгоритм которой в состоянии разпознать эти закономерности - найдет решение на порядок быстрее, чем та что всегда работает перебором.
Согласаен.
Цитата:
ИМХО, без какого-то тестового набора или нескольких наборов нет четкого критерия первенства.
Естественно. Но для чистоты эксперимента эти тестовые наборы не должны быть заранее известны разработчикам.
Вот так и знал, что к слову "размерность" будут придирки.
Если штуку предполагать величиной безразмерной, значит, неверный безразмерный множитель.
Я не могу понять, в чем Вы видите ошибку!
Например в тесте 1 находим А ключей за время Т. Тогда на нахождение одного ключа Тср = Т / А (мс). Проводим n РАЗЛИЧНЫХ тестов. Находим среднее (арифметическое напр.) : (Тср1 + Тср2 + ...+Тсрn)/n. Что не так?
ПС. Возможно в качестве "А" должно быть не кол-во найденных, а исходных ключей.
и не зря боялись, пришло другое поколение, сверх рационалистическое
" Они торчат под рейв и чем-то пудрят носы
они не такие, как мы."
Бросьте. Это просто старческое брюзжание. Такие же, а может и лучше. Вспомните себя годков эдак в 25. Что бы вы предпочли - решать некую задачу, которая возможно и пощекочет ваш центр удовольствий в будущем или пойти с друзьями потусить прямо сейчас? Если первое - то у вас просто нет друзей. А те, кто ардуинит лет с 10 и не бросил это занятие, в 25 уж никак не "новичок".
В конкурсе примут участие только те, для кого программирование - хобби, кому не жалко на на это времени, у кого "базовые потребности" уже удовлетворены. Ради кайфа в тот момент, когда оно "заработало!!!".
те, кто ардуинит лет с 10 и не бросил это занятие, в 25 уж никак не "новичок".
кстати да, стоило бы четче сформулировать. для кого этот конкурс. Потому как задачка, прямо скажем, далеко не для начального уровня. Те "новечки", что приходят сюда спрашивать, "как включить светодиод одним нажатием" - не смогут даже сформулировать подходы к решению, не говоря уж о написании работающего кода.
Поэтому актуален вопрос - кто они, участники этого конкурса? :)
Бросьте. Это просто старческое брюзжание. Такие же, а может и лучше. Вспомните себя годков эдак в 25. Что бы вы предпочли - решать некую задачу, которая возможно и пощекочет ваш центр удовольствий в будущем или пойти с друзьями потусить прямо сейчас? Если первое - то у вас просто нет друзей. А те, кто ардуинит лет с 10 и не бросил это занятие, в 25 уж никак не "новичок".
первое!
что значит друг? для меня это те, кому могу позвонить в любое время дня и ночи, сказать ты мне нужен и через 15 минут он будет у меня, и обратное естественно, таких немного...
PS ты попутал с приятелями, в русском это жеж просто - ПРИ Я Тело, разницу чувствуешь )))
что значит друг? для меня это те, кому могу позвонить в любое время дня и ночи, сказать ты мне нужен и через 15 минут он будет у меня, и обратное естественно, таких немного...
Вы к этому осознанию прям со школьной скамьи пришли? Ну значит Вы мудрый человек! До меня это стало доходить после 30. Да и сейчас часто ошибаюсь в людях. Но эт уже офтоп.
Поэтому актуален вопрос - кто они, участники этого конкурса? :)
Профессионально программированием не занимался, только базовые курсы в школе (+факультатив) и в институте.
С ардуиной я начал знакомиться лет пять назад, всё началось с того, что я сделал гирлянду на новый год на конденсаторах и стартерах, но стартеры долго не прожили. Поэтому поставил под гирлянду нанку. Затем увлёкся идеей "Умного дома", у меня частный дом. Сейчас у меня действующая система из 3-х нанок, одной Меги и одного одноплатника с установленным на последнем MajorDoMo. В основном управление освещением, так же есть пара сигнализаций, пара гирлянд, цветной прожектор, датчики движения, температуры, влажности, давления, освещённости.
Поэтому программирование меня интересует как инструмент для этого моего увлечения.
Например в тесте 1 находим А ключей за время Т. Тогда на нахождение одного ключа Тср = Т / А (мс). Проводим n РАЗЛИЧНЫХ тестов. Находим среднее (арифметическое напр.) : (Тср1 + Тср2 + ...+Тсрn)/n. Что не так?
Почему Вы решили, что между количеством ключей и временем зависимость линейна?
Видимо, Вы считаете, что в строке №1 выделили память и в строке №3 спокойно в неё пишете. Боюсь Вас разочаровать. Напечатайте в сериал sizeof Вашего tmp и посмотрите, сколько там выделилось.
Вы пишете в произвольную память. Если она не под что не распределена, Вам повезло - будет работать, а если она подо что-то выделена, Вы это что-то испортите. Полюбуйтесь, что бывает, когда так пишешь.
Если уж Вам там нужен массив, так пишите его размер явно или нормальный инициализатор.
Почему Вы решили, что между количеством ключей и временем зависимость линейна?
В этом Вы явно ошибаетесь.
andriano, разве я упоминал о зависимости времени расчета от количества ключей? Я просто предложил вариант оценки скорости работы программы. И не утверждал, что он единственно верный. Мне кажется такой формулы не существует в принципе.
Я в свою очередь думаю, что у Вас претензии к (Тср1 + Тср2 + ...+Тсрn)/n просто к как к абстракной формуле. Вот и беседуем - Вы о круглом, я о красном;)
andriano, разве я упоминал о зависимости времени расчета от количества ключей?
Именно. Это утверждение непосредственно следует из предложенной Вами формулы.
Цитата:
Я просто предложил вариант оценки скорости работы программы. И не утверждал, что он единственно верный. Мне кажется такой формулы не существует в принципе.
А она есть!
Цитата:
Я в свою очередь думаю, что у Вас претензии к (Тср1 + Тср2 + ...+Тсрn)/n просто к как к абстракной формуле. Вот и беседуем - Вы о круглом, я о красном;)
Видите ли, математика - это не просто набор значков. Каждая строка имеет свой смысл. Вот смысл в приведенной выше формуле есть только в том случае, если зависимость времени и количества линейна. В противном случае эту формулу применять нельзя.
PS. Если Вы вправду считаете, что все формулы равнозначны, будете ли Вы считать закон Ома по формуле U=I/R ? Чем она хуже U=I*R ?
Не бывает "абстрактных формул". Каждая из них имеет (либо не имеет) какой-то смысл.
у ключа есть ещё и тело, к примеру с одной стороны на 112 а с другой 7 )))
Ну я же перебираю комбинацию ключей, а не размеров.
Если порядок вывода будет нарушен по сравнению с исходным массивом, надеюсь, это не будет ошибкой? Например так:
у ключа есть ещё и тело, к примеру с одной стороны на 112 а с другой 7 )))
Ну я же перебираю комбинацию ключей, а не размеров.
как раз тот случай, когда программист не понимает прикладной задачи, тело ключа и грани рассчитываются на максимальное усилие, разброс размеров в паре имеет свои пределы...я конечно видел и рожковые ключи с отломанными рожками и тех клоунов, что это сделали, но это же исключительный случай - механик не умеющий обращаться с гаечным ключом это клиника
Та ладно, клиника это когда механик не умеет закручивать/откручивать гайки; электронщик паять; а программист программировать, врач лечить и так далее.
Ну я всё-таки за идею перебора сочетаний ключей без повторений с последующей проверкой на наличие всех размеров и сравнению стоимости полученных наборов.
От перебора так или иначе никуда не деться. Самый интересный вопрос - отсечение бесперспективных вариантов. Т.е. сокращение объема перебора.
Самый интересный вопрос - отсечение бесперспективных вариантов. Т.е. сокращение объема перебора.
Дополню для желающих погуглить такие приёмы: это называется "метод ветвей и границ".
Первый фундаментальный вопрос как обозначать наборы и желательно в цифрах, так как все же МК считает в цифрах. Допустим в условии даны 3 гаечных ключа. Сколько наборов из их можно собрать. Правильно 8 наборов. От набора когда ключей нет 000 , до того когда состоят из трех ключей 111. Думаю вам будет понятно. что позиция это номер ключа в задании а 1-испльзуется/0 -нет. Дальше создается тип данных набор, стоимость набора, на сколько гаек он применим. И две функции определение стоимости по набору и определение количества гаек по набору. Ну а дальше уже проявляйте навыки эффективного программирования.
ПС: Так как в условии дано 17 ключей, то на описания набора хватит 3-х байтов. всего вариантов набора будет 2^17=131072 включая когда все ключи в наборе отсутсвуют. Так что достаточно их перебрать сохранив тот вариант когда при большем количестве гаек будет меньшая цена.
Методом полного перебора.
Буду думать как ускорить.
Буду думать как ускорить.
Начните с #57
Если порядок вывода будет нарушен по сравнению с исходным массивом, надеюсь, это не будет ошибкой? Например так:
Евгений Петрович, повторю вопрос. Если порядок вывода не принципиален, готов выложить свою версию.
Я думал это риторический вопрос. Порядок вывода в условии задачи не определён, так что делайте какой хотите. Выкладывайте, а я проверю на нескольких различных исходных наборах. Буду благодарен. если прокомментируете структуры исходных данных, чтобы мне меньше в ней разбираться.
Стиль "Ма-ма мы-ла ра- му". Ну как умею.
P.S. Код изменил. 1-й раз залил неверную версию.
Стиль "Ма-ма мы-ла ра- му". Ну как умею.
P.S. Код изменил. 1-й раз залил неверную версию.
Набор и время еще укажите
Исходный набор:
Тот же набор, но ключ 13*15 можно заменить двумя дешевыми 13*12 и 15*17:
И еще один странный набор ключей с уникальными размерами и более дорогими дубликатами:
kolyn - исходный набор ключей, если я понял - дан в условии Конкурса.
Откуда вы другие наборы взяли? Если придумали сами - зачем их публиковать в этой ветке?
kolyn - исходный набор ключей, если я понял - дан в условии Конкурса.
Нет, там, наоборот, сказано:
kolyn - исходный набор ключей, если я понял - дан в условии Конкурса.
Откуда вы другие наборы взяли? Если придумали сами - зачем их публиковать в этой ветке?
Если бы Вы конкретнее изложили свою просьбу, а именно показать результат выполнения программы с набором ключей, заданных в условиях конкурса, я бы так и сделал;)
Нет, там, наоборот, сказано:
прошу прощения, значит недочитал :)
Тем не менее, для упрощения сравнения эффективности решений участников, лучше указывать время разбора одного единственного набора - приведенного в условиях
прошу прощения, значит недочитал :)
ошибаетесь.
С вашей внимательностью вам трудно в программировании придется :)
ошибаетесь.
С вашей внимательностью вам трудно в программировании придется :)
Упс, крыть нечем :)
Стиль "Ма-ма мы-ла ра- му". Ну как умею.
Евгений Петрович, хотелось бы Вашей реакции. Зачтено? Нет?
Я пока ещё тесты не запускал, в выходные кода ещё не было, а сейчас тяжко, но я постараюсь, и как только, так сразу.
Тем не менее, для упрощения сравнения эффективности решений участников, лучше указывать время разбора одного единственного набора - приведенного в условиях
По сути, интересной является исключительно асимптотическая сложность, а для нее исходный набор слишком мелок.
Есть и другое соображение - возможность "заточки" программы на конкретный набор, т.е. если программа "узнает" предпочтительный набор, он выдает заранее подготовленный вариант мгновенно, а на всех остальных наборах дает правильное, но неоптимальное (очень долгое) решение. По Вашему предложению именно такая программа должна стать победителем.
По моему мнению, программа, подводящая итоги, должна либо пытаться восстановить асимптотическую сложность на основе нескольких примеров, либо брать результаты самого "тяжелого" варианта (естественно того, который заранее не известен участникам).
Есть и другое соображение - возможность "заточки" программы на конкретный набор, т.е. если программа "узнает" предпочтительный набор, он выдает заранее подготовленный вариант мгновенно, а на всех остальных наборах дает правильное, но неоптимальное (очень долгое) решение. По Вашему предложению именно такая программа должна стать победителем.
то что вы описываете - это читерство :) и оно легко видно в исходном коде.
но такое поведение может обьясняться не только "заточкой" программы под конкретные данные. Очевидно, что практически любой набор может быть предварительно упрощен путем отбрасывания очевидных вариантов. Некоторые наборы, например, по мере последовательного упрощения могут решены и чисто аналитически, вообще без перебора. Тогда та программа, алгоритм которой в состоянии разпознать эти закономерности - найдет решение на порядок быстрее, чем та что всегда работает перебором.
Чем больше подобных правил реализовано в программе, тем меньше остается вариантов для перебора и быстрее работает алгоритм в целом. При этом вполне может сложится ситуация, что на одних наборах программа обгоняет всех, а на других отстает... и при этом никакого "читерства" нет.
Это я к тому. что оценивать результаты "вообще" довольно сложно - одна программа на половине наборов выдает ответ мгновенно. а на другой ползет черепашьим шагом, другая работает "очень средне" на всех... и какую признать победителем?
ИМХО, без какого-то тестового набора или нескольких наборов нет четкого критерия первенства.
ИМХО, без какого-то тестового набора или нескольких наборов нет четкого критерия первенства.
Например, среднее от Время/Ключ для N различных тестовых наборов.
Но это решать не мне;)
Некоторые наборы, например, по мере последовательного упрощения могут решены и чисто аналитически, вообще без перебора. Тогда та программа, алгоритм которой в состоянии разпознать эти закономерности - найдет решение на порядок быстрее, чем та что всегда работает перебором.
Согласаен.
ИМХО, без какого-то тестового набора или нескольких наборов нет четкого критерия первенства.
Естественно. Но для чистоты эксперимента эти тестовые наборы не должны быть заранее известны разработчикам.
Например, среднее от Время/Ключ для N различных тестовых наборов.
В математике есть три разных вида среднего. Не говоря даже о медиане, которая также претендует на это звание.
И, если Время/Ключ - это формула, то вряд ли она имеет верную размерность. Объем перебора - отнюдь не линейная функция от числа ключей.
В математике есть три разных вида среднего.
А Вам какое больше нравится?;)
И, если Время/Ключ - это формула, то вряд ли она имеет верную размерность.
Да. Это формула. И она имеет правильную размерность. мс / шт = мс.
Главное не победа, а участие. :)
В своих ранее сделанных поделках я структуры и указатели не использовал. Плохо в них разбираюсь.
И максимальное "разумное" количество ключей для этого кода равно 64.
Результат для набора из задания:
Код:
Класс! Мужики, я так боялся, что не будет желающих!
Да. Это формула. И она имеет правильную размерность. мс / шт = мс.
Вот так и знал, что к слову "размерность" будут придирки.
Если штуку предполагать величиной безразмерной, значит, неверный безразмерный множитель.
Вот так и знал, что к слову "размерность" будут придирки.
Если штуку предполагать величиной безразмерной, значит, неверный безразмерный множитель.
Я не могу понять, в чем Вы видите ошибку!
Например в тесте 1 находим А ключей за время Т. Тогда на нахождение одного ключа Тср = Т / А (мс). Проводим n РАЗЛИЧНЫХ тестов. Находим среднее (арифметическое напр.) : (Тср1 + Тср2 + ...+Тсрn)/n. Что не так?
ПС. Возможно в качестве "А" должно быть не кол-во найденных, а исходных ключей.
Класс! Мужики, я так боялся, что не будет желающих!
и не зря боялись, пришло другое поколение, сверх рационалистическое
и не зря боялись, пришло другое поколение, сверх рационалистическое
" Они торчат под рейв и чем-то пудрят носы
они не такие, как мы."
Бросьте. Это просто старческое брюзжание. Такие же, а может и лучше. Вспомните себя годков эдак в 25. Что бы вы предпочли - решать некую задачу, которая возможно и пощекочет ваш центр удовольствий в будущем или пойти с друзьями потусить прямо сейчас? Если первое - то у вас просто нет друзей. А те, кто ардуинит лет с 10 и не бросил это занятие, в 25 уж никак не "новичок".
В конкурсе примут участие только те, для кого программирование - хобби, кому не жалко на на это времени, у кого "базовые потребности" уже удовлетворены. Ради кайфа в тот момент, когда оно "заработало!!!".
те, кто ардуинит лет с 10 и не бросил это занятие, в 25 уж никак не "новичок".
кстати да, стоило бы четче сформулировать. для кого этот конкурс. Потому как задачка, прямо скажем, далеко не для начального уровня. Те "новечки", что приходят сюда спрашивать, "как включить светодиод одним нажатием" - не смогут даже сформулировать подходы к решению, не говоря уж о написании работающего кода.
Поэтому актуален вопрос - кто они, участники этого конкурса? :)
Поэтому актуален вопрос - кто они, участники этого конкурса? :)
Резюме)))
Бросьте. Это просто старческое брюзжание. Такие же, а может и лучше. Вспомните себя годков эдак в 25. Что бы вы предпочли - решать некую задачу, которая возможно и пощекочет ваш центр удовольствий в будущем или пойти с друзьями потусить прямо сейчас? Если первое - то у вас просто нет друзей. А те, кто ардуинит лет с 10 и не бросил это занятие, в 25 уж никак не "новичок".
первое!
что значит друг? для меня это те, кому могу позвонить в любое время дня и ночи, сказать ты мне нужен и через 15 минут он будет у меня, и обратное естественно, таких немного...
PS ты попутал с приятелями, в русском это жеж просто - ПРИ Я Тело, разницу чувствуешь )))
что значит друг? для меня это те, кому могу позвонить в любое время дня и ночи, сказать ты мне нужен и через 15 минут он будет у меня, и обратное естественно, таких немного...
Вы к этому осознанию прям со школьной скамьи пришли? Ну значит Вы мудрый человек! До меня это стало доходить после 30. Да и сейчас часто ошибаюсь в людях. Но эт уже офтоп.
Ребята, не засоряйте тему
Поэтому актуален вопрос - кто они, участники этого конкурса? :)
Профессионально программированием не занимался, только базовые курсы в школе (+факультатив) и в институте.
С ардуиной я начал знакомиться лет пять назад, всё началось с того, что я сделал гирлянду на новый год на конденсаторах и стартерах, но стартеры долго не прожили. Поэтому поставил под гирлянду нанку. Затем увлёкся идеей "Умного дома", у меня частный дом. Сейчас у меня действующая система из 3-х нанок, одной Меги и одного одноплатника с установленным на последнем MajorDoMo. В основном управление освещением, так же есть пара сигнализаций, пара гирлянд, цветной прожектор, датчики движения, температуры, влажности, давления, освещённости.
Поэтому программирование меня интересует как инструмент для этого моего увлечения.
Ну и да, мне ближе к сорока годикам. :)
kolyn,
попробуйте с вот таким набором данных
У меня получилось
Здесь явно не хватает размеров 2 и 4.
AndreyD,
попробуйте с вот таким набором данных
У меня получилось бесконечное исполнение. Может, и конечное, но больше 15 минут я уж не стал ждать.
kolyn,
попробуйте с вот таким набором данных
У меня получилось
Здесь явно не хватает размеров 2 и 4.
Упс. Ошибка в логике программы. Она основана на сортировке от дешевых к дорогим,а равенство цен я не учел(
Стоит исправлять или уже все?
Конечно, стоит.
Про другие ошибки рассказать? Ну, про то, что глаза сразу бросилось?
Я не могу понять, в чем Вы видите ошибку!
Например в тесте 1 находим А ключей за время Т. Тогда на нахождение одного ключа Тср = Т / А (мс). Проводим n РАЗЛИЧНЫХ тестов. Находим среднее (арифметическое напр.) : (Тср1 + Тср2 + ...+Тсрn)/n. Что не так?
В этом Вы явно ошибаетесь.
Конечно, стоит.
Про другие ошибки рассказать? Ну, про то, что глаза сразу бросилось?
Конечно!
Вы регулярно используете конструкцию
Видимо, Вы считаете, что в строке №1 выделили память и в строке №3 спокойно в неё пишете. Боюсь Вас разочаровать. Напечатайте в сериал sizeof Вашего tmp и посмотрите, сколько там выделилось.
Вы пишете в произвольную память. Если она не под что не распределена, Вам повезло - будет работать, а если она подо что-то выделена, Вы это что-то испортите. Полюбуйтесь, что бывает, когда так пишешь.
Если уж Вам там нужен массив, так пишите его размер явно или нормальный инициализатор.
Почему Вы решили, что между количеством ключей и временем зависимость линейна?
В этом Вы явно ошибаетесь.
Я в свою очередь думаю, что у Вас претензии к (Тср1 + Тср2 + ...+Тсрn)/n просто к как к абстракной формуле. Вот и беседуем - Вы о круглом, я о красном;)
andriano, разве я упоминал о зависимости времени расчета от количества ключей?
Именно. Это утверждение непосредственно следует из предложенной Вами формулы.
Я просто предложил вариант оценки скорости работы программы. И не утверждал, что он единственно верный. Мне кажется такой формулы не существует в принципе.
А она есть!
Я в свою очередь думаю, что у Вас претензии к (Тср1 + Тср2 + ...+Тсрn)/n просто к как к абстракной формуле. Вот и беседуем - Вы о круглом, я о красном;)
Видите ли, математика - это не просто набор значков. Каждая строка имеет свой смысл. Вот смысл в приведенной выше формуле есть только в том случае, если зависимость времени и количества линейна. В противном случае эту формулу применять нельзя.
PS. Если Вы вправду считаете, что все формулы равнозначны, будете ли Вы считать закон Ома по формуле U=I/R ? Чем она хуже U=I*R ?
Не бывает "абстрактных формул". Каждая из них имеет (либо не имеет) какой-то смысл.
Можно еще попробовать на таком простеньком наборе:
сорри, глюк