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. Advertising

  2. joe

    Kai-Uwe Bux Guest

    joe wrote:
    [about: Re: Do saturating integers solve the "signed vs. unsigned" debate?]
    > Do/would they?


    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. Advertising

  3. joe <>, on 11/09/2010 18:54:46, wrote:

    [subject is: Do saturating integers solve the "signed vs. unsigned" debate?]

    > Do/would they?


    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.

    --
    FSC - http://userscripts.org/scripts/show/59948
    http://fscode.altervista.org - http://sardinias.com
     
    Francesco S. Carta, Sep 12, 2010
    #3
  4. joe

    Öö Tiib Guest

    On 12 sept, 02:54, "joe" <> wrote:
    > Do/would they?


    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

    Kai-Uwe Bux wrote:
    > joe wrote:
    > [about: Re: Do saturating integers solve the "signed vs. unsigned"
    > debate?]
    >> Do/would they?

    >
    > 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.
    >


    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

    Francesco S. Carta wrote:
    > joe <>, on 11/09/2010 18:54:46, wrote:
    >
    > [subject is: Do saturating integers solve the "signed vs. unsigned"
    > debate?]
    >> Do/would they?

    >
    > 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.


    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... $$$).

    >
    > 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.


    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

    Öö Tiib wrote:
    > On 12 sept, 02:54, "joe" <> wrote:
    >> Do/would they?

    >
    > What debate?


    Whether unsigned integers should be avoided. Whether size_t is the
    appropriate type or just a relic from history that has continual
    consequence.

    > 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.


    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.

    >
    > 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.


    Why do you think so?

    >Current integers are capacious enough to
    > reserve some values for it, but i don't know if any hardware supports
    > something like that.


    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.

    >
    > Usual saturation arithmetic can solve nothing


    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").

    > ... subtracting 1U from
    > 0U is likely a bug and should be fixed.


    Which is easily assertable with saturation semantics, else not.

    > No much difference if it
    > results with 0U or 4294967295U.
     
    joe, Sep 12, 2010
    #8
  9. joe <>, on 11/09/2010 22:36:14, wrote:

    > Francesco S. Carta wrote:
    >> joe<>, on 11/09/2010 18:54:46, wrote:
    >>
    >> [subject is: Do saturating integers solve the "signed vs. unsigned"
    >> debate?]
    >>> Do/would they?

    >>
    >> 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.

    >
    > 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... $$$).


    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.

    >>
    >> 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.

    >
    > Now you sound like the C guys: "The language is no longer evolving, just
    > being maintained."


    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 ;-)

    --
    FSC - http://userscripts.org/scripts/show/59948
    http://fscode.altervista.org - http://sardinias.com
     
    Francesco S. Carta, Sep 12, 2010
    #9
  10. joe

    Öö Tiib Guest

    On 12 sept, 06:49, "joe" <> wrote:
    > Öö Tiib wrote:
    > > 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.

    >
    > Why do you think so?


    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.

    > >Current integers are capacious enough to
    > > reserve some values for it, but i don't know if any hardware supports
    > > something like that.

    >
    > 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.


    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.

    > > Usual saturation arithmetic can solve nothing

    >
    > 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").


    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

    Francesco S. Carta wrote:
    > joe <>, on 11/09/2010 22:36:14, wrote:
    >
    >> Francesco S. Carta wrote:
    >>> joe<>, on 11/09/2010 18:54:46, wrote:
    >>>
    >>> [subject is: Do saturating integers solve the "signed vs. unsigned"
    >>> debate?]
    >>>> Do/would they?
    >>>
    >>> 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.

    >>
    >> 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... $$$).

    >
    > 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.


    That goes without saying and has been said and is constantly heard in
    these newsgroups.

    >
    > 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.


    I view them as an ADDITION, not replacements.

    >
    > 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.


    I think it would be elegant with language/compiler support. Certainly
    much more efficient.

    >
    >>>
    >>> 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.

    >>
    >> Now you sound like the C guys: "The language is no longer evolving,
    >> just being maintained."

    >
    > Not my purpose. Once more, my point is about contextualizing the
    > discussion.


    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?

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

    joe Guest

    Öö Tiib wrote:
    > On 12 sept, 06:49, "joe" <> wrote:
    >> Öö Tiib wrote:
    >>> 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.

    >>
    >> Why do you think so?

    >
    > 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.
    >
    >>> Current integers are capacious enough to
    >>> reserve some values for it, but i don't know if any hardware
    >>> supports something like that.

    >>
    >> 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.

    >
    > 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.


    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).

    >
    >>> Usual saturation arithmetic can solve nothing

    >>
    >> 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").

    >
    > 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.


    I'm not sure what you mean.
     
    joe, Sep 12, 2010
    #12
  13. joe <>, on 12/09/2010 13:57:49, wrote:

    > Francesco S. Carta wrote:
    >> joe<>, on 11/09/2010 22:36:14, wrote:
    >>
    >>> Francesco S. Carta wrote:
    >>>> joe<>, on 11/09/2010 18:54:46, wrote:
    >>>>
    >>>> [subject is: Do saturating integers solve the "signed vs. unsigned"
    >>>> debate?]
    >>>>> Do/would they?
    >>>>
    >>>> 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.
    >>>
    >>> 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... $$$).

    >>
    >> 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.

    >
    > That goes without saying and has been said and is constantly heard in
    > these newsgroups.


    It is constantly repeated because lot of people happen to be deaf on
    that ear.

    >>
    >> 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.

    >
    > I view them as an ADDITION, not replacements.


    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.

    >>
    >> 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.

    >
    > I think it would be elegant with language/compiler support. Certainly
    > much more efficient.


    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.

    >>>>
    >>>> 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.
    >>>
    >>> Now you sound like the C guys: "The language is no longer evolving,
    >>> just being maintained."

    >>
    >> Not my purpose. Once more, my point is about contextualizing the
    >> discussion.

    >
    > The OP was a continuation from another thread.


    I'm not a clairvoyant.

    > No one was being overly
    > general especially since the area is well-understood and has many
    > examples and implementations.


    Incorrect, because your original post was extremely generic.

    > Perhaps you are not aware that the
    > territory is well-traveled and that's why you are "not getting" the
    > thread?


    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.

    --
    FSC - http://userscripts.org/scripts/show/59948
    http://fscode.altervista.org - http://sardinias.com
     
    Francesco S. Carta, Sep 13, 2010
    #13
  14. Francesco S. Carta <>, on 13/09/2010 04:20:10, wrote:

    <huge self snip>

    > - 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 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.

    --
    FSC - http://userscripts.org/scripts/show/59948
    http://fscode.altervista.org - http://sardinias.com
     
    Francesco S. Carta, Sep 13, 2010
    #14
  15. joe

    joe Guest

    Francesco S. Carta wrote:
    > joe <>, on 12/09/2010 13:57:49, wrote:
    >
    >> Francesco S. Carta wrote:
    >>> joe<>, on 11/09/2010 22:36:14, wrote:
    >>>
    >>>> Francesco S. Carta wrote:
    >>>>> joe<>, on 11/09/2010 18:54:46, wrote:
    >>>>>
    >>>>> [subject is: Do saturating integers solve the "signed vs.
    >>>>> unsigned" debate?]
    >>>>>> Do/would they?
    >>>>>
    >>>>> 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.
    >>>>
    >>>> 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... $$$).
    >>>
    >>> 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.

    >>
    >> That goes without saying and has been said and is constantly heard in
    >> these newsgroups.

    >
    > It is constantly repeated because lot of people happen to be deaf on
    > that ear.


    Or trying to tell you something? Who's deaf? Time will tell.

    >
    >>>
    >>> 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.

    >>
    >> I view them as an ADDITION, not replacements.

    >
    > 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.


    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.

    > The point is about your question, whether they would solve the
    > debate.


    It would be great if the "regulars" on that debate would "go at it" again
    in this new context. (Who needs Netflix!).

    > More on this at the end of my post.
    >
    >>>
    >>> 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.

    >>
    >> I think it would be elegant with language/compiler support. Certainly
    >> much more efficient.

    >
    > Language and compilers cannot give you something that you CPU can't.


    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!).

    >
    > Granted, you might very well have a CPU that gives you them while your
    > compiler/language doesn't.


    Well you could have said that before I typed all of the just-above!

    >
    > My point is: why wait for the language and the compilers? Just create
    > your custom type and implement its internals in assembly.


    I'm slowly but surely approaching that level of capability, but I have
    higher-level coding to worry about right now.

    >
    > 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'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)?

    >
    >>>>>
    >>>>> 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.
    >>>>
    >>>> Now you sound like the C guys: "The language is no longer evolving,
    >>>> just being maintained."
    >>>
    >>> Not my purpose. Once more, my point is about contextualizing the
    >>> discussion.

    >>
    >> The OP was a continuation from another thread.

    >
    > I'm not a clairvoyant.


    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.

    >
    >> No one was being overly
    >> general especially since the area is well-understood and has many
    >> examples and implementations.

    >
    > Incorrect, because your original post was extremely generic.


    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).

    >
    >> Perhaps you are not aware that the
    >> territory is well-traveled and that's why you are "not getting" the
    >> thread?

    >
    > I think I'm getting it, but if you still believe I'm not, I will
    > eagerly read your explanations.


    Well you are now, that's good. I should go into teaching? ;)

    >
    > 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.


    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.

    >
    > You point out saturated integrals


    "integral" is calculus. The correct term is 'integer'.

    > asking whether they would solve the
    > debate - and to solve it, saturated integrals should replace the
    > existing ones.


    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(!)?

    >
    > You say that you see them as an addition, not as 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.

    > hence, in your opinion, they would not solve the debate.


    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?).

    >
    > Have I understood all of this correctly?


    Not hardly.

    > Now let's reset everything and speak about the metal.


    Great. I'm all ears. (But don't call me Dumbo! (the elephant)).

    >
    > We have signed and unsigned types. They both work perfectly


    Oh! Sounds like a skit. Shall we don costumes and have a gradeschool
    play? (Just kidding).

    > 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.


    Probably woefully inadequate, but go on.

    >
    > Now we have saturated integrals


    (for all watching, he meant INTEGERS).

    > which happen to address the problem


    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?

    > above by clipping all the operations at the boundaries - process that
    > still leads to wrong results, but not "that" bad.


    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.

    >
    > All right, now


    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.

    > 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?


    (integERs!). Of course not, but they are an addition, not a replacement.
    Pick your poison, and let freedom rain.

    >
    > - Assuming they will /not/ come for free, will they allow significant
    > optimizations that will outperform unsaturated integrals?


    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? ;)

    >
    > If any of those two questions can be definitely answered with a "yes",


    "You speak with strawman's tongue", comes to mind. Lighten up dude.

    > then I would say that saturated integrals


    My turn for a "question". What is a "saturated integral"?. (I couldn't
    resist, I'm laughing with you, not at you).

    > will solve the silly "signed
    > vs unsigned" debate just to, eventually, open the doors to the even
    > sillier "saturated signed vs saturated unsigned" debate.


    Sounds (to me) like you belong on the analysis team that figures this
    out, maybe. (OTOH, ... thought for another time, nevermind).

    >
    > 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.


    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

    Francesco S. Carta wrote:
    > Francesco S. Carta <>, on 13/09/2010 04:20:10,
    > wrote:
    > <huge self snip>
    >
    >> - 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 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.


    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

    On 12 sept, 22:10, "joe" <> wrote:
    > Öö Tiib wrote:


    > > 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.

    >
    > 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).


    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. joe <>, on 12/09/2010 22:55:38, wrote:

    > Francesco S. Carta wrote:
    >> joe<>, on 12/09/2010 13:57:49, wrote:
    >>
    >>> Francesco S. Carta wrote:
    >>>> joe<>, on 11/09/2010 22:36:14, wrote:
    >>>>
    >>>>> Francesco S. Carta wrote:
    >>>>>> joe<>, on 11/09/2010 18:54:46, wrote:
    >>>>>>
    >>>>>> [subject is: Do saturating integers solve the "signed vs.
    >>>>>> unsigned" debate?]
    >>>>>>> Do/would they?
    >>>>>>
    >>>>>> 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.
    >>>>>
    >>>>> 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... $$$).
    >>>>
    >>>> 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.
    >>>
    >>> That goes without saying and has been said and is constantly heard in
    >>> these newsgroups.

    >>
    >> It is constantly repeated because lot of people happen to be deaf on
    >> that ear.

    >
    > Or trying to tell you something? Who's deaf? Time will tell.


    Indeed. The problem being that I struggle to make my points as explicit
    as possible, while some others don't.

    >>
    >>>>
    >>>> 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.
    >>>
    >>> I view them as an ADDITION, not replacements.

    >>
    >> 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.

    >
    > 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.


    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.

    >> The point is about your question, whether they would solve the
    >> debate.

    >
    > It would be great if the "regulars" on that debate would "go at it" again
    > in this new context. (Who needs Netflix!).


    If that could help dropping the silly debate - not to jump into another
    silly one, though - that would be great indeed.

    >> More on this at the end of my post.
    >>
    >>>>
    >>>> 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.
    >>>
    >>> I think it would be elegant with language/compiler support. Certainly
    >>> much more efficient.

    >>
    >> Language and compilers cannot give you something that you CPU can't.

    >
    > 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.


    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.

    > 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!).
    >
    >>
    >> Granted, you might very well have a CPU that gives you them while your
    >> compiler/language doesn't.

    >
    > Well you could have said that before I typed all of the just-above!


    I did! Aren't you accustomed to thoroughly read a post before replying
    to it? :)

    >>
    >> My point is: why wait for the language and the compilers? Just create
    >> your custom type and implement its internals in assembly.

    >
    > I'm slowly but surely approaching that level of capability, but I have
    > higher-level coding to worry about right now.


    Fine for me.

    >>
    >> 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'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)?


    I have no idea.

    >>
    >>>>>>
    >>>>>> 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.
    >>>>>
    >>>>> Now you sound like the C guys: "The language is no longer evolving,
    >>>>> just being maintained."
    >>>>
    >>>> Not my purpose. Once more, my point is about contextualizing the
    >>>> discussion.
    >>>
    >>> The OP was a continuation from another thread.

    >>
    >> I'm not a clairvoyant.

    >
    > 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.
    >
    >>
    >>> No one was being overly
    >>> general especially since the area is well-understood and has many
    >>> examples and implementations.

    >>
    >> Incorrect, because your original post was extremely generic.

    >
    > 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, that explains your original post indeed. Besides: no, I have no
    particular problem in reading long posts as long as they are intelligible.

    >>
    >>> Perhaps you are not aware that the
    >>> territory is well-traveled and that's why you are "not getting" the
    >>> thread?

    >>
    >> I think I'm getting it, but if you still believe I'm not, I will
    >> eagerly read your explanations.

    >
    > 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.

    >>
    >> 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.

    >
    > 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.


    Fine, different points of view and different concerns. Notice, though,
    the difference between "solving the debate" and "change the landscape of
    the dialog".

    >>
    >> You point out saturated integrals

    >
    > "integral" is calculus. The correct term is 'integer'.


    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.

    >> asking whether they would solve the
    >> debate - and to solve it, saturated integrals should replace the
    >> existing ones.

    >
    > 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(!)?


    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.

    >>
    >> You say that you see them as an addition, not as 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 think my previous paragraph addresses the misunderstanding above.

    >> hence, in your opinion, they would not solve the debate.

    >
    > 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?).
    >
    >>
    >> Have I understood all of this correctly?

    >
    > Not hardly.


    Fine, modulo misunderstandings.

    >> Now let's reset everything and speak about the metal.

    >
    > Great. I'm all ears. (But don't call me Dumbo! (the elephant)).


    That was just to say that I wanted to put languages and compilers apart
    for those closing thoughts and questions of mine.

    >>
    >> We have signed and unsigned types. They both work perfectly

    >
    > Oh! Sounds like a skit. Shall we don costumes and have a gradeschool
    > play? (Just kidding).
    >
    >> 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.

    >
    > Probably woefully inadequate, but go on.


    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.

    >>
    >> Now we have saturated integrals

    >
    > (for all watching, he meant INTEGERS).


    _That_ is getting annoying.

    >> which happen to address the problem

    >
    > 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?
    >
    >> above by clipping all the operations at the boundaries - process that
    >> still leads to wrong results, but not "that" bad.

    >
    > Well no. Did you even read my other post where I gave the malloc example?


    Well yes, more on this right here below.

    > OK, nevermind, you're analyzing the signed/unsigned thing.


    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.

    > 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.


    Thank you :)

    >>
    >> All right, now

    >
    > 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.


    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)

    >> 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?

    >
    > (integERs!).


    And now that has become definitely annoying.

    > Of course not, but they are an addition, not a replacement.


    Already addressed that point.

    > Pick your poison, and let freedom rain.


    I second that as long as others' freedom isn't affected :)

    >>
    >> - Assuming they will /not/ come for free, will they allow significant
    >> optimizations that will outperform unsaturated integrals?

    >
    > 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.

    >>
    >> If any of those two questions can be definitely answered with a "yes",

    >
    > "You speak with strawman's tongue", comes to mind. Lighten up dude.


    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.

    >> then I would say that saturated integrals

    >
    > My turn for a "question". What is a "saturated integral"?. (I couldn't
    > resist, I'm laughing with you, not at you).


    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.

    >> will solve the silly "signed
    >> vs unsigned" debate just to, eventually, open the doors to the even
    >> sillier "saturated signed vs saturated unsigned" debate.

    >
    > Sounds (to me) like you belong on the analysis team that figures this
    > out, maybe. (OTOH, ... thought for another time, nevermind).


    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...

    >>
    >> 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.

    >
    > See, I kinda get that, and got that incling from your post throughout,
    > even though I don't know WTF you are talking about!


    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.

    --
    FSC - http://userscripts.org/scripts/show/59948
    http://fscode.altervista.org - http://sardinias.com
     
    Francesco S. Carta, Sep 13, 2010
    #18
  19. joe <>, on 12/09/2010 23:00:54, wrote:

    > Francesco S. Carta wrote:
    >> Francesco S. Carta<>, on 13/09/2010 04:20:10,
    >> wrote:
    >> <huge self snip>
    >>
    >>> - 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 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.

    >
    > Well I don't remember you interjecting your thoughts into the Godzilla
    > vs. Megalon event. Apparently an "armchair quarterback"?


    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.

    --
    FSC - http://userscripts.org/scripts/show/59948
    http://fscode.altervista.org - http://sardinias.com
     
    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.

    > ncesco S. Carta wrote:
    > joe <>, on 12/09/2010 22:55:38, wrote:
    >
    >> Francesco S. Carta wrote:
    >>> joe<>, on 12/09/2010 13:57:49, wrote:
    >>>
    >>>> Francesco S. Carta wrote:
    >>>>> joe<>, on 11/09/2010 22:36:14, wrote:
    >>>>>
    >>>>>> Francesco S. Carta wrote:
    >>>>>>> joe<>, on 11/09/2010 18:54:46, wrote:
    >>>>>>>
    >>>>>>> [subject is: Do saturating integers solve the "signed vs.
    >>>>>>> unsigned" debate?]
    >>>>>>>> Do/would they?
    >>>>>>>
    >>>>>>> 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.
    >>>>>>
    >>>>>> 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... $$$).
    >>>>>
    >>>>> 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.
    >>>>
    >>>> That goes without saying and has been said and is constantly heard
    >>>> in these newsgroups.
    >>>
    >>> It is constantly repeated because lot of people happen to be deaf on
    >>> that ear.

    >>
    >> Or trying to tell you something? Who's deaf? Time will tell.

    >
    > Indeed. The problem being that I struggle to make my points as
    > explicit as possible, while some others don't.
    >
    >>>
    >>>>>
    >>>>> 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.
    >>>>
    >>>> I view them as an ADDITION, not replacements.
    >>>
    >>> 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.

    >>
    >> 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.

    >
    > 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.
    >
    >>> The point is about your question, whether they would solve the
    >>> debate.

    >>
    >> It would be great if the "regulars" on that debate would "go at it"
    >> again in this new context. (Who needs Netflix!).

    >
    > If that could help dropping the silly debate - not to jump into
    > another silly one, though - that would be great indeed.
    >
    >>> More on this at the end of my post.
    >>>
    >>>>>
    >>>>> 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.
    >>>>
    >>>> I think it would be elegant with language/compiler support.
    >>>> Certainly much more efficient.
    >>>
    >>> Language and compilers cannot give you something that you CPU can't.

    >>
    >> 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.

    >
    > 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.
    >
    >> 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!).
    >>>
    >>> Granted, you might very well have a CPU that gives you them while
    >>> your compiler/language doesn't.

    >>
    >> Well you could have said that before I typed all of the just-above!

    >
    > I did! Aren't you accustomed to thoroughly read a post before replying
    > to it? :)
    >
    >>>
    >>> My point is: why wait for the language and the compilers? Just
    >>> create your custom type and implement its internals in assembly.

    >>
    >> I'm slowly but surely approaching that level of capability, but I
    >> have higher-level coding to worry about right now.

    >
    > Fine for me.
    >
    >>>
    >>> 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'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)?

    >
    > I have no idea.
    >
    >>>
    >>>>>>>
    >>>>>>> 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.
    >>>>>>
    >>>>>> Now you sound like the C guys: "The language is no longer
    >>>>>> evolving, just being maintained."
    >>>>>
    >>>>> Not my purpose. Once more, my point is about contextualizing the
    >>>>> discussion.
    >>>>
    >>>> The OP was a continuation from another thread.
    >>>
    >>> I'm not a clairvoyant.

    >>
    >> 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.
    >>>
    >>>> No one was being overly
    >>>> general especially since the area is well-understood and has many
    >>>> examples and implementations.
    >>>
    >>> Incorrect, because your original post was extremely generic.

    >>
    >> 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, that explains your original post indeed. Besides: no, I have no
    > particular problem in reading long posts as long as they are
    > intelligible.
    >>>
    >>>> Perhaps you are not aware that the
    >>>> territory is well-traveled and that's why you are "not getting" the
    >>>> thread?
    >>>
    >>> I think I'm getting it, but if you still believe I'm not, I will
    >>> eagerly read your explanations.

    >>
    >> 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.
    >
    >>>
    >>> 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.

    >>
    >> 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.

    >
    > Fine, different points of view and different concerns. Notice, though,
    > the difference between "solving the debate" and "change the landscape
    > of the dialog".
    >
    >>>
    >>> You point out saturated integrals

    >>
    >> "integral" is calculus. The correct term is 'integer'.

    >
    > 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.
    >>> asking whether they would solve the
    >>> debate - and to solve it, saturated integrals should replace the
    >>> existing ones.

    >>
    >> 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(!)?

    >
    > 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.
    >
    >>>
    >>> You say that you see them as an addition, not as 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 think my previous paragraph addresses the misunderstanding above.
    >
    >>> hence, in your opinion, they would not solve the debate.

    >>
    >> 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?).
    >>
    >>>
    >>> Have I understood all of this correctly?

    >>
    >> Not hardly.

    >
    > Fine, modulo misunderstandings.
    >
    >>> Now let's reset everything and speak about the metal.

    >>
    >> Great. I'm all ears. (But don't call me Dumbo! (the elephant)).

    >
    > That was just to say that I wanted to put languages and compilers
    > apart for those closing thoughts and questions of mine.
    >
    >>>
    >>> We have signed and unsigned types. They both work perfectly

    >>
    >> Oh! Sounds like a skit. Shall we don costumes and have a gradeschool
    >> play? (Just kidding).
    >>
    >>> 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.

    >>
    >> Probably woefully inadequate, but go on.

    >
    > 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.
    >
    >>>
    >>> Now we have saturated integrals

    >>
    >> (for all watching, he meant INTEGERS).

    >
    > _That_ is getting annoying.
    >
    >>> which happen to address the problem

    >>
    >> 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?
    >>> above by clipping all the operations at the boundaries - process
    >>> that still leads to wrong results, but not "that" bad.

    >>
    >> Well no. Did you even read my other post where I gave the malloc
    >> example?

    >
    > Well yes, more on this right here below.
    >
    >> OK, nevermind, you're analyzing the signed/unsigned thing.

    >
    > 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.
    >
    >> 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.

    >
    > Thank you :)
    >
    >>>
    >>> All right, now

    >>
    >> 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.

    >
    > 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)
    >
    >>> 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?

    >>
    >> (integERs!).

    >
    > And now that has become definitely annoying.
    >
    >> Of course not, but they are an addition, not a replacement.

    >
    > Already addressed that point.
    >
    >> Pick your poison, and let freedom rain.

    >
    > I second that as long as others' freedom isn't affected :)
    >
    >>>
    >>> - Assuming they will /not/ come for free, will they allow
    >>> significant optimizations that will outperform unsaturated
    >>> integrals?

    >>
    >> 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.
    >
    >>>
    >>> If any of those two questions can be definitely answered with a
    >>> "yes",

    >>
    >> "You speak with strawman's tongue", comes to mind. Lighten up dude.

    >
    > 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.
    >
    >>> then I would say that saturated integrals

    >>
    >> My turn for a "question". What is a "saturated integral"?. (I
    >> couldn't resist, I'm laughing with you, not at you).

    >
    > 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.
    >
    >>> will solve the silly "signed
    >>> vs unsigned" debate just to, eventually, open the doors to the even
    >>> sillier "saturated signed vs saturated unsigned" debate.

    >>
    >> Sounds (to me) like you belong on the analysis team that figures this
    >> out, maybe. (OTOH, ... thought for another time, nevermind).

    >
    > 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...
    >
    >>>
    >>> 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.

    >>
    >> See, I kinda get that, and got that incling from your post
    >> throughout, even though I don't know WTF you are talking about!

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

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. gcc 4 signed vs unsigned char

    , Jul 26, 2005, in forum: C Programming
    Replies:
    22
    Views:
    1,669
    Gordon Burditt
    Aug 1, 2005
  2. LuB

    signed vs unsigned

    LuB, Feb 21, 2006, in forum: C++
    Replies:
    26
    Views:
    1,197
    Bo Persson
    Feb 22, 2006
  3. Timothee Groleau

    comparison signed vs unsigned

    Timothee Groleau, May 6, 2006, in forum: C++
    Replies:
    18
    Views:
    802
    persenaama
    May 7, 2006
  4. ÃCø¯
    Replies:
    4
    Views:
    695
    ÃCø¯
    Jan 22, 2008
  5. nexes

    Solve a Debate

    nexes, Feb 15, 2008, in forum: Python
    Replies:
    25
    Views:
    639
Loading...

Share This Page