Dimensions and fixed point types

Dimensions and fixed point types

[Duncan Sands]

Fixed point types have a remarkable property:
you can multiply any two of them to get a third.
You can multiply apples and oranges and get
bananas.  This goes against type safety.

Suppose I have several fixed point types, for
example

type Price is delta 0.01 digits ...;
type Volume is delta 1.0 digits ...;
type Value is delta 0.01 digits ...;

Then all possible multiplications are legal.  By
declaring some multiplications abstract, I can
remove unwanted operations, and just keep the
ones I want, for example Price * Volume = Value.
(This is already a lot of operations to remove!).

However if somewhere else I define

type Oranges is delta ... digits ...;

then I automagically get a whole bunch of new
operations (Orange * Value = Price etc) that I
don't want.  To be safe I'd need to remove them
all too - it is never ending.  This makes fixed point
types almost useless in a dimensions system, or
whenever you want to catch incorrect operations
based on type.

Maybe there is a trick I am missing though.  Can
anyone see a way to use fixed point types safely
in a setting where multiplying objects of the wrong
type would be fatal?

Also, why were things done this way?  It seems to
me that a much better approach would be to say
that multiplication between different fixed point types
is NOT automatically defined, but can be obtained
by writing something like this:

function "*" (Left : Apples; Right : Oranges) return Banana;
pragma Import (Intrinsic, "*");

Thanks for any comments,

Duncan.

Re: Dimensions and fixed point types

[Martin Dowie]

"Duncan Sands" <baldrick@free.fr> wrote in message
news:mailman.77.1086765132.391.comp.lang.ada@ada-france.org...
> Fixed point types have a remarkable property:
> you can multiply any two of them to get a third.
> You can multiply apples and oranges and get
> bananas.  This goes against type safety.
[snip]
> function "*" (Left : Apples; Right : Oranges) return Banana;
> pragma Import (Intrinsic, "*");

I think this is being addressed by the ARG in AI-364

http://www.ada-auth.org/cgi-bin/cvsweb.cgi/AIs/AI-00364.TXT?rev=1.6

Still a work item though...

Re: Dimensions and fixed point types

[Robert I. Eachus]

Martin Dowie wrote:

> "Duncan Sands" <baldrick@free.fr> wrote in message
> news:mailman.77.1086765132.391.comp.lang.ada@ada-france.org...
> 
>>Fixed point types have a remarkable property:
>>you can multiply any two of them to get a third.
>>You can multiply apples and oranges and get
>>bananas.  This goes against type safety.

I agree, and I objected to the original Ada95 rule that allowed the 
explict type conversion from universal fixed to be omitted.  In addition 
to the problems created when you do want to explicitly define a multiply 
operation, it creates the serious problem Duncan refers to:

>> Suppose I have several fixed point types, for
>> example
>> 
>> type Price is delta 0.01 digits ...;
>> type Volume is delta 1.0 digits ...;
>> type Value is delta 0.01 digits ...;

P: Price; V: Volume; Val: Value;
...
P := V * Val; -- the compiler won't object!

> I think this is being addressed by the ARG in AI-364
> 
> http://www.ada-auth.org/cgi-bin/cvsweb.cgi/AIs/AI-00364.TXT?rev=1.6
> 
> Still a work item though...

What is being worked on is actually different problem, where you do want 
to declare your own multiplication or division operators, and find that 
they can't be called in infix notation.

That having been said, the current version exactly fixes Duncan Sands 
problem.  According to the new draft, if you declare a multiplication 
operation for Apples, all of the "special" Apple * fixed and fixed * 
Apple operations returning universal_fixed will be hidden where the user 
defined operators are visible.

So to go back to Duncan's original complaint add:

function "*"(Left: Price; Right: Volume) return Value;

This will hide ALL the predefined operations that Duncan wants to get 
rid of, and any new ones that involve Price, Volume, or Value, so the line:

P := V * Val; -- The compiler will complain that no visible "*" matches.

Glad to be of service. ;-)


-- 

                                           Robert I. Eachus

"The terrorists rejoice in the killing of the innocent, and have 
promised similar violence against Americans, against all free peoples, 
and against any Muslims who reject their ideology of murder. Their 
barbarism cannot be appeased, and their hatred cannot be satisfied. 
There's only one way to deal with terror: We must confront the enemy and 
stay on the offensive until these killers are defeated." -- George W. Bush

Re: Dimensions and fixed point types

[Duncan Sands]

Hi Robert,

> So to go back to Duncan's original complaint add:
> 
> function "*"(Left: Price; Right: Volume) return Value;
> 
> This will hide ALL the predefined operations that Duncan wants to get 
> rid of, and any new ones that involve Price, Volume, or Value, so the line:
> 
> P := V * Val; -- The compiler will complain that no visible "*" matches.

while it would indeed solve my problem, it also makes the rules for fixed
point types even more exotic than they are right now, which is a bad thing
in my opinion.

All the best,

Duncan.

Re: Dimensions and fixed point types

[Duncan Sands]

On Wednesday 09 June 2004 09:47, Martin Dowie wrote:
> "Duncan Sands" <baldrick@free.fr> wrote in message
> news:mailman.77.1086765132.391.comp.lang.ada@ada-france.org...
> > Fixed point types have a remarkable property:
> > you can multiply any two of them to get a third.
> > You can multiply apples and oranges and get
> > bananas.  This goes against type safety.
> [snip]
> > function "*" (Left : Apples; Right : Oranges) return Banana;
> > pragma Import (Intrinsic, "*");
> 
> I think this is being addressed by the ARG in AI-364
> 
> http://www.ada-auth.org/cgi-bin/cvsweb.cgi/AIs/AI-00364.TXT?rev=1.6
> 
> Still a work item though...

