Ada decimal types
REH
have the opportunity to port over to some of the new features 95
provides. We have a 64-bit mission time that is represented as a
record of two 32-bit values (one for seconds and one for microseconds).
Is it advantagous to use:
type Mission_Time_Type is delta 1.0e-6 digits 16 range 0.0 .. (2.0**32)
- 1.0;
instead? I was thinking this would make the math easier and less
"klunky." Are there any ramifications of using decimal types that I
should be aware of? I can't find any info. that goes in depth on the
subject.
Thanks,
REH
Jeffrey R. Carter
Are you sure you still need your own type? Ada.Real_Time may do what you
need.
--
Jeff Carter
"All citizens will be required to change their underwear
every half hour. Underwear will be worn on the outside,
so we can check."
Bananas
29
REH
Jeffrey R. Carter wrote:
> REH wrote:
> > We are in the process of converting our software from '83 to '95, and
> > have the opportunity to port over to some of the new features 95
> > provides. We have a 64-bit mission time that is represented as a
> > record of two 32-bit values (one for seconds and one for microseconds).
> > Is it advantagous to use:
> >
> > type Mission_Time_Type is delta 1.0e-6 digits 16 range 0.0 .. (2.0**32)
> > - 1.0;
> >
> > instead? I was thinking this would make the math easier and less
> > "klunky." Are there any ramifications of using decimal types that I
> > should be aware of? I can't find any info. that goes in depth on the
> > subject.
>
> Are you sure you still need your own type? Ada.Real_Time may do what you
> need.
>
Hi Jeff. I didn't think of the real-time annex. I will look into it.
Thanks.
REH
Stephen Leake
> We are in the process of converting our software from '83 to '95, and
> have the opportunity to port over to some of the new features 95
> provides. We have a 64-bit mission time that is represented as a
> record of two 32-bit values (one for seconds and one for microseconds).
> Is it advantagous to use:
>
> type Mission_Time_Type is delta 1.0e-6 digits 16 range 0.0 .. (2.0**32)
> - 1.0;
>
> instead?
Instead of what? you didn't say what type the 32 bit values have.
I would use a fixed point type, not a decimal type.
I would also use a 64 bit fixed point type, rather than a split
record, but you probably can't change that.
--
-- Stephe
REH
"Stephen Leake" <stephe...@acm.org> wrote in message
news:u1wv8d...@acm.org...
> "REH" <spam...@stny.rr.com> writes:
>
>> We are in the process of converting our software from '83 to '95, and
>> have the opportunity to port over to some of the new features 95
>> provides. We have a 64-bit mission time that is represented as a
>> record of two 32-bit values (one for seconds and one for microseconds).
>> Is it advantagous to use:
>>
>> type Mission_Time_Type is delta 1.0e-6 digits 16 range 0.0 .. (2.0**32)
>> - 1.0;
>>
>> instead?
>
> Instead of what? you didn't say what type the 32 bit values have.
>
> I would use a fixed point type, not a decimal type.
A decimal type is a fixed pointed type. I don't want to use a binary fixed
point because it would change the precision. Currently any value of
microsecond granularity can be represented. If I use a binary fixed point,
that would change.
>
> I would also use a 64 bit fixed point type, rather than a split
> record, but you probably can't change that.
>
I can change it. That is the point. I want to get rid of the record if I
can, but I want to realize any ramifications of the change.
Thanks.
REH
tmo...@acm.org
> point because it would change the precision. Currently any value of
> microsecond granularity can be represented. If I use a binary fixed point,
> that would change.
decimal notation. The value 1/10 could be stored precisely as "0.1",
but 1/10 could not be stored precisely as a binary fraction.
But that's not how Ada "fixed point", even decimal fixed point, works.
"The set of values of a fixed point type comprise the integral multiples
of a number called the 'small' of the type." ARM 3.5.9(8) The only
difference between a decimal and an ordinary fixed point is that the
'small' for a decimal is a power of ten, while the 'small' for an
ordinary is typically a power of two (unless you specify otherwise).
Thus a decimal fixed point type with a delta of 1/10 would be stored,
as integer multiples of 1/10. The value 1/10 would be stored as 1,
with the implied scaling factor of "divide by 10".
So
type Mission_Time_Type is delta 1.0e-6 digits 16 range 0.0 .. (2.0**32) - 1.0;
will store the number of microseconds. In effect your current record
with two 32 bit integers is storing the same thing, it just stores
(number of microseconds)/1_000_000 in one word and
(number of microseconds) mod 1_000_000 in the other word, while type
Mission_Time_Type would store
(number of microseconds)/2**32 in its upper 32 bits and
(number of microseconds) mod 2**32 in its upper 32 bits.
Since all arithmetic is done conceptually as integers (the only difference
is in how they are stored), they should give the same answers and the
same precision.
REH
<tmo...@acm.org> wrote in message news:ZcKdnZAJrtS...@comcast.com...
I do know how fixed points "work." You are making assumptions about my
expectations and the standard. Both of which are wrong. The internal of
the decimal type are not defined by the standard. It could be stored at
integers; it could be BCD. I personally don't care how it is stored. I
just know that Ada guarantees me that if my delta is 1.0e6, it can represent
every multiple of it within my range. You can specualate all you want about
how it "works." I just care that it does.
REH
tmo...@acm.org
>expectations and the standard. Both of which are wrong.
answer that came to me was the speculation I posted. I'm certainly glad
to hear that you understand Ada fixed point. But now I'm puzzled by
why you are worried about converting from records to fixed point.
REH
<tmo...@acm.org> wrote in message news:Idednavn8Kn...@comcast.com...
Because there are always "gotchas" the crop up when making drastic changes
to code. There are certainly more experienced Ada developers than I in this
newsgroups. If there were any issues in making such a change, I would
definitely want to know about them. I am making assumptions that the logic
will be cleaner, safer, and more maintainable if I change the record to a
decimal type. My assumptions have been wrong before. I don't change
working software lightly, but I have the (rare) opportunity to clean up some
very dated code.
REH
Randy Brukardt
news:sKG6g.6427$TT....@twister.nyroc.rr.com...
> > I would use a fixed point type, not a decimal type.
> A decimal type is a fixed pointed type. I don't want to use a binary
fixed
> point because it would change the precision. Currently any value of
> microsecond granularity can be represented. If I use a binary fixed
point,
> that would change.
Decimal fixed point types have different rules for rounding in operations
like "*" and "/" than regular ("ordinary") fixed point does. Be sure that
that behavior doesn't matter to your application. Otherwise, there is no
difference between a decimal fixed point and an ordinary fixed point with an
appropriate small clause:
type Mission_Time_Type is delta 1.0e-6 range 0.0 .. (2.0**32) - 1.0;
for Mission_Time_Type'Small use 1.0e-6;
Ada 95 compilers *could* reject the above, but since they have to implement
it anyway to support decimal types, there is no good reason to do so.
Randy.
Keith Thompson
[...]
> I do know how fixed points "work." You are making assumptions about my
> expectations and the standard. Both of which are wrong. The internal of
> the decimal type are not defined by the standard. It could be stored at
> integers; it could be BCD. I personally don't care how it is stored. I
> just know that Ada guarantees me that if my delta is 1.0e6, it can represent
> every multiple of it within my range. You can specualate all you want about
> how it "works." I just care that it does.
I think you mean 1.0e-6, not 1.0e6.
And it's the small, not the delta, that needs to be 1.0e-6. If you
specify a delta of 1.0e-6 for an ordinary fixed-point type without
specifying the small, you'll (probabaly) get a small of 2.0**-20.
(As you probably know.)
--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
REH
"Keith Thompson" <ks...@mib.org> wrote in message
news:lnmzdvt...@nuthaus.mib.org...
> "REH" <m...@you.com> writes:
> [...]
>> I do know how fixed points "work." You are making assumptions about my
>> expectations and the standard. Both of which are wrong. The internal of
>> the decimal type are not defined by the standard. It could be stored at
>> integers; it could be BCD. I personally don't care how it is stored. I
>> just know that Ada guarantees me that if my delta is 1.0e6, it can
>> represent
>> every multiple of it within my range. You can specualate all you want
>> about
>> how it "works." I just care that it does.
>
> I think you mean 1.0e-6, not 1.0e6.
Yes.
>
> And it's the small, not the delta, that needs to be 1.0e-6. If you
> specify a delta of 1.0e-6 for an ordinary fixed-point type without
> specifying the small, you'll (probabaly) get a small of 2.0**-20.
> (As you probably know.)
It's not an binary fixed point, but a decimal fixed point. I believe the
small has to be a power of ten, not two. Anyways, that is a good point.
For a decimal type, do I need to specify the small?
Thanks,
Rich
Simon Wright
> "Keith Thompson" <ks...@mib.org> wrote in message
> news:lnmzdvt...@nuthaus.mib.org...
>> And it's the small, not the delta, that needs to be 1.0e-6. If you
>> specify a delta of 1.0e-6 for an ordinary fixed-point type without
>> specifying the small, you'll (probabaly) get a small of 2.0**-20.
>> (As you probably know.)
>
> It's not an binary fixed point, but a decimal fixed point. I believe the
> small has to be a power of ten, not two. Anyways, that is a good point.
> For a decimal type, do I need to specify the small?
On GNAT, Duration (which is a plain fixed-point type) is effectively
implemented as
type Duration is delta 1.0e-9;
for Duration'Small use 1.0e-9;
for Duration'Size use 64;
which means that the lsb is 1 nanosecond. I'm pretty sure that a
compiler has to do what you tell it here (or reject the unit).
It may well be that a decimal fixed point type would have exactly the
same effect but I have never used one.
type My_Duration is digits 9 delta 1.0e-9;
for My_Duration'Size use 64;
One point we came unstuck over: depending on your machine, the
alignment of a 64-bit value may end up as 8 bytes, whereas the
alignment of your POSIX-like representation would be 4 bytes.
Had you considered just using Duration?
REH
"Simon Wright" <si...@pushface.org> wrote in message
news:m2k68zm...@grendel.local...
The problem with that is that different compilers that we use define
different precisions for duration. Also, duration is a binary fixed point.
A don't want to use those because precision may be lost. Whether or not the
loss will be an issue, I do not know but I would rather not risk it. Of
course I just may be worrying over nothing.
Thanks.
REH
Randy Brukardt
...
Also, duration is a binary fixed point.
> A don't want to use those because precision may be lost. Whether or not
the
> loss will be an issue, I do not know but I would rather not risk it. Of
> course I just may be worrying over nothing.
You're still very confused. Semantically, there is no difference between
type Mission_Time_Type is delta 1.0e-6 range 0.0 .. (2.0**32) - 1.0;
for Mission_Time_Type'Small use 1.0e-6;
and
type Mission_Time_Type is delta 1.0e-6 digits 14;
other than the bounds of the base type and the rounding of the "*" and "/"
operations. The *precision* is identical, because that depends *only* on the
value of 'small [for all fixed point types], and that is the same for both
of these types. [There might be representation differences, but those can't
change the semantics of the types.]
Of course, specifying the small is necessary to get the appropriate
precision for the ordinary fixed point type (as the default is not what you
want). But that is always a good idea with fixed point; it's too important
of a choice to leave it to the compiler, and it is best to document it
explicitly in the source code.
Randy.
REH
"Randy Brukardt" <ra...@rrsoftware.com> wrote in message
news:8KadnYXCB-5FKMLZ...@megapath.net...
>
> "REH" <m...@you.com> wrote in message
> news:yj47g.23728$ZQ3....@twister.nyroc.rr.com...
> ...
> Also, duration is a binary fixed point.
>> A don't want to use those because precision may be lost. Whether or not
> the
>> loss will be an issue, I do not know but I would rather not risk it. Of
>> course I just may be worrying over nothing.
>
> You're still very confused. Semantically, there is no difference between
>
> type Mission_Time_Type is delta 1.0e-6 range 0.0 .. (2.0**32) - 1.0;
> for Mission_Time_Type'Small use 1.0e-6;
>
> and
>
> type Mission_Time_Type is delta 1.0e-6 digits 14;
>
Why is there not a difference? Won't the first actually use some negative
power-of-2 as the delta?
REH
Keith Thompson
Um, no. The delta is exactly what's specified in the type declaration.
Given:
type Mission_Time_Type is delta 1.0e-6 range 0.0 .. (2.0**32) - 1.0;
the delta is 1.0e-6.
In the absence of a representation clause for 'Small, the default
Small is a power of 2, but in this case the Small was explicitly
specified:
for Mission_Time_Type'Small use 1.0e-6;
so the Small is also exactly 1.0e-6.
Simon Wright
> "Randy Brukardt" <ra...@rrsoftware.com> wrote in message
> news:8KadnYXCB-5FKMLZ...@megapath.net...
>> You're still very confused. Semantically, there is no difference between
>>
>> type Mission_Time_Type is delta 1.0e-6 range 0.0 .. (2.0**32) - 1.0;
>> for Mission_Time_Type'Small use 1.0e-6;
>>
>> and
>>
>> type Mission_Time_Type is delta 1.0e-6 digits 14;
>
> Why is there not a difference? Won't the first actually use some negative
> power-of-2 as the delta?
The LRM 3.5.10(2) is a good deal less than informative as to what this
_Small_ might be. But unless I have been totally wrong all this time
it specifies the value of the LSB of the type.
So for Randy's example, if you do an unchecked conversion of
Mission_Type_Time'(1.5) to a long integer, the result would be
1_500_000.
And if you did the same for a GNAT Duration'(1.5) -- remember, its
'Small is 1e-9) -- you would get 1_500_000_000.
REH
OK, my assumption was that when they added decimal fixed points to the
language, you declared them via "digits x" otherwise you would get a
binary fixed point. Is that not true?
REH
Randy Brukardt
news:1147263720.2...@j73g2000cwa.googlegroups.com...
...
> OK, my assumption was that when they added decimal fixed points to the
> language, you declared them via "digits x" otherwise you would get a
> binary fixed point. Is that not true?
There is no such thing as "binary fixed point"! There is "ordinary fixed
point" and "decimal fixed point". For all fixed point types, the "small" is
the smallest value that can be exactly represented. Other values are
multiples of the small. (The only effect of the delta is to provide guidance
for the *default* selection of the small value; the only thing that matters
is the small value). For "ordinary fixed point", the small value can be
anything. The *default* is a power of two, but it can be specified as any
value (including powers of ten). For "decimal fixed point", the *default*
small value is a power of ten.
The representation of the multiples of small can be anything that the
compiler wants to use (and this may, but doesn't have to vary between
ordinary and decimal fixed point types). Typically, the representation is
some binary integer representation.
It is possible for a compiler to reject specifying a small of 1.0e-6. That
would be a pretty lame Ada 95 compiler, IMHO, given that it has to be
supported in decimal types. Ada 83 compilers used to reject these because
there were impossible precision requirements for mixed multiplies (these
were changed in Ada 95), so there may be some Ada myths about avoiding the
specification of small values.
I think that *all* ordinary fixed point types should have 'Small specified,
because then there is no surprise or guesswork as to what precision is being
used.
I was going to suggest that you read some online resources, but I wasn't
able to find any that explain this correctly (other than the RM, and I
wouldn't suggest starting there!). Specifically, the wikibook entry is
over-simplified to the point of being wrong. I hope someone has the time to
correct it on the lines I give above.
Randy.
Randy Brukardt
...
> > Why is there not a difference? Won't the first actually use some
negative
> > power-of-2 as the delta?
>
> The LRM 3.5.10(2) is a good deal less than informative as to what this
> _Small_ might be. But unless I have been totally wrong all this time
> it specifies the value of the LSB of the type.
The small is defined in 3.5.9(8): "The set of values of a fixed point type
comprise the integral multiples of a value called the small of the type."
For the purposes of the original question, note that this applies to *all*
fixed point types. The only difference between ordinary and decimal fixed
point types is how the default value is determined. If it is specified for
an ordinary fixed point type, then that is the value used (of course).
Randy.
REH
Thank you. I appreciate you taking the time to explain that. Yes, I
was confused. I am coming from an Ada '83 background, and our compiler
didn't like base-10 smalls (thus my misunderstanding). I have been
looking for some information online, without much luck. The standard
is not very clear (to me), and none of my Ada books some to go indepth
on the subject.
REH
Simon Wright
> "Simon Wright" <si...@pushface.org> wrote in message
> news:m264kec...@grendel.local...
>> The LRM 3.5.10(2) is a good deal less than informative as to what
>> this _Small_ might be. But unless I have been totally wrong all
>> this time it specifies the value of the LSB of the type.
>
> The small is defined in 3.5.9(8): "The set of values of a fixed
> point type comprise the integral multiples of a value called the
> small of the type."
_Must_ remember to use the Search facility at AdaIC!
Randy Brukardt
Or (*horrors*) the *index*! ;-)
Don't worry, we all do it.
Randy.