* Re: What is Delta??
@ 2006-05-13 6:52 5% ` Martin Krischik
0 siblings, 0 replies; 57+ results
From: Martin Krischik @ 2006-05-13 6:52 UTC (permalink / raw)
Bjï¿œrn Persson wrote:
> Dennis Lee Bieber wrote:
>> (based upon your surname, I suspect you used the spellings common to
>> some other language -- Dutch, perhaps?)
>
> No, Martin just isn't all that good at spelling. There's nothing wrong
> with that, but with that in mind I wouldn't have expected him to run
> down others' spelling.
Bjï¿œrn, if it was just spelling I would not have said a thing. But typing "u"
instead of "you" is not a spelling mistake but intentional.
Netiquette is quite clear here: you read before you post. And anybody
reading the group would have spotted that we use full sentences in our
posting. He/She might also have stotted the "Ada decimal types" thead - if
there is one thing good about google groups its the search function.
Martin
--
mailto://krischik@users.sourceforge.net
Ada programming at: http://ada.krischik.com
^ permalink raw reply [relevance 5%]
* Re: What is Delta??
@ 2006-05-12 13:49 5% ` Martin Krischik
[not found] ` <0bd9625e9e1eg27a2140e8jp1mli25k61n@4ax.com>
0 siblings, 1 reply; 57+ results
From: Martin Krischik @ 2006-05-12 13:49 UTC (permalink / raw)
Hello Sathish,
Sathish Veluswamy wrote:
> Thanks for your help. I saw that link but still i find some
> difficulties in understanding about DELTA. So if you dont mind can u
> explain about DELTA in detail and if possible with an example.
what is there to understand? Delta declares a fixed point data type.
The same kind of fixed point data type you find in COBOL or PL/1. You
should have learned about fixed point data types at University or
Polytechnik. If not, you can read it up here:
http://en.wikipedia.org/wiki/Fixed-point_arithmetic
There was just recently a very exhaustive thread about Ada's fixed
point type under the heading "Ada decimal types" here at comp.lang.ada:
http://groups.google.com/group/comp.lang.ada/browse_thread/thread/16dbd7ecc6a3d50c
And I just remebered, I got an exapmple as well:
http://en.wikibooks.org/wiki/Ada_Programming/Algorithms/Chapter_6#No_64_bit_integers
http://svn.sourceforge.net/viewcvs.cgi/wikibook-ada/trunk/demos/Source/fibonacci_5.adb?view=markup
Hope that helps.
Martin
PS: its "you" not "u" - we are software engeneers here and not getto
kits.
^ permalink raw reply [relevance 5%]
* Re: Ada decimal types
2006-05-11 5:51 7% ` Simon Wright
@ 2006-05-11 22:33 7% ` Randy Brukardt
0 siblings, 0 replies; 57+ results
From: Randy Brukardt @ 2006-05-11 22:33 UTC (permalink / raw)
"Simon Wright" <simon@pushface.org> wrote in message
news:m21wv1cdmp.fsf@grendel.local...
> "Randy Brukardt" <randy@rrsoftware.com> writes:
>
> > "Simon Wright" <simon@pushface.org> wrote in message
> > news:m264kecudx.fsf@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!
Or (*horrors*) the *index*! ;-)
Don't worry, we all do it.
Randy.
^ permalink raw reply [relevance 7%]
* Re: Ada decimal types
2006-05-10 20:52 7% ` Randy Brukardt
@ 2006-05-11 5:51 7% ` Simon Wright
2006-05-11 22:33 7% ` Randy Brukardt
0 siblings, 1 reply; 57+ results
From: Simon Wright @ 2006-05-11 5:51 UTC (permalink / raw)
"Randy Brukardt" <randy@rrsoftware.com> writes:
> "Simon Wright" <simon@pushface.org> wrote in message
> news:m264kecudx.fsf@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!
^ permalink raw reply [relevance 7%]
* Re: Ada decimal types
2006-05-10 20:47 5% ` Randy Brukardt
@ 2006-05-10 21:26 7% ` REH
0 siblings, 0 replies; 57+ results
From: REH @ 2006-05-10 21:26 UTC (permalink / raw)
Randy Brukardt wrote:
> "REH" <spamjunk@stny.rr.com> wrote in message
> news:1147263720.249883.220580@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.
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
^ permalink raw reply [relevance 7%]
* Re: Ada decimal types
2006-05-10 5:37 7% ` Simon Wright
2006-05-10 12:22 7% ` REH
@ 2006-05-10 20:52 7% ` Randy Brukardt
2006-05-11 5:51 7% ` Simon Wright
1 sibling, 1 reply; 57+ results
From: Randy Brukardt @ 2006-05-10 20:52 UTC (permalink / raw)
"Simon Wright" <simon@pushface.org> wrote in message
news:m264kecudx.fsf@grendel.local...
...
> > 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.
^ permalink raw reply [relevance 7%]
* Re: Ada decimal types
2006-05-10 12:22 7% ` REH
@ 2006-05-10 20:47 5% ` Randy Brukardt
2006-05-10 21:26 7% ` REH
0 siblings, 1 reply; 57+ results
From: Randy Brukardt @ 2006-05-10 20:47 UTC (permalink / raw)
"REH" <spamjunk@stny.rr.com> wrote in message
news:1147263720.249883.220580@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.
^ permalink raw reply [relevance 5%]
* Re: Ada decimal types
2006-05-10 5:37 7% ` Simon Wright
@ 2006-05-10 12:22 7% ` REH
2006-05-10 20:47 5% ` Randy Brukardt
2006-05-10 20:52 7% ` Randy Brukardt
1 sibling, 1 reply; 57+ results
From: REH @ 2006-05-10 12:22 UTC (permalink / raw)
Simon Wright wrote:
> "REH" <me@you.com> writes:
>
> > "Randy Brukardt" <randy@rrsoftware.com> wrote in message
> > news:8KadnYXCB-5FKMLZnZ2dneKdnZydnZ2d@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.
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
^ permalink raw reply [relevance 7%]
* Re: Ada decimal types
2006-05-09 23:21 7% ` REH
2006-05-10 1:08 7% ` Keith Thompson
@ 2006-05-10 5:37 7% ` Simon Wright
2006-05-10 12:22 7% ` REH
2006-05-10 20:52 7% ` Randy Brukardt
1 sibling, 2 replies; 57+ results
From: Simon Wright @ 2006-05-10 5:37 UTC (permalink / raw)
"REH" <me@you.com> writes:
> "Randy Brukardt" <randy@rrsoftware.com> wrote in message
> news:8KadnYXCB-5FKMLZnZ2dneKdnZydnZ2d@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.
^ permalink raw reply [relevance 7%]
* Re: Ada decimal types
2006-05-09 23:21 7% ` REH
@ 2006-05-10 1:08 7% ` Keith Thompson
2006-05-10 5:37 7% ` Simon Wright
1 sibling, 0 replies; 57+ results
From: Keith Thompson @ 2006-05-10 1:08 UTC (permalink / raw)
"REH" <me@you.com> writes:
> "Randy Brukardt" <randy@rrsoftware.com> wrote in message
> news:8KadnYXCB-5FKMLZnZ2dneKdnZydnZ2d@megapath.net...
>>
>> "REH" <me@you.com> wrote in message
>> news:yj47g.23728$ZQ3.20636@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?
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.
--
Keith Thompson (The_Other_Keith) kst-u@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.
^ permalink raw reply [relevance 7%]
* Re: Ada decimal types
2006-05-08 21:19 6% ` Randy Brukardt
@ 2006-05-09 23:21 7% ` REH
2006-05-10 1:08 7% ` Keith Thompson
2006-05-10 5:37 7% ` Simon Wright
0 siblings, 2 replies; 57+ results
From: REH @ 2006-05-09 23:21 UTC (permalink / raw)
"Randy Brukardt" <randy@rrsoftware.com> wrote in message
news:8KadnYXCB-5FKMLZnZ2dneKdnZydnZ2d@megapath.net...
>
> "REH" <me@you.com> wrote in message
> news:yj47g.23728$ZQ3.20636@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
^ permalink raw reply [relevance 7%]
* Re: Ada decimal types
2006-05-06 16:39 7% ` REH
@ 2006-05-08 21:19 6% ` Randy Brukardt
2006-05-09 23:21 7% ` REH
0 siblings, 1 reply; 57+ results
From: Randy Brukardt @ 2006-05-08 21:19 UTC (permalink / raw)
"REH" <me@you.com> wrote in message
news:yj47g.23728$ZQ3.20636@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;
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.
^ permalink raw reply [relevance 6%]
* Re: Ada decimal types
2006-05-06 15:48 6% ` Simon Wright
@ 2006-05-06 16:39 7% ` REH
2006-05-08 21:19 6% ` Randy Brukardt
0 siblings, 1 reply; 57+ results
From: REH @ 2006-05-06 16:39 UTC (permalink / raw)
"Simon Wright" <simon@pushface.org> wrote in message
news:m2k68zm9xl.fsf@grendel.local...
> "REH" <me@you.com> writes:
>
>> "Keith Thompson" <kst-u@mib.org> wrote in message
>> news:lnmzdvttoc.fsf@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?
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
^ permalink raw reply [relevance 7%]
* Re: Ada decimal types
2006-05-06 14:01 7% ` REH
@ 2006-05-06 15:48 6% ` Simon Wright
2006-05-06 16:39 7% ` REH
0 siblings, 1 reply; 57+ results
From: Simon Wright @ 2006-05-06 15:48 UTC (permalink / raw)
"REH" <me@you.com> writes:
> "Keith Thompson" <kst-u@mib.org> wrote in message
> news:lnmzdvttoc.fsf@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?
^ permalink raw reply [relevance 6%]
* Re: Ada decimal types
2006-05-06 8:59 7% ` Keith Thompson
@ 2006-05-06 14:01 7% ` REH
2006-05-06 15:48 6% ` Simon Wright
0 siblings, 1 reply; 57+ results
From: REH @ 2006-05-06 14:01 UTC (permalink / raw)
"Keith Thompson" <kst-u@mib.org> wrote in message
news:lnmzdvttoc.fsf@nuthaus.mib.org...
> "REH" <me@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
^ permalink raw reply [relevance 7%]
* Re: Ada decimal types
2006-05-05 18:08 7% ` REH
2006-05-05 18:49 7% ` tmoran
@ 2006-05-06 8:59 7% ` Keith Thompson
2006-05-06 14:01 7% ` REH
1 sibling, 1 reply; 57+ results
From: Keith Thompson @ 2006-05-06 8:59 UTC (permalink / raw)
"REH" <me@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.
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) kst-u@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.
^ permalink raw reply [relevance 7%]
* Re: Ada decimal types
2006-05-05 11:33 7% ` REH
2006-05-05 16:49 5% ` tmoran
@ 2006-05-05 20:32 7% ` Randy Brukardt
1 sibling, 0 replies; 57+ results
From: Randy Brukardt @ 2006-05-05 20:32 UTC (permalink / raw)
"REH" <me@you.com> wrote in message
news:sKG6g.6427$TT.4592@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.
^ permalink raw reply [relevance 7%]
* Re: Ada decimal types
2006-05-05 18:49 7% ` tmoran
@ 2006-05-05 18:59 7% ` REH
0 siblings, 0 replies; 57+ results
From: REH @ 2006-05-05 18:59 UTC (permalink / raw)
<tmoran@acm.org> wrote in message news:Idednavn8KnKA8bZRVn-ig@comcast.com...
> >I do know how fixed points "work." You are making assumptions about my
>>expectations and the standard. Both of which are wrong.
> I tried to figure out "why would he ask such questions?" and the only
> 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.
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
^ permalink raw reply [relevance 7%]
* Re: Ada decimal types
2006-05-05 18:08 7% ` REH
@ 2006-05-05 18:49 7% ` tmoran
2006-05-05 18:59 7% ` REH
2006-05-06 8:59 7% ` Keith Thompson
1 sibling, 1 reply; 57+ results
From: tmoran @ 2006-05-05 18:49 UTC (permalink / raw)
>I do know how fixed points "work." You are making assumptions about my
>expectations and the standard. Both of which are wrong.
I tried to figure out "why would he ask such questions?" and the only
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.
^ permalink raw reply [relevance 7%]
* Re: Ada decimal types
2006-05-05 16:49 5% ` tmoran
@ 2006-05-05 18:08 7% ` REH
2006-05-05 18:49 7% ` tmoran
2006-05-06 8:59 7% ` Keith Thompson
0 siblings, 2 replies; 57+ results
From: REH @ 2006-05-05 18:08 UTC (permalink / raw)
<tmoran@acm.org> wrote in message news:ZcKdnZAJrtSdH8bZRVn-jQ@comcast.com...
>> 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 think you are expecting a fixed point decimal type to be stored in
> 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.
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
^ permalink raw reply [relevance 7%]
* Re: Ada decimal types
2006-05-05 11:33 7% ` REH
@ 2006-05-05 16:49 5% ` tmoran
2006-05-05 18:08 7% ` REH
2006-05-05 20:32 7% ` Randy Brukardt
1 sibling, 1 reply; 57+ results
From: tmoran @ 2006-05-05 16:49 UTC (permalink / raw)
> 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 think you are expecting a fixed point decimal type to be stored in
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.
^ permalink raw reply [relevance 5%]
* Re: Ada decimal types
2006-05-05 9:14 7% ` Stephen Leake
@ 2006-05-05 11:33 7% ` REH
2006-05-05 16:49 5% ` tmoran
2006-05-05 20:32 7% ` Randy Brukardt
0 siblings, 2 replies; 57+ results
From: REH @ 2006-05-05 11:33 UTC (permalink / raw)
"Stephen Leake" <stephen_leake@acm.org> wrote in message
news:u1wv8dea6.fsf@acm.org...
> "REH" <spamjunk@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.
Instead of the record. The 32-bit values are explained above.
>
> 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
^ permalink raw reply [relevance 7%]
* Re: Ada decimal types
2006-05-04 15:23 7% Ada decimal types REH
2006-05-04 18:17 7% ` Jeffrey R. Carter
@ 2006-05-05 9:14 7% ` Stephen Leake
2006-05-05 11:33 7% ` REH
1 sibling, 1 reply; 57+ results
From: Stephen Leake @ 2006-05-05 9:14 UTC (permalink / raw)
"REH" <spamjunk@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.
I would also use a 64 bit fixed point type, rather than a split
record, but you probably can't change that.
--
-- Stephe
^ permalink raw reply [relevance 7%]
* Re: Ada decimal types
2006-05-04 18:17 7% ` Jeffrey R. Carter
@ 2006-05-04 22:20 7% ` REH
0 siblings, 0 replies; 57+ results
From: REH @ 2006-05-04 22:20 UTC (permalink / raw)
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
^ permalink raw reply [relevance 7%]
* Re: Ada decimal types
2006-05-04 15:23 7% Ada decimal types REH
@ 2006-05-04 18:17 7% ` Jeffrey R. Carter
2006-05-04 22:20 7% ` REH
2006-05-05 9:14 7% ` Stephen Leake
1 sibling, 1 reply; 57+ results
From: Jeffrey R. Carter @ 2006-05-04 18:17 UTC (permalink / raw)
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.
--
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
^ permalink raw reply [relevance 7%]
* Ada decimal types
@ 2006-05-04 15:23 7% REH
2006-05-04 18:17 7% ` Jeffrey R. Carter
2006-05-05 9:14 7% ` Stephen Leake
0 siblings, 2 replies; 57+ results
From: REH @ 2006-05-04 15:23 UTC (permalink / raw)
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.
Thanks,
REH
^ permalink raw reply [relevance 7%]
* Re: Information Systems Annex (usefulness of Decimal Floats)
2002-08-15 9:26 0% ` Robert Dewar
2002-08-15 21:54 0% ` Decimal Floating types was " Robert C. Leif
@ 2002-08-16 15:47 0% ` Warren W. Gay VE3WWG
1 sibling, 0 replies; 57+ results
From: Warren W. Gay VE3WWG @ 2002-08-16 15:47 UTC (permalink / raw)
Robert Dewar wrote:
> "Robert C. Leif" <rleif@rleif.com> wrote in message news:<mailman.1029282844.28090.comp.lang.ada@ada.eu.org>...
>
>>Ada decimal types (as currently defined) are fixed-point
>>types.
>>
>>Are you asking for decimal floating-point?
>
> Decimal floating-point would be quite useless in financial
> applications as far as I can see (COBOL does not have this
> facility).
"Useless" is extreme. There are situations where decimal floating
point is useful in computing financial values, but normally as
intermediate results. The final values of financial calculations
are obviously stored in fixed point.
Currency conversions are often performed in floating point
decimal since the currencies move all over the map in
relative terms in terms of scale. As long as the precision
is maintained in the intermediate results, and that you
properly anticipate the resulting scale and precision, the
use of decimal floats as intermediates work well, with
the final results being stored in a fixed point decimal form.
One recent example of this, was the Euro conversion,
where we had to do those triangulation computations (three
currencies were involved). You have a broad range of values
between British pound and the Turkish Lira, for example.
For smaller numbers you might still cry foul, but when you're
computing the asset value of fund or fund(s) or management
company(ies), you run into larger numbers ;-)
Again of course, you _could_ structure your computations such
that you don't need decimal floats, but this requires
extreme care and good testing (something you don't often
get from junior programmers - but that is a different issue ;-).
So often it is just easier and safer to use decimal floats
provided that the necessary precision is maintained.
As a side note I should mention that in C/C++ code, floating
point decimal is really the only other choice to binary
floating point values. Database vendors INFORMIX
and ORACLE for example, provide routines for decimal
floating point computations (but not for fixed point).
--
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg
^ permalink raw reply [relevance 0%]
* Decimal Floating types was RE: Information Systems Annex was RE: Dispatching and generics - language lawyer question
2002-08-15 9:26 0% ` Robert Dewar
@ 2002-08-15 21:54 0% ` Robert C. Leif
2002-08-16 15:47 0% ` Information Systems Annex (usefulness of Decimal Floats) Warren W. Gay VE3WWG
1 sibling, 0 replies; 57+ results
From: Robert C. Leif @ 2002-08-15 21:54 UTC (permalink / raw)
From: Bob Leif
To: Robert Dewar et al.
Please see IBM http://www2.hursley.ibm.com/decimal/
"Standard Decimal Arithmetic"
"Most computers today support binary floating-point in hardware. While
suitable for many purposes, binary floating-point should not be used for
financial, commercial, and user-centric applications and web services
because the decimal data used in these applications cannot be
represented exactly using binary floating-point. (See the Frequently
Asked Questions page for more reasons and examples.) "
"The problems of binary floating-point can be avoided by using base 10
(decimal) exponents and preserving those exponents where possible. This
site describes a decimal arithmetic which achieves the necessary results
and conforms to the relevant ANSI and IEEE standards. Notably, a single
data type can be used for integer, fixed-point, and floating-point
decimal arithmetic."
Since COBOL does not have a decimal floating point, COBOL programmers,
who still do most of the financial applications, have not had a chance
to try it!. There is another class of financial programmers, the Wall
Street analysts. The analysts do derivatives and other exotic financial
instruments. Do they use conventional binary floating point or COBOL
decimal?
I might note that you have in the past quite properly cautioned on the
complexity of conventional floating point calculations. One good way to
check them would be to employ a decimal floating point.
On a philosophical level, since computers are supposed to work for
humans, why not have them work in the most understandable way? I would
greatly prefer my spreadsheets and computer assisted mechanical design
programs be in decimal. Humans work in pseudo-integer space. We like our
numbers and dimensions, in particular, to be a float that corresponds to
an integer followed by a decimal point, followed by zeros. Designers do
not like to fiddle with a dimension that comes out 28.998. We greatly
prefer 29.000.
-----Original Message-----
From: comp.lang.ada-admin@ada.eu.org
[mailto:comp.lang.ada-admin@ada.eu.org] On Behalf Of Robert Dewar
Sent: Thursday, August 15, 2002 2:27 AM
To: comp.lang.ada@ada.eu.org
Subject: Re: Information Systems Annex was RE: Dispatching and generics
- language lawyer question
"Robert C. Leif" <rleif@rleif.com> wrote in message
news:<mailman.1029282844.28090.comp.lang.ada@ada.eu.org>...
> Ada decimal types (as currently defined) are fixed-point
> types.
>
> Are you asking for decimal floating-point?
Decimal floating-point would be quite useless in financial
applications as far as I can see (COBOL does not have this
facility). What you need in financial calculations is decimal
fixed-point, and very occasionally (this has only
recently been included in the COBOL standard) binary fpt.
^ permalink raw reply [relevance 0%]
* Re: Information Systems Annex was RE: Dispatching and generics - language lawyer question
2002-08-13 23:53 7% ` Robert C. Leif
@ 2002-08-15 9:26 0% ` Robert Dewar
2002-08-15 21:54 0% ` Decimal Floating types was " Robert C. Leif
2002-08-16 15:47 0% ` Information Systems Annex (usefulness of Decimal Floats) Warren W. Gay VE3WWG
0 siblings, 2 replies; 57+ results
From: Robert Dewar @ 2002-08-15 9:26 UTC (permalink / raw)
"Robert C. Leif" <rleif@rleif.com> wrote in message news:<mailman.1029282844.28090.comp.lang.ada@ada.eu.org>...
> Ada decimal types (as currently defined) are fixed-point
> types.
>
> Are you asking for decimal floating-point?
Decimal floating-point would be quite useless in financial
applications as far as I can see (COBOL does not have this
facility). What you need in financial calculations is decimal
fixed-point, and very occasionally (this has only
recently been included in the COBOL standard) binary fpt.
^ permalink raw reply [relevance 0%]
* RE: Information Systems Annex was RE: Dispatching and generics - language lawyer question
2002-08-13 17:37 7% ` Keith Thompson
@ 2002-08-13 23:53 7% ` Robert C. Leif
2002-08-15 9:26 0% ` Robert Dewar
0 siblings, 1 reply; 57+ results
From: Robert C. Leif @ 2002-08-13 23:53 UTC (permalink / raw)
From: Bob Leif
To: Keith Thompson et al.
I would be happy with a decimal floating-point; but, would gladly settle
for a less elegant work-around.
Since I have never worked with binary fixed-point types, please forgive
a naive question. Would the same capacity to create types with exponents
at run-time be of any use or is this equivalent to floating-point?
-----Original Message-----
From: comp.lang.ada-admin@ada.eu.org
[mailto:comp.lang.ada-admin@ada.eu.org] On Behalf Of Keith Thompson
Sent: Tuesday, August 13, 2002 10:38 AM
To: comp.lang.ada@ada.eu.org
Subject: Re: Information Systems Annex was RE: Dispatching and generics
- language lawyer question
"Robert C. Leif" <rleif@rleif.com> writes:
[...]
> I also believe that a way around the static requirement for Ada
decimals
> should be created. I still would like to use the slide-rule formula to
> calculate the exponent. Would a pragma To_Static be possible?
If you're talking about a fundamental change to the way certain types
are implemented and represented, I don't think a pragma is the way to
do it. Ada decimal types (as currently defined) are fixed-point
types.
Are you asking for decimal floating-point?
--
Keith Thompson (The_Other_Keith) kst@cts.com
<http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://www.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"
^ permalink raw reply [relevance 7%]
* Re: Information Systems Annex was RE: Dispatching and generics - language lawyer question
@ 2002-08-13 17:37 7% ` Keith Thompson
2002-08-13 23:53 7% ` Robert C. Leif
0 siblings, 1 reply; 57+ results
From: Keith Thompson @ 2002-08-13 17:37 UTC (permalink / raw)
"Robert C. Leif" <rleif@rleif.com> writes:
[...]
> I also believe that a way around the static requirement for Ada decimals
> should be created. I still would like to use the slide-rule formula to
> calculate the exponent. Would a pragma To_Static be possible?
If you're talking about a fundamental change to the way certain types
are implemented and represented, I don't think a pragma is the way to
do it. Ada decimal types (as currently defined) are fixed-point
types.
Are you asking for decimal floating-point?
--
Keith Thompson (The_Other_Keith) kst@cts.com <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://www.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"
^ permalink raw reply [relevance 7%]
* Re: Floating Decimal Package/Library?
2002-07-22 23:33 6% ` Robert I. Eachus
@ 2002-07-23 13:16 0% ` Marin David Condic
0 siblings, 0 replies; 57+ results
From: Marin David Condic @ 2002-07-23 13:16 UTC (permalink / raw)
More out of curiosity than anything else: Some hardware supports Binary
Coded Decimal (BCD) which was there to support Cobol-like numeric values.
(Its been a while, but IIRC, the MC680x0 supported it.) I'd suspect that BCD
would be suitable for Ada's decimal types. How would this apply here? What
would it likely look like under the hood? Would it be a better answer than
using some sort of scaled integer?
MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas www.pacemicro.com
Enabling the digital revolution
e-Mail: marin.condic@pacemicro.com
"Robert I. Eachus" <rieachus@attbi.com> wrote in message
news:3D3C963D.5020304@attbi.com...
>
> Ada decimal fixed point types are decimal. Unless you insist on peeking
> under the covers, you need know nothing else. But if you insist on
> peeking, read on.
>
> Decimal types are implemented as (almost always twos-complement) binary
> integer representations, with a static divisor that is a power of ten.
> So if you say:
^ permalink raw reply [relevance 0%]
* Re: Floating Decimal Package/Library?
@ 2002-07-22 23:33 6% ` Robert I. Eachus
2002-07-23 13:16 0% ` Marin David Condic
0 siblings, 1 reply; 57+ results
From: Robert I. Eachus @ 2002-07-22 23:33 UTC (permalink / raw)
Warren W. Gay VE3WWG wrote:
> Are you sure that it is "binary fixed point". Is Robert lurking
> about here?
You may have been looking for Robert Dewar, but I think I am at least
one of the right Roberts to answer this.
Ada decimal fixed point types are decimal. Unless you insist on peeking
under the covers, you need know nothing else. But if you insist on
peeking, read on.
Decimal types are implemented as (almost always twos-complement) binary
integer representations, with a static divisor that is a power of ten.
So if you say:
type Dollars is delta 0.01 digits 10;
You get a type that can exactly represent hundredths of dollars, and
more important, cannot represent any value that is not an exact multiple
of one cent. (Or more generally all values of the type must be a
multiple of 'Small.)
However, there is another thing you may care about. The maximum
representable value is not specified for the type Dollars above. The
implementation (compiler) may choose any representation as long as all
values from -99_999_999.99..99_999_999.99 are exactly representable.
But the actual data type may allow larger values. In this case, I would
not be surprised if the representation used 64-bit signed integers, and
allowed values up to 184_467_440_737_095_516.15. But if you want to
restrict the values of the type you can put a range constraint on the
type declaration:
type Dollars is delta 0.01 digits 10
range -99_999_999.99..99_999_999.99;
My recommended approach for Cobol/SQL style programming is to declare
most base types like Dollars without a range constraint, and have
constrained subtypes:
subtype Salary is Dollars range 0.0..10_000_000.00;
...for all database fields. If the underlying database wants to store
this as a string, seems wasteful to me but okay.
Now for the really gory stuff. What about PostGres support for a
thousand digits of floating decimal arithmetic? Chump change. ;-) In
Ada the results of certain operations on fixed point types are required
to be represented exactly. In practice values of type _universal_fixed_
exist only to make your life easier. (And sometimes the life of the
compiler implementor more complex.) For example, in the calculation:
Base_Wages := Dollars(Hours_Worked * Base_Pay);
Hours_Worked might be represented in tenths of hours and Base_Pay in
mills (thousanths of a dollar). Doesn't matter, the result of the
multiplication will only be rounded once, to the Dollars type, and will
only overflow if the result is outside the bounds of Dollars (or
Base_Wages!!!). If you don't want rounding, but truncation to the
nearest cent use:
Base_Wages := Dollars'Truncation(Hours_Worked * Base_Pay);
...but be sure to check the union contract first. ;-)
^ permalink raw reply [relevance 6%]
* RE: Floating Decimal Package/Library?
@ 2002-07-17 2:53 7% ` Robert C. Leif
0 siblings, 0 replies; 57+ results
From: Robert C. Leif @ 2002-07-17 2:53 UTC (permalink / raw)
From: Bob Leif
To: Tom Moran et al.
I do not intend to return to my slide-rule. However, I would like to be
able to optimize the precision of my calculations. Since Turkish Lira
have been mentioned, when one tries to directly calculate currency
equivalents based on the exchange rate between any two currencies,
Ada.Decimal did not appear to permit optimizing the exponent of ratios.
I admit that this is somewhat contrived and one could be US dollar
centric and employ the dollar or one other currency as a common
intermediate.
Again, I would prefer to use decimals for engineering and scientific
calculations.
-----Original Message-----
From: comp.lang.ada-admin@ada.eu.org
[mailto:comp.lang.ada-admin@ada.eu.org] On Behalf Of tmoran@acm.org
Sent: Tuesday, July 16, 2002 6:25 PM
To: comp.lang.ada@ada.eu.org
Subject: RE: Floating Decimal Package/Library?
> > What kind of financial software needs more than 18 decimal digits?
> The problem is not precision. It is the choice of the value for the
> exponent
>
> If I divide X * 10**5 by Y * 10**2, I want the result to be Z * 10**3.
> This is what I did with a slide-rule 50 years ago!
What's the interest, at 4.75% p.a., for the first month of a $10,000
loan. To-the-penny accuracy required. I doubt you could read off all
four digits of $39.58 on your slide rule. The slide rule and floating
point both have excellent range, but poor precision. You use both
because they are, respectively, faster than full precision paper and
pencil or a full precision multi-digit arithmetic subroutine package,
and because a few digits and an exponent take less paper/RAM. It's a
tradeoff of accuracy for speed+space. Unless there's a speed or space
problem using full 18 digit decimal numbers, you needn't make that
tradeoff - you can cover the entire US GNP and have accuracy to the
penny at the same time by using Ada's decimal fixed point types.
^ permalink raw reply [relevance 7%]
* Re: Depending on passing mechanism
@ 1997-10-24 0:00 7% ` Robert Dewar
0 siblings, 0 replies; 57+ results
From: Robert Dewar @ 1997-10-24 0:00 UTC (permalink / raw)
Henry says
<<I agree that Ada's attempts to provide accurate ranges of numbers are
laudable. But PL/I and Cobol offered equally (some would say more
equally) powerful capabilities>>
This is technical nonsense. I assume it means that Henry does not
know COBOL. In COBOL, you can specify the precision of a number only
by giving the number of digits (i.e. equivalent to the digits phrase
in an Ada decimal declaration). There is no capability to declare a
specific range, i.e. there is no equivalent in COBOL of the Ada
declaration:
type x is delta 0.01 digits 5 range 1.00 .. 123.67;
The nearest that COBOL can come is
PICTURE S999V99.
which captures the delta and digits but not the range.
In the binary case, the situation is even worse, since one can still only
specify a range in decimal digits. The normal technique in COBOL is to
write:
05 FIELD1 COMP-4 PICTURE S9(4).
and know that really the range of FIELD1 will be 16-bits signed and
therefore have a range of -32768 .. +32767. All arithmetic with
FIELD1 will be done without using the ON SIZE ERROR, and everything
works out OK, but without proper error checking.
Note also the limitation that in COBOL, even the decimal range is
enforced only if every arithmetic operation specifies ON SIZE ERROR.
The situation in PL/1 with respect to decimal types is identical to
COBOL. The binary situation is better, since ranges can at least
be given in powers of 2, but it is still not possible (at least
in ANSI PL/1, who knows what has happened since) to specify
specific binary ranges.
Anyone would say that COBOL and PL/1 offer "more powerful" capabilities
in this area must presumably be as ignorant about COBOL and PL/1 as
Henry obviously is.
^ permalink raw reply [relevance 7%]
* Re: Tagged Types and Generics
1997-04-21 0:00 8% Tagged Types and Generics Robert C. Leif, Ph.D.
@ 1997-04-24 0:00 6% ` Jeff Carter
0 siblings, 0 replies; 57+ results
From: Jeff Carter @ 1997-04-24 0:00 UTC (permalink / raw)
Robert C. Leif, Ph.D. wrote:
>...
> generic
>
> type Num_Or_Denom is delta <> digits <>;
> type Ratio is delta <> digits <>;
>
> package Dec_Divide is
>
> type Num_Or_Denoms is abstract tagged private;
> --This the start of the class
>
> Function Ratio_Test(Numerator : in Num_Or_Denoms'Class;
> Denominator : in Num_Or_Denoms'Class)
> return Ratio;
> Private
> type Num_Or_Denoms is abstract tagged
> record
> The_Num_Or_Denom : Num_Or_Denom;
> Num_Or_Denom_Scale: Integer := Num_Or_Denom'Scale;
> Num_Or_Denom_digits: Integer := Num_Or_Denom'digits ;
> end record;
> end Dec_Divide;
I don't see any point to this. All objects in Num_Or_Denoms'Class have
the same type for component The_Num_Or_Denom, and the same default
values for components Num_Or_Denom_Scale and Num_Or_Denom_Digits.
> 46. Procedure Divide is new Ada.Decimal.Divide
> 47. (Dividend_type => Gen_Numerator,
> 48. Divisor_Type => Gen_Denominator,
> 49. Quotient_Type => Ratio,
> 50. Remainder_Type => Ratio);
> 51.
> 52. Use Divide;
> |
> >>> "Divide" is not a usable package
This instantiation creates a procedure. You can't "use" a procedure.
If you could do it, this would be the same as
procedure Divide is new Ada.Decimal.Divide
(Dividend_Type => Num_Or_Denom,
Divisor_Type => Num_Or_Denom,
Quotient_Type => Ratio,
Remainder_Type => Ratio);
unless you somehow changed the values of the components
Num_Or_Denom_Scale and Num_Or_Denom_Digits. Perhaps you had planned on a
way to do this, but it's not clear from your post.
Even if you change these values, the numbers you are dividing are still
of type Num_Or_Denom, and your result of type Ratio. You are simply
performing a conversion to another type, equivalent to:
type Z is delta A digits B;
type Y is delta C digits D;
type X is delta E digits F;
type W is delta G digits H;
procedure Divide is new Ada.Decimal.Divide (Dividend_Type => Y,
Divisor_Type => X,
Quotient_Type => W,
Remainder_Type => W);
Dend : Z;
Sor : Z;
Quot : W;
Rmdr : W;
...
Divide (Dividend => Y (Dend),
Divisor => X (Sor),
Quotient => Quot,
Remainder => Rmdr);
Watch out for the auntie-spam return address.
--
Jeff Carter ( carter @ innocon . com ) PGP:1024/440FBE21
"Now go away, or I shall taunt you a second time." Monty Python & the
Holy Grail
^ permalink raw reply [relevance 6%]
* Tagged Types and Generics
@ 1997-04-21 0:00 8% Robert C. Leif, Ph.D.
1997-04-24 0:00 6% ` Jeff Carter
0 siblings, 1 reply; 57+ results
From: Robert C. Leif, Ph.D. @ 1997-04-21 0:00 UTC (permalink / raw)
From: Bob Leif, Ph.D.
To: Comp.Lang.Ada
Date: 21 April, 1997
Subject: Tagged Types and Generics.
Background: Recently, Tom Moran, Randy Brukard and I wrote a paper. "Ada
95, The Language Speaks for Itself". This paper will appear in the May
Object Magazine. In this paper we modeled money as a decimal type and did
inheritance directly via a generic. I had suggested modeling money as a
tagged type. My co-authors very wisely vetoed that approach. After the
paper was submitted, I attempted to do my suggestion and model money as a
tagged type with the child libraries being the different currencies. If
one makes the exchange rate a decimal type, then currency conversion
requires a decimal division of the same field from two of the child library
units. I created a function with class based types and tried to
instantiate the generic procedure Divide in the Annex F Package
Ada.Decimal. My lack of success is described in the listing of the body
below. The program has been reduced and modified to demonstrate the
problem. I know that I could probably get away with using a floating point
type. However, if we are to sell Ada to the MIS world based in part on its
capacity to do decimal arithmetic, then we should employ decimal arithmetic
in our programs.
I do not know how to pass the type an element in a tagged record to a
generic. I tried recreating the type by including the values of the Scale
and Digits attributes in the tagged record. I would appreciate suggestions
and hope for a solution that I could show at the ACM SigAda booth at Object
Expo in New York City from 2-5 June, 1997.
Both the specification and body were compiled under GNAT for Windows.
gcc -c -gnatlv dec_divide.adb > dec_divide.txt
Specification source.
generic
type Num_Or_Denom is delta <> digits <>;
type Ratio is delta <> digits <>;
package Dec_Divide is
type Num_Or_Denoms is abstract tagged private;
--This the start of the class
Function Ratio_Test(Numerator : in Num_Or_Denoms'Class;
Denominator : in Num_Or_Denoms'Class)
return Ratio;
Private
type Num_Or_Denoms is abstract tagged
record
The_Num_Or_Denom : Num_Or_Denom;
Num_Or_Denom_Scale: Integer := Num_Or_Denom'Scale;
Num_Or_Denom_digits: Integer := Num_Or_Denom'digits ;
end record;
end Dec_Divide;
----------------------------------------------------------------------------
------------------------------
Listing of body.
GNAT 3.09 (970121) Copyright 1991-1996 Free Software Foundation, Inc.
Compiling: dec_divide.adb (source file time stamp: 1997-04-22 05:24:59)
1. -- From Ada 95 Referance Manual pages 47-48 Section 3.5.10
2. -- S'Scale
3. -- S'Scale denotes the scale of the subtype S, defined as the
4. -- value N such that S'Delta = 10.0**(-N). The scale indicates
5. -- the position of the point relative to the rightmost
6. -- significant digits of values of subtype S. The value
7. -- of this attribute is of the type universal_integer.
8.
9. -- Note 38. S'Scale is not always the same as S'Aft for a
10. -- decimal subtype; for example, if S'Delta = 1.0 then S'Aft
11. -- is 1 while S'Scale is 0.
12.
13. --S'Digits
14. --S'Digits denotes the digits of the decimal fixed point subtype S,
15. --which corresponds to the number of decimal digits that are
16. --representable in objects of the subtype. The value of this attribute
17. --is of the type universal_integer.
18.
19. -- Note 39. The predefined operations of a fixed point type
20. -- include the assignment operation, qualification,
21. -- the membership tests, and explicit conversion to and
22. -- from other numeric types. They also include the relational
23. -- operators and the following predefined arithmetic operators:
24. -- the binary and unary adding operators - and +,
25. -- multiplying operators, and the unary operator abs.
26.
27. with Ada.Decimal;
28.
29. package body Dec_Divide is
30. Function Ratio_Test(Numerator : in Num_Or_Denoms'Class;
31. Denominator : in Num_Or_Denoms'Class)
32. return Ratio is
33.
34. --This may require access types for the decimals types, which
are
35. --dynamic rather than static. Maybe define box with a generic
in the
36. --specification and pass over. With a pointer, one gets a
general
37. --structure.
38.
39. Type Gen_Numerator is delta
10.0**(-Numerator.Num_Or_Denom_Scale)
|
>>> non-static expression used for delta value
40. digits Numerator.Num_Or_Denom_digits;
|
>>> non-static expression used for digits value
41.
42. Type Gen_Denominator is delta 10.0**(-
Denominator.Num_Or_Denom_Scale)
|
>>> non-static expression used for delta value
43. digits Denominator.Num_Or_Denom_digits;
|
>>> non-static expression used for digits value
44.
45.
46. Procedure Divide is new Ada.Decimal.Divide
47. (Dividend_type => Gen_Numerator,
48. Divisor_Type => Gen_Denominator,
49. Quotient_Type => Ratio,
50. Remainder_Type => Ratio);
51.
52. Use Divide;
|
>>> "Divide" is not a usable package
53. The_Numerator: Gen_Numerator :=
Gen_Numerator(Numerator.The_Num_Or_Denom);
54.
55. The_Denominator:Gen_Denominator :=
Gen_Denominator(Denominator.The_Num_Or_Denom);
56. The_Ratio: Ratio;
57. The_Remainder: Ratio;
58. begin --Ratio_Test
59.
60. Divide
61. (Dividend => The_Numerator,
62. Divisor => The_Denominator,
63. Quotient => The_Ratio,
64. Remainder => The_Remainder);
65. Return The_Ratio;
66. end Ratio_Test;
67. end Dec_Divide;
67 lines:
Robert C. Leif, Ph.D., PMIAC
Vice President & Research Director
Ada_Med, a Division of Newport Instruments
5648 Toyon Road
San Diego, CA 92115-1022
Tel. & Fax (619) 582-0437
E-mail rleif@rleif.com
^ permalink raw reply [relevance 8%]
* Re: Leading zeros with Int_IO.Put()? Or another package?
1996-11-13 0:00 0% ` Ken Garlington
@ 1996-11-19 0:00 6% ` robin
0 siblings, 0 replies; 57+ results
From: robin @ 1996-11-19 0:00 UTC (permalink / raw)
Ken Garlington <garlingtonke@lmtas.lmco.com> writes:
>robin wrote:
>>
>> dewar@merv.cs.nyu.edu (Robert Dewar) writes:
>>
>> >robin says
>>
>> >>"Interface to PL/I and you can use standard I/O:
>>
>> >>put edit (n) (P'-99999999');
>>
>> >>and you don't have to worry about whether the number is
>> >>negative either. The nines in the picture format
>> >>force leading zeros to print.
>>
>> >>And if you want, you can insert commas in the output
>> >>to make it more readable. The picture specification becomes:
>>
>> >I guess robin knows PL/1 and does not know Ada!
>>
>> >If you want to use picture editing to solve this kind of problem, then
>> >use the picture editing in Ada, no need to wander off into PL/1, even in
>> >the unlikely case that you have a PL/1 compiler at hand. Personally I
>> >dislike the picture stuff in PL/1, they tried to improve on COBOL and
>> >made a mess of it.
>>
>> Isn't it amazing! Robert Dewar [among others] already has
>> had an opportunity to reply in this vein to the original
>> posting and subsequent ones, but it didn't occur to him to
>> do so, more than likely because he didn't know that a limited
>> facility existed in Ada. Instead, he suggested using
>> string facilities.
>Actually, if you know Ada, it's not amazing at all. The Ada picture I/O is for
>decimal types; the original request was for integer types. If you don't want to
>convert your type,
Really! The task is to convert to string type. You're saying
that that's not a type conversion.
the suggestion by Dr. Dewar is more straight-forward. If you
>do want to use picture I/O, you probably still want to use an abstraction of
>this facility to hide the details of type conversion, instantiation of picture I/O,
>etc.
>Ada people have this perversity of suggesting the most straight-forward and
>maintainable approach first. :)
>>
>> Below is Robert Dewar's previous posting:
>>
>> >This is a place where CLEARLY there is a missing abstraction (Put with
>> >leading zeros), and it seems obvious that you fix this in the way that
>> >you always do abstraction extension, you create an appropriate abstraction
>> >and use it. If it is useful enough, hopefully it gets to be widely available.
>>
>> >Note that if you do want to construct on the fly, a much clearer way is to
>> >use the string routines from the string packages, which have padding
>> >capabilities.
>>
>> PL/I is not restricted to picture editing with decimal data,
>> (one poster suggested changing to Ada decimal data in order to use
>> Ada's limited editing). PL/I requires *only* the single line:
>>
>> put edit (n) (P'-99999999');
>>
>> and not the (up to) page of Ada code to implement the
>> requirement of the original post.
^ permalink raw reply [relevance 6%]
* Re: Leading zeros with Int_IO.Put()? Or another package?
@ 1996-11-13 0:00 6% ` robin
1996-11-13 0:00 0% ` Ken Garlington
0 siblings, 1 reply; 57+ results
From: robin @ 1996-11-13 0:00 UTC (permalink / raw)
dewar@merv.cs.nyu.edu (Robert Dewar) writes:
>robin says
>>"Interface to PL/I and you can use standard I/O:
>>put edit (n) (P'-99999999');
>>and you don't have to worry about whether the number is
>>negative either. The nines in the picture format
>>force leading zeros to print.
>>And if you want, you can insert commas in the output
>>to make it more readable. The picture specification becomes:
>>P'-999,999,999'"
>I guess robin knows PL/1 and does not know Ada!
>If you want to use picture editing to solve this kind of problem, then
>use the picture editing in Ada, no need to wander off into PL/1, even in
>the unlikely case that you have a PL/1 compiler at hand. Personally I
>dislike the picture stuff in PL/1, they tried to improve on COBOL and
>made a mess of it.
Isn't it amazing! Robert Dewar [among others] already has
had an opportunity to reply in this vein to the original
posting and subsequent ones, but it didn't occur to him to
do so, more than likely because he didn't know that a limited
facility existed in Ada. Instead, he suggested using
string facilities.
Below is Robert Dewar's previous posting:
>This is a place where CLEARLY there is a missing abstraction (Put with
>leading zeros), and it seems obvious that you fix this in the way that
>you always do abstraction extension, you create an appropriate abstraction
>and use it. If it is useful enough, hopefully it gets to be widely available.
>Note that if you do want to construct on the fly, a much clearer way is to
>use the string routines from the string packages, which have padding
>capabilities.
PL/I is not restricted to picture editing with decimal data,
(one poster suggested changing to Ada decimal data in order to use
Ada's limited editing). PL/I requires *only* the single line:
put edit (n) (P'-99999999');
and not the (up to) page of Ada code to implement the
requirement of the original post.
^ permalink raw reply [relevance 6%]
* Re: Leading zeros with Int_IO.Put()? Or another package?
1996-11-13 0:00 6% ` robin
@ 1996-11-13 0:00 0% ` Ken Garlington
1996-11-19 0:00 6% ` robin
0 siblings, 1 reply; 57+ results
From: Ken Garlington @ 1996-11-13 0:00 UTC (permalink / raw)
robin wrote:
>
> dewar@merv.cs.nyu.edu (Robert Dewar) writes:
>
> >robin says
>
> >>"Interface to PL/I and you can use standard I/O:
>
> >>put edit (n) (P'-99999999');
>
> >>and you don't have to worry about whether the number is
> >>negative either. The nines in the picture format
> >>force leading zeros to print.
>
> >>And if you want, you can insert commas in the output
> >>to make it more readable. The picture specification becomes:
>
> >>P'-999,999,999'"
>
> >I guess robin knows PL/1 and does not know Ada!
>
> >If you want to use picture editing to solve this kind of problem, then
> >use the picture editing in Ada, no need to wander off into PL/1, even in
> >the unlikely case that you have a PL/1 compiler at hand. Personally I
> >dislike the picture stuff in PL/1, they tried to improve on COBOL and
> >made a mess of it.
>
> Isn't it amazing! Robert Dewar [among others] already has
> had an opportunity to reply in this vein to the original
> posting and subsequent ones, but it didn't occur to him to
> do so, more than likely because he didn't know that a limited
> facility existed in Ada. Instead, he suggested using
> string facilities.
Actually, if you know Ada, it's not amazing at all. The Ada picture I/O is for
decimal types; the original request was for integer types. If you don't want to
convert your type, the suggestion by Dr. Dewar is more straight-forward. If you
do want to use picture I/O, you probably still want to use an abstraction of
this facility to hide the details of type conversion, instantiation of picture I/O,
etc.
Ada people have this perversity of suggesting the most straight-forward and
maintainable approach first. :)
>
> Below is Robert Dewar's previous posting:
>
> >This is a place where CLEARLY there is a missing abstraction (Put with
> >leading zeros), and it seems obvious that you fix this in the way that
> >you always do abstraction extension, you create an appropriate abstraction
> >and use it. If it is useful enough, hopefully it gets to be widely available.
>
> >Note that if you do want to construct on the fly, a much clearer way is to
> >use the string routines from the string packages, which have padding
> >capabilities.
>
> PL/I is not restricted to picture editing with decimal data,
> (one poster suggested changing to Ada decimal data in order to use
> Ada's limited editing). PL/I requires *only* the single line:
>
> put edit (n) (P'-99999999');
>
> and not the (up to) page of Ada code to implement the
> requirement of the original post.
--
LMTAS - "Our Brand Means Quality"
For more info, see http://www.lmtas.com or http://www.lmco.com
^ permalink raw reply [relevance 0%]
* Re: Looking for experience with Ada/RPCs
@ 1993-04-10 16:19 5% David Emery
0 siblings, 0 replies; 57+ results
From: David Emery @ 1993-04-10 16:19 UTC (permalink / raw)
Considering the business Greg is in, he should know that most
gocvernment contracts have contract provisions requiring government
approval before source code, documentation, papers, etc, are released
to the general public. The reasons for these requirements include
security and export control and also acquisition/procurement
restrictions. I really don't want to get fired or sent to jail in
order to help Greg's software components redistribution business :-)
As I said, once we receive permission, we will be posting source code,
etc. I would point out that the source code on another MITRE project,
the Ada Decimal Arithmetic and Representation is available on
ajpo.sei.cmu.edu.
dave
^ permalink raw reply [relevance 5%]
* Re: Ada Decimal Arithmetic & Representations (ADAR) V1.0 available
1993-03-25 1:22 3% ` Keith Thompson @pulsar
@ 1993-03-25 21:29 5% ` Robert I. Eachus
0 siblings, 0 replies; 57+ results
From: Robert I. Eachus @ 1993-03-25 21:29 UTC (permalink / raw)
In article <1993Mar25.012215.26844@telesoft.com> kst@telesoft.com (Keith Thompson @pulsar) writes:
> The article I was responding to (not written by Robert Eachus) described
> the Alsys SPARC compiler's lack of a Long_Integer type as a shortcoming.
> This is unfair (IMHO). For the SPARC hardware, it's perfectly appropriate
> to define type Integer as 32 bits (it's a 32-bit processor, after all),
> and not to define a type Long_Integer (the SPARC doesn't directly support
> 64-bit arithmetic operations).
Better IMHO is to have Long_Integer in STANDARD as the longest
supported Integer type, even if it is the same length as Integer. I
"overreacted" in this case because the examples mentioned have
Long_Integer with a comment to use the longest integer type
available... the intent was that anyone getting an error message could
figure it out, but if we put in Integer, it would compile with no
warnings then fail at run-time. (And it is a case where, as I said,
you do want to use Integer if possible.)
(A brownie point to anyone who recognizes "JCN 9000").
-- I'm afraid I can't do that, Dave...
> This isn't pretty, but it should work for anything up to 64-bit
> integers. Thanks to Gary Dismukes for the idea.
-- Nice try, but not necessarily static! An expression which raises
-- an exception is not-static. It is legal for a compiler not to
-- raise an exception when evaluating B20, but it is also legitimate
-- to raise one. So, if it works on your compiler, a tip o' the hat,
-- but it is not really portable. (And boy is it ugly! :-) By the
-- way, I gave a presentation at a SIGAda conference on a different
-- case of implementation dependant static expressions which caused a
-- program to be illegal.
Robert I. Eachus
with Standard_Disclaimer;
use Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...
--
Robert I. Eachus
with Standard_Disclaimer;
use Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...
^ permalink raw reply [relevance 5%]
* Re: Ada Decimal Arithmetic & Representations (ADAR) V1.0 available
1993-03-24 1:33 4% ` Robert I. Eachus
@ 1993-03-25 1:22 3% ` Keith Thompson @pulsar
1993-03-25 21:29 5% ` Robert I. Eachus
0 siblings, 1 reply; 57+ results
From: Keith Thompson @pulsar @ 1993-03-25 1:22 UTC (permalink / raw)
In article <EACHUS.93Mar23203327@dr_no.mitre.org> eachus@dr_no.mitre.org (Robert I. Eachus) writes:
> [...]
> In article <1993Mar22.223336.23771@telesoft.com> kst@telesoft.com (Keith Thompson @pulsar) writes:
>
> > Ahem. Actually, it's a shortcoming of the package that it depends
> > on Long_Integer....
>
> > If you want the longest possible integer type (whatever its name
> > happens to be in Standard), use something like this:
>
> > type Longest_Integer is range System.Min_Int .. System.Max_Int;
>
> FLAME ON!!!!
>
> This sort of abstract pontificating has its place, but in this
> case you do a significant disservice in posting something like this
> without looking at the actual packages.
>
> First, most of the use of system dependant types occurs either in
> a configuration package or in examples.
>
> Second, every such case is commented with WHY the decision to
> declare things that way was made.
>
> Third, there are cases where declarations like Longest_Integer
> above will simply not work, because you must use Standard.Integer.
> Two examples are the rules in 3.6.1(2) and the exponentiation
> operators defined in 4.5.6(4).
>
> Forth, well you get the picture...
>
> FLAME OFF.
> [...]
I admit that I was a little quick to attack the package without being
sufficiently familiar with it. Inappropriate use of predefined integer
types happens to be one of my hot buttons. I apologize to the authors
of the ADAR packages for any perceived flame; it was unintentional.
HOWEVER...
The article I was responding to (not written by Robert Eachus) described
the Alsys SPARC compiler's lack of a Long_Integer type as a shortcoming.
This is unfair (IMHO). For the SPARC hardware, it's perfectly appropriate
to define type Integer as 32 bits (it's a 32-bit processor, after all),
and not to define a type Long_Integer (the SPARC doesn't directly support
64-bit arithmetic operations).
Even if one is using only a single compiler/host/target combination, it's
still a good idea to avoid predefined integer types other than Integer.
The choice of how and whether to define types such as Short_Integer and
Long_Integer is an arbitrary one made by the compiler implementers.
It's unlikely that these names really correspond to concepts in
the problem domain; that's what user-defined integer types are for.
(They also keep you from comparing apples and oranges.) Using Integer
is sometimes necessary, as you pointed out; it can also be perfectly
appropriate if all you need is an integer type of "reasonable" size,
range, and efficiency.
I've found that, even if portability isn't a concern (in those extremely
rare cases where you're sure that it will *never* be a concern),
writing software in as portable a fashion as practical tends to make
it cleaner and more easily maintainable. If I'm maintaining a piece of
software that is never intended to run on anything other than a JCN 9000
computer with a FooCorp version 6.9 Ada compiler, I'd still rather deal
with a user-defined integer type than have to remember how the compiler
implementers chose to define Long_Integer. (A brownie point to anyone
who recognizes "JCN 9000").
I offer this as general advice to Ada programmers, not as a criticism of
the ADAR packages. Configuration packages and examples are probably
among the rare cases where direct use of predefined integer types other
than Integer can be appropriate. I do understand the need to get down
close to the hardware and/or compiler when you're writing low-level
numeric software.
Besides, isn't a large part of the purpose of Ada, and of computer
science in general, to bring "abstract pontificating" down into useful
real-life domains?
> Where they can, we did, but for example, find the largest power of ten
> smaller than Integer'LAST in static Ada...)
This isn't pretty, but it should work for anything up to 64-bit
integers. Thanks to Gary Dismukes for the idea.
with Text_IO;
procedure Power is
B01: constant := Boolean'Pos(Integer'Last > 10 ** 1);
B02: constant := Boolean'Pos(Integer'Last > 10 ** 2);
B03: constant := Boolean'Pos(Integer'Last > 10 ** 3);
B04: constant := Boolean'Pos(Integer'Last > 10 ** 4);
B05: constant := Boolean'Pos(Integer'Last > 10 ** 5);
B06: constant := Boolean'Pos(Integer'Last > 10 ** 6);
B07: constant := Boolean'Pos(Integer'Last > 10 ** 7);
B08: constant := Boolean'Pos(Integer'Last > 10 ** 8);
B09: constant := Boolean'Pos(Integer'Last > 10 ** 9);
B10: constant := Boolean'Pos(Integer'Last > 10 ** 10);
B11: constant := Boolean'Pos(Integer'Last > 10 ** 11);
B12: constant := Boolean'Pos(Integer'Last > 10 ** 12);
B13: constant := Boolean'Pos(Integer'Last > 10 ** 13);
B14: constant := Boolean'Pos(Integer'Last > 10 ** 14);
B15: constant := Boolean'Pos(Integer'Last > 10 ** 15);
B16: constant := Boolean'Pos(Integer'Last > 10 ** 16);
B17: constant := Boolean'Pos(Integer'Last > 10 ** 17);
B18: constant := Boolean'Pos(Integer'Last > 10 ** 18);
B19: constant := Boolean'Pos(Integer'Last > 10 ** 19);
B20: constant := Boolean'Pos(Integer'Last > 10 ** 20);
Exponent: constant
:= B01 + B02 + B03 + B04 + B05 + B06 + B07 + B08 + B09 + B10 +
B11 + B12 + B13 + B14 + B15 + B16 + B17 + B18 + B19 + B20;
Largest_Power_Of_Ten: constant := 10 ** Exponent;
begin
Text_IO.Put_Line("Largest_Power_Of_Ten = " &
Integer'Image(Largest_Power_Of_Ten));
Text_IO.Put_Line("Integer'Last = " &
Integer'Image(Integer'Last));
end Power;
--
Keith Thompson (The_Other_Keith) kst@telesoft.com
TeleSoft^H^H^H^H^H^H^H^H Alsys, Inc.
5959 Cornerstone Court West, San Diego, CA, USA, 92121-9891
"Listen to me, people! We must stick them with quills -- it's the only way!"
^ permalink raw reply [relevance 3%]
* Re: Ada Decimal Arithmetic & Representations (ADAR) V1.0 available
1993-03-22 22:33 6% ` Keith Thompson @pulsar
@ 1993-03-24 1:33 4% ` Robert I. Eachus
1993-03-25 1:22 3% ` Keith Thompson @pulsar
0 siblings, 1 reply; 57+ results
From: Robert I. Eachus @ 1993-03-24 1:33 UTC (permalink / raw)
Summary:
The ADAR packages are a portable langauge extension in an area
where Ada just isn't very portable. We came up with a LOT of magic to
make this code possible, since when we started it was expected that
any Ada 83 decimal extension would require support by compiler
vendors. The ADAR packages as produced have portable, but in some
cases slow, bodies which can be customized to a particular compiler to
get a very efficent facility. But don't expect to do such
customization without knowing the compiler internals and the hardware
arithmetic model a lot better than you would like to.
In article <1993Mar22.223336.23771@telesoft.com> kst@telesoft.com (Keith Thompson @pulsar) writes:
> Ahem. Actually, it's a shortcoming of the package that it depends
> on Long_Integer....
> If you want the longest possible integer type (whatever its name
> happens to be in Standard), use something like this:
> type Longest_Integer is range System.Min_Int .. System.Max_Int;
FLAME ON!!!!
This sort of abstract pontificating has its place, but in this
case you do a significant disservice in posting something like this
without looking at the actual packages.
First, most of the use of system dependant types occurs either in
a configuration package or in examples.
Second, every such case is commented with WHY the decision to
declare things that way was made.
Third, there are cases where declarations like Longest_Integer
above will simply not work, because you must use Standard.Integer.
Two examples are the rules in 3.6.1(2) and the exponentiation
operators defined in 4.5.6(4).
Forth, well you get the picture...
FLAME OFF.
We went to a lot of work to push Ada to the edges of the Reference
Manual definition in the ADAR packages. Unfortunately you can only
carry portability so far. In general, the (package) specifications
are perfectly portable. However, it is simply not possible to write,
for example, an efficient portable double precision multiply that will
work on 24-bit and 32-bit hardware. Plan to change a couple of
constants. (And don't flame me about the fact that you need static
values in some places that can't be calculated from static attributes.
Where they can, we did, but for example, find the largest power of ten
smaller than Integer'LAST in static Ada...) We tried to produce
software which could be easily ported without modifying compilers.
But to expect the kind of magic which has to go on in the bodies of
these packages to port with zero effort, give me a BREAK.
As a "simple" example, one of the implementations uses floating
point to provide a type with exact fixed-point semantics. It works,
it's neat, but the number of digits for which you get exact decimal
arithmetic will be a complex function of the hardware floating point
model. (It's usually 15 or 16.) The code as written will get the
bounds right on most hardware I know of, but it does take some
attention to make sure.
--
Robert I. Eachus
with Standard_Disclaimer;
use Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...
^ permalink raw reply [relevance 4%]
* Re: Ada Decimal Arithmetic & Representations (ADAR) V1.0 available
1993-03-22 9:53 2% ` Rolf EBERT
@ 1993-03-22 22:33 6% ` Keith Thompson @pulsar
1993-03-24 1:33 4% ` Robert I. Eachus
0 siblings, 1 reply; 57+ results
From: Keith Thompson @pulsar @ 1993-03-22 22:33 UTC (permalink / raw)
In article <1993Mar22.095301.806@enpc.fr> re@hades.NoSubdomain.NoDomain (Rolf EBERT) writes:
> I tried the package with the Alsys compiler (V5.5.1) on a SPARC station
> and had no difficulties to compile it. The only problem was a
> shortcoming of the Alsys compiler that defines no Long_Integer.
> Context-fiffs are applied at the end.
Ahem. Actually, it's a shortcoming of the package that it depends
on Long_Integer. The language definition allows but does not require
Long_Integer and/or Short_Integer to be defined in Standard, and does
not define their sizes or ranges. Portable software should not use
these types directly; instead, it should define its own integer types
with whatever ranges are appropriate. For that matter, portable software
should be very careful about using type Integer; it's guaranteed to exist,
but its range will vary from one host/target/implementation to another.
If you want the longest possible integer type (whatever its name
happens to be in Standard), use something like this:
type Longest_Integer is range System.Min_Int .. System.Max_Int;
--
Keith Thompson (The_Other_Keith) kst@telesoft.com
TeleSoft^H^H^H^H^H^H^H^H Alsys, Inc.
5959 Cornerstone Court West, San Diego, CA, USA, 92121-9891
"Listen to me, people! We must stick them with quills -- it's the only way!"
^ permalink raw reply [relevance 6%]
* Re: Membership in "set" of characters
@ 1993-03-22 12:22 4% ` Debora Weber-Wulff
0 siblings, 0 replies; 57+ results
From: Debora Weber-Wulff @ 1993-03-22 12:22 UTC (permalink / raw)
Thanks to all who wrote with information about my problems
with membership and FIXED/FLOAT. Here's a short summary of the
other answers I received:
FIXED/FLOAT
Just using
type DM is delta 0.01 range 0.0 .. 1000.0;
gets me in trouble because the delta is a positive fraction
that causes rounding errors. I need
for DM'small use 0.01;
to make it work as I expect, but I've been advised to leave FIXED
alone until I understand more about Ada :-)
I've included a complete letter with some great advice at the end
of this summary.
There's an article in Ada Europe'92 proceedings [is that published
in LNCS? I've not heard of it before, but they seem to be in
their 13th year! Is there a FAQ for this group??? ] by Ben Brosgol,
Robert Eachus and Dave Emery about Ada Decimal Arithmetic.
ajpo.sei.cmu.edu (128.237.2.253) has a library of representations
for decimal arithmetic at ADAR-1.0.tar.Y and a book called
"Ada Quality and Style"
Membership Problem
Lots of suggestions!
* Use subtypes!
* use a case statement!
* make a function is_in (c:character; s:string) return Boolean is ...
* use okay := affirmatives'VALUE (CHARACTER'IMAGE(ch)) IN affirmatives;
* roll my own set as described below - that sounds like the
way I want to go. It reads a tad easier than the previous
suggestion :-)
----- included file -----
In article <J6QBBP3L@math.fu-berlin.de> you write:
> This is another one of those "why won't this work?" for the experts.
> I'm stumped. As far as I can decode the LRM and
> see from 2 textbooks I consulted, this ought to work.
nope
> -- Why won't membership work here?
here's the short answer:
for the type of thing you are doing, you can create a set ADT.
a simple way to do that in Ada for a relatively small discrete universe
like character is to use a boolean array. you can pack it to make it
smaller, which effectively creates a bitmap. this is what Pascal sets
basically are - and this way Ada doesnt have to explicitly support
sets in the language. its just one kind of data type that you can build.
type char_predicates is array (character) of boolean;
pragma pack (char_predicates);
affirmative : constant char_predicates
:= char_predicates'('y'|'Y'|'j'|'J'|'o'|'O' => true, others => false);
...
okay := affirmative(ch);
you could also make affirmative a function instead of a constant array
to save space. you could do this later if necessary without changing
the clients because the syntax for a function call is identical
to that of an array reference.
its a little more typing than Pascal in this case, but its
much easier to tell whats going on.
> I'm currently quite frustrated with the type system after writing a little program
> to calculate the return on investment.
> Is it me? Is it Meridian? Or is this the agony of using Ada?
It takes a while to get used to Ada's strong typing. It seems overly
strict at first, but once you understand the rules well, they dont get
in the way very much at all. in fact, they often help prevent errors.
still that initial period can be rough, since its easy to make things
much stricter than you need without realizing it. and then blame the
language when it is enforcing exactly the rules that you asked for.
derived types are a frequent culprit. they can be very helpful when
you need them, but can easily make it difficult to write any
expression if over-used.
you can get very similar behavior to other languages like Pascal with
respect to numeric types if you wish.
1. avoid derived types until you have learned the rest of Ada well.
then use them judiciously and carefully.
(derived types have the form "type xxx is new yyy")
(also avoid the form "type xxx is range a .. b" at first)
2. use subtypes instead, "subtype xxx is yyy range a .. b"
3. avoid fixed point, use float instead.
4. if you frequently use a mixed mode operation (i.e. multiply integers
and floats to get floats) then define a function so that you dont
have to keep performing conversions.
function "*" (left : integer; right : float) return float is ...
5. when you feel comfortable with Ada, get a few books and try out
derived types and floats. they do have good uses. the book
Ada Quality and Style available on ajpo.sei.cmu.edu has a section
on derived types and subtypes that might help (disclaimer:
I helped write that part) the FAQ on the same machine describes
several good books as well (thanks to Mike Feldman).
good luck.
P.S. Meridian is a pretty good compiler, but if you get the chance
or have something really serious, use DECs.
--
---------------------------------------------------
Alex Blakemore alex@cs.umd.edu NeXT mail accepted
----- end included file -----
--
Debora Weber-Wulff, Professorin fuer Softwaretechnik
snail: Technische Fachhochschule, FB Informatik,
Luxemburgerstr. 10, 1000 Berlin 65
email: dww@informatik.tfh-berlin.dbp.de
^ permalink raw reply [relevance 4%]
* Re: Ada Decimal Arithmetic & Representations (ADAR) V1.0 available
1993-03-21 23:12 5% ` Michael Feldman
@ 1993-03-22 9:53 2% ` Rolf EBERT
1993-03-22 22:33 6% ` Keith Thompson @pulsar
0 siblings, 1 reply; 57+ results
From: Rolf EBERT @ 1993-03-22 9:53 UTC (permalink / raw)
In article <1993Mar21.231233.2934@seas.gwu.edu>, mfeldman@seas.gwu.edu (Michael Feldman) writes:
|> In article <1993Mar19.161646.26563@sei.cmu.edu> adainfo@ajpo.sei.cmu.edu (Michele L. Kee (AdaIC)) writes:
|> >
|> >The ADAR packages were developed to provide a common approach for
|> >decimal arithmetic and Ada 83. The ADAR package set consists of two
|> >related facilities for decimal arithmetic, one based on discriminant
|> >records, and the other on generics, to provide decimal computation and
|> >interoperable representations of decimal quantities.
|> >
|> >The ADAR packages include support for decimal data with up to 18
|> >digits of precision, arithmetic operations with programmer control
|> >over rounding versus truncation, conversions to and from common
|> >external representations, and formatted output of decimal values based
|> >on COBOL's "picture" clauses.
|> >
|> I have been working with ADAR off and on for a month or so, and find it
|> an extraordinarily interesting artifact for educational purposes because
|> there is some very good Ada in it. I believe that it is also useful in
|> its own right as a facility for adding IS features to Ada83. You can view it
|> as a preview of some of the IS facilities in Ada9X.
|>
|> Ben Brosgol, Dave Emery, and Bob Eachus have done a great job of producing
|> this software and deserve our commendation. That said, I wish to express
|> some disappointment at the limited number of compilers for which ADAR
|> has been tested. The Meridian family is the most common family of compilers
|> in education, and ADAR dos not (yet) work under Meridian; preliminary
|> tests indicate that at least some compilation-order problems will need to
|> be resolved.
|>
|> To operate under Ada/Ed, ADAR will need a good bit more work; there are
|> (I think) some capacity problems as well as the Ada/Ed requirement (which
|> used to be common in Ada compilers) that a generic body appear in the
|> same file as the associated generic spec.
|>
|> Perhaps we at GW will find the time to re-work ADAR for these two
|> important education-oriented Ada systems; perhaps someone in net-land
|> will. Whatever, I commend ADAR to you as a neat bunch of stuff.
|>
|> Mike Feldman
|> ------------------------------------------------------------------------
|> Michael B. Feldman
|> co-chair, SIGAda Education Committee
|>
|> Professor, Dept. of Electrical Engineering and Computer Science
|> School of Engineering and Applied Science
|> The George Washington University
|> Washington, DC 20052 USA
|> (202) 994-5253 (voice)
|> (202) 994-5296 (fax)
|> mfeldman@seas.gwu.edu (Internet)
|>
|> "The most important thing is to be sincere,
|> and once you've learned how to fake that, you've got it made."
|> -- old show-business adage
|> ------------------------------------------------------------------------
I tried the package with the Alsys compiler (V5.5.1) on a SPARC station and had
no difficulties to compile it. The only problem was a shortcoming of the Alsys
compiler that defines no Long_Integer. Context-fiffs are applied at the end.
diff -c3 -r ADAR/examples/generic/exercise/decpck.ada ADAR.new/examples/generic/exercise/decpck.ada
*** ADAR/examples/generic/exercise/decpck.ada Mon Mar 15 20:03:23 1993
--- ADAR.new/examples/generic/exercise/decpck.ada Sat Mar 20 15:04:39 1993
***************
*** 1,2 ****
with ADAR_Generic_Decimal;
! package Decimal_Pckg is new ADAR_Generic_Decimal (Long_Integer, Long_Float);
--- 1,2 ----
with ADAR_Generic_Decimal;
! package Decimal_Pckg is new ADAR_Generic_Decimal (Integer, Long_Float);
diff -c3 -r ADAR/examples/generic/exercise/example1.ada ADAR.new/examples/generic/exercise/example1.ada
*** ADAR/examples/generic/exercise/example1.ada Mon Mar 15 20:03:43 1993
--- ADAR.new/examples/generic/exercise/example1.ada Sat Mar 20 15:43:55 1993
***************
*** 20,26 ****
subtype Fraction is Fraction_Type.Decimal;
use Fraction_Type;
! subtype Years is Long_Integer;
Input_File, Output_File : Text_IO.File_Type;
--- 20,26 ----
subtype Fraction is Fraction_Type.Decimal;
use Fraction_Type;
! subtype Years is Integer;
Input_File, Output_File : Text_IO.File_Type;
***************
*** 38,44 ****
(Fraction, Fraction_Type.Default_Format);
function "**" (L : Fraction;
! R : Long_Integer) return Fraction is
use Fraction_Log;
begin
return Exp (R * Log (L));
--- 38,44 ----
(Fraction, Fraction_Type.Default_Format);
function "**" (L : Fraction;
! R : Integer) return Fraction is
use Fraction_Log;
begin
return Exp (R * Log (L));
***************
*** 84,90 ****
use Text_IO;
begin
Put (File, '$');
! Long_Int_IO.Put (File, Long_Integer (Dollars_Type.Float (P)), 4);
Long_Int_IO.Put (File, T, 9); -- six spaces plus two digits.
Fraction_IO.Put (File, Item => R * 100);
-- The multiplication by 100 is to convert to a percentage.
--- 84,90 ----
use Text_IO;
begin
Put (File, '$');
! Long_Int_IO.Put (File, Integer (Dollars_Type.Float (P)), 4);
Long_Int_IO.Put (File, T, 9); -- six spaces plus two digits.
Fraction_IO.Put (File, Item => R * 100);
-- The multiplication by 100 is to convert to a percentage.
diff -c3 -r ADAR/examples/generic/exercise/example2.ada ADAR.new/examples/generic/exercise/example2.ada
*** ADAR/examples/generic/exercise/example2.ada Mon Mar 15 20:04:10 1993
--- ADAR.new/examples/generic/exercise/example2.ada Sat Mar 20 15:06:57 1993
***************
*** 1,3 ****
--- 1,4 ----
+
with Adar_Formats;
with Text_IO;
with Long_Int_IO;
***************
*** 24,30 ****
subtype Fraction is Fraction_Type.Decimal;
use Fraction_Type;
! subtype Shares is Long_Integer;
package Price_Type is new Decimal_Pckg.Short_Decimal
(Decimal_Places => 2,
--- 25,31 ----
subtype Fraction is Fraction_Type.Decimal;
use Fraction_Type;
! subtype Shares is Integer;
package Price_Type is new Decimal_Pckg.Short_Decimal
(Decimal_Places => 2,
diff -c3 -r ADAR/examples/generic/exercise/example3.ada ADAR.new/examples/generic/exercise/example3.ada
*** ADAR/examples/generic/exercise/example3.ada Mon Mar 15 20:04:32 1993
--- ADAR.new/examples/generic/exercise/example3.ada Mon Mar 22 09:51:36 1993
***************
*** 68,74 ****
begin
-- 0--------1---------2---------3---------4---------5---------6---
-- 123456789012345678901234567890123456789012345678901234567890123
! Put (" WEST GERMAN AUTOMOBILE IMPORT COSTS (U.S.$1 = DM ");
Fraction_IO.Put (Deutschmarks_Per_Dollar, Conversion_Format);
Put_Line (")");
New_Line;
--- 68,74 ----
begin
-- 0--------1---------2---------3---------4---------5---------6---
-- 123456789012345678901234567890123456789012345678901234567890123
! Put (" GERMAN AUTOMOBILE IMPORT COSTS (U.S.$1 = DM ");
Fraction_IO.Put (Deutschmarks_Per_Dollar, Conversion_Format);
Put_Line (")");
New_Line;
diff -c3 -r ADAR/examples/generic/exercise/lint_io.ada ADAR.new/examples/generic/exercise/lint_io.ada
*** ADAR/examples/generic/exercise/lint_io.ada Mon Mar 15 20:04:36 1993
--- ADAR.new/examples/generic/exercise/lint_io.ada Sat Mar 20 15:05:17 1993
***************
*** 1,2 ****
with Text_IO;
! package Long_Int_IO is new Text_IO.Integer_IO(Long_Integer);
--- 1,2 ----
with Text_IO;
! package Long_Int_IO is new Text_IO.Integer_IO(Integer);
diff -c3 -r ADAR/intrface/except.ada ADAR.new/intrface/except.ada
*** ADAR/intrface/except.ada Mon Mar 15 18:15:08 1993
--- ADAR.new/intrface/except.ada Sat Mar 20 15:50:40 1993
***************
*** 20,22 ****
--- 20,25 ----
-- of an unchecked conversion by the programmer
end ADAR_Exceptions;
+
+ package body ADAR_Exceptions is
+ end ADAR_Exceptions;
Rolf
-----------------------------------------------------------------------------
Rolf Ebert Groupe Informatique et Systemes Energetiques GISE EMP-ENPC
Tel: +33 1 43044098 app 3475 FAX: +33 1 43046364 La Courtine Cedex
Internet: ebert@enpc.fr F-93167 Noisy le Grand
-----------------------------------------------------------------------------
^ permalink raw reply [relevance 2%]
* Re: Ada Decimal Arithmetic & Representations (ADAR) V1.0 available
1993-03-19 21:16 14% Ada Decimal Arithmetic & Representations (ADAR) V1.0 available Michele L. Kee (AdaIC)
@ 1993-03-21 23:12 5% ` Michael Feldman
1993-03-22 9:53 2% ` Rolf EBERT
0 siblings, 1 reply; 57+ results
From: Michael Feldman @ 1993-03-21 23:12 UTC (permalink / raw)
In article <1993Mar19.161646.26563@sei.cmu.edu> adainfo@ajpo.sei.cmu.edu (Michele L. Kee (AdaIC)) writes:
>
>The ADAR packages were developed to provide a common approach for
>decimal arithmetic and Ada 83. The ADAR package set consists of two
>related facilities for decimal arithmetic, one based on discriminant
>records, and the other on generics, to provide decimal computation and
>interoperable representations of decimal quantities.
>
>The ADAR packages include support for decimal data with up to 18
>digits of precision, arithmetic operations with programmer control
>over rounding versus truncation, conversions to and from common
>external representations, and formatted output of decimal values based
>on COBOL's "picture" clauses.
>
I have been working with ADAR off and on for a month or so, and find it
an extraordinarily interesting artifact for educational purposes because
there is some very good Ada in it. I believe that it is also useful in
its own right as a facility for adding IS features to Ada83. You can view it
as a preview of some of the IS facilities in Ada9X.
Ben Brosgol, Dave Emery, and Bob Eachus have done a great job of producing
this software and deserve our commendation. That said, I wish to express
some disappointment at the limited number of compilers for which ADAR
has been tested. The Meridian family is the most common family of compilers
in education, and ADAR dos not (yet) work under Meridian; preliminary
tests indicate that at least some compilation-order problems will need to
be resolved.
To operate under Ada/Ed, ADAR will need a good bit more work; there are
(I think) some capacity problems as well as the Ada/Ed requirement (which
used to be common in Ada compilers) that a generic body appear in the
same file as the associated generic spec.
Perhaps we at GW will find the time to re-work ADAR for these two
important education-oriented Ada systems; perhaps someone in net-land
will. Whatever, I commend ADAR to you as a neat bunch of stuff.
Mike Feldman
------------------------------------------------------------------------
Michael B. Feldman
co-chair, SIGAda Education Committee
Professor, Dept. of Electrical Engineering and Computer Science
School of Engineering and Applied Science
The George Washington University
Washington, DC 20052 USA
(202) 994-5253 (voice)
(202) 994-5296 (fax)
mfeldman@seas.gwu.edu (Internet)
"The most important thing is to be sincere,
and once you've learned how to fake that, you've got it made."
-- old show-business adage
------------------------------------------------------------------------
^ permalink raw reply [relevance 5%]
* Ada Decimal Arithmetic & Representations (ADAR) V1.0 available
@ 1993-03-19 21:16 14% Michele L. Kee (AdaIC)
1993-03-21 23:12 5% ` Michael Feldman
0 siblings, 1 reply; 57+ results
From: Michele L. Kee (AdaIC) @ 1993-03-19 21:16 UTC (permalink / raw)
The source code for Ada Decimal Arithmetic and Representations (ADAR),
Version 1.0, January 1993, which was developed under the Ada Joint
Program Office's Ada Technology Insertion Program (ATIP), is now
available for anonymous FTP on the AJPO host computer,
ajpo.sei.cmu.edu. The source code has been UNIX TAR'd and compressed
into one file, "ADAR-1.0.tar.Z".
The ADAR packages were developed to provide a common approach for
decimal arithmetic and Ada 83. The ADAR package set consists of two
related facilities for decimal arithmetic, one based on discriminant
records, and the other on generics, to provide decimal computation and
interoperable representations of decimal quantities.
The ADAR packages include support for decimal data with up to 18
digits of precision, arithmetic operations with programmer control
over rounding versus truncation, conversions to and from common
external representations, and formatted output of decimal values based
on COBOL's "picture" clauses.
Anonymous FTP:
Host: ajpo.sei.cmu.edu
IP address: 128.237.2.253
Location: /public/atip/adar/ADAR-1.0.tar.Z
For those of you without FTP access, the AJPO host provides mail-server
capabilities. Use the "file-request" service to receive an uuencoded copy
of the file, ADAR-1.0.tar.Z. Address your message as such --
To: ftpmail@ajpo.sei.cmu.edu
Subject: file-request atip/adar/ADAR-1.0.tar.Z
There is no need for any text in the body of your message.
--
Ada Information Clearinghouse (AdaIC) | IIT Research Institute
703/685-1477, 800/AdaIC-11, FAX 703/685-7019 | operates the AdaIC for
Internet: adainfo@ajpo.sei.cmu.edu | the Ada Joint Program
CompuServe: 70312,3303 | Office (AJPO).
^ permalink raw reply [relevance 14%]
* Re: Ada IBM/370/MVS MIS Applications
@ 1991-06-26 3:12 0% John Prentice
0 siblings, 0 replies; 57+ results
From: John Prentice @ 1991-06-26 3:12 UTC (permalink / raw)
I received a request to post a summary of responses to my original
request for information regarding Ada applications in an IBM/MVS domain.
There were not a lot of responses, which I think is indicative of the lack
of work goining on in the IBM/MVS world. While I'm at it, though, let me thank
those that did respond!
>From eachus@d74sun.mitre.org Tue Jun 11 23:28:58 1991
>
>
> Some answers and a question... First, stick to the PC or some
>other environment for compiling/debugging etc. There are several
>decent Ada cross-compilers, and although there are problems using Ada
>tasking under MVS, these problems also occur under several other
>operating systems, VMS for example. But MVS is definitely not the
>environment to develop your code in. I once heard developing Ada on
>MVS compared to "kicking a dead whale down the beach..." and every
>project I know of which successfully used Ada on IBM mainframes did
>not use MVS for development. (If you want the gory details, I can
>refer you to people who actually WORKED in such an environment on WIS.
>I managed to keep it at arms length.) The IBM development team on WIS
>evetually switched to a Rational for development just so they could
>get reasonable compile times. (It is not unusual for a compile to
>take several times longer on a 3090 running MVS than on a 386, and the
>386 is MUCH cheaper.)
>
> Second, a lot of the stuff developed for WIS and STANFINS-R
>should be both available to you and directly applicable to what you
>are doing. No need to keep re-inventing the wheel.
>
> And now for a request, we (MITRE) are going to be working with
>Ben Brosgol at Alsys to develop a standard Ada decimal arithmetic
>package and propose the interface as an ISO standard. There has been a
>lot of work done already under SIGAda CAUWG, but we would certainly
>appreciate additional input... There also should be some useful stuff
>developed under STARS, but that is not targeted to the commercial
>area.
>
>
> Robert I. Eachus
>
>with STANDARD_DISCLAIMER;
>use STANDARD_DISCLAIMER;
>function MESSAGE (TEXT: in CLEVER_IDEAS) return BETTER_IDEAS is...
>From bhanafee@ads.com Wed Jun 12 12:27:57 1991
>
>Hi,
>You might take a look at the simtel20 Ada repository. In particular,
>I believe the CSPARTS area has some code for report generating. I
>do not know much else other than it's there. If you have any problems
>getting to this site (which is often very busy), you could also look
>for a mirror site called wuarchive. I don't believe the mirror is
>fully complete yet. Also, if you have not yet done so, you should
>contact the Ada Information Clearinghouse and get on their (free)
>mailing list. The phone # is 800/Ada-ic11 or 703/685-1477.
>
>The full name of the Ada repository is
>
>wsmr-simtel20.army.mil (192.88.110.20). The IP address is new, I
>haven't tried it yet. The old IP address was 26.2.0.74. Also note
>that this is not a UNIX site. There is a file with instructions
>on how to use this site in the directory you log on to.
>
>Also,
>wuarchive.wustl.edu (128.252.135.4). I have never used wuarchive,
>so I don't know what you might find.
>
>
>Brian Hanafee
>From kmccook@logdis1.wr.aflc.af.mil Fri Jun 14 07:06:55 1991
>
>We had a similar problem a few months ago. You probably want to look at
>Intermetrics Ada Compiler, CICS, some ANSI SQL database, and get SAMEDL
>from Intermetrics to go between Ada and the SQL (ie ..DATACOMDB).
>
>Feel free to call if you want some more help.
>
>Ken McCook
>HQ 1926th CCSG/SCDD
>Robins AFB, GA 31098-6346
>(DSN) 468-3224
>(912) 926-3224
>From telesoft!choll@uunet.UU.NET Tue Jun 18 03:52:46 1991
>
>Hi John,
>
>In article <1991Jun11.183803.10781@colorado.edu> you write:
>>I'm looking for information/feedback concerning using Ada on an IBM
>>370 running MVS.
>>
>>To date, we have been evaluating compilers (Alsys and Intermetrics),
>>and some PC based tools (e.g. AdaSage), and building interfaces to IBM
>>software such as VSAM and ISPF.
>
>Have you talked to IBM about their Ada compiler and toolset? Just
>curious. I work for TeleSoft, and we build the compilers for IBM. In
>fact, I am presently working in the IBM group, and we have compilers
>and development environments for VM/CMS, (VM/XA shortly - I believe),
>MVS/XA, and MVS/ESA (to be released to IBM at the end of this month).
>
>The MVS compler is being used by the FAA for their new Air Traffic
>Controller Systems, and they seem very happy with it.
>
>I do QA and Performance Measurement for the group, and this will be
>our best release ever (from my perspective).
>
>Chris Holl
>TeleSoft
>San Diego, CA
>(619) 457-2700
>
>Disclaimer: Yes, this is a blatent plug for a TeleSoft/IBM product,
>and I DO work for the company. I'm not in Sales however, and TeleSoft
>doesn't even know I'm sending this. :-)
>
^ permalink raw reply [relevance 0%]
* Re: Ada decimal elaboration, furthe
1988-07-05 23:39 7% ` Michael Murphy
@ 1988-07-09 19:22 7% ` stt
0 siblings, 0 replies; 57+ results
From: stt @ 1988-07-09 19:22 UTC (permalink / raw)
I would expect that things will improve as ACVC 1.10 takes hold,
where Chapter 13 is no longer seen as "optional" by
compiler writers...
-Tucker Taft
Intermetrics, Inc.
Cambridge, MA 02138
^ permalink raw reply [relevance 7%]
* Re: Ada decimal math, an example (or counterexample)
@ 1988-07-06 18:48 6% Gary Morris @flash
0 siblings, 0 replies; 57+ results
From: Gary Morris @flash @ 1988-07-06 18:48 UTC (permalink / raw)
>
> type dollar_type is delta 0.01 range 0.00..1000.00;
> ...
> my_dime : dollar_type :=
> 0.01 + 0.01 + 0.01 + 0.01 + 0.01 + 0.01 + 0.01 + 0.01 + 0.01 + 0.01;
> ...
These calculations are done using the dollar_type which has a 'small of
0.0078125. For the use you are making of this type, you should use a rep
spec to make 'small be the same as the delta. The TeleSoft TeleGen2
compiler supports this:
type dollar_type is delta 0.01 range 0.00..1000.00;
for dollar_type'small use 0.01;
With the rep spec our Sun Ada 1.1 compiler produces the "expected" results:
-- my_dime is worth 0.10
--your_dime is worth 0.10
Without the rep spec our Sun Ada 1.1 compiler does the computation using
a 'small of 0.0078125 yielding 0.078125, which is rounded to 0.08 for
output:
-- my_dime is worth 0.08
--your_dime is worth 0.08
Gary Morris UUCP: ucbvax!ucsd!telesoft!garym
TeleSoft, San Diego telesoft!garym@ucsd.edu
(619) 457-2700 ARPA: ucsd!telesoft!garym@ucbvax.ARPA
^ permalink raw reply [relevance 6%]
* Re: Ada decimal elaboration, further experimentation.
1988-07-03 23:36 6% ` Dik T. Winter
@ 1988-07-05 23:39 7% ` Michael Murphy
1988-07-09 19:22 7% ` Ada decimal elaboration, furthe stt
0 siblings, 1 reply; 57+ results
From: Michael Murphy @ 1988-07-05 23:39 UTC (permalink / raw)
The more serious problem here which is what *really* causes the bad
numbers is that most (all?) Ada compilers only support fixed point numbers
that are a power of two. So despite the type declaration with a
delta of 0.01, the actual delta used is 0.0078125 (2e-7). This makes
decimal arithmetic using fixed point unworkable.
-- Michael Murphy
P.S. The VADS 5.5 compiler for the ELXSI prints out 0.10 for all
my_dime calculations (constant or not) because they are all done with
universal arithmetic, but your_dime is 0.08 for the above reason.
^ permalink raw reply [relevance 7%]
* Re: Ada decimal elaboration, further experimentation.
1988-07-03 18:49 6% Ada decimal elaboration, further experimentation CONTR47
@ 1988-07-03 23:36 6% ` Dik T. Winter
1988-07-05 23:39 7% ` Michael Murphy
0 siblings, 1 reply; 57+ results
From: Dik T. Winter @ 1988-07-03 23:36 UTC (permalink / raw)
In article <8807031845.AA01533@ajpo.sei.cmu.edu> CONTR47@NOSC-TECR.ARPA writes:
> Norm Cohen writes:
...
> The Ada rule is that conversion takes place only at the bottom of the
> expression tree: Only numeric literals, named numbers, and attributes
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> with universal results are convertible.
> ------------------------------
> Wellll. I tried Norm's suggestion (assuming he meant
> "constant dollar_type" instead of just "constant") so that
> my_dime : constant dollar_type := 0.01 + 0.01 etc. for a total of ten 0.01s
...
> How about other people trying this in case I'm
> missing something and also to see how other
Yes, you are. Norm did *not* mean constant dollar_type, but just constant.
You still are trying to get an implicit conversion from a universal real
expression to something of type dollar_type. This is not possible, as noted
by Norm.
Oh, BTW, our system (DG) gives:
My dime is .102
Your dime is .078
which is wrong on two counts.
--
dik t. winter, cwi, amsterdam, nederland
INTERNET : dik@cwi.nl
BITNET/EARN: dik@mcvax
^ permalink raw reply [relevance 6%]
* Ada decimal elaboration, further experimentation.
@ 1988-07-03 18:49 6% CONTR47
1988-07-03 23:36 6% ` Dik T. Winter
0 siblings, 1 reply; 57+ results
From: CONTR47 @ 1988-07-03 18:49 UTC (permalink / raw)
Norm Cohen writes:
Sam Harbaugh expects the addition in
my_dime : dollar_type :=
0.01 + 0.01 + 0.01 + 0.01 + 0.01 + 0.01 + 0.01 + 0.01 + 0.01 + 0.01;
-- 1 2 3 4 5 6 7 8 9 10
to be performed using universal_real addition rather than dollar_type
addition. Actually, it is performed using dollar_type addition: Each
real literal is implicitly converted to dollar_type and the ten resulting
dollar_type values are summed.
If Sam had written
my_dime : constant :=
0.01 + 0.01 + 0.01 + 0.01 + 0.01 + 0.01 + 0.01 + 0.01 + 0.01 + 0.01;
then exact universal_real addition would have been performed.
The Ada rule is that conversion takes place only at the bottom of the
expression tree: Only numeric literals, named numbers, and attributes
with universal results are convertible.
The rule is given in RM paragraph 4.6(15). Paragraph 4.6(20) provides
enlightening examples.
Norman Cohen
IBM Research
------------------------------
Wellll. I tried Norm's suggestion (assuming he meant
"constant dollar_type" instead of just "constant") so that
my_dime : constant dollar_type := 0.01 + 0.01 etc. for a total of ten 0.01s
Janus said my_dime is worth 0.08
Alsys said my_dime is worth 0.10
Dec said my_dime is worth 0.08
How about other people trying this in case I'm
missing something and also to see how other
compilers handle this.
regards,sam harbaugh
-------------------
^ permalink raw reply [relevance 6%]
* Ada decimal math, an example (or counterexample)
@ 1988-07-01 17:54 6% Norman Cohen
0 siblings, 0 replies; 57+ results
From: Norman Cohen @ 1988-07-01 17:54 UTC (permalink / raw)
Sam Harbaugh expects the addition in
my_dime : dollar_type :=
0.01 + 0.01 + 0.01 + 0.01 + 0.01 + 0.01 + 0.01 + 0.01 + 0.01 + 0.01;
-- 1 2 3 4 5 6 7 8 9 10
to be performed using universal_real addition rather than dollar_type
addition. Actually, it is performed using dollar_type addition: Each
real literal is implicitly converted to dollar_type and the ten resulting
dollar_type values are summed.
If Sam had written
my_dime : constant :=
0.01 + 0.01 + 0.01 + 0.01 + 0.01 + 0.01 + 0.01 + 0.01 + 0.01 + 0.01;
then exact universal_real addition would have been performed.
The Ada rule is that conversion takes place only at the bottom of the
expression tree: Only numeric literals, named numbers, and attributes
with universal results are convertible.
The rule is given in RM paragraph 4.6(15). Paragraph 4.6(20) provides
enlightening examples.
Norman Cohen
IBM Research
^ permalink raw reply [relevance 6%]
* Ada decimal math, an example (or counterexample)
@ 1988-06-30 21:53 6% CONTR47
0 siblings, 0 replies; 57+ results
From: CONTR47 @ 1988-06-30 21:53 UTC (permalink / raw)
with text_io; use text_io;
procedure decimal is
type dollar_type is delta 0.01 range 0.00..1000.00;
package decimal_io is new fixed_io(dollar_type); use decimal_io;
my_dime : dollar_type :=
0.01 + 0.01 + 0.01 + 0.01 + 0.01 + 0.01 + 0.01 + 0.01 + 0.01 + 0.01;
-- 1 2 3 4 5 6 7 8 9 10
your_dime : dollar_type := 0.0;
begin
for i in 1..10 loop
your_dime := your_dime + 0.01;
end loop;
put("-- my_dime is worth "); put ( my_dime ); new_line;
put("--your_dime is worth "); put ( your_dime ); new_line;
end decimal;
-- Janus 2.0.2 prints:
-- my_dime is worth 0.08 (Janus apparently isn't doing universal math)
--your_dime is worth 0.08
-- Alsys v3.2 prints:
-- my_dime is worth 0.10
-- your_dime is worth 0.08
-- Verdix (VADS Version 5.41 ) prints:
-- my_dime is worth 0.10
-- your_dime is worth 0.07 (apparently it truncates on I/O)
--Dec version 1.3 prints:
-- my_dime is worth 0.08 (apparently isn't doing universal math)
-- your_dime is worth 0.08
--Since Dec says my_dime is worth 0.08 I now question whether
--Universal math is required for the initialization. Maybe
--only Alsys is doing the my_dime computation at compile time
--and therefore using Universal math and the others are doing
--it at run time using model numbers. What do you experts say?
--I formally withdraw my suggestion to perform computation
--in the declarative region in order to have it done by
--universal math. Sigh.
--regards,sam harbaugh
----------------------
^ permalink raw reply [relevance 6%]
Results 1-57 of 57 | reverse | options above
-- pct% links below jump to the message on this page, permalinks otherwise --
1988-06-30 21:53 6% Ada decimal math, an example (or counterexample) CONTR47
1988-07-01 17:54 6% Norman Cohen
1988-07-03 18:49 6% Ada decimal elaboration, further experimentation CONTR47
1988-07-03 23:36 6% ` Dik T. Winter
1988-07-05 23:39 7% ` Michael Murphy
1988-07-09 19:22 7% ` Ada decimal elaboration, furthe stt
1988-07-06 18:48 6% Ada decimal math, an example (or counterexample) Gary Morris @flash
1991-06-26 3:12 0% Ada IBM/370/MVS MIS Applications John Prentice
1993-03-19 19:57 Membership in "set" of characters Mark A Biggar
1993-03-22 10:37 ` Andrew Dunstan,,2285592,
1993-03-22 12:22 4% ` Debora Weber-Wulff
1993-03-19 21:16 14% Ada Decimal Arithmetic & Representations (ADAR) V1.0 available Michele L. Kee (AdaIC)
1993-03-21 23:12 5% ` Michael Feldman
1993-03-22 9:53 2% ` Rolf EBERT
1993-03-22 22:33 6% ` Keith Thompson @pulsar
1993-03-24 1:33 4% ` Robert I. Eachus
1993-03-25 1:22 3% ` Keith Thompson @pulsar
1993-03-25 21:29 5% ` Robert I. Eachus
1993-04-10 16:19 5% Looking for experience with Ada/RPCs David Emery
1996-11-05 0:00 Leading zeros with Int_IO.Put()? Or another package? J.D. Baldwin
1996-11-05 0:00 ` David Shochat
1996-11-08 0:00 ` robin
1996-11-08 0:00 ` Robert Dewar
1996-11-13 0:00 6% ` robin
1996-11-13 0:00 0% ` Ken Garlington
1996-11-19 0:00 6% ` robin
1997-04-21 0:00 8% Tagged Types and Generics Robert C. Leif, Ph.D.
1997-04-24 0:00 6% ` Jeff Carter
1997-10-13 0:00 Depending on passing mechanism Andre Spiegel
1997-10-14 0:00 ` Robert Dewar
1997-10-14 0:00 ` Henry Baker
1997-10-21 0:00 ` Robert A Duff
1997-10-22 0:00 ` Henry Baker
1997-10-21 0:00 ` Matthew Heaney
1997-10-23 0:00 ` Henry Baker
1997-10-24 0:00 7% ` Robert Dewar
2002-07-16 17:53 Floating Decimal Package/Library? Warren W. Gay VE3WWG
2002-07-17 1:24 ` tmoran
2002-07-17 8:28 ` Vadim Godunko
2002-07-17 13:32 ` Warren W. Gay VE3WWG
2002-07-22 23:33 6% ` Robert I. Eachus
2002-07-23 13:16 0% ` Marin David Condic
2002-07-17 1:24 tmoran
2002-07-17 2:53 7% ` Robert C. Leif
2002-08-13 2:00 Information Systems Annex was RE: Dispatching and generics - language lawyer question Robert C. Leif
2002-08-13 17:37 7% ` Keith Thompson
2002-08-13 23:53 7% ` Robert C. Leif
2002-08-15 9:26 0% ` Robert Dewar
2002-08-15 21:54 0% ` Decimal Floating types was " Robert C. Leif
2002-08-16 15:47 0% ` Information Systems Annex (usefulness of Decimal Floats) Warren W. Gay VE3WWG
2006-05-04 15:23 7% Ada decimal types REH
2006-05-04 18:17 7% ` Jeffrey R. Carter
2006-05-04 22:20 7% ` REH
2006-05-05 9:14 7% ` Stephen Leake
2006-05-05 11:33 7% ` REH
2006-05-05 16:49 5% ` tmoran
2006-05-05 18:08 7% ` REH
2006-05-05 18:49 7% ` tmoran
2006-05-05 18:59 7% ` REH
2006-05-06 8:59 7% ` Keith Thompson
2006-05-06 14:01 7% ` REH
2006-05-06 15:48 6% ` Simon Wright
2006-05-06 16:39 7% ` REH
2006-05-08 21:19 6% ` Randy Brukardt
2006-05-09 23:21 7% ` REH
2006-05-10 1:08 7% ` Keith Thompson
2006-05-10 5:37 7% ` Simon Wright
2006-05-10 12:22 7% ` REH
2006-05-10 20:47 5% ` Randy Brukardt
2006-05-10 21:26 7% ` REH
2006-05-10 20:52 7% ` Randy Brukardt
2006-05-11 5:51 7% ` Simon Wright
2006-05-11 22:33 7% ` Randy Brukardt
2006-05-05 20:32 7% ` Randy Brukardt
2006-05-11 8:20 What is Delta?? Sathish Veluswamy
2006-05-11 12:49 ` Martin Krischik
2006-05-12 11:12 ` Sathish Veluswamy
2006-05-12 13:49 5% ` Martin Krischik
[not found] ` <0bd9625e9e1eg27a2140e8jp1mli25k61n@4ax.com>
2006-05-12 19:27 ` Björn Persson
2006-05-13 6:52 5% ` Martin Krischik
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox