- 1
- 2
- 3
- 4
- 5
- 6
- 7
main = do
print [1 .. 9]
print [1, 3 .. 9]
print [1, 3 .. 10]
print [26.0, 26.2 .. 27.0]
print [25.5..30.0]
print [25, 25 .. 25]
Нашли или выдавили из себя код, который нельзя назвать нормальным, на который без улыбки не взглянешь? Не торопитесь его удалять или рефакторить, — запостите его на говнокод.ру, посмеёмся вместе!
+132
main = do
print [1 .. 9]
print [1, 3 .. 9]
print [1, 3 .. 10]
print [26.0, 26.2 .. 27.0]
print [25.5..30.0]
print [25, 25 .. 25]
В хаскеле сломан генератор списков. :(
http://ideone.com/AvBSuz
serpinski 22.10.2012 23:37 # +5
ZX_Spectrum 23.10.2012 00:29 # +5
HaskellGovno 23.10.2012 01:22 # +2
http://ideone.com/9HQgCW
Забавный факт, но Хаски считает, что -1/0 > 0/0
HaskellGovno 23.10.2012 01:35 # +2
Суть:
http://ideone.com/92PHF2
HaskellGovno 23.10.2012 01:48 # +2
http://liveworkspace.org/code/bb5d5a7fb37f6fc7555a03d49a1c517e
3.14159265 23.10.2012 20:17 # +4
bormand 23.10.2012 06:42 # +1
[a .. b] => for (i=a; i<=b; i++);
[a, b .. c] => for (i=a; i<=c; i+=(b-a))
[25, 25 .. 25] отлично вписывается в схему. А вот про 30.5 действительно непонятно.
bormand 23.10.2012 06:50 # +1
3.14159265 23.10.2012 20:41 # +1
Всё правильно.
Человеческое мышление оно ведь инерционно и сразу думает в случае: print [25.5..30.0] что шаг 0.5.
Это код-подъебка. Особенно когда уже усталый смотришь.
http://ideone.com/yl5LWQ
Правильно так:
main = do
print [25.5,26.0..30.0]
А у гумна аналогично такому:
main = do
print [25.5,26.5..30.0]
bormand 23.10.2012 20:51 # 0
25.5 26.5 27.5 28.5 29.5 30.5
Хотя надо курить доку, вдруг так и задумано.
3.14159265 23.10.2012 20:59 # 0
bormand 23.10.2012 21:11 # +1
http://ideone.com/TAY8A0
3.14159265 23.10.2012 21:12 # 0
3.14159265 23.10.2012 20:22 # +1
Наверное округляет в инты неправильно. Строгая типизация и явные задания типов тут рулят.
http://ideone.com/HZoCdY
bormand 23.10.2012 20:52 # 0
Хммм... а это мысль.
Походу да: http://ideone.com/nKJ7er
Возможно, что он делит длину диапазона на размер шага, и считает сколько нужно сделать шагов. Вот в этот момент и происходит то самое округление не в ту сторону.
P.S. По идее тут надо делать floor а не round... Но судя по результатам там таки round.
3.14159265 24.10.2012 15:12 # +3
Хацкил - очевидный язык.
bormand 24.10.2012 15:54 # 0
Непонятно только какого хрена там round.
3.14159265 24.10.2012 15:57 # +1
>какого хрена там round.
говно. хотя может они так перестраховаться от плавающей точки решили.
bormand 24.10.2012 16:04 # +1
P.S. Кажется начинаю понимать - в нормальных условиях (а не в таких, которые подобрал для нас Гумно) первый и последний аргумент выбраны не хуй-пойми как, а в качестве них взяты действительно первая и последняя точки перечисляемого нами отрезка. Если бы они делали floor, то тот перескок, который мы видим сейчас происходил бы на корректных ситуациях в духе [1.0,3.0 .. 5.0]. Такой вот трейд-офф.
bormand 24.10.2012 16:16 # +1
http://ideone.com/5g9w3w
Благодаря round на вменяемых примерах его нет. Хотя из-за этого и страдают примеры, приведенные Гумном.
3.14159265 24.10.2012 18:35 # 0
3.14159265 24.10.2012 19:46 # +1
Да и здание оного в списке испортило бы всю красоту запейси:
[25,27 .. 32.0, eps=0.001]
А по другому проблему 4.9999 итераций никак не разрулить.
Разве что помнить, что циклы (списки) с плавающей точкой на наших процессорах - источник опастности в любом языке.
Вот в питоне range ясно дает понять что к чему:
TypeError: range() integer end argument expected, got float.
И в аде тоже
for f in Float range 25.0 .. 28.0 loop
prog.adb:7:14: expected a discrete type
HaskellGovno 24.10.2012 16:19 # +2
bormand 24.10.2012 16:33 # +1
roman-kashitsyn 25.10.2012 21:33 # +1
Об этом, кстати, в самом начале RWH говорят "Beware enumerating floating point numbers"
3.14159265 25.10.2012 21:41 # +3
Могли ведь просто запретить float и оставить дроби - было крайне кошерно. А хацкель был бы единственным языком который корректно работает с рациональными числами.
Нет, хотим говнячить Float и Double и делать хаки с округлением.
PS. Мне так и не удалось сломать Ratio Integer.
bormand 25.10.2012 21:44 # +2
Совсем от флоата и дабла избавляться не стоит. Есть много задач где их точности вполне достаточно, и при этом важна скорость вычислений. А вот из класса Enum их вполне можно было выкинуть. Ну какие они к черту перечисляемые?
3.14159265 25.10.2012 22:09 # +1
Так никто об этом не говорит. Надо просто поубирать их из чисто дискретных аспектов и функций.
roman-kashitsyn 25.10.2012 21:45 # +2
3.14159265 25.10.2012 21:49 # +2
Но только теперь язык не виноват в том что ты берешь пистолет и стреляешь себе в ногу.
Ада же не дает range по флоатам, как тут сказал Тарас -
>Выбирая такое неточное говно, как Float, ты уже подписываешься на то, что тебе пофиг точность.
http://govnokod.ru/11979
Сам написал говноцикл - сам и разруливай.
bormand 25.10.2012 21:49 # +1
HaskellGovno 23.10.2012 18:22 # +2
http://habrahabr.ru/post/153659/
bormand 23.10.2012 20:25 # 0
А если читать файл надо не "для поиграться", а по-настоящему - есть модуль ByteString, в котором все работает побыстрее Prelude'ского hGetContents (читает чанками), кушает меньше памяти, и есть версии с ленью и без нее.
Abbath 23.10.2012 20:42 # 0
3.14159265 23.10.2012 20:46 # +1
Рекомендую запустить в коносли:
Это из-за FPU, его баг если хотите.
Это давно известная херня и так ведут себя все языки:
http://ideone.com/hU0BGx
http://ideone.com/hVR0Qw
Другое дело что хацкель гордовитый своей сверхвысокоуровневостью мог бы и обойти такое поведение.
ZX_Spectrum 23.10.2012 23:55 # 0
3.14159265 24.10.2012 14:12 # +2
Но хацкил хочет быть выше этого.
wvxvw 25.10.2012 12:24 # +4
wvxvw 26.10.2012 01:23 # +3
Более подробная информация :)
3.14159265 26.10.2012 14:47 # +1
М-м. Божественно.
3.14159265 23.10.2012 21:03 # 0
ideone.com/pXIhvY
Fai 24.10.2012 05:18 # +4
bormand 24.10.2012 05:32 # 0
Lure Of Chaos 24.10.2012 11:14 # +4
roman-kashitsyn 24.10.2012 11:30 # +5
> Достаточно просто изменить нашу вселенную убрав из нее состояние
Ох уж мне эта трёхмерная крестоимперативщина.
Бесконечноразрядный компьютер вселенной тик за тиком раскрывает бесконечный ленивый персистентный вектор иммутабельных состояний пространства-времени.
Иначе как, по вашему, работает машина времени?
bormand 24.10.2012 13:12 # 0
Если не заныкать ссылочку на предыдущее состояние - никак. GC ведь уберет все ненужное, и возвращаться будет некуда.
roman-kashitsyn 24.10.2012 13:18 # +5
У бесконечноразрядного компьютера вселенной бесконечное количество оперативной памяти, GC там не нужён.
Память освободит вселенская операционная система при завершении программы...
Vasiliy 24.10.2012 13:33 # +5
3.14159265 24.10.2012 15:07 # 0
GC - это Большое сжатие.
Yuuri 13.02.2013 17:52 # +2
3.14159265 24.10.2012 14:35 # +1
>Иначе как, по вашему, работает машина времени?
Она порождает новый вектор? Ведь старые состояния нельзя изменить.
roman-kashitsyn 24.10.2012 14:59 # 0
Я тут на стороне Эйнштейна. Хаос не потому хаос, что он не определяется детерминированными законами, а потому, что законы эти чрезвычайно чувствительны к входным данным (правда, это должно означать, что наша судьба, поступки и мысли полностью определены заранее :[).
> Она порождает новый вектор?
Именно, рождается новая ветвь бытия
3.14159265 24.10.2012 15:03 # 0
>правда, это означать, что наша судьба полностью определена заранее
Да. Я бы тоже был полным сторонником такого .
Если бы не одно НО! - принцип неопределенности гейзенберга.
roman-kashitsyn 24.10.2012 15:14 # −1
Но ведь каждую из сопряжённых величин мы можем измерять с достаточной точностью, проблемы возникают лишь при наблюдениях за несколькими величинами одновременно
лол, упираемся в дискретное время вселенского процессора
Vindicar 24.10.2012 16:41 # 0
HaskellGovno 24.10.2012 13:53 # +1
Например:
*Функтор. Крестобляди считаю, что это функциональный объект. Почему? Функтор из теории категорий: отображение одного множества на другое.
*Каррирование. Крестобляди считают, что это bind. В то время как на самом деле bind - это частичное применение/биндинг. В то время как каррирование/декаррирование - это преобразование функции принимающую несколько параметров в функцию принимающую кортеж и обратно.
И таких моментов много. Почему так?
roman-kashitsyn 24.10.2012 13:56 # +3
defecate-plusplus 24.10.2012 14:00 # +7
functor - 0 вхождений в документ стандарта
function object - 59
curry/сurrying - 0 вхождений
binding - 46
Abbath 24.10.2012 14:20 # +2
LispGovno 24.10.2012 22:25 # 0
3.14159265 24.10.2012 15:28 # +4
Самая суть говнистости хацкила.
Хотя с NaNами мне тоже понравилось.
LispGovno 24.10.2012 16:13 # 0
http://ideone.com/KjeLmf
Смачно вбросил. Уважуха.
TarasB 24.10.2012 18:55 # +3
bormand 24.10.2012 19:04 # 0
Почитай, может найдется, что покритиковать или дополнить.
3.14159265 25.10.2012 16:10 # +3
Yurik 27.10.2012 22:39 # +2
ghci> [1.0,1.25..2.0]
[1.0,1.25,1.5,1.75,2.0]
ghci> [1,4..15]
[1,4,7,10,13]
ghci> [10,9..1]
[10,9,8,7,6,5,4,3,2,1]
In the latter case above [тут он соснул, не в последнем примере, а во втором], the list is quite sensibly missing the end point of the enumeration, because it isn't an element of the series we defined.
We can omit the end point of an enumeration. If a type doesn't have a natural “upper bound”, this will produce values indefinitely. For example, if you type [1..] at the ghci prompt, you'll have to interrupt or kill ghci to stop it from printing an infinite succession of ever-larger numbers. If you are tempted to do this, type C to halt the enumeration. We will find later on that infinite lists are often useful in Haskell.
[Warning] Beware enumerating floating point numbers
Here's a non-intuitive bit of behaviour.
ghci> [1.0..1.8]
[1.0,2.0]
Behind the scenes, to avoid floating point roundoff problems, the Haskell implementation enumerates from 1.0 to 1.8+0.5.
Using enumeration notation over floating point numbers can pack more than a few surprises, so if you use it at all, be careful. Floating point behavior is quirky in all programming languages; there is nothing unique to Haskell here.
http://book.realworldhaskell.org/read/getting-started.html#starting.list
3.14159265 28.10.2012 18:03 # +3
Ну я уже неоднократно предлагал рациональное лекарство.
>is quirky in all programming languages
Съезд. В пыхе ведь всё гораздо лучше.
Ситуацию усугубляет то, что они самые рьяные борцуны за чистоту и простоту кода, высокоуровневость и читаемость языка.
TarasB 28.10.2012 18:21 # +2
Шикарно
bormand 24.10.2012 20:28 # +2
bormand 24.10.2012 20:56 # +2
LispGovno 24.10.2012 22:19 # +1
bormand 25.10.2012 06:59 # 0
3.14159265 25.10.2012 15:08 # +3
По-своему некрасива.
У нас есть выбор
а) по сути UB, когда мы сравниваем прямо:
http://ideone.com/hU0BGx
http://ideone.com/pXIhvY
Это если мы не округляем.
б) проблемы связанные с округлением.
Но тут тоже не все так просто
> m + 1/2
Ведь можно окрулять вверх не от половины, а от 0.99, например.
Тогда проблемный диапазон становится меньше.
И конечно основную проблему так мы не решаем - какое-то гумно может взять большие числа и интервалы.
3.14159265 25.10.2012 15:13 # +3
Но! Есть еще один вариант. Мне вот нравится то что пишет Ада:
expected a discrete type. А конкретно слово дискретный.
в) Можно превращать это в дроби. Тогда коды гумна выше можно интерпретировать так:
[51/2..60/1],[26/1,131/5 .. 27/1]
И все проблемы решаются т.к. дроби дискретные и можно точно узнать количество итераций.
Такие циклы [0,1/3..10/3] будут работать безупречно, несмотря на бесконечную дробь
Единственное что надо запрещать - ставить переменные-floatы, а константы всегда можно выразить в виде дроби.
HaskellGovno 25.10.2012 15:15 # +2
3.14159265 25.10.2012 15:34 # +3
bormand 25.10.2012 15:31 # +2
Грустно.
3.14159265 25.10.2012 15:39 # 0
Ну кстати можно попробовать взять их код, убрать округление и посмотреть как ведут себя дроби при расчете количества итераций. Дабы понять - это сахарок или полноценные инты.
Повторюсь Float, Double там вовсе не нужны.
bormand 25.10.2012 15:46 # 0
Нет-нет. Дроби это полноценные рациональные числа. Там же не зря пишется не просто Ratio, а Ratio a, где вместо a обычно подставляют Int (если уверен что не зашкалит) или Integer (труъ рационалки, ограниченные только памятью).
3.14159265 25.10.2012 15:55 # +2
bormand 25.10.2012 16:14 # +3
3.14159265 25.10.2012 16:20 # +1
1. убрать Float, Double
2. убрать говнохак +1/2.
...
Хацкель снова рулит.
HaskellGovno 25.10.2012 16:23 # +2
3.14159265 25.10.2012 16:24 # +4
USB 26.10.2012 18:51 # −2
LispGovno 29.10.2012 16:30 # 0
3.14159265 25.10.2012 16:43 # +3
И вот свершилось! Сбылась мечта идиота!
http://25.media.tumblr.com/tumblr_m4vdb7JBM61qcbdv2o1_500.jpg
HaskellGovno 25.10.2012 17:19 # +3
3.14159265 25.10.2012 19:17 # +3
И всё илитные функцианальные языки соснулей у пхп. Какой позор.
bormand 25.10.2012 16:44 # +2
3.14159265 25.10.2012 17:50 # +4
htttp://ideone.com/BZ6lr5
В убогом пхп всё отлично работает по дефолту.
Решил проверить еще парочку языков, так, чисто для галочки.
И выяснилось страшное - быдлопыха работает правильней, чем илитные лисп и хацкель. Ха-ха-ха!
HaskellGovno 25.10.2012 18:34 # +1
3.14159265 25.10.2012 18:37 # +2
Главное факт: хацкель, а вместе с ним лисп соснули у пхп.
PHP выбор разработчиков-профессионалов для разработки высоконадежных систем, а haskell и lisp удел псевдоматематического безработного быдла.
3.14159265 25.10.2012 18:52 # +2
Хотите знать что это?
Следите за анонсами в новостях.
3.14159265 25.10.2012 19:09 # +2
А еще она дико тормознутая - пример ideone компилился больше минуты.
Так мало того оно на ideone работает по-другому чем у меня.
http://ideone.com/IoYR62
3.14159265 25.10.2012 19:09 # +3
println (7.0 to 8.2 by 0.3);
выдает ArithmeticException.
Это пиздец, да.
PS. Тут есть ScalaGovno?
roman-kashitsyn 25.10.2012 19:28 # 0
Компилится да, охренеть как долго.
bormand 25.10.2012 19:27 # +2
3.14159265 25.10.2012 19:38 # +1
Как и предполагалось выше:
>Ведь можно окрулять вверх не от половины, а от 0.99, например.
Тогда проблемный диапазон становится меньше.
Я не курил сырцы но нашел пример иллюстрирующий. И в руби наверное тоже так.
Вот кстати баш и руби
http://ideone.com/5tjYy6
http://ideone.com/ZZSbj1
bormand 25.10.2012 19:40 # +3
http://ideone.com/2Yb8Fw
3.14159265 25.10.2012 19:41 # +3
.999999 - нечестно ведь.
bormand 25.10.2012 19:44 # +1
Вот у него то уж точно децималы в виде строк...
3.14159265 25.10.2012 19:45 # +1
http://ideone.com/5tjYy6
Правда девяток многовато, но это наверное из-за того что в пыхе флоат, а баше дабл или вовсе 80-битный.
bormand 25.10.2012 19:49 # +1
3.14159265 25.10.2012 19:54 # +2
Хацкельные дроби c Int соснули:
http://ideone.com/PVn4Ug
Правда c Integer - нормал.
3.14159265 25.10.2012 20:02 # +3
Int соснул - ничего не вывел.
Integer соснул - вывел элемент за пределами диапазона.
PHP wins again!
bormand 25.10.2012 20:05 # +1
3.14159265 25.10.2012 20:09 # +1
Но он на удивление банален
bormand 25.10.2012 20:29 # +2
[3%2,9%5,21%10,12%5,27%10]
Эм, а что тут не так? [1.5, 1.8, 2.1, 2.4, 2.7] 3.0 же уже не нужно.
3.14159265 25.10.2012 20:46 # +1
Меня сбил с толку предыдущий Int который вывел ошибочный и странный результат:
[3%2,9%5,21%10,12%5]
3.14159265 25.10.2012 20:47 # +2
Пёрлу - похуй.
http://ideone.com/pOQFnA
Луа соснула, равно как и все жабоскриптовые:
Lua: http://ideone.com/pgPiqW
Rhino: http://ideone.com/Vn71Mz
spidorMonkey: http://ideone.com/r3IlGM
А груви кстати оказался на удивление хорош, но с .9999999 он сфейлил.
http://ideone.com/ZOlfyv
PS. Проверьте кто-нибудь в крестах бустовский range.
defecate-plusplus 26.10.2012 17:15 # +2
да он походу целочисленный
если кому хочется плавающей точки - предлагается написать самому
только вот мне никогда и целочисленной не доводилось захотеть
rat4 24.10.2012 20:38 # +6
3.14159265 26.10.2012 16:42 # +3
Шарпоблядский OCAML F# и cуровый Erlang.
C F# всё уныло и собственно никакого интереса не представляет. Ну говно как говно, и что?
http://ideone.com/7P6YAup
Забавно другое в шарпе поступили мудро там нельзя! писать иначе как Enumerable.Range(int a,int b)
Неудивительно что в скором времени нашлись забавные поциенты которые взялись и "решили" эту "проблему":
http://www.c-sharpcorner.com/uploadfile/b942f9/dealing-with-ranges-of-numbers-in-C-Sharp
3.14159265 26.10.2012 16:52 # +4
"Вы узнаете об ошибке во время выполнения программы."
http://ideone.com/BG9EXu
defecate-plusplus 26.10.2012 16:54 # +3
3.14159265 26.10.2012 16:58 # +4
Репутацию Лиспа и Хацкеля подправили красивые дроби
А вот Scala и Erlang зашкварены особо .
roman-kashitsyn 26.10.2012 17:03 # +1
3.14159265 26.10.2012 17:05 # +2
А ладно. Я теперь понял суть названия ErrLang.
HaskellGovno 26.10.2012 17:14 # 0
roman-kashitsyn 26.10.2012 17:15 # +1
3.14159265 26.10.2012 17:16 # +2
roman-kashitsyn 26.10.2012 17:14 # +2
3.14159265 26.10.2012 17:18 # +2
В итоге незашкваренными оказалась: Ада, С#
Более-менее нормально генераторы работают в Руби, Груви, Баше и PHP
Ирланг, Пёрл и Путхон - динамика, но флоаты не разрешают.
Остальные - зашкварены в той или иной мере.
roman-kashitsyn 26.10.2012 17:23 # +5
3.14159265 26.10.2012 17:25 # +1
Спишем это на мои крайне низкие познания.
При таком подходе - это хорошо что оно падает. Недетерминированый float-код не сможет выполнится.
roman-kashitsyn 26.10.2012 17:32 # +3
С другой стороны, для какой-либо другой задачи я бы брать erlang не стал.
по сценарию должен придти @wvxvw и обосрать изделие шведских телекомовцев
3.14159265 26.10.2012 17:55 # +3
У меня возникли проблемы с этим. В жабе concurent фреймворк написан замечательно (в сравнении с другими частями стандартной либы он превосходен).
Но лажа в том что никак нельзя остановить треды, которые сами не хотят останавливаться.
http://ideone.com/v9K21C
Да и в Thread Api всё задепрекейтили.
И еще неочедидный и часто заёбывающий InterruptedException приправленый spurious wakeupами на линукс-системах.
Какое нормальное решение этого вопроса, как правильно останавливать треды, на примере того же эрланга?
USB 26.10.2012 18:00 # 0
Что означает?
3.14159265 26.10.2012 18:24 # +2
Но вот только иногда (из-за специфичности потоков на некоторых ос) оно возникает случайно.
Зачем так сделано - хуй знает. Может перестраховка от дедлоков, но твой тред отваливается с прерыванием по непонятной причине - хоть его никто не прерывал.
О проблеме кстати в документации написана только 1 строка.
roman-kashitsyn 26.10.2012 18:14 # 0
В эрланге другая модель - легковесные процессы (шедулящиеся в юзерспейсе), не имеющие общего состояния, и асинхронная передача сообщений. Функционал супервизоров там из коробки. Уронить процесс безусловно там можно всегда функцией exit(Pid, Reason). Но вызывается она в основном из системного кода.
3.14159265 26.10.2012 18:31 # +2
Ну так можно поступить - если ты это контроллируешь .
Трабла в том что код который в Callable небезопастный - его пишут другие люди. Или он может юзать Blocking IO, например
roman-kashitsyn 26.10.2012 19:00 # +2
Замахиваешься на асинхронность - жертвуй. В том же Node.js получаются трёхэтажные конструкции с коллбэками к коллбэкам именно из-за того, что нельзя зависать в блокирующих операциях.
USB 26.10.2012 19:13 # −3
roman-kashitsyn 26.10.2012 19:15 # +2
bormand 26.10.2012 19:25 # +1
wvxvw 26.10.2012 19:38 # 0
Все равно никто никогда не запустит ничего серьезного на Эрланге, а на полсотню-сотню пользователей, и не на таком говне слепить можно. Даже сами разработчики этого никогда не делали, и большая часть ихней инфраструктуры написана на сях, Эрланг - для не принципальных моментов.
guest 26.10.2012 17:15 # 0
ZX_Spectrum 26.10.2012 20:23 # +2
таких изобретателей надо высылать на урановые рудники
bormand 26.10.2012 20:49 # +2