wessen MasterZiv wessen[quot MasterZiv]Один такой вызывал уже, SUN потом его по судам затаскала ...

Ну, получается, что да. Microsoft в своем J++ написал кучу классов для вызова native функций WIN32 API. SUN за это ... ну вы наверное знаете, что дальше было.
Я думаю, что за написание классов с вызовом native функций никто вам ничего не скажет, хотите пользуйтесь, хотите нет. Насколько я помню, M$ сделал так, что если я написал код на Жаве без их классов и скомпилил его в J++, то в байт код, все равно всавлялись вызовы native функций и в результате программа работала только под винду, а это не есть хорошо. Поправте если я не прав.


Суть в была в другом, в MSJVM была ВСТРОЕННАЯ поддержка ms-классов. Т.е. не нужно было передавать их ввиде либов к программе. А это уже нарушение стандартов jvm.

Давайте попорядку :)

c127 >В java переменная "указывает на объект и только"
В Си/Си++ указатель это просто адрес ячейки в "памяти"
В чём разница "указателя в смысле Си" и "java" ясно?

Я же говорил, Вы просто не знаете C/C++, отсюда постоянные ляпы. В качестве ликбеза попробуйте завести переменную типа указатель на double, добавить к ней единицу и сравнить оригинальное значение переменной с полученным. В очередной раз будете удивлены.


Мило. Очень мило.
Ляп тут только один - вы :) Особенно если начнёте, после ваших же слов и дальше утверждать, что указатели java и си одно и тоже.


Указатель это не просто тип данных, это концепция программирования, в процедурных языках так точно.

О! Неужели вы это стали понимать? Что указатели это навязанная от процедурных языков концепция, абсолютно не нужная при объекто-ориентированном подходе?



Вот и джависты не могут ничего объяснить, не прибегая к понятию указатель. Попробуйте рассказать о создании связанного списка не прибегая к этому понятию. О какой логичности языка можно говорить, если студенты, начавшие обучение программирования с джавы и прослушавшие курс алгоритмов на ее основе, потом не могут могут разобраться в том, что там происходит и в результате не могут построить этот разнесчастный список. Это примеры из жизни причем речь далеко не о самых плохих студентах.

А вас не удивляет, что люди прослушавшие курсы мат.анализа не могут потом доказать не одной теоремы? :)



>О памяти требуется знать одно: сделаешь новый объект - свободной памяти станет меньше :)

Этим студентам, судя по всему, так и объясняли. А теперь в том же духе расскажите о связанных списках.

Что вы как маленький на самом деле. Когда рассказывают о списках, рисуют картинки, где обозначены объекты и связи между ними. Где там нужна память и с кучей адресов? :)


Надоело повторять: тип указатель в джаве остался, только указатель получился кастрированный. Нельзя к нему добавить единицу, так это и было его основным свойством, от этого указатель указателем быть не перестал, он по-прежнему указывает на область памяти определенного размера.

Вы не представляете, как мне надоело слушать :)
"Кастрирован" он ровно на столько, что бы выполнять функцию "указания на объект" (вспомните стрелочки на рисунках, указатели поворотов, компас).

То что вы называете "по-прежнему указывает на область памяти" - это детали рализации VM. Она(VM) за тем и нужна, что бы скрыть от программиста технические детали (тот же принцип заложен в ОS - избавить пользователя от общения с примитивными сущностями железа, позволить ему всё делать "мышкой").

Вас же, обозначенный факт почему-то сильно задевает.


>О каких результатах речь-то?

О результатах всеобщей компьютерной грамотности. Кроме PC студенты ничего не знают, да и PC с трудом.

Со всем, что вы перечисляли в постах выше лично я знаком. Может мне не давелось писать машинные коды для дикабразов не оправдавших себя или созданных ради спортивного интереса, но это ничего и не значит.
За ваших абстрактных "студентов" ничего сказать не могу.


>Китай не аргумент, а пример.

Неудачный пример. Приведите удачный.

То что в ВАШЕЙ голове китай - это несчастные воробушки, это не моя не удача :) Хотите больше примеров обратитесь к литературе о которой я уже упоминал. Не давно вышло ещё три книжки. Издаёт издательство "радиотехника", оно же издаёт журнал "нейрокомпьютеры".


>Давайте-давайте. У демон у вас поди дома сидит?
А сети успешно работают :)

Так и работает демон не хуже сетей, об том же и речь: результаты аналогичны.

Результаты не аналогичны. Демон фантазия человека, нейросети реально существуют и очень не плохо работают.


