RE: [boost] Re: A pure C/C++ question

From: David Bergman (davidb_at_[hidden])
Date: 2002-08-21 23:00:00

I realize that I should restate two things:

1. Dealing with integers in a context-sensitive manner would complicate
semantics
2. Introducing "fractional" syntax would underline the main purpose,
multiplying a rational number with a whole or other rational number.
Does that not cover most cases where this would be useful?

/David 

-----Original Message-----
From: boost-bounces_at_[hidden]
[mailto:boost-bounces_at_[hidden]] On Behalf Of David Bergman
Sent: Wednesday, August 21, 2002 11:49 PM
To: boost_at_[hidden]
Subject: RE: [boost] Re: A pure C/C++ question

McSeem (or Maxim),

What we really would want is syntax for rationals, like "a/b". That
rational could then be compiled using the double precision internal ALU
stuff of most architectures when multiplied with either another rational
or an integer. Maybe "rat<a,b>"?

It is getting late, so this "suggestion" is a bit whimsical,
admittedly... But it would keep the integers as is, not to break
existing code (not that much code would, I agree...), but more
importantly to make expressions context-sensitive, which might NOT be a
good idea for RHS expressions... Hard to define semantics in such a
beast.

/David

-----Original Message-----
From: boost-bounces_at_[hidden]
[mailto:boost-bounces_at_[hidden]] On Behalf Of Maxim Shemanarev
Sent: Wednesday, August 21, 2002 11:31 PM
To: boost_at_[hidden]
Subject: [boost] Re: A pure C/C++ question

> If the committee is seriously considering ways to handle stuff, how
> about dealing with the two results returned by almost every integer 
> divide instruction... quotient and remainder.

Right. That's another thing. But in this case if you write x=a/b; y=a%b;
a compiler at least  *can try* to optimize this. In case of x*a/b it
cannot because it's not allowed to! The question is really not a
technical one. We really don't have a choice even if we were the ANSI
committee.

Suppose, it's resolved, i.e. an experssion x*a/b works as I want. I
honestly don't think there're lots of code will be affected, moreover, I
believe that there's nothind serious will go wrong. If something will it
means it was
*written* wrong, at least not in a professional manner. Still if I were
the committee I wouldn't take the responsibility to change these things
because... I just would be afraid to. We live in the real world. So. The
only possibility is to add thing but not change the existing ones even
when they look stupid.

There's another thing. Actually there's no way to make the expression
y=x*a/b work as I proposed (i.e. using 64-bit for x*a). That's because
it's not clear what to do with more complex expressions, like
y=x*a*b*c*d/e; Really, what? As soon as x*a is computed we will have to
deal with the rest of the expression in 64 bits, but we rally don't need
to! There's no choice. So, let it be as it is! But I (and we) really
need some sort of a new syntax for simple constructions like y=x*a/b.
The syntax with a separate variable as the intermediate result is also
not appropriate because there's also not clear for the compiler. Suppose
we have code like: longest_long t=x*a;
blah_blah=blah_blah_function(blah_blah_blah);
int final_result = t/b;
I don't think we could rely on any optimizer in this case. So, the only
possibility is to add a new syntax construction or at least a
standardized function. And ideally it would be great this operation to
be overloadable. I can imagine what the committee would say about it :-)
They would say something like "let's play a game: you won't tell us what
to do and we won't tell you where you should go to" :-)

But still, the issue exists.

McSeem

_______________________________________________
Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost

_______________________________________________
Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost