Комментарии 12
А Math.NET Symbolics не подходит для такого?
Все современное требует .Net 4.5 и выше, а нужно .Net 2.0, так как SMath Studio минимально поддерживает эту версию. Это если я захочу этим требованиям следовать.
Посмотрел, что-то пока он выглядит хуже по функционалу, чем этот калькулятор, судя по тестам в репозитории.
Мне-то ещё нужен исходник (библиотека), которую я смогу сам дополнять и мне хватит для этого знаний. Этот калькулятор поддерживает загрузку .m-файлов, которые имеет даже у себя в ресурсах, где часть функций реализована в виде пользовательских подпрограмм.
В прочих случаях почему бы и нет. Жаль только, что подобные математические библиотеки содержат только что-то примитивное, а как только надо жёсткое ОДУ посчитать, то обратно к фортрану нужно возвращаться.
Посмотрел, что-то пока он выглядит хуже по функционалу, чем этот калькулятор, судя по тестам в репозитории.
Мне-то ещё нужен исходник (библиотека), которую я смогу сам дополнять и мне хватит для этого знаний. Этот калькулятор поддерживает загрузку .m-файлов, которые имеет даже у себя в ресурсах, где часть функций реализована в виде пользовательских подпрограмм.
В прочих случаях почему бы и нет. Жаль только, что подобные математические библиотеки содержат только что-то примитивное, а как только надо жёсткое ОДУ посчитать, то обратно к фортрану нужно возвращаться.
Зачем нужна поддержка древнего .Net 2.0?
Так сложилось исторически и остаётся до сих пор. Если программа может работать даже только с .Net 2.0, то и дополнения к ней желательно должны поддерживать такую возможность. Это необязательное требование.
Библиотека LinqBridge не нужна для .Net 3.5 и выше, где Linq уже встроен. Просто меняем .Net и удаляем зависимость.
Библиотека LinqBridge не нужна для .Net 3.5 и выше, где Linq уже встроен. Просто меняем .Net и удаляем зависимость.
Да, пока возможностей в Math.NET Symbolics не так и много, но исходники открыты, а код легко читаем. Будет здорово расширить функционал.
Жаль только, что подобные математические библиотеки содержат только что-то примитивное, а как только надо жёсткое ОДУ посчитать, то обратно к фортрану нужно возвращаться.
Да, увы, OpenSource библиотеки, особенно которые поддерживаются небольшим числом разработчиков, редко когда подходят для сложных сценариев.
Использовать C++ библиотеки не вариант?
Не вариант. У меня очень богатый опыт подключения неуправляемого кода к c# проекту. Всё выглядит всегда как костыли с побочными эффектами.
Из минусов:
— зависимость от ОС;
— зависимость от разрядности;
— наличие знаний C++/CLI и/или маршалинга;
— сложный состав проекта (зависит от исходников C/C++);
— особые проблемы использования стороннего кода (например, использование неуправляемых указателей на callback функции для всех решателей с пользовательскими функциями или отсутствие дополнительного параметра void * data для пользовательских данных);
— …
В общем, жди подвоха и приготовь костыли.
Из минусов:
— зависимость от ОС;
— зависимость от разрядности;
— наличие знаний C++/CLI и/или маршалинга;
— сложный состав проекта (зависит от исходников C/C++);
— особые проблемы использования стороннего кода (например, использование неуправляемых указателей на callback функции для всех решателей с пользовательскими функциями или отсутствие дополнительного параметра void * data для пользовательских данных);
— …
В общем, жди подвоха и приготовь костыли.
Не пробовали конвертацию байт кода, вместо исходников?
weblog.ikvm.net
weblog.ikvm.net
Не пробовал. В идеале хочется иметь одну Visual Studio и всё остальное, написанное на одном языке и везде работающее. Мечты.
Жаль только, что C# не настолько быстродействующий как C/C++. Между прочим, некоторые конверторы с фортрана на C# очень хорошо себя показали (DotNumerics).
Жаль только, что C# не настолько быстродействующий как C/C++. Между прочим, некоторые конверторы с фортрана на C# очень хорошо себя показали (DotNumerics).
В идеале хочется иметь одну Visual Studio и всё остальное, написанное на одном языке и везде работающее. Мечты.
Чем Rider не устраивает?
Жаль только, что C# не настолько быстродействующий как C/C++.
Какой производительности по сравнению с плюсами там не хватает? Там даже современные векторные инструкции уже поддерживаются (AVX). Хотя с учетом того, что вы до сих пор поддерживаете .Net 2.0, ни о какой производительности не может идти никакой речи.
Чем Rider не устраивает?Так это мечты, а в реальности нужна поддержка C++/CLI и решений вперемешку (C#, C++/CLI). Думается, что только студия это умеет.
Какой производительности по сравнению с плюсами там не хватает?Такой, чтобы применять в embedded проектах на Linux'ах, например. Пробовали и отказались в пользу Qt
Жаль только, что C# не настолько быстродействующий как C/C++.
Сейчас ведется активная разработка CoreRT.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Символьный калькулятор на C#