@WebRion

Собсно, языки развиваются, появляются новые, но все изменения и новшества какие-то довольно простенькие.
Почему нет подобного языка?

Представьте себе какбы было бы удобно написать например что-то вроде:

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

0

@Neter

castorsky, зато преобразование строк из примера в начале этой ветки осуществляется проще простого.
А, по-моему, именно это ищет WebRion.

0

@castorsky

Вы не поняли. Автор выделяется религиозным фанатизмом.

0

@WebRion

Касторский, вы меня достали, честно. Идите со своим ЛИСПом в соответствующую тему.

0

@castorsky

Эта ветка называется "теория и практика программирования". Так что это Вы идите со своим сиплюсплюсом в соответствующую тему и скажите "мне надо символьные вычисления на крестах!". Только боюсь что Вас опять отправят в лисп раздел. А если попадутся бездари (коими тот раздел кишмя кишит) то будут в угоду Вашим фантазиям размышлять о том как чесать левое ухо правой пяткой.

0

@WebRion

Вы слишком низкого мнения о себе.

0

@Ev_Hyper

WebRion, так на то он и ЯП, чтобы вы сделали сами то, что вам нужно

0

@aedeph

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

http://web.info.uvt.ro/~oarito... ompile.pdf

0

@Shamil1

ТС так и не дал внятного объяснения, какую фичу он хочет.
Исходя из тех объяснений, что я видел, я не могу даже сделать вывод, полезная это фича или вредная.

В частности, из первого примера мне не ясно:
- какие требования к функции getArea (какие конструкции языка в ней можно использовать?)
- что делать, функция find не найдёт решения или найдёт несколько решений или не существует символьного решения
- как мне взглянуть на внешний вид результата (например, чтобы принять решение, стоит ли кэшировать результат или промежуточные результаты)
- что делать, если мне не нужна функция getArea, но нужна функция setArea (getRadius)
- что делать, если символьные вычисления занимают много времени (по сути вычисления нужны один раз, а не при каждой компиляции)
... полагаю, в процессе формулировки требований возникли бы ещё вопросы

0

@WebRion

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

Так же как и сейчас реализована компиляция на сях. Компилируются лишь изменения если они есть.

0

@Shamil1

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

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

0

@WebRion

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

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

0

@Shamil1

Если я не умею решать подобные уравнения, то как я узнаю, как выглядит решение, глядя на уравнение?
Кроме того, мне нужно знать, на какой области сколько решений есть.
Что произойдёт, если я вызову функцию setArea с отрицательным аргументом?


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

0

@WebRion

Если вы не умеете решать подобные уравнения, то как вы в ручную собираетесь их решать?

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

Сейчас в сях компиляция происходит при обновлении файла - поменяли что-то в файле, значит будет перекомпилировано. Вроде никто не жалуется. Тут тоже самое.

0

@Shamil1

Я уже писал как: вобью формулу в специализированную программу и получу результат.

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

Как мне догадаться, что функция будет падать на отрицательных числах? Или Вы предлагаете сначала решить уравнение самому "вручную" (на листочке или в специализированной программе), а потом в код программы на С++ вместо решения, которое мне уже известно, вставить уравнение... что займёт столько же времени.

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

0

@WebRion

В какую вобьете? И какой результат - символьный или числовой?

Каким образом вы увидите что на отрицательных будет ошибка - вы собираетесь функцию sqrt писать?

А как вы сейчас догадываетесь что sqrt падает на отрицательных числах не видя тела функции?

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

Причем здесь класс? Вам и так и сяк компилировать его придется. Потом если вам уж вообще скорость нужна, то кешировать можно и по функциям. В IntelliJ IDEA вообще код компилиться налету - что-то поменял, сразу увидел ошибку.

0

@Shamil1

Лично я запущу http://www.wolframalpha.com/
Тот, кому это реально часто требуется, запустит что-то покруче - марпл, математика и т.п. - я не знаю, так как не разбираюсь в этом
Разумеется символьный результат. Зачем мне числовой, если я, фактически, составляю алгоритм решения задачи.

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

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

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

1

@WebRion

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

Ну так и здесь посмотрите и почитаете.

Тут не понял. Ладно, проехали.

0

@Shamil1

Я уже писал: "Я знаю про многие функции их область определения. А про которые не знаю, могу в инете посмотреть."

Вы когда-нибудь писали программы?
Если да, то каким образом Вы выбирали подходящий алгоритм?
Вот и тут примерно так же. Ведь, как я уже писал, по сути это этап составления алгоритма.
В разные дни выбор может быть разным. Иногда ищешь по-быстрее, иногда по-проще и так далее.

Вы сравниваете две вещи: "узнать область определения функции" и "узнать, какие решения могут быть у уравнения, которое я не могу даже классифицировать".
Я уже писал: "Или Вы предлагаете сначала решить уравнение самому "вручную" (на листочке или в специализированной программе), а потом в код программы на С++ вместо решения, которое мне уже известно, вставить уравнение... что займёт столько же времени."

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

0

@WebRion

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

Да, 15 лет уже. Вы и сейчас не выбираете алгоритм sqrt - он для вас "черный ящик". Хотя лет 30 назад - выбирали бы.

Откуда взялась бесконечность?? Если количество правил преобразований - конечно.

0