printf() — не очень подходящая с точки Вашего анализа функция — objdump говорит, что вызов printf() с одним параметром заменяется компилятором на puts().
Сначала нужно, чтобы этот руст обзавелся комитетом в ISO/IEC и этот комитет выпустил стандарт. Стандарт должен устаканиться хотя бы в начальной версиию И уж только после этого стоит этот руст воспринимать серьезно.
Вопрос — что могут рассказать об операционной системе скриншоты рабочего стола и виджетов?
Ответ — практически ничего. Тем более, что пользователь чаще всего рабочего стола и не видит — он, в основном, видит UI программ с котороыми работает.
Есть неприводимые полиномы — они используются не менее массово, нежели простые числа, а то и гораздо более, например, в цифровых системах передачи данных.
Чтобы не было необходимости в последующем рефакторинге, нужно строить модель данных независимо от того, как они в настоящее время используются (возможно, они используются неэффективно). Т.е. в процессе разработки полностью исключить такую хрень, как сценарии взаимодействия участников (юзеркейсы) — все это само нарисуется в виде возможностей, которые позволяет предоставить модель данных после ее разработки. Причем этих самых сценариев будет на порядок больше и все они будут непротиворечивыми и разумными. Останется всего лишь flow chart редактор для этих сценариев написать и статические формы для поддержки этих flow charts.
Есть правило — базы данных должны полно отражать предметную область и не должны зависеть от того, как и кто ее будет использовать — сценарии использования вторичны и определяются структурой данных, над которой они выстраиваются. Будут ли когда-нибудь в реальных сценариях взаимодействия с базой использоваться те или иные отношения и связи, в ней содержащиеся, не должно влиять на их наличие — они должны быть построены и обслуживаться безусловно.
Модели, структуры данных и операции над ними в области управления складами, магазинами и прочими продажами, которые обеспечивают достаточную для всех масштабируемость, надежность и приемлемую производительность, а также максимальную функциональную гибкость, давно разработаны, исследованы, вылизаны теоретиками. Все это апробировано в виде рабочего кода в начале 70-х, еще до того, как появился язык SQL, поэтому остается просто тупо реализовывать эти модели и операции не рефлексируя, поскольку с тех пор ничего нового в управлении данными не появилось. Под под капотом того же декларативного SQL лежит старый добрый ISAM, в терминах которого сегодня описываются все реляционные и не очень модели данных.
Есть книжка про формальные грамматики в приложении к компиляции программ
Маккиман У., Хорнинг Дж., Уортман Д. — Генератор компиляторов М.: Статистика 1980. Весь теоретический базис грамматического разбора там представлен. Книга про компиляторы такого же уровня, как книги Кнута про программирование.
Книгу можно скачать с либрусека
ATLAS also natively provides a few routines from the LAPACK [2] (Linear Algebra PACKage). LAPACK is an extremely comprehensive FORTRAN package for solving the most commonly occurring problems in numerical linear algebra. LAPACK is available as an open source FORTRAN package from netlib [21], and its size and complexity effectively rule out the idea of ATLAS providing a full implementation. Therefore, we add support for particular LAPACK routines only when we believe that the potential performance win we can offer make the extra development and maintenance costs worthwhile. Presently, ATLAS provides roughly most of the routines that involve the LU, QR and Cholesky factorizations.
Поддерживают и пользуются. Или Вы думаете, что штеуд и прочие ведущие производители систем программирования за просто так выпускают компиляторы с фортрана?
Сегодня это единственный компилируемый язык, имеющий возможности для работы с векторами и матрицами прямо в языке, а не просто операторы доступа по индексу.
Если Вы полагаете, что нужна поддержка ООП, что очень спорно, то их там есть — как только ООП стало модным-стильным-молодежным, его тут же туда воткнули.
Не хочу разводить срач, но в С/С++, например, на уровне языка нет вообще никакой поддержки ни векторов, ни матриц, ни параллельного программирования — только лишь на уровне библиотек. Даже массивы, как таковые, поддерживаются всего лишь на уровне оператора доступа по индексу, который, как это написано в стандарте, всего лишь субституция арифметики указателей.
Там гнездится софт, использующийся сегодня всеми значимыми опенсорсными проектами, а также многими проприетарными. На замену этому софту нет ничего и в проекте не просматривается. Как говорится, кому не нравится фортран и хочется переписать нетлиб на <подставьте сюда свой любимый язык>, тот не в состоянии это сделать, а те, кто может — их все устраивает.
На фортране написано слишком много, чтобы это можно было переписать.
Тот же lapack, который установлен на всех linux-кластерах в мире, написан на фортране. На си только привязки.
Его производные:
CLAPACK — f2c’ed conversion of LAPACK
ScaLAPACK — fortran
BLAS — Fortran
CBLAS — C API for BLAS)
BLAS++ — C++ API for BLAS and Batch BLAS.
LAPACK++ — C++ API for LAPACK.
…
А Вы и дальше считайте, что кто-то переписал netlib.org на C, C++ и на МСМ-языки.
Если Вы купите компиляторы интел, с ними будет идти оптимизированный под их процессоры lapack, однако на чем он написан, большой секрет. В любом случае их ifort производит самый быстрый код, и он быстрее, чем произведенный icc. По крайней мере, на задачах разложения матриц, вычисления их спектра и прочих элементов ЛА.
У Вас ошибка интерпретации членов УНС — частная производная скорости по времени \frac{\partial\vec{v}}{\partial t}, что стоит слева от знака равенства, это не ускорение, а скорость изменения скорости в фиксированной точке пространства — частная производная же.
А вот если Вы конвективный член (\vec{v}\cdot\nabla)\vec{v}, что стоит с минусом сразу справа от знака равенства, перенесете в левую часть, она как раз и даст ускорение — полную производную скороcти по времени.
Не сомневайтесь, еще как пишут. Основной язык программирования с использованием MPI — фортран. Собственно, там еще в привязках и С есть, но для численных расчетов физики и инженеры предпочитают таки фортран. Причина банальна — в фортране есть полноценная и удобная работа с комплексными числами, матрицами и многомерными массивами, чего нет ни в Cи, ни в C++ (ISO/IEC 9899-2011 6.5.2.1 Array subscripting).
Собственно, в C и C++ нет ничего для разработки числодробилок, чего нет в фортране, но не наоборот — в фортране есть много чего, чего нет в ни в C, ни в C++. Специализированный инструмент всегда лучше, нежели универсальный.
слабо зависит от скорости, S вообще не звисит.
Ответ — практически ничего. Тем более, что пользователь чаще всего рабочего стола и не видит — он, в основном, видит UI программ с котороыми работает.
Есть правило — базы данных должны полно отражать предметную область и не должны зависеть от того, как и кто ее будет использовать — сценарии использования вторичны и определяются структурой данных, над которой они выстраиваются. Будут ли когда-нибудь в реальных сценариях взаимодействия с базой использоваться те или иные отношения и связи, в ней содержащиеся, не должно влиять на их наличие — они должны быть построены и обслуживаться безусловно.
Модели, структуры данных и операции над ними в области управления складами, магазинами и прочими продажами, которые обеспечивают достаточную для всех масштабируемость, надежность и приемлемую производительность, а также максимальную функциональную гибкость, давно разработаны, исследованы, вылизаны теоретиками. Все это апробировано в виде рабочего кода в начале 70-х, еще до того, как появился язык SQL, поэтому остается просто тупо реализовывать эти модели и операции не рефлексируя, поскольку с тех пор ничего нового в управлении данными не появилось. Под под капотом того же декларативного SQL лежит старый добрый ISAM, в терминах которого сегодня описываются все реляционные и не очень модели данных.
Маккиман У., Хорнинг Дж., Уортман Д. — Генератор компиляторов М.: Статистика 1980. Весь теоретический базис грамматического разбора там представлен. Книга про компиляторы такого же уровня, как книги Кнута про программирование.
Книгу можно скачать с либрусека
Сегодня это единственный компилируемый язык, имеющий возможности для работы с векторами и матрицами прямо в языке, а не просто операторы доступа по индексу.
Если Вы полагаете, что нужна поддержка ООП, что очень спорно, то их там есть — как только ООП стало модным-стильным-молодежным, его тут же туда воткнули.
Не хочу разводить срач, но в С/С++, например, на уровне языка нет вообще никакой поддержки ни векторов, ни матриц, ни параллельного программирования — только лишь на уровне библиотек. Даже массивы, как таковые, поддерживаются всего лишь на уровне оператора доступа по индексу, который, как это написано в стандарте, всего лишь субституция арифметики указателей.
cblas — всего лишь интерфейс к lapack.
Тот же lapack, который установлен на всех linux-кластерах в мире, написан на фортране. На си только привязки.
Его производные:
CLAPACK — f2c’ed conversion of LAPACK
ScaLAPACK — fortran
BLAS — Fortran
CBLAS — C API for BLAS)
BLAS++ — C++ API for BLAS and Batch BLAS.
LAPACK++ — C++ API for LAPACK.
…
А Вы и дальше считайте, что кто-то переписал netlib.org на C, C++ и на МСМ-языки.
Если Вы купите компиляторы интел, с ними будет идти оптимизированный под их процессоры lapack, однако на чем он написан, большой секрет. В любом случае их ifort производит самый быстрый код, и он быстрее, чем произведенный icc. По крайней мере, на задачах разложения матриц, вычисления их спектра и прочих элементов ЛА.
А вот если Вы конвективный член (\vec{v}\cdot\nabla)\vec{v}, что стоит с минусом сразу справа от знака равенства, перенесете в левую часть, она как раз и даст ускорение — полную производную скороcти по времени.
Собственно, в C и C++ нет ничего для разработки числодробилок, чего нет в фортране, но не наоборот — в фортране есть много чего, чего нет в ни в C, ни в C++. Специализированный инструмент всегда лучше, нежели универсальный.