From: si-units-list@si-units (si-units-digest)
To: si-units-digest@si-units
Subject: si-units-digest V1 #6
Reply-To: si-units-list@si-units
Sender: si-units-list@si-units
Errors-To: si-units-list@si-units
Precedence: bulk
si-units-digest Friday, June 14 2002 Volume 01 : Number 006
In this issue:
Re: SI Units Project: Display (output) of units
Re: SI Units Project: Display (output) of units
RE: SI Units Project: Display (output) of units
RE: SI Units Project: Display (output) of units
Re: SI Units Project: Display (output) of units
Re: SI Units Project: Display (output) of units
Re: SI Units Project: Display (output) of units
Re: SI Units Project: Display (output) of units
Re: SI Units Project: Display (output) of units
Re: SI Units Project: Display (output) of units
Re: SI Units Project: Display (output) of units
Re: SI Units Project: Display (output) of units
Re: SI Units Project: Display (output) of units
Re: SI Units Project: Display (output) of units
----------------------------------------------------------------------
Date: Tue, 11 Jun 2002 19:42:50 -0700
From: Pete and Lana Klier
Subject: Re: SI Units Project: Display (output) of units
Mark Easterbrook wrote:
> I've just got back from holiday (hence I've not posted for the last
> couple of weeks - but neither did anyone else so nobody noticed :)
>
> Thinking about the display of units (some ideas):
>
> Assuming we use the thing being measured rather than the units
> as mentioned a few weeks ago so we have our basic types as:
>
> distance
> current
Most textbooks would use "charge" as a more fundamental unit, but the first 4
coverthe same space.
> time
> mass
> temperature
> luminousity
> substance
>
Right. I proposed the first 4, should we make the next 3 into hard
requirements as well??
> and some derived units
>
> area (distance^2)
> volume (distance^3)
> velocity (distance/time)
>
> How would we want these displayed?
>
A lot of times one could put metres^2 or some such if there isn't a name for
it. However,units such as "ohms"
> Number format options:
> 1) normal decimal number using local 24000 / 0.24 or 0,24
> 2) using separators: 24,000 (some locales don't use groups of 3)
> 3) exp. format: 2.4E4 / 2.4E-1
> 4) exp. format by 3: 24E3 / 240E-3
> 5) fixed decimal places: 2.40 24000.00
> 6) fixed precision: 2.40E3 2.40 0.240 2.40E-2
>
> Units format options:
> 1) Standard abbreviation: m A s kg K cd mol m^2 m^3
> 2) Full name: metre, ampere, second, square metre, cubic metre (using
> locale)
>
> Prefix format options:
> 1) Always use base unit: 24000m 24000kg
> 2) Adjust to range (see below): 24km 24Mg
> 3) Adjust to range and use common name: 24 tonne
>
> By adjust to range I mean that there is an upper and lower limit to
> the value displayed, e.g. 500 and 1.0
> If value > upper:
> while value > upper then increase prefix, divide value by 1000
> else
> while value < lower then decrease prefix, multiply value by 1000.
> Note: Do we need to consider this on a unit basis, instance basic,
> globally,
> or at output time. Is this too simplistic, for example, it may be
> "usual" to
> refer to 2000m as 2km but 2000km as 2000km rather than Mm.
>
> Display limitation options:
> 1) Display exact: e.g. micro and ohm using greek characters (needs to be
> specified what character code to use).
> 2) Display nearest ASCII: u for micro, Ohm for omega.
>
> Note that some combination of the above do not make sense.
>
> The fixed precision is an interesting issue as for many scientific
> calculations
> it is a storage issue and not just a display issue. Perhaps our domain
> experts
> would like to comment on this. Should we store a precision? What are the
> rules
> for combining units of different precision?
>
I think the "precision of computation" issue (or even the "printing of a
number") issue is mootif we consider the requirement that the base data-type
is parameterized. For instance, one may
wish to do something like:
metres x = 7.2;
metres y = 5.3;
metres z = x + y;
This should be legal and use the same arithmetic (or as close as we can get)
as the original. The
same reasoning can be applied to a user-defined "abstract" data type (if we
want fixed-point, fine)
for example
ohms foo = 1.0 / (sqrt(-1.0) * omega * C)
or something like that. Similarly,
metres would be automatic.
> Most of the above are only display issues so can be considered when we
> get
> to dealing with I/O. However, we need may need to consider things like
> precision
> early on.
>
Nice to keep this going.
> --
> mark@si-units
------------------------------
Date: Tue, 11 Jun 2002 20:01:58 -0700
From: Pete and Lana Klier
Subject: Re: SI Units Project: Display (output) of units
To further elaborate on the enclosed message, we would note that the numerical
base type would be responsible for its own printing (i.e., via operator <<
(ostream &, T))
and thus printing the *numerical* value isn't an issue, and if you want to create
your
own abstract data type with a customized printing routine, that would fold into
the type-system nicely.
The precision issue is an interesting one if it interacts with the prefixes such
as
giga-, mega-, milli-, micro, etc. One may imagine doing fixed-point
computations as follows:
micro> length1 = 27 micrometres; // or something like that
then, one can do all of the computations as micrometres, using integer
arithmetic, *without* fear
of messing up the units or even the scaling,
metres length2 = length1;
where the conversion, including dividing by 1000000, would be automatic. Come to
think of
it this might actually be useful to scientists beyond simple type-checking.
The printing of the micrometres type would probably be simple: print the value
in the usual
way by the base type, and then the word "micrometres" -- finer control of this,
i.e. scaling and
so forth, could be accomplished by casting to some other scale such as "metres"
and/or
using the abstract data type as the numerical type on which you operate, i.e.
cout << length1 ; // prints "27 micrometres"
cout << metres length1; // prints "0.000027 metres"
so what you see is what you get, and it's relatively predictable.
The big problem I was having was, given a data item tagged (possibly at
compile-time) in fundamental
units only (that is probably the right canonical representation, I believe) would
you print the *type*
field if it weren't simple. How do I figure out that something is in "ohms per
metre" or whatever if the
"ohms" part is expressed again in terms of elementary units of charge, time,
length, and mass.
Pete and Lana Klier wrote:
> Mark Easterbrook wrote:
>
> > I've just got back from holiday (hence I've not posted for the last
> > couple of weeks - but neither did anyone else so nobody noticed :)
> >
> > Thinking about the display of units (some ideas):
> >
> > Assuming we use the thing being measured rather than the units
> > as mentioned a few weeks ago so we have our basic types as:
> >
> > distance
> > current
>
> Most textbooks would use "charge" as a more fundamental unit, but the first 4
> coverthe same space.
>
> > time
> > mass
> > temperature
> > luminousity
> > substance
> >
>
> Right. I proposed the first 4, should we make the next 3 into hard
> requirements as well??
>
> > and some derived units
> >
> > area (distance^2)
> > volume (distance^3)
> > velocity (distance/time)
> >
> > How would we want these displayed?
> >
>
> A lot of times one could put metres^2 or some such if there isn't a name for
> it. However,units such as "ohms"
>
> > Number format options:
> > 1) normal decimal number using local 24000 / 0.24 or 0,24
> > 2) using separators: 24,000 (some locales don't use groups of 3)
> > 3) exp. format: 2.4E4 / 2.4E-1
> > 4) exp. format by 3: 24E3 / 240E-3
> > 5) fixed decimal places: 2.40 24000.00
> > 6) fixed precision: 2.40E3 2.40 0.240 2.40E-2
> >
> > Units format options:
> > 1) Standard abbreviation: m A s kg K cd mol m^2 m^3
> > 2) Full name: metre, ampere, second, square metre, cubic metre (using
> > locale)
> >
> > Prefix format options:
> > 1) Always use base unit: 24000m 24000kg
> > 2) Adjust to range (see below): 24km 24Mg
> > 3) Adjust to range and use common name: 24 tonne
> >
> > By adjust to range I mean that there is an upper and lower limit to
> > the value displayed, e.g. 500 and 1.0
> > If value > upper:
> > while value > upper then increase prefix, divide value by 1000
> > else
> > while value < lower then decrease prefix, multiply value by 1000.
> > Note: Do we need to consider this on a unit basis, instance basic,
> > globally,
> > or at output time. Is this too simplistic, for example, it may be
> > "usual" to
> > refer to 2000m as 2km but 2000km as 2000km rather than Mm.
> >
> > Display limitation options:
> > 1) Display exact: e.g. micro and ohm using greek characters (needs to be
> > specified what character code to use).
> > 2) Display nearest ASCII: u for micro, Ohm for omega.
> >
> > Note that some combination of the above do not make sense.
> >
> > The fixed precision is an interesting issue as for many scientific
> > calculations
> > it is a storage issue and not just a display issue. Perhaps our domain
> > experts
> > would like to comment on this. Should we store a precision? What are the
> > rules
> > for combining units of different precision?
> >
>
> I think the "precision of computation" issue (or even the "printing of a
> number") issue is mootif we consider the requirement that the base data-type
> is parameterized. For instance, one may
> wish to do something like:
>
> metres x = 7.2;
> metres y = 5.3;
>
> metres z = x + y;
>
> This should be legal and use the same arithmetic (or as close as we can get)
> as the original. The
> same reasoning can be applied to a user-defined "abstract" data type (if we
> want fixed-point, fine)
> for example
>
> ohms foo = 1.0 / (sqrt(-1.0) * omega * C)
>
> or something like that. Similarly,
>
> metres would be automatic.
>
> > Most of the above are only display issues so can be considered when we
> > get
> > to dealing with I/O. However, we need may need to consider things like
> > precision
> > early on.
> >
>
> Nice to keep this going.
>
> > --
> > mark@si-units
------------------------------
Date: Wed, 12 Jun 2002 09:57:18 +0100
From: R.D.Hughes@si-units
Subject: RE: SI Units Project: Display (output) of units
> The fixed precision is an interesting issue as for many scientific
> calculations
> it is a storage issue and not just a display issue. Perhaps our domain
> experts
> would like to comment on this. Should we store a precision?
> What are the
> rules
> for combining units of different precision?
I will choose my terminology a little carefully here, because by precision
you are referring to significant figures, which is closely related, but
slightly different (the number of significant figures is normally determined
by the precision to which a figure is known). To illustrate the difference:
If you knew a distance was 2.7682 metres and the estimated precision on the
measurement was +/- 0.025 metres, you would quote the measurement to either
two or three decimal places (3 or 4 significant figures in this case).
I need to think very carefully about this and comment further in a day or
so, because the treatment varies considerably depending on the calculation,
and on whether precisions (i.e. estimates of error) are known (because if
they are, you can perform calculations at the highest known level of
significance, and then round based on an error analysis)
This also brings up another interesting question, which is how to round with
5's. Traditionally in school mathematics you are taught to round 5's
upwards, so if you wanted to quote the above error to 1 significant figure
it would be +/- 0.03. In analytical science, this is the wrong approach,
because it is equally likely that the number should be rounded low as high.
So the only fair way in which to treat such figures is to randomly choose
whether to round down or up (I would add that although this is the
recommended method, I know of many labs where this little detail is rather
naughtily ignored).
Rob
------------------------------
Date: Wed, 12 Jun 2002 10:11:17 +0100
From: R.D.Hughes@si-units
Subject: RE: SI Units Project: Display (output) of units
> > I've just got back from holiday (hence I've not posted for the last
> > couple of weeks - but neither did anyone else so nobody noticed :)
> >
> > Thinking about the display of units (some ideas):
> >
> > Assuming we use the thing being measured rather than the units
> > as mentioned a few weeks ago so we have our basic types as:
> >
> > distance
> > current
>
> Most textbooks would use "charge" as a more fundamental unit,
> but the first 4
> coverthe same space.
Only if they are either very old (current has been the fundamental unit for
least 15 years, and probably a good deal longer), or just plain incorrect. I
think we should stick with the units as given by the SI specifications, but
the usage of charge instead of current as a fundamental might be some kind
of configuration choice if it is still widely used (although until this
project, I didn't even know there had been a change, because I have only
ever seen current used as a fundamental unit).
>
> > time
> > mass
> > temperature
> > luminousity
> > substance
> >
>
> Right. I proposed the first 4, should we make the next 3 into hard
> requirements as well??
It would be best I think, but not necessarily all at once. I see nothing
wrong with starting with a smaller set, and then extending the scope once
viability is demonstrated.
> > The fixed precision is an interesting issue as for many scientific
> > calculations
> > it is a storage issue and not just a display issue. Perhaps
> our domain
> > experts
> > would like to comment on this. Should we store a precision?
> What are the
> > rules
> > for combining units of different precision?
> >
>
> I think the "precision of computation" issue (or even the
> "printing of a
> number") issue is mootif we consider the requirement that the
> base data-type
> is parameterized. For instance, one may
> wish to do something like:
>
> metres x = 7.2;
> metres y = 5.3;
The second example here gives me trouble. I can see why we want this, but it
seems presents a fundamental clash between the nature of scientific
calculation and the way in which a statically typed language works.
The problem is that the definition above implies that the value of y is
known to a precision of at least one decimal place, but the implication of
the parameterisation is that it is only known to 0 decimal places.
Furthermore, although the above example behaves correctly in a sense (i.e.
if we changed our minds and decided that 5.3 was expressed too precisely we
would use 5 instead anyway), but if the value of y was 5.8 for example, it
would not behave correctly (I know of no scientific application where 5.8
would be rounded to 5 to reduce its known precision).
At the moment, the only truely safe way I can see of handling figures
properly is to always use a double type (or long double). We should do our
utmost to prevent behaviour that is contrary to normal usage, whether
explicit or otherwise. The only way in which I can even vaguely see
parameterisation working is if we can ensure that all figures used in a
calculation are parameterised with the same type, and where implicit
conversions are not allowed, so the above would have to become:
metres< int > y = static_cast< int >( 5.3 );
Even this sends a shudder down my spine, because again, if the value is 5.8
it implies a fundamentally different behaviour from any that would occur in
a calculation by hand.
Rob
------------------------------
Date: Wed, 12 Jun 2002 17:00:04 +0200
From: Terje Slettebų
Subject: Re: SI Units Project: Display (output) of units
>From: "Terje Slettebų"
>
> For example, I recently experimented some with NTL
(http://shoup.net/ntl/),
> an arbitrary integer precision library, where there's no limit to the
> precision possible.
By the way, I used it to find the 100,000 th Fibonacci number - a number
with about 20,000 digits. It found it in a few seconds. That was rather fun.
:)
I used a short function for this, using the NTL arbitrary precision integer
type, and using the Fibonacci definition, kept record of the last two
numbers in the series.
There would have been no chance of doing this, with any of the built-in
types. They have about 20 digits maximum precision. Using NTL, I got an
exact answer with about 20,000 digits.
Regards,
Terje
------------------------------
Date: Wed, 12 Jun 2002 16:40:25 +0200
From: Terje Slettebx
Subject: Re: SI Units Project: Display (output) of units
Just to give my 0.02 on this, as well.
>From:
> >
> > metres x = 7.2;
> > metres y = 5.3;
>
> The second example here gives me trouble. I can see why we want this, but
it
> seems presents a fundamental clash between the nature of scientific
> calculation and the way in which a statically typed language works.
>
> At the moment, the only truely safe way I can see of handling figures
> properly is to always use a double type (or long double).
I think it is a bad idea to fix the numerical type, in a library like this.
Witness STL, where everything is parameterized on type.
Especially in a scientific library, like an SI library, I think it's
important for the user to be able to select the type (and hence the
precision, and computational efficiency) to use. I think anything else would
seriously decrease flexibility, and applicability.
For example, I recently experimented some with NTL (http://shoup.net/ntl/),
an arbitrary integer precision library, where there's no limit to the
precision possible. There are also such libraries for arbitrary floating
point precision. Using such a library, you could use any precision you like.
The same goes for other types.
Fixing the type at double, or long double, would give a one size fits all.
It's no coincidence that also other components in the standard library, such
as std::complex (for complex numbers) also is parameterized on the type for
the real and imaginary components.
> metres< int > y = static_cast< int >( 5.3 );
>
> Even this sends a shudder down my spine, because again, if the value is
5.8
> it implies a fundamentally different behaviour from any that would occur
in
> a calculation by hand.
Whether or not conversions are allowed (and which ones), can be treated
separately. If someone uses static_cast, then they purposely circumvent the
type system, and is therefore expected to know what they're doing. It would
be completely possible to provide a conversion constructor, that rounds
according to mathematical rules, if conversion should be allowed, hence no
static_cast is needed.
Regards,
Terje
------------------------------
Date: Wed, 12 Jun 2002 20:22:58 +0000
From: Mark Easterbrook
Subject: Re: SI Units Project: Display (output) of units
R.D.Hughes@si-units wrote:
>
> > The fixed precision is an interesting issue as for many scientific
> > calculations
> > it is a storage issue and not just a display issue. Perhaps our domain
> > experts
> > would like to comment on this. Should we store a precision?
> > What are the
> > rules
> > for combining units of different precision?
>
> I will choose my terminology a little carefully here, because by precision
> you are referring to significant figures, which is closely related, but
> slightly different (the number of significant figures is normally determined
> by the precision to which a figure is known). To illustrate the difference:
>
> If you knew a distance was 2.7682 metres and the estimated precision on the
> measurement was +/- 0.025 metres, you would quote the measurement to either
> two or three decimal places (3 or 4 significant figures in this case).
>
> I need to think very carefully about this and comment further in a day or
> so, because the treatment varies considerably depending on the calculation,
> and on whether precisions (i.e. estimates of error) are known (because if
> they are, you can perform calculations at the highest known level of
> significance, and then round based on an error analysis)
>
>
> Rob
Significant digits
- ------------------
When I talked about precision I meant significant digits (as Rob
correctly
guessed). I was wondering if each value needs to have a significant
digit
part for proper scientific calculations. (If not set, then defaults to a
value high number giving maximum accuracy according to the underlying
number type such as double).
So 0.250m is value 0.25, type distance, significant digits 3.
Base types
- ----------
As I mention type, I think the types should be the things being measured
and not the SI unit. e.g.
distance my_height(1.68);
mass my_weight(88);
This avoids a number of problems:
1) On output, the type and display do not match (e.g. type metres being
displayed as kilometres or micrometres).
2) The mass SI base units contains a prefix (kg) so you cannot just add
a prefix to the base unit.
3) We avoid the meter/metre argument (it becomes a locale issue).
Does anyone have any objection to this type naming?
I envisage the following ways of constructing a variable:
distance measure1; // Zero metres, infinite sig places
distance measure2(12.3); // 12.3 metres, infinite sig places
distance measure3(1.2, kilometre); // 1.2E3 metres, infinite sig
places
distance measure4(1.2, kilometre, 3); // 1.2E3 metres, 3 sig
places.
mass measure5(42.0); // 42 kilograms
mass measure6(42.0, gram); // 0.042 kilograms
Precision
- ---------
Since Rob has mentioned it - should we consider precision (i.e. +/- X).
mass measure7(42.0, gram, pair(+0.25,-0.50));
// 0.042 kilograms +0.00025,-0.0005
Quick C++ question
- ------------------
To save me digging through my C++ books. Can templates have default
values to arguments?:
template distance...
So we don't need to write "distance var" all the time.
- --
mark@si-units
------------------------------
Date: Wed, 12 Jun 2002 20:46:02 +0000
From: Mark Easterbrook
Subject: Re: SI Units Project: Display (output) of units
Pete and Lana Klier wrote:
>
> To further elaborate on the enclosed message, we would note that the numerical
> base type would be responsible for its own printing (i.e., via operator <<
> (ostream &, T))
> and thus printing the *numerical* value isn't an issue, and if you want to create
> your
> own abstract data type with a customized printing routine, that would fold into
> the type-system nicely.
I'm not sure this folding will work very well :)
* We may wish to only use multiples of 3 (10^3, 10^6) whereas the
"normal"
way is to fix the mantissa range. (e.g. 1.2E1 1.2E2 1.2E3)
* We may always want to align numbers to the same units, for example,
all
distances in kilometres even if the range is > 10^3.
* Most number types deal with precision whereas we may need to deal
with significant digits (see Rob's discussion on precision vs.
significant
digits).
I would like to see some use cases and scenarios for the type of
scientific calculations that might use a SI units library. Then we
will get a better idea of things we need to provide and what input
and output usually looks like.
Can either of our domain experts find some suitable material for this?
- --
mark@si-units
------------------------------
Date: Wed, 12 Jun 2002 21:12:40 +0000
From: Mark Easterbrook
Subject: Re: SI Units Project: Display (output) of units
"Terje Slettebų" wrote:
>
> >From: "Terje Slettebų"
> >
> > For example, I recently experimented some with NTL
> (http://shoup.net/ntl/),
> > an arbitrary integer precision library, where there's no limit to the
> > precision possible.
>
> By the way, I used it to find the 100,000 th Fibonacci number - a number
> with about 20,000 digits. It found it in a few seconds. That was rather fun.
> :)
>
> I used a short function for this, using the NTL arbitrary precision integer
> type, and using the Fibonacci definition, kept record of the last two
> numbers in the series.
>
> There would have been no chance of doing this, with any of the built-in
> types. They have about 20 digits maximum precision. Using NTL, I got an
> exact answer with about 20,000 digits.
>
> Regards,
>
> Terje
I am yet to be convinced that integer types are useful.
double should be the default.
float as an option for those who wish to trade precision for speed and
their machine is significantly faster doing floats (I believe some
modern machines are actually slower doing floats).
a user defined floating point number to provide increased precision
beyond what double can provide. (Even this is doubtful - most scientific
work comes from measurements, and double has more precision than any
measuring device that I can think of, so what does increased precision
actually give us).
I'm not saying we should prevent integer types, just that they are not
useful. Good template code would allow any numeric type, even those
that are non-sensible!
- --
mark@si-units
------------------------------
Date: Wed, 12 Jun 2002 20:56:31 +0000
From: Mark Easterbrook
Subject: Re: SI Units Project: Display (output) of units
R.D.Hughes@si-units wrote:
>
> > The fixed precision is an interesting issue as for many scientific
> > calculations
> > it is a storage issue and not just a display issue. Perhaps our domain
> > experts
> > would like to comment on this. Should we store a precision?
> > What are the
> > rules
> > for combining units of different precision?
>
> I will choose my terminology a little carefully here, because by precision
> you are referring to significant figures, which is closely related, but
> slightly different (the number of significant figures is normally determined
> by the precision to which a figure is known). To illustrate the difference:
>
> If you knew a distance was 2.7682 metres and the estimated precision on the
> measurement was +/- 0.025 metres, you would quote the measurement to either
> two or three decimal places (3 or 4 significant figures in this case).
>
> I need to think very carefully about this and comment further in a day or
> so, because the treatment varies considerably depending on the calculation,
> and on whether precisions (i.e. estimates of error) are known (because if
> they are, you can perform calculations at the highest known level of
> significance, and then round based on an error analysis)
I understand that when performing manual calculations, there is no point
in using more than the number of significant digits than your
measurements
because you are wasting time/effort. However, with a computer doing the
work
you are not saving anything (in fact rounding involves more processing
time, not less). So, is it acceptable to do all calculations at full
precision and only deal with significant digits at the final result?
i.e. If all the inputs are 3 significant places, calculate to full
precision but display 3 significant places for the result.
>
> This also brings up another interesting question, which is how to round with
> 5's. Traditionally in school mathematics you are taught to round 5's
> upwards, so if you wanted to quote the above error to 1 significant figure
> it would be +/- 0.03. In analytical science, this is the wrong approach,
> because it is equally likely that the number should be rounded low as high.
> So the only fair way in which to treat such figures is to randomly choose
> whether to round down or up (I would add that although this is the
> recommended method, I know of many labs where this little detail is rather
> naughtily ignored).
>
> Rob
- --
mark@si-units or markandmaura@easterbrook.org.uk
------------------------------
Date: Wed, 12 Jun 2002 22:20:21 -0700
From: Pete and Lana Klier
Subject: Re: SI Units Project: Display (output) of units
Sounds like we're alive again. That's great.
Yes, I believe that default template arguments can occur on most compilers, so one
could
default to "double" but allow any data type as well.
I'm going to ask my local domain expert (who provided me with the original units
breakdown) about the charge-versus-current thing. However, in a *good* system
nobody would know the difference between the two representations!
Mark Easterbrook wrote:
> "Terje Slettebų" wrote:
> >
> > >From: "Terje Slettebų"
> > >
> > > For example, I recently experimented some with NTL
> > (http://shoup.net/ntl/),
> > > an arbitrary integer precision library, where there's no limit to the
> > > precision possible.
> >
> > By the way, I used it to find the 100,000 th Fibonacci number - a number
> > with about 20,000 digits. It found it in a few seconds. That was rather fun.
> > :)
> >
> > I used a short function for this, using the NTL arbitrary precision integer
> > type, and using the Fibonacci definition, kept record of the last two
> > numbers in the series.
> >
> > There would have been no chance of doing this, with any of the built-in
> > types. They have about 20 digits maximum precision. Using NTL, I got an
> > exact answer with about 20,000 digits.
> >
> > Regards,
> >
> > Terje
>
> I am yet to be convinced that integer types are useful.
>
> double should be the default.
>
> float as an option for those who wish to trade precision for speed and
> their machine is significantly faster doing floats (I believe some
> modern machines are actually slower doing floats).
>
> a user defined floating point number to provide increased precision
> beyond what double can provide. (Even this is doubtful - most scientific
> work comes from measurements, and double has more precision than any
> measuring device that I can think of, so what does increased precision
> actually give us).
>
> I'm not saying we should prevent integer types, just that they are not
> useful. Good template code would allow any numeric type, even those
> that are non-sensible!
>
> --
> mark@si-units
------------------------------
Date: Thu, 13 Jun 2002 13:22:59 +0200
From: Terje Slettebx
Subject: Re: SI Units Project: Display (output) of units
>From: "Mark Easterbrook"
> >
> > For example, I recently experimented some with NTL
> (http://shoup.net/ntl/),
> > an arbitrary integer precision library, where there's no limit to the
> > precision possible.
>I am yet to be convinced that integer types are useful.
The above example was just to illustrate the use of user-defined types. Like
I said, there are arbitrary precision floating point types, as well.
>double should be the default.
My point was that the SI type should be parameterized on type. That is, the
type shouldn't be hard-coded into the library.
>float as an option for those who wish to trade precision for speed and
>their machine is significantly faster doing floats (I believe some
>modern machines are actually slower doing floats).
>a user defined floating point number to provide increased precision
>beyond what double can provide. (Even this is doubtful - most scientific
>work comes from measurements, and double has more precision than any
>measuring device that I can think of, so what does increased precision
>actually give us).
>I'm not saying we should prevent integer types, just that they are not
>useful. Good template code would allow any numeric type, even those
>that are non-sensible!
You're saying the same as I said in the posting. Does this mean you agree
with me, then? That the type should be left to the library user, not library
writer? I also notice in another posting, that Pete agrees, too.
Whether or not to provide a default, and if so, which one, can be treated
separately.
Regards,
Terje
------------------------------
Date: Thu, 13 Jun 2002 19:20:37 +0000
From: Mark Easterbrook
Subject: Re: SI Units Project: Display (output) of units
Terje Slettebx wrote:
>
>[stuff cut]
> You're saying the same as I said in the posting. Does this mean you agree
> with me, then? That the type should be left to the library user, not library
> writer? I also notice in another posting, that Pete agrees, too.
Yes, the user should be able to provide a type. However, a user provided
type needs to provide at least what a float/double can provide in order
to
be useful. You should be able to, for example(*), divide by 1000 and
then
multiply by 1000 and end up effectivily where you started - you cannot
do
this with an integer type - the precision is dependant on the magnitude.
(*)Enter a number in millimeters, div by 1000 to store metres, mult by
1000 to output again in millimeters.
>
> Whether or not to provide a default, and if so, which one, can be treated
> separately.
>
> Regards,
>
> Terje
- --
mark@si-units
------------------------------
Date: Fri, 14 Jun 2002 00:08:34 +0200
From: Terje Slettebx
Subject: Re: SI Units Project: Display (output) of units
>From: "Mark Easterbrook"
> > You're saying the same as I said in the posting. Does this mean you
agree
> > with me, then? That the type should be left to the library user, not
library
> > writer? I also notice in another posting, that Pete agrees, too.
>
> Yes, the user should be able to provide a type.
> However, a user provided
> type needs to provide at least what a float/double can provide in order
> to be useful.
The library is to be able to calculate SI units, and it keeps track of the
units and prefixes, itself.
Apart from this, I don't think it's the library's concern what types are
used, so why is this discussed? Aren't we discussing how to make the
library, not which types are used for it?
Since this is not up to the library, any type can be used for it, including
int. This is up to the user.
>You should be able to, for example(*), divide by 1000 and
> then
> multiply by 1000 and end up effectivily where you started - you cannot
> do
> this with an integer type
Whether or not this is a concern, is up to the user, not the library.
> > Whether or not to provide a default, and if so, which one, can be
treated
> > separately.
By the way, be aware that even with defaults, the angle brackets are needed.
That is, if there's no parameters beside the default, it's specified like
this: "Type<> value;". This is like default parameters for functions.
Regards,
Terje
------------------------------
End of si-units-digest V1 #6
****************************