All streams
Search
Write a publication
Pull to refresh
0
0
Евгений Варганов @Gokjer

User

Send message
Да, есть, надо лишь выбрать правильную школу :)

Насчет преимуществ F# перед OCaml ничего не могу сказать, ибо в тонкостях их различия не разбирался. Вам, как работнику Майкрософт, виднее. По поводу инструментов разработки — по-моему, в школе ничего кроме Far Manager'a и компилятора не нужно.

А Haskell, я думаю, слишком однобок. Серьезную математику, на которой он основан, изучать сложновато будет в школе, а то, что на поверхности, в основном умеет и OCaml. Haskell интересен с точки зрения ленивых вычислений(которые, кажется, в OCaml костылем делаются), все остальное либо сложно для обучения, либо есть и в более универсальных языках.
Мой первый язык — OCaml. Я его начал изучать в восьмом классе и, на мой взгляд, он не сильно сложен для изучения. Кроме того, он мультипарадигменный, так что при должном построении процесса обучения на базовом уровне вполне можно вопринять ФП и ООП.

Также OCaml можно использовать в качестве второго языка. На него, как на язык более высокого уровня, можно переходить после того же Паскаля постепенно, писать сначала в паскалеподобном стиле(что синтаксис позволяет).
Ну это уже для извращенцев на любителя.
А еще есть японские шахматы — Сёги.
Вы не поняли, программа предназначена для тех, кто ходит в спортзал. Если вы бегаете по утрам, никто не заставляет вас её использовать.
А количество выкуренных сигарет тоже по GPS определялось?
Насколько я понимаю, если написать
head $ solve mathOperators [1, 5, 6, 7] 21

то Хаскель сам оборвет вычисления на первом попавшемся результате.
А на вашем конкурсе никто не предлагал другого решения? Лично я, участвуя, не стал бы писать решение в лоб, а попробовал бы придумать что-то. На мой взгляд, это единственное, что представляет интерес.
А у этой задачи нет более оптимального решения, кроме полного перебора? Вы реализовали самый очевидный алгоритм, нет ли чего-то более быстрого?
Я в физике ноль, но давайте пофантазируем. Возьмем упомянутое вами уравнение. Представим, что нейтрино могут спонтанно домножать свою массу на мнимую единицу. Тогда скорость автоматически перескакивает на сверхсветовую(процесс, разумеется, не изменяет энергию). Однако, состояние с мнимой массой жутко нестабильно, поэтому массы нейтрино довольно быстро возвращаются обратно в вещественную область. Наличие таких перескоков может сделать среднюю скорость на измеряемом участке больше скорости света.
Под категорию «тахион» они тоже не попадают, т.к. эти частицы должны обладать мнимой массой, тогда как нейтрино обладают массой реальной.
Можно еще один глупый вопрос он не-физика?
Почему масса у нейтрино не может внезапно поменяться? Случайно так на мнимую единицу домножиться, к примеру.
Часть не заметила вообще. Если вы из третьей группы, то с большой вероятностью вы — дислексик.

Дислексикам сложно читать:… слова с перемешанными буквами.

А как дислексик может не заметить ошибку, если ему сложно прочитать слово?
Из владений Дании
В haskell'е вам тоже никто не запрещает пройти циклом по списку и подсчитать все, что нужно. Фишка в том, что можно написать нечто в среднем то же самое(и даже немного быстрее) в одну строчку. Более того, я не знаю, как работает стандартная сортировка (sort из Data.List), но на моем нетбуке она немного обгоняет как пробег по массиву, так и qsort(в плохих случаях).
Вообще пример с qsort я привел как самый очевидный, наверняка что-то подобное можно сделать и, к примеру, с mergesort.
Пока гипотетический C/go программист писал свой пробег по циклу, его товарищ написал на haskell'e одну строку и оставшиеся две минуты неспешно пил горячий кофе, с легкой усмешкой поглядывая на соседа.
А вы можете найти k наименьших элементов в массиве/списке менее, чем за O(N)? То есть не проходя весь массив/список?
Вы не поверите, но в «ленивом» языке тоже никто не будет сортировать весь массив. Отсортируется то, что нужно, остальное останется в стороне.
То есть попась в случай, когда опорный элемент оказался в хвосте — очень даже вероятно.

Столь же вероятно, сколь и попасть в случай, когда «опорный элемент» окажется в начале. Итого в среднем он оказывается в середине списка, т.е. делит список на «половинки».
Прочитайте мой комментарий выше, там нестрого, на пальцах пояснено, почему алгоритм будет работать за O(N).

В подавляющем большинстве случаев будет массовая и затратная операция над данными.

В каком, простите, подавляющем большинстве? Что есть массовая и затратная операция? В среднем такой алгоритм будет работать за O(N). Вы случайно не считаете, что «в подавляющем большинстве случаев» qsort работает за O(N^2)?
В среднем, алгоритм с qsort'ом будет работать быстрее, т.к. работает за O(N), см. мой комментарий ниже.
Вы, вероятно, упоминаете интуитивный алгоритм в 1 пробег с чем-то вроде стека в руках. Я давно не писал на хаскеле, но вот — то, что пишется за пару минут(извините за некоторую корявость):
sink a (r1:rs) | r1 > a = r1:(sink a rs)
sink a l = a:l

kmin k len r (a:l) = kmin k len1 r1 l
 where
  r1 = if len<k then sink a r
   else drop 1 $ sink a r
  len1 = if len<k then len+1 else len

kmin _ _ r _ = r

mink k l = reverse $ kmin k 0 [] l

И это работает медленнее, чем take и самописный qsort(а также медленнее, чем take и встроенный sort из Data.List).

Information

Rating
Does not participate
Location
Санкт-Петербург, Санкт-Петербург и область, Россия
Registered
Activity