I'm an engineer of the physical ilk (MSME), but semi-literate in the art of C++ programming. After discovering GiNaC today, I thought "nice library ". I've created a few programs for optimizing things, doing simple FEA (finite element analysis) and other sorts of calculations. Invariably, I end up restricting the domain to a consistent set of physical units (e.g. metric meter, kg, sec) or writing a lot of code to compensate for varying units across the input. For general-purpose tools, it can be a real pain in the shorts to get right. I haven't thought a great deal about why math libraries so consistently ignore the problem of unit consistency and conversion. But, I have failed to do it successfully with other libraries. For example, the Gnu project citrus[1] is a unit conversion library that implements it's own expression concept. Units and expressions are inextricably tied, I can't do my job without the old reliable kg/s/m^2 (aka. Newtons, aka. energy) after all. And, what is sin(pi)? Is that degrees or radians? It seems worthwhile to explore integrating physical units to GiNaC, if only to make like easier on poor engineers like myself. Is that a reasonable possibility? [1] http://citrus.sourceforge.net/
Hi, On Thu, 22 Jan 2004, Lee Harding wrote:
I've created a few programs for optimizing things, doing simple FEA (finite element analysis) and other sorts of calculations. Invariably, I end up restricting the domain to a consistent set of physical units (e.g. metric meter, kg, sec) or writing a lot of code to compensate for varying units across the input. For general-purpose tools, it can be a real pain in the shorts to get right.
This is not just laborious. Coming up with a good design is nontrivial and in this case it's worth studying other approaches. Because, you know, "A few weeks of developing and testing can save a whole afternoon in the library". Over at Fermilab, Walt Brown had to start from scratch at least four times till he came up with something elegant and rather bulletproof [0].
I haven't thought a great deal about why math libraries so consistently ignore the problem of unit consistency and conversion. But, I have failed to do it successfully with other libraries. For example, the Gnu project citrus[1] is a unit conversion library that implements it's own expression concept. Units and expressions are inextricably tied, I can't do my job without the old reliable kg/s/m^2 (aka. Newtons, aka. energy) after all.
And, what is sin(pi)? Is that degrees or radians?
Radians of course! How can it possibly be a temperature?
It seems worthwhile to explore integrating physical units to GiNaC, if only to make like easier on poor engineers like myself. Is that a reasonable possibility?
Have a look at the already mentioned SIunits [0], and maybe also at Qalculate [1]. If this sparks some ideas, please do let us know! Regards -richy. [0] <http://www.fnal.gov/docs/working-groups/fpcltf/html/SIunits-summary.html> [1] <http://qalculate.sourceforge.net/> -- Richard B. Kreckel <Richard.Kreckel@GiNaC.DE> <http://www.ginac.de/~kreckel/>
I'm an engineer of the physical ilk (MSME), but semi-literate in the art of C++ programming. After discovering GiNaC today, I thought "nice library ".
I've created a few programs for optimizing things, doing simple FEA (finite element analysis) and other sorts of calculations. Invariably, I end up restricting the domain to a consistent set of physical units (e.g. metric meter, kg, sec) or writing a lot of code to compensate for varying units across the input. For general-purpose tools, it can be a real pain in the shorts to get right.
Have a look at, http://sourceforge.net/projects/quantity this is a C++ template library designed for unit conversions and unit type checking (already at compile time). As far as I know, there will be a new (redesigned) release in due course. Regards, Kai -- http://echempp.sourceforge.net Kai Ludwig Institut für Organische Chemie Auf der Morgenstelle 18 72076 Tübingen Tel.: 07071/29-73049 Mail: kai.ludwig@uni-tuebingen.de
Hi all. I'm trying to use ginac for some calculation involving small matrices with symbolic values. I tried the following code: #include <ginac/ginac.h> using namespace GiNaC; main() { matrix M(2,2); matrix N(2,2); matrix H=M*N; } and obtain the error: conversion from `GiNaC::ex' to non-scalar type `GiNaC::matrix' requested I can solve the problem using matrix H=M.mul(N); instead. Anyway I wonder if this is a desired behaviour of the library. I suppose that the object M*N is of type GiNaC::ex because of delayed evaluation of the product. But, in principle, it should be possible, for the library, to understand (at run time, of course) if an object of type ex is a matrix or can be converted to a matrix using evalm(). Thank you for your attention, E. Paolini Dipartimento di Matematica Universita` di Firenze
Hi! On Fri, Jan 23, 2004 at 05:12:11PM +0100, Emanuele Paolini wrote:
I tried the following code:
matrix M(2,2); matrix N(2,2); matrix H=M*N;
and obtain the error: conversion from `GiNaC::ex' to non-scalar type `GiNaC::matrix' requested
Anyway I wonder if this is a desired behaviour of the library. I suppose that the object M*N is of type GiNaC::ex because of delayed evaluation of the product.
Yes, well, GiNaC is a symbolic expressions library, not a matrix library, and thus the fundamental type is "ex". I suppose we could implement an automatic evalm() when you assign an "ex" to a matrix, but that would interfere with the existing matrix::operator=(const ex &) that is used for matrix initialization... Bye, Christian -- / Physics is an algorithm \/ http://www.uni-mainz.de/~bauec002/
participants (5)
-
Christian Bauer
-
Emanuele Paolini
-
Kai Ludwig
-
Lee Harding
-
Richard B. Kreckel