Hi Martin, thanks for the interesting reference.  I don't like this approach
at all: "improving" a wart by adding another little wart on top of it.  It's
damage control.  The damage was done when the decision was taken
to define multiplication and division automatically between any fixed point
types (big mistake).  I understand that the ARG wants to maintain backwards
compatibility, but I think they are wrong.  For example, suppose in Ada 200x
this rule was thrown away, and replaced with the rule that you (the programmer)
have to define multiplication explicitly, but can import it from intrinsic (see above).
Then correct Ada 95 programs would no longer compile.  However they could
be made to compile and work the same via a purely mechanical operation:
importing the multiplication operation in every unit where it is needed.  It
probably wouldn't be hard to write a tool that adds the right declarations automatically.
So while backwards compatibility would not be retained (correct Ada 95 programs
will no longer compile), the cost of upgrading would be quite small.  This seems
better to me: a little pain for a good gain.

Ciao,

Duncan.

Re: Dimensions and fixed point types

[Hyman Rosen]

Duncan Sands wrote:
> Fixed point types have a remarkable property:
> you can multiply any two of them to get a third.
> You can multiply apples and oranges and get
> bananas.  This goes against type safety.

You appear to imply that multiplying apples and apples
to get apples, on the other hand, *is* "type safe". Why?

Re: Dimensions and fixed point types

[Duncan Sands]

On Friday 11 June 2004 09:26, Hyman Rosen wrote:
> Duncan Sands wrote:
> > Fixed point types have a remarkable property:
> > you can multiply any two of them to get a third.
> > You can multiply apples and oranges and get
> > bananas.  This goes against type safety.
> 
> You appear to imply that multiplying apples and apples
> to get apples, on the other hand, *is* "type safe". Why?

I implied no such thing.

Duncan.

Re: Dimensions and fixed point types

[Hyman Rosen]

Duncan Sands wrote:
> On Friday 11 June 2004 09:26, Hyman Rosen wrote:
>>You appear to imply that multiplying apples and apples
>>to get apples, on the other hand, *is* "type safe". Why?
> 
> I implied no such thing.

Well, here's what you said:
    > It seems to me that a much better approach would be
    > to say that multiplication between different fixed
    > point types is NOT automatically defined

This certainly implies that you believe that multiplication
of a fixed point type with itself should be automatically
defined. How else is one to read this?

Re: Dimensions and fixed point types

[Duncan Sands]

On Friday 11 June 2004 19:47, Hyman Rosen wrote:
> Duncan Sands wrote:
> > On Friday 11 June 2004 09:26, Hyman Rosen wrote:
> >>You appear to imply that multiplying apples and apples
> >>to get apples, on the other hand, *is* "type safe". Why?
> > 
> > I implied no such thing.
> 
> Well, here's what you said:
>     > It seems to me that a much better approach would be
>     > to say that multiplication between different fixed
>     > point types is NOT automatically defined
> 
> This certainly implies that you believe that multiplication
> of a fixed point type with itself should be automatically
> defined. How else is one to read this?

There is no contradiction.  Not saying X is not the same
as saying not X.  However from a practical point of view,
any proposal to not have multiplication be auto-defined
between fixed point numbers of the same type would
never be accepted, since such multiplication is defined
in the case of integer and floating point types.  So I didn't
propose it.  That doesn't mean I think that auto-defining
such multiplication is a good idea.  In many contexts
multiplying two numbers of the same type makes no sense.

Ciao,

Duncan.

Re: Dimensions and fixed point types

[Robert I. Eachus]

Duncan Sands wrote:

> There is no contradiction.  Not saying X is not the same
> as saying not X.  However from a practical point of view,
> any proposal to not have multiplication be auto-defined
> between fixed point numbers of the same type would
> never be accepted, since such multiplication is defined
> in the case of integer and floating point types.  So I didn't
> propose it.  That doesn't mean I think that auto-defining
> such multiplication is a good idea.  In many contexts
> multiplying two numbers of the same type makes no sense.

I have to agree with Hyman on this one.  In Ada 83 and Ada 95 
multiplication (or division) of a fixed-point parameter by Integer is 
predefined, but there is no "function "*" (L,R: _T_) return _T_" as 
there is for integer and floating-point types.

So such multiplication is not now "auto-defined".  There is the 
operation returning _universal_fixed_, and I agree that it would have 
been nice if it did not have global visibility.  Maybe it should be put 
in a package within Standard so that you have to use prefix notation or 
a use clause if you want to use it.  The operation is necessary so that 
users can define needed operations.  The original visibility wasn't bad, 
it is the added Ada 95 visibility that is a mistake.  The current 
position being discussed is a compromise.  It will make some legal Ada 
95 programs illegal, but only silly ones.

-- 

                                           Robert I. Eachus

The ideology he opposed throughout his political life insisted that 
history was moved by impersonal tides and unalterable fates. Ronald 
Reagan believed instead in the courage and triumph of free men and we 
believe it all the more because we saw that courage in him.  -- George 
W. Bush June 11, 2004