>Кто многие? Если доморощенные специалисты - то не удивительно.
У нас их нет, практически нет.
Это не у "нас", это у "них".
>Остаётся мировой опыт,
Во-во, об ем и была речь.

Что касается доступа к "их опыту", то в россию этот краник прекрыт.



>Нейросети это наука, нельзя придти со стороны, узнать основные концепции и сказать - я профи.

Чтоб стать профи основных концепций может и недостаточно, но чтоб разобраться что наука относится к разряду втирания очков обывателю, основных концепций может хватить вполне.
Уважаю основательный подход к вопросу.
Переубеждать вас желания не имею.
Удивлён только, что вы так и не привели общеизвестный "факт" несостоятельности нейронных сетей обнаруженный в 60-х годах, после чего был почти 20-ти летний период когда ими почти не занимались.

c127Вместо "Нельзя к нему добавить единицу, так это и было его основным свойством"
следует читать: "Нельзя к нему добавить единицу, так это и не было его основным свойством"
Об том и речь. В сях есть избыточность обусловеленная его универсальностью.
Без многих вещей можно счастливо жить.



Подумал, осознал аспект. Теперь вопрос. То, о чем Вы говорите (понижение алгоритмической сложности) есть результат чисто теоретический, совершенно строгий и не требует наличия работающего нейрокомпьютера. Этот результат получается на бумаге. Иными словами чтоб говорить то, что говорите Вы нужно этот результат иметь. Вот и дайте ссылку или приведите тут доказательство того, что нейрокомпьютер или нейронная сеть решает хоть какую нибудь задачу за меньшее время, чем классическая архитектура.
[/quot]

Книга 6 "Нейроматематика" (из серии "Нейрокомпьютеры и их применение").
Глава 2. "Нейросетевые алгоритмы решения алгебраических задач".
Задача: сложение двух двоичных чисел. Сложность задачи o(n) n - число бит.
Нейросетевое решение: двухслойная сеть без обратных связей. Приведён алгоритм вычисления весов и алгоритм построения сети для произвольного n.
Результат сложения получается за один "такт", не зависимо от значения n.
Доказательство работоспособности элементарное. Приводить рисунки не буду.
Ссылку на источник дал.

Промоделировав сеть в МатЛаб'е, можно убедиться, что никто не врёт, - сеть работает. Железо для построения сетей тоже существует (но главным образом "у них", в том числе и у китайцей, благо есть дешёвая промышленная база)

c1271) джава имеет некие загадочные свойства революционного характера, существенно облегчающие написание программ в сравнении с C/C++. В результате дискуссии выяснилось, что наличие сборщика мусора, в принципе сокращающего и упрощающего код с лихвой компенсируется отсутсвием нормального механизма обмена данными с подпрограммами. Таким вполне логичным представляется экспериментальный результат, что джава код получается длиннее и сложнее, а программисты тратят больше времени на его разработку. Этот эффект небольшой, но есть.

2) джава имеет некие не менее загадочные свойства, облегчающие его использование в качестве языка разработки интернет приложений. В пользу этого вообще не было высказано никаких аргументов, кроме наличия библиотек. Кстати библиотеки всплывают постоянно, но библиотеки дело наживное.


-- Не существует в ООП подпрограмм :) Есть объекты и их методоы.
Сравнивать процедурный стиль написания кода и ОО - бессмысленно.

-- Использовани любой новой технологии по началу идёт не эффективно. Особенно, если изучают её "за неделю".

-- Что лежит за словами сокращение кода? С точки зрения синтаксических конструкций, на С++ можно писать более сжато, это результат наследния от процедурного языка С. Но кол-во кода которое придётся написать на java, в общем случае "будет меньше", за счёт наличия отличных библиотек. В итоге выйгрыш в размере кода. (Подразумевается написание приложения с нуля. Если уже 90% требуемого кода написано предыдущей командой разработчков для смежного проекта на С++, то дописать ещё 10% на том же С++ в кучу раз выгоднее, чем с нуля переписывать всё на java (хотя смысл в этом всё же есть, если смотреть в будущее :)).

-- В результате дискусси выяснилось, что в java избыточности усложнаяющих написание кода и позволяющих писать уродский код. Никто не избавит программиста от сложности решаемой задачи "самой по себе".

-- Большой пласт решений уровня копроративных приложений и серьёзных веб приложений вынесен в java frame work'и. Это как технологии J2EE, так и продукты других разработчиков. (Фактически этот процесс представляется как стандартиция удачных решений, что избавляет от изобретения велосипедов во многих группах разработчиков)


