Расчет количества комбинаций

В общем фишка такая что
Y может быть 15
X может быть выбран 14

это сложно посчитать в ручную, и хотелось бы запрограммить универсально, чтобы даже если Y=100, X=50 считалось, правдо цифры там будут охрененные!!! Народ, поможите кто чем может. Мона на любом языке программирования, а ещё лучше просто алгоритм

Открой любую книжку по комбинаторике. Можно не открывать, но тогда обрати внимание на то что ты привел в пример:
y1*y2*y3
y1*y2*y4
y1*y2*y5
y1*y3*y4
y1*y3*y5
y2*y3*y4
y2*y3*y5
y3*y4*y5
y4*y5*y1
y4*y5*y2

Можно сгруппировать несоклько другим образом
y1*y2*y3
y1*y2*y4
y1*y2*y5
y1*y3*y4
y1*y3*y5
y1*y4*y5
y2*y3*y4
y2*y3*y5
y2*y4*y5
y3*y4*y5

Подумав прийдем к мысли что это число сочетаний без повторений. Чуть чуть поэкспериментировав над листком бумаги и разными комбинациями x и y. Прийдем к старой доброй формуле.

Число сочетаний k элементов из n = n!/k!(n-k)!

Да фишка в том, что число комбинаций без повторений я расчитать могу, мне надо получить сами комбинации. Вот это я сделать не могу.

>делаем произведения, всего их может быть 10

Я кстати и указал, сколько их может быть. Это рассчитать не сложно. Основным вопросом как раз было получить массив с произведениями этих комбинаций.

А... каюсь невнимательно прочитал :). То есть тебя не страивает банальное умножение всех комбинаций и ты его хочешь ускорить? Если же оно тебя устраивает то посмотри как я сгруппировал элементы.

Там фишка, что я могу получить количество не повторяюшихся комбинаций. Но мне надо получить произведение в каждой комбинации. Основной задачей является получить на выходе массив с результатом до бишь с произвдением всех комбинаций.

Точне с результатом произведения каждой комбинации.

Тобишь 10 уникальных комбинаций - 10 результатов произвдений в каждой комбинации

Кстати мона ещё упростить задачу известно ещё число например 200 при 10 уникальных комбинациях

тогда на одну комбинацию будет приходится 20

тогда в результате надо получить

произвед_комб1*20+
произвед_комб2*20+
произвед_комб3*20+
произвед_комб4*20+
произвед_комб5*20+
произвед_комб6*20+
произвед_комб7*20+
произвед_комб8*20+
произвед_комб9*20+
произвед_комб10*20=???

Вообщем сам скрипт и то что нужно найти по этому адресу

http://bonb.ru/phl/systema.php

Кто захочет помочь ICQ 125328224

произв_комб8*1 это что? я так и не понял.

произв_комб8 - это одна из возможных не повторяющихся комбинаций.

*1 - это число которое получается при делении содержимиого самого нижнего текстового поля на количество комбинаций.

Тобишь это число равномерно распределяется на все комбинации.

Понятно.. то есть оно нас не колышет? Ну тогда нас интересует лишь сумма произведений чисел из сочетаний. Я так понимаю что проблема заключается в том, можно ли как нибудь свернуть эту формулу?

Да, оно вводится пользовтелем, и добавить его к каждой комбинации проблемы не составляет. Вся проблема в том как найти произведения комбинаций.


К примеру.

Есть
--------------
X=2
Y=3
Y1=4
Y2=5
Y3=10
KOL_KOMBINACI=3 (считаем через факториал)
SUMMA=60
SUMMA_NA_ODNU_KOMBINACIU=SUMMA/3
--------------

Y1*Y2*SUMMA_NA_ODNU_KOMBINACIU+
Y1*Y3*SUMMA_NA_ODNU_KOMBINACIU+
Y2*Y3*SUMMA_NA_ODNU_KOMBINACIU = 4*5*20+4*10*20+5*10*20 = 400+800+1000=2200

Вот эти 2200 и надо найти (в смысле уже нашли, но а если X=4, Y=10)
тогда получится KOL_KOMBINACI=210, а тут уже будет в ручную считать очень трудно :-)

