J
joe
Do/would they?
K
Kai-Uwe Bux
joe wrote:
[about: Re: Do saturating integers solve the "signed vs. unsigned" debate?]
That would depend on the precise rules for signed and unsigned arithmetic
types that you propose, in particular the rules for how values are treated
in expressions that contain signed and unsigned subexpressions. Without
language to replace 4.5 and 4.7, it is impossible to tell.
Best
Kai-Uwe Bux
[about: Re: Do saturating integers solve the "signed vs. unsigned" debate?]
That would depend on the precise rules for signed and unsigned arithmetic
types that you propose, in particular the rules for how values are treated
in expressions that contain signed and unsigned subexpressions. Without
language to replace 4.5 and 4.7, it is impossible to tell.
Best
Kai-Uwe Bux
F
Francesco S. Carta
on 11/09/2010 18:54:46 said:
What's your pick? And have you considered the "safety vs performance"
debate? Would they solve it, after calling for it?
Heck, I'm watching astonished as another "C++ vs Java vs whatever"
debate is taking place right now... I wonder if we have nothing more
important to spend our time on.
We have tasks, we have tools. We should just pick the tool that we find
more fitting and comfortable to solve each task, and stop pushing
languages, techniques and implementations one against the other as if we
would get a living out of it.
Ö
Öö Tiib
What debate? I have seen here smart people (very verbosely and with
insults involved) agreeing with each other that:
a) mixing signed and unsigned arithmetic is evil.
b) both signed and unsigned arithmetic has usages.
Only debate can be that where exactly to use what. And that is
pointless debate mostly since no one of them will go and rewrite their
code-base after losing such debate anyway.
Only good form of saturation is when overflows result with "infinity",
"negative infinity" or "not a number" values like IEEE 754 does with
floating point numbers. Current integers are capacious enough to
reserve some values for it, but i don't know if any hardware supports
something like that.
Usual saturation arithmetic can solve nothing ... subtracting 1U from
0U is likely a bug and should be fixed. No much difference if it
results with 0U or 4294967295U.
J
joe
joe said:
Here are some background and potential user-level solutions links:
http://en.wikipedia.org/wiki/Saturating_arithmetic
http://www.drdobbs.com/184401988
http://stackoverflow.com/questions/121240/saturating-addition-in-c
http://www.tommesani.com/MMXArithmetic.html
http://en.wikibooks.org/wiki/X86_Assembly/MMX
J
joe
Kai-Uwe Bux said:
Yeah, those pesky implicit integer promotions/conversions evermoreso rear
their ugly head. That aside though, which is something for the language
lawyers to figure out, I am chomping at the bit for elegant precondition
checking semantics by a called function taking integer arguments, such as
malloc, for one example.
I'd be more than glad to "give up" the max value of an integer to get
that. Secondly, I would opt for clipping to the max value whether
overflow OR underflow occurred (since clipping to 0 really messes up all
the places where 0 is a valid value), as I don't believe the
error-condition is something for mainline code to rely on (such as in the
DSP scenario given in one of the links I posted), and underflow, of
course, would result in large values usually (e.g., a 'for' loop that
counts downwards) anyway with wrapping integers.
Lastly, (and this may be much harder to accomplish) I'd want a var to
STAY saturated once it became so (if practically possible). Is it Xmas
yet?
I'm not sure if I would ever use wrapping integers if there were
saturating ones available. I haven't yet assessed the user-land solutions
from the Stack Overflow link I posted, but something there (or the
HEAVYWEIGHT SafeInt class) may work OK, although much less elegantly than
language-level support.
Just a couple of examples:
void* malloc(sat_uint32 sz)
{ // catch the bug that a negative number was passed as sz
assert(sz != UI32_SATURATION)
// blah...
}
void func2()
{ // from 100 to 0 inclusive
for(sat_uint32 i=100; i != UI32_SATURATION; i--)
// blah something with i
}
J
joe
Francesco said:
Note that there is a C extension (Embedded C) that provides saturation
semantics, so it's not a "way out there" pursuit. My post was from need,
not from language comparison. If I were someone who places bets, I'd bet
that C++ will have this feature some day (it's just so woeful that the
process is so broken that it takes decades to get anything done with the
standard). All is not lost though, I'm all for compiler-specific
extensions if it gets it to me in my lifetime (!) (listen up MS/VC++...
differentiated product.. value added... $$$).
Now you sound like the C guys: "The language is no longer evolving, just
being maintained."
J
joe
Öö Tiib said:
Whether unsigned integers should be avoided. Whether size_t is the
appropriate type or just a relic from history that has continual
consequence.
It analyzes language design choices. That everyone is "stuck" with those
choices in C/C++ does not make the discussion moot by any means. Like
they say, if you don't like what's on TV, don't watch it.
Why do you think so?
But there are saturation semantics available in Intels SIMD (or MMX)
assembly instructions. And there's always been the overflow flags that a
compiler could take advantage of, I presume.
I gave 2 examples in a new post above. Whereas the for loop with wrapping
integers is "sharp knife to be handled with care", saturation semantics
make it "child-safe". The DSP example from one of the links is another
and surely led to the extension of C to Embedded C (but clipping to 0, if
it does that doesn't sound at all "general").
Which is easily assertable with saturation semantics, else not.
F
Francesco S. Carta
I must have failed to explain my point properly, my point being that any
kind of absolute debate - signed vs unsigned, safety vs speed, saturated
vs unsaturated and so on - is almost useless unless we contextualize the
discussion for the specific use cases.
Even if saturated integrals came for free in all the cases, one will
eventually want to use unsaturated ones /on purpose/ for some specific
tasks.
Besides, nobody forbids you to implement saturated integrals in C++, the
language facilities and features are there for you to use and extend,
you don't have to wait the standard or your library implementer to do
that for you.
Not my purpose. Once more, my point is about contextualizing the
discussion. There is nothing clever or constructive in absolute debates
aiming to artificially raise one side of the balance out of thin air.
Once we start putting weights on each side, the balance will "naturally"
tilt to one side or to the other - the analogy is faulty because some
weights will be pondered differently from different points of view,
hence sometimes also fully contextualized debates fall in the "let's
agree we disagree" category - which is fine, because of the appended
full stop ;-)
Ö
Öö Tiib
These are sane results of overflowing operation. Sort of "can't tell"
or "invalid operands". In lot of programs such "missing value" values/
states are artificially added anyway. If some "missing value" had been
already there than these were far more often used than value
represented by std::numeric_limits<int>::min() for example.
Sometimes "missing values" are frequent enough to even bother to call
them as something exceptional. For example when you do millions of
measurements (with interval of 40 nanoseconds) in a row and some of
measurements fail or give noise. Level of noise is information about
quality (and therefore reliability) of measurements. If it is low
enough you can make vital decisions anyway. It is sort of "null
pointer" that is currently missing in integral arithmetic.
Currently floating point is used in scientific calculations, but
various sensors usually return short integers. On most cases it is
very expensive to make physical sensors that can measure more
accurately than 3 significant decimal digits. Fortunately floating
point has become quick on modern platforms but its usage involves even
more care than with sometimes overflowing integral types. Devices used
in industrial manufacturing automatics often use fixed point
arithmetic.
Yes, but currently there still exist few platforms that support only
modular arithmetic and modular arithmetic has still valid (if rare)
usages. Like Kai-Uwe Bux said 4.5 and 4.7 need to be rewritten first
(maybe entirely new integral types need to be added) and then lot of
people have to agree with it.
Ok, i stand corrected; you can solve something. OTOH when any
operation with "missing value" gives "missing value" as result then it
is as child-safe as it can get i think.
J
joe
Francesco said:
That goes without saying and has been said and is constantly heard in
these newsgroups.
I view them as an ADDITION, not replacements.
I think it would be elegant with language/compiler support. Certainly
much more efficient.
The OP was a continuation from another thread. No one was being overly
general especially since the area is well-understood and has many
examples and implementations. Perhaps you are not aware that the
territory is well-traveled and that's why you are "not getting" the
thread?
J
joe
Öö Tiib said:
So your point is what? That because it's difficult to do with C++ that it
just be forgotten? I say, the sooner the ball gets rolling, the sooner
the job will be done! That said, I don't have high hopes for
standardization anytime soon, but perhaps compiler vendors would initiate
and make it common practice which can then be standardized by ISO (which
is how it works, decidely, right?). It may be quite bold for a company to
implement such an optional C++ extension though (I would do it pronto if
I was a compiler vendor. "it" being do the R&D and see if it is practical
(noting that Embedded C already does this, it may be an easy analysis).
I'm not sure what you mean.
F
Francesco S. Carta
It is constantly repeated because lot of people happen to be deaf on
that ear.
Just like I do, of course. The point is not about having them available
or not, the point is _deciding_ to use one instead of the other. The
point is about your question, whether they would solve the debate. More
on this at the end of my post.
Language and compilers cannot give you something that you CPU can't.
Granted, you might very well have a CPU that gives you them while your
compiler/language doesn't.
My point is: why wait for the language and the compilers? Just create
your custom type and implement its internals in assembly.
If you cannot, that's another story. But then the only way to obtain
them would be to ask them to the language or to your compiler vendor.
I'm not a clairvoyant.
Incorrect, because your original post was extremely generic.
I think I'm getting it, but if you still believe I'm not, I will eagerly
read your explanations.
Let me resume, just to see if I got it right:
You drop in a post where you throw in the "signed vs unsigned" debate,
which is a silly debate in first place.
You point out saturated integrals asking whether they would solve the
debate - and to solve it, saturated integrals should replace the
existing ones.
You say that you see them as an addition, not as a replacement - hence,
in your opinion, they would not solve the debate.
Have I understood all of this correctly?
---
Now let's reset everything and speak about the metal.
We have signed and unsigned types. They both work perfectly as long as
you don't pass their limits. Once you've passed the line, several
different things could happen, but let's not list what happens in one
machine or another, the important thing to know is that breaking the
boundaries is bad because it leads to wrong results, and that's enough
for the purpose of this discussion.
Now we have saturated integrals which happen to address the problem
above by clipping all the operations at the boundaries - process that
still leads to wrong results, but not "that" bad.
All right, now let's ask the questions I find most interesting:
- Do saturated integrals come for free /in CPUs/? I mean, will they
perform /as fast as/ unsaturated integrals?
- Assuming they will /not/ come for free, will they allow significant
optimizations that will outperform unsaturated integrals?
If any of those two questions can be definitely answered with a "yes",
then I would say that saturated integrals will solve the silly "signed
vs unsigned" debate just to, eventually, open the doors to the even
sillier "saturated signed vs saturated unsigned" debate.
Just for the records, in any case, I would break the stick and steal the
dog to anybody standing between me and the wrapping integrals.
F
Francesco S. Carta
on 13/09/2010 04:20:10 said:
Just in case somebody wonders, I am fully aware of the different
behavior between (unsaturated) signed and unsigned types, when it comes
to "passing the line" - I mean, the difference between UB and wraparound
- that simply doesn't make the "signed vs unsigned" debate any less
silly to my eyes.
J
joe
Francesco said:
Or trying to tell you something? Who's deaf? Time will tell.
Wrong. Given that they are not a part of C++, the issue IS whether they
should be or not and if so, in what way.
It would be great if the "regulars" on that debate would "go at it" again
in this new context. (Who needs Netflix!).
The assumption is, duh, where there is that, and of course Intel has that
(not sure how effective, haven't looked into it deeply, and it's a bit
below the level I am programming at now). Note my other posts where I
mentioned SIMD and MMX.
That said, I know where you're going with that point: that it's "not
portable" because many CPUs don't have the capability. That sounds like a
big price to pay for those who are on hardware that does. THAT said,
while it may appear that I am suggesting it for the ISO standard (and I
am suggesting some people there take a look at the feasibility of it if
they haven't already, and even if they have, prepare a report on their
findings that represent the whole membership, remembering that the
members are just a sliver of the user base), I don't have my fingers
crossed or anything for that, and personally, I don't have much hope for
MS doing it either. (Jeez, I'm pessimistic today!).
Well you could have said that before I typed all of the just-above!
I'm slowly but surely approaching that level of capability, but I have
higher-level coding to worry about right now.
I've hinted at that too, but I think the chances are slim: I use VC++ and
what's the likelihood of MS putting that in C++ rather than C# (which I
refuse to use)?
Well not directly "a continuation". It wasn't necessary to know that to
"be on the same page" (not necessarilly in agreement, of course) with me.
It's called, "lead-in"/"intro". Personally, I don't read loooong posts
starting a new thread. Do you? (The subject question remains open yet
though, for sure. I wanted "someone else to do my thinking", kinda).
Well you are now, that's good. I should go into teaching?
I don't think the debate is "silly", and I wondered how a new landscape
where saturated integers were available would change that dialog, if in
any way.
"integral" is calculus. The correct term is 'integer'.
NOOOOOO ... NOT AT ALL! Jeez, give an ounce of credit to another human
already: how many times have I stated that an ADDITIONAL "set" (2? 1? ??)
of integers that "saturate" (whatever that means) rather than wrap was at
most the consideration, and NOT a replacement(!)?
Now this is getting annoying. You say stuff that requires me to type, and
then you say stuff that wastes my typing effort! (I guess I need to learn
LALR(1)).
Yes, a potential addition.
I'm not byting on that. I'm not part of the signed/unsigned debate. I was
WONDERING if the new hypothetical landscape would change anything in that
debate. (signed/unsigned, round 2?).
Not hardly.
Great. I'm all ears. (But don't call me Dumbo! (the elephant)).
Oh! Sounds like a skit. Shall we don costumes and have a gradeschool
play? (Just kidding).
Probably woefully inadequate, but go on.
(for all watching, he meant INTEGERS).
I was wondering if they would (not that I am agreeing to your statement
of "the problem"). I did not assert that they would. I am not even being
lazy in thinking, I just have other stuff to think about and certain
people here can "write it right down", so why should I tax my brain?
Well no. Did you even read my other post where I gave the malloc example?
OK, nevermind, you're analyzing the signed/unsigned thing. Back on track
now. (But didn't I already say that I don't want to think about this and
have better things to do?). That said, I welcome your thoughts.
As if this is some kind of juncture. Not for me! I'm hell-bent on
obtaining the capability to assert on the value passed to malloc and
filtering out the negative-value-passed bug.
(integERs!). Of course not, but they are an addition, not a replacement.
Pick your poison, and let freedom rain.
This is not a proper way to layout the project plan, but yes, those
things will have to be analyzed. Can I have your impartial report by next
Monday?
"You speak with strawman's tongue", comes to mind. Lighten up dude.
My turn for a "question". What is a "saturated integral"?. (I couldn't
resist, I'm laughing with you, not at you).
Sounds (to me) like you belong on the analysis team that figures this
out, maybe. (OTOH, ... thought for another time, nevermind).
See, I kinda get that, and got that incling from your post throughout,
even though I don't know WTF you are talking about!
J
joe
Francesco said:
Well I don't remember you interjecting your thoughts into the Godzilla
vs. Megalon event. Apparently an "armchair quarterback"?
Ö
Öö Tiib
Yes it is practical, it is used in practice where needed. Scientists
often need arithmetic where "missing value" is present, but scientists
are usually needing floating point that already has it. Of course
there are nothing usual about science sometimes it is "complex" what
they need, sometimes "tri-bool" (true, false and missing). It is also
doable with ints on most modern platforms. If you do not worry about
some overhead and loss of optimizations you can implement it already
in C++. There are operators and you can overload them.
Trouble is indeed difficulty to introduce it into standard. There are
already sitting "bool", "char", "short", "int" and "long" with
families and lot of code rightfully assumes these to be modular and go
nowhere. There will be no cryptography without modular arithmetic.
Adding something there makes it uglier since the more players on field
the more relations how something interoperates with and converts into
something else. So someone with good Diplomacy, English and
Standardeze skills (far better than me) is needed to propose something
to that effect.
F
Francesco S. Carta
Indeed. The problem being that I struggle to make my points as explicit
as possible, while some others don't.
Heck, of course "the point" was "my point", so there is nothing wrong
with it. I'll try to be more precise in the future.
Please keep in mind the statement you replied to: my point in this
thread is that if they try to solve any debate they need to be available
in first place (it doesn't matter that C++ has not them right now). So
assuming they are available, the point becomes: using them as a
replacement of regular types in order to solve the "signed vs. unsigned"
debate; once more, the core of the debate is about the _decision_ to use
a tool instead of another, not about its availability.
If that could help dropping the silly debate - not to jump into another
silly one, though - that would be great indeed.
No, you just think you know where I'm going. I welcome saturating
arithmetic as an optional, well defined extension of the language. I
just think it would not solve any silly debate.
I did! Aren't you accustomed to thoroughly read a post before replying
to it?
Fine for me.
I have no idea.
Well, that explains your original post indeed. Besides: no, I have no
particular problem in reading long posts as long as they are intelligible.
Well you are now, that's good. I should go into teaching?
For what concerns myself, I have no data to evaluate it - to put it
straight out, I don't feel I should thank you for having taught me
anything important.
Fine, different points of view and different concerns. Notice, though,
the difference between "solving the debate" and "change the landscape of
the dialog".
Ah, a really important nitpick! So important that you felt the need to
spell it out several times in the very post I'm replying to.
Please consider that I'm not a native speaker - if you didn't notice
that, that would be a compliment for my English - although that isn't
enough of a justification for my "mistake" due to the technicality of
the subject - "integrals" was just a handy short for "integral types",
just in case you didn't realize.
But I suppose I _did_ get the meaning across, didn't I? That would be
enough not to reiterate the nitpick.
Furthermore, once you were there at nitpicking, you could have corrected
my "saturated" spelling with "saturating", which is surely the correct one.
Eh, do you recall that sentence of mine that I asked you to keep in
mind? The noun "replacement", in the context of my post, is about
replacing regular integral types with saturating ones _in order to solve
the debate_, that is, _using_ them in practice, not replacing them by
pulling out regular ones out of the language.
I think my previous paragraph addresses the misunderstanding above.
Fine, modulo misunderstandings.
That was just to say that I wanted to put languages and compilers apart
for those closing thoughts and questions of mine.
That was put in layman and simplistic words on purpose to keep the
discussion away from secondary details - keeping them in mind, of
course, as theory must always cope with reality in the end.
_That_ is getting annoying.
Well yes, more on this right here below.
Heck, wasn't that the subject of your original post? Ah, I recall, the
implied previous context that you omitted to point out in your OP.
Thank you
Do you think there isn't any working way to filter out that bug other
than using saturating integral types, since /that/ is your concern?
(Besides, it would have been nice to clearly spell it out in first place
when you started this thread, you cannot assume that everybody reads
every post of every topic)
And now that has become definitely annoying.
Already addressed that point.
I second that as long as others' freedom isn't affected
This is not a proper way to layout the project plan, but yes, those
things will have to be analyzed. Can I have your impartial report by next
Monday?
I'd like to be able to, but unfortunately I'm not. I've just read that
paying the cost of the more-difficult-to-implement saturating arithmetic
helps optimizing and getting better results out of some metal that uses
them (DSPs), and I wondered if that kind of optimizations could be
applied at the programming level.
Uh? What's so hard to understand? If "they come for free" or if "the
optimizations they permit make them just as convenient" then they can be
used as a safer replacement for regular types, therefore the debate
would be over, that's my position.
Well, finally you addressed the "saturat/ed/" issue somewhat, but I hope
you understand that the nitpick becomes extremely annoying and maybe
even offensive at its fourth occurrence - your parenthetic didn't help
at all in that matter.
Eh, just to let you know, I'm just an hobbyist with a high school degree
who has never worked as a professional programmer, let alone putting my
hands on such advanced topic as software analysis.
That would be extremely offensive to dismiss all of this discussion just
because of the above fact, just in case...
Eheheheh, that was a joke, I just forgot to add a smile ;-)
Just like in any other technical field, in language design and compiler
design we have geniuses as well as blind people, hence the joke about
the stick and the dog.
Hey, I know that you weren't suggesting to remove modulo arithmetic from
the available features, that joke wasn't addressed to anyone in particular.
F
Francesco S. Carta
Could you elaborate? I'm not familiar with rugby analogies - maybe I
could understand it better if you put it in soccer terms, although I
prefer more direct kinds of communication.
J
joe
The "proverbial" "bottom line" is.... do fat old women own the internet?
( you are one, so you would know ). You are barking on the wrong tree
dude.
( you are one, so you would know ). You are barking on the wrong tree
dude.
ncesco S. Carta wrote:
Indeed. The problem being that I struggle to make my points as
explicit as possible, while some others don't.
Heck, of course "the point" was "my point", so there is nothing wrong
with it. I'll try to be more precise in the future.
Please keep in mind the statement you replied to: my point in this
thread is that if they try to solve any debate they need to be
available in first place (it doesn't matter that C++ has not them
right now). So assuming they are available, the point becomes: using
them as a replacement of regular types in order to solve the "signed
vs. unsigned" debate; once more, the core of the debate is about the
_decision_ to use a tool instead of another, not about its
availability.
If that could help dropping the silly debate - not to jump into
another silly one, though - that would be great indeed.
No, you just think you know where I'm going. I welcome saturating
arithmetic as an optional, well defined extension of the language. I
just think it would not solve any silly debate.
I did! Aren't you accustomed to thoroughly read a post before replying
to it?
Fine for me.
I have no idea.
Well, that explains your original post indeed. Besides: no, I have no
particular problem in reading long posts as long as they are
intelligible.Well you are now, that's good. I should go into teaching?
For what concerns myself, I have no data to evaluate it - to put it
straight out, I don't feel I should thank you for having taught me
anything important.
Fine, different points of view and different concerns. Notice, though,
the difference between "solving the debate" and "change the landscape
of the dialog".
Ah, a really important nitpick! So important that you felt the need to
spell it out several times in the very post I'm replying to.
Please consider that I'm not a native speaker - if you didn't notice
that, that would be a compliment for my English - although that isn't
enough of a justification for my "mistake" due to the technicality of
the subject - "integrals" was just a handy short for "integral types",
just in case you didn't realize.
But I suppose I _did_ get the meaning across, didn't I? That would be
enough not to reiterate the nitpick.
Furthermore, once you were there at nitpicking, you could have
corrected my "saturated" spelling with "saturating", which is surely
the correct one.
Eh, do you recall that sentence of mine that I asked you to keep in
mind? The noun "replacement", in the context of my post, is about
replacing regular integral types with saturating ones _in order to
solve the debate_, that is, _using_ them in practice, not replacing
them by pulling out regular ones out of the language.
I think my previous paragraph addresses the misunderstanding above.
Fine, modulo misunderstandings.
That was just to say that I wanted to put languages and compilers
apart for those closing thoughts and questions of mine.
That was put in layman and simplistic words on purpose to keep the
discussion away from secondary details - keeping them in mind, of
course, as theory must always cope with reality in the end.
_That_ is getting annoying.
Well yes, more on this right here below.
Heck, wasn't that the subject of your original post? Ah, I recall, the
implied previous context that you omitted to point out in your OP.
Thank you
Do you think there isn't any working way to filter out that bug other
than using saturating integral types, since /that/ is your concern?
(Besides, it would have been nice to clearly spell it out in first
place when you started this thread, you cannot assume that everybody
reads every post of every topic)
And now that has become definitely annoying.
Already addressed that point.
I second that as long as others' freedom isn't affected
This is not a proper way to layout the project plan, but yes, those
things will have to be analyzed. Can I have your impartial report by
next Monday?
I'd like to be able to, but unfortunately I'm not. I've just read that
paying the cost of the more-difficult-to-implement saturating
arithmetic helps optimizing and getting better results out of some
metal that uses them (DSPs), and I wondered if that kind of
optimizations could be applied at the programming level.
Uh? What's so hard to understand? If "they come for free" or if "the
optimizations they permit make them just as convenient" then they can
be used as a safer replacement for regular types, therefore the debate
would be over, that's my position.
Well, finally you addressed the "saturat/ed/" issue somewhat, but I
hope you understand that the nitpick becomes extremely annoying and
maybe even offensive at its fourth occurrence - your parenthetic didn't
help
at all in that matter.
Eh, just to let you know, I'm just an hobbyist with a high school
degree who has never worked as a professional programmer, let alone
putting my hands on such advanced topic as software analysis.
That would be extremely offensive to dismiss all of this discussion
just because of the above fact, just in case...
Eheheheh, that was a joke, I just forgot to add a smile ;-)
Just like in any other technical field, in language design and
compiler design we have geniuses as well as blind people, hence the
joke about the stick and the dog.
Hey, I know that you weren't suggesting to remove modulo arithmetic
from the available features, that joke wasn't addressed to anyone in
particular.