-- Всё что реализованно на java, можно реализовать на C++. Даже работать будет быстрее. Если напрячся, то даже не нескольких платформах.
Однако, такая потенциальная возможность, не может заменить реальности. А реальность такова, что на это уйдёт огромное кол-во труда, времени и денег.
(Повторюсь, если "труд, время и деньги" не потратили команды разработчиков занимаясь в смежной области. Халява, она и есть халява.)


С первых дней cуществования java говорится, что это не язык, а платформа, со всеми вытекающими из этого следствиями.

kompotFXМожет и не к теме, но я заметил что c++ програмисты больше и охотнее разбираются в другрих языках - в той же джаве, вб или шарпе, чем джависты в си, вб или шарпе... Это я по своей команде сужу. У нас пацаны во всем шустрят по зову партии и приказу шефа. Но вот два джава-профика как то фанатично упираются - типа пусть через жопу но чтоб в jave.
Ну а вобщем они пацаны нормальные, только вот кофе пьют литрами.
Вообше, это как-то связано (кофе и джава) ? (У них вроде-как даже на эмблеме это нарисовано...)

Естественно, если в зиму по нужде бегать в сортир на улице, то удовольствием будешь ходить на любой горшок по теплее, а вот наоборот... :)

Java - cорт кофе. Beans - зёрна. jar - банки (с кофем). - вся эта терминология живёт в языке :)

c127Это, надо понимать, из собственного опыта. А программировать Вы тоже картинками будете?

Программировать я буду на Java пока за это не плохо платят :)
И что вы имеете ввиду под словами "собственный опыт"?
На ваш вопрос я целиком и полностью ответил.


Потому я и говорю: вот они, результаты повальной компьютерной грамотности. Количество обученных не переходит в качество подготовки отдельно взятого индивидуума, он ничего не знает и ничего не умеет.

Поэтому это почему? :)
Слишком много утверждений на пустом месте выстраиваете.


> Удивлён только, что вы так и не привели общеизвестный "факт" несостоятельности нейронных сетей обнаруженный в 60-х годах, после чего был почти 20-ти летний период когда ими почти не занимались.

Процитируйте плз, только точно, а то я уже подзабыл где я такое говорил.

???
Вы и не говорили, в том то и дело :) Для вас этот факт не знаком, хоть вы и кичитесь своей "граммотностью".


> -- Не существует в ООП подпрограмм :) Есть объекты и их методоы.

А в C нет процедур, есть функции. И что это меняет? Хоть горшком назови, процедуры останутся процедурами.

Именно поэтому многие используют ОО С++ как процедурный язык, только прикрываясь понятием ОО. Это не мои слова, но вы меня в них убеждаете.
Видимо трудно всё-таки понимать новое, если старое всё ещё работает.


> Сравнивать процедурный стиль написания кода и ОО - бессмысленно.

Это Вы сами придумали, или кто-то подсказал? Интересно услышать хоть какую-нибудь аргументацию на сей счет.

А что вас здесь смущает?
Там где не нужно ООП, там не нужна Java.
А там где приминение ОО подхода оправданно, выйгрыш будет совсем другого порядка, чем от написанного на треть короче кода.
Поэтому хотите сравнивать - сравнивайте. Можете даже сравнить C++ с js и html. Но только без моего участия.


Мой аргумент все тот-же: время и усилия (длина кода), затраченные программистом на создание программы. По этому критерию очень даже можно сравнивать ООП, функциональное, логическое, процедурное и всякие другие программирования.

Можно, но тема топика от этого не должна меняться, а именно Java vs С++ (а не С).


> - Что лежит за словами сокращение кода? С точки зрения синтаксических конструкций, на С++ можно писать более сжато, это результат наследния от процедурного языка С. Но кол-во кода которое придётся написать на java, в общем случае "будет меньше", за счёт наличия отличных библиотек.

Таким образом Вы согласны с тем, что разница только в библиотеках, а язык сам по себе не лучше, а возможно хуже? Что ЯЗЫК сам по себе не обладает свойствами, позволяющими его использовать эффективнее чем C/C++?

Про что речь? Вроде раз пять уже писал.
Да, ЯЗЫК java не обладает свойствами, позволяющими писать компактнее чем на С, но это не влияет на эффективность ОО языка. "Напечатывание кода" самая малая часть процесса программирования.
Эффективность в данном случае это лёгкость проектирования/реализации/отладки/рефекторинга кода. Юзабилити одним словом. В Java она выше. За счёт чего это достигается, тоже говорилось.
Это простота оо модели, отсутствие процедурных атавизмов.