Ну в принципе не так много перемноженийвсего то количество сочетаний*количество элементов в сочетаниях. Причем и тут можно использовать рекурсивные формулы для облегчения вычислений. Или время выполнения очень уж критично?

Тока там разделить не на 3, а на Y, но я думаю ты уже догадался. Время большого значения не имеет. Главное чтобы решалось унифицировано, для любых чисел.

Так все ж просто? По всем сочетаниям пробегаешся и находишь произвдеения, по пути их суммируя. Умножаешь на коэффициент. В чем проблема?

К примеру практически, такая задача как:

X=7 Y=15 (6435)
или
X=8 Y=15 (6435)

решаться скорее всего не будет, но мало ли, кому в голову взбредет. Так что надо предусматреть. А как видно 6435, это слишком много комбинаций

Ну поработает машинка немного.. произведет 50000 умножений. В чем проблема?

Проблема в том, что мне не известны сами комбинации. Я не знаю что на что умножать!

function f(m:array of double):Double
begin
sum = 0;
for i=1 to y-x+1 do
begin
to_use = copy_right_part(m,i+1); // копировать правую часть массива чисел начиная с i+1 позиции
sum = sum+m(i)*f(to_use);
end;
return sum;
end

P.S. Мог где то накосячить, нарисовал в уме, не пробовал вычислять.

Хм, щас попробую

Не понял как это
>копировать правую часть массива чисел начиная с i+1 позиции

Понял, щас реализуем.

Тяжко, может начнем с

Функция СчитаемРезультат(Сумма(SUMMA), Тип_Системы(X), Массив_Элементов(Y))
{
Количество_Элементов=размер(Массив_Элементов)






}

Реализовал, получаю стабильный 0, это неправильно :-)

В смысле тяжко? что не так?

Кажись, пока что мы тут с программерами консилиум устроили. Кажись нашли че да как, и в чем проблема. Как сделать. Как только будет готово, скину сюда.

Все вопрос закрыт

http://www.bonb.ru/systema.php

Посмотрел условие. Написал за 15 минут программку и задал ей страшные x=14 и y=15,
смотрю результатов маловато, потом проверил число комбинаций по формуле.

Долго смеялся когда понял, что число неповторяющихся комбинаций при выборе x=14 из y=15 всего равно 15 штук ;-))

Программка на Common Lisp со вспомогательными функциями:

