[Jprogramming] Polygon containment

[Bo Jacoby]

Size is objectively the number of characters of the program, while complexity (in this context) is the subjective and time-dependent difficulty of understanding the program. So a short J-program can be more complex than a nice long explanation in English. 

Theoretically the (Kolmogorov) complexity of a problem is the size of the smallest program that solves the problem, as far as I understand.

R.E.Boss made an interesting speed competition, but the results depend not only on the programs tested but also on the test data. 

The judging between competing programs may ultimately be a matter of taste. 

--- Den ons 28/4/10 skrev Oleg Kobchenko <olegykj at yahoo.com>:

> Fra: Oleg Kobchenko <olegykj at yahoo.com>
> Emne: Re: [Jprogramming] Polygon containment
> Til: "Programming forum" <programming at jsoftware.com>
> Dato: onsdag 28. april 2010 05.48
> As we all know here, size and
> complexity are two different measures.
> 
> 
> 
> On Apr 27, 2010, at 8:08 AM, Bo Jacoby <bojacoby at yahoo.dk>
> wrote:
> 
> I agree that correctness comes first. 
> 
> When a program performs better in some specific cases and
> worse in other cases then the concept of performance is not
> well defined. 
> 
> Simplicity is necessary for reliability. Big programs have
> bugs. 
> 
> --- Den tirs 27/4/10 skrev R.E. Boss <r.e.boss at planet.nl>:
> 
> Fra: R.E. Boss <r.e.boss at planet.nl>
> Emne: Re: [Jprogramming] Polygon containment
> Til: "'Programming forum'" <programming at jsoftware.com>
> Dato: tirsdag 27. april 2010 13.45
> 
> 
> Van: programming-bounces at jsoftware.com
> [mailto:programming-
> bounces at jsoftware.com]
> Namens Bo Jacoby
> Onderwerp: Re: [Jprogramming] Polygon containment
> 
> I think that one should usually resist the temptation
> to introduce
> additional complexity into a program in order to speed
> it up a little in
> special cases, because it may turn out to be slower in
> some other cases,
> which is bad, and simplicity is lost, which is worse,
> and also bugs may be
> introduced, which is very bad.
> (...)
> 
> 
> My priorities differ: correctness comes first, then
> performance, then
> elegance.
> 
> Efficiency improvements only count from a factor 2 upwards
> (Hui's rule). So
> "to speed it up a little in special cases" is too
> dismissive.
> 
> 
> R.E. Boss
>