|
|
|
Задача на собеседование
|
|||
|---|---|---|---|
|
#18+
авторДанные представлены в табличке с двумя колонками, где в первой - простая нумерация заправок от 1 до N, а во второй - расстояние до заправки (считать, что для первой заправки расстояние считается от начала отправления пользователя, например - из дома) Выбирать точку отсчета начала маршрута непонятно где для решения задачи неудобно и ни на что не влияет, поэтому на первом шаге имеет смысл сделать первую заправку точкой отсчета, соответственно точка отправления пользователя уйдет в минус на координатной оси, куда ей и дорога. Второй момент, если есть или получаются одинаковые расстояния между заправками, куда помещать новую заправку? Этот момент необходимо конкретизировать для получения детерменированного решения задачи. Добавляем условие, если есть несколько отрезков (расстояний между соседними заправками) одинаковой величины, то новая заправка помещается на максимально удаленном от первой заправки отрезке. Сделаем тестовый пример: Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. Результат добавления L новых заправок представить в виде таблицы, содержащей столбцы - номер заправки, расстояние до первой заправки, расстояние до предыдущей заправки, номера заправок должны быть последовательные и следовать в порядке увеличения расстояния от первой заправки. В таком виде задача приобретает более осмысленный вид и пригодна для решения, дерзайте)) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.10.2018, 22:47 |
|
||
|
Задача на собеседование
|
|||
|---|---|---|---|
|
#18+
SkilledJuniorВ таком виде задача приобретает более осмысленный вид и пригодна для решения, дерзайте))Нужно быть очень неордиарной личонстью, чтоб после уточненных условий и предоставленных решений написать этот поток сознания да еще с таким апломбом. Есть вполне конкретные входные данные и четкий критерий минимизации. Если что-то непонятно - лучше просто уточнить. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.10.2018, 22:58 |
|
||
|
Задача на собеседование
|
|||
|---|---|---|---|
|
#18+
ValergradО чем вы, ребята? О каких уникумах? Задачка очень простая же. Речь не о сложности самого алгоритма, а о способности человека записать программный код "на бумажке". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.10.2018, 02:10 |
|
||
|
Задача на собеседование
|
|||
|---|---|---|---|
|
#18+
982183Речь не о сложности самого алгоритма, а о способности человека записать программный код "на бумажке". Может быть речь шла как раз о путях решения, сомнительно чтобы на собеседовании требовалось решить итерационную задачку на SQL, на процедурном языке нужны всего навсего массив и три цикла. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.10.2018, 12:29 |
|
||
|
Задача на собеседование
|
|||
|---|---|---|---|
|
#18+
982183о способности человека записать программный код "на бумажке".Когда-то проще было написать на бумажке, чем сразу нащелкивать тумблерами адрес и значение, а потом гадать, что получилось. Правда язык машинных кодов, в отличие от всяких наворотов над ним, прост для понимания. Даже тупые машины могут его исполнять без дополнительных манипуляций. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.10.2018, 12:38 |
|
||
|
Задача на собеседование
|
|||
|---|---|---|---|
|
#18+
Одно дело описать алгоритм на бумажке, другое дело код, зачем подобную кракозябру писать на бумажке? Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.10.2018, 14:38 |
|
||
|
Задача на собеседование
|
|||
|---|---|---|---|
|
#18+
Третий цикл даже лишний и сортировка исходных данных по расстоянию не нужна, сбили любители select-ов с их "бесплатной" сортировкой. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.10.2018, 14:50 |
|
||
|
Задача на собеседование
|
|||
|---|---|---|---|
|
#18+
Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.10.2018, 15:06 |
|
||
|
Задача на собеседование
|
|||
|---|---|---|---|
|
#18+
SkilledJunior, Код: plsql 1. 2. 3. 4. 5. 6. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.10.2018, 15:20 |
|
||
|
Задача на собеседование
|
|||
|---|---|---|---|
|
#18+
123йй, 18с)) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.10.2018, 15:28 |
|
||
|
Задача на собеседование
|
|||
|---|---|---|---|
|
#18+
SkilledJuniorВторой момент, если есть или получаются одинаковые расстояния между заправками, куда помещать новую заправку? Этот момент необходимо конкретизировать для получения детерменированного решения задачи. Добавляем условие, если есть несколько отрезков (расстояний между соседними заправками) одинаковой величины, то новая заправка помещается на максимально удаленном от первой заправки отрезке. Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.10.2018, 00:28 |
|
||
|
Задача на собеседование
|
|||
|---|---|---|---|
|
#18+
Спасибо всем за обсуждение данной задачи. Подкину ещё один способ решения: довольно таки затратный, неоптимизированный и т.д., но делает то, что нужно. Такое на бумажке не напишешь, конечно же, поэтому решение от Valergrad считаю оптимальным, при тех условиях, что я писал в начале темы. Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.10.2018, 16:30 |
|
||
|
Задача на собеседование
|
|||
|---|---|---|---|
|
#18+
KDA_666делает то, что нужноОно даже приблизительно не делает то, что нужно. Попытка использовать powermultiset_by_cardinality для генерации возможных распределений изначально неудачна, т.к. число добавленных заправок не обязано быть уникальным по участкам. Если делать полный перебор есть намного более вменяемые способы в SQL. Чтоб убедиться в нерабочести достаточно заменить 60 на 600, тогда все добавленные должны пойти на последний участок а на остальных участках будет по нулям. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.10.2018, 18:19 |
|
||
|
Задача на собеседование
|
|||
|---|---|---|---|
|
#18+
Кто способен изобразить на листочке? Код: plsql 1. 2. 3. 4. 5. 6. Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. Код: plsql 1. 2. 3. 4. 5. 6. Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. Еще остался простор для оптимизации поиска максимального расстояния между заправками ... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.10.2018, 14:40 |
|
||
|
Задача на собеседование
|
|||
|---|---|---|---|
|
#18+
SkilledJuniorКто способен изобразить на листочке? А что здесь сложного? Кроме излишней многословности не вижу ничего такого - но я не вчитывался. Можно узнать, чем этот фрагмент лучше лаконичного sql? Может быть он быстрее? И еще у меня в памяти запомнилось, что вы говорили в исходном комменте о том, что задачу нельзя решать c помощью pl/sql, среди других ограничений. Именно такое было условие на собеседовании, если я вас правильно понял. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.10.2018, 21:36 |
|
||
|
Задача на собеседование
|
|||
|---|---|---|---|
|
#18+
ValergradА что здесь сложного? Абсолютно ничего, если не рисовать это на листочке. Valergradчем этот фрагмент лучше лаконичного sql? Может быть он быстрее? Итерационная задача оптимальным образом может быть решена с помощью соответствующих инструментов и SQL это не совсем подходящий инструмент, хотя если просто побаловаться или получить быстро и разово результат на небольшой выборке, то и SQL сойдет. По скорости нужно сравнивать, как правило процедурное решение работает на порядок, а то и на два быстрее. ValergradИ еще у меня в памяти запомнилось, что вы говорили в исходном комменте о том, что задачу нельзя решать c помощью pl/sql, среди других ограничений. Именно такое было условие на собеседовании, если я вас правильно понял. Подвела тебя память, я не автор темы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.10.2018, 22:49 |
|
||
|
Задача на собеседование
|
|||
|---|---|---|---|
|
#18+
SkilledJuniorValergradА что здесь сложного? По скорости нужно сравнивать, как правило процедурное решение работает на порядок, а то и на два быстрее. Здесь не соглашусь. Дело не в процедурности-непроцедурности, а в алгоритме. Как я и написал, у моего запроса сложность - o(N*K*log(n*k)). У вашего, соответственно - o(N*K) ( в худшем случае, в среднем зависит от распределения данных). На малых значениях еще важна константа, которая для sql-решения будет, конечно, меньше за счет нативности операций и отсутсвия переключений контекста. Поэтому сравнение запроса и кода на случайных данных показывает что 1) пока N и K до 1000 - запрос работает быстрее. 2) Далее, запрос начинает отставать , но зато его легко убыстрить, добавив просто хинт /*+ PARALLEL(n) */ - что дает запросу возможность работать быстрее еще до 5-10 тысяч N и K. В процедуру вы параллелизацию так просто не прикрутите - придется ее перерабатывать. 3) И только после 10 тысяч процедура начинает работать быстрее - за счет лучшей сложности алгоритма. Впрочем, эта сложность не наилучшая. Скажем, есть несложное решение ( использующее как раз структуры данных ) у которого сложность алгоритма будет o( log(n) * k). Сможете найти? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.10.2018, 02:55 |
|
||
|
Задача на собеседование
|
|||
|---|---|---|---|
|
#18+
SkilledJunior, Если представить, что задача была дана до интервью как тестовая, то возникает вопрос: что для кандидата хуже : не прислать ничего или прислать твой бред. К сожалению, прислать бред все же хуже, т.к. ничего не прислав можно будет попробовать на открывшуюся позицию через некоторый срок. А если кандидат прислал такое, то его вряд ли рассмотрят и через год и через два. Потому что ясность мышления приобретается заметно сложнее чем знания по продукту. Если у кандидата каша в голове то какая разница, пусть он знает хоть все доки наизусть. Теперь посмотрим, так ли монструозно выглядит остальное. Пусть было n заправок, надо добавить k. Вычислительная сложность первой модели O(k*n*n): k итераций, на каждой проходим n строк, для каждой строки считаем агрегат(ы). Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. Вычислительная сложность варианта Valergrad O((n*k)log(n*k)): По сути требуется сортировка набора размером n*k. Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. Если больше подумать над моделью то можно додуматься что на каждой итераци можно считать индекс для обновления на следующей итерации - r. Вычислительная сложность O((k*(n*log(n))): Выполняем k итераций, на кадой сортируем набор размером n. Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. Очень много текста? Это НЕ подходящая задача для интервью, но адекватное тестовое задание, если требуется проверить алгоритмическую смекалку (для SQL разработчика ). В силу специфики SQL движка, и особенно модели, накладные расходы могут достаточно сильно искажать картину. В частности, вариант Valergrad скоее всего будет быстрее даже улучшенной модели не смотря на его большую вычислительную сложность. На PL/SQL можно решить заметно эффективнее и без простыни говно-кода. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.10.2018, 02:56 |
|
||
|
Задача на собеседование
|
|||
|---|---|---|---|
|
#18+
Valergrad...На минуту опередил! Зря я так расписывал... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.10.2018, 03:00 |
|
||
|
Задача на собеседование
|
|||
|---|---|---|---|
|
#18+
Кобанчегдля SQL разработчика Это кто такие? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.10.2018, 07:46 |
|
||
|
Задача на собеседование
|
|||
|---|---|---|---|
|
#18+
КобанчегValergrad...На минуту опередил! Зря я так расписывал... Сорри... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.10.2018, 11:49 |
|
||
|
Задача на собеседование
|
|||
|---|---|---|---|
|
#18+
КобанчегНа PL/SQL можно решить заметно эффективнее и без простыни говно-кода. Как-то сурово. Код как код, видал я ( и вижу на работе регулярно у коллег ) и похуже. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.10.2018, 12:01 |
|
||
|
Задача на собеседование
|
|||
|---|---|---|---|
|
#18+
ElicКобанчегдля SQL разработчика Это кто такие?Разработчику Оракла зачастую более важно уметь выражать мысли декларативно на SQL чем быть искусным в алгоритмах. С другой стороны, задача могла бы быть уместной на собеседовании C++/Java. Хотя никто доподлинно не может сказать на какую позицию была эта задача и была ли вообще. ValergradКак-то сурово. Код как код, видал я ( и вижу на работе регулярно у коллег ) и похуже.Ну раз тех коллег кто-то нанимает и никто не увольняет, то и SkilledJunior не пропадет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.10.2018, 12:20 |
|
||
|
Задача на собеседование
|
|||
|---|---|---|---|
|
#18+
КобанчегНу раз тех коллег кто-то нанимает и никто не увольняет, то и SkilledJunior не пропадет. А у вас таких нет? Что за компания, я тогда к вам пойду))) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.10.2018, 12:49 |
|
||
|
Задача на собеседование
|
|||
|---|---|---|---|
|
#18+
ValergradЗдесь не соглашусь. А не надо соглашаться или не соглашаться, тесты нужно написать и выполнить в одинаковых условиях, тогда будет более менее реальная картина. ValergradНа малых значениях еще важна константа, которая для sql-решения будет, конечно, меньше за счет нативности операций и отсутсвия переключений контекста. Ты уверен что PL/SQL не нативный? Что касается переключения контекста, и накладных расходов, с этой точки зрения такой запрос: select my_st_all_typ(num_station, dist_to_prev, 0, dist_to_prev) это опа. Зачем я так сделал? Чтобы продемонстрировать табличные функции разных типов и поленился немного, конечно нужно было считывать исходные данные в коллекцию записей а не объектов, считывая в коллекцию объектов приходится дергать конструктор объекта, т.е. дергать функцию на каждую строку, в реальной системе так делать конечно не стоит. ValergradВпрочем, эта сложность не наилучшая. Скажем, есть несложное решение ( использующее как раз структуры данных ) у которого сложность алгоритма будет o( log(n) * k). Сможете найти? Слабое место это поиск максимального расстояния на каждой итерации, я прохожу в лоб циклом перебирая N строк, можно пытаться строить индекс и пользоваться индексом, но есть большое но, индекс очень быстро теряет свою селективность по максимальному значению и начинает стремиться к полному перебору, т.е. индекс нужно периодически полностью перестраивать, делать это на каждой итерации еще хуже чем простой перебор. Поэтому я надеюсь ты не хотел предложить ассоциативный массив с неуправляемой тобой индексацией и не совсем подходящим типом данных индекса? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.10.2018, 00:00 |
|
||
|
|

start [/forum/topic.php?fid=52&msg=39719547&tid=1883283]: |
0ms |
get settings: |
6ms |
get forum list: |
14ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
157ms |
get topic data: |
11ms |
get forum data: |
2ms |
get page messages: |
65ms |
get tp. blocked users: |
1ms |
| others: | 201ms |
| total: | 463ms |

| 0 / 0 |
