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

Алгоритмы-алгоритмам рознь.
Здесь придется делиться между программистами и алгоритмистами.
Есть алгоритмы верхнего уровня, читай математическое описание решения задач, есл численные алгоритмы и тоже на уровне абстрактной математики, а есть численные алгоритмы и реализация их на конкретной "железной" платформе.
Точный водораздел провести сложно.

в такой годный тред хочется немного набросить

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

но нужно добавить, что такие алгоритмисты (не идиоты же они) имеют опыт реализации алгоритмов и понимают сколько ресурсов ПЛИС и/или процессора потребует задача, если же что-то новое, то могут правильно сформулировать вопросы для оценки ресурсов

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

Если руководствоваться такими принципами - то разные реализации одного и того же алгоритма (ну, допустим, g.729, или h.264, ну и т.п.) окажутся совершенно несовместимы друг с другом, и одинаковые входные потоки начнут генерировать совершенно разные выходные Это будет бардак и анархия

Все таки, все необходимые точности и методики вычислений (отработка переполнений/ограничений/т.п.) это неотъемлемая часть алгоритма, чтобы он был реализуем однозначным образом. И, докучи, по-хорошему, должны быть наборы тестовых векторов входных и выходных данных для проверки соответствия реализации алгоритму.

yes
Хмм...
Ну если Вы реализовали (а значит и разобрались!) хотя бы один раз новый алгоритм, то больше алгоритмист и не нужен. Патентный поверенный нужен, системный и прикладной программисты ошибки исправлять нужны, заведующий производством нужен, тестировщик нужен, продажник толковый нужен. А вот алгоритмист - нет: "До свиданья, с Вами было приятно сотрудничать. Не забывайте, пожалуйста, про соглашение о неразглошении. Выход там - Вас проводят". И это реальные отношения в коммерческом секторе.
А вот новая платформа вышла - тут-то и нужен сразу и железятник, и плисовод, и программист.
В алгоритмах, как правило, (ну по-моему скромному опыту) нет ничего архисложного.
С аутсорсом тоже не всё так радужно: чтобы грамотно поставить задачу и проконтролировать результат (да ещё разобраться в чужом коде) нужен специалист высокого уровня. Тут ещё считать надо что выгоднее.
Так что, для экономии денег как раз и нужно нагружать именно алгоритмиста.
Уважаемый SM написал, что по-хорошему, должны быть наборы тестовых векторов. Добавлю: не "по-хорошему", а обязательно. И обязательно с учётом точности и методики вычислений.
Ну а про [V0,D0] = eig(A0)...
Выдавать такое за алгоритм - это натуральное хамство по отношению к FPGA-дизайнеру.
Получается, что ТС и есть алгоритмист. Осталось только оформить это документально.

почему же он же проффессор и знает как лучше выдавать правильный алгоритм, а кто такой FPGA-дизайнер - "вчерашний студент". Разве "вчерашний студент" может знать что лучше или хуже ...
короче жесть работать с такими людьми и мне кажется, что его уже не исправить, тем более если проффессор уже предпенсионного/пенсионного возраста...

знакомые сильно работали в области IEEE 802.11 (в 90-е делали азики в США), так там все точно так и было, несмотря на толстенную кучу бумаг от ieee
по слухам и с блютусом то же самое было поначалу - между собой могло общаться только оборудование одного производителя

естественно, я не спорю, что методология должна быть и тестовые вектора и интерфейсы/протоколы/методологии

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

то есть понимает как работает система, предположительно, сложная система

----






это вроде как и непротиворечит высокой оплате труда алгоритмиста?

а так, после запуска производства, нужен отдел продаж и, возможно, саппорт.

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

--------

на всякий случай - я то "программист", то есть могу имплементировать задачи если мне объяснят - преимущество, отсутствие узкой специализации, то есть с трудоустройством проще, чем у алгоритмиста, но некая зависть к ним все-таки имеется

Советую Вам посмотреть на HDL Coder или DSP System Generator - они позволяют матлабовские алгоритмы перевести в рабочий HDL код намного быстрее чем ручками, а также позволят Вашим алгоритмистам еще до выдачи алгоритма кодерам проверить их на синтезируемость.

1. Нужен отдел экспертизы на соответствие ТЗ существующим нормам и стандартам.
2. Ваше право проверить правильность "переписывания листинга". Доказывать соответствие "переписанного алгоритма" "оригиналу" должен сектор программистов.
3. Должны приходить не с листочками, а отдельными блоками алгоритмов.
4. Это анархия.
5. Все обсуждения и Ваши замечания должны быть оформлены в виде документов с указанием даты.
6. См.пп.5 При наличии документов согласования виноваты будут Ваши заказчики.
7. Опыт взаимодействия есть. Вам придётся разработать "болванку" ТЗ, которая будет соответствовать существующим стандартам и Вашим собственным дополнительным требованиям. В противном случае Вы ВСЕГДА будете в ответе за ВСЁ и за ВСЕХ. Параллельно необходимо иметь систему моделирования, на которой можно проверить работоспособность отдельных блоков алгоритма.

Сообщение отредактировал VNS - Sep 12 2014, 01:35