;(setf *y* '(1 2 3 4 5))

;(defun factorial (n)
; (if (= n 0) 1
; (* n (factorial (1- n)))))

;(defun n-combs (n-elts len)
; (/ (fact len) (* (fact n-elts) (fact (- len n-elts)))))

;(defun find-combs (x-depth cur-prod tail fn &optional (f-;num 0))
; (if (= x-depth 1)
; (dolist (e tail f-num)
; (incf f-num)
; (format t "result[~D]=~D~%" f-num (funcall fn cur-prod e)))
; (do ((t-tail (cdr tail) (cdr t-tail))
; (t-head (car tail) (car t-tail)))
; ((null t-tail) f-num)
; (setf f-num (find-combs (1- x-depth) (funcall fn cur-prod t-head) t-tail fn f-num)))))

;(defun concat (lst elt)
; (append lst (list elt)))

;; выдает сами комбинации
(find-combs 3 nil *y* #'concat)
;; выдает результаты
(find-combs 3 1 *y* #'*)

Версия конечно наивная, наверняка можно покороче и попонятнее, но вроде работает. Если рекурсия не устроит, то можно переделать.

Lisper

Форматирование дохнет, повтор.

Кстати данные приведены для выбора из 5 по 3, то есть x=3 y=5

Подчеркивания заменить на пробелы.

(setf *y* '(1 2 3 4 5))

(defun factorial (n)
____(if (= n 0) 1
______(* n (factorial (1- n)))))

(defun n-combs (n-elts len)
____(/ (fact len) (* (fact n-elts) (fact (- len n-elts)))))

(defun find-combs (x-depth cur-prod tail fn &optional (f-num 0))
____(if (= x-depth 1)
________(dolist (e tail f-num)
____________(incf f-num)
____________(format t "result[~D]=~D~%" f-num (funcall fn cur-prod e)))
________(do ((t-tail (cdr tail) (cdr t-tail))
____________(t-head (car tail) (car t-tail)))
____________((null t-tail) f-num)
____________(setf f-num (find-combs (1- x-depth) (funcall fn ur-prod t-head) t-tail fn f-num)))))

(defun concat (lst elt)
____(append lst (list elt)))

;; списки всех комбинаций по 3 из 5
(find-combs 3 nil *y* #'concat)
;; результаты произведения всех комбинаций
(find-combs 3 1 *y* #'*)

Lisper

По прежнему пропагаднируешь LISP?

А почему бы и нет. Он как раз хорошо приспособлен для решения таких задачек. Естественно Common Lisp, так как всякие AutoLisp существенно не дотягивают по многим параметрам.

Не согласен :). Тут слишком простой случай, чтобы прибегать к лиспу, вполне можно было бы обойтись чемнибудь стандартным. Вот если бы существовало с десяток доп.условий, то лисп бы получил преимущество.

P.S. Интересно, а что ты думаешь скажем о PROLOG?

Лисп и так стандартный, ANSI Common Lisp называется. Лисп имеет преимущества практически в любом случае, никаких доп. условий не надо.

Кстати то что в моем решении используются списки не значит, что я не могу использовать массив, но списков для этой задачи достаточно.

И что общего у Common Lisp и Пролога ? Разве что на Лиспе можно реализовать Пролог в качестве встроенного языка и использовать его в некоторых частях приложения (что и делают крупные вендоры реализаций Common Lisp). В общем пока ничего не думаю о Прологе.

В 9 случаях из 10 спорящие лишь еще больше утверждаются в своих мнениях :). Черт побери, не зная лиспа так как вы, с вами невозможно спорить.

Best regards.

А дрова на Лиспе слабо будет написать?

Знавал я одну конторку (за бугром), где как-то пытались дрова на Яве писать....

Лет этак 20 назад на Лиспе были созданы и целые операционные системы и дрова тоже были написаны на Лиспе. Почитайте про Лисп-машины, некоторые люди их до сих пор используют.

Что касается современных компьютеров, есть проекты типа LispOS, но дрова на Лиспе скорее всего никто не пишет, да и нафиг это нужно, надо же С/С++ хоть какую-то нишу оставить ;-) По быстродействию с С/С++ расхождение может быть где-то на 30%, на некоторых задачах Лисп обгоняет, используя преимущества компиляции на лету, т.е. дрова вполне можно писать.

Извиняюсь, диалетанский вопрос. А какие коммерческие продукты реализованы на Лиспе. В каких областях он получил применение?
Вот Вы его хвалите, хвалите. А где, кто и для каких реальных задач его использует.
Мне из универовского курса Лисп запомнился языком совершенно неподходящим например для GUI, Web приложений, Application серверов и вообще любых бизнес задач, только для научных целей / и разработки спец алгоритмов, хотя честно говоря я его уже забыл, наверное просто не в теме ...
Ведь помимо самого языка и его парадигмы для коммерческого использования необходима поддержка библиотеками самого разного плана. Есть ли это для Лиспа и в каком объеме?

По поводу быстродействия. А на каких тестах сравнивается? Лисп ведь функциональный язык, а те же плюсы это уже ООП. Было бы интересно посмотреть исходники небольших тестов, чтобы оценить насколько сравнимы алгоритмы, т.е. действительно ли их можно сравнивать.

Ваш вопрос настолько ёмкий, что на него сложно коротко ответить. Попробую как смогу
прокомментировать.

>Извиняюсь, диалетанский вопрос. А какие коммерческие продукты реализованы на Лиспе. В каких

>областях он получил применение?
>Вот Вы его хвалите, хвалите. А где, кто и для каких реальных задач его использует.

Ссылки:
http://www.franz.com/success - (англ) страница историй успеха
одного из ведущих вендоров Common Lisp
http://www.lisp.org/table/applications.htm - (англ) перечень приложений, написанных на Лиспе
http://www.lisp.org/table/good.htm - (англ) обзор, для чего хорош Лисп

http://www.paulgraham.com/paulgraham/avg.html - (англ) статья о суперуспешном применении Лиспа
для генерации интернет магазинов. Вообще советую
почитать все, что есть на сайте.

http://www.paulgraham.com/iflisp.html - (англ) короткая статья о том, почему Лисп не популярен
и вроде бы нигде не используется.

http://www.lispworks.com - страница еще одного ведущего вендора реализаций Common Lisp

Цитата:
"...Please don't assume Lisp is only useful for Animation and Graphics, AI, Bioinformatics, B2B and

E-Commerce, Data Mining, EDA/Semiconductor applications, Expert Systems, Finance, Intelligent

Agents, Knowledge Management, Mechanical CAD, Modeling and Simulation, Natural Language,

Optimization, Research, Risk Analysis, Scheduling, Telecom, and Web Authoring just because these are

the only things they happened to list." - Kent Pitman

http://lisp.narod.ru/msg.html - (рус) хорошая подборка заблуждений относительно Лиспа, среди
которых "Лисп - это язык функционального программирования".

>Мне из универовского курса Лисп запомнился языком совершенно неподходящим например для GUI

Интересно почему ?

Например Пример описания окна диалога с полем для ввода и списком строк:

(contain
(make-instance 'column-layout :description (list
(make-instance 'text-input-pane)
(make-instance 'list-panel :items
'(first second third)))))

Мне кажется очень удобной библиотека CAPI (Common Application Programmer's Interface)
в одной из коммерческих реализаций Common Lisp (http://www.lispworks.com). Все удобно
и логично, очень смахивает на программирование GUI в Java, однако количество строк кода
требуется поменьше.

> Web приложений

Читайте http://www.paulgraham.com/paulgraham/avg.html и надеюсь измените свое
мнение. Потому что, IMHO Лисп как раз в этой области имеет самый большой потенциал.

> Application серверов и вообще любых бизнес задач.

Странно, но похоже Лисп как раз идеален для Application серверов. Вы можете поменять любую
функцию или класс прямо в работающем в данный момент приложении без его остановки. Вы можете

добавлять функциональность в приложения 24x7 без всяких доп. интерфейсов и сложных компонентных

моделей.

>, только для научных целей / и разработки спец алгоритмов, хотя честно говоря я его уже забыл,

>наверное просто не в теме ...

Он просто хорошо подходит для сложных и особенно неизведанных задач. Но это же вроде плюс ???

>Ведь помимо самого языка и его парадигмы для коммерческого использования необходима поддержка

>библиотеками самого разного плана. Есть ли это для Лиспа и в каком объеме?

Есть много всего всего, особенно у коммерческих вендоров. Хотя недавно был топик, в котором
пришлось признать, что например для разработки риал-тайм 3D движков для игр маловато поддержки,
но одна из известных компаний умудрилась разработать свой специальный компилятор (GOAL), написать

суперский движок и создать игру на нем (для приставок!!!, у которых очень жесткие ограничения
на память и другие ресурсы):

http://www.franz.com/success/customer_apps/animation_graphics/naughtydog.lhtml

Более того они написали на нем множество инструментов для создания будущих игр и
активно используют Лисп для предвычисления оптимальных параметров отображения сцен
по множеству характеристик.

Когда они после очередного проекта разбирали недостатки и преимущества, то выяснилось, что

единственным недостатком такой технологии в сущности являлся плохой менеджмент проекта, который

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

Получилось что один спец писал и компилятор и движок (год на компилятор и 2 года на игру), но они

вышли с игрой точно в срок и пишут, что этой точности они обязаны таки Лиспу.

По поводу использования Common Lisp в распределенных вычислениях и кластерных архитектурах
хорошая статья про ITA Software http://www.paulgraham.com/carl.html

>По поводу быстродействия. А на каких тестах сравнивается?

На всяких. Например разбор регулярных выражений, CL-PPCRE ощутимо перегоняет PERL (зависит
от реализации Common Lisp).

Честно говоря, виндовые реализации Common Lisp на примитивных тестах уступают оптимизированному
С/С++ побольше, чем на 30%, но это можно преодолеть по правилу 20/80 и оптимизировать критические
участки кода получше или сменить алгоритм (Лисп хорошо подходит для быстрой проверки идей).
Некоторые реализации транслируют в Си и требуется просто подобрать хороший компилятор (g++ из
Cygwin не выдержал соревнования с компилером из VStudio 7.1

Я из баловства сравнивал на простеньких тестах вроде сложения всех элементов матрицы 1000x1000
и бинаризации и у меня получилось расхождение порядка: VС++ ~1.5 ms. - CMU Common Lisp ~1.6 ms.
g++ выдал результат за ~14 ms (тот же результат из аналогичной программы на Лисп, транслированной
в Си ~14 ms).

>Лисп ведь функциональный язык, а те же плюсы это уже ООП.

"А мужики-то не знают!" (Цитата) У Вас явно недостаток информации по этому вопросу.
Для улучшения кругозора, наверное стоит ознакомиться с несколькими языками (помимо С++),
в первую очередь рекомендую посмотреть OCaml (http://caml.inria.fr) ,
Haskell (http://www.haskell.org) или Clean (http://www.cs.kun.nl/~clean).
Вы увидите, что ООП и ФП никак друг другу не противоречат и что объектно-ориентированный
подход не панацея, а средство имеющее свою ограниченную область применения.

Оба Ваших утверждения как минимум наполовину не верны:

1) Common Lisp - это язык поддерживающий множество парадигм программирования и Вы можете
реализовать и проверить на нем свою собственную новую парадигму. ФП, ИП, ЛП, АП, ООП - это
не полный список парадигм, которые поддерживает Лисп. Более того Лисп был первым ООП языком,
который был стандартизирован ANSI и по сей день его объектная система CLOS вне конкуренции.
Кстати Лисп - это не язык, это семейство языков, в котором помимо Common Lisp есть например
Scheme.

2) C++ - это гибридный язык и реализация идей ООП в нем мягко говоря не блестящая.
Гибридную суть С++ можно выразить фразой: "С++ is answer, what was the question ?".
Например в Common Lisp из коробки доступна множественная диспетчеризация и специализация
методов на конкретном экземпляре объекта, а также такая рулезная вещь как МетаОбъектный
Протокол (MOP), которая позволяет менять свойства классов, представляя их экземплярами
метаклассов и тем самым добавлять функциональность полностью отогонально имеющейся.
Как в C++ получить и использовать указатель на виртуальный метод ? Я знаю, что все можно
сделать/имитировать, но IMHO обертки над этими имитациями в С++ довольно тяжелы, не очевидны
в использовании (Boost, Loki, Lisp++) и не идут ни в какое сравнение с тем, что можно сделать,
используя макросы Common Lisp.

>Было бы интересно посмотреть исходники небольших тестов, чтобы оценить насколько сравнимы

>алгоритмы, т.е. действительно ли их можно сравнивать.
Честно говоря, меня уже достали сравнения микроэффективности (хотя она тоже важна).
Будь все реализации Common Lisp даже в 10 раз тормознее на каких-нибудь операциях (некоторые

реализации тормозят на массивах), я бы все равно его выбрал по причине кучи других преимуществ,

среди которых есть не встречающиеся ни в каком другом языке:

a) Макросы (не путать с макросами С/С++, в Common Lisp макросы - это программы для написания

программ). Благодаря этому, CLOS сам написан на Common Lisp (и большая часть Common Lisp тоже)
Например в стандарт Common Lisp включен (один из имеющихся) языков для описания итеративных
алгоритмов. Простенький примерчик:


(loop for E across Array
when (> E 0)
sum E into My-sum
when (evenp E)
collect E into Even-list
finally (return (values My-sum Even-list)))

Суммирует все числа больше нуля (любого типа) из массива Array,
составляет список четных чисел и, в итоге, возвращает оба значения.

Весь синтаксис этого языка итераций написан на Лиспе и Вы также можете создать свои
встроенные языки вроде Common SQL, поставляемого вместе с LispWorks:

(select [person_id] [person surname] :from [person])
(connect "personnel")

;(with-transaction
; (insert-records :into [emp] :attributes '(empno ename job deptno) ;

; :values '(7100 "ANDERSON" "SALESMAN" 30))

(update-records [emp] :attributes [deptno] :values 50 :where [= [deptno] 40])
(delete-records :from [emp] :where [> [sal] 300000]))

Примечание: в Common Lisp функция и вообще любое вражение может возвращать
несколько значений одновременно, при чем любое выражение концептуально всегда
возвращает результат, даже если он NIL, то есть все выражения можно использовать
как конструкции типа y = x > 0 ? 0 : x в Си. То есть в переводе на С++ в Common Lisp
возможны такие вещи как:

T sum_elts = { int i; T sum; for (sum=0,i=0;i

Ну во-первых большое спасибо за столь развернутый и подробный ответ.

Я просто не обладаю сейчас достаточным временем, чтобы прочитать все статьи, ссылки на которые Вы
выложили. В любом случаю в свободное время я это сделаю, так как похоже Лисп на самом деле заслуживает
внимания. И Вы мне подкинули интересную информацию, расширили кругозор, я например узнал что Лисп используется
в качестве скриптового языка для Автокада. Что либо существенное сказать по Лиспу пока просто не могу,
так как повторюсь - я просто не в теме.

>>Мне из универовского курса Лисп запомнился языком совершенно неподходящим например для GUI
>Интересно почему ?

Наверное в силу того как излагали курс. Насколько я помню на примере Лиспа мы изучали функциональное
программирование. Может быть поэтому.

>Мне кажется очень удобной библиотека CAPI (Common Application Programmer's Interface)
>в одной из коммерческих реализаций Common Lisp (http://www.lispworks.com). Все удобно
>и логично, очень смахивает на программирование GUI в Java, однако количество строк кода
>требуется поменьше.

Это интересно. Я тут мин за 20 написал небольшой примерчик ГУИ на джаве - окошко, в котором по краям
движется квадратик. Кликая на него мышкой полчаем попап с его координатами. Мне кажется этот пример
показателен - работа с рисование, обработка событий мыши. стандартные сообщения. 90 строк. См. аттач.
Интересно сколько подобный пример занимает на Лиспе.

>Странно, но похоже Лисп как раз идеален для Application серверов. Вы можете поменять любую
>функцию или класс прямо в работающем в данный момент приложении без его остановки. Вы можете
>добавлять функциональность в приложения 24x7 без всяких доп. интерфейсов и сложных компонентных
>моделей.

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

> Он просто хорошо подходит для сложных
В любой сфере есть сложные задачи. Не думаю, что для всех сложных задач подходит Лисп :).
> и особенно неизведанных задач. Но это же вроде плюс ???
Я бы сказал, что это скорее не плюс, а специфика.

>Ведь помимо самого языка и его парадигмы для коммерческого использования необходима поддержка
>библиотеками самого разного плана. Есть ли это для Лиспа и в каком объеме?

>> Есть много всего всего, особенно у коммерческих вендоров. Хотя недавно был топик, в котором
>> пришлось признать, что например для разработки риал-тайм 3D движков для игр маловато поддержки,
>> но одна из известных компаний умудрилась разработать свой специальный компилятор (GOAL), написать

Особое место занимает стоимость коммерческих продуктов. Доступность -> массовость -> качество и большое
количество разнообразных библиотек.

>Лисп ведь функциональный язык, а те же плюсы это уже ООП.
> Вы увидите, что ООП и ФП никак друг другу не противоречат

Что значит не противорчат. Разные же подходы к программированию. Можно например на Java
писать как на C используя только статические методы при желании :). Но мы же про другое.

> 1) Common Lisp - это язык поддерживающий множество парадигм программирования и Вы можете
> реализовать и проверить на нем свою собственную новую парадигму. ФП, ИП, ЛП, АП, ООП - это
> не полный список парадигм, которые поддерживает Лисп. Более того Лисп был первым ООП языком,
> который был стандартизирован ANSI и по сей день его объектная система CLOS вне конкуренции.
> Кстати Лисп - это не язык, это семейство языков, в котором помимо Common Lisp есть например
> Scheme.

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

> 2) C++ - это гибридный язык и реализация идей ООП в нем мягко говоря не блестящая.
> Гибридную суть С++ можно выразить фразой: "С++ is answer, what was the question ?".
> Например в Common Lisp из коробки доступна множественная диспетчеризация и специализация
> методов на конкретном экземпляре объекта, а также такая рулезная вещь как МетаОбъектный
> Протокол (MOP), которая позволяет менять свойства классов, представляя их экземплярами
> метаклассов и тем самым добавлять функциональность полностью отогонально имеющейся.
> Как в C++ получить и использовать указатель на виртуальный метод ? Я знаю, что все можно
> сделать/имитировать, но IMHO обертки над этими имитациями в С++ довольно тяжелы, не очевидны
> в использовании (Boost, Loki, Lisp++) и не идут ни в какое сравнение с тем, что можно сделать,
> используя макросы Common Lisp.

О реализации ООП в C++ можно много спорить :). То что он гибрид мне не нравится самому
(это чисто субъективно). Но это его особенность, в этом есть и плюсы и минусы.


С уважением
Лестор

> Переопределение любой части кода на лету прямо в работающем приложении

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

В общем, слишком много свободы тоже бывает плохо.

>Это интересно. Я тут мин за 20 написал небольшой примерчик ГУИ на джаве - окошко, в котором по краям движется квадратик. Кликая на него мышкой
>полчаем попап с его координатами. Мне кажется этот
>пример показателен - работа с рисование,
>обработка событий мыши. стандартные сообщения.
> 90 строк. Интересно сколько подобный пример
> занимает на Лиспе.

У меня ушло больше 20 минут, так как я только начал изучать библиотеку CAPI (раньше писал свою библиотеку GUI под Corman Lisp). Опять же можно написать и компактнее и чище, но все же. См. аттач.

> Переопределение любой части кода на лету
> прямо в работающем приложении

>Опасно, ой, опасно... Этим ножом очень легко >порезаться.

Дык когдa в одной из функций найдется малююсенький косяк, а программа уже у клиента на другом конце земного шара, то эта фича как минимум позволит послать клиенту патч размером в 1К и легко закрыть дыру.

>Пример - ООП программы на Java (объекты >основаны на классах, которые сначала пишутся, >потом компилируются) как правило вполне понятны >и работоспособны.
Дык потому что особо фич для метапрограммирования никаких нет. Шаблонов нет, макросов как в Common Lisp нет. Вот и набивай одно и тоже 30 раз.

>Сравнимые по сложности программы на JavaScript
>(объекты основаны на прототипах, которые
>конструируюися на лету) кишат ошибками, и для их
>переделки нужны нетривиальные усилия.
Ну я вообще-то не совсем это имел в виду. А то что можно дописывать на ходу уже работающее приложение - переопределять функции и все что угодно не останавливая приложение. Причем тут понятность кода и прототипы ?

Ну хотя генерация и компиляция кода самими функциями в процессе работы в Commo Lisp тоже возможнa, что может ускорить операции, для которых прекомпилированный запрос будет работать быстрее, чем интерпретируемый. Но такие вещи применяются там, где без них никак нельзя.

>Ну во-первых большое спасибо за столь
>развернутый и подробный ответ.

You're welcome ;-) Вопрос действительно емкий и я даже со статьями покрыл его всего процентов на 5.

>Я просто не обладаю сейчас достаточным >временем, чтобы прочитать все статьи, ссылки на >которые Вы выложили. В любом случаю в >свободное время я это сделаю, так как похоже >Лисп на самом деле заслуживает
>внимания. И Вы мне подкинули интересную >информацию, расширили кругозор, я например >узнал что Лисп используется
>в качестве скриптового языка для Автокада. Что >либо существенное сказать по Лиспу пока просто >не могу, так как повторюсь - я просто не в теме.

Лиспы повсюду и в очень разных формах, например XML - это просто другое представление S-выражений из Лиспа. В качестве языка программирования общего назначения рекомендую Common Lisp.

>Наверное в силу того как излагали курс. Насколько я помню на примере Лиспа мы изучали функциональное
>программирование. Может быть поэтому.

Да, специфика отечественного преподавания такова. Хотя надо сказать Common Lisp действительно хорошо приспособлен для ФП, но не ограничивается им ни в коей мере.

>Наверное я не совсем правильно высказался. Есть >ли сервера приложений в которых можно создавать
>сервиса на Лиспе. Возможно Лисп потенциально и >неплох, другой вопрос - а можно ли уже сейчас >разрабатывать на нем.
Думаю можно. А какого типа сервисы нужны ?

>Особое место занимает стоимость коммерческих продуктов. Доступность -> массовость -> качество и большое
>количество разнообразных библиотек.

Смотря что делать. Библиотек вроде много, но наверняка чего-то не хватает. Например какие Вас интересуют ?

>Что значит не противорчат. Разные же подходы к >программированию. Можно например на Java
>писать как на C используя только статические >методы при желании . Но мы же про другое.

Не путайте (Императивное программирование vs Функциональное программирование) с (Объектно-ориентированное программирование vs Функциональное программирование). Если первые прямо противоречат друг другу, то вторые вовсе ортогональны и никак не мешают друг другу. См. OCAML (Objective CAML) http://caml.inria.fr/

>Это интересно. Но меня настораживает. Как это из практики уже сложилось, что чем больше универсализм,
>тем неудобнее для конкретных задач.
Главный способ программирования в Лиспе - создавать небольшие встроенные языки, хорошо подходящие к проблеме, поэтому универсализм здесь только на уровне базового языка, а дальше уже конкретика, т.е. язык поднимается к приложению в то время как приложение пишется на этом языке. Таким образом, создаем удобный специализированный язык и решаем конечную задачу на нем, в то же время он будет оставаться тем же Лиспом.

С уважением
Lisper

16 минут и около 70 строк кода на плюсах с использованием библиотеки Qt.
Правда, еще сотня строк сгенерированного кода, но ведь это не учитываем, верно?

Плюс еще одна строка: удаление таймера в деструкторе

Предлагаю пример. Бронирование авиабилетов онлайн.

Допустим крупная авиакомпания хочет предоставлять услугу бронирования авиабилетов
онлайн вместе с расписаниями полетов и т.п.

Нужно сделать как минимум:

набор отчетов
веб интерфейс для клиентов.
рабочее место для продавца.
рабочее место для оператора.
рабочее место менеджера.

на самом деле список неполный.

Реализация клиент-серверного приложения предполагается в следующем виде:

клиентская часть - веб контейнеры - сервер приложений - БД

Клиентская часть может быть как ГУИ так и веб интерфейсом.
Веб контейнеры формируют отчеты, принимает и отправляют запросы клиентов.
Сервер приложений - проводит транзакции по бронированию билетов, извлекает
данные из БД и т.п.

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

Т.е. что нужно (по первой прикидке):

Веб-контейнер, в котором можно писать обработчики HTTP запросов на Лиспе.
Сервер-приложений,
Библиотека по формированию pdf, xls, doc файлов для отчетов.
GUI с html парсером (чтобы менеджер мог видеть html отчеты у себя в приложении)
Библиотека с доступом к различным БД (аналог ODBC или JDBC)
Библиотека для отсылки/приема писем (как минимум smpt и pop3)

Технология для работы ЛИСП в среде веб-приложения: HTTP запросы, пользовательские сессии, авторизация.
Разработка собственного веб-сервера не пройдет для промышленной системы. Слишком много рисков.
Библиотека для парсинга XML.

Технология для работы ЛИСП в среде сервера-приложений: HTTP запросы, пользовательские сессии, авторизация,
создания управляемых сервисов (модуля, которым мог бы управлять оператор например через веб-консоль), транзакционность
распределенных операций, механизма обмена событиями.
Разработка собственного сервера приложений не пройдет для промышленной системы. Слишком много рисков.

К каким вендорам обратиться и сколько нужно заплатить за софт, чтобы сделать такую систему?
Есть ли некоторые стандартные подходы к решению таких задач используя ЛИСП. И есть ли стандарты, которые реализованы у
нескольких вендоров, или у каждого вендора свой API для решения таких задач? Риски сокращаются, если можно менять вендора по ходу выполнения проекта.

С уважением,
Лестор.

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

Надо бы почитать ... Звучит страшно :). Это чтобы что-то делать я для начала должен написать целый язык Пусть и маленький. А если каждый программист начнет писать свой язык, что будет с приложением объем которого хотя бы больше 40-50 тыс строк? Его вообще отладить можно будет?