Do saturating integers solve the "signed vs. unsigned" debate?

Discussion in 'C++' started by joe, Sep 12, 2010.

  1. joe

    joe Guest

    Do/would they?
     
    joe, Sep 12, 2010
    #1
    1. Advertisements

  2. joe

    Kai-Uwe Bux Guest

    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
     
    Kai-Uwe Bux, Sep 12, 2010
    #2
    1. Advertisements

  3. 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.
     
    Francesco S. Carta, Sep 12, 2010
    #3
  4. joe

    Öö Tiib Guest

    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.
     
    Öö Tiib, Sep 12, 2010
    #4
  5. joe

    joe Guest

    joe, Sep 12, 2010
    #5
  6. joe

    joe Guest

    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
    }
     
    joe, Sep 12, 2010
    #6
  7. joe

    joe Guest

    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."
     
    joe, Sep 12, 2010
    #7
  8. joe

    joe Guest

    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.
     
    joe, Sep 12, 2010
    #8
  9. 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 ;-)
     
    Francesco S. Carta, Sep 12, 2010
    #9
  10. joe

    Öö Tiib Guest

    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.
     
    Öö Tiib, Sep 12, 2010
    #10
  11. joe

    joe Guest

    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?
     
    joe, Sep 12, 2010
    #11
  12. joe

    joe Guest

    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.
     
    joe, Sep 12, 2010
    #12
  13. 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.
     
    Francesco S. Carta, Sep 13, 2010
    #13
  14. 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.
     
    Francesco S. Carta, Sep 13, 2010
    #14
  15. joe

    joe Guest

    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!
     
    joe, Sep 13, 2010
    #15
  16. joe

    joe Guest

    Well I don't remember you interjecting your thoughts into the Godzilla
    vs. Megalon event. Apparently an "armchair quarterback"?
     
    joe, Sep 13, 2010
    #16
  17. joe

    Öö Tiib Guest

    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.
     
    Öö Tiib, Sep 13, 2010
    #17
  18. 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.
    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 :)
    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.
     
    Francesco S. Carta, Sep 13, 2010
    #18
  19. 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.
     
    Francesco S. Carta, Sep 13, 2010
    #19
  20. joe

    joe Guest

    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.
     
    joe, Sep 14, 2010
    #20
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.