Если копипаст получился интересным, то почему бы и нет. Я так думаю, что надо сделать предварительную проверку заказчиком. Т.е. заказчик является наиболее компетентным, он и должен проверить. А вот на счет плюсов, это да… надо сделать рейтинг запросов, хотя с другой стороны, если кто-то написал запрос, значит ему это интересно.
Про реализацию чисто техническую, не знаю… можно сделать что-то похожее на вопросы с некоторыми ограничениями. Но, думаю, что это не проблема реализовать.
Поэтому оно и должно существовать. Есть конкретный технический топик, который точно кому-то интересно и этот кто-то может дать карму. Иначе только няшки с «сенсациями» и останутся. А так, человек знает, какие еще темы интересны.
Ну а что получится на самом деле предсказать сложно:)
Люди, зачем столько спорить из-за такой проблемы? Правды нет:) Те, кто привыкли писать на Си и понимают, как все это работает, будут писать на Си. (Лично для меня описанное поведение программы очевидно.) И эти люди будут писать хороший надежный код. Люди, которые не пишут на Си и привыкли к тому, что они не заботятся о таких мелочах, будут писать хороший код на чем-то другом, причем это самое что-то другое может быть лучше для какой-то конкретной цели (и это правильно, надо выбирать подходящие средства).
Проблема же заключается в том, что есть третьи люди, которые не понимают, как все устроено, но пытаются писать на Си. Вот тогда возникают трудности. Но я видел, как такие люди и на C#/Java/AS создавали проблемы, ничуть не хуже этого несчастного указателя. С любой технологией надо знать как работать. У каждой есть свои плюсы и минусы. Нельзя сказать, что Си плохой, потому что он позволяет делать ошибки, любой язык это позволяет, не с указателями, так с чем-то еще. Просто в Си, можно делать больше ошибок, как раз потому, что он дает больше возможностей.
В автомобилестроении существует аналогичная проблема: есть просто водители, а есть спортсмены. Просто водителям нужна нянька (всякие разные электронные системы безопасности, которые часто нельзя выключить), которая их может и спасти. Спортсмены же страдают от того, что эту самую няньку часто нельзя выключить и она ограничивает их действия, а может и убить если не повезет. Что лучше? А нет ответа, для простых водителей нужна нянька, для спортсменов — не нужна. А вот для тех, кто думает, что они спортсмены (но ими не являются), часто нужна лишь скорая.
Спасибо за разъяснение, стало понятно, но не до конца. Такой уж я непонятливый:)
Есть три возможных непонятности:
1) Что такое правдивость? Как она появляется и как связана с вероятностью, если связана?
2) Можно ли сказать, что нечеткая логика может включать в себя вероятностную модель, когда правдивость равна вероятности в тот момент времени, когда принимается решение?
3) Если предыдущее не верно, то как правильно применить нечеткую логику к задаче про пешехода? Возможно ли это в принципе? (Должно быть возможно, с обычной бинарной логикой я могу сказать просто, машина исправна И водитель видит = надо идти, но я теряю часть информации)
Мне она тоже была не нужна, пока я не оказался за тысячи километров от дома на неопределенный срок.
А, вообще, вот оно будущее — бесплатная видеосвязь по всему миру.
Вот поэтому и пытаюсь разобраться, где что:)
Я не совсем понимаю почему нельзя применять в этом случае нечеткую логику. Есть вероятность события — водитель видит пешехода. Но в то же время есть высказывание «водитель видит пешехода», оно может быть правдой или ложью в каждый момент времени: водитель либо видит, либо не видит, только вот мы не знаем ответа на него, знаем только то, что водитель чаще видит. Поэтому это высказывание правдиво в этот момент времени с этой самой вероятностью 70%. В чем тут ошибка?
Прочитал я статью и комменты и стало мне интересно немного разобраться, где же грань между вероятностными моделями и нечеткой логикой. Я не являюсь экспертом в этой области, поэтому хотел бы услышать мнение знающих людей. А чтобы было проще, приведу простой пример и мои то, как я это понимаю.
Представим, что есть пешеход, который планирует переходить дорогу на пешеходном переходе. В это время к пешеходному переходу приближается автомобиль.
Человек должен принять решение: начать переходить или стоять.
Машина может остановиться или проехать. Это зависит от 2 факторов: исправна ли машина (технически может остановиться) и видит ли водитель пешехода.
Предположим, что вероятность поломки машины 1% (т.е. в каждый момент времени у нас есть 1 шанс из 100 на то, что тормоза откажут, не очень хорошая машина. Можно взять реальные числа, рассчитанные исходя из времени наработки на отказ тормозов машины, но они будут маленькими и неудобными).
Вероятность того, что водитель не заметит пешехода 30% (т.е. есть в 3 случаях из 10, водитель просто не замечает пешехода, проезжая по этой дороге, а вот это число уже весьма реально, особенно вечером).
Итак, нам надо решить, что должен делать пешеход.
Вероятностная модель нам дает следующее: вероятность остановки машины равна 0,7*0,99 = 0,693 = 69,3%
Решение пешехода зависит от того, насколько он хочет жить. Если он хочет остаться в живых (считаем, выжить после аварии у него не получится) с вероятностью 95% (вполне нормальное желание), он должен ждать. Тут мы не рассматриваем то, что машина начнет останавливаться и это будет значить, что повысились шансы на то, что водитель видит пешехода, тогда решение может поменяться.
Нечеткая логика дает следующее: для того, чтобы перейти, нам надо знать, что машина остановится. Машина остановится если выполняются оба условия: она исправна и водитель видит пешехода. Правдивость того, что машина исправна 0,99, правдивость того, что водитель видит пешехода 0,7. Оператор И определен в статье a && b => a * b. и мы получаем все то же 0,693. Это значение правдивости такого утверждения: «пешеход перейдет дорогу и останется в живых». И тут нам надо делать дефаззификацию, если просто поставить какую-то границу (на сколько хочется жить), то будет точно также, как и с вероятностью. Если же случайно выбрать один из ответов с вероятностью 0,693 и обратной 0,307, то это не дает нам ничего, кроме принятия какого-то решения.
В такой задачке я не совсем понимаю разницы между подходами. Что я упускаю? Объясните плиз. Или может быть они не такие уж разные?
Все, как-бы, достаточно очевидно. Используя Си, мы платим безопасностью за производительность. Другое дело, что очень часто нам эта производительность ни к чему, в этом случае мы просто платим за то, что привыкли к Си:) Хочется меньше думать об управлении памятью, есть множество языков, которые в этом помогут, но потребуют за это плату в виде производительности.
Спасибо за сайт, почитаю.
А вы никогда не пробовали делать какой-нибудь простенький тест? Например посчитать длину вектора нативной функцией и вручную. У меня руки все никак не доходят до этого, да и без 3х компонентных векторов смысла не было. Просто интересно, нвидевская документация тоже говорит, что будет быстрее, но вот факты мне еще не попадались.
С одной стороны, это плохо, что не тестируют особо, но далеко не всегда это плохо. Я пришел к тому, что сначала надо всегда делать прототип, не особо парясь о тестах там, главное чтобы работало, а уже потом все с нуля писать красиво и с тестами, если времени хватит на них. Если же времени не хватит, то после написания прототипа обычно получается вполне хорошо даже без тестов (ну кроме совсем уж очевидных ляпов). Причем в прототипе какие-то заботы о тестах = потеря времени. Написание продакшн кода без прототипа = потеря времени на тестировании и отладке. Причем пропускать стадию прототипирования можно только в том случае, если Вы делали точно такую же конкретную задачу недавно. Но, в целом, время на тестирование и хорошую архитектуру себя окупают всегда (для продакшн кода). Каждый это знает, кучу исследований было по этому поводу, но пересилить себя тяжко. Похоже, что точно также курильщикам бросить курить тяжко:)
Эх… вот написали бы они ее на годик раньше...:) Я тогда долго искал хорошую книжку, но пришлось читать мануал и программинг гайд от nvidia. А там не все всегда ясно.
Вы правы, много потоков может быть при любом количестве видеокарт (да и разницы сколько там ядер тоже нет), просто, имхо, наиболее популярный сценарий — поток на видеокарту, хотя я могу и ошибаться.
Как будет время, обязательно продолжу. Рабочий код сейчас показать не могу, но, опять же как будет время, попробую сделать несколько тестовых примерчиков, а то мне самому интересно проверить некоторые вещи. С AMD сложнее… у меня есть кучка карт от nVidia и ни одной от AMD (нвидия как-то добрее, например прислала нам Quadro 6000 бесплатно (при стоимости в несколько килобаксов) для рисерчей). Но если попадется, попробую.
А про сложный и простой код правда. Только вот не так уж много в реальных приложениях этих самых простых алгоритмов, а все сложное уже должно оптимизироваться под каждую архитектуру… тут с до-Fermi на Fermi не перенесешь особо (без потери производительности относительно максимума), а на другую совершенно архитектуру еще хуже.
На чистых видеокартах не имеют… кто-то помню извращался на ферми что-то х86 симулировал, но жутко медленно. А вот использовать GPU как сопроцессор, очень даже хорошо.
Что правда, то правда. Только вот получить больше 6 CPU ядер в среднем компьютере весьма и весьма тяжко, а получить 4 GPU очень даже легко, каждая вторая материнка 2 PCIe слота имеет, куда две GTX590 запихнуть можно за сравнимые (с 6 ядерным процом) деньги.
А если дальше посмотреть, все еще веселее… в плане цен становится…
Для сравнения производительности могу сказать, что GTX580 обгоняет одно ядро i7-2600 раз эдак в 30-130 (все зависит от алгоритма, данных итд итп).
Все несколько интересней на самом деле.
NV compute capability <1.3 (если не ошибаюсь) не умеют работать с double в принципе.
NV compute capability <2.0 Имеют один double блок на мультипроцессорв, в результате у них примерно в 10 раз меньше скорость вычисления double чем single
NV compute capability 2.0 может работать с double в ДВА раза медленнее, чем с single (и это правда для Tesla и Quadro), но производительность GeForce специально ограничена еще в 4 раза, дабы люди покупали Quadro.
Ну а что получится на самом деле предсказать сложно:)
Проблема же заключается в том, что есть третьи люди, которые не понимают, как все устроено, но пытаются писать на Си. Вот тогда возникают трудности. Но я видел, как такие люди и на C#/Java/AS создавали проблемы, ничуть не хуже этого несчастного указателя. С любой технологией надо знать как работать. У каждой есть свои плюсы и минусы. Нельзя сказать, что Си плохой, потому что он позволяет делать ошибки, любой язык это позволяет, не с указателями, так с чем-то еще. Просто в Си, можно делать больше ошибок, как раз потому, что он дает больше возможностей.
В автомобилестроении существует аналогичная проблема: есть просто водители, а есть спортсмены. Просто водителям нужна нянька (всякие разные электронные системы безопасности, которые часто нельзя выключить), которая их может и спасти. Спортсмены же страдают от того, что эту самую няньку часто нельзя выключить и она ограничивает их действия, а может и убить если не повезет. Что лучше? А нет ответа, для простых водителей нужна нянька, для спортсменов — не нужна. А вот для тех, кто думает, что они спортсмены (но ими не являются), часто нужна лишь скорая.
Есть три возможных непонятности:
1) Что такое правдивость? Как она появляется и как связана с вероятностью, если связана?
2) Можно ли сказать, что нечеткая логика может включать в себя вероятностную модель, когда правдивость равна вероятности в тот момент времени, когда принимается решение?
3) Если предыдущее не верно, то как правильно применить нечеткую логику к задаче про пешехода? Возможно ли это в принципе? (Должно быть возможно, с обычной бинарной логикой я могу сказать просто, машина исправна И водитель видит = надо идти, но я теряю часть информации)
А, вообще, вот оно будущее — бесплатная видеосвязь по всему миру.
Я не совсем понимаю почему нельзя применять в этом случае нечеткую логику. Есть вероятность события — водитель видит пешехода. Но в то же время есть высказывание «водитель видит пешехода», оно может быть правдой или ложью в каждый момент времени: водитель либо видит, либо не видит, только вот мы не знаем ответа на него, знаем только то, что водитель чаще видит. Поэтому это высказывание правдиво в этот момент времени с этой самой вероятностью 70%. В чем тут ошибка?
Представим, что есть пешеход, который планирует переходить дорогу на пешеходном переходе. В это время к пешеходному переходу приближается автомобиль.
Человек должен принять решение: начать переходить или стоять.
Машина может остановиться или проехать. Это зависит от 2 факторов: исправна ли машина (технически может остановиться) и видит ли водитель пешехода.
Предположим, что вероятность поломки машины 1% (т.е. в каждый момент времени у нас есть 1 шанс из 100 на то, что тормоза откажут, не очень хорошая машина. Можно взять реальные числа, рассчитанные исходя из времени наработки на отказ тормозов машины, но они будут маленькими и неудобными).
Вероятность того, что водитель не заметит пешехода 30% (т.е. есть в 3 случаях из 10, водитель просто не замечает пешехода, проезжая по этой дороге, а вот это число уже весьма реально, особенно вечером).
Итак, нам надо решить, что должен делать пешеход.
Вероятностная модель нам дает следующее: вероятность остановки машины равна 0,7*0,99 = 0,693 = 69,3%
Решение пешехода зависит от того, насколько он хочет жить. Если он хочет остаться в живых (считаем, выжить после аварии у него не получится) с вероятностью 95% (вполне нормальное желание), он должен ждать. Тут мы не рассматриваем то, что машина начнет останавливаться и это будет значить, что повысились шансы на то, что водитель видит пешехода, тогда решение может поменяться.
Нечеткая логика дает следующее: для того, чтобы перейти, нам надо знать, что машина остановится. Машина остановится если выполняются оба условия: она исправна и водитель видит пешехода. Правдивость того, что машина исправна 0,99, правдивость того, что водитель видит пешехода 0,7. Оператор И определен в статье a && b => a * b. и мы получаем все то же 0,693. Это значение правдивости такого утверждения: «пешеход перейдет дорогу и останется в живых». И тут нам надо делать дефаззификацию, если просто поставить какую-то границу (на сколько хочется жить), то будет точно также, как и с вероятностью. Если же случайно выбрать один из ответов с вероятностью 0,693 и обратной 0,307, то это не дает нам ничего, кроме принятия какого-то решения.
В такой задачке я не совсем понимаю разницы между подходами. Что я упускаю? Объясните плиз. Или может быть они не такие уж разные?
Как она графики выводит? Создает свое окно или куда скажешь?
А вы никогда не пробовали делать какой-нибудь простенький тест? Например посчитать длину вектора нативной функцией и вручную. У меня руки все никак не доходят до этого, да и без 3х компонентных векторов смысла не было. Просто интересно, нвидевская документация тоже говорит, что будет быстрее, но вот факты мне еще не попадались.
А про сложный и простой код правда. Только вот не так уж много в реальных приложениях этих самых простых алгоритмов, а все сложное уже должно оптимизироваться под каждую архитектуру… тут с до-Fermi на Fermi не перенесешь особо (без потери производительности относительно максимума), а на другую совершенно архитектуру еще хуже.
А если дальше посмотреть, все еще веселее… в плане цен становится…
Для сравнения производительности могу сказать, что GTX580 обгоняет одно ядро i7-2600 раз эдак в 30-130 (все зависит от алгоритма, данных итд итп).
NV compute capability <1.3 (если не ошибаюсь) не умеют работать с double в принципе.
NV compute capability <2.0 Имеют один double блок на мультипроцессорв, в результате у них примерно в 10 раз меньше скорость вычисления double чем single
NV compute capability 2.0 может работать с double в ДВА раза медленнее, чем с single (и это правда для Tesla и Quadro), но производительность GeForce специально ограничена еще в 4 раза, дабы люди покупали Quadro.
Про AMD не знаю.