Символьный калькулятор на C#

[gnaeus]

А Math.NET Symbolics не подходит для такого?

[ViacheslavMezentsev]

Все современное требует .Net 4.5 и выше, а нужно .Net 2.0, так как SMath Studio минимально поддерживает эту версию. Это если я захочу этим требованиям следовать.
Посмотрел, что-то пока он выглядит хуже по функционалу, чем этот калькулятор, судя по тестам в репозитории.
Мне-то ещё нужен исходник (библиотека), которую я смогу сам дополнять и мне хватит для этого знаний. Этот калькулятор поддерживает загрузку .m-файлов, которые имеет даже у себя в ресурсах, где часть функций реализована в виде пользовательских подпрограмм.

В прочих случаях почему бы и нет. Жаль только, что подобные математические библиотеки содержат только что-то примитивное, а как только надо жёсткое ОДУ посчитать, то обратно к фортрану нужно возвращаться.

[KvanTTT]

Зачем нужна поддержка древнего .Net 2.0?

[ViacheslavMezentsev]

Так сложилось исторически и остаётся до сих пор. Если программа может работать даже только с .Net 2.0, то и дополнения к ней желательно должны поддерживать такую возможность. Это необязательное требование.
Библиотека LinqBridge не нужна для .Net 3.5 и выше, где Linq уже встроен. Просто меняем .Net и удаляем зависимость.

[FoggyFinder]

Да, пока возможностей в Math.NET Symbolics не так и много, но исходники открыты, а код легко читаем. Будет здорово расширить функционал.

Жаль только, что подобные математические библиотеки содержат только что-то примитивное, а как только надо жёсткое ОДУ посчитать, то обратно к фортрану нужно возвращаться.

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

[dimka11]

Использовать C++ библиотеки не вариант?

[ViacheslavMezentsev]

Не вариант. У меня очень богатый опыт подключения неуправляемого кода к c# проекту. Всё выглядит всегда как костыли с побочными эффектами.

Из минусов:
— зависимость от ОС;
— зависимость от разрядности;
— наличие знаний C++/CLI и/или маршалинга;
— сложный состав проекта (зависит от исходников C/C++);
— особые проблемы использования стороннего кода (например, использование неуправляемых указателей на callback функции для всех решателей с пользовательскими функциями или отсутствие дополнительного параметра void * data для пользовательских данных);
— …

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

[Taraflex]

Не пробовали конвертацию байт кода, вместо исходников?
weblog.ikvm.net

[ViacheslavMezentsev]

Не пробовал. В идеале хочется иметь одну Visual Studio и всё остальное, написанное на одном языке и везде работающее. Мечты.
Жаль только, что C# не настолько быстродействующий как C/C++. Между прочим, некоторые конверторы с фортрана на C# очень хорошо себя показали (DotNumerics).

[KvanTTT]

В идеале хочется иметь одну Visual Studio и всё остальное, написанное на одном языке и везде работающее. Мечты.

Чем Rider не устраивает?

Жаль только, что C# не настолько быстродействующий как C/C++.

Какой производительности по сравнению с плюсами там не хватает? Там даже современные векторные инструкции уже поддерживаются (AVX). Хотя с учетом того, что вы до сих пор поддерживаете .Net 2.0, ни о какой производительности не может идти никакой речи.

[ViacheslavMezentsev]

Чем Rider не устраивает?

Так это мечты, а в реальности нужна поддержка C++/CLI и решений вперемешку (C#, C++/CLI). Думается, что только студия это умеет.

Какой производительности по сравнению с плюсами там не хватает?

Такой, чтобы применять в embedded проектах на Linux'ах, например. Пробовали и отказались в пользу Qt

[FoggyFinder]

Жаль только, что C# не настолько быстродействующий как C/C++.

Сейчас ведется активная разработка CoreRT.