Да, в задавшись строгими правилами, можно и в С++ писать как на Java, так же красиво и мило. И при этом каждой табуретке объяснять - так нельзя делать, нельзя, хоть синтаксис позволяет - но нельзя.
Антипаттернов связанных с саммим языком в C++ на порядок больше, чем в Java.



Я напоминаю, что мы начали с того, что я сказал, что вместо джавы можно было бы использовать C/C++, дополнив его стандартизированными библиотеками и, возможно, но не обязательно, VM. По-моему Вы сейчас сказали то же самое ("за счёт наличия отличных библиотек").

Я уже отвечал на этот вопрос многократно.
Зачем тащить за собой сложную модель языка, процедурные атавизмы и отсутствие стандартизации туда, где это не нужно. Особенно если учесть концепции автоматической уборки мусора и платформенно не зависимого байткода, которые были заложенны в java. А также что java это платформа программирования, а не язык программирования как таковой. Осмысленное управление развитием этой платформы было бы не возможно, если бы в качестве языка служил бы С++.
java != C++.


> Что касается доступа к "их опыту", то в россию этот краник прекрыт.
Чепуха, все открыто. Только нужно изучать все результаты и не отбрасывать те, что противоречат желаемым.

Об чём базар-то?


> Результаты не аналогичны. Демон фантазия человека, нейросети реально существуют и очень не плохо работают.
Так это ж не те нейросети. У них одинакового - одно название.

Вы про что?
Нейросети это не модели нейронов в голове человека.
Такое мнение это результаты вашей "повальной грамотности", не иначе.

Реальные нейронные сети, реализованные в железе благополучно работают, не зависимо от вашего знания об этом :))


У комара 30 (или 300, не помню) нейронов. Ничтожное число, вполне доступное для моделирования на современных компьютерах. Слабо смоделировать поведение комара своими нейросетями из 300 нейронов? Даже без учета времени реакции системы, чтоб не было отговорок, что компопьютеры медленные. Попробуйте, сразу все встанет на свои места.

Это вообще к чему? Продолжение темы "грамотности"?
Что на какие места встанет? Не позорьтесь.


А если устройтсво имеет переменное количество элементов, то для решения таких задач совсем не нужно изобретать нейроные сети: любой классический сумматор переменной разрядности складывает числа за один или два такта не хуже нейронных сетей, а скорее лучше, ведь такты короче. Но только это НЕ понижение вычислительной сложности и НЕ уменьшение времени решения.

Возьмите задачу коммивояжора, для фиксированного N = 1000. И порешайте.
Возьмите фиксированное кол-во (пару сотен) не линейных диф.уравнений - и порешайте.
А потом увеличте кол-во вершин/уравнений ещё на порядок и подумайте, сколько насколько дольше станет работать ваше решение. И насколько дольше это будет делать нейронная сеть после масштабирования.

Вы уж извините, но разрядность ЭВМ'а тоже не бесконечна. Так же как и у нейросетей.

Лол.
Сумматор говорите, за 1-2 такта?
А как насчёт привести схемку и временную диаграммку (ссылочку)?
Или вы изобрели что-то новое?
http://www.skvozilka.com.ru/electronics/DOCel/shmtechnika_7.htm
На двоичной логике вы получите только o(n) от тактов синхронизации, ограниченных временем переключения одного элемента.
Или под классическим сумматором вы понимаете программирование плиски (хранить 2^n результатов, что бы вернуть за один такт требуемый)?

Но тут-то ладно, задача простая, переключение простенького транзистора на порядок быстрее, чем переключение нейрона. Это лишь иллюстрация принципа о котором вы просили, "helloword" своеборазный.

Для более сложных задач, таких как решение систем нелинейных дифф.уравнений, вы тоже предлагаете делать схемотехническое решение на булевской логике ? :) Времени много или денег? :)


И Вы хотите сказать, что, например, сеть состоящая из 100 (или N, но ФИКСИРОВАННОГО числа) нейронов за один такт сложит и 1000-разрядные числа и 10000 разрядные числа и 100*N разрядные числа?

Не хочу.



Учите матчасть.

Благодарю.


Вопрос остается открытым: "Вот и дайте ссылку или приведите тут доказательство того, что нейрокомпьютер или нейронная сеть решает хоть какую нибудь задачу за меньшее время, чем классическая архитектура."
Дискутировать с вами на тему не интересно. Ничего кроме желания куда-то ткнуть носом с вашей стороны не видно.