Hi,

If I want to have arithmetic-overflow checking in all parts of an
application,
what is the most practical, simple, efficient way to achieve this?
Id like to clutter the code as little a possible...
Is there any way to instruct the JVM to include it?

rop rop <rop049@gmail.com> writes:
>If I want to have arithmetic-overflow checking in all parts of an
>application,
>what is the most practical, simple, efficient way to achieve this?
>Id like to clutter the code as little a possible...

  One could use a JVM-based language with operator overloading.

>Is there any way to instruct the JVM to include it?

  One also could write a bytecode-to-bytecode transformer
  that modifies arithmetic operations accordingly.

On 7/6/2011 8:35 AM, rop rop wrote:
> Hi,
>
> If I want to have arithmetic-overflow checking in all parts of an
> application,
> what is the most practical, simple, efficient way to achieve this?
> Id like to clutter the code as little a possible...
> Is there any way to instruct the JVM to include it?


Nope, can't be done.  And yes I've griped about this myself, so you're 
in good (well, average at least) company.

On 7/6/2011 8:35 AM, rop rop wrote:
> Hi,
>
> If I want to have arithmetic-overflow checking in all parts of an
> application,
> what is the most practical, simple, efficient way to achieve this?

Write the application in Ada.

Patricia

On Jul 6, 6:42=A0pm, markspace <-@.> wrote:
> On 7/6/2011 8:35 AM, rop rop wrote:
>
> > Hi,
>
> > If I want to have arithmetic-overflow checking in all parts of an
> > application,
> > what is the most practical, simple, efficient way to achieve this?
> > Id like to clutter the code as little a possible...
> > Is there any way to instruct the JVM to include it?
>
> Nope, can't be done. =A0And yes I've griped about this myself, so you're
> in good (well, average at least) company.

OK...
What about patching the JVM to add this (sadly missing) "feature"?
It is open-source, isnt it?

Nobody has done this already?
Doesnt seems like a terribly big project, once I can locate the right
place to do it...

Any license aspects to consider, if I do it myself?

On 7/6/2011 11:30 AM, stefan@nyniva.se wrote:

> Doesnt seems like a terribly big project, once I can locate the right
> place to do it...


lol.  Yeah right.

http://openjdk.java.net/

Good luck kid.

In article <015aeb15-57db-48ab-9cd4-
77f8448b632f@w24g2000yqw.googlegroups.com>, rop049@gmail.com says...
> 
> Hi,
> 
> If I want to have arithmetic-overflow checking in all parts of an
> application,
> what is the most practical, simple, efficient way to achieve this?
> Id like to clutter the code as little a possible...
> Is there any way to instruct the JVM to include it?

Not automagically, at least if you want to avoid building a sourcecode-
preprocessor or tool that instruments your bytecode at class loading 
time.

You could use your very own math-methods and discourage the use of the 
operators "+","-" throughout your code by convention.

public final class OverflowUtil{

 public static void passIntRangeCheck(final long x){
  if( x > Integer.MAX_VALUE)
   throw new ArithemticException("int overflow");
  if if( x < Integer.MIN_VALUE)
   throw new ArithemticException("int underflow");
 }

 public static void passLongRangeCheck(final BigInteger x){
  if( x.compareTo(BigInteger.valueOf(Long.MAX_VALUE)) > 0)
   throw new ArithemticException("long overflow");
  if( x.compareTo(BigInteger.valueOf(Long.MIN_VALUE)) < 0)
   throw new ArithemticException("long underflow");
 }

 //... same for byte and short
}


import static OverflowUtil.*;
public class OverFlowSafe{

 static int add(final int a, final int b){
  final long x = a+b;
  passIntRangeCheck(x);
  return (int)x;
 }

 static long add(final long a, final long b){
   final long x = BigInteger.valueOf(a).add(BigInteger.valueOf(b);
   passLongRangeCheck(x);
   return x.longValue();
 }

 //.... other operations..
}

To be used like:

void foo(){
  final int x = Integer.MAX_VALUE;
  final int y = 1L;
  final int sum = OverflowSafe.add(x,y);

  System.out.println(sum);
}

The code not tested and hacked in a hurry, varargs would probably be 
nicer. The upside to any instrumentation or preprocessing tool is that 
you can distinguish safe from unsafe code with a blink of an eye.

Kind regards,
Wanja

-- 
...Alesi's problem was that the back of the car was jumping up and down 
dangerously - and I can assure you from having been teammate to 
Jean Alesi and knowing what kind of cars that he can pull up with, 
when Jean Alesi says that a car is dangerous - it is. [Jonathan Palmer]

--- Posted via news://freenews.netfront.net/ - Complaints to news@netfront.net ---

In article <MPG.287ee3d2698d83599896a9@202.177.16.121>, 
brixomatic@yahoo.com says...

> You could use your very own math-methods and discourage the use of the 
> operators "+","-" throughout your code by convention.

...and the others of course.

Kind regards,
Wanja



-- 
...Alesi's problem was that the back of the car was jumping up and down 
dangerously - and I can assure you from having been teammate to 
Jean Alesi and knowing what kind of cars that he can pull up with, 
when Jean Alesi says that a car is dangerous - it is. [Jonathan Palmer]

--- Posted via news://freenews.netfront.net/ - Complaints to news@netfront.net ---

On Wed, 6 Jul 2011, Wanja Gayk wrote:

> In article <015aeb15-57db-48ab-9cd4-
> 77f8448b632f@w24g2000yqw.googlegroups.com>, rop049@gmail.com says...
>
>> If I want to have arithmetic-overflow checking in all parts of an 
>> application, what is the most practical, simple, efficient way to 
>> achieve this? Id like to clutter the code as little a possible... Is 
>> there any way to instruct the JVM to include it?
>
> Not automagically, at least if you want to avoid building a sourcecode- 
> preprocessor or tool that instruments your bytecode at class loading 
> time.

Actually, a load-time bytecode manipulator might be the most practical way 
to do this. Modding the JVM is a non-starter for a few reasons, using an 
alternative language is not even a solution, using a library or a set of 
functions by convention is error-prone, but a bytecode weaver (using the 
java.lang.instrument API, to be clear) could do the job, and would be a 
fairly focused way of doing it - after the fairly small amount of 
boilerplate, it would just be a matter of decoding all targeted bytecode 
and rewriting it to check for overflow.

I didn't say it would be easy, just focused.

tom

-- 
History, I believe, furnishes no example of a priest-ridden people
maintaining a free civil government. -- Thomas Jefferson

On Wed, 6 Jul 2011 08:35:01 -0700 (PDT), rop rop <rop049@gmail.com>
wrote, quoted or indirectly quoted someone who said :

>If I want to have arithmetic-overflow checking in all parts of an
>application,
>what is the most practical, simple, efficient way to achieve this?
>Id like to clutter the code as little a possible...
>Is there any way to instruct the JVM to include it?

the JVM does not detect it because most hardware does not. You pretty
well have to use long instead of int and mask off and check overflow.
-- 
Roedy Green Canadian Mind Products
http://mindprod.com
One thing I love about having a website, is that when I complain about
something, I only have to do it once. It saves me endless hours of grumbling.

On Wed, 6 Jul 2011 08:35:01 -0700 (PDT), rop rop <rop049@gmail.com>
wrote, quoted or indirectly quoted someone who said :

>If I want to have arithmetic-overflow checking in all parts of an
>application,
>what is the most practical, simple, efficient way to achieve this?
>Id like to clutter the code as little a possible...

If your hardware detects it, you could use some JNI and test the
status codes and return a object containing the result and overflow
info.  Slow though.
-- 
Roedy Green Canadian Mind Products
http://mindprod.com
One thing I love about having a website, is that when I complain about
something, I only have to do it once. It saves me endless hours of grumbling.

In article <2rydnez7l-H5BYnTnZ2dnUVZ_vGdnZ2d@earthlink.com>,
 Patricia Shanahan <pats@acm.org> wrote:

> On 7/6/2011 8:35 AM, rop rop wrote:
> >
> > If I want to have arithmetic-overflow checking in all parts of an 
> > application, what is the most practical, simple, efficient way to 
> > achieve this?
> 
> Write the application in Ada.

In one popular implementation, the -gnato compiler option enables 
numeric overflow checking:

<http://gcc.gnu.org/onlinedocs/gcc-4.6.1/gnat_ugn_unw/Switches-for-gcc.html#Switches-for-gcc>

The language defined attribute 'Machine_Overflows will indicate if 
checking is available for fixed or floating point types:

<http://www.adaic.org/resources/add_content/standards/05rm/html/RM-K.html>

JGNAT targets the JVM, but I haven't used it.

-- 
John B. Matthews
trashgod at gmail dot com
<http://sites.google.com/site/drjohnbmatthews>

On Jul 6, 11:32=A0pm, Tom Anderson <t...@urchin.earth.li> wrote:
> Modding the JVM is a non-starter for a few reasons...

Hi Tom,
Thanks for input.
Could you just elaborate on this, please... what is the main-problem
with actually patching the JVM?
Why is it so hard?
Without having looked into the source-code, this seems like the most
straight-forward and robust way to do it...
Is the code so hard to penetrate or what?

rop rop <rop049@gmail.com> writes:
>If I want to have arithmetic-overflow checking in all parts of an
>application,
>what is the most practical, simple, efficient way to achieve this?
>Id like to clutter the code as little a possible...

  Even if you would be willing to use method calls in your
  source code, arithmetic overflow still could happen in
  library methods called by you. So it would not be sufficient
  to adjust only the source code written by you.

  Otherwise, if for some reason this should be sufficient,
  there is a Java 1.6 grammar for AntLR:

http://www.antlr.org/grammar/list

  , so you could parse your source code with AntLR and this
  grammar, then transform all the operators to method calls
  (the precedence should already have been taken care of by
  the parser) and write out the result as source code again.

On 7/7/2011 3:30 AM, rop rop wrote:
> On Jul 6, 11:32 pm, Tom Anderson<t...@urchin.earth.li>  wrote:
>> Modding the JVM is a non-starter for a few reasons...
>
> Hi Tom,
> Thanks for input.
> Could you just elaborate on this, please... what is the main-problem
> with actually patching the JVM?
> Why is it so hard?
> Without having looked into the source-code, this seems like the most
> straight-forward and robust way to do it...
> Is the code so hard to penetrate or what?

     The first thing that comes to mind is altering a JVM so it does
not behave as described in the Java Virtual Machine Specification
means you no longer have a JVM.  Specifically, from section 2.4.2:
"The built-in integer operators do not indicate (positive or negative)
overflow in any way; they wrap around on overflow."  For good or for
ill, that's a requirement all JVM implementations must satisfy.

     But, okay, you start with a JVM and alter it to produce a "KWN"
that behaves just like a JVM except in this one regard.  Now a second
difficulty arises: You start running Java on the KWN, and almost at
once you get an arithmetic overflow exception.  Investigating, you
find that it occurred in a hashCode() method that's computing the
time-honored sum x0+p*(x1+p*(x2+...)) with the fields x0,x1,... and
a prime p.  The overflow is entirely benign, yet "Hello".hashCode()
stops your program in its tracks.  So now you need a way to distinguish
expected (benign) overflow from unanticipated (injurious) overflow --
which means you need to alter not only the JVM but also Java.  (Or maybe
you could do something with annotations; I'm not sure.)  But the main
point is that all existing Java code expects overflow to wrap around,
and lots of that code actually relies on wraparound.

     Finally, you've got definitional problems to sort out.  For
example, is there an overflow in `int value = (int)Long.LONG_MAX;'?
You need to put on your Language Legislator hat and think about it
before you can decide how your KWN should behave.

     Personally, I wish integer over- and under-flow would in fact
throw exceptions, and that the language had something like `unsigned'
to allow the programmer to suppress the exceptions when appropriate.
But that's a wish I don't expect to see fulfilled.

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

rop rop <rop049@gmail.com> writes:

> If I want to have arithmetic-overflow checking in all parts of an
> application,
> what is the most practical, simple, efficient way to achieve this?
> Id like to clutter the code as little a possible...

Without knowing anything about your application, I wonder if doing all
the arithmetics with the BigInteger class instead of the int or long
primitives would help. It shouldn't ever overflow according to the
javadocs.
Of course you may consider it not being practical and simple, and
at least changing all the primitive numbers would mean changes to the
code, but I haven't noticed any better suggestion so far.

-- 
Jukka Lahtinen

On Jul 7, 1:54=A0pm, Eric Sosman <esos...@ieee-dot-org.invalid> wrote:
> On 7/7/2011 3:30 AM, rop rop wrote:
>
> > On Jul 6, 11:32 pm, Tom Anderson<t...@urchin.earth.li> =A0wrote:
> >> Modding the JVM is a non-starter for a few reasons...
>
> > Hi Tom,
> > Thanks for input.
> > Could you just elaborate on this, please... what is the main-problem
> > with actually patching the JVM?
> > Why is it so hard?
> > Without having looked into the source-code, this seems like the most
> > straight-forward and robust way to do it...
> > Is the code so hard to penetrate or what?
>
> =A0 =A0 =A0The first thing that comes to mind is altering a JVM so it doe=
s
> not behave as described in the Java Virtual Machine Specification
> means you no longer have a JVM. =A0Specifically, from section 2.4.2:
> "The built-in integer operators do not indicate (positive or negative)
> overflow in any way; they wrap around on overflow." =A0For good or for
> ill, that's a requirement all JVM implementations must satisfy.
>
> =A0 =A0 =A0But, okay, you start with a JVM and alter it to produce a "KWN=
"
> that behaves just like a JVM except in this one regard. =A0Now a second
> difficulty arises: You start running Java on the KWN, and almost at
> once you get an arithmetic overflow exception. =A0Investigating, you
> find that it occurred in a hashCode() method that's computing the
> time-honored sum x0+p*(x1+p*(x2+...)) with the fields x0,x1,... and
> a prime p. =A0The overflow is entirely benign, yet "Hello".hashCode()
> stops your program in its tracks. =A0So now you need a way to distinguish
> expected (benign) overflow from unanticipated (injurious) overflow --
> which means you need to alter not only the JVM but also Java. =A0(Or mayb=
e
> you could do something with annotations; I'm not sure.) =A0But the main
> point is that all existing Java code expects overflow to wrap around,
> and lots of that code actually relies on wraparound.
>
> =A0 =A0 =A0Finally, you've got definitional problems to sort out. =A0For
> example, is there an overflow in `int value =3D (int)Long.LONG_MAX;'?
> You need to put on your Language Legislator hat and think about it
> before you can decide how your KWN should behave.
>
> =A0 =A0 =A0Personally, I wish integer over- and under-flow would in fact
> throw exceptions, and that the language had something like `unsigned'
> to allow the programmer to suppress the exceptions when appropriate.
> But that's a wish I don't expect to see fulfilled.
>
> --
> Eric Sosman
> esos...@ieee-dot-org.invalid

Thanks for clarification Eric -- besides no longer being a
"JVM" (which I am aware of and dont care abt here),
I now start to see the technical problems :)

So one would also need a way to specify what classes overflow-checking
should apply to,
either a class-annotation,
or perhaps a runtime-flag
   -Xcheckforoverflow.classes=3Dmy.firstpkg.*;my.secondpkg.*
or similar would be practical.

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--232016332-447867670-1310044908=:17342
Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8BIT

On Thu, 7 Jul 2011, rop rop wrote:

> On Jul 6, 11:32�pm, Tom Anderson <t...@urchin.earth.li> wrote:
>> Modding the JVM is a non-starter for a few reasons...
>
> Could you just elaborate on this, please... what is the main-problem 
> with actually patching the JVM? Why is it so hard?

It would involve modifying a bytecode interpreter and two just-in-time 
compilers, all three highly developed instances of their species, and all 
written in C++. How much do you know about interpreters and compilers, and 
how is your C++? I am a good Java programmer, but that task would be way 
beyond me.

> Without having looked into the source-code, this seems like the most
> straight-forward and robust way to do it...

Prefixing a statement about some source code with 'without having looked 
at the source-code' pretty much disqualifies it completely.

Tell you what: the source code to the x86 version of HotSpot is here:

http://hg.openjdk.java.net/jdk7/hotspot/hotspot/file/tip/src/cpu/x86/vm/

In particular, here's the table of assembly instructions used for each 
bytecode in the interpreter:

http://hg.openjdk.java.net/jdk7/hotspot/hotspot/file/tip/src/cpu/x86/vm/templateTable_x86_32.cpp

Have a look at that, and let me know how hard you think it would be to 
modify that to do overflow checking (and remember that you can't do it 
everywhere, because existing code is written to use overflow - you have to 
have some way of only doing it in specified bits of code).

tom

-- 
Links are content.
--232016332-447867670-1310044908=:17342--

On 7/6/11 10:16 AM, Patricia Shanahan wrote:
> On 7/6/2011 8:35 AM, rop rop wrote:
>> Hi,
>>
>> If I want to have arithmetic-overflow checking in all parts of an
>> application,
>> what is the most practical, simple, efficient way to achieve this?
>
> Write the application in Ada.

Or use C#, which has the same feature, but is a lot more like Java 
otherwise.

That said, I suspect Tom's guess is correct and a language-change just 
to achieve this goal isn't going to be the practical choice.

Pete

On 7/7/2011 7:11 AM, Peter Duniho wrote:
> On 7/6/11 10:16 AM, Patricia Shanahan wrote:
>> On 7/6/2011 8:35 AM, rop rop wrote:
>>> Hi,
>>>
>>> If I want to have arithmetic-overflow checking in all parts of an
>>> application,
>>> what is the most practical, simple, efficient way to achieve this?
>>
>> Write the application in Ada.
>
> Or use C#, which has the same feature, but is a lot more like Java
> otherwise.
>
> That said, I suspect Tom's guess is correct and a language-change just
> to achieve this goal isn't going to be the practical choice.

Like most design decisions, it is a trade-off. If Tom *needs* overflow
checking, the most practical, simple, efficient way to achieve it is to
use a language that is designed to support overflow checking.

If he merely *wants* overflow checking, the best choice may be to stick
to Java and drop general overflow checking. That does not prevent having
e.g. a BigInteger subclass that takes a range as a constructor parameter
and does overflow checking against that range.

I have not yet seen an option for getting general overflow checking in
Java, without getting false hits on code that depends on the JLS
specified arithmetic behavior, that is at all practical, simple, or
efficient.

Patricia

On 07/07/2011 13:54, Eric Sosman allegedly wrote:
> On 7/7/2011 3:30 AM, rop rop wrote:
>> On Jul 6, 11:32 pm, Tom Anderson<t...@urchin.earth.li>  wrote:
>>> Modding the JVM is a non-starter for a few reasons...
>>
>> Hi Tom,
>> Thanks for input.
>> Could you just elaborate on this, please... what is the main-problem
>> with actually patching the JVM?
>> Why is it so hard?
>> Without having looked into the source-code, this seems like the most
>> straight-forward and robust way to do it...
>> Is the code so hard to penetrate or what?
> 
>     The first thing that comes to mind is altering a JVM so it does
> not behave as described in the Java Virtual Machine Specification
> means you no longer have a JVM.  Specifically, from section 2.4.2:
> "The built-in integer operators do not indicate (positive or negative)
> overflow in any way; they wrap around on overflow."  For good or for
> ill, that's a requirement all JVM implementations must satisfy.
> 
>     But, okay, you start with a JVM and alter it to produce a "KWN"
> that behaves just like a JVM except in this one regard.  Now a second
> difficulty arises: You start running Java on the KWN, and almost at
> once you get an arithmetic overflow exception.  Investigating, you
> find that it occurred in a hashCode() method that's computing the
> time-honored sum x0+p*(x1+p*(x2+...)) with the fields x0,x1,... and
> a prime p.  The overflow is entirely benign, yet "Hello".hashCode()
> stops your program in its tracks.  So now you need a way to distinguish
> expected (benign) overflow from unanticipated (injurious) overflow --
> which means you need to alter not only the JVM but also Java.  (Or maybe
> you could do something with annotations; I'm not sure.)  But the main
> point is that all existing Java code expects overflow to wrap around,
> and lots of that code actually relies on wraparound.
> 
>     Finally, you've got definitional problems to sort out.  For
> example, is there an overflow in `int value = (int)Long.LONG_MAX;'?
> You need to put on your Language Legislator hat and think about it
> before you can decide how your KWN should behave.
> 
>     Personally, I wish integer over- and under-flow would in fact
> throw exceptions, and that the language had something like `unsigned'
> to allow the programmer to suppress the exceptions when appropriate.
> But that's a wish I don't expect to see fulfilled.
> 

Not to mention the mess if it's an app you plan to distribute.

-- 
DF.
Determinism trumps correctness.

On Wed, 06 Jul 2011 22:41:54 -0700, Roedy Green
<see_website@mindprod.com.invalid> wrote:

>On Wed, 6 Jul 2011 08:35:01 -0700 (PDT), rop rop <rop049@gmail.com>
>wrote, quoted or indirectly quoted someone who said :
>
>>If I want to have arithmetic-overflow checking in all parts of an
>>application,
>>what is the most practical, simple, efficient way to achieve this?
>>Id like to clutter the code as little a possible...
>>Is there any way to instruct the JVM to include it?
>
>the JVM does not detect it because most hardware does not. You pretty
>well have to use long instead of int and mask off and check overflow.

     Which hardware does not have overflow detection?

     x86 does have an overflow flag.

Sincerely,

Gene Wirchenko

On 7/7/2011 2:34 PM, Gene Wirchenko wrote:
> On Wed, 06 Jul 2011 22:41:54 -0700, Roedy Green
> <see_website@mindprod.com.invalid>  wrote:
>
>> On Wed, 6 Jul 2011 08:35:01 -0700 (PDT), rop rop<rop049@gmail.com>
>> wrote, quoted or indirectly quoted someone who said :
>>
>>> If I want to have arithmetic-overflow checking in all parts of an
>>> application,
>>> what is the most practical, simple, efficient way to achieve this?
>>> Id like to clutter the code as little a possible...
>>> Is there any way to instruct the JVM to include it?
>>
>> the JVM does not detect it because most hardware does not. You pretty
>> well have to use long instead of int and mask off and check overflow.
>
>       Which hardware does not have overflow detection?
>
>       x86 does have an overflow flag.

So far, every instruction set I have studied has included overflow
detection at the hardware level.

I think the problem is more a matter of software knowing when overflow
should and should not be treated as an error.

Patricia

On Thu, 07 Jul 2011 14:53:50 -0700, Patricia Shanahan <pats@acm.org>
wrote:

[snip]

>I think the problem is more a matter of software knowing when overflow
>should and should not be treated as an error.

     Exactly.  C does not do that sort of checking, and the meme has
spread widely.  I would much prefer to have things blow up when wrong
than not blow up.  It makes for smaller messes.

Sincerely,

Gene Wirchenko

On Jul 7, 5:12=A0pm, Gene Wirchenko <ge...@ocis.net> wrote:
> On Thu, 07 Jul 2011 14:53:50 -0700, Patricia Shanahan <p...@acm.org>
> wrote:
>
> [snip]
>
> >I think the problem is more a matter of software knowing when overflow
> >should and should not be treated as an error.
>
> =A0 =A0 =A0Exactly. =A0C does not do that sort of checking, and the meme =
has
> spread widely. =A0I would much prefer to have things blow up when wrong
> than not blow up. =A0It makes for smaller messes.
>

the problem with that statement is that it's not wrong for Java
primitive integer types to wrap around.

It is, in fact, wrong for them to throw an overflow exception, as many
have pointed out in this thread.

--
Lew

On 7/7/11 10:02 AM, Patricia Shanahan wrote:
> On 7/7/2011 7:11 AM, Peter Duniho wrote:
>> On 7/6/11 10:16 AM, Patricia Shanahan wrote:
>>> On 7/6/2011 8:35 AM, rop rop wrote:
>>>> Hi,
>>>>
>>>> If I want to have arithmetic-overflow checking in all parts of an
>>>> application,
>>>> what is the most practical, simple, efficient way to achieve this?
>>>
>>> Write the application in Ada.
>>
>> Or use C#, which has the same feature, but is a lot more like Java
>> otherwise.
>>
>> That said, I suspect Tom's guess is correct and a language-change just
>> to achieve this goal isn't going to be the practical choice.
>
> Like most design decisions, it is a trade-off. If Tom *needs* overflow
> checking, the most practical, simple, efficient way to achieve it is to
> use a language that is designed to support overflow checking.

To be clear, I don't think _Tom_ needs or doesn't need this.  He was 
simply replying to the OP.

> If he merely *wants* overflow checking, the best choice may be to stick
> to Java and drop general overflow checking. That does not prevent having
> e.g. a BigInteger subclass that takes a range as a constructor parameter
> and does overflow checking against that range.

I don't disagree with that.  In fact, I'm skeptical that in any program 
it really makes sense to apply overflow checking to _every_ computation, 
even not counting the issues that have already been pointed out wrt the 
JDK itself and other libraries which rely on the lack of it.  For 
example, does every integral "for" loop _really_ need the index 
increment operation to be checked for overflow?  Seems unlikely to me.

While the discussion has been interesting, I can't help but feel that 
the original question is fundamentally flawed.  The answers are mostly 
academic, as it's unlikely anyone really ought to be trying to approach 
the problem in this way in the first place.

> I have not yet seen an option for getting general overflow checking in
> Java, without getting false hits on code that depends on the JLS
> specified arithmetic behavior, that is at all practical, simple, or
> efficient.

Well, I think Tom's suggestion of some sort of automatic code-rewriter 
_could_ be the best solution in _certain_ scenarios.  Such an 
implementation could be applied selectively to specific code.

I would not worry about the "simple" or "efficient" criteria.  IMHO, if 
one is deciding to apply overflow checking to every computation, one has 
already abandoned the hope of efficiency.

And "simple" is relative; if the requirement for checking is absolute, 
no solution is going to pass the "simple" bar for all programs, 
especially non-trivial ones.  In a very large code base, where one 
literally wants to apply checking to all of that base, either a rewrite 
in another language or trying to track down every possible place where 
one can replace a built-in type with a custom overflow-checking type 
could very well be more costly and complex a solution as simply writing 
a generalized tool that inserts overflow checking everywhere as needed.

I'm not really that big a fan of code-rewriting, mind you.  Debugging 
can be hard enough without having to deal with live code that's 
completely different from the original source code, and of course bugs 
in the rewriter itself can manifest as strange, hard-to-debug problems 
in the rewritten program.

But when one is talking about relative cost of implementation, there may 
well be scenarios where code-rewriting has the lowest cost compared to 
other choices.  In terms of practicality, that would make it a win.

Frankly, as long as the discussion is purely hypothetical (as it is 
now), I don't see how anyone can claim with 100% certainty the broad 
superiority or inferiority of any given solution.  It's too dependent on 
the specifics of whatever real-world scenario is at hand.

Pete

On 7/7/2011 5:51 PM, Peter Duniho wrote:
....
> I would not worry about the "simple" or "efficient" criteria. IMHO, if
> one is deciding to apply overflow checking to every computation, one has
> already abandoned the hope of efficiency.

Not necessarily. I assumed a couple of decades ago that array index
checking would be impossibly inefficient, but it seems to work fine in
Java. I suspect that having integer range types would be a major help.
When I'm working out whether an int can overflow, I often think in terms
of the ranges of inputs to calculations. A compiler would be able to
tell that adding a digit to a digit always fits in the range [0,18].


> And "simple" is relative; if the requirement for checking is absolute,
> no solution is going to pass the "simple" bar for all programs,
> especially non-trivial ones. In a very large code base, where one
> literally wants to apply checking to all of that base, either a rewrite
> in another language or trying to track down every possible place where
> one can replace a built-in type with a custom overflow-checking type
> could very well be more costly and complex a solution as simply writing
> a generalized tool that inserts overflow checking everywhere as needed.

The problem is "as needed". How does an automated tool tell the
difference between code that depends on the standard arithmetic and code
for which overflow detection is appropriate?

Patricia

On 7/7/11 8:04 PM, Patricia Shanahan wrote:
> On 7/7/2011 5:51 PM, Peter Duniho wrote:
> ....
>> I would not worry about the "simple" or "efficient" criteria. IMHO, if
>> one is deciding to apply overflow checking to every computation, one has
>> already abandoned the hope of efficiency.
>
> Not necessarily. I assumed a couple of decades ago that array index
> checking would be impossibly inefficient, but it seems to work fine in
> Java.

The JIT compiler can in many cases remove bounds checking for arrays 
based on context.  I suppose it could do the same sort of thing for 
overflow checking, which I think is what you're describing in the rest 
of the paragraph? (here:

> I suspect that having integer range types would be a major help.
> When I'm working out whether an int can overflow, I often think in terms
> of the ranges of inputs to calculations. A compiler would be able to
> tell that adding a digit to a digit always fits in the range [0,18].

?)

>> And "simple" is relative; if the requirement for checking is absolute,
>> no solution is going to pass the "simple" bar for all programs,
>> especially non-trivial ones. In a very large code base, where one
>> literally wants to apply checking to all of that base, either a rewrite
>> in another language or trying to track down every possible place where
>> one can replace a built-in type with a custom overflow-checking type
>> could very well be more costly and complex a solution as simply writing
>> a generalized tool that inserts overflow checking everywhere as needed.
>
> The problem is "as needed". How does an automated tool tell the
> difference between code that depends on the standard arithmetic and code
> for which overflow detection is appropriate?

It would rely on the user.  It's only "automated" in the sense that it 
does the code rewriting automatically.  It would still at a minimum have 
to be told which packages to apply the processing to.

Pete

On 7/7/2011 8:51 PM, Peter Duniho wrote:
> [...]
> I would not worry about the "simple" or "efficient" criteria. IMHO, if
> one is deciding to apply overflow checking to every computation, one has
> already abandoned the hope of efficiency.

     I've used machines that raised overflow traps "for free," in
the sense that it was done by the hardware/firmware/microcode, just
like setting condition flags.

     Flipping the mode bit that enabled or disabled traps for integer
arithmetic was relatively expensive, so programs tended to set it
one way or the other during initialization and then just leave it
alone.  But it's not necessary to use a global bit to get this kind
of behavior: an instruction set might feature both an AddAndWrap and
an AddAndTrap instruction.  True, that's not entirely free -- you
pay for extra decoding logic in the instruction pipeline, for example.
But the inefficiencies don't rise to the "abandon hope" level, IMHO.

     Besides: What are the relative efficiencies of an error caught
and announced versus a wrong answer computed at great speed without
any indication that it's wrong?

     (The machines I speak of were from forty-odd years ago and might
be dismissed as ancientry, but their lineal descendants are still
being made and sold.  I don't know how today's editions deal with
overflow, but if you're curious you can write to the vendor.  Their
headquarters are in Armonk, NY.)

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

On 7/7/11 9:30 PM, Eric Sosman wrote:
> On 7/7/2011 8:51 PM, Peter Duniho wrote:
>> [...]
>> I would not worry about the "simple" or "efficient" criteria. IMHO, if
>> one is deciding to apply overflow checking to every computation, one has
>> already abandoned the hope of efficiency.
>
> I've used machines that raised overflow traps "for free," in
> the sense that it was done by the hardware/firmware/microcode, just
> like setting condition flags.
>
> Flipping the mode bit that enabled or disabled traps for integer
> arithmetic was relatively expensive, so programs tended to set it
> one way or the other during initialization and then just leave it
> alone. But it's not necessary to use a global bit to get this kind
> of behavior: an instruction set might feature both an AddAndWrap and
> an AddAndTrap instruction. True, that's not entirely free -- you
> pay for extra decoding logic in the instruction pipeline, for example.
> But the inefficiencies don't rise to the "abandon hope" level, IMHO.

AFAIK, mainstream hardware (e.g. x86-compatible) doesn't include special 
overflow-checking instructions as you're describing.  I agree it's 
theoretically possible, but without such instructions in actual 
hardware, one is left toggling global state around every place that 
involves a change in whether overflow is checked or not.

Maybe some of the other more common CPUs, such as PowerPC, SHx, ARM, 
etc. do include those instructions.  I don't know off the top of my 
head.  But targeting a specific CPU would still require JVM and/or 
bytecode support.

These are hypothetical solutions, even more hypothetical than the actual 
question.  :)

(In case it's not clear, I should emphasize that my comments are in the 
context of the stated question…that is, assuming Java as it is today, 
and potential solutions given the stated requirement).

> Besides: What are the relative efficiencies of an error caught
> and announced versus a wrong answer computed at great speed without
> any indication that it's wrong?

You'll get no argument from me there.  I'm a strong proponent of correct 
code over incorrect fast code, and even of correct, _maintainable_ code 
over correct fast code (at least prior to detailed performance analysis).

In fact, my main point was that given the stated requirement, worrying 
about efficiency becomes beside the point.  If you have a business need 
for having every computation checked for overflow, then you have that 
need, whether or not it can be done efficiently.  If one can find an 
efficient solution, great.  But I think given what the OP has to work 
with, that's not likely.  More important just to get _some_ working 
solution (assuming it's a real requirement…as I mentioned, I suspect 
it's not as hard-and-fast as the original question seems to imply).

Pete

On 7/8/2011 1:29 AM, Peter Duniho wrote:

> AFAIK, mainstream hardware (e.g. x86-compatible) doesn't include special
> overflow-checking instructions as you're describing. I agree it's

Er, x86 and i32/64 certainly does.  I just happen to be browsing their 
hardware architecture documents last weak.

Not a single instruction to AddWithTrap, but a it does have a global 
state register, and a test/branch instrution, so you just pair up an ADD 
followed by a JO (Jump if Overflow) and that's it.  Two easy 
instructions paired together, and it works the same for MUL and SUB too. 
  (DIV can't overflow; think about it).

On Thu, 07 Jul 2011 17:51:06 -0700, Peter Duniho
<NpOeStPeAdM@NnOwSlPiAnMk.com> wrote:

[snip]

>I would not worry about the "simple" or "efficient" criteria.  IMHO, if 
>one is deciding to apply overflow checking to every computation, one has 
>already abandoned the hope of efficiency.

     Not necessarily.  If a rocket ends up being destroyed as a
result, having the computing go a bit slower to save having to build
another rocket would have been more efficient.  Unfortunately, this is
not a made-up example.  See:
          http://en.wikipedia.org/wiki/Ariane_5_Flight_501
In the subsequent investigation, the cause of the problem was
recreated.

     Turn on those run-time checks unless speed *REALLY* is of
paramount importance.  It usually is not.

[snip]

Sincerely,

Gene Wirchenko

On Thu, 7 Jul 2011 17:29:42 -0700 (PDT), lewbloch <lewbloch@gmail.com>
wrote:

>On Jul 7, 5:12�pm, Gene Wirchenko <ge...@ocis.net> wrote:
>> On Thu, 07 Jul 2011 14:53:50 -0700, Patricia Shanahan <p...@acm.org>
>> wrote:
>>
>> [snip]
>>
>> >I think the problem is more a matter of software knowing when overflow
>> >should and should not be treated as an error.
>>
>> � � �Exactly. �C does not do that sort of checking, and the meme has
>> spread widely. �I would much prefer to have things blow up when wrong
>> than not blow up. �It makes for smaller messes.
>>
>
>the problem with that statement is that it's not wrong for Java
>primitive integer types to wrap around.

     Java is designed to behave that way.  That does not mean that it
is not wrong.

     A garrot is designed to be a murder weapon.  That it was designed
for that does not make any murder committed with a garrot any less
wrong.

>It is, in fact, wrong for them to throw an overflow exception, as many
>have pointed out in this thread.

     It is designed to behave like that.  That behaviour is often
wrong from the point of view of ensuring program correctness.

     C allows wraparound with unsigned (which I wish Java had)
integers.  An overflow with signed integers results in undefined
behaviour.  C's semantics are better than those of Java in this
regard.  They should be better: throw an error.

Sincerely,

Gene Wrichenko

On Jul 8, 10:27=A0am, Gene Wirchenko <ge...@ocis.net> wrote:
> On Thu, 7 Jul 2011 17:29:42 -0700 (PDT), lewbloch <lewbl...@gmail.com>
> wrote:
>
>
>
>
>
>
>
>
>
> >On Jul 7, 5:12=A0pm, Gene Wirchenko <ge...@ocis.net> wrote:
> >> On Thu, 07 Jul 2011 14:53:50 -0700, Patricia Shanahan <p...@acm.org>
> >> wrote:
>
> >> [snip]
>
> >> >I think the problem is more a matter of software knowing when overflo=
w
> >> >should and should not be treated as an error.
>
> >> =A0 =A0 =A0Exactly. =A0C does not do that sort of checking, and the me=
me has
> >> spread widely. =A0I would much prefer to have things blow up when wron=
g
> >> than not blow up. =A0It makes for smaller messes.
>
> >the problem with that statement is that it's not wrong for Java
> >primitive integer types to wrap around.
>
> =A0 =A0 =A0Java is designed to behave that way. =A0That does not mean tha=
t it
> is not wrong.
>

It doesn't mean that it is wrong.

In fact, it does mean that it's not wrong.  If you're working in Java,
to do differently from what the Java spec requires is wrong.

As others have pointed out, there's an awful lot of code that depends
on the documented, required behavior.  For that code, to have overflow
exceptions would be wrong, doubly so because it would violate the
rules under which the code was developed.

> =A0 =A0 =A0A garrot is designed to be a murder weapon. =A0That it was des=
igned
> for that does not make any murder committed with a garrot any less
> wrong.
>

A useless analogy that adds no insight to the question of overflow
exceptions.  There is no evidence that wrapping around overflow is
equivalent to a murder weapon other than your fanciful rhetoric.

> >It is, in fact, wrong for them to throw an overflow exception, as many
> >have pointed out in this thread.
>
> =A0 =A0 =A0It is designed to behave like that. =A0That behaviour is often
> wrong from the point of view of ensuring program correctness.
>

Much more often, in Java, the behavior is right from the point of view
of ensuring program correctness, because Java programs are written
with the required behavior in mind.

> =A0 =A0 =A0C allows wraparound with unsigned (which I wish Java had)
> integers. =A0An overflow with signed integers results in undefined
> behaviour. =A0C's semantics are better than those of Java in this
> regard. =A0They should be better: throw an error.
>

"should" is pretty useless here - Java should do what it's documented
to do.

There are programmatic workarounds for preventing wraparound, and no
doubt there are errors that arise from the lack of overflow exception
trapping, just as there would be errors possible from its presence.
You have a personal preference to trap overflow exceptions, which you
like to present as an absolute rule for all programmers.  that doesn't
make your personal preference better, just yours.  You've offered no
objective evidence that your preference would be better for anyone
besides yourself; others here have offered evidence that to change
Java's behavior would cause more errors than your idea would fix.

I fully support your right to have a personal preference.

--
Lew

On Jul 8, 2:29 am, lewbloch <lewbl...@gmail.com> wrote:
> >      Exactly.  C does not do that sort of checking, and the meme has
> > spread widely.  I would much prefer to have things blow up when wrong
> > than not blow up.  It makes for smaller messes.
>
> the problem with that statement is that it's not wrong for Java
> primitive integer types to wrap around.
>
> It is, in fact, wrong for them to throw an overflow exception, as many
> have pointed out in this thread.
>
> --
> Lew

Hi Lew,

Yes, I am sure we all know that it IS 100% per the Java-spec -- no
need to point out that...

That being said, I personally think it must be one of the most epic
design errors in software-history, to DELIBERATELY design a
programming-language this way.
To me its like... WHAT THE H*** WERE THEY THINKING? :)

I mean, it's fine if you have an OPTION for users to turn off overflow-
checking, for performance reasons, or whatever other reason someone
can dream up.

BUT, to make it so difficult for users that (as far as I have been
googling up) after 15+years of Java-evolution and refinement, still
NOBODY has came up with a simple and robust way of including such an
extremely basic "feature" for a software-language.

I am a big fan of Java and the "echo-system" around it and all the fun
we're having with it every day -- this one being the only BIG
EXCEPTION I can think of.
What I would hope for is that, still, at some point in the future,
there will actually be an OPTION in the JVM to turn on overflow-
checking.
That way, it can be adopted by users who really value robust and bug-
free software, without breaking backwards compatibility with existing
code.

Generally, as for performance, for the majority of typical industry-
apps today (web-app backed by a database) overflow-checking would have
completely negligible impact on performance.

In-memory-computations, today, typically has extremely little impact,
compared to database-accesses and sending data over network.

Only in number-crunching applications would it make any significant
difference.
(Incidentally, however, these are perhaps the ones where overflow-bugs
are the most likely to occur?)

In article <t0fe17do5p4qslksigd5fmgbsbg7l3hk9n@4ax.com>,
 Gene Wirchenko <genew@ocis.net> wrote:

> On Thu, 07 Jul 2011 17:51:06 -0700, Peter Duniho
> <NpOeStPeAdM@NnOwSlPiAnMk.com> wrote:
> 
> [snip]
> 
> >I would not worry about the "simple" or "efficient" criteria.  IMHO, 
> >if one is deciding to apply overflow checking to every computation, 
> >one has already abandoned the hope of efficiency.
> 
> Not necessarily.  If a rocket ends up being destroyed as a result, 
> having the computing go a bit slower to save having to build another 
> rocket would have been more efficient.  Unfortunately, this is not a 
> made-up example.  See:

> <http://en.wikipedia.org/wiki/Ariane_5_Flight_501>

> In the subsequent investigation, the cause of the problem was 
> recreated.
> 
> Turn on those run-time checks unless speed *REALLY* is of paramount 
> importance.  It usually is not.

The software was designed for one system but used in another system 
without adequate testing. In particular,

s) It would have been technically feasible to include almost the entire 
inertial reference system in the overall system simulations which were 
performed. For a number of reasons it was decided to use the simulated 
output of the inertial reference system, not the system itself or its 
detailed simulation. Had the system been included, the failure could 
have been detected.

The full report may be seen here:

<http://en.wikisource.org/wiki/Ariane_501_Inquiry_Board_report>

-- 
John B. Matthews
trashgod at gmail dot com
<http://sites.google.com/site/drjohnbmatthews>

On 7/8/2011 10:38 AM, markspace wrote:
> On 7/8/2011 1:29 AM, Peter Duniho wrote:
>
>> AFAIK, mainstream hardware (e.g. x86-compatible) doesn't include special
>> overflow-checking instructions as you're describing. I agree it's
>
> Er, x86 and i32/64 certainly does. I just happen to be browsing their
> hardware architecture documents last weak.
>
> Not a single instruction to AddWithTrap, but a it does have a global
> state register, and a test/branch instrution, so you just pair up an ADD
> followed by a JO (Jump if Overflow) and that's it. Two easy instructions
> paired together, and it works the same for MUL and SUB too. (DIV can't
> overflow; think about it).

     I Am Curious, Ultraviolet: Even for Integer.MIN_VALUE / -1?

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

On 7/8/11 7:38 AM, markspace wrote:
> On 7/8/2011 1:29 AM, Peter Duniho wrote:
>
>> AFAIK, mainstream hardware (e.g. x86-compatible) doesn't include special
>> overflow-checking instructions as you're describing. I agree it's
>
> Er, x86 and i32/64 certainly does. I just happen to be browsing their
> hardware architecture documents last weak.
>
> Not a single instruction to AddWithTrap, but a it does have a global
> state register, and a test/branch instrution, so you just pair up an ADD
> followed by a JO (Jump if Overflow) and that's it. Two easy instructions
> paired together, and it works the same for MUL and SUB too. (DIV can't
> overflow; think about it).

Go back and read what you're replying to.

The context is _specifically_ about "a single instruction to AddWithTrap".

x86 and lots of other hardware has the global state you're talking 
about.  But that's not what we're talking about.

Pete

On 7/8/2011 5:40 PM, Eric Sosman wrote:

>> Not a single instruction to AddWithTrap, but a it does have a global
>> state register, and a test/branch instrution, so you just pair up an ADD
>> followed by a JO (Jump if Overflow) and that's it. Two easy instructions
>> paired together, and it works the same for MUL and SUB too. (DIV can't
>> overflow; think about it).
>
> I Am Curious, Ultraviolet: Even for Integer.MIN_VALUE / -1?


Hmm, that was the description I read in the docs, or thought I read. 
I'm not really sure what the hardware will do in that case.  One way to 
find out would be to try it. :)

On 7/8/11 6:17 PM, markspace wrote:
> On 7/8/2011 5:40 PM, Eric Sosman wrote:
>
>>> Not a single instruction to AddWithTrap, but a it does have a global
>>> state register, and a test/branch instrution, so you just pair up an ADD
>>> followed by a JO (Jump if Overflow) and that's it. Two easy instructions
>>> paired together, and it works the same for MUL and SUB too. (DIV can't
>>> overflow; think about it).
>>
>> I Am Curious, Ultraviolet: Even for Integer.MIN_VALUE / -1?
>
>
> Hmm, that was the description I read in the docs, or thought I read. I'm
> not really sure what the hardware will do in that case. One way to find
> out would be to try it. :)

It had better trigger the same overflow as for other arithmetic 
operations.  And in C# (which is using the hardware features), it does:

   using System;

   namespace TestDivOverflow
   {
     class Program
     {
       static void Main(string[] args)
       {
         try
         {
           checked
           {
             int i = int.MinValue, j = i / -1;
           }
         }
         catch (Exception e)
         {
           Console.WriteLine(e.Message);
         }
       }
     }
   }


Output:

   Arithmetic operation resulted in an overflow.

Note that .NET is taking advantage of the hardware exception; it doesn't 
have to check the overflow bit, because the CPU generates an interrupt 
when the overflow occurs, when set up properly.  Here's the 
(unoptimized) assembly for the line of code in the "checked" block:

   00000041  mov         dword ptr [ebp-40h],80000000h
   00000048  mov         eax,dword ptr [ebp-40h]
   0000004b  or          ecx,0FFFFFFFFh
   0000004e  cdq
   0000004f  idiv        eax,ecx
   00000051  mov         dword ptr [ebp-44h],eax

Java _could_ do the same, but of course you'd have to, one way or the 
other, wrap "checked" areas of code with the toggle of the 
interrupt-trapping so that only those areas of code you want to generate 
the overflow check actually get it.

Pete

On 7/6/2011 8:35 AM, rop rop wrote:
> Hi,
>
> If I want to have arithmetic-overflow checking in all parts of an
> application,
> what is the most practical, simple, efficient way to achieve this?
> Id like to clutter the code as little a possible...
> Is there any way to instruct the JVM to include it?

What? You mean you guys do not have this in Java??

It is a compiler option in Ada GNAT/gcc compiler:

http://gcc.gnu.org/onlinedocs/gcc-4.3.5/gnat_ugn_unw/Run_002dTime-Checks.html

"`-gnato'
     Enables overflow checking for integer operations. This causes
GNAT to generate slower and larger executable programs by adding
code to check for overflow (resulting in raising Constraint_Error as
required by standard Ada semantics)."

This is something that should be there in Java.

--Nasser

On 7/8/2011 9:27 PM, Nasser M. Abbasi wrote:
> On 7/6/2011 8:35 AM, rop rop wrote:
>> Hi,
>>
>> If I want to have arithmetic-overflow checking in all parts of an
>> application,
>> what is the most practical, simple, efficient way to achieve this?
>> Id like to clutter the code as little a possible...
>> Is there any way to instruct the JVM to include it?
>
> What? You mean you guys do not have this in Java??
>
> It is a compiler option in Ada GNAT/gcc compiler:
>
> http://gcc.gnu.org/onlinedocs/gcc-4.3.5/gnat_ugn_unw/Run_002dTime-Checks.html
>
> "`-gnato'
>       Enables overflow checking for integer operations. This causes
> GNAT to generate slower and larger executable programs by adding
> code to check for overflow (resulting in raising Constraint_Error as
> required by standard Ada semantics)."
>
> This is something that should be there in Java.
>
> --Nasser

sorry, I see now this is mentioned in this thread. I replied before
reading the full thread.

--Nasser

On 7/8/2011 7:49 PM, Peter Duniho wrote:
> the CPU generates an interrupt
> when the overflow occurs,

Ah, ok that's why I read that the DIV instruction didn't affect the OV 
bit--it uses a different mechanism.  Thanks!

On Fri, 8 Jul 2011, Eric Sosman wrote:

> On 7/7/2011 8:51 PM, Peter Duniho wrote:
>
>> I would not worry about the "simple" or "efficient" criteria. IMHO, if
>> one is deciding to apply overflow checking to every computation, one has
>> already abandoned the hope of efficiency.
>
>    I've used machines that raised overflow traps "for free," in
> the sense that it was done by the hardware/firmware/microcode, just
> like setting condition flags.
>
>    Flipping the mode bit that enabled or disabled traps for integer
> arithmetic was relatively expensive, so programs tended to set it
> one way or the other during initialization and then just leave it
> alone.  But it's not necessary to use a global bit to get this kind
> of behavior: an instruction set might feature both an AddAndWrap and
> an AddAndTrap instruction.  True, that's not entirely free -- you
> pay for extra decoding logic in the instruction pipeline, for example.
> But the inefficiencies don't rise to the "abandon hope" level, IMHO.
>
>    Besides: What are the relative efficiencies of an error caught
> and announced versus a wrong answer computed at great speed without
> any indication that it's wrong?
>
>    (The machines I speak of were from forty-odd years ago and might be 
> dismissed as ancientry, but their lineal descendants are still being 
> made and sold.  I don't know how today's editions deal with overflow, 
> but if you're curious you can write to the vendor.  Their headquarters 
> are in Armonk, NY.)

In that case, i can tell you what they do: charge you extra for it.

tom

-- 
ONE IN EIGHT GO MAD

On Thu, 7 Jul 2011, Patricia Shanahan wrote:

> On 7/7/2011 5:51 PM, Peter Duniho wrote:
>
>> And "simple" is relative; if the requirement for checking is absolute, 
>> no solution is going to pass the "simple" bar for all programs, 
>> especially non-trivial ones. In a very large code base, where one 
>> literally wants to apply checking to all of that base, either a rewrite 
>> in another language or trying to track down every possible place where 
>> one can replace a built-in type with a custom overflow-checking type 
>> could very well be more costly and complex a solution as simply writing 
>> a generalized tool that inserts overflow checking everywhere as needed.
>
> The problem is "as needed". How does an automated tool tell the 
> difference between code that depends on the standard arithmetic and code 
> for which overflow detection is appropriate?

I'd been thinking it could be something like the presence of an 
@CheckForOverflow annotation on the method or class. To be clear, this 
would definitely be a feature that the user would have to request, not 
something that happened by surprise.

You do then have this question of whether code called from a 
@CheckForOverflow also gets checked for overflow (as with strictfp) or 
not. I think not, because existing code will not have been written with 
overflow checking in mind, so it can't be assumed that it will work with 
it on. This is a blow to reuse, but it's not the end of the world.

tom

-- 
ONE IN EIGHT GO MAD

On Jul 9, 11:31=A0am, Tom Anderson <t...@urchin.earth.li> wrote:
> You do then have this question of whether code called from a
> @CheckForOverflow also gets checked for overflow (as with strictfp) or
> not. I think not, because existing code will not have been written with
> overflow checking in mind, so it can't be assumed that it will work with
> it on. This is a blow to reuse, but it's not the end of the world.

I also think not, in the general case...
But you could also have an annotation argument, like

@CheckForOverflow(allTheWayDown=3Dtrue)
or
@CheckForOverflow(allTheWayDown=3Dfalse)

:)

rop rop <rop049@gmail.com> writes:
>what is the most practical, simple, efficient way to achieve this?

  Ok, so /given that Java has to be used/ it seems to be most
  practical now, to call methods for arithmetic operations,
  which include overflow checking. This looks ugly in the
  source code without operator overloading, but requires the
  least global preparation effort.

  Another approach would be to statically prove that, under
  the operating conditions given in a certain context,
  overflow cannot occur (unless it is intended to occur) and
  then write tests to verify this at run time.

  Possibly, the discussion could gain some more insights,
  if you could give a specific example of a program where such
  an overflow checking would be used.

  PS: We have a famous example of an overflow-related bug in 
  Java SE:

http://googleresearch.blogspot.com/2006/06/extra-extra-read-all-about-it-nearly.html

  . (Both an attempt to prove that an overflow cannot occur
  in this method or carefully written test cases should have
  revealed that there was a bug in this method.)

On 7/9/2011 5:58 AM, rop rop wrote:
> On Jul 9, 11:31 am, Tom Anderson<t...@urchin.earth.li>  wrote:
>> You do then have this question of whether code called from a
>> @CheckForOverflow also gets checked for overflow (as with strictfp) or
>> not. I think not, because existing code will not have been written with
>> overflow checking in mind, so it can't be assumed that it will work with
>> it on. This is a blow to reuse, but it's not the end of the world.
>
> I also think not, in the general case...
> But you could also have an annotation argument, like
>
> @CheckForOverflow(allTheWayDown=true)
> or
> @CheckForOverflow(allTheWayDown=false)

     I don't think the "true" variant would be workable, since it
pretty much forbids hashCode() calls.  It probably also forbids
loading any classes, so you'd need to ensure that everything "all
the way down" was pre-loaded; that's going to be extremely hard
with plug-in architectures.

     But if you're so interested in the topic, why don't you grab
the sources and go hack on them for a while?  I expect the account
of your experiences would be a lot more interesting than idle
speculation is.

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

Wed, 6 Jul 2011 22:28:50 +0200, /Tom Anderson/:

> using a library or a set of functions by convention is error-prone,

The set of library functions would just address the requirement of 
not cluttering the code.  The error-proneness is usually addressed 
by writing appropriate unit tests which verify the code is dealing 
with overflow situations in expected manner.

-- 
Stanimir

On 7/9/2011 2:58 AM, rop rop wrote:
> I also think not, in the general case...
> But you could also have an annotation argument, like
>
> @CheckForOverflow(allTheWayDown=true)
> or
> @CheckForOverflow(allTheWayDown=false)


I did a quick check of the C# variant when it was mentioned here, and 
this is how they do it:

   int result = checked( a + b - c );

In other words is a key word.  Since Java can't really do this easily, 
I'd be in favor of using an existing key word and extending it.  For 
example, the key word "try" can't ever appear currently as a class name 
or package name in any program, so we could do this:

   int result = try.checked( a + b - c );

Which at least makes sense to me as one reads the code;  i.e., it's 
literate programming.  One could, I suppose, also extend the syntax 
where an annotation can be used, but this might have side effects also. 
  For example, it might be hard to support these new user defined 
annotations in the general case.

"Nasser M. Abbasi" wrote:
> rop rop wrote:
>> If I want to have arithmetic-overflow checking in all parts of an
>> application,
>> what is the most practical, simple, efficient way to achieve this?
>> Id like to clutter the code as little a possible...
>> Is there any way to instruct the JVM to include it?
>

> What? You mean you guys do not have this in Java??
>
> It is a compiler option in Ada GNAT/gcc compiler:
>
> http://gcc.gnu.org/onlinedocs/gcc-4.3.5/gnat_ugn_unw/Run_002dTime-Che...
>
> "`-gnato'
> =A0 =A0 =A0Enables overflow checking for integer operations. This causes
> GNAT to generate slower and larger executable programs by adding
> code to check for overflow (resulting in raising Constraint_Error as
> required by standard Ada semantics)."
>
> This is something that should be there in Java.
>

Ada was mentioned upthread as a language with the feature.  Not only
we guys, but no one has this in Java, as the many posts upthread have
made quite clear.  In fact, the Java language specification
specifically excludes trapping overflow in integer operations.  As was
mentioned upthread by several folks.  Lots of posters have expressed
the opinion that the feature should be present in some form in Java.
The discussion has now progressed to the form such a feature could
take without breaking Java and all the Java programs out there.  Some
of the suggestions seem to be viable.

--
Lew

On 8 Jul., 05:04, Patricia Shanahan <p...@acm.org> wrote:
> On 7/7/2011 5:51 PM, Peter Duniho wrote:
> ...
>
> > I would not worry about the "simple" or "efficient" criteria. IMHO, if
> > one is deciding to apply overflow checking to every computation, one has
> > already abandoned the hope of efficiency.
>
> Not necessarily. I assumed a couple of decades ago that array index
> checking would be impossibly inefficient, but it seems to work fine in
> Java.

And in other languages, like Pascal, Ada and Seed7, as well.

> I suspect that having integer range types would be a major help.
> When I'm working out whether an int can overflow, I often think in terms
> of the ranges of inputs to calculations. A compiler would be able to
> tell that adding a digit to a digit always fits in the range [0,18].

I think there are two things:

  1. range checks (like value fits in [0,18]).
  2. check if an 32-bit (or 8-bit, 16-bit, 64-bit, ...)
     computation overflows.

In the 1. case a compiler could generate code that does
the computation and checks the range afterwards.
In the 2. case a computation could result in wrong data,
because the overflow was silently ignored. In this case
either some checks must be done before the computation or
the overfow condition is recognized during or after the
computation. In an ideal world the hardware would do this.

A CPU could (in theory) easily recognize the overflow
and generate an interrupt. This way normal computations
(without overflow) would have no extra cost. AFAIK
commonly used CPUs do not have this possibility. They
have some FLAG, which is set when an overflow occurred.
But there is no possibility to cause an interrupt, when
the overflow FLAG is set. So code, which checks for
overflow, must check this flag after every computation.
Needless to say: Normal computations (without overflow)
are slowed down by this checks.

Because of this slow down most compilers and virtual
machines (AFAIK inluding the JVM) have no overflow
checking.

In other words: A missing hardware feature:

  Trigger interupt when overflow flag is set.

Causes compilers and JVMs to omit overflow checks.


Greetings Thomas Mertes

--
Seed7 Homepage:  http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows.

In article <3797038f-22d1-40b2-8c12-60db5a0976b8@t5g2000yqj.googlegroups.com>,
 tm <thomas.mertes@gmx.at> wrote:

> On 8 Jul., 05:04, Patricia Shanahan <p...@acm.org> wrote:
> > On 7/7/2011 5:51 PM, Peter Duniho wrote:
> > ...
> >
> > > I would not worry about the "simple" or "efficient" criteria. IMHO, if
> > > one is deciding to apply overflow checking to every computation, one has
> > > already abandoned the hope of efficiency.
> >
> > Not necessarily. I assumed a couple of decades ago that array index
> > checking would be impossibly inefficient, but it seems to work fine in
> > Java.
> 
> And in other languages, like Pascal, Ada and Seed7, as well.

In C the array size is not part of the type or value, so there is nothing to 
check. Addressing an array outside its allocation is undefined in general, but 
an implementation can define it anyway.

>   2. check if an 32-bit (or 8-bit, 16-bit, 64-bit, ...)
>      computation overflows.

C integer arithmetic is always modulo M, for some large M (like 2**32 or 2**64). 
So the concept of overflow does not apply.

>   Trigger interupt when overflow flag is set.

Not all CPUs detect integer arithmetic overflow. Not all CPUs signal integer 
arithmetic problems.

-- 
I remember finding out about you,  |A free Thai dyed shirt in every box.
Everyday my mind is all around you,|      I'm whoever you want me to be.
Looking out from my lonely room    | Annoying Usenet one post at a time.
Day after day.                     |   At least I can stay in character.

China Blue Dolls wrote:
 
> In C the array size is not part of the type or value,
> so there is nothing to check.

In C, 
the size of an array is part of the type of the array.

-- 
pete

In article <4E19791F.3E45@mindspring.com>, pete <pfiland@mindspring.com> wrote:

> China Blue Dolls wrote:
>  
> > In C the array size is not part of the type or value,
> > so there is nothing to check.
> 
> In C, 
> the size of an array is part of the type of the array.

extern char s[];

-- 
I remember finding out about you,  |A free Thai dyed shirt in every box.
Everyday my mind is all around you,|      I'm whoever you want me to be.
Looking out from my lonely room    | Annoying Usenet one post at a time.
Day after day.                     |   At least I can stay in character.

On 10 Jul., 11:47, China Blue Dolls <chine.b...@yahoo.com> wrote:
> In article <3797038f-22d1-40b2-8c12-60db5a097...@t5g2000yqj.googlegroups.=
com>,
>
> =A0tm <thomas.mer...@gmx.at> wrote:
> > On 8 Jul., 05:04, Patricia Shanahan <p...@acm.org> wrote:
> > > On 7/7/2011 5:51 PM, Peter Duniho wrote:
> > > ...
>
> > > > I would not worry about the "simple" or "efficient" criteria. IMHO,=
 if
> > > > one is deciding to apply overflow checking to every computation, on=
e has
> > > > already abandoned the hope of efficiency.
>
> > > Not necessarily. I assumed a couple of decades ago that array index
> > > checking would be impossibly inefficient, but it seems to work fine i=
n
> > > Java.
>
> > =A0 2. check if an 32-bit (or 8-bit, 16-bit, 64-bit, ...)
> > =A0 =A0 =A0computation overflows.
>
> C integer arithmetic is always modulo M, for some large M (like 2**32 or =
2**64).
> So the concept of overflow does not apply.
>
> > =A0 Trigger interupt when overflow flag is set.
>
> Not all CPUs detect integer arithmetic overflow. Not all CPUs signal inte=
ger
> arithmetic problems.

And popular CPUs, which do detect integer overflow, do not
trigger an interupt. This makes zero overhead overflow
detection impossible.

So software suffers because hardware / CPU designers want
to save a transistor...


Greetings Thomas Mertes

--
Seed7 Homepage:  http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows.

On 7/10/2011 5:47 AM, China Blue Dolls wrote:
>
> In C the array size is not part of the type or value, so there is nothing to
> check.

     No; the size (element count) is part of an array's type.  Your
compiler will confirm this for you by issuing a diagnostic for

	char matrix[5][7];  /* five char[7] arrays */
	char (*nine)[9];    /* pointer to char[9] */
	nine = matrix;      /* point it at the first char[7] */

> C integer arithmetic is always modulo M, for some large M (like 2**32 or 2**64).
> So the concept of overflow does not apply.

     This is true only for `unsigned' integer arithmetic.  Signed
integer arithmetic is in fact vulnerable to overflow.

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

On Jul 10, 4:28=A0pm, Eric Sosman <esos...@ieee-dot-org.invalid> wrote:
>
> =A0 =A0 =A0This is true only for `unsigned' integer arithmetic. =A0Signed
> integer arithmetic is in fact vulnerable to overflow.
>
All arithmetic is vulnerable to overflow. The question is whether the
system reports and error or gives wrong results. Sometimes wrong
results are better than errors, for instance in video games, but only
rarely.
--
Learn all about MPI
Tutorial on my website: http://www.malcolmmclean.site11.com/www

On 08/07/2011 12:30 AM, Eric Sosman wrote:
> On 7/7/2011 8:51 PM, Peter Duniho wrote:
>> [...]
>> I would not worry about the "simple" or "efficient" criteria. IMHO, if
>> one is deciding to apply overflow checking to every computation, one has
>> already abandoned the hope of efficiency.
>
> I've used machines that raised overflow traps "for free,"
....
> (The machines I speak of were from forty-odd years ago

When microprocessors started to arrive on the scene, a lot of old-timey 
hardware folks said they'd forgotten 30+ years of hardware design. When 
operating systems for computers based on said processors came out, a lot 
of old-timey software folks said they'd forgotten 30+ years of operating 
system design.  We seem to still be suffering the consequences.

On Sun, 10 Jul 2011 01:47:25 -0700 (PDT), tm <thomas.mertes@gmx.at>
wrote:

>On 8 Jul., 05:04, Patricia Shanahan <p...@acm.org> wrote:
>> On 7/7/2011 5:51 PM, Peter Duniho wrote:
>> ...
>>
>> > I would not worry about the "simple" or "efficient" criteria. IMHO, if
>> > one is deciding to apply overflow checking to every computation, one has
>> > already abandoned the hope of efficiency.
>>
>> Not necessarily. I assumed a couple of decades ago that array index
>> checking would be impossibly inefficient, but it seems to work fine in
>> Java.
>
>And in other languages, like Pascal, Ada and Seed7, as well.


A good compiler can often limit the number of time array bounds checks
to much less than every access.  For example, a sequence of uses of
the same index value obvious only needs the index checked once, or a
loop with bounds that don't change during the loop can often move the
check ahead of the loop.


>> I suspect that having integer range types would be a major help.
>> When I'm working out whether an int can overflow, I often think in terms
>> of the ranges of inputs to calculations. A compiler would be able to
>> tell that adding a digit to a digit always fits in the range [0,18].
>
>I think there are two things:
>
>  1. range checks (like value fits in [0,18]).
>  2. check if an 32-bit (or 8-bit, 16-bit, 64-bit, ...)
>     computation overflows.
>
>In the 1. case a compiler could generate code that does
>the computation and checks the range afterwards.
>In the 2. case a computation could result in wrong data,
>because the overflow was silently ignored. In this case
>either some checks must be done before the computation or
>the overfow condition is recognized during or after the
>computation. In an ideal world the hardware would do this.
>
>A CPU could (in theory) easily recognize the overflow
>and generate an interrupt. This way normal computations
>(without overflow) would have no extra cost. AFAIK
>commonly used CPUs do not have this possibility. They
>have some FLAG, which is set when an overflow occurred.
>But there is no possibility to cause an interrupt, when
>the overflow FLAG is set. So code, which checks for
>overflow, must check this flag after every computation.
>Needless to say: Normal computations (without overflow)
>are slowed down by this checks.
>
>Because of this slow down most compilers and virtual
>machines (AFAIK inluding the JVM) have no overflow
>checking.
>
>In other words: A missing hardware feature:
>
>  Trigger interupt when overflow flag is set.
>
>Causes compilers and JVMs to omit overflow checks.


S/360 and its descendents have such a feature (for both binary and
decimal arithmetic), which can be enabled by applications by setting a
bit in the PSW.  Nobody uses it.  It doesn't do quite everything (for
example, the multiply instruction produces double width results, and
doesn't ever overflow, but you obviously have an issue if you're going
to store that result back in a single width variable).  It also messes
up enough code, that what you'd really want is a separate set of
instruction that did or didn't trap on overflow (S/360 already has a
number of separate signed and unsigned binary arithmetic instructions,
the unsigned ones don't trap on "overflow").

In a similar vein, SNaNs are only rarely actually set to trap, even
though a lot of hardware that support IEEE math does support doing
that.

On 07/10/2011 05:47 AM, China Blue Dolls wrote:
> In article<3797038f-22d1-40b2-8c12-60db5a0976b8@t5g2000yqj.googlegroups.com>,
>>    2. check if an 32-bit (or 8-bit, 16-bit, 64-bit, ...)
>>       computation overflows.
>
> C integer arithmetic is always modulo M, for some large M (like 2**32 or 2**64).
> So the concept of overflow does not apply.

That is only true for unsigned integers; signed integer overflow is 
undefined.

-- 
Beware of bugs in the above code; I have only proved it correct, not 
tried it. -- Donald E. Knuth

China Blue Dolls <chine.bleu@yahoo.com> writes:
> In article <4E19791F.3E45@mindspring.com>, pete <pfiland@mindspring.com> wrote:
> > China Blue Dolls wrote:
> >  
> > > In C the array size is not part of the type or value,
> > > so there is nothing to check.
> > 
> > In C, 
> > the size of an array is part of the type of the array.

One might even say that array types are characterized by their
element type and by the number of elements in the array.
 
> extern char s[];

That's not an array, that's a promise that somewhere else there's
an array.

Phil
-- 
"At least you know where you are with Microsoft."
"True. I just wish I'd brought a paddle." -- Matthew Vernon

On Sun, 10 Jul 2011 10:53:09 -0400, David Lamb wrote:

> On 08/07/2011 12:30 AM, Eric Sosman wrote:
>> On 7/7/2011 8:51 PM, Peter Duniho wrote:
>>> [...]
>>> I would not worry about the "simple" or "efficient" criteria. IMHO, if
>>> one is deciding to apply overflow checking to every computation, one
>>> has already abandoned the hope of efficiency.
>>
>> I've used machines that raised overflow traps "for free,"
> ...
>> (The machines I speak of were from forty-odd years ago
> 
> When microprocessors started to arrive on the scene, a lot of old-timey
> hardware folks said they'd forgotten 30+ years of hardware design. When
> operating systems for computers based on said processors came out, a lot
> of old-timey software folks said they'd forgotten 30+ years of operating
> system design.  We seem to still be suffering the consequences.

That happened not once, but twice.

The first great leap backward was the minicomputer era, when the likes of 
the PDP-8 arrived with a single user, single tasking OS reminiscent of 
early computers, except they generally had teletypes instead of banks of  
switches and flashing lights. By then the better mainframes were multi-
user, multitasking beasts.

Then the first microcomputers arrived in the mid/late '70s. By this time 
the better minis had multi-tasking operating systems, but micros had re-
implemented the earliest mini OSes - CP/M was near as dammit a copy of 
the old PDP-8 OS (RSTS?) from the late 60s - and the earliest micros even 
had switches and flashing lights (KIM-1, IMSAI 8080). By 1980 the minis 
were running UNIX but the latest and greatest micros had - drumroll - MS-
DOS!


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

On 7/10/2011 11:07 AM, Martin Gregorie wrote:
> On Sun, 10 Jul 2011 10:53:09 -0400, David Lamb wrote:
>
>> On 08/07/2011 12:30 AM, Eric Sosman wrote:
>>> On 7/7/2011 8:51 PM, Peter Duniho wrote:
>>>> [...]
>>>> I would not worry about the "simple" or "efficient" criteria. IMHO, if
>>>> one is deciding to apply overflow checking to every computation, one
>>>> has already abandoned the hope of efficiency.
>>>
>>> I've used machines that raised overflow traps "for free,"
>> ...
>>> (The machines I speak of were from forty-odd years ago
>>
>> When microprocessors started to arrive on the scene, a lot of old-timey
>> hardware folks said they'd forgotten 30+ years of hardware design. When
>> operating systems for computers based on said processors came out, a lot
>> of old-timey software folks said they'd forgotten 30+ years of operating
>> system design.  We seem to still be suffering the consequences.
>
> That happened not once, but twice.
>
> The first great leap backward was the minicomputer era, when the likes of
> the PDP-8 arrived with a single user, single tasking OS reminiscent of
> early computers, except they generally had teletypes instead of banks of
> switches and flashing lights. By then the better mainframes were multi-
> user, multitasking beasts.
>
> Then the first microcomputers arrived in the mid/late '70s. By this time
> the better minis had multi-tasking operating systems, but micros had re-
> implemented the earliest mini OSes - CP/M was near as dammit a copy of
> the old PDP-8 OS (RSTS?) from the late 60s - and the earliest micros even
> had switches and flashing lights (KIM-1, IMSAI 8080). By 1980 the minis
> were running UNIX but the latest and greatest micros had - drumroll - MS-
> DOS!
>
>

Only twice? Aren't you forgetting "smart" phones. One of the great
advances in Android is (Drum roll!) multitasking!!!

Patricia

On Sun, 10 Jul 2011 11:29:39 -0700, Patricia Shanahan wrote:

> On 7/10/2011 11:07 AM, Martin Gregorie wrote:
>> On Sun, 10 Jul 2011 10:53:09 -0400, David Lamb wrote:
>>
>>> On 08/07/2011 12:30 AM, Eric Sosman wrote:
>>>> On 7/7/2011 8:51 PM, Peter Duniho wrote:
>>>>> [...]
>>>>> I would not worry about the "simple" or "efficient" criteria. IMHO,
>>>>> if one is deciding to apply overflow checking to every computation,
>>>>> one has already abandoned the hope of efficiency.
>>>>
>>>> I've used machines that raised overflow traps "for free,"
>>> ...
>>>> (The machines I speak of were from forty-odd years ago
>>>
>>> When microprocessors started to arrive on the scene, a lot of
>>> old-timey hardware folks said they'd forgotten 30+ years of hardware
>>> design. When operating systems for computers based on said processors
>>> came out, a lot of old-timey software folks said they'd forgotten 30+
>>> years of operating system design.  We seem to still be suffering the
>>> consequences.
>>
>> That happened not once, but twice.
>>
>> The first great leap backward was the minicomputer era, when the likes
>> of the PDP-8 arrived with a single user, single tasking OS reminiscent
>> of early computers, except they generally had teletypes instead of
>> banks of switches and flashing lights. By then the better mainframes
>> were multi- user, multitasking beasts.
>>
>> Then the first microcomputers arrived in the mid/late '70s. By this
>> time the better minis had multi-tasking operating systems, but micros
>> had re- implemented the earliest mini OSes - CP/M was near as dammit a
>> copy of the old PDP-8 OS (RSTS?) from the late 60s - and the earliest
>> micros even had switches and flashing lights (KIM-1, IMSAI 8080). By
>> 1980 the minis were running UNIX but the latest and greatest micros had
>> - drumroll - MS- DOS!
>>
>>
>>
> Only twice? Aren't you forgetting "smart" phones. One of the great
> advances in Android is (Drum roll!) multitasking!!!
>
They don't count since, unlike minis and micros, their builders didn't 
retreat to the techno-stone age, ignore progress made to date, and build 
primitive OS by rubbing (metaphorical) sticks together.

AFAIK all smartphones started an a more advanced level because they 
inherited better operating systems. IIRC these all originated on 
electronic memo pads such as Psion, HP and Palm Pilot made, and were all 
a lot more advanced than the likes of RSTS, CP/M, Flex09, etc. Leastwise, 
I don't think you can consider Symbian and whatever MS was calling the 
iPAQ OS at that stage any more primitive than the contemporary versions 
of MacOS, OS/2 or even Windows, though admittedly they were rather behind 
UNIX and its distant relations such as OS-9/68K. 


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> On Jul 10, 4:28 pm, Eric Sosman <esos...@ieee-dot-org.invalid> wrote:
>>      This is true only for `unsigned' integer arithmetic.  Signed
>> integer arithmetic is in fact vulnerable to overflow.
>>
> All arithmetic is vulnerable to overflow. The question is whether the
> system reports and error or gives wrong results. Sometimes wrong
> results are better than errors, for instance in video games, but only
> rarely.

All arithmetic that's intended to model (a subset of) the real
numbers with the usual mathematical operations is vulnerable to
overflow.  (Even arbitrary-precision packages can run out of memory.)

But C unsigned arithmetic, for example *doesn't* model normal real
arithmetic; it models arithmetic modulo 2**N and is not vulnerable
to overflow.  (Wraparound is not overflow; it yields the correct
wrapped result.)

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

On 7/10/2011 11:29 AM, Patricia Shanahan wrote:

> On 7/10/2011 11:07 AM, Martin Gregorie wrote:
>> Then the first microcomputers arrived in the mid/late '70s. By this time
>> the better minis had multi-tasking operating systems, but micros had re-
>> implemented the earliest mini OSes - CP/M was near as dammit a copy of
>> the old PDP-8 OS (RSTS?) from the late 60s - and the earliest micros even
>> had switches and flashing lights (KIM-1, IMSAI 8080). By 1980 the minis
>> were running UNIX but the latest and greatest micros had - drumroll - MS-
>> DOS!

> Only twice? Aren't you forgetting "smart" phones. One of the great
> advances in Android is (Drum roll!) multitasking!!!


If you're counting smart phones and MS-DOS, then you have to count 
Apple's first MacOS, which used co-operative multi-tasking.  I.e., any 
error by any program in the system and the whole thing would just break. 
  This went on for nearly two decades iirc.

There's probably others we should count.  8-3 filenames, 
case-insensitive file systems, weird mapping schemes for disc usage 
based on a "maximum" storage size of say about 256kB (not kidding), 
Apple's "innovative" data/resource fork file-scheme--I won't call it a 
file-system--still causing pain to this day, and any other number of 
"quick" or "new" kludges based on the idea of limited resources or 
limited time to market.

All right up there with "saving" time or complexity not giving the user 
a choice of hardware detection for integer overflow *coughjava*.

China Blue Dolls wrote:
> 
> In article <4E19791F.3E45@mindspring.com>, pete <pfiland@mindspring.com> wrote:

> > In C,
> > the size of an array is part of the type of the array.
> 
> extern char s[];

That's called an "incomplete type".

-- 
pete

On Sun, 10 Jul 2011 01:47:25 -0700 (PDT), tm <thomas.mertes@gmx.at>
wrote:

[snip]

>In other words: A missing hardware feature:
>
>  Trigger interupt when overflow flag is set.
>
>Causes compilers and JVMs to omit overflow checks.

     No, it does not.  Coupled with the idea of speed at all costs,
yes.

     I think the safe option should be on by default.  If you really
need the speed, then you can make the decision to override.

     Most of the time, the speed is not required.  I will take
slightly slower, correct results over fast, possibly wrong results.

Sincerely,

Gene Wirchenko

On Fri, 08 Jul 2011 19:30:09 -0400, "John B. Matthews"
<nospam@nospam.invalid> wrote:

>In article <t0fe17do5p4qslksigd5fmgbsbg7l3hk9n@4ax.com>,
> Gene Wirchenko <genew@ocis.net> wrote:
>
>> On Thu, 07 Jul 2011 17:51:06 -0700, Peter Duniho
>> <NpOeStPeAdM@NnOwSlPiAnMk.com> wrote:
>> 
>> [snip]
>> 
>> >I would not worry about the "simple" or "efficient" criteria.  IMHO, 
>> >if one is deciding to apply overflow checking to every computation, 
>> >one has already abandoned the hope of efficiency.
>> 
>> Not necessarily.  If a rocket ends up being destroyed as a result, 
>> having the computing go a bit slower to save having to build another 
>> rocket would have been more efficient.  Unfortunately, this is not a 
>> made-up example.  See:
>
>> <http://en.wikipedia.org/wiki/Ariane_5_Flight_501>
>
>> In the subsequent investigation, the cause of the problem was 
>> recreated.
>> 
>> Turn on those run-time checks unless speed *REALLY* is of paramount 
>> importance.  It usually is not.
>
>The software was designed for one system but used in another system 
>without adequate testing. In particular,
>
>s) It would have been technically feasible to include almost the entire 
>inertial reference system in the overall system simulations which were 
>performed. For a number of reasons it was decided to use the simulated 
>output of the inertial reference system, not the system itself or its 
>detailed simulation. Had the system been included, the failure could 
>have been detected.

     And the subsystem that the error was in was neded for the Ariane
4 but not for the Ariane 5.  Software reuse ended up biting hard.

>The full report may be seen here:
>
><http://en.wikisource.org/wiki/Ariane_501_Inquiry_Board_report>

     I have read a lot about that incident, though not as much as
about the THERAC-25 fiasco.

Sincerely,

Gene Wirchenko

On Fri, 8 Jul 2011 15:34:58 -0700 (PDT), rop rop <rop049@gmail.com>
wrote:

[snip]

>Yes, I am sure we all know that it IS 100% per the Java-spec -- no
>need to point out that...

     And as if it excuses it.  There is a reason why we have specs. It
is to specify desired behaviour, not be a straitjacket forevermore.

>That being said, I personally think it must be one of the most epic
>design errors in software-history, to DELIBERATELY design a
>programming-language this way.
>To me its like... WHAT THE H*** WERE THEY THINKING? :)

     Exactly.

>I mean, it's fine if you have an OPTION for users to turn off overflow-
>checking, for performance reasons, or whatever other reason someone
>can dream up.
>
>BUT, to make it so difficult for users that (as far as I have been
>googling up) after 15+years of Java-evolution and refinement, still
>NOBODY has came up with a simple and robust way of including such an
>extremely basic "feature" for a software-language.
>
>I am a big fan of Java and the "echo-system" around it and all the fun
>we're having with it every day -- this one being the only BIG
>EXCEPTION I can think of.
>What I would hope for is that, still, at some point in the future,
>there will actually be an OPTION in the JVM to turn on overflow-
>checking.
>That way, it can be adopted by users who really value robust and bug-
>free software, without breaking backwards compatibility with existing
>code.

     I would rather have it the other way around.  Safety first.  Make
the option on by default.  If someone really needs the additional
speed and judges the risk is acceptable, then that person can flip the
switch and maybe get sued into the ground if he gets it wrong.

Sincerely,

Gene Wirchenko

On 7/11/2011 8:09 AM, Gene Wirchenko wrote:
>       I would rather have it the other way around.  Safety first.  Make
> the option on by default.  If someone really needs the additional
> speed and judges the risk is acceptable, then that person can flip the
> switch and maybe get sued into the ground if he gets it wrong.

The problem with arithmetic overflow is that it's not really adding any 
safety. Sure, having 2^30 + 2^30 be a value less than 0 is wrong, but 
often times the 2^30 value in the first place is just as wrong. Not to 
mention that sometimes people fake unsigned integer types, in which case 
2 - 1 is an invalid value--how is the compiler supposed to know that 
this value is really an unsigned value? Note that this would break, 
e.g., java.util.Arrays.binarySearch.

What you really need is checked ranges, not automatic overflow checking.

-- 
Beware of bugs in the above code; I have only proved it correct, not 
tried it. -- Donald E. Knuth

On Jul 11, 5:58=A0pm, Gene Wirchenko <ge...@ocis.net> wrote:
>
> =A0 =A0 =A0Most of the time, the speed is not required. =A0I will take
> slightly slower, correct results over fast, possibly wrong results.
>
The game keeps on changing.

For instance modern space invaders are slowed down by the need to
normalise their vectors for lighting. Most of the rest of the code is
either handled by special rasterisers, or is insignificant in the
larger scheme of things. However they used to crawl about the screen
unless you pulled all the layers of indirection and gift-wrapping and
bounds checking away.
--
Learn MPI (message passing interface).
On my website, http://www.malcolmmclean.site11.com/www

On Mon, 11 Jul 2011 10:30:26 -0700, Joshua Cranmer
<Pidgeot18@verizon.invalid> wrote:

>On 7/11/2011 8:09 AM, Gene Wirchenko wrote:
>>       I would rather have it the other way around.  Safety first.  Make
>> the option on by default.  If someone really needs the additional
>> speed and judges the risk is acceptable, then that person can flip the
>> switch and maybe get sued into the ground if he gets it wrong.
>
>The problem with arithmetic overflow is that it's not really adding any 
>safety. Sure, having 2^30 + 2^30 be a value less than 0 is wrong, but 
>often times the 2^30 value in the first place is just as wrong. Not to 
>mention that sometimes people fake unsigned integer types, in which case 
>2 - 1 is an invalid value--how is the compiler supposed to know that 
>this value is really an unsigned value? Note that this would break, 
>e.g., java.util.Arrays.binarySearch.
>
>What you really need is checked ranges, not automatic overflow checking.

     We need both.  Either one would catch the problem above, but some
situations are vulnerable to only one.

     Going off the end of a small array would be caught by bounds
checking and not overflow checking.

     Averaging a set of numbers with a sum too big would be caught by
overflow checking and not bounds checking.

Sincerely,

Gene Wirchenko

On 7/11/2011 2:43 PM, Gene Wirchenko wrote:
> On Mon, 11 Jul 2011 10:30:26 -0700, Joshua Cranmer
> <Pidgeot18@verizon.invalid>  wrote:
>       Averaging a set of numbers with a sum too big would be caught by
> overflow checking and not bounds checking.

What I advocated would basically be a "checked integer": every operation 
is guaranteed to have a result between [min, max]; if not, it throws an 
exception.

-- 
Beware of bugs in the above code; I have only proved it correct, not 
tried it. -- Donald E. Knuth

On 11 Jul., 16:58, Gene Wirchenko <ge...@ocis.net> wrote:
> On Sun, 10 Jul 2011 01:47:25 -0700 (PDT), tm <thomas.mer...@gmx.at>
> wrote:
>
> [snip]
>
> >In other words: A missing hardware feature:
>
> > =A0Trigger interupt when overflow flag is set.
>
> >Causes compilers and JVMs to omit overflow checks.
>
> =A0 =A0 =A0No, it does not. =A0Coupled with the idea of speed at all cost=
s,
> yes.
>
> =A0 =A0 =A0I think the safe option should be on by default. =A0If you rea=
lly
> need the speed, then you can make the decision to override.
>
> =A0 =A0 =A0Most of the time, the speed is not required. =A0I will take
> slightly slower, correct results over fast, possibly wrong results.

It is not always necessary to pay for correct results
with a slowdown.

Correct results can be computed without any slowdown,
when the CPU is able to trigger an overflow interupt.

A slowdown would only happen when an overflow occurs.
Computations without overflow would run at full speed.


Greetings Thomas Mertes

--
Seed7 Homepage:  http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows.

> All arithmetic is vulnerable to overflow. 

Unfortunately, for unsigned arithmetic, C blesses silent wraparound
and says it has to work "properly", with no trapping on wraparound.
A lot of code depends on this.  (A lot of code probably depends on
*signed* overflow not trapping, but that code is wrong per the C
standard.) For example, a lot of checksum and CRC calculations would
fail with overflow traps when the calculation result is perfectly
fine if C were redefined so that unsigned arithmetic is required
to cause overflow traps in response to wraparounds.  Another class
of properly-written (according to the C standard) code likely to
fail is multi-precision math routines that depend on unsigned
arithmetic not trapping.

> The question is whether the
> system reports and error or gives wrong results. 

Is anyone going to use signed arithmetic error trapping, assuming
it is available and fairly cheap, *BUT* it does not allow a signal
handler to meaningfully return and resume the code?  Also, your
signal handler would have to be extremely inappropriately chummy
with the implementation if it's going to try substituting 0 for the
result of a division if overflow occurs during calculation of the
denominator.  Having the signal handler disassemble the main program
to figure out where the result of the calculation that overflowed goes
is extremely messy, error-prone, and machine-dependent.

Unfortunatly, C specifies that longjmp from a signal handler is
undefined behavior, which rules out things like:

jmp_buf x;
void overflowsignalhandler(void)
{
	longjmp(x, 1);
}
	...
	sometypedef value;
	signal(SIGINTEGER_OVERFLOW, overflowsignalhandler);

	if (setjmp(x) == 0) {
		value = /* complicated messy calculation 
			which might overflow */ ;
	} else {
		value = /* some default */;
	}


> Sometimes wrong
> results are better than errors, for instance in video games, but only
> rarely.

Sometimes a "crash" (terminating the program for an error) is even
less desirable than proceeding with a wrong result, even if both
may cause fatalities.

In a fly-by-wire airplane, making the manual controls *and* automatic
pilot non-functional is worse than just about anything else, even
a nose-dive into the ground, since a pilot might recover from that.

In a nuclear reactor, just freezing is a lot worse than "scramming"
it, causing the control rods to fall back into the reactor, shutting
it down.  But the cooling system needs to continue running.

On the other side, note that if a program is not required to produce
a correct answer, it can be optimized to execute in 0 time and 0
bytes.

On 7/11/2011 5:54 PM, tm wrote:
>[...]
> Correct results can be computed without any slowdown,
> when the CPU is able to trigger an overflow interupt.
>
> A slowdown would only happen when an overflow occurs.
> Computations without overflow would run at full speed.

     Well, no.  At least, not in any trap-capable architecture I've
seen.  Three points:

     1) Even the non-trap isn't entirely free: There's some logic in
the execution pipeline that decides not to raise it.  The silicon
devoted to that logic might instead have been devoted to one more
slot in a CPU-internal cache or something, so its mere presence slows
down the CPU even if it's never exercised.

     2) In mode-bit styles, the maintenance of the mode bit carries
a cost.  You've got to set or clear it before some computation, and
restore it afterward, and the instructions to do so aren't free.  In
the machine I mentioned earlier, the mode bit was in a "Program Status
Word" that was mostly off-limits to user-level code; IIRC you had to
call an O/S service to fiddle with the bit.  (It's been a long time and
maybe I don't RC, but if there were special instructions to manipulate
the privilege-insensitive parts of the PSW, see point (3) below.)

     3) In ISA styles (different instructions to wrap or trap), you
double the "decode space" for the instructions of interest.  That is,
the arithmetic instructions need to devote a bit to wrap/trap, and the
bit therefore becomes unavailable for other purposes.  This means that
some otherwise desirable instructions will be absent from the ISA, and
that programs desiring those operations will perforce execute multiple
instructions instead of just one.

     These effects are all small (I think).  But in an environment where
a 3.63GHz part gets bragging rights over a mere 3.59GHz, I don't think
"full speed" is entirely accurate.  It's sort of like those car ads:
"Best highway mileage *in its class*."

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

"tm" <thomas.mertes@gmx.at> ha scritto nel messaggio 
news:3797038f-22d1-40b2-8c12-60db5a0976b8@t5g2000yqj.googlegroups.com...
> On 8 Jul., 05:04, Patricia Shanahan <p...@acm.org> wrote:
>> On 7/7/2011 5:51 PM, Peter Duniho wrote:
>> ...
>>
>> > I would not worry about the "simple" or "efficient" criteria. IMHO, if
>> > one is deciding to apply overflow checking to every computation, one has
>> > already abandoned the hope of efficiency.
>>
>> Not necessarily. I assumed a couple of decades ago that array index
>> checking would be impossibly inefficient, but it seems to work fine in
>> Java.
>
> And in other languages, like Pascal, Ada and Seed7, as well.
>
>> I suspect that having integer range types would be a major help.
>> When I'm working out whether an int can overflow, I often think in terms
>> of the ranges of inputs to calculations. A compiler would be able to
>> tell that adding a digit to a digit always fits in the range [0,18].
>
> I think there are two things:
>
>  1. range checks (like value fits in [0,18]).
>  2. check if an 32-bit (or 8-bit, 16-bit, 64-bit, ...)
>     computation overflows.

the carry flag for 2^n word is ok for detect overflow 

On 12 Jul., 09:05, "io_x" <a...@b.c.invalid> wrote:
> "tm" <thomas.mer...@gmx.at> ha scritto nel messaggionews:3797038f-22d1-40=
b2-8c12-60db5a0976b8@t5g2000yqj.googlegroups.com...
>
>
>
> > On 8 Jul., 05:04, Patricia Shanahan <p...@acm.org> wrote:
> >> On 7/7/2011 5:51 PM, Peter Duniho wrote:
> >> ...
>
> >> > I would not worry about the "simple" or "efficient" criteria. IMHO, =
if
> >> > one is deciding to apply overflow checking to every computation, one=
 has
> >> > already abandoned the hope of efficiency.
>
> >> Not necessarily. I assumed a couple of decades ago that array index
> >> checking would be impossibly inefficient, but it seems to work fine in
> >> Java.
>
> > And in other languages, like Pascal, Ada and Seed7, as well.
>
> >> I suspect that having integer range types would be a major help.
> >> When I'm working out whether an int can overflow, I often think in ter=
ms
> >> of the ranges of inputs to calculations. A compiler would be able to
> >> tell that adding a digit to a digit always fits in the range [0,18].
>
> > I think there are two things:
>
> > =A01. range checks (like value fits in [0,18]).
> > =A02. check if an 32-bit (or 8-bit, 16-bit, 64-bit, ...)
> > =A0 =A0 computation overflows.
>
> the carry flag for 2^n word is ok for detect overflow

Yes, but it must be checked after every operation.
A hardware that triggers an interrupt, would save this
extra checks.

Unchecked signed integer operations are used, because of
performance reasons. Many people don't care about correct
results, as long as they have maximum performance. With
hardware support there would be no performance loss. So
there would be no excuse to accept wrong results.


Greetings Thomas Mertes

--
Seed7 Homepage:  http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows.

"tm" <thomas.mertes@gmx.at> ha scritto nel messaggio 
news:e7b7711c-93d5-477e-a470-21386854ff6f@j15g2000yqf.googlegroups.com...
On 12 Jul., 09:05, "io_x" <a...@b.c.invalid> wrote:
> > I think there are two things:
>
> > 1. range checks (like value fits in [0,18]).
> > 2. check if an 32-bit (or 8-bit, 16-bit, 64-bit, ...)
> > computation overflows.
>
> the carry flag for 2^n word is ok for detect overflow

>Yes, but it must be checked after every operation.
>A hardware that triggers an interrupt, would save this
>extra checks.

#in how i see that
#i like extra checks
#if hardware 'triggers' an interrupt all you lost the prog
#or lost the control of the program; and this is not good.
#but the checks can be done one time for all, in the input
#data for the function for impose arg has to be in a
#numeric range good for not overflow

On Jul 12, 12:34=A0pm, "io_x" <a...@b.c.invalid> wrote:
>
> #but the checks can be done one time for all, in the input
> #data for the function for impose arg has to be in a
> #numeric range good for not overflow
>
It's too fiddly, at least in C. You can overflow check if you really
have to, but it's not a viable strategy to insert checking code for
every single arithmetical operation that could conceivably overflow.
You need a different language for that.
--
Check out MiniBasic
http://www.malcolmmclean.site11.com/www

"tm" <thomas.mertes@gmx.at> wrote in message
news:289ad570-65fc-49d8-9cc8-1f15d13ff3e3@gv8g2000vbb.googlegroups.com...

> And popular CPUs, which do detect integer overflow, do not
> trigger an interupt. This makes zero overhead overflow
> detection impossible.
>
> So software suffers because hardware / CPU designers want
> to save a transistor...

Even if zero-overhead detection was possible, it's difficult to know how to
make use of this in C. For example:

int a,b,c;

c=a+b;

The a+b overflows, but then what? You can't then magically switch over to:

long long int a,b,c;

Even /with/ the overhead, it's difficult to see what could follow such an
expression:

 if (overflow(c=a+b)) ...

In the context of C-based code for implementing auto-ranging, dynamic types
of /another language/, this might be workable, but still difficult to see
how it can be done with zero-overhead. But this is a limited application
(which I wouldn't even attempt in C because it's so fiddly).

Aborting a program is also a possibility, but this just helps in debugging,
and overheads are less relevant.

(There is a longer thread on this in comp.lang.misc: "Integer arithmetic" 
from around start of March 2011.)

-- 
Bartc 

On 12 Jul., 11:34, "io_x" <a...@b.c.invalid> wrote:
> "tm" <thomas.mer...@gmx.at> ha scritto nel messaggionews:e7b7711c-93d5-477e-a470-21386854ff6f@j15g2000yqf.googlegroups.com...
> On 12 Jul., 09:05, "io_x" <a...@b.c.invalid> wrote:
>
> > > I think there are two things:
>
> > > 1. range checks (like value fits in [0,18]).
> > > 2. check if an 32-bit (or 8-bit, 16-bit, 64-bit, ...)
> > > computation overflows.
>
> > the carry flag for 2^n word is ok for detect overflow
> >Yes, but it must be checked after every operation.
> >A hardware that triggers an interrupt, would save this
> >extra checks.
>
> #if hardware 'triggers' an interrupt all you lost the prog
> #or lost the control of the program; and this is not good.

Why should the control of the program be lost?
A hardware interrupt can cause an signal or an exception.
So the program can handle the signal or handle the exception.

On many CPUs a division by zero triggers also an interrupt.
Depending on the language a signal or an exception allows
the program to stay in control. Of cause such things are
done by the runtime library in cooperation with the OS.


Greetings Thomas Mertes

--
Seed7 Homepage:  http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows.

On 12 Jul., 12:33, "BartC" <b...@freeuk.com> wrote:
> "tm" <thomas.mer...@gmx.at> wrote in message
>
> news:289ad570-65fc-49d8-9cc8-1f15d13ff3e3@gv8g2000vbb.googlegroups.com...
>
> > And popular CPUs, which do detect integer overflow, do not
> > trigger an interupt. This makes zero overhead overflow
> > detection impossible.
>
> > So software suffers because hardware / CPU designers want
> > to save a transistor...
>
> Even if zero-overhead detection was possible, it's difficult to know how =
to
> make use of this in C. For example:
>
> int a,b,c;
>
> c=3Da+b;
>
> The a+b overflows, but then what? You can't then magically switch over to=
:
>
> long long int a,b,c;

No, when a+b overflows, there is a bug in the program.
The purpose of overflow detection is NOT support for
unlimited precision integers. When the programmer thinks,
that all his computations will fit in an int, he can use
it (for performance or other reasons). In this case
he probably wants to know when his approach was wrong.

Most programmers want correct results, or the
information that something went wrong. Reasons where
wrong results are acceptable should be left out from
this discussion.

> Even /with/ the overhead, it's difficult to see what could follow such an
> expression:
>
> =A0if (overflow(c=3Da+b)) ...

I dont think that checking every expression in your program
makes sense. The runtime library (maybe in cooperation with
the OS) should do the job.

Signals and exceptions are the right mechanism to notify
a program that an overflow occurred.

> In the context of C-based code for implementing auto-ranging, dynamic typ=
es
> of /another language/, ...

You seem to see overflow detection as a possibility to
support unlimited precision integers. But this is NOT
the main reason to use it. In C and other languages
integer values are used for two things:

  1. Integer arithmetic ( + - * / )
  2. Bit manipulation (shifts, masks, logical and, logical or)

Bit manipulation works best without overflow detection.
For this reason C supports unsigned int, where overflows
are silently ignored.

Integer arithmetic, where overflows are ignored, leads to
wrong results. So overflow detection makes much sense
for integer arithmetic. C leaves the overflow beviour of
signed integers unspecified. Unfortunately many other
languages followed this decision.

> this might be workable, but still difficult to see
> how it can be done with zero-overhead.

The hardware triggers an interrupt and the program
recieves a signal or an exception.

> But this is a limited application
> (which I wouldn't even attempt in C because it's so fiddly).

It is only fiddly when you intend to check every
expression in your program. When you use some
exception (or signal) handlers it is not fiddly.

> Aborting a program is also a possibility, but this just helps in debuggin=
g,
> and overheads are less relevant.

A program that fails to catch an exception (or signal)
is aborted.

> (There is a longer thread on this in comp.lang.misc: "Integer arithmetic"
> from around start of March 2011.)

Probably my arguments can also be found in this thread. :-)


Greetings Thomas Mertes

--
Seed7 Homepage:  http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows.

"tm" <thomas.mertes@gmx.at> ha scritto nel messaggio
news:e7b7711c-93d5-477e-a470-21386854ff6f@j15g2000yqf.googlegroups.com...
> > I think there are two things:
>
> > 1. range checks (like value fits in [0,18]).
> > 2. check if an 32-bit (or 8-bit, 16-bit, 64-bit, ...)
> > computation overflows.

there is anhother one, the one i think could be right

3. consider operation on varible saturantion

for example here unsigned are 32 bits range 0..0FFFFFFFFh
than consider to each operation overflow saturate its variable
for example

unsigned32bitsSpecial   a;

a=9; a+=0xFFFFFFFA;
; here 'a' has value 0FFFFFFFFh because += overflow 'a';
it is as double in the standard C that has +INF

so allowed range of not overflow 32Bit variable are
0..0xFFFFFFFE
varible in overflow or +INF is 0xFFFFFFFF

so if a=INF
if b,c,r,m are saturabile variables

b+=a, c-=a  r/=a  m*=a all overflow b,c,r,m
and at end
b==c==r==m==INF
etc etc

> the carry flag for 2^n word is ok for detect overflow

>Yes, but it must be checked after every operation.
>A hardware that triggers an interrupt, would save this
>extra checks.

>Unchecked signed integer operations

i refer only to unsigned, not negative number.

i never use it [saturate variables] i like carry flag
and check for overflow too

disclaimer: i can wrong on all this
i'm just an hobby programmer

> are used, because of
>performance reasons. Many people don't care about correct
>results, as long as they have maximum performance.

>With
>hardware support there would be no performance loss. So
>there would be no excuse to accept wrong results.


>Greetings Thomas Mertes

>--
>Seed7 Homepage:  http://seed7.sourceforge.net
>Seed7 - The extensible programming language: User defined statements
>and operators, abstract data types, templates without special
>syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows.

"tm" <thomas.mertes@gmx.at> wrote in message 
news:a642c317-92bf-47a3-995a-2839d17c98ba@cq10g2000vbb.googlegroups.com...
> On 12 Jul., 12:33, "BartC" <b...@freeuk.com> wrote:
>> "tm" <thomas.mer...@gmx.at> wrote in message
>>
>> news:289ad570-65fc-49d8-9cc8-1f15d13ff3e3@gv8g2000vbb.googlegroups.com...
>>
>> > And popular CPUs, which do detect integer overflow, do not
>> > trigger an interupt. This makes zero overhead overflow
>> > detection impossible.
>>
>> > So software suffers because hardware / CPU designers want
>> > to save a transistor...

>> int a,b,c;
>>
>> c=a+b;
>>
>> The a+b overflows, but then what? You can't then magically switch over 
>> to:
>>
>> long long int a,b,c;
>
> No, when a+b overflows, there is a bug in the program.
> The purpose of overflow detection is NOT support for
> unlimited precision integers. When the programmer thinks,
> that all his computations will fit in an int, he can use
> it (for performance or other reasons). In this case
> he probably wants to know when his approach was wrong.
>
> Most programmers want correct results, or the
> information that something went wrong. Reasons where
> wrong results are acceptable should be left out from
> this discussion.

OK, so it's for debugging purposes. In this case, any overhead (of extra 
instructions to check flags and interrupt or whatever) is less important, 
and can be (and needs to be) optional.

-- 
Bartc 

On 12 Jul., 13:33, "BartC" <b...@freeuk.com> wrote:
> "tm" <thomas.mer...@gmx.at> wrote in message
>
> news:a642c317-92bf-47a3-995a-2839d17c98ba@cq10g2000vbb.googlegroups.com...
>
>
>
> > On 12 Jul., 12:33, "BartC" <b...@freeuk.com> wrote:
> >> "tm" <thomas.mer...@gmx.at> wrote in message
>
> >>news:289ad570-65fc-49d8-9cc8-1f15d13ff3e3@gv8g2000vbb.googlegroups.com...
>
> >> > And popular CPUs, which do detect integer overflow, do not
> >> > trigger an interupt. This makes zero overhead overflow
> >> > detection impossible.
>
> >> > So software suffers because hardware / CPU designers want
> >> > to save a transistor...
> >> int a,b,c;
>
> >> c=a+b;
>
> >> The a+b overflows, but then what? You can't then magically switch over
> >> to:
>
> >> long long int a,b,c;
>
> > No, when a+b overflows, there is a bug in the program.
> > The purpose of overflow detection is NOT support for
> > unlimited precision integers. When the programmer thinks,
> > that all his computations will fit in an int, he can use
> > it (for performance or other reasons). In this case
> > he probably wants to know when his approach was wrong.
>
> > Most programmers want correct results, or the
> > information that something went wrong. Reasons where
> > wrong results are acceptable should be left out from
> > this discussion.
>
> OK, so it's for debugging purposes.

Not alone. Arithmetic overflow checking should be also
done in production. Like you want to know also when a
production system does division by zero, dereferences
NULL, accesses memory outside the process (SEGV),
accesses array elements outside of an array or does
other illegal things.

For that reason I am interested in hardware support to
do (near) zero overhead arithmetic overflow detection.

> In this case, any overhead (of extra
> instructions to check flags and interrupt or whatever) is less important,
> and can be (and needs to be) optional.

Sometimes extra instructions are necessary, to do
some checks. But, except for rare cases, reasonable
checks should be done in a production system also.

The philosophy: No checks in a production system should
be a thing of the past.


Greetings Thomas Mertes

--
Seed7 Homepage:  http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows.

On Jul 12, 2:17=A0pm, tm <thomas.mer...@gmx.at> wrote:
> On 12 Jul., 12:33, "BartC" <b...@freeuk.com> wrote:
>
> > The a+b overflows, but then what? You can't then magically switch over =
to:
>
> > long long int a,b,c;
>
> No, when a+b overflows, there is a bug in the program.
> The purpose of overflow detection is NOT support for
> unlimited precision integers. When the programmer thinks,
> that all his computations will fit in an int, he can use
> it (for performance or other reasons). In this case
> he probably wants to know when his approach was wrong.
>
The problem is that 32 bit ints are large enough to count most things,
but not all.

You can't give a different 32-bit integer to everyone in the world,
for example, nor to all the bytes of RAM you might reasonably have in
your desktop computer.

64 bit ints solve most of these problems, they can count the vast
majority of things we need to count.
--
The campaign  for 64-bit ints
Coming soon to http://www.malcolmmclean.site11.com/www

On 12/07/2011 5:34 AM, io_x wrote:
> "tm"<thomas.mertes@gmx.at>  ha scritto nel messaggio
>> Yes, but it must be checked after every operation.
>> A hardware that triggers an interrupt, would save this
>> extra checks.
>
> #in how i see that
> #i like extra checks
> #if hardware 'triggers' an interrupt all you lost the prog
> #or lost the control of the program; and this is not good.

I seem to recall at least one computer architecture where a hardware 
interrupt essentially simulated a procedure call (indirectly through a 
fixed address), so the location where the exception occurred would be 
known to the exception handler. Thus control could be returned to the 
point of exception if desired (which it usually wasn't -- some sort of 
stack unwinding was likely better).

"BartC" <bc@freeuk.com> writes:
>a+b overflows, but then what?

  This can only be answered given the requirements
  specification of a specific project.

On 7/12/2011 6:16 AM, Stefan Ram wrote:
> "BartC"<bc@freeuk.com>  writes:
>> a+b overflows, but then what?
>
>    This can only be answered given the requirements
>    specification of a specific project.


What I think he's saying is there's no way physically detect the 
overflow in a language like C which has no exceptions.  You'd have to at 
least introduce some sort of global flag.

   int c = a + b;
   if( GLOBAL_OVERFLOW_FLAG ) {
     printf( "bugger..." );
   }

markspace <-@.> writes:

> On 7/12/2011 6:16 AM, Stefan Ram wrote:
>> "BartC"<bc@freeuk.com>  writes:
>>> a+b overflows, but then what?
>>
>>    This can only be answered given the requirements
>>    specification of a specific project.
>
>
> What I think he's saying is there's no way physically detect the
> overflow in a language like C which has no exceptions.  You'd have to
> at least introduce some sort of global flag.
>
>   int c = a + b;
>   if( GLOBAL_OVERFLOW_FLAG ) {
>     printf( "bugger..." );
>   }

Well, yes there is.  For example on an addition, if both operands have
the same sign and the result is the other sign, you had an overflow.
Analogous conditions exist (which I don't remember off the top of my
head and am too lazy to look up) exist for subtraction and
multiplication.  Integer division can't overflow.

My reading of the question was "OK, you've detected an overflow.  Now
what do you do about it?" and the (correct) answer was, in essence,
"well, what do you *want* to do about it?"

On Tue, 12 Jul 2011 09:26:49 -0700, markspace wrote:

> On 7/12/2011 6:16 AM, Stefan Ram wrote:
>> "BartC"<bc@freeuk.com>  writes:
>>> a+b overflows, but then what?
>>
>>    This can only be answered given the requirements specification of a
>>    specific project.
> 
> 
> What I think he's saying is there's no way physically detect the
> overflow in a language like C which has no exceptions.  You'd have to at
> least introduce some sort of global flag.
> 
>    int c = a + b;
>    if( GLOBAL_OVERFLOW_FLAG ) {
>      printf( "bugger..." );
>    }

Interestingly, the much maligned COBOL has a built-in mitigation for 
overflow and a way of trapping it:

Mitigation: since you can specify the number of digits in a numeric data 
item (integer or fixed decimal), it follows that the programmer can 
control whether overflow can occur and, as the maximum size of a numeric 
field is 18 digits, the result field can almost alrays be made long 
enough.

Trapping: all computational verbs will accept the ON SIZE ERROR clause 
which, despite its name, traps almost all possible calculation errors 
including overflow, divide by zero, etc.:

ADD TRANSACTION-VALUE TO TOTAL-VALUE 
    ON SIZE ERROR PERFORM REPORT-CALCULATION-ERROR.

....and yeah, whoever it was who said Java was verbose has clearly never 
written COBOL!


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

On 12 Jul., 18:26, markspace <-@.> wrote:
> On 7/12/2011 6:16 AM, Stefan Ram wrote:
>
> > "BartC"<b...@freeuk.com> =A0writes:
> >> a+b overflows, but then what?
>
> > =A0 =A0This can only be answered given the requirements
> > =A0 =A0specification of a specific project.
>
> What I think he's saying is there's no way physically detect the
> overflow in a language like C which has no exceptions.

But there are signals, which can be used for that purpose.
Signals are also used for other exceptional things, like
a division by zero.

> You'd have to at
> least introduce some sort of global flag.
>
> =A0 =A0int c =3D a + b;
> =A0 =A0if( GLOBAL_OVERFLOW_FLAG ) {
> =A0 =A0 =A0printf( "bugger..." );
> =A0 =A0}

Checking a global flag is a bad idea, since it does not
allow zero overhead arithmethic overflow detection (by
CPUs which are able to trigger an interrupt on overflow).


Greetings Thomas Mertes

--
Seed7 Homepage:  http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows.

On 12 Jul., 14:25, Malcolm McLean <malcolm.mcle...@btinternet.com>
wrote:
> On Jul 12, 2:17=A0pm, tm <thomas.mer...@gmx.at> wrote:> On 12 Jul., 12:33=
, "BartC" <b...@freeuk.com> wrote:
>
> > > The a+b overflows, but then what? You can't then magically switch ove=
r to:
>
> > > long long int a,b,c;
>
> > No, when a+b overflows, there is a bug in the program.
> > The purpose of overflow detection is NOT support for
> > unlimited precision integers. When the programmer thinks,
> > that all his computations will fit in an int, he can use
> > it (for performance or other reasons). In this case
> > he probably wants to know when his approach was wrong.
>
> The problem is that 32 bit ints are large enough to count most things,
> but not all.
>
> You can't give a different 32-bit integer to everyone in the world,
> for example, nor to all the bytes of RAM you might reasonably have in
> your desktop computer.
>
> 64 bit ints solve most of these problems, they can count the vast
> majority of things we need to count.

When CPUs moved from 16 to 32 bit integers the argumentation
was similar.

Using 64 bit ints only shifts the problem, but does NOT
solve it. Only overflow detection and unlimited precision
integers can solve it.


Greetings Thomas Mertes

--
Seed7 Homepage:  http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows.

Joe Pfeiffer <pfeiffer@cs.nmsu.edu> writes:
> markspace <-@.> writes:
>> On 7/12/2011 6:16 AM, Stefan Ram wrote:
>>> "BartC"<bc@freeuk.com>  writes:
>>>> a+b overflows, but then what?
>>>
>>>    This can only be answered given the requirements
>>>    specification of a specific project.
>>
>> What I think he's saying is there's no way physically detect the
>> overflow in a language like C which has no exceptions.  You'd have to
>> at least introduce some sort of global flag.
>>
>>   int c = a + b;
>>   if( GLOBAL_OVERFLOW_FLAG ) {
>>     printf( "bugger..." );
>>   }
>
> Well, yes there is.  For example on an addition, if both operands have
> the same sign and the result is the other sign, you had an overflow.
> Analogous conditions exist (which I don't remember off the top of my
> head and am too lazy to look up) exist for subtraction and
> multiplication.  Integer division can't overflow.

On many systems, yes, you can detect signed overflow after the fact by
examining the values of the operands and the result.  But in C, the
behavior is undefined -- and even on systems that use 2's-complement, an
optimizing compiler can take advantage of that fact and generate code
based on the assumption that overflow never occurs.  For example, this:

    int x = INT_MAX;
    if (x + 1 < x) {
        fprintf(stderr, "Overflow!\n");
    }

can be optimized away  (For example, gcc does this at -O2 and above.)

And yes, integer division can overflow; consider INT_MIN / -1.

> My reading of the question was "OK, you've detected an overflow.  Now
> what do you do about it?" and the (correct) answer was, in essence,
> "well, what do you *want* to do about it?"

But detecting the overflow in the first place can be *very* tricky.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

"Malcolm McLean" <malcolm.mclean5@btinternet.com> wrote in message
news:d16ec56b-6e94-473d-80b4-b2ddfcf58850@r18g2000vbs.googlegroups.com...

> The problem is that 32 bit ints are large enough to count most things,
> but not all.
>
> You can't give a different 32-bit integer to everyone in the world,

Just give two each...

> for example, nor to all the bytes of RAM you might reasonably have in
> your desktop computer.

No, you need up to 40-bits, if there is really a need to address every byte
in each object, and in every task, uniquely.

> 64 bit ints solve most of these problems, they can count the vast
> majority of things we need to count.

When you start doing arithmetic requiring bigger numbers, then 64-bits won't
be enough either. If you're calculating factorials, it means you can go up
to 20! instead of 12! Big deal...

And if you're advocating always using 64-bits, whether it's needed or not, 
then you could be doubling or quadrupling memory needs, and bandwidth, 
unnecessarily. Especially on a machine with a natural word size of 32-bits.

-- 
Bartc 

Keith Thompson <kst-u@mib.org> writes:

> Joe Pfeiffer <pfeiffer@cs.nmsu.edu> writes:
>> markspace <-@.> writes:
>>> On 7/12/2011 6:16 AM, Stefan Ram wrote:
>>>> "BartC"<bc@freeuk.com>  writes:
>>>>> a+b overflows, but then what?
>>>>
>>>>    This can only be answered given the requirements
>>>>    specification of a specific project.
>>>
>>> What I think he's saying is there's no way physically detect the
>>> overflow in a language like C which has no exceptions.  You'd have to
>>> at least introduce some sort of global flag.
>>>
>>>   int c = a + b;
>>>   if( GLOBAL_OVERFLOW_FLAG ) {
>>>     printf( "bugger..." );
>>>   }
>>
>> Well, yes there is.  For example on an addition, if both operands have
>> the same sign and the result is the other sign, you had an overflow.
>> Analogous conditions exist (which I don't remember off the top of my
>> head and am too lazy to look up) exist for subtraction and
>> multiplication.  Integer division can't overflow.
>
> On many systems, yes, you can detect signed overflow after the fact by
> examining the values of the operands and the result.  But in C, the
> behavior is undefined -- and even on systems that use 2's-complement, an
> optimizing compiler can take advantage of that fact and generate code
> based on the assumption that overflow never occurs.  For example, this:
>
>     int x = INT_MAX;
>     if (x + 1 < x) {
>         fprintf(stderr, "Overflow!\n");
>     }
>
> can be optimized away  (For example, gcc does this at -O2 and above.)

True, but I was considering the likelier case of something more like

    y = x + 1;

    if ((x > 0) && (y < 0))
	printf("overflow\n");

Which strikes me as much less likely to be optimized away.

> And yes, integer division can overflow; consider INT_MIN / -1.

Drat.  I stand corrected.

>> My reading of the question was "OK, you've detected an overflow.  Now
>> what do you do about it?" and the (correct) answer was, in essence,
>> "well, what do you *want* to do about it?"
>
> But detecting the overflow in the first place can be *very* tricky.

Joe Pfeiffer <pfeiffer@cs.nmsu.edu> writes:
> Keith Thompson <kst-u@mib.org> writes:
[...]
>> On many systems, yes, you can detect signed overflow after the fact by
>> examining the values of the operands and the result.  But in C, the
>> behavior is undefined -- and even on systems that use 2's-complement, an
>> optimizing compiler can take advantage of that fact and generate code
>> based on the assumption that overflow never occurs.  For example, this:
>>
>>     int x = INT_MAX;
>>     if (x + 1 < x) {
>>         fprintf(stderr, "Overflow!\n");
>>     }
>>
>> can be optimized away  (For example, gcc does this at -O2 and above.)
>
> True, but I was considering the likelier case of something more like
>
>     y = x + 1;
>
>     if ((x > 0) && (y < 0))
> 	printf("overflow\n");
>
> Which strikes me as much less likely to be optimized away.

Perhaps -- but optimizing compilers can be very clever, often
cleverer than you expect them to be.  (Some years ago, a co-worker
was surprised to discover that a substantial chunk of code was
eliminated entirely, and assumed it was a compiler bug.  On further
investigation, she found that it was a perfectly legitimate
sequence of optimizations; the code didn't actually do anything,
but she didn't expect the optimizer to be clever enough to notice.
And she was working on the optimizer.)

Depending on the compiler *not noticing things* is not a good way to
detect overflows.

Here's a program based on your suggestion:

#include <stdio.h>
#include <time.h>
#include <limits.h>
int main(void)
{
    int x = time(NULL) < 0 ? 42 : INT_MAX;
    int y;

    y = x + 1;

    if ((x > 0) && (y < 0)) {
        printf("overflow\n");
    }
    else {
        printf("no overflow\n");
    }
    return 0;
}

When compiled with "gcc -O1", it prints "overflow".  With "gcc -O2", it
prints "no overflow".

[...]

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

You are correct, and I am surprised.  What surprises me even more is
that I'd tried almost the same test, using

int x = INT_MAX;

and saw the correct result.  After your followup, I looked at the
generated assembly code for both versions; it turned out that mine had
optimized away the 'if' and simply printed 'overflow'; yours had optimized
away the 'if' and simply printed 'no overflow'!

On Tue, 12 Jul 2011 10:21:44 -0700 (PDT)
tm <thomas.mertes@gmx.at> wrote:

> Using 64 bit ints only shifts the problem, but does NOT
> solve it. Only overflow detection and unlimited precision
> integers 

 and unlimited amounts of RAM

>can solve it.

On 12 Jul., 22:39, Thomas Boell <tbo...@domain.invalid> wrote:
> On Tue, 12 Jul 2011 10:21:44 -0700 (PDT)
>
> tm <thomas.mer...@gmx.at> wrote:
> > Using 64 bit ints only shifts the problem, but does NOT
> > solve it. Only overflow detection and unlimited precision
> > integers
>
> =A0and unlimited amounts of RAM

Libraries supporting unlimited precision integers usually
raise a MEMORY_EXCEPTION when there is not enough memory
to represent an integer. At least my bigInteger library
(see: http://seed7.sourceforge.net/libraries/bigint.htm)
works this way. :-)

> > can solve it.


Greetings Thomas Mertes

--
Seed7 Homepage:  http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows.

Joe Pfeiffer <pfeiffer@cs.nmsu.edu> writes:
> You are correct, and I am surprised.  What surprises me even more is
> that I'd tried almost the same test, using
>
> int x = INT_MAX;
>
> and saw the correct result.  After your followup, I looked at the
> generated assembly code for both versions; it turned out that mine had
> optimized away the 'if' and simply printed 'overflow'; yours had optimized
> away the 'if' and simply printed 'no overflow'!

Undefined behavior can be like that.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

tm <thomas.mertes@gmx.at> writes:
> On 12 Jul., 22:39, Thomas Boell <tbo...@domain.invalid> wrote:
>> On Tue, 12 Jul 2011 10:21:44 -0700 (PDT)
>>
>> tm <thomas.mer...@gmx.at> wrote:
>> > Using 64 bit ints only shifts the problem, but does NOT
>> > solve it. Only overflow detection and unlimited precision
>> > integers
>>
>>  and unlimited amounts of RAM
>
> Libraries supporting unlimited precision integers usually
> raise a MEMORY_EXCEPTION when there is not enough memory
> to represent an integer. At least my bigInteger library
> (see: http://seed7.sourceforge.net/libraries/bigint.htm)
> works this way. :-)

Or, if they're in C rather than C++, they either return a result
or set errno to some value that indicates they've run out of memory.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

On 7/12/2011 8:24 AM, tm wrote:
> [...]
> The philosophy: No checks in a production system should
> be a thing of the past.

     "Test what you fly, fly what you test."

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

On 7/12/2011 12:26 PM, markspace wrote:
> On 7/12/2011 6:16 AM, Stefan Ram wrote:
>> "BartC"<bc@freeuk.com> writes:
>>> a+b overflows, but then what?
>>
>> This can only be answered given the requirements
>> specification of a specific project.
>
>
> What I think he's saying is there's no way physically detect the
> overflow in a language like C which has no exceptions.

     C has something far more flexible than exceptions: It has
"undefined behavior."

     :-)

     This thread is dragging on in both comp.lang.java.programmer,
where it began, and in comp.lang.c, to which some doubtless well-
meaning but insufficiently wise person cross-posted it.  The two
languages are rather different (in Java, there *is* no integer
overflow in C's sense), and the thread has become at least half-
irrelevant to at least one of the two groups.

     Permit me to suggest that people who wish to discuss integer
overflow in C should delete "comp.lang.java.programmer" from their
replies, and likewise people who wish to discuss an alternate Java
that handles overflow differently should delete "comp.lang.c".  In
this as in many other matters, the two languages have very little
to do with each other.

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> 
> It's too fiddly, at least in C. You can overflow check if you really
> have to, but it's not a viable strategy to insert checking code for
> every single arithmetical operation that could conceivably overflow.
> You need a different language for that.

Well, it's pretty trivial to do overflow checking with a decent compiler.

See the '-ftrapv' option for GCC, for example.

-- 
						Greg A. Woods
						RoboHack

<woods@robohack.ca>     living on the edge      http://www.robohack.ca/

tm <thomas.mertes@gmx.at> writes:
> 
> Yes, but it must be checked after every operation.
> A hardware that triggers an interrupt, would save this
> extra checks.

I think you're assuming either the code is running nearly bare on the
hardware (in which case your program has its own ISR), or that your OS
has a very inexpensive way to deliver the ISR to a process.

As I mentioned in another post just now, a decent compiler can use
library routines for all arithmetic operations and thus allow all
operations to be checked for overflow algorithmically.  See GCC's
"-ftrapv" option, for example.

You may also be assuming that overflows aren't so common in C.  :-)

Try re-compiling your system's entire userland with "gcc -ftrapv" and
see how much of it still works without aborting.

-- 
						Greg A. Woods
						RoboHack

<woods@robohack.ca>     living on the edge      http://www.robohack.ca/

Keith Thompson <kst-u@mib.org> writes:
> 
> But detecting the overflow in the first place can be *very* tricky.

Assuming your code is too complex or performance sensitive to use a
compiler that can do the checking for you (e.g. maybe with Clang's
"-ftrapv" -- see my comments below), it's reasonlyb easy to reliably do
the checks yourself, assuming you understand your target platform.

Attached is some test code I wrote quite a long time ago for checking
compilers and such.  It uses techniques I found from various sources to
demonstrate the possibilities of reliable integer overflow and
underflow detection for addition and subtraction, respectively.

I think I've covered testing each technique for most of the corner &
edge cases you have to watch out for, but I can't be certain.

I just re-ran it with some newer versions of GCC though and I see that
'-ftrapv' doesn't seem to work at all any more.  They broke it bad, and
haven't got around to fixing it yet.  See the comments in the code below.

Half-hearted apologies to anyone stuck with an 80-column terminal.  Join
the modern age and get a wider screen!  :-)


						Greg A. Woods
						RoboHack

<woods@robohack.ca>     living on the edge      http://www.robohack.ca/

#include <limits.h>
#include <stdio.h>
#include <stdlib.h>
#include <time.h>

/*
 * NOTES about C implementations vs. integer overflow detection:
 *
 * GCC has '-ftrapv' which (in some versions) replaces integer arithmetic
 * operators with calls to libgcc wrapper functions which (assuming
 * two's-complement signed integer arithmetic implementstions) will do overflow
 * checks (usually post-condition wrap-around checks) and call abort() if
 * there's an overflow detected in the operation.
 *
 * Unfortunately using GCC-4.1.2's '-ftrapv' in combination with any
 * optimization (i.e. '-O1' or greater) then the compiler will apparently
 * generate code which will purposefuly optimize away the libgcc internal calls
 * for (at least) addition operations.  The tests below will still detect the
 * overflows at runtime, and we know these tests are never optimized away
 * because we check that they work correctly for known non-overflowing values.
 * This is a GCC bug.
 *
 * Even more recent versions of GCC suffer worse:
 *
 * '-ftrapv' has no affect on Mac OS X (10.6.8 w/ gcc 4.2.1) (not in manpage)
 *
 * '-ftrapv' has no affect on FreeBSD 8.x w/ gcc 4.2.1 either (is documented)
 *
 * And as of last check, it's still a noted, open, bug:
 *
 *	http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35412 
 *	
 * However some discussions on some GCC mailing lists suggest this is too
 * broken to fix as-is.  Back in 2008 it was suggested it be deprecated for 4.4
 * and re-implemented properly using GIMPLE, whatever that is.
 *
 * Some other work done on this issue:
 *
 *	http://repository.cmu.edu/cgi/viewcontent.cgi?article=1017&context=ece
 *
 * Clang does support '-ftrapv', and it works even with -O3.
 *
 * BTW, if you do use '-ftrapv' you could add a signal handler for SIGABRT, or
 * re-define the abort() function, and then get signalled/called for every test
 * where overflow/underflow is detected.
 *
 * Someday C may have "as-if infinitely ranging integers".....
 */

/*
 * WARNING:  when testing this kind of stuff one must be careful not to give
 * away the secret to the optimizer, else it's certain to just elide your code.
 * Here we either use a system call to make the compiler uncertain about what
 * value will be used, or (with the following #define) we enable input options
 * for the user to supply the values, giving our suggestion as a simplistic
 * automated Turing test to out-smart the compiler.
 */
#if 1
#define USE_TIME_TO_INIT	/* defined.... */
#endif

void	unsigned_int_add_ovf(unsigned int, unsigned int);
void	unsigned_int_sub_undf(unsigned int, unsigned int);
void	signed_int_add_ovf_1(signed int, signed int);
void	signed_int_add_ovf_2(signed int, signed int);
void	signed_int_add_ovf_3(signed int, signed int);
void	signed_int_add_ovf_mot(signed int, signed int);
void	signed_int_add_ovf_cert_2s(signed int, signed int);
void	signed_int_add_ovf_cert_any(signed int, signed int);
void	signed_int_sub_undf_3(signed int, signed int);
void	signed_int_sub_undf_mot(signed int, signed int);


int main(void);

int
main()
{
	unsigned int ufoo;
	unsigned int ubar;

	signed int foo;
	signed int bar;

	int high_int_bit = (1 << ((int) (sizeof(int) * CHAR_BIT) - 1));

	/*
	 * note: this entire "if" trivially gets optimized away with -O1
	 */
	if (high_int_bit != INT_MIN) {
		printf("*** high bit expression says INT_MIN is busted! (INT_MIN=0x%x)\n", INT_MIN);
	}

	printf("\nTesting unsigned integer OK....\n\n");

#ifdef USE_TIME_TO_INIT
	ufoo = 	(time((time_t) NULL) < 0) ? 42 : 1;
	ubar = 	(time((time_t) NULL) < 0) ? 42 : 1;
#else
	printf("Enter a 1: ");
	fscanf(stdin, "%u", &ufoo);
	printf("got %u\n\n", ufoo);

	printf("Enter a 1: ");
	fscanf(stdin, "%u", &ubar);
	printf("got %u\n\n", ubar);
#endif

	unsigned_int_add_ovf(ufoo, ubar); /* UINT_MAX + 1 */

#ifdef USE_TIME_TO_INIT
	ufoo = 	(time((time_t) NULL) < 0) ? 42 : (UINT_MAX - 1);
#else
	printf("Enter %d: ", (UINT_MAX - 1));
	fscanf(stdin, "%u", &ufoo);
	printf("got %u\n\n", ufoo);
#endif
	unsigned_int_add_ovf(ufoo, ubar); /* (UINT_MAX-1) + 1 */


	printf("\nTesting unsigned integer overflow detection....\n\n");


#ifdef USE_TIME_TO_INIT
	ufoo = 	(time((time_t) NULL) < 0) ? 42 : UINT_MAX;
	ubar = 	(time((time_t) NULL) < 0) ? 42 : 1;
#else
	printf("Enter %u: ", UINT_MAX);
	fscanf(stdin, "%u", &ufoo);
	printf("got %u\n\n", ufoo);

	printf("Enter a 1: ");
	fscanf(stdin, "%u", &ubar);
	printf("got %u\n\n", ubar);
#endif

	unsigned_int_add_ovf(ufoo, ubar); /* UINT_MAX + 1 */

#ifdef USE_TIME_TO_INIT
	ubar = 	(time((time_t) NULL) < 0) ? 42 : UINT_MAX;
#else
	printf("Enter %u: ", UINT_MAX);
	fscanf(stdin, "%u", &ubar);
	printf("got %u\n\n", ubar);
#endif

	unsigned_int_add_ovf(ufoo, ubar); /* UINT_MAX + UINT_MAX */

#ifdef USE_TIME_TO_INIT
	ufoo = 	(time((time_t) NULL) < 0) ? 42 : 0;
	ubar = 	(time((time_t) NULL) < 0) ? 42 : 1;
#else
	printf("Enter a 0: ");
	fscanf(stdin, "%u", &ufoo);
	printf("got %u\n\n", ufoo);

	printf("Enter a 1: ");
	fscanf(stdin, "%u", &ubar);
	printf("got %u\n\n", ubar);
#endif

	unsigned_int_sub_undf(ufoo, ubar); /* 0 - 1 */


#ifdef USE_TIME_TO_INIT
	ubar = 	(time((time_t) NULL) < 0) ? 42 : UINT_MAX;
#else
	printf("Enter %u: ", UINT_MAX);
	fscanf(stdin, "%u", &ubar);
	printf("got %u\n\n", ubar);
#endif

	unsigned_int_sub_undf(ufoo, ubar); /*  0 - UINT_MAX */


	printf("\nTesting signed integer OK....\n\n");

#ifdef USE_TIME_TO_INIT
	foo = 	(time((time_t) NULL) < 0) ? 42 : 1;
	bar = 	(time((time_t) NULL) < 0) ? 42 : 1;
#else
	printf("Enter a 1: ");
	fscanf(stdin, "%d", &foo);
	printf("got %d\n\n", foo);

	printf("Enter a 1: ");
	fscanf(stdin, "%d", &bar);
	printf("got %d\n\n", bar);
#endif

	signed_int_add_ovf_1(foo, bar); /* INT_MAX + 1 */
	signed_int_add_ovf_2(foo, bar);
	signed_int_add_ovf_3(foo, bar);
	signed_int_add_ovf_mot(foo, bar);
	signed_int_add_ovf_cert_2s(foo, bar);
	signed_int_add_ovf_cert_any(foo, bar);

#ifdef USE_TIME_TO_INIT
	foo = 	(time((time_t) NULL) < 0) ? 42 : (INT_MAX - 1);
#else
	printf("Enter %d: ", (INT_MAX - 1));
	fscanf(stdin, "%d", &foo);
	printf("got %d\n\n", foo);
#endif

	signed_int_add_ovf_1(foo, bar); /* (INT_MAX-1) + 1 */
	signed_int_add_ovf_2(foo, bar);
	signed_int_add_ovf_3(foo, bar);
	signed_int_add_ovf_mot(foo, bar);
	signed_int_add_ovf_cert_2s(foo, bar);
	signed_int_add_ovf_cert_any(foo, bar);


	printf("\nTesting signed integer addition overflow detection....\n\n");

#ifdef USE_TIME_TO_INIT
	foo = 	(time((time_t) NULL) < 0) ? 42 : INT_MAX;
	bar = 	(time((time_t) NULL) < 0) ? 42 : 1;
#else
	printf("Enter %d: ", INT_MAX);
	fscanf(stdin, "%d", &foo);
	printf("got %d\n\n", foo);

	printf("Enter a 1: ");
	fscanf(stdin, "%d", &bar);
	printf("got %d\n\n", bar);
#endif

	signed_int_add_ovf_1(foo, bar);
	signed_int_add_ovf_2(foo, bar);
	signed_int_add_ovf_3(foo, bar);
	signed_int_add_ovf_mot(foo, bar);
	signed_int_add_ovf_cert_2s(foo, bar);
	signed_int_add_ovf_cert_any(foo, bar);

#ifdef USE_TIME_TO_INIT
	bar = 	(time((time_t) NULL) < 0) ? 42 : INT_MAX;
#else
	printf("Enter %d: ", INT_MAX);
	fscanf(stdin, "%d", &bar);
	printf("got %d\n\n", bar);
#endif

	signed_int_add_ovf_1(foo, bar);
	signed_int_add_ovf_2(foo, bar);
	signed_int_add_ovf_3(foo, bar);
	signed_int_add_ovf_mot(foo, bar);
	signed_int_add_ovf_cert_2s(foo, bar);
	signed_int_add_ovf_cert_any(foo, bar);

	printf("\nTesting signed integer subtraction OK....\n\n");

#ifdef USE_TIME_TO_INIT
	foo = 	(time((time_t) NULL) < 0) ? 42 : 1;
	bar = 	(time((time_t) NULL) < 0) ? 42 : 1;
#else
	printf("Enter a 1: ");
	fscanf(stdin, "%d", &foo);
	printf("got %d\n\n", foo);

	printf("Enter a 1: ");
	fscanf(stdin, "%d", &bar);
	printf("got %d\n\n", bar);
#endif
	signed_int_sub_undf_3(foo, bar);
	signed_int_sub_undf_mot(foo, bar);

#ifdef USE_TIME_TO_INIT
	foo = 	(time((time_t) NULL) < 0) ? 42 : 0;
#else
	printf("Enter a 0: ");
	fscanf(stdin, "%d", &foo);
	printf("got %d\n\n", foo);
#endif
	signed_int_sub_undf_3(foo, bar);
	signed_int_sub_undf_mot(foo, bar);

#ifdef USE_TIME_TO_INIT
	foo = 	(time((time_t) NULL) < 0) ? 42 : (INT_MIN + 1);
#else
	printf("Enter %d: ", (INT_MIN + 1));
	fscanf(stdin, "%d", &foo);
	printf("got %d\n\n", foo);
#endif
	signed_int_sub_undf_3(foo, bar);
	signed_int_sub_undf_mot(foo, bar);

	printf("\nTesting signed integer subtraction underflow detection....\n\n");

#ifdef USE_TIME_TO_INIT
	foo = 	(time((time_t) NULL) < 0) ? 42 : INT_MIN;
	bar = 	(time((time_t) NULL) < 0) ? 42 : 1;
#else
	printf("Enter %d: ", INT_MIN);
	fscanf(stdin, "%d", &foo);
	printf("got %d\n\n", foo);

	printf("Enter a 1: ");
	fscanf(stdin, "%d", &bar);
	printf("got %d\n\n", bar);
#endif
	signed_int_sub_undf_3(foo, bar);
	signed_int_sub_undf_mot(foo, bar);

#ifdef USE_TIME_TO_INIT
	foo = 	(time((time_t) NULL) < 0) ? 42 : INT_MIN;
	bar = 	(time((time_t) NULL) < 0) ? 42 : INT_MAX;
#else
	printf("Enter %d: ", INT_MIN);
	fscanf(stdin, "%d", &foo);
	printf("got %d\n\n", foo);

	printf("Enter %d: ", INT_MAX);
	fscanf(stdin, "%d", &bar);
	printf("got %d\n\n", bar);
#endif

	signed_int_sub_undf_3(foo, bar);
	signed_int_sub_undf_mot(foo, bar);

	exit(0);
}

void
unsigned_int_add_ovf(ufoo, ubar)
	unsigned int ufoo;		/* = UINT_MAX */
	unsigned int ubar;		/* = 1 */
{
	unsigned int usum;

	/*
	 * the simplest (and most portable) case is for addition of unsigned
	 * integers -- just check that the result is not less than either of
	 * the operands:
	 *
	 * (you should be using unsigned ints for array subscripts anyway!) 
	 */
	usum = ufoo + ubar;
	if (usum < ufoo || usum < ubar) {
		printf("*** unsigned integer addition overflow: %u + %u = %u!\n", ufoo, ubar, usum);
	} else {
		printf("unsigned integer addition OK: %u + %u = %u\n", ufoo, ubar, usum);
	}
}

void
unsigned_int_sub_undf(ufoo, ubar)
	unsigned int ufoo;		/* = 0 */
	unsigned int ubar;		/* = UINT_MAX || 1 */
{
	unsigned int udiff;

	/*
	 * similarly for subtraction -- just check that the result is not
	 * greater than either of the operands:
	 */
	udiff = ufoo - ubar;
	if (udiff > ufoo || udiff > ubar) {
		printf("*** unsigned integer subtraction underflow: %u - %u = %u!\n", ufoo, ubar, udiff);
	} else {
		printf("unsigned integer subtraction OK: %u - %u = %u\n", ufoo, ubar, udiff);
	}
}

void
signed_int_add_ovf_1(foo, bar)
	signed int foo;
	signed int bar;
{
	signed int sum;

	/*
	 * For signed integers on two's-compliment systems:
	 * 
	 * When using operators such as '+' and '-', in which both operands
	 * have like signs, a change of sign in the result indicates an
	 * overflow condition.
	 *
	 * Note that if the signs of the operands are different then of course
	 * an overflow or underflow is impossible.
	 */
	sum = foo + bar;
	if ((foo >= 0 && bar <= 0) ||
	    (foo <= 0 && bar >= 0)) {
		printf("signed 2's-compliment integer addition 1 OK: %d + %d = %d\n", foo, bar, sum);
	} else if ((foo > 0 && sum < 0) ||
		   (foo < 0 && sum > 0)) {
		printf("*** signed 2's-compliment integer addition overflow 1: %d + %d = %d!\n", foo, bar, sum);
	} else {
		printf("signed 2's-compliment integer addition 1 OK: %d + %d = %d\n", foo, bar, sum);
	}
}

void
signed_int_add_ovf_2(foo, bar)
	signed int foo;
	signed int bar;
{
	signed int sum;

	/*
	 * perhaps even simpler than the sign-change check though for
	 * 2's-complement systems is this simple magnitude check of one operand
	 * against the result based on whether the other operand is positive or
	 * not (from GCC's "-ftrapv" runtime):
	 *
	 * NOTE:  This is probably the least expensive post-condition check!
	 */
	sum = foo + bar;
	if ((foo >= 0) ? (sum < bar) : (sum > bar)) {
		printf("*** signed 2's-complement integer addition overflow 2: %d + %d = %d!\n", foo, bar, sum);
	} else {
		printf("signed 2's-complement integer addition 2 OK: %d + %d = %d\n", foo, bar, sum);
	}
}

void
signed_int_add_ovf_3(foo, bar)
	signed int foo;
	signed int bar;
{
	signed int sum;

	/*
	 * from Autoconf's manual, a tranformed variant of the above expression
	 */
	sum = foo + bar;
	if ((sum < bar) != (foo < 0)) {
		printf("*** signed 2's-complement integer addition overflow 3: %d + %d = %d!\n", foo, bar, sum);
	} else {
		printf("signed 2's-complement integer addition 3 OK: %d + %d = %d\n", foo, bar, sum);
	}
}

void
signed_int_add_ovf_mot(foo, bar)
	signed int foo;
	signed int bar;
{
	signed int sum;

	/*
	 * without regard to the sign of the operands we can also use the
	 * following on two's-complement systems (Apparently from Motorola's
	 * documented scheme for setting the overflow bit in MC68k family).
	 */
	sum = foo + bar;
	if (((foo & bar & ~sum) | (~foo & ~bar & sum)) < 0) {
		printf("*** safe & simple signed 2's-complement integer addition overflow: %d + %d = %d!\n", foo, bar, sum);
	} else {
		printf("safe & simple signed signed 2's-complement integer addition OK: %d + %d = %d\n", foo, bar, sum);
	}
}

void
signed_int_add_ovf_cert_2s(foo, bar)
	signed int foo;
	signed int bar;
{
	signed int sum;

	/*
	 * The CERT secure coding page shows an even more complex version (I've
	 * replaced a complex static expression with INT_MIN) of this still
	 * very complex and much more expensive (especially on RISC CPUs)
	 * solution for testing for potential integer overflow when adding two
	 * integer values when the host uses a two's-complement representation
	 * for integers:
	 */
	if (((foo^bar) | (((foo^(~(foo^bar) & INT_MIN)) + bar)^bar)) >= 0) {
		sum = foo + bar;
		printf("*** expensive pre-condition signed 2's-complement integer addition overflow: %d + %d = %d!\n", foo, bar, sum);
	} else {
		sum = foo + bar;
		printf("expensive pre-condition signed 2's-complement integer addition OK: %d + %d = %d\n", foo, bar, sum);
	}
}

void
signed_int_add_ovf_cert_any(foo, bar)
	signed int foo;
	signed int bar;
{
	signed int sum;

	/*
	 * The CERT secure coding page goes on to show another equally (or even
	 * more) expensive solution for testing for potential integer overflow
	 * when adding two integer values regardless of what binary
	 * representation the host uses for integers:
	 */
	if ((foo > 0 && bar > 0 && foo > (INT_MAX - bar)) ||
	    (foo < 0 && bar < 0 && foo < (INT_MIN - bar))) {
		sum = foo + bar;
		printf("*** expensive pre-conditioned signed integer addition overflow: %d + %d = %d!\n", foo, bar, sum);
	} else {
		sum = foo + bar;
		printf("expensive pre-condition signed integer addition OK: %d + %d = %d\n", foo, bar, sum);
	}
}

void
signed_int_sub_undf_3(foo, bar)
	signed int foo;
	signed int bar;
{
	signed int diff;

	/*
	 * again from libgcc:
	 *
	 * NOTE:  This is probably the least expensive post-condition check!
	 */
	diff = foo - bar;
	if ((bar >= 0) ? (diff > foo) : (diff < foo)) {
		printf("*** signed 2's-complement integer subtraction underflow 3: %d - %d = %d!\n", foo, bar, diff);
	} else {
		printf("signed 2's-complement integer subtraction OK 3: %d - %d = %d\n", foo, bar, diff);
	}
}

void
signed_int_sub_undf_mot(foo, bar)
	signed int foo;
	signed int bar;
{
	signed int diff;

	/*
	 * again from Motorola:
	 */
	diff = foo - bar;
	if (((foo & ~bar & ~diff) | (~foo & bar & diff)) < 0) {
		printf("*** safe & simple signed 2's-complement integer subtraction overflow: %d - %d = %d!\n", foo, bar, diff);
	} else {
		printf("safe & simple signed signed 2's-complement integer subtraction OK: %d - %d = %d\n", foo, bar, diff);
	}
}

"Greg A. Woods" <woods@robohack.org> writes:

> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>> 
>> It's too fiddly, at least in C. You can overflow check if you really
>> have to, but it's not a viable strategy to insert checking code for
>> every single arithmetical operation that could conceivably overflow.
>> You need a different language for that.
>
> Well, it's pretty trivial to do overflow checking with a decent compiler.
>
> See the '-ftrapv' option for GCC, for example.

Ooops -- sorry -- newer versions of GCC broke '-ftrapv' without
deprecating it or even documenting the breakage.

Clang gets it right though.

-- 
						Greg A. Woods
						RoboHack

<woods@robohack.ca>     living on the edge      http://www.robohack.ca/

On 12 Jul., 23:18, Keith Thompson <ks...@mib.org> wrote:
> tm <thomas.mer...@gmx.at> writes:
> > On 12 Jul., 22:39, Thomas Boell <tbo...@domain.invalid> wrote:
> >> On Tue, 12 Jul 2011 10:21:44 -0700 (PDT)
>
> >> tm <thomas.mer...@gmx.at> wrote:
> >> > Using 64 bit ints only shifts the problem, but does NOT
> >> > solve it. Only overflow detection and unlimited precision
> >> > integers
>
> >> =A0and unlimited amounts of RAM
>
> > Libraries supporting unlimited precision integers usually
> > raise a MEMORY_EXCEPTION when there is not enough memory
> > to represent an integer. At least my bigInteger library
> > (see:http://seed7.sourceforge.net/libraries/bigint.htm)
> > works this way. :-)
>
> Or, if they're in C rather than C++, they either return a result
> or set errno to some value that indicates they've run out of memory.

My librariy is written in C, but it raises a Seed7 exception
in out of memory situations. :-)
Does GMP set errno when it runs out of memory?

I am not sure that Java can handle out of memory situations
with an exception.


Greetings Thomas Mertes

--
Seed7 Homepage:  http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows.

On Jul 12, 9:14=A0pm, "BartC" <b...@freeuk.com> wrote:
> "Malcolm McLean" <malcolm.mcle...@btinternet.com> wrote in message
>
> And if you're advocating always using 64-bits, whether it's needed or not=
,
> then you could be doubling or quadrupling memory needs, and bandwidth,
> unnecessarily. Especially on a machine with a natural word size of 32-bit=
s.
>
We need to find out where memory is actually used.

For instance my current program work with genetic sequence data. When
memory gets tight, that's normally because I need an NxN matrix of
genes in an organism, where N is about 6000. However day to day, most
of the memory is used by sequence data - which fits comfortably into
2GB - a list of genes might be 15 megabytes.

So in my case, moving to 64 bit ints wouldn't impact memory
requirements at all. However that's not necessarily true of everyone.
--
Bioinformatics programming goodies:
vist my website http://www.malcolmmclean.site11.com/www

On 13 Jul., 05:03, "Greg A. Woods" <wo...@robohack.org> wrote:
> tm <thomas.mer...@gmx.at> writes:
>
> > Yes, but it must be checked after every operation.
> > A hardware that triggers an interrupt, would save this
> > extra checks.
>
> I think you're assuming either the code is running nearly bare on the
> hardware (in which case your program has its own ISR), or that your OS
> has a very inexpensive way to deliver the ISR to a process.

I was not talking about the overhead that occurs when an overflow
happens. Exceptions should be rare and people know that they are
not as cheap as normal computations.

I thought about overhead, when NO overflow occurs.

In an ideal world code with and without overflow checking would run
at the same speed (as long as no overflow occurs).

> As I mentioned in another post just now, a decent compiler can use
> library routines for all arithmetic operations and thus allow all
> operations to be checked for overflow algorithmically.

Yes, but this would have probable more overhead than checking
an overflow flag, not to mention hardware that can do this
without extra cost (trigger interrupt).

> See GCC's "-ftrapv" option, for example.

AFAIK -ftrapv adds code to check an overflow flag after arithmetic
operations.

IMHO -ftrapv is the right way, because it allows gcc to use hardware
support (when a CPU is able to trigger an interrupt on overflow).

BTW, does gcj support this option also?
Has javac a similar option?

> You may also be assuming that overflows aren't so common in C.  :-)
>
> Try re-compiling your system's entire userland with "gcc -ftrapv" and
> see how much of it still works without aborting.

It does work.
I just had to change a program which checks left shift by comparing
the result with a multiplication by a power of two. AFAIK left shift
is not checked by -ftrapv, but multiplication is. Nor the chkint.sd7
program only checks left shift in situations where no overflow
occurs.

Using the signal to raise an exception is something else.
E.g.: gcc and clang disagree in the signal used (gcc: SIGABRT,
clang: SIGILL). So useful support of this feature in Seed7 may
take some time.


Greetings Thomas Mertes

--
Seed7 Homepage:  http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows.

"Greg A. Woods" <woods@robohack.org> writes:

> Keith Thompson <kst-u@mib.org> writes:
>> 
>> But detecting the overflow in the first place can be *very* tricky.
>
> Assuming your code is too complex or performance sensitive to use a
> compiler that can do the checking for you (e.g. maybe with Clang's
> "-ftrapv" -- see my comments below), it's reasonlyb easy to reliably do
> the checks yourself, assuming you understand your target platform.
>
> Attached is some test code I wrote quite a long time ago for checking
> compilers and such.  It uses techniques I found from various sources to
> demonstrate the possibilities of reliable integer overflow and
> underflow detection for addition and subtraction, respectively.

I am not sure what you mean by "reliable".  For example, the code
produces different results with different gcc optimisations turned on.
It's been said before (I think) but it is worth noting that any test
that does the arithmetic first has already entered the world of
undefined behaviour and that's not the best place to be for reliable
tests.

> I think I've covered testing each technique for most of the corner &
> edge cases you have to watch out for, but I can't be certain.
>
> I just re-ran it with some newer versions of GCC though and I see that
> '-ftrapv' doesn't seem to work at all any more.  They broke it bad, and
> haven't got around to fixing it yet.  See the comments in the code below.
>
> Half-hearted apologies to anyone stuck with an 80-column terminal.  Join
> the modern age and get a wider screen!  :-)

I have one now, but the last time I edited K&R style functions I didn't!

<snip code>
-- 
Ben.

On 7/13/2011 12:52 AM, tm wrote:
> On 13 Jul., 05:03, "Greg A. Woods"<wo...@robohack.org>  wrote:
....
>> As I mentioned in another post just now, a decent compiler can use
>> library routines for all arithmetic operations and thus allow all
>> operations to be checked for overflow algorithmically.
>
> Yes, but this would have probable more overhead than checking
> an overflow flag, not to mention hardware that can do this
> without extra cost (trigger interrupt).

I'm not convinced that there would be extra cost. The main performance
costs on modern processors tend to be data movement, and mis-predicted
conditional branches. The overflow check needs no additional data, and
the associated conditional branches will be about as easy to predict as
is possible.

Patricia

"Greg A. Woods" <woods@robohack.org> writes:
> Keith Thompson <kst-u@mib.org> writes:
>> But detecting the overflow in the first place can be *very* tricky.
>
> Assuming your code is too complex or performance sensitive to use a
> compiler that can do the checking for you (e.g. maybe with Clang's
> "-ftrapv" -- see my comments below), it's reasonlyb easy to reliably do
> the checks yourself, assuming you understand your target platform.
                       --------------------------------------------

Which means you can't do it portably.

> Attached is some test code I wrote quite a long time ago for checking
> compilers and such.  It uses techniques I found from various sources to
> demonstrate the possibilities of reliable integer overflow and
> underflow detection for addition and subtraction, respectively.
[...]

> #ifdef USE_TIME_TO_INIT
> 	ufoo = 	(time((time_t) NULL) < 0) ? 42 : 1;
> 	ubar = 	(time((time_t) NULL) < 0) ? 42 : 1;
> #else
[...]
> #endif
[...]

Interesting, I used almost exactly the same trick just yesterday in this
very thread:

    int x = time(NULL) < 0 ? 42 : INT_MAX;

Great minds think alik.  And so do ours.  8-)}

BTW, the cast is unnecesary; since you have a #include <time.h>,
the compiler knows that time() takes a time_t* argument, and will
generate an implicit conversion.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> 
> "Greg A. Woods" <woods@robohack.org> writes:
> >
> > Attached is some test code I wrote quite a long time ago for checking
> > compilers and such.  It uses techniques I found from various sources to
> > demonstrate the possibilities of reliable integer overflow and
> > underflow detection for addition and subtraction, respectively.
>
> I am not sure what you mean by "reliable".  For example, the code
> produces different results with different gcc optimisations turned on.

Are you sure?  I can't get any different behaviour no matter how much
optimisation I use, and I've tried many versions of GCC, as well as
Clang now on OS X.

The only option which (sometimes) makes a difference is '-ftrapv'.  :-)

-- 
						Greg A. Woods
						RoboHack

<woods@robohack.ca>     living on the edge      http://www.robohack.ca/

tm <thomas.mertes@gmx.at> writes:
> 
> On 13 Jul., 05:03, "Greg A. Woods" <wo...@robohack.org> wrote:
> >
> > You may also be assuming that overflows aren't so common in C.  :-)
> >
> > Try re-compiling your system's entire userland with "gcc -ftrapv" and
> > see how much of it still works without aborting.
>
> It does work.

Your _entire_ system's userland?  Really?

I wonder if in NetBSD the shell wouldn't even die while running the
start-up scripts, and not because of a bug, but rather "intended"
overflows or wraparounds.

I dunno if I'm even brave enough to try it in a virtual machine!  ;-)

(of course I'd have to use a version of gcc with a working -ftrapv, and
that seems to be more difficult to find than I thought -- it's been a
while since I used that option for production code or even serious
testing)

-- 
						Greg A. Woods
						RoboHack

<woods@robohack.ca>     living on the edge      http://www.robohack.ca/

Patricia Shanahan <pats@acm.org> writes:
> 
> On 7/13/2011 12:52 AM, tm wrote:
> > 
> > On 13 Jul., 05:03, "Greg A. Woods"<wo...@robohack.org>  wrote:
> ...
> > > As I mentioned in another post just now, a decent compiler can use
> > > library routines for all arithmetic operations and thus allow all
> > > operations to be checked for overflow algorithmically.
> >
> > Yes, but this would have probable more overhead than checking
> > an overflow flag, not to mention hardware that can do this
> > without extra cost (trigger interrupt).
>
> I'm not convinced that there would be extra cost. The main performance
> costs on modern processors tend to be data movement, and mis-predicted
> conditional branches. The overflow check needs no additional data, and
> the associated conditional branches will be about as easy to predict as
> is possible.

I'm not sure what target host environment you're thinking of, but in any
general purpose operating system environment I can think of the extra
cost of the hardware interrupts triggered by arithmetic overflows could
be significant.  Signal delivery and context switching is never free.

Worst would be if the hardware interrupt couldn't easily and efficiently
be disabled temporarily by the OS when running a process which didn't
care to be notified.  Then the OS would have to handle the interrupt and
figure out whether to discard it or not.  CRC algorithms, and especially
those in the kernel, may have to be carefully re-implemented to avoid
triggering overflows unnecessarily, and would thus then incur added
runtime costs themselves.  I.e. avoiding triggering unnecessary
interrupts could also be a significant runtime cost.

When you get down to brass tacks you only want overflow and wraparound
checking when you need it.  Unfortunately C makes it hard for
programmers to easily know when they need it.  I think the AIR proposal
may help, and it seems as if the RICH work identified many of these
issues and dealt with some of them too.  I guess I'll be content to wait
until something like these shows up in a GCC or Clang release I'm using,
as I've been living with overflows and wraparound (and no bounds checks)
well enough so far.

-- 
						Greg A. Woods
						RoboHack

<woods@robohack.ca>     living on the edge      http://www.robohack.ca/

"Greg A. Woods" <woods@robohack.org> writes:

> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>> 
>> "Greg A. Woods" <woods@robohack.org> writes:
>> >
>> > Attached is some test code I wrote quite a long time ago for checking
>> > compilers and such.  It uses techniques I found from various sources to
>> > demonstrate the possibilities of reliable integer overflow and
>> > underflow detection for addition and subtraction, respectively.
>>
>> I am not sure what you mean by "reliable".  For example, the code
>> produces different results with different gcc optimisations turned on.
>
> Are you sure?  I can't get any different behaviour no matter how much
> optimisation I use, and I've tried many versions of GCC, as well as
> Clang now on OS X.

Maybe I'm misunderstanding the program but I get this:

$ gcc -std=c99 -pedantic -O2 ovf.c -o ovf
$ ./ovf >o2
$ gcc -std=c99 -pedantic -O3 ovf.c -o ovf
$ ./ovf >o3
$ diff o2 o3
31,33c31,33
< *** signed 2's-compliment integer addition overflow 1: 2147483647 + 1 = -2147483648!
< *** signed 2's-complement integer addition overflow 2: 2147483647 + 1 = -2147483648!
< *** signed 2's-complement integer addition overflow 3: 2147483647 + 1 = -2147483648!
---
> signed 2's-compliment integer addition 1 OK: 2147483647 + 1 = -2147483648
> signed 2's-complement integer addition 2 OK: 2147483647 + 1 = -2147483648
> signed 2's-complement integer addition 3 OK: 2147483647 + 1 = -2147483648
37c37
< *** signed 2's-compliment integer addition overflow 1: 2147483647 + 2147483647 = -2!
---
> signed 2's-compliment integer addition 1 OK: 2147483647 + 2147483647 = -2
$ gcc --version
gcc (Ubuntu 4.4.3-4ubuntu5) 4.4.3
Copyright (C) 2009 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

-- 
Ben.

Eric Sosman wrote:
> On 7/10/2011 5:47 AM, China Blue Dolls wrote:
>>
>> In C the array size is not part of the type or value, so there is
>> nothing to check.
>
>     No; the size (element count) is part of an array's type.  Your
> compiler will confirm this for you by issuing a diagnostic for
>
> char matrix[5][7];  /* five char[7] arrays */
> char (*nine)[9];    /* pointer to char[9] */
> nine = matrix;      /* point it at the first char[7] */
>
>> C integer arithmetic is always modulo M, for some large M (like
>> 2**32 or 2**64). So the concept of overflow does not apply.
>
>     This is true only for `unsigned' integer arithmetic.  Signed
> integer arithmetic is in fact vulnerable to overflow.

And if you take "overflow" to mean "can do something undesireable (wrap) 
without warning", so does unsigned arith. To say "So the concept of 
overflow does not apply" seems to attempt to dismiss the behavior as 
being OK somehow instead of recognizing the deficiency that it is most of 
the time. 

Greg A. Woods wrote:
> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>>
>> It's too fiddly, at least in C. You can overflow check if you really
>> have to, but it's not a viable strategy to insert checking code for
>> every single arithmetical operation that could conceivably overflow.
>> You need a different language for that.
>
> Well, it's pretty trivial to do overflow checking with a decent
> compiler.
>
> See the '-ftrapv' option for GCC, for example.

From the technical note "As-If Infinitely Ranged Integer Model, Second 
Edition" (a pdf available at 
http://www.sei.cmu.edu/library/abstracts/reports/10tn008.cfm and a 
recommended good read as background info for this thread discusion for 
those who haven't seen it):

"The -ftrapv option is known to have substantial problems. The 
__addvsi3() function re-quires a function call and conditional branching, 
which can be expensive on modern hardware. An alternative implementation 
tests the processor overflow condition code, but it requires assembly 
code and is non-portable. Furthermore, the GCC -ftrapv flag only works 
for a limited subset of signed operations and always results in an 
abort() when a runtime overflow is detected. Dis-cussions for how to trap 
signed integer overflows in a reliable and maintainable manner are 
ongo-ing within the GCC community."

So, as far as I can tell, it's impossible, rather than trivial, to do it 
effectively using ftrapv. 

BartC wrote:
> "tm" <thomas.mertes@gmx.at> wrote in message
> news:289ad570-65fc-49d8-9cc8-1f15d13ff3e3@gv8g2000vbb.googlegroups.com...
>
>> And popular CPUs, which do detect integer overflow, do not
>> trigger an interupt. This makes zero overhead overflow
>> detection impossible.
>>
>> So software suffers because hardware / CPU designers want
>> to save a transistor...
>
> Even if zero-overhead detection was possible, it's difficult to know
> how to make use of this in C. For example:
>
> int a,b,c;
>
> c=a+b;
>
> The a+b overflows, but then what?

Then you fix the bug in the program that causes the overflow.

> You can't then magically switch
> over to:
> long long int a,b,c;
>
> Even /with/ the overhead, it's difficult to see what could follow
> such an expression:
>
> if (overflow(c=a+b)) ...
>
> In the context of C-based code for implementing auto-ranging, dynamic
> types of /another language/, this might be workable, but still
> difficult to see how it can be done with zero-overhead. But this is a
> limited application (which I wouldn't even attempt in C because it's
> so fiddly).
> Aborting a program is also a possibility, but this just helps in
> debugging, and overheads are less relevant.

"JUST" helps debugging? Wouldn't it be nice to get thos MANY, COMMON bugs 
out of code before it gets deployed?

>
> (There is a longer thread on this in comp.lang.misc: "Integer
> arithmetic" from around start of March 2011.) 

Keith Thompson wrote:
> Joe Pfeiffer <pfeiffer@cs.nmsu.edu> writes:
>> markspace <-@.> writes:
>>> On 7/12/2011 6:16 AM, Stefan Ram wrote:
>>>> "BartC"<bc@freeuk.com>  writes:
>>>>> a+b overflows, but then what?
>>>>
>>>>    This can only be answered given the requirements
>>>>    specification of a specific project.
>>>
>>> What I think he's saying is there's no way physically detect the
>>> overflow in a language like C which has no exceptions.  You'd have
>>> to at least introduce some sort of global flag.
>>>
>>>   int c = a + b;
>>>   if( GLOBAL_OVERFLOW_FLAG ) {
>>>     printf( "bugger..." );
>>>   }
>>
>> Well, yes there is.  For example on an addition, if both operands
>> have the same sign and the result is the other sign, you had an
>> overflow. Analogous conditions exist (which I don't remember off the
>> top of my head and am too lazy to look up) exist for subtraction and
>> multiplication.  Integer division can't overflow.
>
> On many systems, yes, you can detect signed overflow after the fact by
> examining the values of the operands and the result.

That is post-condition checking. Pre-condition techniques are possible 
also.

>But in C, the
> behavior is undefined

So post-condition checking is not an option for signed arithmetic in C 
(not portably, anyway).

> -- and even on systems that use 2's-complement,
> an optimizing compiler can take advantage of that fact and generate
> code based on the assumption that overflow never occurs.  For
> example, this:
>
>    int x = INT_MAX;
>    if (x + 1 < x) {
>        fprintf(stderr, "Overflow!\n");
>    }
>
> can be optimized away  (For example, gcc does this at -O2 and above.)

A recognized issue. I forgot what the solution to that was. Oh yeah: 
don't optimize!

>
> And yes, integer division can overflow; consider INT_MIN / -1.
>
>> My reading of the question was "OK, you've detected an overflow.  Now
>> what do you do about it?" and the (correct) answer was, in essence,
>> "well, what do you *want* to do about it?"
>
> But detecting the overflow in the first place can be *very* tricky.

Do you mean at the programmer level or at the compiler level? 

Patricia Shanahan wrote:
> On 7/6/2011 8:35 AM, rop rop wrote:
>> Hi,
>>
>> If I want to have arithmetic-overflow checking in all parts of an
>> application,
>> what is the most practical, simple, efficient way to achieve this?
>
> Write the application in Ada.
>
> Patricia

But C# is very Java-like and has "checked" and also the compiler-level 
equivalent, so C# would be the better alternative. (And yes, I do know 
you were just kidding about Ada). 

Peter Duniho wrote:
> On 7/7/11 10:02 AM, Patricia Shanahan wrote:
>> On 7/7/2011 7:11 AM, Peter Duniho wrote:
>>> On 7/6/11 10:16 AM, Patricia Shanahan wrote:
>>>> On 7/6/2011 8:35 AM, rop rop wrote:
>>>>> Hi,
>>>>>
>>>>> If I want to have arithmetic-overflow checking in all parts of an
>>>>> application,
>>>>> what is the most practical, simple, efficient way to achieve this?
>>>>
>>>> Write the application in Ada.
>>>
>>> Or use C#, which has the same feature, but is a lot more like Java
>>> otherwise.
>>>
>>> That said, I suspect Tom's guess is correct and a language-change
>>> just to achieve this goal isn't going to be the practical choice.
>>
>> Like most design decisions, it is a trade-off. If Tom *needs*
>> overflow checking, the most practical, simple, efficient way to
>> achieve it is to use a language that is designed to support overflow
>> checking.
>
> To be clear, I don't think _Tom_ needs or doesn't need this.  He was
> simply replying to the OP.
>
>> If he merely *wants* overflow checking, the best choice may be to
>> stick to Java and drop general overflow checking. That does not
>> prevent having e.g. a BigInteger subclass that takes a range as a
>> constructor parameter and does overflow checking against that range.
>
> I don't disagree with that.  In fact, I'm skeptical that in any
> program it really makes sense to apply overflow checking to _every_
> computation, even not counting the issues that have already been
> pointed out wrt the JDK itself and other libraries which rely on the
> lack of it.  For example, does every integral "for" loop _really_
> need the index increment operation to be checked for overflow?  Seems
> unlikely to me.

It's Java. Why worry about performance?! And how expensive really is it? 
Instead of just increment, increment and check the hardware overflow 
flag. (Oops, did I say "hardware" in a Java NG? My bad).

>
> While the discussion has been interesting, I can't help but feel that
> the original question is fundamentally flawed.  The answers are mostly
> academic, as it's unlikely anyone really ought to be trying to
> approach the problem in this way in the first place.

It's as easy as setting a compiler switch in some languages (not in C or 
C++ though, but C#, e.g.), so the approach seems sound and desireable for 
a language to implement. The programmer shouldn't be overly burdened with 
the task of overflow checking.

>
>> I have not yet seen an option for getting general overflow checking
>> in Java, without getting false hits on code that depends on the JLS
>> specified arithmetic behavior, that is at all practical, simple, or
>> efficient.
>
> Well, I think Tom's suggestion of some sort of automatic code-rewriter
> _could_ be the best solution in _certain_ scenarios.  Such an
> implementation could be applied selectively to specific code.
>
> I would not worry about the "simple" or "efficient" criteria.  IMHO,
> if one is deciding to apply overflow checking to every computation,
> one has already abandoned the hope of efficiency.

I don't think that is true. It depends on the application of course, but 
for most programs, wouldn't a single-digit performance hit be acceptable? 
(OK, maybe not on already slow Java ;) ).


> Frankly, as long as the discussion is purely hypothetical (as it is
> now), I don't see how anyone can claim with 100% certainty the broad
> superiority or inferiority of any given solution.  It's too dependent
> on the specifics of whatever real-world scenario is at hand.
>

I think the issue has achieved critical mass (programmers, not just comp 
scientists) now and every language needs to "keep up with the Joneses" 
(C#) to stay relevant. 

On 7/14/2011 10:14 PM, MikeP wrote:
> Patricia Shanahan wrote:
>> On 7/6/2011 8:35 AM, rop rop wrote:
>>> Hi,
>>>
>>> If I want to have arithmetic-overflow checking in all parts of an
>>> application,
>>> what is the most practical, simple, efficient way to achieve this?
>>
>> Write the application in Ada.
>>
>> Patricia
>
> But C# is very Java-like and has "checked" and also the compiler-level
> equivalent, so C# would be the better alternative. (And yes, I do know
> you were just kidding about Ada).
>
>

No, I was not really joking, though I did not attempt to find all the
languages that would meet the stated requirement.

I'm very strongly of the opinion different languages should provide
different features, making different trade-offs, and programmers should
pick the language for a job based on its requirements and those features.

The alternative a lot of programmers follow seems to be to pick one
language, ignore all the others, and then complain when there is a
mismatch between that language's features and their current requirements.

I have no problem with pushing minor changes and additional features
within the general framework of a language, but if the basic framework
is not a good match for a job, the solution is to pick a language that
is more suitable.

Patricia

Patricia Shanahan wrote:
> MikeP wrote:
>> Patricia Shanahan wrote:
....
>>> Write the application in Ada.
>
> >> Patricia
>
> > But C# is very Java-like and has "checked" and also the compiler-level
> > equivalent, so C# would be the better alternative. (And yes, I do know
> > you were just kidding about Ada).
>
> No, I was not really joking, though I did not attempt to find all the
> languages that would meet the stated requirement.
>

Others did not think you were joking.  I've known people who use Ada
professionally and not one complained about the language.  I've only
ever encountered disparagement of Ada from people who don't use it.

I've never worked with Ada, so I defer to those who have.

> I'm very strongly of the opinion different languages should provide
> different features, making different trade-offs, and programmers should
> pick the language for a job based on its requirements and those features.
>
> The alternative a lot of programmers follow seems to be to pick one
> language, ignore all the others, and then complain when there is a
> mismatch between that language's features and their current requirements.
>
> I have no problem with pushing minor changes and additional features
> within the general framework of a language, but if the basic framework
> is not a good match for a job, the solution is to pick a language that
> is more suitable.
>

+1

--
Lew

Patricia Shanahan wrote:
> On 7/14/2011 10:14 PM, MikeP wrote:
>> Patricia Shanahan wrote:
>>> On 7/6/2011 8:35 AM, rop rop wrote:
>>>> Hi,
>>>>
>>>> If I want to have arithmetic-overflow checking in all parts of an
>>>> application,
>>>> what is the most practical, simple, efficient way to achieve this?
>>>
>>> Write the application in Ada.
>>>
>>> Patricia
>>
>> But C# is very Java-like and has "checked" and also the
>> compiler-level equivalent, so C# would be the better alternative.
>> (And yes, I do know you were just kidding about Ada).
>>
>>
>
> No, I was not really joking, though I did not attempt to find all the
> languages that would meet the stated requirement.

Don't look now, but if you weren't joking, then you recommended Ada to a 
Java programmer! Oh my.

>
> I'm very strongly of the opinion different languages should provide
> different features, making different trade-offs, and programmers
> should pick the language for a job based on its requirements and
> those features.

You have to admit, it's quite a chasm between Java/C# and Ada.

> The alternative a lot of programmers follow seems to be to pick one
> language,

I do/did that. (C++ is my poison).

> ignore all the others,

I have regularly looked at other languages and used them in minor ways 
for evaluation.

> and then complain when there is a
> mismatch between that language's features and their current
> requirements.

In another post, I said that I think that today (like in right now) the 
awareness of the overflow issue (language support) has achieved critical 
mass. Combine that with the alternatives that are available and more yet 
to come, a language cannot afford to go the path of, say, C anymore for 
it will lose relevance much more quickly. It's not complaining. It's 
customer feedback (companies BEG their customers for such!). Companies 
that don't recognize their customers needs and change with the times, go 
out of business. Java is not C and can't afford to stagnate like C did 
(OK, C++ gave it a "reconditioning"), or it won't last.

>
> I have no problem with pushing minor changes and additional features
> within the general framework of a language, but if the basic framework
> is not a good match for a job, the solution is to pick a language that
> is more suitable.

C# will fit in a lot of places where Java does (or so I assume given what 
I know about them, as I'm don't use either language other than for 
evaluation and case study). Pushing away programmers to other languages 
instead of evolving the language according to the expectations (i.e., 
what programmers have come to expect to be standard feature in a given 
class of language) is surely a path to obsolescence. 

On 7/15/2011 9:29 PM, MikeP wrote:
> Patricia Shanahan wrote:
>> On 7/14/2011 10:14 PM, MikeP wrote:
>>> Patricia Shanahan wrote:
>>>> On 7/6/2011 8:35 AM, rop rop wrote:
>>>>> Hi,
>>>>>
>>>>> If I want to have arithmetic-overflow checking in all parts of an
>>>>> application,
>>>>> what is the most practical, simple, efficient way to achieve this?
>>>>
>>>> Write the application in Ada.
>>>>
>>>> Patricia
>>>
>>> But C# is very Java-like and has "checked" and also the
>>> compiler-level equivalent, so C# would be the better alternative.
>>> (And yes, I do know you were just kidding about Ada).
>>>
>>>
>>
>> No, I was not really joking, though I did not attempt to find all the
>> languages that would meet the stated requirement.
>
> Don't look now, but if you weren't joking, then you recommended Ada to a
> Java programmer! Oh my.

Huh? Java, like any healthy programming language, is a tool, not a religion.

Patricia

Patricia Shanahan wrote:
> On 7/15/2011 9:29 PM, MikeP wrote:
>> Patricia Shanahan wrote:
>>> On 7/14/2011 10:14 PM, MikeP wrote:
>>>> Patricia Shanahan wrote:
>>>>> On 7/6/2011 8:35 AM, rop rop wrote:
>>>>>> Hi,
>>>>>>
>>>>>> If I want to have arithmetic-overflow checking in all parts of an
>>>>>> application,
>>>>>> what is the most practical, simple, efficient way to achieve
>>>>>> this?
>>>>>
>>>>> Write the application in Ada.
>>>>>
>>>>> Patricia
>>>>
>>>> But C# is very Java-like and has "checked" and also the
>>>> compiler-level equivalent, so C# would be the better alternative.
>>>> (And yes, I do know you were just kidding about Ada).
>>>>
>>>>
>>>
>>> No, I was not really joking, though I did not attempt to find all
>>> the languages that would meet the stated requirement.
>>
>> Don't look now, but if you weren't joking, then you recommended Ada
>> to a Java programmer! Oh my.
>
> Huh? Java, like any healthy programming language, is a tool, not a
> religion.

Just like a dentist's drill and an oil well drill are tools? 

In article <ivr43p$7cq$1@dont-email.me>, "MikeP" <mp011011@some.org> 
wrote:

> Patricia Shanahan wrote:
[...]
> > No, I was not really joking, though I did not attempt to find all 
> > the languages that would meet the stated requirement.
> 
> Don't look now, but if you weren't joking, then you recommended Ada 
> to a Java programmer! Oh my.

I often suggest Ada to Java programmers; knowledgeable Java programmers 
often return the favor; I've learned a lot that way.

> > I'm very strongly of the opinion different languages should provide 
> > different features, making different trade-offs, and programmers 
> > should pick the language for a job based on its requirements and 
> > those features.
> 
> You have to admit, it's quite a chasm between Java/C# and Ada.

I find points of comparison very illuminating. Perhaps "chasm" is a 
matter of perspective.

> > The alternative a lot of programmers follow seems to be to pick one 
> > language,
> 
> I do/did that. (C++ is my poison).

See also: "The science of fanboyism."
Article: <http://techreport.com/discussions.x/21294>
Discussion: <http://science.slashdot.org/story/11/07/15/1331243>

-- 
John B. Matthews
trashgod at gmail dot com
<http://sites.google.com/site/drjohnbmatthews>

John B. Matthews wrote:
> "MikeP" wrote:
>> Patricia Shanahan wrote:
> [...]
>>> No, I was not really joking, though I did not attempt to find all
>>> the languages that would meet the stated requirement.
>
>> Don't look now, but if you weren't joking, then you recommended Ada
>> to a Java programmer! Oh my.
>

Oh, your what?  What are you acting so shocked about?  Give us logic,
evidence, reasoning, not just superficial rhetorical devices.  What in
bloody blazes is so strange about recommending Ada to a Java
programmer, hm?

Nothing!

Let's be an engineer, "MikeP", hm-k?

> I often suggest Ada to Java programmers; knowledgeable Java programmers
> often return the favor; I've learned a lot that way.
>
>>> I'm very strongly of the opinion different languages should provide
>>> different features, making different trade-offs, and programmers
>>> should pick the language for a job based on its requirements and
>>> those features.
>
>> You have to admit, it's quite a chasm between Java/C# and Ada.
>

Be specific.  No one has to admit that.  As the person making the
claim, the burden of proof is on you, "MikeP".  Demonstrate your
point, please.  Define "chasm", how to measure it, and what makes the
difference "quite" a chasm.

> I find points of comparison very illuminating. Perhaps "chasm" is a
> matter of perspective.
>

Perhaps "quite a chasm" is a matter of someone wanting to sound
impressive who has no facts or reasoning behind their argument, so
they make little unsupportable foolish comments full of "nudge, nudge,
wink, wink" instead.

>>> The alternative a lot of programmers follow seems to be to pick one
>>> language,
>

Not the good ones, nor the ones who wish to stay employed.

>> I do/did that. (C++ is my poison).
>
> See also: "The science of fanboyism."
> Article: <http://techreport.com/discussions.x/21294>
> Discussion: <http://science.slashdot.org/story/11/07/15/1331243>
>

C'mon, "MikeP", this is a programmers' group.  Give us more than
tabloid gossip-column rhetoric, please.

--
Lew

"MikeP" wrote:
> C# will fit in a lot of places where Java does (or so I assume given what
> I know about them, as I'm [sic] don't use either language other than for
>

You might want to know a little more about the languages before
rendering judgment.

C# and Java run on different platforms - C# far fewer than Java.  What
do you mean by "a lot"?

> evaluation and case study). Pushing away programmers to other languages
> instead of evolving the language according to the expectations (i.e.,
> what programmers have come to expect to be standard feature in a given
> class of language) is surely a path to obsolescence.
>

"Surely"?  Would you mind providing *any* evidence or logic for that
claim?

Over three decades as a professional programmer, I've had to know a
zillion languages to avoid obsolescence.  Those who stuck with Fortran
when C became popular found themselves marginalized with frightening
speed, although of course there is still Fortran work out there.  C
programmers had to know shell programming and assembler to get any
work done.  If you don't know SQL, you are so screwed.  If you stayed
with C when C++ and # and Java came out, you were dooming yourself to
obsolescence, over the large segments of the market.  C++ has become
ivory tower and very competitive - unless you're one of the best in
that world, failing to learn other languages "surely" doomed you to
obsolescence.  C# and Java are similar in a lot of ways, but language
alone doth not make the program.  Software is 1% programming and 99%
deployment and operations.  They run in different environments, and
you cannot really use either one without SQL, HTML, Javascript and
things like Python, and now, of course, JQL and other metalanguages.
Don't speak XML?  Hello, obsolescence!  Can't use JSON?  You're
limited.  Can't read bytecode?  You're less of a Java programmer.

You couldn't be more mistaken in your conclusions.  A programmer needs
to know a minimum of two full-fledged programming languages, one with
the ability to create wild pointers, a database-query language, a
shell and at least one scripting language just to be minimally
competent.

Please don't imagine that you're going to impress anyone if you
respond to this post with more of your indirect, suggestive comments
unsubstantiated by even the merest jot of reasoning and evidence.

--
Lew

"MikeP" wrote:
> Patricia Shanahan wrote:
>> MikeP wrote:
>>> Patricia Shanahan wrote:
>>>> MikeP wrote:
>>>>> Patricia Shanahan wrote:
>>>>>> Write the application in Ada.
>
>>>>> But C# is very Java-like and has "checked" and also the
>>>>> compiler-level equivalent, so C# would be the better alternative.
>>>>> (And yes, I do know you were just kidding about Ada).
>
>>>> No, I was not really joking, though I did not attempt to find all
>>>> the languages that would meet the stated requirement.
>
>>> Don't look now, but if you weren't joking, then you recommended Ada
>>> to a Java programmer! Oh my.
>
>> Huh? Java, like any healthy programming language, is a tool, not a
>> religion.
>
> Just like a dentist's drill and an oil well [sic] drill are tools?
>

Yes, exactly.  Both of those are tools, and neither of those are
religions.

--
Lew

On 7/16/2011 10:46 AM, lewbloch wrote:
....
> Over three decades as a professional programmer, I've had to know a
> zillion languages to avoid obsolescence.  Those who stuck with Fortran
> when C became popular found themselves marginalized with frightening
> speed, although of course there is still Fortran work out there.  C
> programmers had to know shell programming and assembler to get any
> work done.  ...

If I had picked a couple of programming languages near the start of my
career, they would have been Fortran and NEAT/3 Level 2 (the assembly
language for the NCR Century computers).

I don't believe I would have had anywhere near as long, or fun, a career
without continuous willingness to learn programming languages.

In my last professional project, I wrote code in Java, Verilog, Perl,
and Forth.

Patricia

On 7/16/2011 11:00 AM, lewbloch wrote:
> "MikeP" wrote:
>> Patricia Shanahan wrote:
>>> MikeP wrote:
>>>> Patricia Shanahan wrote:
>>>>> MikeP wrote:
>>>>>> Patricia Shanahan wrote:
>>>>>>> Write the application in Ada.
>>
>>>>>> But C# is very Java-like and has "checked" and also the
>>>>>> compiler-level equivalent, so C# would be the better alternative.
>>>>>> (And yes, I do know you were just kidding about Ada).
>>
>>>>> No, I was not really joking, though I did not attempt to find all
>>>>> the languages that would meet the stated requirement.
>>
>>>> Don't look now, but if you weren't joking, then you recommended Ada
>>>> to a Java programmer! Oh my.
>>
>>> Huh? Java, like any healthy programming language, is a tool, not a
>>> religion.
>>
>> Just like a dentist's drill and an oil well [sic] drill are tools?
>>
>
> Yes, exactly.  Both of those are tools, and neither of those are
> religions.

And it would be just as pointless to complain about the dental drill
taking too long to drill a thousand foot well as to complain about the
oil well drill being too big to fit in a patient's mouth. It's much
better to look at the job and pick the tool that is most suitable for it.

Patricia

Patricia Shanahan wrote:
> On 7/16/2011 11:00 AM, lewbloch wrote:
>> "MikeP" wrote:
>>> Patricia Shanahan wrote:
>>>> MikeP wrote:
>>>>> Patricia Shanahan wrote:
>>>>>> MikeP wrote:
>>>>>>> Patricia Shanahan wrote:
>>>>>>>> Write the application in Ada.
>>>
>>>>>>> But C# is very Java-like and has "checked" and also the
>>>>>>> compiler-level equivalent, so C# would be the better
>>>>>>> alternative. (And yes, I do know you were just kidding about
>>>>>>> Ada).
>>>
>>>>>> No, I was not really joking, though I did not attempt to find all
>>>>>> the languages that would meet the stated requirement.
>>>
>>>>> Don't look now, but if you weren't joking, then you recommended
>>>>> Ada to a Java programmer! Oh my.
>>>
>>>> Huh? Java, like any healthy programming language, is a tool, not a
>>>> religion.
>>>
>>> Just like a dentist's drill and an oil well [sic] drill are tools?
>>>
>>
>> Yes, exactly.  Both of those are tools, and neither of those are
>> religions.
>
> And it would be just as pointless to complain about the dental drill
> taking too long to drill a thousand foot well as to complain about the
> oil well drill being too big to fit in a patient's mouth. It's much
> better to look at the job and pick the tool that is most suitable for
> it.

I found it bizarre that you recommended an oil well drill to a dentist. 

John B. Matthews wrote:

>> I do/did that. (C++ is my poison).
>
> See also: "The science of fanboyism."
> Article: <http://techreport.com/discussions.x/21294>
> Discussion: <http://science.slashdot.org/story/11/07/15/1331243>

Do you mean because I use C++ I'm now "a fanboy"? 

lewbloch wrote:
> John B. Matthews wrote:
>> "MikeP" wrote:
>>> Patricia Shanahan wrote:
>> [...]
>>>> No, I was not really joking, though I did not attempt to find all
>>>> the languages that would meet the stated requirement.
>>
>>> Don't look now, but if you weren't joking, then you recommended Ada
>>> to a Java programmer! Oh my.
>>
>
> Oh, your what?  What are you acting so shocked about?

That Patricia recommended "an oil well drill to a dentist". I did not 
think the concept was obtuse.

>>>> I'm very strongly of the opinion different languages should provide
>>>> different features, making different trade-offs, and programmers
>>>> should pick the language for a job based on its requirements and
>>>> those features.
>>
>>> You have to admit, it's quite a chasm between Java/C# and Ada.
>>
>
> Be specific.  No one has to admit that.  As the person making the
> claim, the burden of proof is on you, "MikeP".  Demonstrate your
> point, please.  Define "chasm", how to measure it, and what makes the
> difference "quite" a chasm.

You are on a witch-hunt so I'll bid you farewell (as in buh-bye, I don't 
do pee-pee measuring contests).

>
>> I find points of comparison very illuminating. Perhaps "chasm" is a
>> matter of perspective.
>>
>
> Perhaps "quite a chasm" is a matter of someone wanting to sound
> impressive who has no facts or reasoning behind their argument, so
> they make little unsupportable foolish comments full of "nudge, nudge,
> wink, wink" instead.

Don't look now but your EQ (lack of) is showing.

>
> C'mon, "MikeP", this is a programmers' group.  Give us more than
> tabloid gossip-column rhetoric, please.

I really have no advice to those who are proverbial "bit heads" other 
than maybe enroll in a few Humanities classes?

Now, if you want to grow up and have some post-adolescent discourse, 
fine. Else just puh-leeeze, go away! 

MikeP <mp011011@some.org> wrote:
> Patricia Shanahan wrote:
>> On 7/16/2011 11:00 AM, lewbloch wrote:
>>> "MikeP" wrote:
>>>> Patricia Shanahan wrote:
>>>>> MikeP wrote:
>>>>>> Patricia Shanahan wrote:
>>>>>>> MikeP wrote:
>>>>>>>> Patricia Shanahan wrote:
>>>>>>>>> Write the application in Ada.
>>>>
>>>>>>>> But C# is very Java-like and has "checked" and also the
>>>>>>>> compiler-level equivalent, so C# would be the better
>>>>>>>> alternative. (And yes, I do know you were just kidding about
>>>>>>>> Ada).
>>>>
>>>>>>> No, I was not really joking, though I did not attempt to find all
>>>>>>> the languages that would meet the stated requirement.
>>>>
>>>>>> Don't look now, but if you weren't joking, then you recommended
>>>>>> Ada to a Java programmer! Oh my.
>>>>
>>>>> Huh? Java, like any healthy programming language, is a tool, not a
>>>>> religion.
>>>>
>>>> Just like a dentist's drill and an oil well [sic] drill are tools?
>>>>
>>>
>>> Yes, exactly.  Both of those are tools, and neither of those are
>>> religions.
>>
>> And it would be just as pointless to complain about the dental drill
>> taking too long to drill a thousand foot well as to complain about the
>> oil well drill being too big to fit in a patient's mouth. It's much
>> better to look at the job and pick the tool that is most suitable for
>> it.
> I found it bizarre that you recommended an oil well drill to a dentist. 

That's just, because the dentist expressed a need to exploit the oil well
in his backyard.

Andreas Leitgeb wrote:
> MikeP <mp011011@some.org> wrote:
>> Patricia Shanahan wrote:
>>> On 7/16/2011 11:00 AM, lewbloch wrote:
>>>> "MikeP" wrote:
>>>>> Patricia Shanahan wrote:
>>>>>> MikeP wrote:
>>>>>>> Patricia Shanahan wrote:
>>>>>>>> MikeP wrote:
>>>>>>>>> Patricia Shanahan wrote:
>>>>>>>>>> Write the application in Ada.
>>>>>
>>>>>>>>> But C# is very Java-like and has "checked" and also the
>>>>>>>>> compiler-level equivalent, so C# would be the better
>>>>>>>>> alternative. (And yes, I do know you were just kidding about
>>>>>>>>> Ada).
>>>>>
>>>>>>>> No, I was not really joking, though I did not attempt to find
>>>>>>>> all the languages that would meet the stated requirement.
>>>>>
>>>>>>> Don't look now, but if you weren't joking, then you recommended
>>>>>>> Ada to a Java programmer! Oh my.
>>>>>
>>>>>> Huh? Java, like any healthy programming language, is a tool, not
>>>>>> a religion.
>>>>>
>>>>> Just like a dentist's drill and an oil well [sic] drill are tools?
>>>>>
>>>>
>>>> Yes, exactly.  Both of those are tools, and neither of those are
>>>> religions.
>>>
>>> And it would be just as pointless to complain about the dental drill
>>> taking too long to drill a thousand foot well as to complain about
>>> the oil well drill being too big to fit in a patient's mouth. It's
>>> much better to look at the job and pick the tool that is most
>>> suitable for it.
>> I found it bizarre that you recommended an oil well drill to a
>> dentist.
>
> That's just, because the dentist expressed a need to exploit the oil
> well in his backyard.

He did not. He wanted to provide better care to his patients. 

In article <ivst52$p8a$1@dont-email.me>, "MikeP" <mp011011@some.org> 
wrote:

> John B. Matthews wrote:
> 
> >> I do/did that. (C++ is my poison).
> >
> > See also: "The science of fanboyism."
> > Article: <http://techreport.com/discussions.x/21294>
> > Discussion: <http://science.slashdot.org/story/11/07/15/1331243>
> 
> Do you mean because I use C++ I'm now "a fanboy"? 

I sense you didn't read the article; it suggests that the predilection 
is pervasive, and not unique to you or C++. As I struggle continually 
against such bias, I'd welcome your perspective.

-- 
John B. Matthews
trashgod at gmail dot com
<http://sites.google.com/site/drjohnbmatthews>

On 11/07/2011 23:49, Joshua Cranmer allegedly wrote:
> On 7/11/2011 2:43 PM, Gene Wirchenko wrote:
>> On Mon, 11 Jul 2011 10:30:26 -0700, Joshua Cranmer
>> <Pidgeot18@verizon.invalid>  wrote:
>>       Averaging a set of numbers with a sum too big would be caught by
>> overflow checking and not bounds checking.
> 
> What I advocated would basically be a "checked integer": every operation
> is guaranteed to have a result between [min, max]; if not, it throws an
> exception.

Sounds cool. Any chance we might see it in teh Jav one day? And is there
actually hardware support for it?

-- 
DF.
Determinism trumps correctness.

On 7/17/2011 6:50 AM, John B. Matthews wrote:
> In article<ivst52$p8a$1@dont-email.me>, "MikeP"<mp011011@some.org>
> wrote:
>
>> John B. Matthews wrote:
>>
>>>> I do/did that. (C++ is my poison).
>>>
>>> See also: "The science of fanboyism."
>>> Article:<http://techreport.com/discussions.x/21294>
>>> Discussion:<http://science.slashdot.org/story/11/07/15/1331243>
>>
>> Do you mean because I use C++ I'm now "a fanboy"?
>
> I sense you didn't read the article; it suggests that the predilection
> is pervasive, and not unique to you or C++. As I struggle continually
> against such bias, I'd welcome your perspective.
>

I don't like the term "fanboy" because it suggests it is an immature
male tendency. The research does not support that. I'm definitely a
fanwoman when it comes to the desirability of programming as a career,
but have never fallen in love with a programming language.

Patricia

"MikeP" wrote:
> lewbloch wrote:
> > John B. Matthews wrote:
> >> "MikeP" wrote:
> >>> Patricia Shanahan wrote:
> >> [...]
> >>>> No, I was not really joking, though I did not attempt to find all
> >>>> the languages that would meet the stated requirement.
>
> >>> Don't look now, but if you weren't joking, then you recommended Ada
> >>> to a Java programmer! Oh my.
>
> > Oh, your what? =A0What are you acting so shocked about?
>
> That Patricia recommended "an oil well drill to a dentist". I did not
> think the concept was obtuse.
>

She did no such thing.  You should listen.  And once again, stop with
the tabloid headline nonsense.  Programming is an engineering
profession, ergo it requires logic and cold-hearted examination of
reality.  Sound-bite poster sayings will not substitute for that.
Practice using logical and reasoned arguments.

> >>>> I'm very strongly of the opinion different languages should provide
> >>>> different features, making different trade-offs, and programmers
> >>>> should pick the language for a job based on its requirements and
> >>>> those features.
>
> >>> You have to admit, it's quite a chasm between Java/C# and Ada.
>
> > Be specific. =A0No one has to admit that. =A0As the person making the
> > claim, the burden of proof is on you, "MikeP". =A0Demonstrate your
> > point, please. =A0Define "chasm", how to measure it, and what makes the
> > difference "quite" a chasm.
>
> You are on a witch-hunt so I'll bid you farewell (as in buh-bye, I don't
> do pee-pee measuring contests).
>

Again, you are employing emotional and indirect comments to make
conclusions not supported by the evidence.

Far from being on a "witch-hunt [sic]", I am recommending an essential
skill the practice of which will greatly help you.  In other words,
I'm giving you good advice.  That is the antithesis of a witch hunt, a
phrase that refers to the determined search for blame without regard
for the facts.

> >> I find points of comparison very illuminating. Perhaps "chasm" is a
> >> matter of perspective.
>
> > Perhaps "quite a chasm" is a matter of someone wanting to sound
> > impressive who has no facts or reasoning behind their argument, so
> > they make little unsupportable foolish comments full of "nudge, nudge,
> > wink, wink" instead.
>
> Don't look now but your EQ (lack of) is showing.

You believe that I am unequalized?  What do you even mean?

You are quite fond of this "Don't look now" phrasing.  It really isn't
making any real points.

>> C'mon, "MikeP", this is a programmers' group. =A0Give us more than
>> tabloid gossip-column rhetoric, please.
>
> I really have no advice to those who are proverbial "bit heads" other
> than maybe enroll in a few Humanities classes?
>

Sorry?  How does that relate to my comment, other than to demonstrate
a complete lack of understanding thereof or a complete refusal to
engage in reasoned discussion?

No one asked you for advice.  I gave you advice, and a request (that
you have obviously declined).

> Now, if you want to grow up and have some post-adolescent discourse,
> fine. Else just puh-leeeze, go away!

Is that meant to demonstrate mature discourse?

No one is impressed by your insistence on troll-like emotional and
irrelevant comments in lieu of reasoned discussion.  Sorry,
"discourse".  The one engaging in bashing and adolescent expressions
like "puh-leeeze" is not the one to render judgment on what
constitutes "post-adolescent discourse".  Rather, your avoidance of
the points raised by anyone in this discussion and consistent refusal
to use logic or evidence puts you in no position to act so snotty.

You are a troll.  You've done nothing but issue snarky comments and
argumentative statements this entire discussion.  This is a group for
programmers to discuss programming matters.  You would benefit from
behaving accordingly.

--
Lew

In article <19CdnS9k06YSYb_TnZ2dnUVZ_oSdnZ2d@earthlink.com>,
 Patricia Shanahan <pats@acm.org> wrote:

> On 7/17/2011 6:50 AM, John B. Matthews wrote:
> > In article<ivst52$p8a$1@dont-email.me>, "MikeP"<mp011011@some.org>
> > wrote:
> >
> >> John B. Matthews wrote:
> >>
> >>>> I do/did that. (C++ is my poison).
> >>>
> >>> See also: "The science of fanboyism."
> >>> Article:<http://techreport.com/discussions.x/21294>
> >>> Discussion:<http://science.slashdot.org/story/11/07/15/1331243>
> >>
> >> Do you mean because I use C++ I'm now "a fanboy"?
> >
> > I sense you didn't read the article; it suggests that the predilection
> > is pervasive, and not unique to you or C++. As I struggle continually
> > against such bias, I'd welcome your perspective.
> >
> 
> I don't like the term "fanboy" because it suggests it is an immature
> male tendency. The research does not support that. I'm definitely a
> fanwoman when it comes to the desirability of programming as a career,
> but have never fallen in love with a programming language.

Yes, the term is awkward and loaded with irrelevant connotations; but 
immaturity may be pivotal. I distinctly remember a series of 
infatuations, starting with Fortran II on an NCR Century 200. In 
exchange for a modicum of scut work, the third-shift operator would give 
my deck a precious extra run or two. Carelessly, I rejected his offer to 
teach me the rudiments of COBOL, for no better treason than the bias 
cited above. I've tried to be more vigilant since.

-- 
John B. Matthews
trashgod at gmail dot com
<http://sites.google.com/site/drjohnbmatthews>

John B. Matthews wrote:
> In article <ivst52$p8a$1@dont-email.me>, "MikeP" <mp011011@some.org>
> wrote:
>
>> John B. Matthews wrote:
>>
>>>> I do/did that. (C++ is my poison).
>>>
>>> See also: "The science of fanboyism."
>>> Article: <http://techreport.com/discussions.x/21294>
>>> Discussion: <http://science.slashdot.org/story/11/07/15/1331243>
>>
>> Do you mean because I use C++ I'm now "a fanboy"?
>
> I sense you didn't read the article; it suggests that the predilection
> is pervasive, and not unique to you or C++. As I struggle continually
> against such bias, I'd welcome your perspective.

So now I have one of these "predilection" thingies, huh. 

lewbloch wrote:

[masturbation snipped]

Oh the irony.

On Jul 18, 5:03=A0am, "MikeP" <mp011...@some.org> wrote:
> lewbloch wrote:
>
> [masturbation snipped]
>
> Oh the irony.

Plonk

On Sat, 16 Jul 2011 15:43:21 -0500, "MikeP" <mp011011@some.org> wrote:

>John B. Matthews wrote:
>
>>> I do/did that. (C++ is my poison).
>>
>> See also: "The science of fanboyism."
>> Article: <http://techreport.com/discussions.x/21294>
>> Discussion: <http://science.slashdot.org/story/11/07/15/1331243>
>
>Do you mean because I use C++ I'm now "a fanboy"? 

     Some might.  I do not.

     I do not mind someone thinking that what he is using is the best
for him.  I do not mind him suggesting that I might benefit from it,
too.  What I do object to is him trying to cram it down my throat.

     Apple is built on fanboyism.  I remember Apple fanboys getting on
my case in the early 1980's.  Perish the thought that there be more
than one thing to be, do, or have.

     And, sadly, fanboyism is much more widespread.

Sincerely,

Gene Wirchenko

On 18/07/2011 7:56 AM, MikeP wrote:
> John B. Matthews wrote:
>> In article<ivst52$p8a$1@dont-email.me>, "MikeP"<mp011011@some.org>
>> wrote:
>>> Do you mean because I use C++ I'm now "a fanboy"?

No. Only if you irrationally stick with C++ when there are better 
alternatives.  Not sayin' you're doing that, just applying the ideas of 
the research summarized in that blog.

>>
>> I sense you didn't read the article; it suggests that the predilection
>> is pervasive, and not unique to you or C++. As I struggle continually
>> against such bias, I'd welcome your perspective.
>
> So now I have one of these "predilection" thingies, huh.

According to the research cited in the blog, we all do.

On 17/07/2011 11:14 AM, Daniele Futtorovic wrote:
> On 11/07/2011 23:49, Joshua Cranmer allegedly wrote:
>> What I advocated would basically be a "checked integer": every operation
>> is guaranteed to have a result between [min, max]; if not, it throws an
>> exception.
>
> Sounds cool. Any chance we might see it in teh Jav one day? And is there
> actually hardware support for it?

I think the gist of some other discussion in this thread is that some 
computers have hardware detection and others don't.

On 7/18/2011 4:28 PM, David Lamb wrote:
> On 17/07/2011 11:14 AM, Daniele Futtorovic wrote:
>> On 11/07/2011 23:49, Joshua Cranmer allegedly wrote:
>>> What I advocated would basically be a "checked integer": every operation
>>> is guaranteed to have a result between [min, max]; if not, it throws an
>>> exception.
>>
>> Sounds cool. Any chance we might see it in teh Jav one day? And is there
>> actually hardware support for it?
>
> I think the gist of some other discussion in this thread is that some
> computers have hardware detection and others don't.

In a sense, most processors that could run a full Java installation
already have what they need.

In many case, range limited integer checking can be done at compile
time, because of the greater precision. Suppose, for example, you are
adding two one digit numbers. If each of them is in a [0,9], the
compiler knows that the result will fit in a [0,18]. If each is in a
byte, the compiler cannot know that their sum fits in a byte.

In the remaining cases, we are looking at comparisons involving
constants and values that are already in registers, and conditional
branches that go the same way somewhere between 99.9999% and 100% of the
time. The expensive operations are cache misses and mis-predicted
branches, and neither is likely in this case. The processor in a small
2011 PC is a supercomputer by historical standards, with the ability to
do multiple operations at the same time, if the data is available.

Patricia

On 7/6/2011 2:30 PM, stefan@nyniva.se wrote:
> On Jul 6, 6:42 pm, markspace<-@.>  wrote:
>> On 7/6/2011 8:35 AM, rop rop wrote:
>>> If I want to have arithmetic-overflow checking in all parts of an
>>> application,
>>> what is the most practical, simple, efficient way to achieve this?
>>> Id like to clutter the code as little a possible...
>>> Is there any way to instruct the JVM to include it?
>>
>> Nope, can't be done.  And yes I've griped about this myself, so you're
>> in good (well, average at least) company.
>
> OK...
> What about patching the JVM to add this (sadly missing) "feature"?
> It is open-source, isnt it?

There are a few open source JVM's around.

> Nobody has done this already?

I don't think so.

And remember that it will not be Java or JVM any longer.

> Doesnt seems like a terribly big project, once I can locate the right
> place to do it...

Probably depends a bit on how you want it to work.

> Any license aspects to consider, if I do it myself?

You need to follow the license for the open source code.

If I remember correct then OpenJDK and GCJ is GPL and Harmony
is Apache (for the JVM part).

And you can not call it Java or Oracle's lawyers will demand
10 trillion dollars (or something like that) for trademark infringement.

Arne

On 7/7/2011 2:26 AM, John B. Matthews wrote:
> In article<2rydnez7l-H5BYnTnZ2dnUVZ_vGdnZ2d@earthlink.com>,
>   Patricia Shanahan<pats@acm.org>  wrote:
>> On 7/6/2011 8:35 AM, rop rop wrote:
>>>
>>> If I want to have arithmetic-overflow checking in all parts of an
>>> application, what is the most practical, simple, efficient way to
>>> achieve this?
>>
>> Write the application in Ada.
>
> In one popular implementation, the -gnato compiler option enables
> numeric overflow checking:
>
> <http://gcc.gnu.org/onlinedocs/gcc-4.6.1/gnat_ugn_unw/Switches-for-gcc.html#Switches-for-gcc>
>
> The language defined attribute 'Machine_Overflows will indicate if
> checking is available for fixed or floating point types:
>
> <http://www.adaic.org/resources/add_content/standards/05rm/html/RM-K.html>
>
> JGNAT targets the JVM, but I haven't used it.

It works pretty well.

Arne

On 7/7/2011 10:11 AM, Peter Duniho wrote:
> On 7/6/11 10:16 AM, Patricia Shanahan wrote:
>> On 7/6/2011 8:35 AM, rop rop wrote:
>>> If I want to have arithmetic-overflow checking in all parts of an
>>> application,
>>> what is the most practical, simple, efficient way to achieve this?
>>
>> Write the application in Ada.
>
> Or use C#, which has the same feature, but is a lot more like Java
> otherwise.

But if he does not want to switch runtime - either due to runtime
availability or existing libraries, then I have more faith in JGnat than
in GrassHopper.

Arne

On 7/8/2011 6:52 PM, rop rop wrote:
> Generally, as for performance, for the majority of typical industry-
> apps today (web-app backed by a database) overflow-checking would have
> completely negligible impact on performance.
>
> In-memory-computations, today, typically has extremely little impact,
> compared to database-accesses and sending data over network.

Be careful.

Do you want to check for overflow in your code only or in all Java
code incl. Java library, JDBC drivers etc.?

If the first, then I completely agree.

If the second I would want to measure before agreeing.

Arne

On 7/9/2011 10:46 AM, markspace wrote:
> On 7/9/2011 2:58 AM, rop rop wrote:
>> I also think not, in the general case...
>> But you could also have an annotation argument, like
>>
>> @CheckForOverflow(allTheWayDown=true)
>> or
>> @CheckForOverflow(allTheWayDown=false)
>
>
> I did a quick check of the C# variant when it was mentioned here, and
> this is how they do it:
>
> int result = checked( a + b - c );
>
> In other words is a key word. Since Java can't really do this easily,
> I'd be in favor of using an existing key word and extending it. For
> example, the key word "try" can't ever appear currently as a class name
> or package name in any program, so we could do this:
>
> int result = try.checked( a + b - c );
>
> Which at least makes sense to me as one reads the code; i.e., it's
> literate programming. One could, I suppose, also extend the syntax where
> an annotation can be used, but this might have side effects also. For
> example, it might be hard to support these new user defined annotations
> in the general case.

Just note that C# is a bit more rich than that:

default and compiled with /checked- => checked(expression) and
checked { } do overflow check for expression / block but do not
for the rest

compiled with /checked+ => unchecked(expression) and
unchecked { } do not overflow check for expression / block
but do for the rest

Arne

On 7/18/11 8:17 PM, Arne Vajhøj wrote:
> [...]
>> I did a quick check of the C# variant when it was mentioned here, and
>> this is how they do it:
>>
>> int result = checked( a + b - c );
>>
>> [...]
>
> Just note that C# is a bit more rich than that:
>
> default and compiled with /checked- => checked(expression) and
> checked { } do overflow check for expression / block but do not
> for the rest
>
> compiled with /checked+ => unchecked(expression) and
> unchecked { } do not overflow check for expression / block
> but do for the rest

As long as we're calling out the specifics: it may be important to know 
that in C#, statically computable expressions (more specifically, those 
that contain only constants) are always checked unless in an explicit 
"unchecked" block, even if the default setting is used.

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> $ gcc --version
> gcc (Ubuntu 4.4.3-4ubuntu5) 4.4.3

Good to know -- I don't have access to any GCC that new.

-- 
						Greg A. Woods
						RoboHack

<woods@robohack.ca>     living on the edge      http://www.robohack.ca/

"MikeP" <mp011011@some.org> writes:
> 
> So, as far as I can tell, it's impossible, rather than trivial, to do it 
> effectively using ftrapv. 

With more recent releases of GCC, yes.  Seems to work fine with Clang,
and they're happy to mention it as a feature too.

-- 
						Greg A. Woods
						RoboHack

<woods@robohack.ca>     living on the edge      http://www.robohack.ca/

On 7/8/2011 4:15 PM, lewbloch wrote:
> On Jul 8, 10:27 am, Gene Wirchenko<ge...@ocis.net>  wrote:
>> On Thu, 7 Jul 2011 17:29:42 -0700 (PDT), lewbloch<lewbl...@gmail.com>
>> wrote:
>>> On Jul 7, 5:12 pm, Gene Wirchenko<ge...@ocis.net>  wrote:
>>>> On Thu, 07 Jul 2011 14:53:50 -0700, Patricia Shanahan<p...@acm.org>
>>>> wrote:
>>>>> I think the problem is more a matter of software knowing when overflow
>>>>> should and should not be treated as an error.
>>
>>>>       Exactly.  C does not do that sort of checking, and the meme has
>>>> spread widely.  I would much prefer to have things blow up when wrong
>>>> than not blow up.  It makes for smaller messes.
>>
>>> the problem with that statement is that it's not wrong for Java
>>> primitive integer types to wrap around.
>>
>>       Java is designed to behave that way.  That does not mean that it
>> is not wrong.
>
> It doesn't mean that it is wrong.
>
> In fact, it does mean that it's not wrong.  If you're working in Java,
> to do differently from what the Java spec requires is wrong.
>
> As others have pointed out, there's an awful lot of code that depends
> on the documented, required behavior.  For that code, to have overflow
> exceptions would be wrong, doubly so because it would violate the
> rules under which the code was developed.

Yes, but given that there are already two languages under discussion,
then it seems rather obvious that his point is that Java should have
been designed different 16 years ago not change overflow handling
in Java 8.

Arne

On 7/8/2011 6:34 PM, rop rop wrote:
> On Jul 8, 2:29 am, lewbloch<lewbl...@gmail.com>  wrote:
>>>       Exactly.  C does not do that sort of checking, and the meme has
>>> spread widely.  I would much prefer to have things blow up when wrong
>>> than not blow up.  It makes for smaller messes.
>>
>> the problem with that statement is that it's not wrong for Java
>> primitive integer types to wrap around.
>>
>> It is, in fact, wrong for them to throw an overflow exception, as many
>> have pointed out in this thread.
>
> Yes, I am sure we all know that it IS 100% per the Java-spec -- no
> need to point out that...

Yes yes.

> That being said, I personally think it must be one of the most epic
> design errors in software-history, to DELIBERATELY design a
> programming-language this way.
> To me its like... WHAT THE H*** WERE THEY THINKING? :)

The same as most other language designers.

How many mainstream languages do you know that detect integer
overflow?

Arne

On 7/19/2011 5:54 PM, Arne Vajh�j wrote:

>> On Jul 8, 10:27 am, Gene Wirchenko<ge...@ocis.net> wrote:
>>> Java is designed to behave that way. That does not mean that it
>>> is not wrong.

 > On 7/8/2011 4:15 PM, lewbloch wrote:
>>
>> It doesn't mean that it is wrong.
>>

> Yes, but given that there are already two languages under discussion,
> then it seems rather obvious that his point is that Java should have
> been designed different 16 years ago not change overflow handling
> in Java 8.


I think the point being made is that it's behavior that could be 
improved *now*.

The prescience required to see 16 years into the future is darn hard.  I 
don't think anyone at all has that kind of skill or knowledge.  It would 
have been better however to acknowledge sometime in the past that Java 
needed to be improved in some fundamental ways and then make those 
changes.

Generics should have been reifiable, primitives should be "first class 
objects," integer math should be checked for overflow where the 
programmer deems needed.  These things have been lacking for some time, 
and are still needed, imo.

On 7/19/2011 9:07 PM, markspace wrote:
> On 7/19/2011 5:54 PM, Arne Vajh�j wrote:
>>> On Jul 8, 10:27 am, Gene Wirchenko<ge...@ocis.net> wrote:
>>>> Java is designed to behave that way. That does not mean that it
>>>> is not wrong.
>
>  > On 7/8/2011 4:15 PM, lewbloch wrote:
>>>
>>> It doesn't mean that it is wrong.
>>>
>
>> Yes, but given that there are already two languages under discussion,
>> then it seems rather obvious that his point is that Java should have
>> been designed different 16 years ago not change overflow handling
>> in Java 8.
>
>
> I think the point being made is that it's behavior that could be
> improved *now*.
>
> The prescience required to see 16 years into the future is darn hard. I
> don't think anyone at all has that kind of skill or knowledge. It would
> have been better however to acknowledge sometime in the past that Java
> needed to be improved in some fundamental ways and then make those changes.
>
> Generics should have been reifiable, primitives should be "first class
> objects," integer math should be checked for overflow where the
> programmer deems needed. These things have been lacking for some time,
> and are still needed, imo.

Today it is a must that changes must not break existing code.

That still leaves some room for improvements.

But it tend to become messy.

Sometimes we just need to realize that a wrong decision was
made, that we are stuck with it and that it should be done
correctly in the next language.

Arne

On 7/11/2011 1:30 PM, Joshua Cranmer wrote:
> On 7/11/2011 8:09 AM, Gene Wirchenko wrote:
>> I would rather have it the other way around. Safety first. Make
>> the option on by default. If someone really needs the additional
>> speed and judges the risk is acceptable, then that person can flip the
>> switch and maybe get sued into the ground if he gets it wrong.
>
> The problem with arithmetic overflow is that it's not really adding any
> safety. Sure, having 2^30 + 2^30 be a value less than 0 is wrong, but
> often times the 2^30 value in the first place is just as wrong. Not to
> mention that sometimes people fake unsigned integer types, in which case
> 2 - 1 is an invalid value--how is the compiler supposed to know that
> this value is really an unsigned value? Note that this would break,
> e.g., java.util.Arrays.binarySearch.
>
> What you really need is checked ranges, not automatic overflow checking.

Checked ranges would be nice too.

But check of whether integer arithmetic follows math rules could
still be nice standalone.

Arne

"Greg A. Woods" <woods@robohack.org> writes:

> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>> $ gcc --version
>> gcc (Ubuntu 4.4.3-4ubuntu5) 4.4.3
>
> Good to know -- I don't have access to any GCC that new.

Spend $300 for a netbook and install Ubuntu?

Joe Pfeiffer <pfeiffer@cs.nmsu.edu> writes:
> "Greg A. Woods" <woods@robohack.org> writes:
>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>> $ gcc --version
>>> gcc (Ubuntu 4.4.3-4ubuntu5) 4.4.3
>>
>> Good to know -- I don't have access to any GCC that new.
>
> Spend $300 for a netbook and install Ubuntu?

Spend $0 for VirtualBox and install Ubuntu?

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

On Tue, 19 Jul 2011 20:47:45 -0600, Joe Pfeiffer wrote:

[snip]
 
> Spend $300 for a netbook and install Ubuntu?

Yes, that's what I did and I've never regretted it for a minute.

Todd

tm wrote:

>
> And popular CPUs, which do detect integer overflow, do not
> trigger an interupt. This makes zero overhead overflow
> detection impossible.
>
> So software suffers because hardware / CPU designers want
> to save a transistor...

Some software relies on overflows NOT triggering
anything - encryption software, for example.

I think an interrupt every time THAT overflows
would have performance implications ;-)

  BugBear

On 11-07-19 10:31 PM, Arne Vajh�j wrote:
> On 7/19/2011 9:07 PM, markspace wrote:
>> On 7/19/2011 5:54 PM, Arne Vajh�j wrote:
>>>> On Jul 8, 10:27 am, Gene Wirchenko<ge...@ocis.net> wrote:
>>>>> Java is designed to behave that way. That does not mean that it
>>>>> is not wrong.
>>
>>  > On 7/8/2011 4:15 PM, lewbloch wrote:
>>>>
>>>> It doesn't mean that it is wrong.
>>>>
>>
>>> Yes, but given that there are already two languages under discussion,
>>> then it seems rather obvious that his point is that Java should have
>>> been designed different 16 years ago not change overflow handling
>>> in Java 8.
>>
>>
>> I think the point being made is that it's behavior that could be
>> improved *now*.
>>
>> The prescience required to see 16 years into the future is darn hard. I
>> don't think anyone at all has that kind of skill or knowledge. It would
>> have been better however to acknowledge sometime in the past that Java
>> needed to be improved in some fundamental ways and then make those
>> changes.
>>
>> Generics should have been reifiable, primitives should be "first class
>> objects," integer math should be checked for overflow where the
>> programmer deems needed. These things have been lacking for some time,
>> and are still needed, imo.
> 
> Today it is a must that changes must not break existing code.
> 
> That still leaves some room for improvements.
> 
> But it tend to become messy.
> 
> Sometimes we just need to realize that a wrong decision was
> made, that we are stuck with it and that it should be done
> correctly in the next language.
> 
> Arne
> 
Changes, even backwards-incompatible changes, to version X of a language
do not break existing code *unless* users of that existing code make a
conscious choice to operate that code in the new environment. I am not
convinced there is a strong need to do that.

As an example, and I'm sure I'm not alone in this, I routinely maintain
applications in 2011 that are J2EE 1.4 or Java EE 5. No shortage of them
are J2EE 1.4. Some colleagues who maintain other big web apps I am
familiar with have to deal with Struts 1. The penetration of Java EE 6
applications and Java EE 6 servers into the local big business and
government scene is paltry.

In terms of the associated Java versions, it's true that many folks use
Java 5 or 6 (frequently 1.6 latest update) even if they are developing
for a J2EE 1.4 server, but in my experience there has rarely been a
compelling need for it. To put it another way, I have little time for
someone who argues that they just absolutely need a cool Java 6 language
feature but they can't be bothered to upgrade from J2EE 1.4.

Looking at the Oracle support roadmaps for J2SE/Java SE, fact is that
J2SE 1.4, and Java 5/6, will have some form of adequate support for a
long time yet (http://www.oracle.com/technetwork/java/eol-135779.html).
If Java 8, for example, decided to make some backwards-incompatible
changes to the language, people with existing code bases would have
sufficient options with Java 7 or earlier to keep them happy for a long,
long time. I simply do not see the validity of an argument that says
that the existence of an incompatible Java 8 or 9 is going to affect any
of these people. As it is, I expect not to be primarily working with
Java EE 6 and JDK 7 until 2015 at the earliest...and that may be
optimistic for the Java EE side of things.

As far as "next" languages go, we've already been getting them on the
JVM: Scala and Clojure for example. Or you just abandon the JVM
entirely. Holding back from certain language changes just so someone can
compile a codebase written against Java 5 on a Java 9 compiler, and have
it work, is holding back the entire language. Ironically, the
conservative users that we are pandering to with this approach wouldn't
be in any hurry to use the latest JDK anyway...if ever. And the
hard-charging bleeding-edge developers can certainly rewrite some
existing code in the midst of using all the new features and APIs.

AHS

On 20/07/2011 11:36, Arved Sandstrom wrote:
> Holding back from certain language changes just so someone can
> compile a codebase written against Java 5 on a Java 9 compiler, and have
> it work, is holding back the entire language.

Why is this a problem?

Firstly, you can use `javac -source 1.3` to compile old code, can't you?

Secondly, a future version of Java could introduce some mechanism such 
as in-line compiler directives that turn new 
compiler-behaviours/language-features on for specified classes or for 
specified sections of code (I'm thinking of Perl's `use feature` pragma 
but I'm sure this sort of idea exists in other languages).

-- 
RGB

RedGrittyBrick <RedGrittyBr...@spamweary.invalid> wrote:
> Arved Sandstrom wrote:
>> Holding back from certain language changes just so someone can
>> compile a codebase written against Java 5 on a Java 9 compiler, and have
>> it work, is holding back the entire language.
>
> Why is this a problem?
>
> Firstly, you can use `javac -source 1.3` to compile old code, can't you?
>

No.  Not if you want some of the new features.  For example, if you're
developing to Java 6 and want to keep generics but don't want
autoboxing, you cannot use '-source 1.3 -target 1.3'.  So, if you have
a library that breaks with Java 5 or later, such as commons-lang
enumerations under rare situations, you cannot accommodate that simply
by 'source 1.4'ing it without giving up other desirable features.

You also have to make sure that all your third-party libraries for
that build conform to the older spec.

Targeting an old version is an all-or-nothing proposition.

> Secondly, a future version of Java could introduce some mechanism such
> as in-line compiler directives that turn new
> compiler-behaviours/language-features on for specified classes or for
> specified sections of code (I'm thinking of Perl's `use feature` pragma
> but I'm sure this sort of idea exists in other languages).
>

It'll come down to someone's perception of how valuable that feature
is against the cost.

--
Lew

On 20 Jul., 10:22, bugbear <bugbear@trim_papermule.co.uk_trim> wrote:
> tm wrote:
>
> > And popular CPUs, which do detect integer overflow, do not
> > trigger an interupt. This makes zero overhead overflow
> > detection impossible.
>
> > So software suffers because hardware / CPU designers want
> > to save a transistor...
>
> Some software relies on overflows NOT triggering
> anything - encryption software, for example.
>
> I think an interrupt every time THAT overflows
> would have performance implications ;-)

In C and other languages integer values are used for two
things:

  1. Integer arithmetic ( + - * / )
  2. Bit manipulation (shifts, masks, logical and, logical or)

Bit manipulation works best without overflow detection.
Your example of encryption software is IMHO a bit
manipulation. I am interested in integer arithmetic with
overflow checking.

The programmer should decide, if he wants overflow checking.
E.g. with a compiler switch, different types or pragmas.
In C unsigned integer types are defined to have no overflow
checking, while signed integer types have an undefined
behavior, when an overflow occurs. Gcc and clang have the
flag -ftrapv, which checks the signed operations +, +, *, /
and % for overflow.

Existing code should continue to work in the way it was
defined (no overflow checking or undefined behavior), but
the programmer should have the possibility to use overflow
checking. The CPUs and the compilers should be changed to
allow cheap overflow checking (with zero cost when no
overflow happens). This can IMHO only be done when an
overflow raises an exception (or a signal in a language
which does not support exceptions). An approach with an
overflow flag will probably not allow zero overhead when
no overflow occurs.

A new language (or a language variant) has other
possibilities, since there is no backward compatibility.
For my own language I want to use overflow checking.
I use C as implementation language for interpreter and
runtime library and as backend for the compiler. A such
I only can support what C, the C compiler, the OS and
the hardware allows me to do.

If languages like C, C++ and Java start to consider
overflow checking as important, the CPU designers and
compiler writers will be motivated to support it.

  Correct results are the most important thing you want
  from an computer.

Sometimes errors are accepted, just to get maximum
performance. Some people accept errors, because they want
no exception. But this are corner cases, which should
be handled as special.

  Correct results (with overflow checking) should be
  the normal case and everything else should be handled
  as special case (e.g. a pragma to ignore overflow).


Greetings Thomas Mertes

--
Seed7 Homepage:  http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows.

>> Some software relies on overflows NOT triggering
>> anything - encryption software, for example.
>>
>> I think an interrupt every time THAT overflows
>> would have performance implications ;-)

I think there would be more than performance implications:  there
isn't any easy way, and certainly not portable way, to tell
specifically where the overflow happened so it can be ignored.
Aborting the program certainly will have (infinite) performance
implications.

> In C and other languages integer values are used for two
> things:
> 
>  1. Integer arithmetic ( + - * / )
>  2. Bit manipulation (shifts, masks, logical and, logical or)

Bit manipulation may include integer arithmetic also:  consider
checksums.  You can't tell the difference between (1) and (2)
by looking at the machine instructions.

> Bit manipulation works best without overflow detection.
> Your example of encryption software is IMHO a bit
> manipulation. I am interested in integer arithmetic with
> overflow checking.

It is often not possible to tell the difference between intended
bit manipulation and intended integer arithmetic.  (x*2) is sometimes
written as (x << 1), and under some circumstances *needs* an overflow
check.  One good indication that bit manipulation is intended seems
to be the use of an unsigned type in C.

> The programmer should decide, if he wants overflow checking.
> E.g. with a compiler switch, different types or pragmas.

A compiler switch alone would seem to be usually too coarse-grained.
I prefer a special operator/function which evaluates its arguments
with or without overflow checking.  E.g. 
	nooverflowcheck(checksum += buffer[i]);
although this has problems when there are function calls in the
expression.  I prefer that *both* nooverflowcheck() and overflowcheck()
exist, to override more global defaults of pragmas and compiler
options.

I can also see the possibility of an expression which needs over
a dozen pragmas in it.  Pragma may also be too coarse-grained
in some situations.

> In C unsigned integer types are defined to have no overflow
> checking, while signed integer types have an undefined
> behavior, when an overflow occurs. Gcc and clang have the
> flag -ftrapv, which checks the signed operations +, +, *, /
> and % for overflow.

GCC omits mention that -ftrapv checks signed / or % operations.
Does it really check that?  No mention is made of checking on unary
minus.  Also blatantly missing is any check on overflow during
conversions such as long to short or int to char.  Also, as others
have brought up, recent GCC versions break -ftrapv completely.

> Existing code should continue to work in the way it was
> defined (no overflow checking or undefined behavior), but
> the programmer should have the possibility to use overflow
> checking. 

>The CPUs and the compilers should be changed to
> allow cheap overflow checking (with zero cost when no
> overflow happens). 

I don't believe this (zero cost on no overflow) is possible.
Conventional wisdom says that conditional branches are
oh-so-horribly-expensive on modern CPUs.  I expect that conditional
traps are approximately equally expensive.  I expect a cost in the
pipeline even for a predicted-trap-not-taken actual trap-not-taken
overflow check, even if it's just failure to pipeline one more
instruction.

Also, you need a way to distinguish between overflow-trapping and
non-overflow-trapping instructions.  That seems to have several
possibilities:

(1) Use a check/don't check bit in the instruction.  Since
instruction-set designers try to use most of the bit combinations
effectively, this means pushing other instructions into a longer
format or out of the instruction set entirely.  Some code is going
to get longer.  Here you're hiding the cost in the instruction set
design.

(2) Use a status bit to control checking.  This implies that the
compiler has to insert instructions to turn the bit on and off, and
there's a need for saving and restoring the state of that bit.
Those instructions take memory and have a cost, even if it's the
opportunity cost of not being able to pipeline another instruction.

If there's a spare bit in an existing status register, this might
not require additional instructions in the instruction set, making
use of existing instructions to set and clear bits in the status
register, and save and restore it.  Existing interrupt handler
code may not need to be changed.

(3) Explicitly check for overflow.  This could be ftrapv, or a
conditional branch or call to a routine that raises a signal.  Note
that the conditional branch method loses information on exactly
where the overflow happened.  These instructions take memory and
time.


>This can IMHO only be done when an
> overflow raises an exception (or a signal in a language
> which does not support exceptions). An approach with an
> overflow flag will probably not allow zero overhead when
> no overflow occurs.

I'm not sure I believe in "zero overhead overflow checking".

> A new language (or a language variant) has other
> possibilities, since there is no backward compatibility.
> For my own language I want to use overflow checking.
> I use C as implementation language for interpreter and
> runtime library and as backend for the compiler. A such
> I only can support what C, the C compiler, the OS and
> the hardware allows me to do.

I think using longjmp out of a signal handler, currently undefined
behavior, could be made defined with restrictions for the overflow
signal.

> If languages like C, C++ and Java start to consider
> overflow checking as important, the CPU designers and
> compiler writers will be motivated to support it.
> 
>  Correct results are the most important thing you want
>  from an computer.

This depends on the application.  Rolling over and dying is
not always acceptable, *especially* in certain safety-critical
applications like flight control.  "scramming" a nuclear reactor
to shut it down is acceptable, but shutting down the cooling
system is not.  Shutting down an ISP's primary nameserver because
one query overflowed a statistics counter, or even something
important to the query, is not acceptable (but failing a single
query is).

> Sometimes errors are accepted, just to get maximum
> performance. Some people accept errors, because they want
> no exception. But this are corner cases, which should
> be handled as special.
 
>  Correct results (with overflow checking) should be
>  the normal case and everything else should be handled
>  as special case (e.g. a pragma to ignore overflow).

On Tue, 19 Jul 2011 20:56:26 -0400, Arne Vajh�j <arne@vajhoej.dk>
wrote:

[snip]

>How many mainstream languages do you know that detect integer
>overflow?

     Visual Basic 6 managed.  In fact, it could be turned off if you
wanted but defaulted to on.

     I do not care how many languages have a certain flaw.  If it is a
flaw, it is a flaw.

Sincerely,

Gene Wirchenko

On 7/20/2011 5:36 PM, Gene Wirchenko wrote:
> On Tue, 19 Jul 2011 20:56:26 -0400, Arne Vajh�j<arne@vajhoej.dk>
> wrote:

[snip back]
 >>> That being said, I personally think it must be one of the most epic
 >>> design errors in software-history, to DELIBERATELY design a
 >>> programming-language this way.
 >>> To me its like... WHAT THE H*** WERE THEY THINKING?
 >>>
 >>> The same as most other language designers.
[/snip back]

>> How many mainstream languages do you know that detect integer
>> overflow?
>
>       Visual Basic 6 managed.  In fact, it could be turned off if you
> wanted but defaulted to on.
>
>       I do not care how many languages have a certain flaw.  If it is a
> flaw, it is a flaw.

Irrelevant in the context.

Why don't you read what you are commenting on????

Arne

On 7/20/2011 6:36 AM, Arved Sandstrom wrote:
> On 11-07-19 10:31 PM, Arne Vajh�j wrote:
>> On 7/19/2011 9:07 PM, markspace wrote:
>>> On 7/19/2011 5:54 PM, Arne Vajh�j wrote:
>>>>> On Jul 8, 10:27 am, Gene Wirchenko<ge...@ocis.net>  wrote:
>>>>>> Java is designed to behave that way. That does not mean that it
>>>>>> is not wrong.
>>>
>>>   >  On 7/8/2011 4:15 PM, lewbloch wrote:
>>>>>
>>>>> It doesn't mean that it is wrong.
>>>>>
>>>
>>>> Yes, but given that there are already two languages under discussion,
>>>> then it seems rather obvious that his point is that Java should have
>>>> been designed different 16 years ago not change overflow handling
>>>> in Java 8.
>>>
>>>
>>> I think the point being made is that it's behavior that could be
>>> improved *now*.
>>>
>>> The prescience required to see 16 years into the future is darn hard. I
>>> don't think anyone at all has that kind of skill or knowledge. It would
>>> have been better however to acknowledge sometime in the past that Java
>>> needed to be improved in some fundamental ways and then make those
>>> changes.
>>>
>>> Generics should have been reifiable, primitives should be "first class
>>> objects," integer math should be checked for overflow where the
>>> programmer deems needed. These things have been lacking for some time,
>>> and are still needed, imo.
>>
>> Today it is a must that changes must not break existing code.
>>
>> That still leaves some room for improvements.
>>
>> But it tend to become messy.
>>
>> Sometimes we just need to realize that a wrong decision was
>> made, that we are stuck with it and that it should be done
>> correctly in the next language.

> Changes, even backwards-incompatible changes, to version X of a language
> do not break existing code *unless* users of that existing code make a
> conscious choice to operate that code in the new environment. I am not
> convinced there is a strong need to do that.
>
> As an example, and I'm sure I'm not alone in this, I routinely maintain
> applications in 2011 that are J2EE 1.4 or Java EE 5. No shortage of them
> are J2EE 1.4. Some colleagues who maintain other big web apps I am
> familiar with have to deal with Struts 1. The penetration of Java EE 6
> applications and Java EE 6 servers into the local big business and
> government scene is paltry.
>
> In terms of the associated Java versions, it's true that many folks use
> Java 5 or 6 (frequently 1.6 latest update) even if they are developing
> for a J2EE 1.4 server, but in my experience there has rarely been a
> compelling need for it. To put it another way, I have little time for
> someone who argues that they just absolutely need a cool Java 6 language
> feature but they can't be bothered to upgrade from J2EE 1.4.
>
> Looking at the Oracle support roadmaps for J2SE/Java SE, fact is that
> J2SE 1.4, and Java 5/6, will have some form of adequate support for a
> long time yet (http://www.oracle.com/technetwork/java/eol-135779.html).
> If Java 8, for example, decided to make some backwards-incompatible
> changes to the language, people with existing code bases would have
> sufficient options with Java 7 or earlier to keep them happy for a long,
> long time. I simply do not see the validity of an argument that says
> that the existence of an incompatible Java 8 or 9 is going to affect any
> of these people. As it is, I expect not to be primarily working with
> Java EE 6 and JDK 7 until 2015 at the earliest...and that may be
> optimistic for the Java EE side of things.

It is true that migrating code to new EE and SE versions are usually
a lot behind.

But eventually the code get lifted.

Typical because the vendors stop support for the platform.

And changes that does not create runtime exceptions or compile
time warnings, but silently changes the semantics are about as
bad as they get.

The fact that it may take many years before the problems are felt does
not make the problem smaller.

> As far as "next" languages go, we've already been getting them on the
> JVM: Scala and Clojure for example. Or you just abandon the JVM
> entirely. Holding back from certain language changes just so someone can
> compile a codebase written against Java 5 on a Java 9 compiler, and have
> it work, is holding back the entire language. Ironically, the
> conservative users that we are pandering to with this approach wouldn't
> be in any hurry to use the latest JDK anyway...if ever.

Why not?

Not wanting to spend 6 or 7 digit dollar amounts verifying that
code still works as original intended does not imply that you may
not want new features.

It just put (harsh) restrictions on how the new features can
be implemented.

Arne

On 7/15/2011 11:09 AM, lewbloch wrote:
> Patricia Shanahan wrote:
>> MikeP wrote:
>>> Patricia Shanahan wrote:
> ...
>>>> Write the application in Ada.
>>
>>>> Patricia
>>
>>> But C# is very Java-like and has "checked" and also the compiler-level
>>> equivalent, so C# would be the better alternative. (And yes, I do know
>>> you were just kidding about Ada).
>>
>> No, I was not really joking, though I did not attempt to find all the
>> languages that would meet the stated requirement.
>>
>
> Others did not think you were joking.  I've known people who use Ada
> professionally and not one complained about the language.  I've only
> ever encountered disparagement of Ada from people who don't use it.
>
> I've never worked with Ada, so I defer to those who have.

Ada is a very nice language.

Or maybe I should say that Ada83 was a very nice language.

Ada95 extended a procedural language to be object oriented. And
I don't think the result is so nice.

It is obviously a very powerful language.

But it is also a very difficult language to learn and master.

Arne

On 7/16/2011 12:29 AM, MikeP wrote:
> Patricia Shanahan wrote:
>> and then complain when there is a
>> mismatch between that language's features and their current
>> requirements.
>
> In another post, I said that I think that today (like in right now) the
> awareness of the overflow issue (language support) has achieved critical
> mass. Combine that with the alternatives that are available and more yet
> to come, a language cannot afford to go the path of, say, C anymore for
> it will lose relevance much more quickly. It's not complaining. It's
> customer feedback (companies BEG their customers for such!). Companies
> that don't recognize their customers needs and change with the times, go
> out of business. Java is not C and can't afford to stagnate like C did
> (OK, C++ gave it a "reconditioning"), or it won't last.

It seems highly unlikely that the lack of overflow detection
will have any impact on the usage of Java.

The typical business app does not care.

Arne

On 7/16/2011 12:29 AM, MikeP wrote:
> C# will fit in a lot of places where Java does (or so I assume given what
> I know about them, as I'm don't use either language other than for
> evaluation and case study). Pushing away programmers to other languages
> instead of evolving the language according to the expectations (i.e.,
> what programmers have come to expect to be standard feature in a given
> class of language) is surely a path to obsolescence.

C# is now 9 years old and Java has not disappeared - it has
not even shrunk in usage.

C# seems to be taking most of its users from C++ and VB*.

Arne

On 7/16/2011 8:39 AM, John B. Matthews wrote:
> In article<ivr43p$7cq$1@dont-email.me>, "MikeP"<mp011011@some.org>
> wrote:
>
>> Patricia Shanahan wrote:
> [...]
>>> No, I was not really joking, though I did not attempt to find all
>>> the languages that would meet the stated requirement.
>>
>> Don't look now, but if you weren't joking, then you recommended Ada
>> to a Java programmer! Oh my.
>
> I often suggest Ada to Java programmers; knowledgeable Java programmers
> often return the favor; I've learned a lot that way.

All Java developers should master at least one language from
the Pascal/Modula-2/Ada family.

It gives a different view on many things.

Unfortunately curly bracket languages have almost monopolized
the mindset of aspiring programmers.

Arne

On 11-07-20 08:50 PM, Arne Vajh�j wrote:
> On 7/20/2011 6:36 AM, Arved Sandstrom wrote:
>> On 11-07-19 10:31 PM, Arne Vajh�j wrote:
>>> On 7/19/2011 9:07 PM, markspace wrote:
>>>> On 7/19/2011 5:54 PM, Arne Vajh�j wrote:
>>>>>> On Jul 8, 10:27 am, Gene Wirchenko<ge...@ocis.net>  wrote:
>>>>>>> Java is designed to behave that way. That does not mean that it
>>>>>>> is not wrong.
>>>>
>>>>   >  On 7/8/2011 4:15 PM, lewbloch wrote:
>>>>>>
>>>>>> It doesn't mean that it is wrong.
>>>>>>
>>>>
>>>>> Yes, but given that there are already two languages under discussion,
>>>>> then it seems rather obvious that his point is that Java should have
>>>>> been designed different 16 years ago not change overflow handling
>>>>> in Java 8.
>>>>
>>>>
>>>> I think the point being made is that it's behavior that could be
>>>> improved *now*.
>>>>
>>>> The prescience required to see 16 years into the future is darn hard. I
>>>> don't think anyone at all has that kind of skill or knowledge. It would
>>>> have been better however to acknowledge sometime in the past that Java
>>>> needed to be improved in some fundamental ways and then make those
>>>> changes.
>>>>
>>>> Generics should have been reifiable, primitives should be "first class
>>>> objects," integer math should be checked for overflow where the
>>>> programmer deems needed. These things have been lacking for some time,
>>>> and are still needed, imo.
>>>
>>> Today it is a must that changes must not break existing code.
>>>
>>> That still leaves some room for improvements.
>>>
>>> But it tend to become messy.
>>>
>>> Sometimes we just need to realize that a wrong decision was
>>> made, that we are stuck with it and that it should be done
>>> correctly in the next language.
> 
>> Changes, even backwards-incompatible changes, to version X of a language
>> do not break existing code *unless* users of that existing code make a
>> conscious choice to operate that code in the new environment. I am not
>> convinced there is a strong need to do that.
>>
>> As an example, and I'm sure I'm not alone in this, I routinely maintain
>> applications in 2011 that are J2EE 1.4 or Java EE 5. No shortage of them
>> are J2EE 1.4. Some colleagues who maintain other big web apps I am
>> familiar with have to deal with Struts 1. The penetration of Java EE 6
>> applications and Java EE 6 servers into the local big business and
>> government scene is paltry.
>>
>> In terms of the associated Java versions, it's true that many folks use
>> Java 5 or 6 (frequently 1.6 latest update) even if they are developing
>> for a J2EE 1.4 server, but in my experience there has rarely been a
>> compelling need for it. To put it another way, I have little time for
>> someone who argues that they just absolutely need a cool Java 6 language
>> feature but they can't be bothered to upgrade from J2EE 1.4.
>>
>> Looking at the Oracle support roadmaps for J2SE/Java SE, fact is that
>> J2SE 1.4, and Java 5/6, will have some form of adequate support for a
>> long time yet (http://www.oracle.com/technetwork/java/eol-135779.html).
>> If Java 8, for example, decided to make some backwards-incompatible
>> changes to the language, people with existing code bases would have
>> sufficient options with Java 7 or earlier to keep them happy for a long,
>> long time. I simply do not see the validity of an argument that says
>> that the existence of an incompatible Java 8 or 9 is going to affect any
>> of these people. As it is, I expect not to be primarily working with
>> Java EE 6 and JDK 7 until 2015 at the earliest...and that may be
>> optimistic for the Java EE side of things.
> 
> It is true that migrating code to new EE and SE versions are usually
> a lot behind.
> 
> But eventually the code get lifted.
> 
> Typical because the vendors stop support for the platform.
> 
> And changes that does not create runtime exceptions or compile
> time warnings, but silently changes the semantics are about as
> bad as they get.
> 
> The fact that it may take many years before the problems are felt does
> not make the problem smaller.

I should point out that I'm not talking about arithmetic overflow
checking or any other specific feature here. I am quite unconcerned
about arithmetic overflow checking in Java, because I see at least two
better solutions than changing the language: either (1) using a
different language, or (2) being aware of your quantities and actually
putting some thought into your design to avoid overflow. These have been
suggested already.

I'm talking about backwards-incompatible changes in general. There's no
need to worry about "silent changes to semantics", because by definition
you cannot expect your old source to be compatible with this newest
version. You're told that, and you're told why. You can figure out what
you need to change if you intend to upgrade some codebase, compiler
warnings or no compiler warnings.

Talking about Java specifically, SE or EE, there is a great deal of
advance warning. You're typically going to have close to a decade of
warning that you need to make certain modifications, if a version at
some point introduces backwards incompatibilities. This is more than
enough time. Since changes that _are_ backwards incompatible will almost
certainly be important changes that should have been introduced much
earlier anyway, and everyone's code should use them, and it will help
everyone's code, where's the downside in forcing people to do some
necessary work? People certainly do take advantage of new APIs and
language features that _are_ backwards compatible, and they need to put
in a lot of work to do that, so how is it somehow a bad thing that
they've got to do a bit of work to upgrade a codebase into a new
backwards-incompatible version?

Call me a bit unsympathetic perhaps. I deal almost every day with people
who want to do bleeding edge SOA on J2EE 1.4 app servers, and they
agonize about upgrades that are all over 5 years old themselves. So I
see the problem more that the vendors are too frigging lenient with
support. Mainly because it's a cash cow.

>> As far as "next" languages go, we've already been getting them on the
>> JVM: Scala and Clojure for example. Or you just abandon the JVM
>> entirely. Holding back from certain language changes just so someone can
>> compile a codebase written against Java 5 on a Java 9 compiler, and have
>> it work, is holding back the entire language. Ironically, the
>> conservative users that we are pandering to with this approach wouldn't
>> be in any hurry to use the latest JDK anyway...if ever.
> 
> Why not?

Because I used the word "conservative". IOW, your typical GiantCorp or
government department that wants new functionality all the time but
could care less about the language features or new APIs. The ones that
expect you to implement the latest and greatest ideas with 10-year-old
J2EE APIs because getting them to upgrade to Java EE 5 in the year 2011
is a frightening proposition.

If a company or government IT shop is willing to keep up with the latest
Java SE/EE releases then they are not conservative.

> Not wanting to spend 6 or 7 digit dollar amounts verifying that
> code still works as original intended does not imply that you may
> not want new features.

What percentage of business types do you think care about new language
features and new APIs? 10 percent? 5 percent? One percent? What they
care about is can you develop their latest pet project for them. Since
we devs usually can cobble something together, albeit with difficulty,
even with ancient libraries and old language versions, that's how it
goes in real life.

Let me give you just one example; not so many months ago I had to go
through a lengthy and arduous process with one client, involving much
analysis and multiple meetings, offering assurances all the way up to
Director of IT level, just to bump up an EclipseLink minor version. To
the typical conservative client any upgrade of any library is a Big
Deal. You certainly won't see them clamouring for the speedy adoption of
a new JDK because it offers support for lambdas.

As for code working as originally intended, show me the production
application that is substantively defect-free and works as originally
intended. About the worst that will happen with an upgrade is that the
typical app will break in new ways.

Sometimes these new breakages are beneficial even. I'm minded of when we
moved a complex J2EE app from one old app server over to a newish one
from another vendor. Suddenly dozens of new defects appeared. Turned out
that all of them were real code defects and that the old app server
simply sucked that bad. My feeling is that forced adoption of better VMs
and better servers and better language features, backwards-incompatible
or no, is generally a good thing - it exposes flaws in codebases. They
didn't get _created_, they were already there.

> It just put (harsh) restrictions on how the new features can
> be implemented.
> 
> Arne

Yeah. The harshness resides in forcing people to rewrite some to make
their code better.

AHS

On 20/07/2011 10:16 PM, Arne Vajhøj wrote:
> All Java developers should master at least one language from
> the Pascal/Modula-2/Ada family.
>
> It gives a different view on many things.
>
> Unfortunately curly bracket languages have almost monopolized
> the mindset of aspiring programmers.

s/those three shitty languages/Lisp and I'll agree with you. :)

On Jul 20, 7:09=A0pm, Arne Vajh=F8j <a...@vajhoej.dk> wrote:
> On 7/16/2011 12:29 AM, MikeP wrote:
>
> > Patricia Shanahan wrote:
> >> and then complain when there is a
> >> mismatch between that language's features and their current
> >> requirements.
>
> > In another post, I said that I think that today (like in right now) the
> > awareness of the overflow issue (language support) has achieved critica=
l
> > mass. Combine that with the alternatives that are available and more ye=
t
> > to come, a language cannot afford to go the path of, say, C anymore for
> > it will lose relevance much more quickly. It's not complaining. It's
> > customer feedback (companies BEG their customers for such!). Companies
> > that don't recognize their customers needs and change with the times, g=
o
> > out of business. Java is not C and can't afford to stagnate like C did
> > (OK, C++ gave it a "reconditioning"), or it won't last.
>
> It seems highly unlikely that the lack of overflow detection
> will have any impact on the usage of Java.
>
> The typical business app does not care.

C has not lost all relevance, nor stagnated, despite "MikeP"'s
unsubstantiated claims.

Many places and applications use C still.

--
Lew

On 11-07-15 11:00 AM, Patricia Shanahan wrote:
> On 7/14/2011 10:14 PM, MikeP wrote:
>> Patricia Shanahan wrote:
>>> On 7/6/2011 8:35 AM, rop rop wrote:
>>>> Hi,
>>>>
>>>> If I want to have arithmetic-overflow checking in all parts of an
>>>> application,
>>>> what is the most practical, simple, efficient way to achieve this?
>>>
>>> Write the application in Ada.
>>>
>>> Patricia
>>
>> But C# is very Java-like and has "checked" and also the compiler-level
>> equivalent, so C# would be the better alternative. (And yes, I do know
>> you were just kidding about Ada).
>>
>>
> 
> No, I was not really joking, though I did not attempt to find all the
> languages that would meet the stated requirement.
> 
> I'm very strongly of the opinion different languages should provide
> different features, making different trade-offs, and programmers should
> pick the language for a job based on its requirements and those features.
> 
> The alternative a lot of programmers follow seems to be to pick one
> language, ignore all the others, and then complain when there is a
> mismatch between that language's features and their current requirements.
> 
> I have no problem with pushing minor changes and additional features
> within the general framework of a language, but if the basic framework
> is not a good match for a job, the solution is to pick a language that
> is more suitable.
> 
> Patricia

I agree 100 percent.

I'll add this observation: this state of affairs is largely a result of
the mediocrity of most programmers. The pressure to conform to a very
few mainstream languages - and there is real pressure to this effect,
unless you are dabbling, or are in some odd niche - may come from
managers, from business, from customers, or from developers themselves -
ultimately stems from this pervasive mediocrity. And this state of
affairs will not change so long as software development remains
unprofessional.

How many languages should be in a programmer's toolkit? Well, at least
half a dozen. Preferably a dozen. These would be languages that cover
the entire spectrum, and that the programmer is at least competent in.

To add insult to injury you don't even often see most mainstream
programmers taking advantage of the realistic constrained possibilities
offered by real-world working environments. For example, developers who
usually will find themselves working with .NET on the CLR, or Java SE/EE
on the JVM. The C# programmers don't often consider that maybe judicious
interop with some F# code will be a better solution, or that they could
contemplate IronRuby on the DLR, and you don't often see enterprise Java
programmers (or their bosses) willing to think of using some Scala or
Clojure or Groovy. And the practise of taking advantage of one's larger
platform, and writing shell or Powershell scripts (or Python or whatever
programs) to handle other tasks connected with a larger project in Java,
is both frowned upon and rare.

The blanket excuse used to justify all this is standardization of
skillsets. Although candid hirers and managers will tell you that this
is mandated by widespread mediocrity. They acknowledge that a very good
programmer does do better if they can choose their tools, but they are
worried about the ability of 90 percent of the developers out there to
maintain and extend the code that the good programmers write.

This is the real world, and it'll take a long time to change it.

AHS

On 11-07-20 11:09 PM, Arne Vajh�j wrote:
> On 7/16/2011 12:29 AM, MikeP wrote:
>> Patricia Shanahan wrote:
>>> and then complain when there is a
>>> mismatch between that language's features and their current
>>> requirements.
>>
>> In another post, I said that I think that today (like in right now) the
>> awareness of the overflow issue (language support) has achieved critical
>> mass. Combine that with the alternatives that are available and more yet
>> to come, a language cannot afford to go the path of, say, C anymore for
>> it will lose relevance much more quickly. It's not complaining. It's
>> customer feedback (companies BEG their customers for such!). Companies
>> that don't recognize their customers needs and change with the times, go
>> out of business. Java is not C and can't afford to stagnate like C did
>> (OK, C++ gave it a "reconditioning"), or it won't last.
> 
> It seems highly unlikely that the lack of overflow detection
> will have any impact on the usage of Java.
> 
> The typical business app does not care.
> 
> Arne
> 
I agree, with caveats. The larger issue is the proper treatment of
numerical quantities in business applications. Leaving aside currency,
which there is _some_ awareness of in terms of appropriate things to do,
the expression of other numerical quantities in Java is typified by the
use of unconstrained primitives, with haphazard and inconsistent bounds
checking scattered over the code. Maybe it's just me, but wouldn't a
better approach to a numerical data type be to write its own class,
which is responsible for its own invariants (*) (**)? Hang the minor to
moderate performance implications: what's more important, correct code
or fast code?

My questions to a Java programmer who wants (or thinks they want)
overflow detection would include: are you using the correct primitive
type (or wrapper for a primitive)? Do you even know the design ranges
for your quantity? Why are you wanting to rely on overflow detection to
save your program when 99 percent of the possible legal values for your
chosen data type are also wrong for the design problem, and you're
obviously not concerned about that at all? Why don't you write a proper
class for your data type?

AHS

* Own class in an OOP language, that is.
** An acceptable approach in some circumstances is rules engines. I have
not seen these widely adopted or even often considered.

On 21/07/2011 6:05 AM, Arved Sandstrom wrote:
> I agree, with caveats. The larger issue is the proper treatment of
> numerical quantities in business applications. Leaving aside currency,
> which there is _some_ awareness of in terms of appropriate things to do,
> the expression of other numerical quantities in Java is typified by the
> use of unconstrained primitives, with haphazard and inconsistent bounds
> checking scattered over the code. Maybe it's just me, but wouldn't a
> better approach to a numerical data type be to write its own class,
> which is responsible for its own invariants (*) (**)? ... Why don't you
> write a proper class for your data type?

In four words: Lack of operator overloading.

Math on non-primitive types is *painful* in Java.

On 20/07/2011 17:51, lewbloch wrote:
> RedGrittyBrick<RedGrittyBr...@spamweary.invalid>  wrote:
>> Arved Sandstrom wrote:
>>> Holding back from certain language changes just so someone can
>>> compile a codebase written against Java 5 on a Java 9 compiler, and have
>>> it work, is holding back the entire language.
>>
>> Why is this a problem?
>>
>> Firstly, you can use `javac -source 1.3` to compile old code, can't you?
>>
>
> No.  Not if you want some of the new features.  [...]
>
> You also have to make sure that all your third-party libraries for
> that build conform to the older spec.
>
> Targeting an old version is an all-or-nothing proposition.
>

All good points but I feel your "No." is more like a "Yes, but".

If everyone at Oracle went mad and Java 1.9 changed the language spec so 
that integer arithmetic could throw an IntegerOverflowException, 
presumably they could arrange things in the compiler (and JVM) so that 
the `-source 1.5` option would compile the code such that integer 
operations would never throw an IntegerOverflowException thus satisfying 
Arved's objection - couldn't they?

>> Secondly, a future version of Java could introduce some mechanism such
>> as in-line compiler directives that turn new
>> compiler-behaviours/language-features on for specified classes or for
>> specified sections of code (I'm thinking of Perl's `use feature` pragma
>> but I'm sure this sort of idea exists in other languages).
>>
>
> It'll come down to someone's perception of how valuable that feature
> is against the cost.

Sure (assuming you're talking about the cost of adding that feature to 
javac and JVM etc), I'm speaking hypothetically.

    @IntegerOverflowExceptions(true)
    int c = a + b;
    @IntegerOverflowExceptions(false)

It looks horrid to me, and presumably there's lots of issues to 
overcome, better syntax to achieve the same ends, but essentially, if 
Sunacle felt it worthwhile, something could be done to introduce new 
behaviours whilst making them optional for existing code that those 
behaviours would break?

Whilst I personally (think I) have no need for arithmetic overflow 
checking of this sort, I imagine some clever language designers could 
provide for it in a way that didn't break existing crypto libraries that 
rely on such overflows being ignored.

Perhaps I'm wrong, but people seem to be saying "you just can't do this 
because it would break existing code" - I haven't grasped why those 
people are sure this is the case.

Despite the above, I'm in favour of keeping the language relatively simple.

-- 
RGB

"tm" <thomas.mertes@gmx.at> wrote in message
news:65991dc2-9acf-4867-b54a-8569b9683320@l37g2000yqd.googlegroups.com...

>  Correct results are the most important thing you want
>  from an computer.

> Sometimes errors are accepted, just to get maximum
> performance.

Or sometimes people can assume there will be no error because they know the
program.

If you are using C to implement another language, especially a 'softer'
language where the user expects the language to hold his hand a lot more,
then that is a bit of a special case.

Here, problems such as trapping bounds-errors and overflows can be solved by
the /implementer/ writing the appropriate C code, taking advantage of any
built-in facilities for these, but not depending on them.

If a badly handled bounds or overflow error occurs in the (user's) program,
then that is the responsibility of the implementer; you can't blame the
short-comings of C for that.

People writing directly in C (who are not using C to implement another
system) can't easily and elegantly make use of things such as overflow
checks and array bounds checking.

With an implementer however, clunky code may not be an issue (since the code
will only appear in one place, or will be in generated code that no-one will
ever see).

(And what if the language being implemented has a range type, such as Int:
1000 .. 2000; you would surely need to check overflow *and* underflow, and
you can't expect C, the OS or the hardware to give you much help here.

Even more so if you have a type such as (2,4,6,10), ie. only containing
those values. In this case, these checks need to be built on top of C (or
whatever implementation language is used); and the same can surely be done
for anything else.)

-- 
Bartc 

On Wed, 20 Jul 2011 22:16:11 -0400, Arne Vajhøj wrote:

> On 7/16/2011 8:39 AM, John B. Matthews wrote:
>> In article<ivr43p$7cq$1@dont-email.me>, "MikeP"<mp011011@some.org>
>> wrote:
>>
>>> Patricia Shanahan wrote:
>> [...]
>>>> No, I was not really joking, though I did not attempt to find all the
>>>> languages that would meet the stated requirement.
>>>
>>> Don't look now, but if you weren't joking, then you recommended Ada to
>>> a Java programmer! Oh my.
>>
>> I often suggest Ada to Java programmers; knowledgeable Java programmers
>> often return the favor; I've learned a lot that way.
> 
> All Java developers should master at least one language from the
> Pascal/Modula-2/Ada family.
>
Add Algol 68 to that list. Compilers and runtimes are available and free.

I knew Algol 60 and a smattering of Pascal when I learnt it. 

A68 was a huge eye-opener in terms of expressiveness and its ability to 
handle variable record structures that I thought could only be 
successfully handled in assembler: this was in pre-C days. For George 3 
hands, these were G3 job accounting records. Others should think ASN.1


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

supercalifragilisticexpialadiamaticonormalizeringelimatisticantations <supercalifragilisticexpialadiamaticonormalizeringelimatisticantations@averylongandannoyingdomainname.com> wrote:
> On 21/07/2011 6:05 AM, Arved Sandstrom wrote:
>> ... Why don't you write a proper class for your data type?
> In four words: Lack of operator overloading.
> Math on non-primitive types is *painful* in Java.

agreeCount = agreeCount.plus(AgreeCount.ONE)
    on painfulness of non-primitive math.

On Thu, 21 Jul 2011 12:11:55 +0100, RedGrittyBrick wrote:

> Sure (assuming you're talking about the cost of adding that feature to
> javac and JVM etc), I'm speaking hypothetically.
> 
>     @IntegerOverflowExceptions(true)
>     int c = a + b;
>     @IntegerOverflowExceptions(false)
> 
> It looks horrid to me, and presumably there's lots of issues to
> overcome, better syntax to achieve the same ends, but essentially, if
> Sunacle felt it worthwhile, something could be done to introduce new
> behaviours whilst making them optional for existing code that those
> behaviours would break?
>
Agreed, but there's another way to handle this in Java that would 
probably cater for most overflow and out of range requirements without 
affecting existing programs or the language at all:

Just add range checking constructors to Integer and friends, e.g:

	Integer boundedValue = new Integer(0,1,10);

to declare an Integer, initialised to zero and with the range 1:10. The 
overheads would be minimal if the checks were only enabled if limits were 
added. It could either throw an unchecked exception or provide a range 
checking method: 

	 if (!boundedValue.isInRange()) {...}  

to check the current value or the possibly more useful:

	 if (boundedValue.setChecked( ( a + b ) / c )) {...}


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

On 20/07/2011 10:25 PM, Henderson wrote:
> On 20/07/2011 10:16 PM, Arne Vajhøj wrote:
>> All Java developers should master at least one language from
>> the Pascal/Modula-2/Ada family.
>>
>> It gives a different view on many things.
>>
>> Unfortunately curly bracket languages have almost monopolized
>> the mindset of aspiring programmers.
>
> s/those three shitty languages/Lisp and I'll agree with you. :)
>

That raises a non-smiley point; if you want to expand programmers' minds 
about alternate language possibilities, it seems to me that learning 
Prolog (logic programming) and Haskell (functional programming) would do 
a lot more than another procedural language. I seem to recall at least 
one comment about some XML-related Java package that it was bogus 
because it required people to understand functional programming; that 
comment made me sad.

On Wed, 20 Jul 2011 23:21:53 -0300, Arved Sandstrom wrote:

> Talking about Java specifically, SE or EE, there is a great deal of
> advance warning. You're typically going to have close to a decade of
> warning that you need to make certain modifications, if a version at
> some point introduces backwards incompatibilities. This is more than
> enough time.
>
Arguably, the delay in removing deprecated features (which amounts to the 
same thing) is a waste of time: Y2K showed us that, with absolutely 
nothing being done ahead of time in most shops, the result was the 
expensive last minute panic.

In fact, you can make the opposite argument: delay too long and there 
will be nobody left who remembers which programs might be affected or 
even that there is a problem. 


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

On Jul 21, 8:43=A0am, Martin Gregorie <mar...@address-in-sig.invalid>
wrote:
....
> Agreed, but there's another way to handle this in Java that would
> probably cater for most overflow and out of range requirements without
> affecting existing programs or the language at all:
>
> Just add range checking constructors to Integer and friends, e.g:
>
> =A0 =A0 =A0 =A0 Integer boundedValue =3D new Integer(0,1,10);
>
> to declare an Integer, initialised to zero and with the range 1:10. The
> overheads would be minimal if the checks were only enabled if limits were
> added. It could either throw an unchecked exception or provide a range
> checking method:
>

How would this help given that Integers can't change anyway? It can
only check that the initialization value is in range.  You'd have to
somehow make these Integers 'sticky' in some way so that any
expression using one of them is also subject to bounds checking.

E.g.,
   Integer firstValue =3D new Integer(Integer.MAX_VALUE, 0,
                             Integer.MAX_VALUE);
   Integer nextValue =3D new Integer(firstValue+Integer.MAX_VALUE+3,
       0, 10);

clearly overflows, but it would work fine unless something significant
were added to the language.

    Regards,
    Tom McGlynn

RedGrittyBrick wrote:
> lewbloch wrote:
>> RedGrittyBrick=A0wrote:
>>> Arved Sandstrom wrote:
>>>> Holding back from certain language changes just so someone can
>>>> compile a codebase written against Java 5 on a Java 9 compiler, and ha=
ve
>>>> it work, is holding back the entire language.
>
>>> Why is this a problem?
>
>>> Firstly, you can use `javac -source 1.3` to compile old code, can't you=
?
>
>> No. =A0Not if you want some of the new features. =A0[...]
>
>> You also have to make sure that all your third-party libraries for
>> that build conform to the older spec.
>
>> Targeting an old version is an all-or-nothing proposition.
>
> All good points but I feel your "No." is more like a "Yes, but".
>

It's a fair cop.

> If everyone at Oracle went mad and Java 1.9 changed the language spec so
> that integer arithmetic could throw an IntegerOverflowException,
> presumably they could arrange things in the compiler (and JVM) so that
> the `-source 1.5` option would compile the code such that integer
> operations would never throw an IntegerOverflowException thus satisfying
> Arved's objection - couldn't they?
>

Sure.  I present the obstacles not as stoppers but as things for which
the designer(s) of such a change must be responsible.

>>> Secondly, a future version of Java could introduce some mechanism such
>>> as in-line compiler directives that turn new
>>> compiler-behaviours/language-features on for specified classes or for
>>> specified sections of code (I'm thinking of Perl's `use feature` pragma
>>> but I'm sure this sort of idea exists in other languages).
>

Yes, and they would have to.  The issue is with the statement that
"Java should have feature /X/" without any concept of the challenges
that must be addressed.

If the challenges are too expensive to overcome, or lack sufficient
widespread utility, or are too foreign to the ethos of the language,
then it might be best to reject the feature even if there does exist a
good use case for it somewhere.

Patricia and Arved, among others, have made the point that focusing on
changes to Java when there are suitable alternative languages (that
even run on the JVM!) is not always optimal.  Why change Java if
Javascript or Ruby or Scala can do the job for you right now?

And what about the suggestion to write a CheckedInteger type that does
what you need?  You can get what you need without waiting for some
potential future revolution in Java, and without leaving the
comforting security of your favorite language.

>> It'll come down to someone's perception of how valuable that feature
>> is against the cost.
>

> Sure (assuming you're talking about the cost of adding that feature to
> javac and JVM etc), I'm speaking hypothetically.
>
> =A0 =A0 @IntegerOverflowExceptions(true)
> =A0 =A0 int c =3D a + b;
> =A0 =A0 @IntegerOverflowExceptions(false)
>
> It looks horrid to me, and presumably there's lots of issues to
> overcome, better syntax to achieve the same ends, but essentially, if
> Sunacle felt it worthwhile, something could be done to introduce new
> behaviours whilst making them optional for existing code that those
> behaviours would break?
>
> Whilst I personally (think I) have no need for arithmetic overflow
> checking of this sort, I imagine some clever language designers could
> provide for it in a way that didn't break existing crypto libraries that
> rely on such overflows being ignored.
>
> Perhaps I'm wrong, but people seem to be saying "you just can't do this
> because it would break existing code" - I haven't grasped why those
> people are sure this is the case.
>

That's not my claim.  My claim is that you just can't do this
irresponsibly lest you break existing code.  I also believe that
others' suggestions in this thread can solve the problem immediately
without requiring Draconian and slow-to-arrive changes in the
language.

> Despite the above, I'm in favour of keeping the language relatively simpl=
e.
>

That's especially valid given that the language supports the desired
functionality as long as you're willing to be a programmer and write
the necessary code.  I especially endorse Arved's comment:

> Why are you wanting to rely on overflow detection to
> save your program when 99 percent of the possible legal values for your
> chosen data type are also wrong for the design problem, and you're
> obviously not concerned about that at all? Why don't you write a proper
> class for your data type?

--
Lew

On Jul 21, 5:50=A0am, David Lamb <dal...@cs.queensu.ca> wrote:
> On 20/07/2011 10:25 PM, Henderson wrote:
>
> > On 20/07/2011 10:16 PM, Arne Vajh=F8j wrote:
> >> All Java developers should master at least one language from
> >> the Pascal/Modula-2/Ada family.
>
> >> It gives a different view on many things.
>
> >> Unfortunately curly bracket languages have almost monopolized
> >> the mindset of aspiring programmers.
>
> > s/those three shitty languages/Lisp and I'll agree with you. :)
>
> That raises a non-smiley point; if you want to expand programmers' minds
> about alternate language possibilities, it seems to me that learning
> Prolog (logic programming) and Haskell (functional programming) would do
> a lot more than another procedural language. I seem to recall at least
> one comment about some XML-related Java package that it was bogus
> because it required people to understand functional programming; that
> comment made me sad.

+1

--
Lew

lewbloch <lewbloch@gmail.com> wrote:
> And what about the suggestion to write a CheckedInteger type that does
> what you need?

That has been answered already, but you may have missed it, or maybe 
blocked the one who answered this seriously and (imho) agreeably.

Due to Java's lack of operator overloading, doing Math with
non-primitive types is just painful.

PS: my approach would be a new keyword like strictfp (which may modify
  floating point semantics compared to not-applying it),
  just one for modifying integral semantics:  arithmetic overflow checks
  and runtime checks on cast to narrower types.  Just like use of
  "strictfp" can be expected to slow down programs, the same would be
  acceptable for an integral pendant.

On Jul 21, 8:38=A0am, Andreas Leitgeb <a...@gamma.logic.tuwien.ac.at>
wrote:
> lewbloch <lewbl...@gmail.com> wrote:
> > And what about the suggestion to write a CheckedInteger type that does
> > what you need?
>
> That has been answered already, but you may have missed it, or maybe
> blocked the one who answered this seriously and (imho) agreeably.
>
> Due to Java's lack of operator overloading, doing Math with
> non-primitive types is just painful.
>

I saw that suggestion, but painful !=3D impossible.  And how freaking
"painful" is it to read method calls anyway?  "Painful" is digging
ditches, tarring roofs, smelting steel, even working the floor at your
neighborhood mall anchor store.  All a programmer has to do is read
method calls and do some typing.  People need to get over themselves.

So for those who "can't" do range checking because "method calls are
too 'painful'" - Shut The Front Door, whiner!

Jesus H. Tap-dancing Christ!

Or get out of programming and get a real job.

Do keep agitating for a better way.  Just don't cavil that there's no
way to do it now, because there is.

Amazing.  Yeesh.

--
Lew

On 7/21/2011 9:03 AM, lewbloch wrote:
> On Jul 21, 8:38 am, Andreas Leitgeb<a...@gamma.logic.tuwien.ac.at>
> wrote:
>> lewbloch<lewbl...@gmail.com>  wrote:
>>> And what about the suggestion to write a CheckedInteger type that does
>>> what you need?
>>
>> That has been answered already, but you may have missed it, or maybe
>> blocked the one who answered this seriously and (imho) agreeably.
>>
>> Due to Java's lack of operator overloading, doing Math with
>> non-primitive types is just painful.
>>
>
> I saw that suggestion, but painful != impossible.  And how freaking
> "painful" is it to read method calls anyway?  "Painful" is digging
> ditches, tarring roofs, smelting steel, even working the floor at your
> neighborhood mall anchor store.  All a programmer has to do is read
> method calls and do some typing.  People need to get over themselves.

No, painful is realizing that your attempts to make something work all 
fail because you need to put together two libraries that need different 
versions of the same library. Next step, writing a script to extract the 
necessary symbols from library v2 but not in v1, dump those out as 
assembly, and copy them over.

I'd love to have the pain that comes with "I need to write out `+' as 
`plus'" right now.

-- 
Beware of bugs in the above code; I have only proved it correct, not 
tried it. -- Donald E. Knuth

On 21/07/2011 8:52 AM, Martin Gregorie wrote:
> Arguably, the delay in removing deprecated features (which amounts to the
> same thing) is a waste of time: Y2K showed us that, with absolutely
> nothing being done ahead of time in most shops, the result was the
> expensive last minute panic.
>
> In fact, you can make the opposite argument: delay too long and there
> will be nobody left who remembers which programs might be affected or
> even that there is a problem.

One problem with removing deprecated features, at least from Snoracle's 
standpoint, is that organizations will be even more reluctant to update 
Java if doing so might require extensive modifications to all their 
stuff's source code.

On 7/21/2011 5:41 AM, Arved Sandstrom wrote:
> On 11-07-15 11:00 AM, Patricia Shanahan wrote:
>> On 7/14/2011 10:14 PM, MikeP wrote:
>>> Patricia Shanahan wrote:
>>>> On 7/6/2011 8:35 AM, rop rop wrote:
>>>>> If I want to have arithmetic-overflow checking in all parts of an
>>>>> application,
>>>>> what is the most practical, simple, efficient way to achieve this?
>>>>
>>>> Write the application in Ada.
>>>>
>>>> Patricia
>>>
>>> But C# is very Java-like and has "checked" and also the compiler-level
>>> equivalent, so C# would be the better alternative. (And yes, I do know
>>> you were just kidding about Ada).
>>
>> No, I was not really joking, though I did not attempt to find all the
>> languages that would meet the stated requirement.
>>
>> I'm very strongly of the opinion different languages should provide
>> different features, making different trade-offs, and programmers should
>> pick the language for a job based on its requirements and those features.
>>
>> The alternative a lot of programmers follow seems to be to pick one
>> language, ignore all the others, and then complain when there is a
>> mismatch between that language's features and their current requirements.
>>
>> I have no problem with pushing minor changes and additional features
>> within the general framework of a language, but if the basic framework
>> is not a good match for a job, the solution is to pick a language that
>> is more suitable.
>
> I agree 100 percent.
>
> I'll add this observation: this state of affairs is largely a result of
> the mediocrity of most programmers. The pressure to conform to a very
> few mainstream languages - and there is real pressure to this effect,
> unless you are dabbling, or are in some odd niche - may come from
> managers, from business, from customers, or from developers themselves -
> ultimately stems from this pervasive mediocrity. And this state of
> affairs will not change so long as software development remains
> unprofessional.
>
> How many languages should be in a programmer's toolkit? Well, at least
> half a dozen. Preferably a dozen. These would be languages that cover
> the entire spectrum, and that the programmer is at least competent in.
>
> To add insult to injury you don't even often see most mainstream
> programmers taking advantage of the realistic constrained possibilities
> offered by real-world working environments. For example, developers who
> usually will find themselves working with .NET on the CLR, or Java SE/EE
> on the JVM. The C# programmers don't often consider that maybe judicious
> interop with some F# code will be a better solution, or that they could
> contemplate IronRuby on the DLR, and you don't often see enterprise Java
> programmers (or their bosses) willing to think of using some Scala or
> Clojure or Groovy. And the practise of taking advantage of one's larger
> platform, and writing shell or Powershell scripts (or Python or whatever
> programs) to handle other tasks connected with a larger project in Java,
> is both frowned upon and rare.
>
> The blanket excuse used to justify all this is standardization of
> skillsets. Although candid hirers and managers will tell you that this
> is mandated by widespread mediocrity. They acknowledge that a very good
> programmer does do better if they can choose their tools, but they are
> worried about the ability of 90 percent of the developers out there to
> maintain and extend the code that the good programmers write.
>
> This is the real world, and it'll take a long time to change it.

You can hardly blame the managers from making decisions on tools
based on what their developers actually know instead of what they
should know.

mediocre developers => mediocre code

But if we say that there are 10 million developers of which 2 million
is good, 6 million is mediocre and 2 million is hopeless, then just
getting the majority to e good will require 3 million good developers.
They will not show up tomorrow by magic.

Arne

On 7/10/2011 3:22 PM, Martin Gregorie wrote:
> On Sun, 10 Jul 2011 11:29:39 -0700, Patricia Shanahan wrote:
>
>> On 7/10/2011 11:07 AM, Martin Gregorie wrote:
>>> On Sun, 10 Jul 2011 10:53:09 -0400, David Lamb wrote:
>>>
>>>> On 08/07/2011 12:30 AM, Eric Sosman wrote:
>>>>> On 7/7/2011 8:51 PM, Peter Duniho wrote:
>>>>>> [...]
>>>>>> I would not worry about the "simple" or "efficient" criteria. IMHO,
>>>>>> if one is deciding to apply overflow checking to every computation,
>>>>>> one has already abandoned the hope of efficiency.
>>>>>
>>>>> I've used machines that raised overflow traps "for free,"
>>>> ...
>>>>> (The machines I speak of were from forty-odd years ago
>>>>
>>>> When microprocessors started to arrive on the scene, a lot of
>>>> old-timey hardware folks said they'd forgotten 30+ years of hardware
>>>> design. When operating systems for computers based on said processors
>>>> came out, a lot of old-timey software folks said they'd forgotten 30+
>>>> years of operating system design.  We seem to still be suffering the
>>>> consequences.
>>>
>>> That happened not once, but twice.
>>>
>>> The first great leap backward was the minicomputer era, when the likes
>>> of the PDP-8 arrived with a single user, single tasking OS reminiscent
>>> of early computers, except they generally had teletypes instead of
>>> banks of switches and flashing lights. By then the better mainframes
>>> were multi- user, multitasking beasts.
>>>
>>> Then the first microcomputers arrived in the mid/late '70s. By this
>>> time the better minis had multi-tasking operating systems, but micros
>>> had re- implemented the earliest mini OSes - CP/M was near as dammit a
>>> copy of the old PDP-8 OS (RSTS?) from the late 60s - and the earliest
>>> micros even had switches and flashing lights (KIM-1, IMSAI 8080). By
>>> 1980 the minis were running UNIX but the latest and greatest micros had
>>> - drumroll - MS- DOS!
>>>
>>>
>>>
>> Only twice? Aren't you forgetting "smart" phones. One of the great
>> advances in Android is (Drum roll!) multitasking!!!
>>
> They don't count since, unlike minis and micros, their builders didn't
> retreat to the techno-stone age, ignore progress made to date, and build
> primitive OS by rubbing (metaphorical) sticks together.
>
> AFAIK all smartphones started an a more advanced level because they
> inherited better operating systems. IIRC these all originated on
> electronic memo pads such as Psion, HP and Palm Pilot made, and were all
> a lot more advanced than the likes of RSTS, CP/M, Flex09, etc. Leastwise,
> I don't think you can consider Symbian and whatever MS was calling the
> iPAQ OS at that stage any more primitive than the contemporary versions
> of MacOS, OS/2 or even Windows, though admittedly they were rather behind
> UNIX and its distant relations such as OS-9/68K.

If they don't support multi-tasking I would say that they in at least
one aspect is behind the desktop OS'es.

(how important multitasking is on a smartphone is a different
discussion)

Arne

On 7/8/2011 1:23 PM, Gene Wirchenko wrote:
> On Thu, 07 Jul 2011 17:51:06 -0700, Peter Duniho
> <NpOeStPeAdM@NnOwSlPiAnMk.com>  wrote:
>> I would not worry about the "simple" or "efficient" criteria.  IMHO, if
>> one is deciding to apply overflow checking to every computation, one has
>> already abandoned the hope of efficiency.
>
>       Not necessarily.  If a rocket ends up being destroyed as a
> result, having the computing go a bit slower to save having to build
> another rocket would have been more efficient.

I am pretty sure that Peter was talking about the efficiency of
the computer program.

>                                                Unfortunately, this is
> not a made-up example.  See:
>            http://en.wikipedia.org/wiki/Ariane_5_Flight_501
> In the subsequent investigation, the cause of the problem was
> recreated.

It was an integer overflow. But the real problem was a bad software
process. If there had not been an integer overflow there could have
been many other types of problems.

>       Turn on those run-time checks unless speed *REALLY* is of
> paramount importance.  It usually is not.

I would agree with that.

Arne

On 7/17/2011 11:15 AM, Patricia Shanahan wrote:
> On 7/17/2011 6:50 AM, John B. Matthews wrote:
>> In article<ivst52$p8a$1@dont-email.me>, "MikeP"<mp011011@some.org>
>> wrote:
>>> John B. Matthews wrote:
>>>>> I do/did that. (C++ is my poison).
>>>>
>>>> See also: "The science of fanboyism."
>>>> Article:<http://techreport.com/discussions.x/21294>
>>>> Discussion:<http://science.slashdot.org/story/11/07/15/1331243>
>>>
>>> Do you mean because I use C++ I'm now "a fanboy"?
>>
>> I sense you didn't read the article; it suggests that the predilection
>> is pervasive, and not unique to you or C++. As I struggle continually
>> against such bias, I'd welcome your perspective.
>>
>
> I don't like the term "fanboy" because it suggests it is an immature
> male tendency. The research does not support that. I'm definitely a
> fanwoman when it comes to the desirability of programming as a career,
> but have never fallen in love with a programming language.

The liking and disliking of programming languages has some objective
considerations but also some subjective feelings.

It is part of being a professional to act based on the objective
part - how well does the language fit with the task at hand.

But they can still have some personal preferences about what they
think are elegant languages and what is not.

To make a car analogy (!): if you are buying cars to a fleet, then
there are some objective facts like price, space, safety, fuel
economy etc. and the decision should be made on those. But you
may still have a personal preference that the instrumentation
in a Ford is easier to work with and that blue looks better than
other colors.

Arne

On 7/21/2011 8:50 AM, David Lamb wrote:
> On 20/07/2011 10:25 PM, Henderson wrote:
>> On 20/07/2011 10:16 PM, Arne Vajhøj wrote:
>>> All Java developers should master at least one language from
>>> the Pascal/Modula-2/Ada family.
>>>
>>> It gives a different view on many things.
>>>
>>> Unfortunately curly bracket languages have almost monopolized
>>> the mindset of aspiring programmers.
>>
>> s/those three shitty languages/Lisp and I'll agree with you. :)
>
> That raises a non-smiley point; if you want to expand programmers' minds
> about alternate language possibilities, it seems to me that learning
> Prolog (logic programming) and Haskell (functional programming) would do
> a lot more than another procedural language. I seem to recall at least
> one comment about some XML-related Java package that it was bogus
> because it required people to understand functional programming; that
> comment made me sad.

Calling some languages shitty just mean that the post will be ignored.

It is true that there are languages that are more different from Java
than those, but they still have a different approach to type safety
that in my opinion is very relevant.

Arne

On 7/21/2011 8:19 AM, Martin Gregorie wrote:
> On Wed, 20 Jul 2011 22:16:11 -0400, Arne Vajhøj wrote:
>> On 7/16/2011 8:39 AM, John B. Matthews wrote:
>>> In article<ivr43p$7cq$1@dont-email.me>, "MikeP"<mp011011@some.org>
>>> wrote:
>>>
>>>> Patricia Shanahan wrote:
>>> [...]
>>>>> No, I was not really joking, though I did not attempt to find all the
>>>>> languages that would meet the stated requirement.
>>>>
>>>> Don't look now, but if you weren't joking, then you recommended Ada to
>>>> a Java programmer! Oh my.
>>>
>>> I often suggest Ada to Java programmers; knowledgeable Java programmers
>>> often return the favor; I've learned a lot that way.
>>
>> All Java developers should master at least one language from the
>> Pascal/Modula-2/Ada family.
>>
> Add Algol 68 to that list. Compilers and runtimes are available and free.
>
> I knew Algol 60 and a smattering of Pascal when I learnt it.
>
> A68 was a huge eye-opener in terms of expressiveness and its ability to
> handle variable record structures that I thought could only be
> successfully handled in assembler: this was in pre-C days. For George 3
> hands, these were G3 job accounting records. Others should think ASN.1

I don't know Algol, so I could not add it to the list.

But I do know that the begin end family of languages are children
of Algol.

Arne

On 7/21/2011 6:05 AM, Arved Sandstrom wrote:
> On 11-07-20 11:09 PM, Arne Vajh�j wrote:
>> On 7/16/2011 12:29 AM, MikeP wrote:
>>> Patricia Shanahan wrote:
>>>> and then complain when there is a
>>>> mismatch between that language's features and their current
>>>> requirements.
>>>
>>> In another post, I said that I think that today (like in right now) the
>>> awareness of the overflow issue (language support) has achieved critical
>>> mass. Combine that with the alternatives that are available and more yet
>>> to come, a language cannot afford to go the path of, say, C anymore for
>>> it will lose relevance much more quickly. It's not complaining. It's
>>> customer feedback (companies BEG their customers for such!). Companies
>>> that don't recognize their customers needs and change with the times, go
>>> out of business. Java is not C and can't afford to stagnate like C did
>>> (OK, C++ gave it a "reconditioning"), or it won't last.
>>
>> It seems highly unlikely that the lack of overflow detection
>> will have any impact on the usage of Java.
>>
>> The typical business app does not care.

> I agree, with caveats. The larger issue is the proper treatment of
> numerical quantities in business applications. Leaving aside currency,
> which there is _some_ awareness of in terms of appropriate things to do,
> the expression of other numerical quantities in Java is typified by the
> use of unconstrained primitives, with haphazard and inconsistent bounds
> checking scattered over the code. Maybe it's just me, but wouldn't a
> better approach to a numerical data type be to write its own class,
> which is responsible for its own invariants (*) (**)? Hang the minor to
> moderate performance implications: what's more important, correct code
> or fast code?
>
> My questions to a Java programmer who wants (or thinks they want)
> overflow detection would include: are you using the correct primitive
> type (or wrapper for a primitive)? Do you even know the design ranges
> for your quantity? Why are you wanting to rely on overflow detection to
> save your program when 99 percent of the possible legal values for your
> chosen data type are also wrong for the design problem, and you're
> obviously not concerned about that at all? Why don't you write a proper
> class for your data type?

PEAA recommends a money class.

Arne

On 7/21/2011 8:32 AM, Andreas Leitgeb wrote:
> supercalifragilisticexpialadiamaticonormalizeringelimatisticantations<supercalifragilisticexpialadiamaticonormalizeringelimatisticantations@averylongandannoyingdomainname.com>  wrote:
>> On 21/07/2011 6:05 AM, Arved Sandstrom wrote:
>>> ... Why don't you write a proper class for your data type?
>> In four words: Lack of operator overloading.
>> Math on non-primitive types is *painful* in Java.
>
> agreeCount = agreeCount.plus(AgreeCount.ONE)
>      on painfulness of non-primitive math.

It does not look good.

But I find it hard to believe to be a significant problem in typical
business apps.

Arne

On 7/21/2011 11:38 AM, Andreas Leitgeb wrote:
> PS: my approach would be a new keyword like strictfp (which may modify
>    floating point semantics compared to not-applying it),
>    just one for modifying integral semantics:  arithmetic overflow checks
>    and runtime checks on cast to narrower types.  Just like use of
>    "strictfp" can be expected to slow down programs, the same would be
>    acceptable for an integral pendant.

Somehow I think that sounds very Java'ish.

(and if someone are in doubt then that is good when the context
is Java)

Arne

On 7/20/2011 10:21 PM, Arved Sandstrom wrote:
> On 11-07-20 08:50 PM, Arne Vajh�j wrote:
>> On 7/20/2011 6:36 AM, Arved Sandstrom wrote:
>>> On 11-07-19 10:31 PM, Arne Vajh�j wrote:
>>>> On 7/19/2011 9:07 PM, markspace wrote:
>>>>> On 7/19/2011 5:54 PM, Arne Vajh�j wrote:
>>>>>>> On Jul 8, 10:27 am, Gene Wirchenko<ge...@ocis.net>   wrote:
>>>>>>>> Java is designed to behave that way. That does not mean that it
>>>>>>>> is not wrong.
>>>>>
>>>>>    >   On 7/8/2011 4:15 PM, lewbloch wrote:
>>>>>>>
>>>>>>> It doesn't mean that it is wrong.
>>>>>>>
>>>>>
>>>>>> Yes, but given that there are already two languages under discussion,
>>>>>> then it seems rather obvious that his point is that Java should have
>>>>>> been designed different 16 years ago not change overflow handling
>>>>>> in Java 8.
>>>>>
>>>>>
>>>>> I think the point being made is that it's behavior that could be
>>>>> improved *now*.
>>>>>
>>>>> The prescience required to see 16 years into the future is darn hard. I
>>>>> don't think anyone at all has that kind of skill or knowledge. It would
>>>>> have been better however to acknowledge sometime in the past that Java
>>>>> needed to be improved in some fundamental ways and then make those
>>>>> changes.
>>>>>
>>>>> Generics should have been reifiable, primitives should be "first class
>>>>> objects," integer math should be checked for overflow where the
>>>>> programmer deems needed. These things have been lacking for some time,
>>>>> and are still needed, imo.
>>>>
>>>> Today it is a must that changes must not break existing code.
>>>>
>>>> That still leaves some room for improvements.
>>>>
>>>> But it tend to become messy.
>>>>
>>>> Sometimes we just need to realize that a wrong decision was
>>>> made, that we are stuck with it and that it should be done
>>>> correctly in the next language.
>>
>>> Changes, even backwards-incompatible changes, to version X of a language
>>> do not break existing code *unless* users of that existing code make a
>>> conscious choice to operate that code in the new environment. I am not
>>> convinced there is a strong need to do that.
>>>
>>> As an example, and I'm sure I'm not alone in this, I routinely maintain
>>> applications in 2011 that are J2EE 1.4 or Java EE 5. No shortage of them
>>> are J2EE 1.4. Some colleagues who maintain other big web apps I am
>>> familiar with have to deal with Struts 1. The penetration of Java EE 6
>>> applications and Java EE 6 servers into the local big business and
>>> government scene is paltry.
>>>
>>> In terms of the associated Java versions, it's true that many folks use
>>> Java 5 or 6 (frequently 1.6 latest update) even if they are developing
>>> for a J2EE 1.4 server, but in my experience there has rarely been a
>>> compelling need for it. To put it another way, I have little time for
>>> someone who argues that they just absolutely need a cool Java 6 language
>>> feature but they can't be bothered to upgrade from J2EE 1.4.
>>>
>>> Looking at the Oracle support roadmaps for J2SE/Java SE, fact is that
>>> J2SE 1.4, and Java 5/6, will have some form of adequate support for a
>>> long time yet (http://www.oracle.com/technetwork/java/eol-135779.html).
>>> If Java 8, for example, decided to make some backwards-incompatible
>>> changes to the language, people with existing code bases would have
>>> sufficient options with Java 7 or earlier to keep them happy for a long,
>>> long time. I simply do not see the validity of an argument that says
>>> that the existence of an incompatible Java 8 or 9 is going to affect any
>>> of these people. As it is, I expect not to be primarily working with
>>> Java EE 6 and JDK 7 until 2015 at the earliest...and that may be
>>> optimistic for the Java EE side of things.
>>
>> It is true that migrating code to new EE and SE versions are usually
>> a lot behind.
>>
>> But eventually the code get lifted.
>>
>> Typical because the vendors stop support for the platform.
>>
>> And changes that does not create runtime exceptions or compile
>> time warnings, but silently changes the semantics are about as
>> bad as they get.
>>
>> The fact that it may take many years before the problems are felt does
>> not make the problem smaller.
>
> I should point out that I'm not talking about arithmetic overflow
> checking or any other specific feature here. I am quite unconcerned
> about arithmetic overflow checking in Java, because I see at least two
> better solutions than changing the language: either (1) using a
> different language, or (2) being aware of your quantities and actually
> putting some thought into your design to avoid overflow. These have been
> suggested already.
>
> I'm talking about backwards-incompatible changes in general. There's no
> need to worry about "silent changes to semantics", because by definition
> you cannot expect your old source to be compatible with this newest
> version. You're told that, and you're told why. You can figure out what
> you need to change if you intend to upgrade some codebase, compiler
> warnings or no compiler warnings.
>
> Talking about Java specifically, SE or EE, there is a great deal of
> advance warning. You're typically going to have close to a decade of
> warning that you need to make certain modifications, if a version at
> some point introduces backwards incompatibilities. This is more than
> enough time. Since changes that _are_ backwards incompatible will almost
> certainly be important changes that should have been introduced much
> earlier anyway, and everyone's code should use them, and it will help
> everyone's code, where's the downside in forcing people to do some
> necessary work? People certainly do take advantage of new APIs and
> language features that _are_ backwards compatible, and they need to put
> in a lot of work to do that, so how is it somehow a bad thing that
> they've got to do a bit of work to upgrade a codebase into a new
 > backwards-incompatible version?

There are usually plenty of warnings.

But that does not make the cost go away.

And cost is bad.

>> Not wanting to spend 6 or 7 digit dollar amounts verifying that
>> code still works as original intended does not imply that you may
>> not want new features.
>
> What percentage of business types do you think care about new language
> features and new APIs? 10 percent? 5 percent? One percent? What they
> care about is can you develop their latest pet project for them. Since
> we devs usually can cobble something together, albeit with difficulty,
> even with ancient libraries and old language versions, that's how it
> goes in real life.
>
> Let me give you just one example; not so many months ago I had to go
> through a lengthy and arduous process with one client, involving much
> analysis and multiple meetings, offering assurances all the way up to
> Director of IT level, just to bump up an EclipseLink minor version. To
> the typical conservative client any upgrade of any library is a Big
> Deal. You certainly won't see them clamouring for the speedy adoption of
> a new JDK because it offers support for lambdas.

More breaking of existing code will make it even harder to get
permission to upgrade.

It is exactly to get permission to upgrade that the compatibility
is so important.

> As for code working as originally intended, show me the production
> application that is substantively defect-free and works as originally
> intended. About the worst that will happen with an upgrade is that the
> typical app will break in new ways.
>
> Sometimes these new breakages are beneficial even. I'm minded of when we
> moved a complex J2EE app from one old app server over to a newish one
> from another vendor. Suddenly dozens of new defects appeared. Turned out
> that all of them were real code defects and that the old app server
> simply sucked that bad. My feeling is that forced adoption of better VMs
> and better servers and better language features, backwards-incompatible
> or no, is generally a good thing - it exposes flaws in codebases. They
> didn't get _created_, they were already there.

Most/all code has bugs but migrating to a new runtime with slightly
different semantics will most likely increase the number of bugs
(the old ones will not go away and new will come).

Arne

On Thu, 21 Jul 2011 16:54:55 -0400, Arne Vajh�j <arne@vajhoej.dk>
wrote:

[snip]

>But I do know that the begin end family of languages are children
>of Algol.

     Block-structured languages are children of ALGOL.  That includes
C et al.

Sincerely,

Gene Wirchenko

On 7/21/2011 5:46 PM, Gene Wirchenko wrote:
> On Thu, 21 Jul 2011 16:54:55 -0400, Arne Vajh�j<arne@vajhoej.dk>
> wrote:
>
> [snip]
>
>> But I do know that the begin end family of languages are children
>> of Algol.
>
>       Block-structured languages are children of ALGOL.  That includes
> C et al.

Call them the children that the parent would be proud of then.

Arne

On 7/21/2011 1:58 PM, Arne Vajh�j wrote:
> On 7/21/2011 8:32 AM, Andreas Leitgeb wrote:
>> supercalifragilisticexpialadiamaticonormalizeringelimatisticantations<supercalifragilisticexpialadiamaticonormalizeringelimatisticantations@averylongandannoyingdomainname.com>
>> wrote:
>>> On 21/07/2011 6:05 AM, Arved Sandstrom wrote:
>>>> ... Why don't you write a proper class for your data type?
>>> In four words: Lack of operator overloading.
>>> Math on non-primitive types is *painful* in Java.
>>
>> agreeCount = agreeCount.plus(AgreeCount.ONE)
>> on painfulness of non-primitive math.
>
> It does not look good.
>
> But I find it hard to believe to be a significant problem in typical
> business apps.

I agree. After all, it is no worse than "ADD 1 TO AGREECOUNT GIVING
AGREECOUNT.".

I do have a serious concern with lack of either operator overloading or
complex primitives as one of the barriers to use of Java for engineering
and scientific programming.

The problem is not just the keystrokes for typing the expressions. It is
very important to be able to check that a lengthy expression in a
program is a correct translation of the corresponding expression, in
mathematical notation, in a textbook or paper.

Patricia

On Thu, 21 Jul 2011 16:40:08 -0400, Arne Vajhøj wrote:

> On 7/10/2011 3:22 PM, Martin Gregorie wrote:
>> On Sun, 10 Jul 2011 11:29:39 -0700, Patricia Shanahan wrote:
>>
>>> On 7/10/2011 11:07 AM, Martin Gregorie wrote:
>>>> On Sun, 10 Jul 2011 10:53:09 -0400, David Lamb wrote:
>>>>
>>>>> On 08/07/2011 12:30 AM, Eric Sosman wrote:
>>>>>> On 7/7/2011 8:51 PM, Peter Duniho wrote:
>>>>>>> [...]
>>>>>>> I would not worry about the "simple" or "efficient" criteria.
>>>>>>> IMHO, if one is deciding to apply overflow checking to every
>>>>>>> computation, one has already abandoned the hope of efficiency.
>>>>>>
>>>>>> I've used machines that raised overflow traps "for free,"
>>>>> ...
>>>>>> (The machines I speak of were from forty-odd years ago
>>>>>
>>>>> When microprocessors started to arrive on the scene, a lot of
>>>>> old-timey hardware folks said they'd forgotten 30+ years of hardware
>>>>> design. When operating systems for computers based on said
>>>>> processors came out, a lot of old-timey software folks said they'd
>>>>> forgotten 30+ years of operating system design.  We seem to still be
>>>>> suffering the consequences.
>>>>
>>>> That happened not once, but twice.
>>>>
>>>> The first great leap backward was the minicomputer era, when the
>>>> likes of the PDP-8 arrived with a single user, single tasking OS
>>>> reminiscent of early computers, except they generally had teletypes
>>>> instead of banks of switches and flashing lights. By then the better
>>>> mainframes were multi- user, multitasking beasts.
>>>>
>>>> Then the first microcomputers arrived in the mid/late '70s. By this
>>>> time the better minis had multi-tasking operating systems, but micros
>>>> had re- implemented the earliest mini OSes - CP/M was near as dammit
>>>> a copy of the old PDP-8 OS (RSTS?) from the late 60s - and the
>>>> earliest micros even had switches and flashing lights (KIM-1, IMSAI
>>>> 8080). By 1980 the minis were running UNIX but the latest and
>>>> greatest micros had - drumroll - MS- DOS!
>>>>
>>>>
>>>>
>>> Only twice? Aren't you forgetting "smart" phones. One of the great
>>> advances in Android is (Drum roll!) multitasking!!!
>>>
>> They don't count since, unlike minis and micros, their builders didn't
>> retreat to the techno-stone age, ignore progress made to date, and
>> build primitive OS by rubbing (metaphorical) sticks together.
>>
>> AFAIK all smartphones started an a more advanced level because they
>> inherited better operating systems. IIRC these all originated on
>> electronic memo pads such as Psion, HP and Palm Pilot made, and were
>> all a lot more advanced than the likes of RSTS, CP/M, Flex09, etc.
>> Leastwise, I don't think you can consider Symbian and whatever MS was
>> calling the iPAQ OS at that stage any more primitive than the
>> contemporary versions of MacOS, OS/2 or even Windows, though admittedly
>> they were rather behind UNIX and its distant relations such as
>> OS-9/68K.
> 
> If they don't support multi-tasking I would say that they in at least
> one aspect is behind the desktop OS'es.
>
Well, the OSen I quoted RSTS, CP/M, Flex09 and contemporaries on small 
minicomputers and early microcomputers, are all single tasking, and all 
had worse display handling than the smartphone OSen, because they all 
were basically green screen 24x80 systems. 

In my mind the improved graphical interfaces of the early smartphones 
(and even on the Palm Pilots) puts the latter ahead on points, and if any 
are multitasking then they're streets ahead.

IIRC first small and cheap multitasking OSes were: 

- Microware's OS/9  in 1981, so precedes even the PC/DOS incarnation
  of MS/DOS and would support multiple users on a 64K 6809 box

- TSC's uniFlex also ran on SWTPc 6809 boxes. Similar capability to OS/9
  but not nearly as flexible or portable as OS/9

- SCO UNIX was also running on 8086 hardware around the same time - 
  multi-user operation on around 128 KB RAM I think

All of these appeared around the same time and all supported simultaneous 
multiple users with 24x80 green screens terminals such as VT100, 
Hazeltine, Beehive, etc. I think Wyse were later but I could be wrong.  
  
  
> (how important multitasking is on a smartphone is a different
> discussion)
> 
Agreed: apart from anything else you'd have problems using more than one 
interactive app at a time on those tiny screens. In fact those early 
smart phones had to have some rudimentary multitasking ability, at least 
equivalent to what the early Macs could do, or the phone couldn't accept 
an incoming call if its owner was using an app.

Palm Pilots were and are extremely useful despite having no multitasking 
ability whatever.


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

On 7/21/2011 6:58 PM, Patricia Shanahan wrote:
> On 7/21/2011 1:58 PM, Arne Vajh�j wrote:
>> On 7/21/2011 8:32 AM, Andreas Leitgeb wrote:
>>> supercalifragilisticexpialadiamaticonormalizeringelimatisticantations<supercalifragilisticexpialadiamaticonormalizeringelimatisticantations@averylongandannoyingdomainname.com>
>>>
>>> wrote:
>>>> On 21/07/2011 6:05 AM, Arved Sandstrom wrote:
>>>>> ... Why don't you write a proper class for your data type?
>>>> In four words: Lack of operator overloading.
>>>> Math on non-primitive types is *painful* in Java.
>>>
>>> agreeCount = agreeCount.plus(AgreeCount.ONE)
>>> on painfulness of non-primitive math.
>>
>> It does not look good.
>>
>> But I find it hard to believe to be a significant problem in typical
>> business apps.
>
> I agree. After all, it is no worse than "ADD 1 TO AGREECOUNT GIVING
> AGREECOUNT.".
>
> I do have a serious concern with lack of either operator overloading or
> complex primitives as one of the barriers to use of Java for engineering
> and scientific programming.
 >
 > The problem is not just the keystrokes for typing the expressions. It is
 > very important to be able to check that a lengthy expression in a
 > program is a correct translation of the corresponding expression, in
 > mathematical notation, in a textbook or paper.

I perfectly understand that.

And implementing basic operators for BigInteger, BigDecimal and Complex
in Java would help that group.

Or maybe they should switch to Scala. Somehow I think that group would
like Scala.

Arne

On Thu, 21 Jul 2011 14:46:04 -0700, Gene Wirchenko wrote:

> On Thu, 21 Jul 2011 16:54:55 -0400, Arne Vajhøj <arne@vajhoej.dk> wrote:
> 
> [snip]
> 
>>But I do know that the begin end family of languages are children of
>>Algol.
> 
>      Block-structured languages are children of ALGOL.  That includes
> C et al.
>
C was the child of BCPL, a much more primitive language than Algol 60. 
For instance BCPL lacked any explicit variable typing: its only variable 
types were words and arrays of words. BCPL was the ancestor of all curly 
bracket languages.

I have no idea what, if any, relationship there was between BCPL and Algol 
60. BCPL was later (1966 vs 1960) but as quick scan of the Wikipedia 
article found no references to Algol, my guess is that there is no 
connection between the two.

I once was able to read BCPL well enough to transcribe the General 
Purpose Macro Generator, which was written in it, into Algol 60  - the 
two languages were similar enough to make this a reasonably simple task. 
Eliott 503 Algol was my first computer language. 
 

-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

On 7/21/2011 7:06 PM, Martin Gregorie wrote:
> On Thu, 21 Jul 2011 16:40:08 -0400, Arne Vajhøj wrote:
>
>> On 7/10/2011 3:22 PM, Martin Gregorie wrote:
>>> On Sun, 10 Jul 2011 11:29:39 -0700, Patricia Shanahan wrote:
>>>
>>>> On 7/10/2011 11:07 AM, Martin Gregorie wrote:
>>>>> On Sun, 10 Jul 2011 10:53:09 -0400, David Lamb wrote:
>>>>>
>>>>>> On 08/07/2011 12:30 AM, Eric Sosman wrote:
>>>>>>> On 7/7/2011 8:51 PM, Peter Duniho wrote:
>>>>>>>> [...]
>>>>>>>> I would not worry about the "simple" or "efficient" criteria.
>>>>>>>> IMHO, if one is deciding to apply overflow checking to every
>>>>>>>> computation, one has already abandoned the hope of efficiency.
>>>>>>>
>>>>>>> I've used machines that raised overflow traps "for free,"
>>>>>> ...
>>>>>>> (The machines I speak of were from forty-odd years ago
>>>>>>
>>>>>> When microprocessors started to arrive on the scene, a lot of
>>>>>> old-timey hardware folks said they'd forgotten 30+ years of hardware
>>>>>> design. When operating systems for computers based on said
>>>>>> processors came out, a lot of old-timey software folks said they'd
>>>>>> forgotten 30+ years of operating system design.  We seem to still be
>>>>>> suffering the consequences.
>>>>>
>>>>> That happened not once, but twice.
>>>>>
>>>>> The first great leap backward was the minicomputer era, when the
>>>>> likes of the PDP-8 arrived with a single user, single tasking OS
>>>>> reminiscent of early computers, except they generally had teletypes
>>>>> instead of banks of switches and flashing lights. By then the better
>>>>> mainframes were multi- user, multitasking beasts.
>>>>>
>>>>> Then the first microcomputers arrived in the mid/late '70s. By this
>>>>> time the better minis had multi-tasking operating systems, but micros
>>>>> had re- implemented the earliest mini OSes - CP/M was near as dammit
>>>>> a copy of the old PDP-8 OS (RSTS?) from the late 60s - and the
>>>>> earliest micros even had switches and flashing lights (KIM-1, IMSAI
>>>>> 8080). By 1980 the minis were running UNIX but the latest and
>>>>> greatest micros had - drumroll - MS- DOS!
>>>>>
>>>>>
>>>>>
>>>> Only twice? Aren't you forgetting "smart" phones. One of the great
>>>> advances in Android is (Drum roll!) multitasking!!!
>>>>
>>> They don't count since, unlike minis and micros, their builders didn't
>>> retreat to the techno-stone age, ignore progress made to date, and
>>> build primitive OS by rubbing (metaphorical) sticks together.
>>>
>>> AFAIK all smartphones started an a more advanced level because they
>>> inherited better operating systems. IIRC these all originated on
>>> electronic memo pads such as Psion, HP and Palm Pilot made, and were
>>> all a lot more advanced than the likes of RSTS, CP/M, Flex09, etc.
>>> Leastwise, I don't think you can consider Symbian and whatever MS was
>>> calling the iPAQ OS at that stage any more primitive than the
>>> contemporary versions of MacOS, OS/2 or even Windows, though admittedly
>>> they were rather behind UNIX and its distant relations such as
>>> OS-9/68K.
>>
>> If they don't support multi-tasking I would say that they in at least
>> one aspect is behind the desktop OS'es.
>>
> Well, the OSen I quoted RSTS, CP/M, Flex09 and contemporaries on small
> minicomputers and early microcomputers, are all single tasking, and all
> had worse display handling than the smartphone OSen, because they all
> were basically green screen 24x80 systems.

WP7 was introduces last year without real multitasking.

Arne

In article <df7h27dk9n83fm5unmn7gpgvh1rl1gi3fi@4ax.com>,
 Gene Wirchenko <genew@ocis.net> wrote:

> On Thu, 21 Jul 2011 16:54:55 -0400, Arne Vajhøj <arne@vajhoej.dk>
> wrote:
> 
> [snip]
> 
> >But I do know that the begin end family of languages are children of 
> >Algol.
> 
> Block-structured languages are children of ALGOL.  That includes C et 
> al.

"In its semantic structure Scheme is as closely akin to Algol 60 as to 
early Lisps. Algol 60 … lives on in the genes of Scheme and 
Pascal."—Alan J. Perlis, Structure and Interpretation of Computer 
Programs, Forward: 

<http://mitpress.mit.edu/sicp/full-text/book/book.html>

-- 
John B. Matthews
trashgod at gmail dot com
<http://sites.google.com/site/drjohnbmatthews>

On 21/07/2011 7:06 PM, Martin Gregorie wrote:
> Agreed: apart from anything else you'd have problems using more than one
> interactive app at a time on those tiny screens. In fact those early
> smart phones had to have some rudimentary multitasking ability, at least
> equivalent to what the early Macs could do, or the phone couldn't accept
> an incoming call if its owner was using an app.

A lot of phone apps save their exact state when you use the phone's menu 
button to close them and return to the phone's menus. The effect for 
many users is similar to true multitasking, in that they can leave work 
in progress in one app, switch to another, and return to the first 
afterward and continue where they left off. It's just they can't have a 
background job grinding away while they do something else; if they have, 
say, something rendering an animation and switch to another app the 
render makes no progress when they're not in the rendering app.

I think later-generation phones are starting to introduce the ability to 
have daemon threads.

One irritation with phone apps saving their state is that they can get 
wedged and be difficult to unwedge. The Safari browser on the iPhone is 
a frequent culprit. There's an obscure reset procedure for the iPhone 
that involves powering it off for 15 seconds and doing some magic dance, 
maybe not in that order, that will reset apps to their installed states. 
You lose work in progress but if Safari, or another app, got b0rked it 
will work again. Unfortunately you can't reset just the b0rked app. 
There's a still more severe reset that wipes the phone to factory state; 
if you do that, better have synched it with your iTunes or you've lost 
everything on the phone, possibly including paid apps.

On Fri, 22 Jul 2011 00:27:16 -0400, Henderson wrote:

> A lot of phone apps save their exact state when you use the phone's menu
> button to close them and return to the phone's menus. The effect for
> many users is similar to true multitasking, in that they can leave work
> in progress in one app, switch to another, and return to the first
> afterward and continue where they left off. It's just they can't have a
> background job grinding away while they do something else; if they have,
> say, something rendering an animation and switch to another app the
> render makes no progress when they're not in the rendering app.
>
That all sounds remarkably like a Palm Pilot: no multi-tasking, instant 
focus switch, state preserved for all tasks.
 
> One irritation with phone apps saving their state is that they can get
> wedged and be difficult to unwedge.
>
In that cast the Palm Pilot wins: I don't think mine, an ancient 
monochrome M100, has ever gotten wedged.


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

On Thu, 21 Jul 2011 15:58:44 -0700, Patricia Shanahan wrote:

> On 7/21/2011 1:58 PM, Arne Vajhøj wrote:
>> But I find it hard to believe to be a significant problem in typical
>> business apps.
> 
> I agree. After all, it is no worse than "ADD 1 TO AGREECOUNT GIVING
> AGREECOUNT.".
> 
But if its critical that a number doesn't overflow, adding an "ON SIZE 
ERROR" clause to that sentence will catch arithmetic overflow and also 
check that the result fits in the receiving field while giving the 
programmer the ability specify the corrective action.
 

-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

Joshua Cranmer <Pidgeot18@verizon.invalid> wrote:
> On 7/21/2011 9:03 AM, lewbloch wrote:
>> On Jul 21, 8:38 am, Andreas Leitgeb<a...@gamma.logic.tuwien.ac.at>
>> wrote:
>>> lewbloch<lewbl...@gmail.com>  wrote:
>>>> And what about the suggestion to write a CheckedInteger type that does
>>>> what you need?
>>> Due to Java's lack of operator overloading, doing Math with
>>> non-primitive types is just painful.
>> I saw that suggestion, but painful != impossible.

And "not impossible" != "a satisfying alternative". 

> No, painful is realizing that your attempts to make something work all 
> fail because you need to put together two libraries that need different 
> versions of the same library. Next step, writing a script to extract the 
> necessary symbols from library v2 but not in v1, dump those out as 
> assembly, and copy them over.

I'm not sure which relation to the current discussion you might have had
in mind for posting your example, but having to resort to some wordy
prefix-notation instead of infix-notation, may indeed just be comparable
to fiddling with native machine code libraries compared to jar-files.

Patricia Shanahan <pats@acm.org> wrote:
> After all, it is no worse than "ADD 1 TO AGREECOUNT GIVING AGREECOUNT.".

All Rejoice! There's still a language (like COBOL) that makes simple
expressions more verbose.  That really should keep us all happy about
Java.  (NOT!)

[about lack of operator overloading for non-primitive arithmetic types]

> The problem is not just the keystrokes for typing the expressions.
> It is very important to be able to check that a lengthy expression
> in a program is a correct translation of the corresponding expression,
> in mathematical notation, in a textbook or paper.

Lew?

On Jul 22, 10:33=A0am, Andreas Leitgeb <a...@gamma.logic.tuwien.ac.at>
wrote:
> Patricia Shanahan <p...@acm.org> wrote:
> > After all, it is no worse than "ADD 1 TO AGREECOUNT GIVING AGREECOUNT."=
..
>
> All Rejoice! There's still a language (like COBOL) that makes simple
> expressions more verbose. =A0That really should keep us all happy about
> Java. =A0(NOT!)
>
> [about lack of operator overloading for non-primitive arithmetic types]
>
> > The problem is not just the keystrokes for typing the expressions.
> > It is very important to be able to check that a lengthy expression
> > in a program is a correct translation of the corresponding expression,
> > in mathematical notation, in a textbook or paper.
>
> Lew?

Yes?

--
Lew

lewbloch <lewbloch@gmail.com> wrote:
> On Jul 22, 10:33 am, Andreas Leitgeb <a...@gamma.logic.tuwien.ac.at>
> wrote:
>> Patricia Shanahan <p...@acm.org> wrote:
>> [about lack of operator overloading for non-primitive arithmetic types]
>>> The problem is not just the keystrokes for typing the expressions.
>>> It is very important to be able to check that a lengthy expression
>>> in a program is a correct translation of the corresponding expression,
>>> in mathematical notation, in a textbook or paper.
>> Lew?
> Yes?

So here are arguments (admittedly not mine) that include ("... not just...")
but also go beyond the complaint about the number of keystrokes. I was just
wondering, if you had any expert-opinion about them, that you'd care to share.

On 7/22/2011 4:16 PM, Andreas Leitgeb wrote:
> lewbloch<lewbloch@gmail.com>  wrote:
>> On Jul 22, 10:33 am, Andreas Leitgeb<a...@gamma.logic.tuwien.ac.at>
>> wrote:
>>> Patricia Shanahan<p...@acm.org>  wrote:
>>> [about lack of operator overloading for non-primitive arithmetic types]
>>>> The problem is not just the keystrokes for typing the expressions.
>>>> It is very important to be able to check that a lengthy expression
>>>> in a program is a correct translation of the corresponding expression,
>>>> in mathematical notation, in a textbook or paper.
>>> Lew?
>> Yes?
>
> So here are arguments (admittedly not mine) that include ("... not just...")
> but also go beyond the complaint about the number of keystrokes. I was just
> wondering, if you had any expert-opinion about them, that you'd care to share.
>

Some of the context has been dropped in editing. My remarks were
specific to the complex, in every sense of the word, expressions I've
seen in scientific and engineering programs.

Patricia

On 21/07/2011 5:46 PM, Gene Wirchenko wrote:
> On Thu, 21 Jul 2011 16:54:55 -0400, Arne Vajh�j<arne@vajhoej.dk>
> wrote:
>
> [snip]
>
>> But I do know that the begin end family of languages are children
>> of Algol.
>
>       Block-structured languages are children of ALGOL.  That includes
> C et al.

I don't think "child" is quite the right word -- "inspiration" perhaps. 
  The first papers about CPL, precursor to BCPL/B/C/C++/Java, came out 
in 1963, so definitely several years after Algol 58, but it didn't have 
"block structure" in the Algol sense where you could declare procedures 
within procedures ad nauseum. I think it's fair to call Pascal and Ada 
children of Algol.

On 21/07/2011 8:32 AM, Andreas Leitgeb wrote:
> supercalifragilisticexpialadiamaticonormalizeringelimatisticantations<supercalifragilisticexpialadiamaticonormalizeringelimatisticantations@averylongandannoyingdomainname.com>  wrote:
>> On 21/07/2011 6:05 AM, Arved Sandstrom wrote:
>>> ... Why don't you write a proper class for your data type?
>> In four words: Lack of operator overloading.
>> Math on non-primitive types is *painful* in Java.
>
> agreeCount = agreeCount.plus(AgreeCount.ONE)
>      on painfulness of non-primitive math.
>

or if you think ++ is common enough:
   agreeCount.increment();
and generally
   agreeCount.add(someOtherAgreeCount)
and if you decide to have your operators return "this"
   ac0.mul(ac1).plus(ac2)) // ac0 = ac0*ac1+ac2
or
   ac = (new AgreeCount(ac0)).mul(ac1).plus(ac2) // ac = ac0*ac1+ac2

On 22/07/2011 1:16 PM, Andreas Leitgeb wrote:
> I'm not sure which relation to the current discussion you might have had
> in mind for posting your example, but having to resort to some wordy
> prefix-notation instead of infix-notation, may indeed just be comparable
> to fiddling with native machine code libraries compared to jar-files.

I have done all of those things, and for me, having to deal with method 
calls instead of infix (while annoying) is nowhere near as painful as 
the library comparison. Plus IMHO getting operator overloading *right* 
in a language isn't exactly trivial. It's not horrible, but not trivial 
either.

On 23/07/2011 11:23 AM, David Lamb wrote:
> On 21/07/2011 8:32 AM, Andreas Leitgeb wrote:
>> agreeCount = agreeCount.plus(AgreeCount.ONE)
>> on painfulness of non-primitive math.
>
> or if you think ++ is common enough:
> agreeCount.increment();
> and generally
> agreeCount.add(someOtherAgreeCount)
> and if you decide to have your operators return "this"
> ac0.mul(ac1).plus(ac2)) // ac0 = ac0*ac1+ac2
> or
> ac = (new AgreeCount(ac0)).mul(ac1).plus(ac2) // ac = ac0*ac1+ac2

Eww. Mutable number classes.

I think I'm going to throw up.

On Jul 22, 4:16=A0pm, Andreas Leitgeb <a...@gamma.logic.tuwien.ac.at>
wrote:
> lewbloch <lewbl...@gmail.com> wrote:
> > On Jul 22, 10:33=A0am, Andreas Leitgeb <a...@gamma.logic.tuwien.ac.at>
> > wrote:
> >> Patricia Shanahan <p...@acm.org> wrote:
> >> [about lack of operator overloading for non-primitive arithmetic types=
]
> >>> The problem is not just the keystrokes for typing the expressions.
> >>> It is very important to be able to check that a lengthy expression
> >>> in a program is a correct translation of the corresponding expression=
,
> >>> in mathematical notation, in a textbook or paper.
> >> Lew?
> > Yes?
>
> So here are arguments (admittedly not mine) that include ("... not just..=
..")
> but also go beyond the complaint about the number of keystrokes. I was ju=
st
> wondering, if you had any expert-opinion about them, that you'd care to s=
hare.

Patricia made excellent points.

I don't think I can improve on them.

--
Lew

On Jul 23, 8:23=A0am, David Lamb <dal...@cs.queensu.ca> wrote:
> On 21/07/2011 8:32 AM, Andreas Leitgeb wrote:
>
> > supercalifragilisticexpialadiamaticonormalizeringelimatisticantations<s=
uper califragilisticexpialadiamaticonormalizeringelimatisticantati...@avery=
longandannoyingdomainname.com> =A0wrote:
> >> On 21/07/2011 6:05 AM, Arved Sandstrom wrote:
> >>> ... Why don't you write a proper class for your data type?
> >> In four words: Lack of operator overloading.
> >> Math on non-primitive types is *painful* in Java.
>
> > agreeCount =3D agreeCount.plus(AgreeCount.ONE)
> > =A0 =A0 =A0on painfulness of non-primitive math.
>
> or if you think ++ is common enough:
> =A0 =A0agreeCount.increment();
> and generally
> =A0 =A0agreeCount.add(someOtherAgreeCount)
> and if you decide to have your operators return "this"
> =A0 =A0ac0.mul(ac1).plus(ac2)) // ac0 =3D ac0*ac1+ac2
> or
> =A0 =A0ac =3D (new AgreeCount(ac0)).mul(ac1).plus(ac2) // ac =3D ac0*ac1+=
ac2

While not as compact as operator overloading, this technique provides
a way to ameliorate the matching problem to which Patricia alluded, at
least partially, within the current capabilities of Java.

We also must consider Patricia's other sage advice to consider other
languages for problem domains for which Java is not ideal.

--
Lew

On 23/07/2011 12:04 PM, 
supercalifragilisticexpialadiamaticonormalizeringelimatisticantations wrote:
> On 23/07/2011 11:23 AM, David Lamb wrote:
>> On 21/07/2011 8:32 AM, Andreas Leitgeb wrote:
>>> agreeCount = agreeCount.plus(AgreeCount.ONE)
>>> on painfulness of non-primitive math.
>>
>> or if you think ++ is common enough:
>> agreeCount.increment();
>> and generally
>> agreeCount.add(someOtherAgreeCount)
>> and if you decide to have your operators return "this"
>> ac0.mul(ac1).plus(ac2)) // ac0 = ac0*ac1+ac2
>> or
>> ac = (new AgreeCount(ac0)).mul(ac1).plus(ac2) // ac = ac0*ac1+ac2
>
> Eww. Mutable number classes.
>
> I think I'm going to throw up.
>

It's what happens to ordinary ints in most machine languages. Feel free 
to define the less-efficient functional versions that always generate 
new objects. The main point was that the method calls aren't necessarily 
all that hard to read.

David Lamb wrote:
> supercalifragilisticexpialadiamaticonormalizeringelimatisticantations wrote:
>> David Lamb wrote:
....
>>> ac = (new AgreeCount(ac0)).mul(ac1).plus(ac2) // ac = ac0*ac1+ac2
>
>> Eww. Mutable number classes.
>>
>> I think I'm going to throw up.
>
> It's what happens to ordinary ints in most machine languages. Feel free
> to define the less-efficient functional versions that always generate
> new objects. The main point was that the method calls aren't necessarily
> all that hard to read.

The "Eww" poster seems fond of making tabloid statements devoid of
engineering reasoning.

There's nothing intrinsically wrong with mutable number classes,
particular for the use case under discussion for them, as long as they
aren't used where immutable number classes would be better.

Though the "Eww" poster is free to provide logic and evidence to
support a contrary position, if they so desire and have the
capability.

--
Lew

Patricia Shanahan <pats@acm.org> wrote:
> On 7/22/2011 4:16 PM, Andreas Leitgeb wrote:
>> lewbloch<lewbloch@gmail.com>  wrote:
>>> On Jul 22, 10:33 am, Andreas Leitgeb<a...@gamma.logic.tuwien.ac.at>
>>> wrote:
>>>> Patricia Shanahan<p...@acm.org>  wrote:
>>>> [about lack of operator overloading for non-primitive arithmetic types]
>>>>> The problem is not just the keystrokes for typing the expressions.
>>>>> It is very important to be able to check that a lengthy expression
>>>>> in a program is a correct translation of the corresponding expression,
>>>>> in mathematical notation, in a textbook or paper.
>>>> Lew?
>>> Yes?
>> So here are arguments (admittedly not mine) that include ("... not just...")
>> but also go beyond the complaint about the number of keystrokes. I was just
>> wondering, if you had any expert-opinion about them, that you'd care to share.
> Some of the context has been dropped in editing. My remarks were
> specific to the complex, in every sense of the word, expressions I've
> seen in scientific and engineering programs.

You meant only complex expressions on complex numbers?  (Is that every sense
of "complex", or did I even miss some more?)
If so, then sorry, I obviously understood your remarks as more general than they
were.  It's not my intention to misquote contexts and all that. I apologize
if it happened.

David Lamb <dalamb@cs.queensu.ca> wrote:
> On 22/07/2011 1:16 PM, Andreas Leitgeb wrote:
>> I'm not sure which relation to the current discussion you might have had
>> in mind for posting your example, but having to resort to some wordy
>> prefix-notation instead of infix-notation, may indeed just be comparable
>> to fiddling with native machine code libraries compared to jar-files.
> I have done all of those things, and for me, having to deal with method 
> calls instead of infix (while annoying) is nowhere near as painful as 
> the library comparison.

Comparing particular subjective painfulnesses doesn't contribute
much to the discussion.

It is my opinion, that operator overloading at least for a certain
limited set of JSL classes (including BigDecimal and BigInteger as
well as some new Complex class in addition to String's +), would
be beneficial.  Ditto for a new "strictint" keyword to enable 
detection and handling of integer overflows.

There obviously won't be much agreement on how much effort these
might be worth, and some may even claim that adding those would
make Java worse.  No consensus is likely to be reached here.
And even if it were reached, chances would be neglectible that Java 
would grow a feature just because it reached consensus in c.l.j.p

> Plus IMHO getting operator overloading *right* in a language isn't
> exactly trivial. It's not horrible, but not trivial either.

That's the kind of argument that made this posting worth answering.

It becomes non-trivial when it comes to mixing types in expressions.
There'd be some rules and maybe some "cannot"s but that wouldn't be
a blocking point.

lewbloch <lewbloch@gmail.com> wrote:
> While not as compact as operator overloading, this technique provides
> a way to ameliorate the matching problem to which Patricia alluded, at
> least partially, within the current capabilities of Java.

a.plus(b).mul(c)     (let's assume them all to be non-mutating methods)
might bear some surprises, but geniuses like Lew won't fall for it,
and others aren't supposed to do professional programming in Java,
anyway ;-)

> We also must consider Patricia's other sage advice to consider other
> languages for problem domains for which Java is not ideal.

I followed that advice long before it was made.  I used Tcl (8.5) for
my large-integer tasks.

Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> wrote:
> lewbloch <lewbloch@gmail.com> wrote:
>> While not as compact as operator overloading, this technique provides
>> a way to ameliorate the matching problem to which Patricia alluded, at
>> least partially, within the current capabilities of Java.
>
> a.plus(b).mul(c)     (let's assume them all to be non-mutating methods)

PS: yes, it's trivial to correct it to   a.plus(b.mul(c)) but the point is,
  that with all the parens for the method arguments, such errors happen
  more likely than with the standard infix math operators and their
  standard (mathematics-inspired) precedence rules.

> might bear some surprises, but geniuses like Lew won't fall for it,
> and others aren't supposed to do professional programming in Java,
> anyway ;-)
>
>> We also must consider Patricia's other sage advice to consider other
>> languages for problem domains for which Java is not ideal.
>
> I followed that advice long before it was made.  I used Tcl (8.5) for
> my large-integer tasks.
>

On 23/07/2011 2:51 PM, lewbloch wrote:
> David Lamb wrote:
>> supercalifragilisticexpialadiamaticonormalizeringelimatisticantations wrote:
>>> Eww. Mutable number classes.
>>
>> It's what happens to ordinary ints in most machine languages. Feel free
>> to define the less-efficient functional versions that always generate
>> new objects. The main point was that the method calls aren't necessarily
>> all that hard to read.
>
> The "Eww" poster seems fond of making tabloid statements devoid of
> engineering reasoning.

Wrong.

Ordinary ints aren't (in Java, at least, with no "int *" type) subject 
to aliasing and other problems that a mutable Integer-analogue would be.

> There's nothing intrinsically wrong with mutable number classes,
> particular for the use case under discussion for them, as long as they
> aren't used where immutable number classes would be better.

See above.

> Though the "Eww" poster is free to provide logic and evidence to
> support a contrary position, if they so desire and have the
> capability.

See above.

On 23/07/2011 5:03 PM, Andreas Leitgeb wrote:
> It is my opinion, that operator overloading at least for a certain
> limited set of JSL classes (including BigDecimal and BigInteger as
> well as some new Complex class in addition to String's +), would
> be beneficial.  Ditto for a new "strictint" keyword to enable
> detection and handling of integer overflows.

An obvious suggestion would be to allow it on all java.lang.Number 
subclasses, but a + b among these is only defined if a is a Number class 
that has an overload of .plus(x) that is applicable to an argument of a 
supertype of b, and the most specific such is chosen; and if a is a 
primitive, is treated as b + a; a * b analogously; a - b with a 
primitive uses (b - a).negate() and expects the return type of minus to 
support negate(); and for division we likewise need .reciprocal().

We could go further and rewrite Number.java so that it is Number<T 
extends Number<T>> and defines:

public T plus (? super T)
public T plus (int)
public T plus (long)
public T plus (float)
public T plus (double)
public T minus (? super T)
public T minus (int)
....
public T times (? super T)
....
public T dividedBy (? super T)
....
public T negate ()
public T reciprocal ()

or something of the sort. I think short overloads can be left out as 
they can just auto-promote to int and use the int version and the int 
version won't be less efficient, unlike (on 32 bit hardware) the long 
version.

The operator expressions then become shorthands for the method calls 
above, and generate compile time type errors if one is needed and 
missing, e.g. MyBigInteger.plus(BigInteger) is not defined but 
MyBigInteger.plus(MyBigInteger) is and one mixes the two types in a + 
expression. (Integer etc. needn't be explicitly supported as 
autounboxing can be used to call the primitive plus (int) or whatever if 
necessary.)

On 7/23/2011 1:09 PM, Andreas Leitgeb wrote:
> Patricia Shanahan<pats@acm.org>  wrote:
>> On 7/22/2011 4:16 PM, Andreas Leitgeb wrote:
>>> lewbloch<lewbloch@gmail.com>   wrote:
>>>> On Jul 22, 10:33 am, Andreas Leitgeb<a...@gamma.logic.tuwien.ac.at>
>>>> wrote:
>>>>> Patricia Shanahan<p...@acm.org>   wrote:
>>>>> [about lack of operator overloading for non-primitive arithmetic types]
>>>>>> The problem is not just the keystrokes for typing the expressions.
>>>>>> It is very important to be able to check that a lengthy expression
>>>>>> in a program is a correct translation of the corresponding expression,
>>>>>> in mathematical notation, in a textbook or paper.
>>>>> Lew?
>>>> Yes?
>>> So here are arguments (admittedly not mine) that include ("... not just...")
>>> but also go beyond the complaint about the number of keystrokes. I was just
>>> wondering, if you had any expert-opinion about them, that you'd care to share.
>> Some of the context has been dropped in editing. My remarks were
>> specific to the complex, in every sense of the word, expressions I've
>> seen in scientific and engineering programs.
>
> You meant only complex expressions on complex numbers?  (Is that every sense
> of "complex", or did I even miss some more?)
> If so, then sorry, I obviously understood your remarks as more general than they
> were.  It's not my intention to misquote contexts and all that. I apologize
> if it happened.
>

No problem. My practical experience of cases in which I think
representing expressions in method calls would be disastrous is
complicated expressions in complex numbers. It seems reasonable to me
that it might also be a problem e.g. for a rational type or for
BigDecimal, but I don't have direct observations to back that up.

Patricia

On 7/23/2011 7:55 PM, Henderson wrote:
> On 23/07/2011 5:03 PM, Andreas Leitgeb wrote:
>> It is my opinion, that operator overloading at least for a certain
>> limited set of JSL classes (including BigDecimal and BigInteger as
>> well as some new Complex class in addition to String's +), would
>> be beneficial. Ditto for a new "strictint" keyword to enable
>> detection and handling of integer overflows.
>
> An obvious suggestion would be to allow it on all java.lang.Number
> subclasses, but a + b among these is only defined if a is a Number class
> that has an overload of .plus(x) that is applicable to an argument of a
> supertype of b, and the most specific such is chosen; and if a is a
> primitive, is treated as b + a; a * b analogously; a - b with a
> primitive uses (b - a).negate() and expects the return type of minus to
> support negate(); and for division we likewise need .reciprocal().
>
> We could go further and rewrite Number.java so that it is Number<T
> extends Number<T>> and defines:

I don't think it would be wise to tie operator overloading to Number.
Number defines a series of conversions that make some sense for those
types that represent subsets of the real line.

You cannot return "the value of the specified number as a double" if the
specified number is complex. I would prefer the complex type to have
separate, meaningfully named, methods returning as double each of the
real part, the complex part, the absolute value, and the phase.

I think it might be better to create a marker interface
java.math.Arithmetic. I do like the idea of a fixed mapping from
operators to method names that are normal identifiers. I don't think
all arithmetic types should be required to support all operations. For
example, consider negate and an unsigned type, or reciprocal and an
integer type.

Patricia

On 7/24/2011 9:16 AM, Patricia Shanahan wrote:
> I think it might be better to create a marker interface
> java.math.Arithmetic. I do like the idea of a fixed mapping from
> operators to method names that are normal identifiers.


I'd be concerned that a marker interface could be abused.

public abstract class BaseNumber extends Number {
   public abstract BaseNumber add( Number n );
   public abstract BaseNumber subtract( Number n );
   public abstract BaseNumber mul( Number n );
   public abstract BaseNumber[] div( Number n );
   public abstract BaseNumber modulo( Number n );
}

Then restrict operator overloading to a class like BaseNumber and its 
subclasses.  Some classes in the existing Java API like BigDecimal may 
need to also extend BaseNumber.

On 7/24/2011 10:40 AM, markspace wrote:
> On 7/24/2011 9:16 AM, Patricia Shanahan wrote:
>> I think it might be better to create a marker interface
>> java.math.Arithmetic. I do like the idea of a fixed mapping from
>> operators to method names that are normal identifiers.
>
>
> I'd be concerned that a marker interface could be abused.
>
> public abstract class BaseNumber extends Number {
> public abstract BaseNumber add( Number n );
> public abstract BaseNumber subtract( Number n );
> public abstract BaseNumber mul( Number n );
> public abstract BaseNumber[] div( Number n );
> public abstract BaseNumber modulo( Number n );
> }
>
> Then restrict operator overloading to a class like BaseNumber and its
> subclasses. Some classes in the existing Java API like BigDecimal may
> need to also extend BaseNumber.

Whatever is done can, and will, be abused. People will just make their
non-arithmetic classes for which they want "+" extend BaseNumber, and
meanwhile complex would be forced to provide a meaningless conversion to
byte.

Patricia

On 7/24/2011 10:54 AM, Patricia Shanahan wrote:
> meanwhile complex would be forced to provide a meaningless conversion to
> byte.


It could just throw an error.  Collections uses this technique to make 
unmodifiable Collection's.  An unmodifiable List for example throws 
UnsupportedOperation if add() is invoked.  'Taint the prettiest but it 
works.

On 7/24/2011 11:09 AM, markspace wrote:
> On 7/24/2011 10:54 AM, Patricia Shanahan wrote:
>> meanwhile complex would be forced to provide a meaningless conversion to
>> byte.
>
>
> It could just throw an error. Collections uses this technique to make
> unmodifiable Collection's. An unmodifiable List for example throws
> UnsupportedOperation if add() is invoked. 'Taint the prettiest but it
> works.
>
>

As well as not being particularly pretty, it changes what could be a
compile time error to an exception during execution.

Note that misuses of arithmetic operator overloading can use exactly the
same technique - extend Number and throw exceptions for the Number
methods.

I still don't see the advantage over a marker interface.

Patricia

On 7/24/2011 12:53 PM, Patricia Shanahan wrote:
> I still don't see the advantage over a marker interface.


The advantage of a class instead of an interface is that extends is 
required.  Since Java doesn't support multiple inheritance, 
opportunities for abuse are reduced.  I also think there is a mental 
barrier to is-a abstract class versus just a marker interface.  The 
former has design implications that many would not wish to break just to 
get a little operator overloading.

On 7/24/2011 3:15 PM, markspace wrote:
> On 7/24/2011 12:53 PM, Patricia Shanahan wrote:
>> I still don't see the advantage over a marker interface.
>
>
> The advantage of a class instead of an interface is that extends is
> required. Since Java doesn't support multiple inheritance, opportunities
> for abuse are reduced. I also think there is a mental barrier to is-a
> abstract class versus just a marker interface. The former has design
> implications that many would not wish to break just to get a little
> operator overloading.
>
>
>

I don't see how forcing is-a Number distinguishes between arithmetic
types and non-arithmetic types.

The main feature of Number is a set of methods that presume natural
mapping from each Number subclass into the real line.

If people are expected to live with that for arithmetic types that are
not subsets of the reals, why do you believe they will be reluctant to
live with it for non-arithmetic types, some of which do have a natural
mapping into the reals?

Patricia

On 24/07/2011 12:16 PM, Patricia Shanahan wrote:
> On 7/23/2011 7:55 PM, Henderson wrote:
>> We could go further and rewrite Number.java so that it is Number<T
>> extends Number<T>> and defines:
>
> I don't think it would be wise to tie operator overloading to Number.
> Number defines a series of conversions that make some sense for those
> types that represent subsets of the real line.

I wasn't thinking beyond the real line to the more abstract stuff 
mathematicians futz around with and consider to have addition and 
multiplication.

But short of giving general operator overloading to the masses (which 
the gurus in charge of Java clearly do not want to do), there *is* a 
way: introduce an abstract superclass, say, AbstractNumber or 
ArithmeticComposable or something for "things that aren't necessarily 
normal numbers, but have the basic arithmetic operations".

> I think it might be better to create a marker interface
> java.math.Arithmetic.

That sneaks in arbitrary operator overloading through the back door, as 
people slap "implements java.math.Arithmetic" on 
"JFoobarSQLQueryEnumerator" and implement ".plus" for it. ;)

Even as things go, I'd like there to be some compiler magic making the 
ArithmeticComposables (or whatever) have automatically final fields, 
anything with that as an ancestor, as well. It should be that a += b 
changes what math object the reference a points to, but doesn't change a 
for anybody else, so all the arithmetic operations should return new 
objects (as currently seems to be the case for BigInteger and 
BigDecimal), not mutate the original.

> I do like the idea of a fixed mapping from
> operators to method names that are normal identifiers.

It's also the only way to do it without adding new keywords and syntax 
in a probably source-compatibility-breaking way. And do we really want 
C++'s "operator+" notation?

> I don't think
> all arithmetic types should be required to support all operations. For
> example, consider negate and an unsigned type, or reciprocal and an
> integer type.

There's two approaches to dealing with that.

1. AbstractNumber implements everything, but they all throw
    UnsupportedOperationException. You override what you can support.

2. AbstractNumber doesn't even specify some of these, but +, -, etc.
    may expand into them anyway, and the compiler will then complain
    if the corresponding named method is not found.

One problem with this, though, is that implementing a - b when a is 
primitive and b isn't, and likewise a / b, seems to require having 
negate and reciprocal, respectively, supported by whatever the return 
type of b - a and b / a would be.

There's also a possible precision problem with a/b being computed as 
1/(b/a) in these cases.

As an alternative, perhaps boxing transformations can be expected 
instead: valueOf(int), etc. methods will be used so if b is of an 
ArithmeticComposable type Foo with a valueOf(int) method and a is an 
int, or can be widened to int (short, byte), then a + b becomes 
Foo.valueOf(a).plus(b).

Of course, valueOf may need to cope with values out of range. What if 
Foo is your hypothetical unsigned type and a is -42? RuntimeExceptions 
seem indicated in these cases. We already have an ArithmeticException 
class, currently used for BigInteger/BigDecimal ops that result in 
division by zero or non-representable values (in the case of a BD with 
unlimited precision -- another spot where we could sorely use a Rational 
class). I'd suggest including an ArithmeticRangeException subclass of 
that for use in such valueOf methods.

And once boxing conversions are being included, why not go ahead and 
allow any ArithmeticComposable with intValue or similarly-named methods 
be autounboxed when used in contexts that expect a primitive? (Though a 
+ b and other arithmetic situations will never unbox b instead of boxing 
a, presuming that the specialized type of b is desired. Manual unboxing 
can be done if the opposite is desired, e.g. a + b.intValue().)

On 7/25/2011 12:21 AM, Henderson wrote:
> On 24/07/2011 12:16 PM, Patricia Shanahan wrote:
>> On 7/23/2011 7:55 PM, Henderson wrote:
>>> We could go further and rewrite Number.java so that it is Number<T
>>> extends Number<T>> and defines:
>>
>> I don't think it would be wise to tie operator overloading to Number.
>> Number defines a series of conversions that make some sense for those
>> types that represent subsets of the real line.
>
> I wasn't thinking beyond the real line to the more abstract stuff
> mathematicians futz around with and consider to have addition and
> multiplication.

Historically, complex numbers were indeed invented by and for
mathematicians for the abstract satisfaction of having solutions for all
quadratic equations. However, as happens surprisingly often when
mathematicians think they have invented something abstract for their own
amusement, scientists and engineers turned them into useful tools for
practical uses.

For example, a complex number can represent both magnitude and phase of
an alternating current. That simplifies some electrical engineering
calculations.

I've seen far too many uses of complex numbers in scientific and
engineering programs to be really comfortable with the fact that Java
lacks a practical way to express anything other than the simplest
complex number expressions.

Patricia

On 11-07-25 04:56 AM, Patricia Shanahan wrote:
> On 7/25/2011 12:21 AM, Henderson wrote:
>> On 24/07/2011 12:16 PM, Patricia Shanahan wrote:
>>> On 7/23/2011 7:55 PM, Henderson wrote:
>>>> We could go further and rewrite Number.java so that it is Number<T
>>>> extends Number<T>> and defines:
>>>
>>> I don't think it would be wise to tie operator overloading to Number.
>>> Number defines a series of conversions that make some sense for those
>>> types that represent subsets of the real line.
>>
>> I wasn't thinking beyond the real line to the more abstract stuff
>> mathematicians futz around with and consider to have addition and
>> multiplication.
> 
> Historically, complex numbers were indeed invented by and for
> mathematicians for the abstract satisfaction of having solutions for all
> quadratic equations. However, as happens surprisingly often when
> mathematicians think they have invented something abstract for their own
> amusement, scientists and engineers turned them into useful tools for
> practical uses.
> 
> For example, a complex number can represent both magnitude and phase of
> an alternating current. That simplifies some electrical engineering
> calculations.
> 
> I've seen far too many uses of complex numbers in scientific and
> engineering programs to be really comfortable with the fact that Java
> lacks a practical way to express anything other than the simplest
> complex number expressions.
> 
> Patricia

I agree. Unless it were a trivial and very limited use of complex
numbers I'd likely skip Java as a candidate for doing that work. But if
the application had a moderate need for complex numbers, but also a
compelling argument for using Java for most of the logic, I would
consider Scala for the complex numbers bit. Or Jython for that matter.

But for an application that was all about science and engineering
computations my first few choices of programming languages would not
include Java anyway. Nor C#, even though that has much better support
for complex. Just as when I was doing primarily scientific programming
(12 or more years ago) I believe that faced with the same questions
today I'd still look first at what language has got the best built-ins
and libraries for the specific job, including not just data manipulation
but also data visualization.

Another interesting consideration is languages that have type systems
that support the notion of dimension. I've played a bit with that in F#
and Fortress, and I believe that language support for units of measure
is also very important in ensuring program correctness.

AHS

Henderson <h1@g1.f1> wrote:
>> I think it might be better to create a marker interface
>> java.math.Arithmetic.
>
> That sneaks in arbitrary operator overloading through the back door, as 
> people slap "implements java.math.Arithmetic" on 
> "JFoobarSQLQueryEnumerator" and implement ".plus" for it. ;)

It's quite likely that the reviewer who inevitably will shoot the
programmer for this, will have the jury's sympathy and not be 
punished...  ;)

A more fundamental problem with operator overloading for "Arithmetic"
types is, when Arithmetic types can or cannot be mixed for a particular
operation.

Simple example:  what would be the sum of
BigInteger("123456789012345678901234567890123456789012") and some
Complex( 0.0 , Math.PI )?  Ok, preferences likely go towards
Complex as the result for this particular example, but there must
be some formalism as to how this addition would be actually
calculated: either there would have to be an over*load* of
..plus(...) for each and every other type, or there must be some
bottleneck like "double" through which unknown Arithmetic-
implementations for the right operand are going to be queezed to
perform the actual calculation.

Such cross-type-behaviour can be deliberately defined for a fixed
handful of new types, but not generally among any two implementors
(or subclasses) of some interface (or baseclass). (I anticipate 
that someone will now throw up .equals(), but that's of course
a much simpler matter ("just return false") with respect to
unrelated argument types.)

PS:
I have a faible for philosophical discussions of what new features
would or would not improve Java, and what dangers linger behind them.
I do not think, that any of this discussion or outcomes will have an
influence on what may or may not go into a new version of Java.

On 25/07/2011 7:06 AM, Andreas Leitgeb wrote:
> Henderson<h1@g1.f1>  wrote:
>>> I think it might be better to create a marker interface
>>> java.math.Arithmetic.
>>
>> That sneaks in arbitrary operator overloading through the back door, as
>> people slap "implements java.math.Arithmetic" on
>> "JFoobarSQLQueryEnumerator" and implement ".plus" for it. ;)
>
> It's quite likely that the reviewer who inevitably will shoot the
> programmer for this, will have the jury's sympathy and not be
> punished...  ;)
>
> A more fundamental problem with operator overloading for "Arithmetic"
> types is, when Arithmetic types can or cannot be mixed for a particular
> operation.
>
> Simple example:  what would be the sum of
> BigInteger("123456789012345678901234567890123456789012") and some
> Complex( 0.0 , Math.PI )?

Ideally, it would be a Complex with bignum components, preserving precision.

This seems to require Complex<BaseType> rather than just Complex.

Of course you also raise a valid point regarding overloading for 
conversions. Probably you'd have to create a whole framework, with a 
NVector<T> for "things with dimension > 1 over the real numbers" and 
NVector<BigDecimal> of appropriate dimensionality as the conversion 
intermediary (so as not to lose either precision or dimensions in going 
to the intermediary) -- just BigDecimal when one-dimensional. Then 
conversion to and from BigDecimal and NVector<BigDecimal> is all that is 
required.

Until some enterprising mathematician thinks up something that can be 
added and multiplied, but has no sensible correspondence to any subset 
of any kind of vectors of real numbers ...

I think you can cram matrices in there, and complex numbers. Numbers mod 
something, too -- though do you quietly truncate when converting to 
these, or throw an exception? Of course, primitive int is already 
actually an integers-mod-2^32 type so that may be considered already 
settled.

A quick search of wikipedia for "numbers" and looking at terms in the 
results that seem to describe funny kinds of numbers turns up "p-adic 
numbers" and "hyperreal numbers" that I'm guessing would still run into 
problems here. No operator overloading for those, then. :)

On 7/25/2011 8:12 AM, Henderson wrote:
> On 25/07/2011 7:06 AM, Andreas Leitgeb wrote:
....
>> Simple example: what would be the sum of
>> BigInteger("123456789012345678901234567890123456789012") and some
>> Complex( 0.0 , Math.PI )?
>
> Ideally, it would be a Complex with bignum components, preserving
> precision.

Treat x+y as x.plus(y). Apply the usual compile and run time method
invocation rules. The type of the result of x+y is the return type of
x.plus(y). Report the usual errors.

That strategy would require some explicit conversions but is much
clearer than anything that attempts inference for user-defined
arithmetic types beyond the method invocation conversions.

It leaves the choice of the return type to the writers of the classes
and the code using them, where it should be for generality.

> Until some enterprising mathematician thinks up something that can be
> added and multiplied, but has no sensible correspondence to any
> subset of any kind of vectors of real numbers ...

How about the symmetries of a square? Or, for that matter, any arbitrary
group? If you have a group, you have addition.

At one level, every practical type is limited to values that can be
represented by finite bit strings, and those bit strings can all be
mapped to natural numbers.

The key question is how "sensible" is the correspondence. We already
have some awkwardness in making Double implement Comparable and extend
Number, because Double can have Not-a-Number values. Double has to
pretend NaNs are numbers in some Comparable and Number contexts, even
though their whole point is to represent the lack of a numerical result.

Patricia

On 7/25/2011 9:09 AM, Patricia Shanahan wrote:
....
> The key question is how "sensible" is the correspondence. We already
> have some awkwardness in making Double implement Comparable and extend
> Number, because Double can have Not-a-Number values. Double has to
> pretend NaNs are numbers in some Comparable and Number contexts, even
> though their whole point is to represent the lack of a numerical result.
....

Returning to the original topic of this thread, I think one of the worst
decisions in the early Java design was to treat NaN as zero on
conversion to an integer type.

Consider the following program:

public class DivisionExample {
   public static void main(String[] args) {
     System.out.println(0.0 / 0.0);
     System.out.println((long) (0.0 / 0.0));
     try {
       System.out.println(0 / 0);
     } catch (ArithmeticException e) {
       System.out.println("Integer division: " + e.getMessage());
     }
   }
}

It prints:

NaN
0
Integer division: / by zero

If the undefined 0/0 division is done in an integer type it throws an
exception. If it is done in double and the double is output as a double,
it is a NaN. If the double is converted to integer, the already detected
NaN condition is silently turned into a zero.

Patricia

On 7/23/2011 7:39 PM, 
supercalifragilisticexpialadiamaticonormalizeringelimatisticantations wrote:
> On 23/07/2011 2:51 PM, lewbloch wrote:
>> David Lamb wrote:
>>> supercalifragilisticexpialadiamaticonormalizeringelimatisticantations
>>> wrote:
>>>> Eww. Mutable number classes.
>>>
>>> It's what happens to ordinary ints in most machine languages. Feel free
>>> to define the less-efficient functional versions that always generate
>>> new objects. The main point was that the method calls aren't necessarily
>>> all that hard to read.
>>
>> The "Eww" poster seems fond of making tabloid statements devoid of
>> engineering reasoning.
>
> Wrong.
>
> Ordinary ints aren't (in Java, at least, with no "int *" type) subject
> to aliasing and other problems that a mutable Integer-analogue would be.

Then I suppose you'd have no objection to making the Matrix class 
immutable and implicitly copying itself every time you do an operation. 
I really appreciate that when using Householders to find eigenvalues in 
my small 10Kx10K matrix.

-- 
Beware of bugs in the above code; I have only proved it correct, not 
tried it. -- Donald E. Knuth

On 25/07/2011 1:20 PM, Joshua Cranmer wrote:
> On 7/23/2011 7:39 PM,
> supercalifragilisticexpialadiamaticonormalizeringelimatisticantations
> wrote:
>> Wrong.
>>
>> Ordinary ints aren't (in Java, at least, with no "int *" type) subject
>> to aliasing and other problems that a mutable Integer-analogue would be.
>
> Then I suppose you'd have no objection to making the Matrix class
> immutable and implicitly copying itself every time you do an operation.
> I really appreciate that when using Householders to find eigenvalues in
> my small 10Kx10K matrix.

We were talking about numbers, not matrices.

For something like matrices, I'd consider it "good enough" to have a 
mutable and an immutable version, with mutable ones used inside of 
methods as temporaries and the immutable type used in argument and 
return types. (Obviously each would have a constructor that accepted the 
other type.)

On 25/07/2011 11:12 AM, Henderson wrote:
> Until some enterprising mathematician thinks up something that can be
> added and multiplied, but has no sensible correspondence to any subset
> of any kind of vectors of real numbers ...

They're called "Rings":
http://en.wikipedia.org/wiki/Ring_%28mathematics%29

On 25/07/2011 1:29 PM, 
supercalifragilisticexpialadiamaticonormalizeringelimatisticantations wrote:
> For something like matrices, I'd consider it "good enough" to have a
> mutable and an immutable version, with mutable ones used inside of
> methods as temporaries and the immutable type used in argument and
> return types.

I'd be reasonably happy with that, too.

In article <SNhXp.70431$5v5.35598@newsfe11.iad>,
 David Lamb <dalamb@cs.queensu.ca> wrote:

> On 25/07/2011 11:12 AM, Henderson wrote:
> > Until some enterprising mathematician thinks up something that can 
> > be added and multiplied, but has no sensible correspondence to any 
> > subset of any kind of vectors of real numbers ...
> 
> They're called "Rings":
> http://en.wikipedia.org/wiki/Ring_%28mathematics%29

The interface org.jscience.mathematics.structure.Ring represents just 
such an algebraic structure:

<http://jscience.org/api/org/jscience/mathematics/structure/Ring.html>

Both Complex and Polynomial implement Ring<R>, and there's a an example 
using Polynomial<Complex> here:

<http://sites.google.com/site/drjohnbmatthews/polyroots>

-- 
John B. Matthews
trashgod at gmail dot com
<http://sites.google.com/site/drjohnbmatthews>

On 7/25/2011 11:12 AM, Henderson wrote:
> Until some enterprising mathematician thinks up something that can be
> added and multiplied, but has no sensible correspondence to any subset
> of any kind of vectors of real numbers ...

You've never taken abstract algebra, have you? Polynomials are the most 
common counterexample I can think of (although they are treatable as an 
infinite vector space over any finite field). You can also generalize 
functions over the real numbers as a ring, and I'd find it hard pressed 
to come up with a scheme that can sensibly "correspond to any subset of 
any kind of vectors of real numbers" that can handle things as wildly 
varying as f(x) = 1, f(x) = sin x, f(x) = integral from 0 to x of 
exp(-t^2) dt, f(x) = 1 if x is rational and 1/x if x is irrational, or 
f(x) = sum from n = 0 to infinity of 1/2 ^n cos(9^n pi x) (the 
Weierstrass function).

Of course, if you just want addition, I can pull any old group out of a 
hat. Symmetries of an n-gon are a particular favorite example for 
nonabelian groups, as are permutations of sets.

> I think you can cram matrices in there, and complex numbers. Numbers mod
> something, too -- though do you quietly truncate when converting to
> these, or throw an exception? Of course, primitive int is already
> actually an integers-mod-2^32 type so that may be considered already
> settled.

What do you mean by "truncate" in modular arithmetic? Mod 10, 1 and 11 
are the same thing (the set of numbers {..., -9, 1, 11, ... }).

-- 
Beware of bugs in the above code; I have only proved it correct, not 
tried it. -- Donald E. Knuth

Am 25.07.2011 09:56, schrieb Patricia Shanahan:
> On 7/25/2011 12:21 AM, Henderson wrote:
>> On 24/07/2011 12:16 PM, Patricia Shanahan wrote:
>>> On 7/23/2011 7:55 PM, Henderson wrote:
>>>> We could go further and rewrite Number.java so that it is Number<T
>>>> extends Number<T>> and defines:
>>>
>>> I don't think it would be wise to tie operator overloading to Number.
>>> Number defines a series of conversions that make some sense for those
>>> types that represent subsets of the real line.
>>
>> I wasn't thinking beyond the real line to the more abstract stuff
>> mathematicians futz around with and consider to have addition and
>> multiplication.
>
> Historically, complex numbers were indeed invented by and for
> mathematicians for the abstract satisfaction of having solutions for all
> quadratic equations.

Not at all! There was simply no need to solve quadratic equations like 
x^2 + 4 = 0 simply because everyone knew, and it was obvious, that this 
equation *does not have* a solution.

Complex numbers were invented as a tool to solve *cubic* equations. The 
tricky thing is that, if you want to solve a cubic equation, you *know* 
that it must either have one, two or three solutions, ever. However, in 
the three-solution case, a closed formula for computing the solutions 
was found, but this equation required you, somewhere in the middle, to 
handle with roots of negative numbers. All these strange negative roots 
then vanish again in the final solution using rules like sqrt(-1) * 
sqrt(-1) = -1, and then cancel out, so everything was "correct" in the 
end. All what happened then is that these rules for manipulating the 
strange temporary = "imaginary" numbers where written down, and *this* 
gave the complex numbers.

Thus, complex numbers weren't an abstract invention by crazy 
mathematicians trying to solve what wasn't possible to solve, but rather 
as a toolkit to solve something very practical, namely to apply an 
algorithm for solving cubic(!) equations. This is very much a useful 
task, as it is to use complex numbers to describe AC currents.

That java lacks operator overloading is a historic decision, probably 
taken on the basis that C++ started with this feature, and everyone 
considered it "so cool" that it was misused for all types of nonsense. 
Basically, I don't consider the choice of the C++ STL to use << and >> 
operators for input and output a sane one, and probably the java 
language designers had the same impression, so wanted to avoid it, but 
then overdid it by disallowing operator overloading in total.

Nowadays, one can probably say that operator overloading *is* a useful 
tool, but as for all useful tools it is one that should be handled with 
care, and a tool that can cause quite some trouble in the hands of 
fools. Thus, what C++ overdid, and Java "under"-did. From today's 
perspective, I *would* prefer to have operator overloading in java, but 
apply it only where it makes sense and the semantics of operators is 
correct. That is, apply it to numeric types (numbers including complex 
numbers, matrices, vectors). Appyling it to I/O as does C++ is, IMHO, 
not a good idea.

Greetings,
	Thomas