Michael,
"Now, for personal opinion, I would share a tremendous frustration that
programmers often don't think at all about these issues and thereby allow
their thinking to be shallow. My clearest example is code like "k=i+j" or
"k = i*j" both of which are common."
Are you shocked—shocked—to find that this is going on? :-)
Programming Pearls, Second Edition by Jon Bentley.
phrase = inputchars
for (wordsleft = 10000; wordsleft > 0; wordsleft--)
l = -1
u = nword
while l+1 != u
m = (l + u) / 2
if wordncmp(word[m], phrase) < 0
l = m
else
u = m
for (i = 0; wordncmp(phrase, word[u+i]) == 0; i++)
if rand() % (i+1) == 0
p = word[u+i]
phrase = skip(p, 1)
if strlen(skip(phrase, k-1)) == 0
break
print skip(phrase, k-1)
Check the list of acknowledgments for the second Edition. :-)
Extra, Extra - Read All About It: Nearly All Binary Searches and Mergesorts
are Broken
Joshua Bloch, Software Engineer
https://research.googleblog.com/2006/06/extra-extra-read-all-about-it-nearly.html
Peter
On Thursday, March 16, 2017 at 5:52:29 AM UTC-4, Michael Jones wrote:
>
> Yes, there are cases for integer domain wraparound just as there are cases
> for exception at the limits.
>
> The argument FOR is that "computers work that way." Since ENIAC, there
> have been overflow condition flags, but there have rarely been
> overflow/underflow panic traps. (Either no support, or support but
> universally disabled by high-level languages and their runtime
> infrastructure.) The defining characteristic of BCPL / B / C is that the
> machine virtualized by the language has the natural behaviors of the
> underlying hardware. (This both overstates and understates the 'FOR'
> argument--more below)
>
> The argument AGAINST is that mathematics does not work that way. Niklaus
> Wirth was a champion of this mindset and you'll see that PASCAL and later
> languages from him were more serious minded about the legitimacy of
> computing as a mathematical abstraction. (0 - 1 => some giant number is
> obviously illegitimate in this worldview.)
>
> Now, the FOR side has an interesting historical basis: very many
> algorithms expect faulty-style computer arithmetic for their operation.
> Imagine computing a hash code where multiplying, adding, or shifting a bt
> off the high or low end caused a panic on the scale of divide by zero.
> There are many tasks performed by computers where falling off the end, or
> wrapping around, are the most natural and only workable meaning (multiple
> precision arithmetic and CRC checksums as other examples).
>
> Wirth had some challenges with such things and resorted to awkward coding
> strategies in response. You can see other examples in Knuth's original
> Pascal TeX source code vs the prior SAIL version. On the other hand ,
> Wirth's languages were amenable to proof-style assertions about ranges and
> domains because violations were errors.
>
> So, there are reasons both ways and reasonable people can disagree. The
> balance of the programming craft has a bias toward wraparound. The balance
> of CPUs make that mode best supported in response.
>
> That's the story.
>
> Now, for personal opinion, I would share a tremendous frustration that
> programmers often don't think at all about these issues and thereby allow
> their thinking to be shallow. My clearest example is code like "k=i+j" or
> "k = i*j" both of which are common. Stop and ask yourself "how frequently
> is this successful?" that is, in what percentage of the possible I and J
> combinations is the result wrong?
>
> Think about it.
>
> Here is the answer: https://play.golang.org/p/xc8TdVBgmf Maybe you can
> feel my horror that something could be wrong in 49.8047 or 96.9971% of the
> cases and only "weirdos like me and Wirth" even see it as a topic worthy of
> thought. He took this as an argument AGAINST and fought the system. I'm
> cool with FOR, but I wish I had at least one language other than assembler
> that respected my desire to say what I want in all such cases: to exploit
> overflow/underflow flags when desired, to use multiple rounding modes in
> expressions, etc. The transistors are there. It is language designers who
> are the weak link in the chain.
>
> On Tue, Mar 14, 2017 at 6:48 AM, Eyal Posener <[email protected]
> <javascript:>> wrote:
>
>> I was thinking about the type safety of uint in go, and comparing it for
>> a similar problem.
>>
>> If I have this go code:
>>
>> var x uint
>> x--
>>
>> The value of x is then the maximal value of uint, which is probably not
>> what the gother wanted (I think, is there any particular use cases for that
>> that you know of?)
>>
>> So my question is: why does go allow that, and for example panics on
>> index out of range of an array? Doesn't it make sense that it also should
>> panic in this case?
>>
>> Cheers,
>> Eyal
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to [email protected] <javascript:>.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
> Michael T. Jones
> [email protected] <javascript:>
>
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
