Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 29
А в каком виде заливать свое решение? Создавать новый файл со своим ником, править существующий? И как вы намерены обрабатывать конфликтующие pull-request'ы?
нет, создавать новый файл со своим решением. а по поводу второго вопроса — насколько я понял, там есть такая штука, как Organizations — где можно настраивать права.
И тогда может получиться свалка… Я вот например хотел бы поправить ваше решение, так как в нем есть явные «оплошности».
свалка вряд ли получится, потому что недостаточно людей.
а что вы предлагаете? как это можно лучше организовать? я просто до этого не сталкивался с гитом, поэтому не очень осведомлен
а что вы предлагаете? как это можно лучше организовать? я просто до этого не сталкивался с гитом, поэтому не очень осведомлен
Можете еще посмотреть на github.com/nashby/ruby_kick_prologs_ass
Там частично решены вот эти задачи — sites.google.com/site/prologsite/prolog-problems
Думаю, они поинтересней будут.
Там частично решены вот эти задачи — sites.google.com/site/prologsite/prolog-problems
Думаю, они поинтересней будут.
В третьей задаче вместо проверки больше размер массива нуля использовать .empty?.
… отсутствие официальной документации несколько замедляет процесс обучения.
Не могу понять о чём вы говорите. Официальная документация есть www.ruby-doc.org/
А ешё есть книга, вышедшая недавно на русском языке Язык программирования Ruby/.
И ещё есть вот прекрасная книга на английском языке: Metaprogramming Ruby: Program Like the Ruby Pros.
Ну и раз уж речь идёт о лучших решениях, то стоит упомянуть и это издание: Ruby Best Practices.
#001 можно короче: p $<.read.split.map{|x| x.to_i}.max
Из условия задачи: «Количество чисел меньше 10000». Я конечно понимаю, что на современных мощностях преобразовать строку, размером порядка 25 кб, в массив — это фигня. Но в рамках спортивного программирования так не делается. Уж слишком бросается в глаза неоптимальность использования массива для решения данной задачи.
А если уж гнаться за минимальностью кода, то можно ж ещё на 7 символов сократить:
p gets.split.map(&:to_i).max
А если уж гнаться за минимальностью кода, то можно ж ещё на 7 символов сократить:
p gets.split.map(&:to_i).max
задача 000 красивее:
puts gets.split.inject { |memo, num| num.to_i + memo.to_i }
puts gets.split.inject { |memo, num| num.to_i + memo.to_i }
Тогда уж хотя бы так:
puts gets.split.inject(0) { |memo, num| num.to_i + memo }
Ну это в рамках исправления неправильного использования inject…
А вообще все подобные решения неправильны, где запросы типа «Введите первое число: », «Введите второе число: »? Валидация входных данных напрочь отсутствует. А решения с inject вообще решают какую-то другую задачу, ведь они легко могут просуммировать и больше, чем 2 числа.
puts gets.split.inject(0) { |memo, num| num.to_i + memo }
Ну это в рамках исправления неправильного использования inject…
А вообще все подобные решения неправильны, где запросы типа «Введите первое число: », «Введите второе число: »? Валидация входных данных напрочь отсутствует. А решения с inject вообще решают какую-то другую задачу, ведь они легко могут просуммировать и больше, чем 2 числа.
Integer#to_i возвращает самого себя. inject без параметра по дефолту берёт в качестве первого результата первое число, а первого аргумента — второе число. не могу понять, почему вы говорите, что inject использован неверно.
Причём тут Integer#to_i? Ваш вариант эквивалентен вызову:
puts gets.split.inject("") { |memo, num| num.to_i + memo.to_i }
Это в принципе работает, но складывать числа, помещая промежуточные результаты в строку, — это явно плохой пример новичкам. Да и вообще абсурдно как-то, не?
Если сомневаетесь, что аккумулятор в вашем примере строка, можете попробовать:
puts gets.split.inject { |memo, num| num.to_i + memo }
puts gets.split.inject("") { |memo, num| num.to_i + memo.to_i }
Это в принципе работает, но складывать числа, помещая промежуточные результаты в строку, — это явно плохой пример новичкам. Да и вообще абсурдно как-то, не?
Если сомневаетесь, что аккумулятор в вашем примере строка, можете попробовать:
puts gets.split.inject { |memo, num| num.to_i + memo }
аккумулятор в моём примере строка только на первой итерации. inject без параметра берёт на первой итерации в кач-ве аккумулятора 1ый член, в качестве итератора второй, на остальных строкой будет только итератор. кое-кому надо перечитать справочник ;)
на всякий случай, чтобы вы больше не спорили:
ruby-1.9.2-p180 :006 > puts gets.split.inject { |memo, num| puts memo.inspect; puts num.inspect; num.to_i + memo.to_i }
123 234
"123"
"234"
357
=> nil
ruby-1.9.2-p180 :007 > puts gets.split.inject { |memo, num| puts memo.inspect; puts num.inspect; num.to_i + memo.to_i }
123 234 345 456
"123"
"234"
357
"345"
702
"456"
1158
=> nil> аккумулятор в моём примере строка только на первой итерации.
Ну и в чём сакральный смысл этой путаницы? Понтануться как круто Вы знаете справочник по Ruby? Даже если я его перечитаю, я всё равно буду утверждать, что это пример крайне плохого, нечитабельного кода с лишними приведениями типов, т.к. даже Integer#to_i вызывать глупо. Так программировать не надо, а учить других так программировать вообще злодеяние.
Ну и в чём сакральный смысл этой путаницы? Понтануться как круто Вы знаете справочник по Ruby? Даже если я его перечитаю, я всё равно буду утверждать, что это пример крайне плохого, нечитабельного кода с лишними приведениями типов, т.к. даже Integer#to_i вызывать глупо. Так программировать не надо, а учить других так программировать вообще злодеяние.
ололо.
считаете, что решение с лишним аргументом и лишней итерацией лучше — ваши проблемы. только сами первые по поводу простоты и «неверного учения новичков» не начинайте.
считаете, что решение с лишним аргументом и лишней итерацией лучше — ваши проблемы. только сами первые по поводу простоты и «неверного учения новичков» не начинайте.
Если Вы забыли, повторюсь, что решение с использованием inject для данной задачи является абсолютно неверным.
В корректном решении обязательно должна быть проверка на кол-во (не более двух) и тип (только целые числа) полученных от пользователя значений.
В корректном решении обязательно должна быть проверка на кол-во (не более двух) и тип (только целые числа) полученных от пользователя значений.
в таких задачах практически всегда суть заключается в том, чтобы удовлетворить функциональные требования. если при этом решение может складывать и другие количества чисел, и не падает от неверного вода, то на это не смотрят. потому что в реальном мире такое поведение пошло бы только на пользу.
в доказательство формулировка задачи:
> Требуется найти сумму целых чисел A и B.
> Оба числа не превосходят 1 000 000 000 по модулю.
здесь не сказано, что программа должна умирать, если чисел не два, или если они превосходят 1000000000, или если они не целые.
в доказательство формулировка задачи:
> Требуется найти сумму целых чисел A и B.
> Оба числа не превосходят 1 000 000 000 по модулю.
здесь не сказано, что программа должна умирать, если чисел не два, или если они превосходят 1000000000, или если они не целые.
я там гольфил :) в нескольких задачах я в топе коротких решений :)
Только я на перле, а на руби со мной боролся Nakilon :)
«Нашелся отличный сайт с ejudge — acm.mipt.ru с интерпретатором Ruby. Но при решении задач(особенно на незнакомом языке), постоянно присутствует ощущение, что может быть это можно было сделать как-то иначе — легче, быстрее, удобнее.»
Можно еще сюда посмотреть rubyquiz.com/ и не париться с репозиторием и прочим. Есть задание, решаете, при этом в каждом задании слева есть список вариантов решения, также можно прислать свое.
Можно еще сюда посмотреть rubyquiz.com/ и не париться с репозиторием и прочим. Есть задание, решаете, при этом в каждом задании слева есть список вариантов решения, также можно прислать свое.
На codeforces.ru (типа русского TopCoder'а) можно решать задачки на Ruby, что очень порадовало ) И вообще там куча разных языков (в т.ч. С++, Delphi, Pascal, Java, PHP, Python, C#, C, Haskell)
А я смотрю кто-то все же не забросил до конца спортивное программирование, и это очень радует.
Идея очень хорошая, а с документацией могут быть проблемы только из-за того что Ruby долгое время была исконно японским «продуктом», хотя сейчас ситуация изменилась и можно легко найти доки на английском языке.
Идея очень хорошая, а с документацией могут быть проблемы только из-за того что Ruby долгое время была исконно японским «продуктом», хотя сейчас ситуация изменилась и можно легко найти доки на английском языке.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Репозиторий с задачами на Ruby