Re: python coding contest

[Claudio Grondi]

Michael Spencer wrote:
> Claudio Grondi wrote:
> 
>> ...I analysed the outcome of it and have
>> come to the conclusion, that there were two major factors which 
>> contributed to squeezing of code:
>>
>>(1). usage of available variants for coding of the same thing
>>(2). sqeezing the size of used numeric and string literals
>>
> not only squeezing the size of the literals, but the combined size 
> of the compressed data and the code to expand it.  In this respect it 
> turned out to be a surprisingly rewarding challenge, and a nice 
> reinforcement of the Pythonic mantra of seeking performance gains by 
> optimizing algorithms.
> 
> Michael
> 
You are right. I have overseen that aspect which makes the contest a 
kind of Python scripting language related compression challenge.

I haven't done it yet, but I consider it interesting to check out how 
compression algorithms are doing on the three lines 7 segment LCD 
mimicking text representations of a decimal number generated by 
seven_seg() compared to size of input string plus the size of the 
module. I suppose, as the input string is not of minimal possible size 
compared to the information it carries, compression schemes should be 
able to beat the 'compression' by seven_seg().

Interesting in this context for me is also, that if I understand it 
right, according to Kolmogorov complexity law, it will be never possible 
to state if the achieved solution is the shortest possible as it will be 
also not possible for any other provided (shorter) solution.

Claudio
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python coding contest

[Alex Martelli]

Christian Tismer <[EMAIL PROTECTED]> wrote:

> Hans Nowak wrote:
> 
> >...  for u in(3,14,10))
> > 
> > can be written as:
> > 
> >...  for u in 3,14,10)
> > 
> > which would shave off a character.  Tuples don't always need parentheses...
> 
> This would work with a list comprehension.
> Doesn't work with a generator expression
> (thought of it, too, and the list comprehension eats one char)

Right.  I asked Guido about that, as he put together the 120-chars
submission of "Team Google" (including some input from me and others),
and he says it's to avoid (human) ambiguity, much like the reason the
parentheses are mandatory in [(a,b) for ...].


Alex
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python coding contest

[Michael Spencer]

Claudio Grondi wrote:
> ...I analysed the outcome of it and have
> come to the conclusion, that there were two major factors which 
> contributed to squeezing of code:
> 
>(1). usage of available variants for coding of the same thing
>(2). sqeezing the size of used numeric and string literals
> 
...not only squeezing the size of the literals, but the combined size of the 
compressed data and the code to expand it.  In this respect it turned out to be 
a surprisingly rewarding challenge, and a nice reinforcement of the Pythonic 
mantra of seeking performance gains by optimizing algorithms.

Michael



-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python coding contest

[Jacob Hallen]

In article <[EMAIL PROTECTED]>,
Simon Hengel  <[EMAIL PROTECTED]> wrote:
>Hello,
>
>> After all, I'd really love to set up another contest with
>> different measures and criteria.
>
>for future events i will take a close look at other possibilities for
>doing a ranking. At the moment the 22c3 and the contest is eating up all
>my time. Pleas appreciate that i may not keep up with all mails. Sorry
>for that.

For whatever it is worth, I enjoyed myself thoroughly thinking about the 
problem,
discussing it and listening to others discuss it. It was FUN!

It is built into all requirements for shortest or fastest that the winning 
solution
will be using obscure features and combinations in order to make the absolutely
optimal solution. This doesn't really matter unless your goals are to 
demonstrate
the elegance of the programming language. If you want to provide an alternative
to solving crossword puzzles or mega-hard Sudoku's for the Christmas holiday, 
I'd
say this is spot on.

Jacob Hallén


-- 
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python coding contest

[Claudio Grondi]

Claudio Grondi wrote:
> Steven D'Aprano wrote:
> 
>> On Sun, 01 Jan 2006 15:49:58 +0100, Claudio Grondi wrote:
>>
>>
>>
>>> What I have thought about as a simpler/better solution is a method 
>>> allowing to avoid processing the content of the string or long 
>>> integer object by looping over its content. 
>>
>>
>>
>> How can you avoid looping over its content? Whether you do it yourself
>> using "for byte in array" or similar, or Python does it for you
>> (using array.tostring perhaps), *something* has to walk through the 
>> bytes.
>>
>> If you don't like walking the string, write a function to do it once, and
>> then use the function.
>>
>>
>>> I suppose, that knowing enough about Python internals it must be 
>>> possible to change only the object type not beeing forced to process 
>>> the content i.e. the value itself, what in case of big size of data 
>>> to convert with methods like this above wastes CPU time.
>>
>>
>>
>> I'm reminded of a time I was going for a drive in the country when I 
>> drove
>> past an apple orchid. Standing in the orchid was a farmer with a pig. He
>> lifted the pig into the air, and the pig then bit an apple and slowly
>> chewed it. The farmer then carried him over to another branch, and the 
>> pig
>> ate another apple.
>>
>> I was so surprised I stopped my car and wandered over to ask the farmer
>> what he was doing.
>>
>> "I'm feeding apples to my pig," he replied.
>>
>> "Wouldn't it save time to just pick some apples and feed them to the 
>> pig?"
>>
>> The farmer looked at me like I was an idiot. "What's time to a pig?"
>>
>>
>> The moral of the story is, before spending time working on some scheme to
>> save CPU time, you better be absolutely sure that firstly, you are going
>> to save CPU time, secondly, that it is enough CPU time to be worth 
>> saving,
>> and thirdly, that you aren't wasting more of your own time to do it.
>>
>>
>>
> It's a funny story :-))
> 
> , but in my eyes not appropriate in given context, because my prior goal 
> is to understand some more about Python internals, i.e. what is and if 
> it is at all a differerence between the internal representation of a 
> string and a long integer.
> 
> I know, I should probably look into the C source of Python, but I 
> suppose it could be too hard for me to find the appropriate piece of 
> code, so I welcome any hints.
> 
> If I knew the internal representation of string and long integer objects 
> and were able to read/write to memory and point an identifier at a given 
> memory address, a conversion between long integer and string types were 
> probably nothing else as changing some bytes and repointing an 
> identifier (assuming that string and long integer values are in memory 
> the same data if they represent the same value). That it would save CPU 
> time is secondary here, but with increasing costs of energy making the 
> number on my electrical power bill higher each year due to higher power 
> consumption with increasing number of programs I run (it makes a 
> difference of 50 Watt between an algorithm keeping the CPU 100% busy and 
> an algorithm using only 1% of it) it is not necessarily paranoia driving 
> one to consider potential savings of CPU time.
> In this context the example of the bigdec class comes to my mind, where 
> usage of another algorithm made it possible to cut down power 
> consumption and time of printing a decimal form of the largest known 
> prime number from 7 hours of a 100% busy CPU down to 7 seconds!
> 
> Claudio

 From stringobject.h :
typedef struct {
 PyObject_VAR_HEAD
 long ob_shash;
 int ob_sstate;
 char ob_sval[1];
 /* Invariants:
  * ob_sval contains space for 'ob_size+1' elements.
  * ob_sval[ob_size] == 0.
  * ob_shash is the hash of the string or -1 if not computed yet.
  * ob_sstate != 0 iff the string object is in stringobject.c's
  *   'interned' dictionary; in this case the two references
  *   from 'interned' to this object are *not counted* in ob_refcnt.
  */
} PyStringObject;

 From longobject.h :
typedef struct _longobject PyLongObject; /* Revealed in longintrepr.h */
 From longintrepr.h :
typedef unsigned short digit;
struct _longobject {
  PyObject_VAR_HEAD
  digit ob_digit[1];
};

 From this I mean to see, that the string data header is longer 
containing an additional long and an int compared to long integer data 
header. The long integer seem to be an array of unsigned short values 
and the string an array of characters. My MSDN help tells me, that:
"Type short int (or simply short) is an integral type that is larger 
than or equal to the size of type char, and shorter than or equal to the 
size of type int." In Microsoft Visual C++ short is 2 bytes long, and 
because I am on an Intel processor the sequence of bytes will differ 
from what I will get when creating a binary string out of a long integer 
due to swapping of byte order. Am I right here?

My conclusion is, that b

Re: python coding contest

[Peter Hansen]

[EMAIL PROTECTED] wrote:
> Steven D'Aprano wrote:
> 
>>I'm reminded of a time I was going for a drive in the country when I drove
>>past an apple orchid. Standing in the orchid was a farmer with a pig. He
>>lifted the pig into the air, and the pig then bit an apple and slowly
>>chewed it. The farmer then carried him over to another branch, and the pig
>>ate another apple.
>>
>>I was so surprised I stopped my car and wandered over to ask the farmer
>>what he was doing.
>>
>>"I'm feeding apples to my pig," he replied.
>>
>>"Wouldn't it save time to just pick some apples and feed them to the pig?"
>>
>>The farmer looked at me like I was an idiot. "What's time to a pig?"
> 
> 
> Has anyone studied if farmers like him are in general healthier ?

Yes, they have stronger arms, but some greater incidence of back 
problems as well.  Other than that they're basically just as healthy as 
the rest of us who feed our pigs the normal way.

-Peter

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python coding contest

[bonono]

Steven D'Aprano wrote:
> I'm reminded of a time I was going for a drive in the country when I drove
> past an apple orchid. Standing in the orchid was a farmer with a pig. He
> lifted the pig into the air, and the pig then bit an apple and slowly
> chewed it. The farmer then carried him over to another branch, and the pig
> ate another apple.
>
> I was so surprised I stopped my car and wandered over to ask the farmer
> what he was doing.
>
> "I'm feeding apples to my pig," he replied.
>
> "Wouldn't it save time to just pick some apples and feed them to the pig?"
>
> The farmer looked at me like I was an idiot. "What's time to a pig?"

Has anyone studied if farmers like him are in general healthier ?

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python coding contest

[Claudio Grondi]

Steven D'Aprano wrote:
> On Sun, 01 Jan 2006 15:49:58 +0100, Claudio Grondi wrote:
> 
> 
> 
>>What I have thought about as a simpler/better solution is a method 
>>allowing to avoid processing the content of the string or long integer 
>>object by looping over its content. 
> 
> 
> How can you avoid looping over its content? Whether you do it yourself
> using "for byte in array" or similar, or Python does it for you
> (using array.tostring perhaps), *something* has to walk through the bytes.
> 
> If you don't like walking the string, write a function to do it once, and
> then use the function.
> 
> 
>>I suppose, that knowing enough about 
>>Python internals it must be possible to change only the object type not 
>>beeing forced to process the content i.e. the value itself, what in case 
>>of big size of data to convert with methods like this above wastes CPU 
>>time.
> 
> 
> I'm reminded of a time I was going for a drive in the country when I drove
> past an apple orchid. Standing in the orchid was a farmer with a pig. He
> lifted the pig into the air, and the pig then bit an apple and slowly
> chewed it. The farmer then carried him over to another branch, and the pig
> ate another apple.
> 
> I was so surprised I stopped my car and wandered over to ask the farmer
> what he was doing.
> 
> "I'm feeding apples to my pig," he replied.
> 
> "Wouldn't it save time to just pick some apples and feed them to the pig?"
> 
> The farmer looked at me like I was an idiot. "What's time to a pig?"
> 
> 
> The moral of the story is, before spending time working on some scheme to
> save CPU time, you better be absolutely sure that firstly, you are going
> to save CPU time, secondly, that it is enough CPU time to be worth saving,
> and thirdly, that you aren't wasting more of your own time to do it.
> 
> 
> 
It's a funny story :-))

, but in my eyes not appropriate in given context, because my prior goal 
is to understand some more about Python internals, i.e. what is and if 
it is at all a differerence between the internal representation of a 
string and a long integer.

I know, I should probably look into the C source of Python, but I 
suppose it could be too hard for me to find the appropriate piece of 
code, so I welcome any hints.

If I knew the internal representation of string and long integer objects 
and were able to read/write to memory and point an identifier at a given 
memory address, a conversion between long integer and string types were 
probably nothing else as changing some bytes and repointing an 
identifier (assuming that string and long integer values are in memory 
the same data if they represent the same value). That it would save CPU 
time is secondary here, but with increasing costs of energy making the 
number on my electrical power bill higher each year due to higher power 
consumption with increasing number of programs I run (it makes a 
difference of 50 Watt between an algorithm keeping the CPU 100% busy and 
an algorithm using only 1% of it) it is not necessarily paranoia driving 
one to consider potential savings of CPU time.
In this context the example of the bigdec class comes to my mind, where 
usage of another algorithm made it possible to cut down power 
consumption and time of printing a decimal form of the largest known 
prime number from 7 hours of a 100% busy CPU down to 7 seconds!

Claudio
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python coding contest

[Steven D'Aprano]

On Sun, 01 Jan 2006 15:49:58 +0100, Claudio Grondi wrote:


> What I have thought about as a simpler/better solution is a method 
> allowing to avoid processing the content of the string or long integer 
> object by looping over its content. 

How can you avoid looping over its content? Whether you do it yourself
using "for byte in array" or similar, or Python does it for you
(using array.tostring perhaps), *something* has to walk through the bytes.

If you don't like walking the string, write a function to do it once, and
then use the function.

> I suppose, that knowing enough about 
> Python internals it must be possible to change only the object type not 
> beeing forced to process the content i.e. the value itself, what in case 
> of big size of data to convert with methods like this above wastes CPU 
> time.

I'm reminded of a time I was going for a drive in the country when I drove
past an apple orchid. Standing in the orchid was a farmer with a pig. He
lifted the pig into the air, and the pig then bit an apple and slowly
chewed it. The farmer then carried him over to another branch, and the pig
ate another apple.

I was so surprised I stopped my car and wandered over to ask the farmer
what he was doing.

"I'm feeding apples to my pig," he replied.

"Wouldn't it save time to just pick some apples and feed them to the pig?"

The farmer looked at me like I was an idiot. "What's time to a pig?"


The moral of the story is, before spending time working on some scheme to
save CPU time, you better be absolutely sure that firstly, you are going
to save CPU time, secondly, that it is enough CPU time to be worth saving,
and thirdly, that you aren't wasting more of your own time to do it.



-- 
Steven.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python coding contest

[Claudio Grondi]

Steven D'Aprano wrote:
> On Sun, 01 Jan 2006 03:34:33 +0100, Claudio Grondi wrote:
> 
> 
>>>Please send me comments, suggestions and ideas.
>>
>>Now, after the contest is over I analysed the outcome of it and have 
>>come to the conclusion, that there were two major factors which 
>>contributed to squeezing of code:
>>
>>   (1). usage of available variants for coding of the same thing
>>   (2). sqeezing the size of used numeric and string literals
> 
> 
> [snip]
> 
> 
>>Is there in Python any simple way to do the same as the following two 
>>following functions I have put together today:
> 
> 
> They are already pretty simple. You can make them even more simple by
> using less complicated names and getting rid of the explicit end block
> markers. It is sometimes useful to put in explicit end block markers when
> you have long blocks, but when the block is just a single line, well,
> I don't see the point.
> 
> Here is another possibility.
> 
> 
import array
A = array.array('b')
n = 100
while n:
> 
>  A.append(n&255); n = n >> 8
>  
> 
A.reverse()
A
> 
> array('b', [15, 66, 64])
> 
15*256**2 + 66*256 + 64
> 
> 100
> 
A.tostring()
> 
> '\x0fB@'
> 
> The reverse transformation is just as easy:
> 
> 
A = array.array('b', "\x0fB@")  # initialise from a byte string
n = 0L
for b in A:
> 
>  n = n << 8 | b
> 
> 
n
> 
> 100L
> 
> And of course these can be turned into functions.
> 
> 
> 
What I have thought about as a simpler/better solution is a method 
allowing to avoid processing the content of the string or long integer 
object by looping over its content. I suppose, that knowing enough about 
Python internals it must be possible to change only the object type not 
beeing forced to process the content i.e. the value itself, what in case 
of big size of data to convert with methods like this above wastes CPU 
time.

Claudio
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python coding contest

[Claudio Grondi]

Claudio Grondi wrote:
>> Please send me comments, suggestions and ideas.
> 
> 
> Now, after the contest is over I analysed the outcome of it and have 
> come to the conclusion, that there were two major factors which 
> contributed to squeezing of code:
> 
>   (1). usage of available variants for coding of the same thing
>   (2). sqeezing the size of used numeric and string literals
> 
> As (1) leads to less readable cryptic code it makes not much sense from 
> my point of view to dig deeper in that direction. As already mentioned 
> in this thread by Tim Peters ( pointing to 
> http://spoj.sphere.pl/problems/KAMIL/ ) it seems, that Pearl is here the 
> proper language of choice for such kind of problems anyway.
> 
> Trying to improve on (2) belongs in my eyes much more into the area of 
> problems discussed in comp.compression than to problems belonging into 
> comp.lang.python .
> 
> So what is my point? Ok, I will mention it at the end of this post.
> 
> Before that I want to thank the originators of the contest and 
> especially the participants for providing insight into the techniques 
> they have used. I have learned from the contest what lambda expression 
> is good for and how it works  where I failed to grasp it from reading 
> tutorials only.
> 
> I have detected, that it would be a nice thing to have in Python a 
> function able to convert values from binary string to an integer 
> representation as in my eyes both in case of long integer values are 
> more or less the same thing/object. The only difference is probably in 
> the header not in the representation of the actual value in memory - am 
> I right here? Will it make sense to have a string-integer object which 
> value can be used in both contexts as a binary string and a long integer 
> value?
> Is there in Python any simple way to do the same as the following two 
> following functions I have put together today:
> 
> def longIntWithBitsOfBinaryString(stringToConvert):
>   intWithBitsOfBinaryString = 0L
>   for singleChar in stringToConvert:
> intWithBitsOfBinaryString = (intWithBitsOfBinaryString<<8) + 
> ord(singleChar)
>   #:for
>   return intWithBitsOfBinaryString
> #:def longIntWithBitsOfBinaryString(s)
> 
> def binaryStringWithBitsOfLongInt(i):
>   listOfCharsOfStringWithThePackedInt = []
>   exponent = 1
>   while i > 256**exponent: exponent+=1
>   for byteNo in range(0,exponent):
> noOfBitsToShift = byteNo*8
> 
> listOfCharsOfStringWithThePackedInt.append(chr(i>>noOfBitsToShift&0xFF))
>   #:for
>   # reverse (in place) in order to get the highest bits of the integer 
> as leftmost byte
>   listOfCharsOfStringWithThePackedInt.reverse()
>   stringWithThePackedInt = ''.join(listOfCharsOfStringWithThePackedInt)
>   return stringWithThePackedInt
> #:def binaryStringWithBitsOfLongInt(i)
> 
> print "longIntWithBitsOfBinaryString('ABBA') = 
> %i"%longIntWithBitsOfBinaryString('ABBA')
> print 
> "binaryStringWithBitsOfLongInt(longIntWithBitsOfBinaryString('ABBA')) = 
> '%s'"%binaryStringWithBitsOfLongInt(longIntWithBitsOfBinaryString('ABBA'))
> 
> which gives:
> 
> longIntWithBitsOfBinaryString('ABBA') = 1094861377
> binaryStringWithBitsOfLongInt(longIntWithBitsOfBinaryString('ABBA')) = 
> 'ABBA'
> 
> ?
> 
> And now my point I have promised to write about:
> 
> If squeezing code makes it bad code and compressing literals is more or 
> less compression technique and not Python programming, it is maybe a 
> good idea to try to explore what Python distribution provides as data 
> and modules and rewrite the  seven_seg  module, but with following 
> limitations:
> 
> 1. it is not allowed to use any literals in the provided code
> 2. it is not allowed to misuse the names of the identifiers as a kind of 
> literals providing data
> 3. it is not allowed to use modules or files which doesn't come with the 
> Python distribution.
> 
> I have no slightest idea if it is possible to program a  seven_seg 
> module under such conditions. It could be a sign, that it would be a 
> very interesting challenge worth to get involved into or a sign I have 
> no slightest idea about Python and programming.
> 
> What do you all think about it?
> 
> Claudio
After some coding trials, it turned out to be quite easy (almost 
trivial) to overcome the problem of not beeing allowed to use any 
literals in the script code, but I suppose, that I am not alone with not 
seeing directly how to code it, so it is maybe a good exercise for a 
Python beginner (like me) to cope a bit with it.
Knowing this I am curious if it is also comparable easy in other 
programming languages, e.g. when using only a C/C++ compiler and linker 
executables along with the provided libraries and header files? I 
suppose, that each language comes with built-in literals which can be 
utilized in own code to get the full range of required literals into 
identifiers by using only what the language provides itself.
Am I right or not?

Claudio
-- 
http://mail.python.org/mailman/listinfo/pyth

Re: python coding contest

[Steven D'Aprano]

On Sun, 01 Jan 2006 03:34:33 +0100, Claudio Grondi wrote:

>> Please send me comments, suggestions and ideas.
> 
> Now, after the contest is over I analysed the outcome of it and have 
> come to the conclusion, that there were two major factors which 
> contributed to squeezing of code:
> 
>(1). usage of available variants for coding of the same thing
>(2). sqeezing the size of used numeric and string literals

[snip]

> Is there in Python any simple way to do the same as the following two 
> following functions I have put together today:

They are already pretty simple. You can make them even more simple by
using less complicated names and getting rid of the explicit end block
markers. It is sometimes useful to put in explicit end block markers when
you have long blocks, but when the block is just a single line, well,
I don't see the point.

Here is another possibility.

>>> import array
>>> A = array.array('b')
>>> n = 100
>>> while n:
... A.append(n&255); n = n >> 8
... 
>>> A.reverse()
>>> A
array('b', [15, 66, 64])
>>> 15*256**2 + 66*256 + 64
100
>>> A.tostring()
'\x0fB@'

The reverse transformation is just as easy:

>>> A = array.array('b', "\x0fB@")  # initialise from a byte string
>>> n = 0L
>>> for b in A:
... n = n << 8 | b
...
>>> n
100L

And of course these can be turned into functions.



-- 
Steven.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python coding contest

[Claudio Grondi]

> Please send me comments, suggestions and ideas.

Now, after the contest is over I analysed the outcome of it and have 
come to the conclusion, that there were two major factors which 
contributed to squeezing of code:

   (1). usage of available variants for coding of the same thing
   (2). sqeezing the size of used numeric and string literals

As (1) leads to less readable cryptic code it makes not much sense from 
my point of view to dig deeper in that direction. As already mentioned 
in this thread by Tim Peters ( pointing to 
http://spoj.sphere.pl/problems/KAMIL/ ) it seems, that Pearl is here the 
proper language of choice for such kind of problems anyway.

Trying to improve on (2) belongs in my eyes much more into the area of 
problems discussed in comp.compression than to problems belonging into 
comp.lang.python .

So what is my point? Ok, I will mention it at the end of this post.

Before that I want to thank the originators of the contest and 
especially the participants for providing insight into the techniques 
they have used. I have learned from the contest what lambda expression 
is good for and how it works  where I failed to grasp it from reading 
tutorials only.

I have detected, that it would be a nice thing to have in Python a 
function able to convert values from binary string to an integer 
representation as in my eyes both in case of long integer values are 
more or less the same thing/object. The only difference is probably in 
the header not in the representation of the actual value in memory - am 
I right here? Will it make sense to have a string-integer object which 
value can be used in both contexts as a binary string and a long integer 
value?
Is there in Python any simple way to do the same as the following two 
following functions I have put together today:

def longIntWithBitsOfBinaryString(stringToConvert):
   intWithBitsOfBinaryString = 0L
   for singleChar in stringToConvert:
 intWithBitsOfBinaryString = (intWithBitsOfBinaryString<<8) + 
ord(singleChar)
   #:for
   return intWithBitsOfBinaryString
#:def longIntWithBitsOfBinaryString(s)

def binaryStringWithBitsOfLongInt(i):
   listOfCharsOfStringWithThePackedInt = []
   exponent = 1
   while i > 256**exponent: exponent+=1
   for byteNo in range(0,exponent):
 noOfBitsToShift = byteNo*8
 
listOfCharsOfStringWithThePackedInt.append(chr(i>>noOfBitsToShift&0xFF))
   #:for
   # reverse (in place) in order to get the highest bits of the integer 
as leftmost byte
   listOfCharsOfStringWithThePackedInt.reverse()
   stringWithThePackedInt = ''.join(listOfCharsOfStringWithThePackedInt)
   return stringWithThePackedInt
#:def binaryStringWithBitsOfLongInt(i)

print "longIntWithBitsOfBinaryString('ABBA') = 
%i"%longIntWithBitsOfBinaryString('ABBA')
print 
"binaryStringWithBitsOfLongInt(longIntWithBitsOfBinaryString('ABBA')) = 
'%s'"%binaryStringWithBitsOfLongInt(longIntWithBitsOfBinaryString('ABBA'))

which gives:

longIntWithBitsOfBinaryString('ABBA') = 1094861377
binaryStringWithBitsOfLongInt(longIntWithBitsOfBinaryString('ABBA')) = 
'ABBA'

?

And now my point I have promised to write about:

If squeezing code makes it bad code and compressing literals is more or 
less compression technique and not Python programming, it is maybe a 
good idea to try to explore what Python distribution provides as data 
and modules and rewrite the  seven_seg  module, but with following 
limitations:

1. it is not allowed to use any literals in the provided code
2. it is not allowed to misuse the names of the identifiers as a kind of 
literals providing data
3. it is not allowed to use modules or files which doesn't come with the 
Python distribution.

I have no slightest idea if it is possible to program a  seven_seg 
module under such conditions. It could be a sign, that it would be a 
very interesting challenge worth to get involved into or a sign I have 
no slightest idea about Python and programming.

What do you all think about it?

Claudio
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python coding contest

[Christian Tismer]

Hans Nowak wrote:

>...  for u in(3,14,10))
> 
> can be written as:
> 
>...  for u in 3,14,10)
> 
> which would shave off a character.  Tuples don't always need parentheses...

This would work with a list comprehension.
Doesn't work with a generator expression
(thought of it, too, and the list comprehension eats one char)

cheers - chris
-- 
Christian Tismer :^)   
tismerysoft GmbH : Have a break! Take a ride on Python's
Johannes-Niemeyer-Weg 9A :*Starship* http://starship.python.net/
14109 Berlin : PGP key -> http://wwwkeys.pgp.net/
work +49 30 802 86 56  mobile +49 173 24 18 776  fax +49 30 80 90 57 05
PGP 0x57F3BF04   9064 F4E1 D754 C2FF 1619  305B C09C 5A3B 57F3 BF04
  whom do you want to sponsor today?   http://www.stackless.com/
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python coding contest

[Hans Nowak]

André wrote:
> Hans Nowak wrote:
> 
>>André wrote:
> 
> 
>>I don't know if this suggestion has been made already, but it seems to
>>me that the end of the expression
>>
>>   ...  for u in(3,14,10))
>>
>>can be written as:
>>
>>   ...  for u in 3,14,10)
>>
>>which would shave off a character.  Tuples don't always need parentheses...
>>
> 
> I tried ... but, in this case, it appears that they do, unfortunately
> :-(

Ah, you are right.  It works for a list comprehension, but not for a 
genexp. :-(

-- 
Hans Nowak
http://zephyrfalcon.org/
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python coding contest

[André]

Hans Nowak wrote:
> André wrote:

>
> I don't know if this suggestion has been made already, but it seems to
> me that the end of the expression
>
>...  for u in(3,14,10))
>
> can be written as:
>
>...  for u in 3,14,10)
>
> which would shave off a character.  Tuples don't always need parentheses...
>
I tried ... but, in this case, it appears that they do, unfortunately
:-(

André

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python coding contest

[Hans Nowak]

André wrote:
> Christian Tismer wrote:

>>It seems to be very hard to improve. No idea if this is
>>possible: One might try to re-order the character string
>>a bit to change moduli, trying to get one more number in
>>
>>(3,14,10)
>>
>>to be one-digit. Haven't tried, yet, and chances are small.
>>
>>congrats again and a happy new year - chris
> 
> 
> With the string of " _|" I used, starting sub-indices for each
> 3-character substrings are such that one need modulo 10 (or greater)
> for at least two of the three indices.  I have looked at a few other
> combinations and, after thinking about it, have convinced myself that
> it is unfortunately not possible to do.  I would love to be proven
> wrong!  Good idea though!

I don't know if this suggestion has been made already, but it seems to 
me that the end of the expression

   ...  for u in(3,14,10))

can be written as:

   ...  for u in 3,14,10)

which would shave off a character.  Tuples don't always need parentheses...

-- 
Hans Nowak
http://zephyrfalcon.org/
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python coding contest

[André]

Christian Tismer wrote:
> André wrote:
> > For the few that might be interested, I will be posting the details of
> > a 117 character long solution to the challenge on my blog
> > http://aroberge.blogspot.com/.
>
...
> It seems to be very hard to improve. No idea if this is
> possible: One might try to re-order the character string
> a bit to change moduli, trying to get one more number in
>
> (3,14,10)
>
> to be one-digit. Haven't tried, yet, and chances are small.
>
> congrats again and a happy new year - chris

With the string of " _|" I used, starting sub-indices for each
3-character substrings are such that one need modulo 10 (or greater)
for at least two of the three indices.  I have looked at a few other
combinations and, after thinking about it, have convinced myself that
it is unfortunately not possible to do.  I would love to be proven
wrong!  Good idea though!

Happy New Year to you all!

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python coding contest

[Christian Tismer]

André wrote:
> For the few that might be interested, I will be posting the details of
> a 117 character long solution to the challenge on my blog
> http://aroberge.blogspot.com/.

Congratulations!
I'm very impressed by this elegant solution.
It seems to be very hard to improve. No idea if this is
possible: One might try to re-order the character string
a bit to change moduli, trying to get one more number in

(3,14,10)

to be one-digit. Haven't tried, yet, and chances are small.

congrats again and a happy new year - chris

-- 
Christian Tismer :^)   
tismerysoft GmbH : Have a break! Take a ride on Python's
Johannes-Niemeyer-Weg 9A :*Starship* http://starship.python.net/
14109 Berlin : PGP key -> http://wwwkeys.pgp.net/
work +49 30 802 86 56  mobile +49 173 24 18 776  fax +49 30 80 90 57 05
PGP 0x57F3BF04   9064 F4E1 D754 C2FF 1619  305B C09C 5A3B 57F3 BF04
  whom do you want to sponsor today?   http://www.stackless.com/
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python coding contest

[Christoph Zwerschke]

Just wrote:
> Duh, sorry, it's early. 118 is better than 119. Printable or not :) 
> Still, a 119 bytes version that is fully printable is pretty cool.

No, you're right, I also somehow missed the point. I believed "»" to be 
"printable" (opposed to control char's) but technically speaking, the 
consensus is that "printable" restricts to 7-bit-ascii (in Python, 
string.printable does not even change if you change the locale setting, 
contrary to string.letters; this is a bit unclear in the Python docs).

Mark's point was that his solution was purely 7-bit-ascii printable and 
as such it was good although it was one byte more.

In the next contest, there should be subcategories for solutions that 
are 7-bit-printable and/or have no imports.

-- Christoph
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python coding contest

[Paddy]

So, testosterone wins again!

We get to boast:
  "Mine's smaller than your's"

Lets wait for Pythonic to go to bed, then sneak downstairs, go to that
tripple-X rated 'shortest solutions' website, and 'whack-off' some
solutions.
Unghhh,  my solution... its coming!!!

Well don't forget to clean up before Pythonic wakes up.

Happy new year :-)

- Pad.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python coding contest

[Just]

In article <[EMAIL PROTECTED]>,
 Just <[EMAIL PROTECTED]> wrote:

> In article <[EMAIL PROTECTED]>,
>  Christoph Zwerschke <[EMAIL PROTECTED]> wrote:
> 
> > Mark Dickinson wrote:
> > > Here's a variant of André's brilliant idea that's
> > > 119 characters long, and fully printable:
> > > 
> > > j=''.join;seven_seg=lambda z:j(j('   _  | |_ _|_|'
> > > [ord('^r|=Zm.:v\r'[int(a)])%u*2:][:3]for a in z)
> > > +"\n"for u in(3,7,8))
> > 
> > You have an escaped CR (\r) as the last character in your string.
> 
> Which is perfectly printable.
> 
> > Here is a 118 character fully printable variant without the \r:
> > 
> > j=''.join;seven_seg=lambda x:j(j('   _  |_|_ _| 
> > |'[ord('^rm=3|4:s»'[int(c)])%d*2:][:3]for c in x)+"\n"for d in(3,8,7))
> > 
> > Note that there is only one non-ascii character in the code.
> 
> Which isn't. So I'm not sure what the point is you're trying to make.

Duh, sorry, it's early. 118 is better than 119. Printable or not :) 
Still, a 119 bytes version that is fully printable is pretty cool.

Just
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python coding contest

[Just]

In article <[EMAIL PROTECTED]>,
 Christoph Zwerschke <[EMAIL PROTECTED]> wrote:

> Mark Dickinson wrote:
> > Here's a variant of André's brilliant idea that's
> > 119 characters long, and fully printable:
> > 
> > j=''.join;seven_seg=lambda z:j(j('   _  | |_ _|_|'
> > [ord('^r|=Zm.:v\r'[int(a)])%u*2:][:3]for a in z)
> > +"\n"for u in(3,7,8))
> 
> You have an escaped CR (\r) as the last character in your string.

Which is perfectly printable.

> Here is a 118 character fully printable variant without the \r:
> 
> j=''.join;seven_seg=lambda x:j(j('   _  |_|_ _| 
> |'[ord('^rm=3|4:s»'[int(c)])%d*2:][:3]for c in x)+"\n"for d in(3,8,7))
> 
> Note that there is only one non-ascii character in the code.

Which isn't. So I'm not sure what the point is you're trying to make.

Just
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python coding contest

[Christoph Zwerschke]

Mark Dickinson wrote:
> Here's a variant of André's brilliant idea that's
> 119 characters long, and fully printable:
> 
> j=''.join;seven_seg=lambda z:j(j('   _  | |_ _|_|'
> [ord('^r|=Zm.:v\r'[int(a)])%u*2:][:3]for a in z)
> +"\n"for u in(3,7,8))

You have an escaped CR (\r) as the last character in your string.

Here is a 118 character fully printable variant without the \r:

j=''.join;seven_seg=lambda x:j(j('   _  |_|_ _| 
|'[ord('^rm=3|4:s»'[int(c)])%d*2:][:3]for c in x)+"\n"for d in(3,8,7))

Note that there is only one non-ascii character in the code.

However, André's final solution is one character shorter (117).

-- Christoph
-- 
http://mail.python.org/mailman/listinfo/python-list

python coding contest

[Mark Dickinson]

Here's a variant of André's brilliant idea that's
119 characters long, and fully printable:

j=''.join;seven_seg=lambda z:j(j('   _  | |_ _|_|'
[ord('^r|=Zm.:v\r'[int(a)])%u*2:][:3]for a in z)
+"\n"for u in(3,7,8))

Mark
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python coding contest

[Marius Gedminas]

I managed it with vim.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python coding contest

[André]

Claudio Grondi wrote:
>
> P.S. By the way: on Windows XP with UltraEdit there was no problem to
> input the special characters. There is an ASCII table and a HEX editor
> mode available for it. Any hints which free editor makes it possible, too?

I simply used Pythonwin.  (print chr(3), then cut and paste the result
in my python file).

André

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python coding contest

[André]

Shane Hathaway wrote:
> Claudio Grondi wrote:
> > so I tried all which made sense in the context of '0' conversion and
> > found out, that it should be the
> >
> >' _   |_|_ _| |'
> >
> > not the at http://aroberge.blogspot.com/
> >
> >' _ |_|_ _| |'
>
> The HTML source has the three spaces.  If the code had been surrounded
> by a "pre" tag, it would have rendered correctly.
>
> Shane

Thanks, I hadn't noticed that.  It should be fixed now.

André

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python coding contest

[Shane Hathaway]

Claudio Grondi wrote:
> so I tried all which made sense in the context of '0' conversion and 
> found out, that it should be the
> 
>' _   |_|_ _| |'
> 
> not the at http://aroberge.blogspot.com/
> 
>' _ |_|_ _| |'

The HTML source has the three spaces.  If the code had been surrounded 
by a "pre" tag, it would have rendered correctly.

Shane
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python coding contest

[Claudio Grondi]

André wrote:
> For the few that might be interested, I will be posting the details of
> a 117 character long solution to the challenge on my blog
> http://aroberge.blogspot.com/.
> 
> Enjoy!
> 
> André
> 
It doesn't work for me as described on that page.
The output is scrumbled. It seems, that the 12 bytes long string ' _ 
|_|_ _| |' is the reason, as the index [11] to it gives '|' not the 
expected '| |'.

There are a total of 24 following 14 bytes strings possible for use in 
coding of indexes to all necessary character triples:

   '   | |_ _ _|_|'
   '   | |_|_ _ _|'
   '   |_ _ _| |_|'
   '   |_ _ _|_| |'
   '   |_| |_ _ _|'
   '   |_|_ _ _| |'
   ' _   | |_ _|_|'
   ' _   | |_|_ _|'
   ' _   |_ _| |_|'
   ' _   |_ _|_| |'
   ' _   |_| |_ _|'
   ' _   |_|_ _| |'
   ' _ _| |_   |_|'
   ' _ _| |_|_   |'
   ' _ _|_   | |_|'
   ' _ _|_   |_| |'
   ' _ _|_| |_   |'
   ' _ _|_|_   | |'
   ' _| |_ _   |_|'
   ' _| |_|_ _   |'
   ' _|_ _   | |_|'
   ' _|_ _   |_| |'
   ' _|_| |_ _   |'
   ' _|_|_ _   | |'

so I tried all which made sense in the context of '0' conversion and 
found out, that it should be the

   ' _   |_|_ _| |'

not the at http://aroberge.blogspot.com/

   ' _ |_|_ _| |'

given one to make the described algorithm work as expected.
Anyway, the code with the two bytes longer string is 117 bytes long, so 
the announcement of a 117 bytes long code keeps what it promises.

Excellent work!

What I wonder about is, how the author arrived at that solution? Trying 
all of the 24 available 14 byte strings to see which one produces the 
coding table which can be used as it was used? Trial-and-error over 
using division, modulo, shifting, masking? What was the path of thought 
to arrive at that? Knowing the solution seems to be of little value if 
not knowing how to arrive at it when a similar problem comes up in the 
future.

Claudio
P.S. By the way: on Windows XP with UltraEdit there was no problem to 
input the special characters. There is an ASCII table and a HEX editor 
mode available for it. Any hints which free editor makes it possible, too?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python coding contest

[Tim Hochberg]

Shane Hathaway wrote:
> André wrote:
> 
>>For the few that might be interested, I will be posting the details of
>>a 117 character long solution to the challenge on my blog
>>http://aroberge.blogspot.com/.
>>
>>Enjoy!
> 
> 
> You took advantage of prime numbers, enabling you to extract encoded 
> information using a single modulus operation rather than shift and mask. 
>   Brilliant strategy.  Congratulations.

Indeed. Very impressive. And thanks for posting, it was driving me nuts.

Now I wonder if this could be adapted to the other, three loop strategy? 
It's not clear, but there are three characters that are superfulous in 
the current incarnation of that. Hmmm..

-tim

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python coding contest

[Shane Hathaway]

André wrote:
> For the few that might be interested, I will be posting the details of
> a 117 character long solution to the challenge on my blog
> http://aroberge.blogspot.com/.
> 
> Enjoy!

You took advantage of prime numbers, enabling you to extract encoded 
information using a single modulus operation rather than shift and mask. 
  Brilliant strategy.  Congratulations.

Shane
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python coding contest

[André]

For the few that might be interested, I will be posting the details of
a 117 character long solution to the challenge on my blog
http://aroberge.blogspot.com/.

Enjoy!

André

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python coding contest

[Claudio Grondi]

[EMAIL PROTECTED] wrote:
> Thomas Heller wrote:
> 
>>X=' _ _ _  |  _| _ |_|_'
>>Y=0x23018F406A3530EC273F008
>>j="".join
>>seven_seg=lambda n:j(j(c)+"\n"for c in zip(*[X[Y>>m+int(d)*9&7::8]for d in n 
>>for m in(6,3,0)]))
> 
> 
> Interesting bit:
> 
> Although there are more 3-char combinations when you read vertically,
> they compact better.
> 
> If A=" ", B="_" and C="|", this 12 char string contains al possible
> combinations:
> 
> BBBABAAACACC
> 
> which is 2 chars shorter than the best for horizontal combinations:
> 
> ABAAACBABCBCAC
> 
> Still, I don't think this vertical idea can go below 123 or 124, but
> it's good :-)
> 
> Now I wonder what the 119 solution is!
> 
I suppose the known 120 solution twisted to work with a one byte shorter 
string as you already found it out providing one example of it above, 
right?  :-)

Claudio
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python coding contest

[Shane Hathaway]

Szabolcs Nagy wrote:
> my two solutions (well I wasn't so clever to encode everything in
> strings instead of numbers, but at least it won't give warnings about
> non ascii characters):
> 128:
> j,seven_seg=''.join,lambda s:j(j(' |_ |'[i>>3*int(c)&b]for c in s for b
> in(4,2,1))+'\n'for i in(306775170,1060861645,524130191))
> 
> 122:
> seven_seg=lambda s,j=''.join:j(j(' _   _|_| |_
> |'[i>>3*int(c)&14:][:3]for c in s)+'\n'for i
> in(8208,934111592,664455910))

FWIW, here's my 121 character solution that's fully printable.  (Line 
breaks added.)

seven_seg=lambda s,j=''.join:j(j(
'   _ _| |_  |_|'[ord('^-TR5bfmvr'[int(c)])/b%8*2:][:3]for c in s)+'\n'
for b in(64,8,1))

This solution uses the 7 lower bits of every encoded byte, rather than 
the 7 upper bits that the 8 bit solutions use.  8 bits make it possible 
to avoid multiplying by 2, but I wanted this version to use pure ASCII, 
so I had to multiply by 2.  The choice to divide rather than shift is 
important because it allowed me to eliminate parentheses.

It's interesting that there seems to be no room for special cases.  For 
example, the top row has only two states and those states are not used 
by the other rows.  Therefore, the top row could be computed in a much 
simpler way than the other two rows, and the other two rows could be 
simplified by having only 5 possible states rather than 7.  However, all 
my attempts to exploit this property produced larger code.

Shane
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python coding contest

[Szabolcs Nagy]

my two solutions (well I wasn't so clever to encode everything in
strings instead of numbers, but at least it won't give warnings about
non ascii characters):
128:
j,seven_seg=''.join,lambda s:j(j(' |_ |'[i>>3*int(c)&b]for c in s for b
in(4,2,1))+'\n'for i in(306775170,1060861645,524130191))

122:
seven_seg=lambda s,j=''.join:j(j(' _   _|_| |_
|'[i>>3*int(c)&14:][:3]for c in s)+'\n'for i
in(8208,934111592,664455910))

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python coding contest

[Shane Hathaway]

Tim Hochberg wrote:
> g=''.join;seven_seg=lambda i:g(
> g(' _|x|'[ord("~$]m'k{d\x7fo"[int(n)])>>s&j]
> for n in i for j in(2,1,4))+'\n'for s in(6,0,3))
> 
> I've replaced the unprintable characters and added some preemptive 
> linebreaks so that hopefully this won't get too munged. It's all clear 
> now, right? Two hints: 6,0,3->row, 2,1,4->column and the 6 and 1 have to 
> be where they are to exploit the property that the top row only ever has 
> a center character in it. That way things can be encoded in 7-bits and 
> fit in a character string that Python likes. The order of the other loop 
> indices is mostly accidental but not all permutations may work.

I worked on a similar solution, but didn't have the idea of iterating 
over a series of masks as you did with the 'j' variable.  Good work.

> I'm off to try to figure out how to do it the other way now, before the 
> code gets revealed.

We should have more contests like this.  While the skills I applied for 
the contest don't have much practical value, the mental exercise was great.

Shane
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python coding contest

[Michael Spencer]

Tim Hochberg wrote:
> Shane Hathaway wrote:
>> Andrew Durdin wrote:
>>
>>> On 12/28/05, Shane Hathaway <[EMAIL PROTECTED]> wrote:
>>>
>>>
 I just found a 125 character solution.  It's actually faster and more
 readable than the 133 character solution (though it's still obscure.)
>>>
>>> Having spent a good deal of time and effort, and not getting below 144
>>> characters, I am now very eager to see how these shorter versions
>>> work, particularly the 6  120-character solutions. I also expect that
>>> someone (I'll certainly give it a try) will produce a yet shorter
>>> version after the contest closes, based on the knowledge from the
>>> winning solutions.
>>
>> Roberto Alsina fully documented his 120 byte solution here:
>>
>> http://www.pycs.net/lateral/weblog/2005/12/29.html#P333
>>
>> My 120 byte solution is equivalent.  Many others probably did the same 
>> thing.  Python's philosophy of one way to do it seems to be leading us 
>> all down the same road.
>>
>> However, it still feels like there's room for improvement.  I have a 123 
>> byte solution based on a fairly repetitive 21 character string; if I 
>> could compress the representation of the string, it could win.
> 
> Apparently there was as someone put out a 119 byte solution. I can't get 
> to Roberto's code at present (perhaps he's suffering a bandwidth 
> crisis?), but it seems that my 120 character solution is different. It 
> sounds like he encoded his as a row at a time and did two loops one for 
> each character and one for each row. I encoded the data per character 
> and did three loops one per column, one per character and one per row. 
> I'm sure that's not clear, so here's the code:
> 
> g=''.join;seven_seg=lambda i:g(
> g(' _|x|'[ord("~$]m'k{d\x7fo"[int(n)])>>s&j]
> for n in i for j in(2,1,4))+'\n'for s in(6,0,3))
> 
> I've replaced the unprintable characters and added some preemptive 
> linebreaks so that hopefully this won't get too munged. It's all clear 
> now, right? Two hints: 6,0,3->row, 2,1,4->column and the 6 and 1 have to 
> be where they are to exploit the property that the top row only ever has 
> a center character in it. That way things can be encoded in 7-bits and 
> fit in a character string that Python likes. The order of the other loop 
> indices is mostly accidental but not all permutations may work.
> 
> I'm off to try to figure out how to do it the other way now, before the 
> code gets revealed.
> 
> 
> -tim
> -tim
> 
> 
Mine was practically identical, but with another permutation of the loop 
variables:

seven_seg=lambda n,s="".join:s(
s(" _| |"[ord('w\x12][:koR\x7f{'[int(i)])>>r&j]
for i in n for j in(4,1,2))+"\n"for r in(6,3,0))

More evidence that 'there is one obvious way to do it' ;-)

Still curious about 119, though

Michael



-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python coding contest

[Tim Hochberg]

Shane Hathaway wrote:
> Andrew Durdin wrote:
> 
>>On 12/28/05, Shane Hathaway <[EMAIL PROTECTED]> wrote:
>>
>>
>>>I just found a 125 character solution.  It's actually faster and more
>>>readable than the 133 character solution (though it's still obscure.)
>>
>>
>>Having spent a good deal of time and effort, and not getting below 144
>>characters, I am now very eager to see how these shorter versions
>>work, particularly the 6  120-character solutions. I also expect that
>>someone (I'll certainly give it a try) will produce a yet shorter
>>version after the contest closes, based on the knowledge from the
>>winning solutions.
> 
> 
> Roberto Alsina fully documented his 120 byte solution here:
> 
> http://www.pycs.net/lateral/weblog/2005/12/29.html#P333
> 
> My 120 byte solution is equivalent.  Many others probably did the same 
> thing.  Python's philosophy of one way to do it seems to be leading us 
> all down the same road.
> 
> However, it still feels like there's room for improvement.  I have a 123 
> byte solution based on a fairly repetitive 21 character string; if I 
> could compress the representation of the string, it could win.

Apparently there was as someone put out a 119 byte solution. I can't get 
to Roberto's code at present (perhaps he's suffering a bandwidth 
crisis?), but it seems that my 120 character solution is different. It 
sounds like he encoded his as a row at a time and did two loops one for 
each character and one for each row. I encoded the data per character 
and did three loops one per column, one per character and one per row. 
I'm sure that's not clear, so here's the code:

g=''.join;seven_seg=lambda i:g(
g(' _|x|'[ord("~$]m'k{d\x7fo"[int(n)])>>s&j]
for n in i for j in(2,1,4))+'\n'for s in(6,0,3))

I've replaced the unprintable characters and added some preemptive 
linebreaks so that hopefully this won't get too munged. It's all clear 
now, right? Two hints: 6,0,3->row, 2,1,4->column and the 6 and 1 have to 
be where they are to exploit the property that the top row only ever has 
a center character in it. That way things can be encoded in 7-bits and 
fit in a character string that Python likes. The order of the other loop 
indices is mostly accidental but not all permutations may work.

I'm off to try to figure out how to do it the other way now, before the 
code gets revealed.


-tim
-tim


-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python coding contest

[roberto . alsina]

Thomas Heller wrote:
> X=' _ _ _  |  _| _ |_|_'
> Y=0x23018F406A3530EC273F008
> j="".join
> seven_seg=lambda n:j(j(c)+"\n"for c in zip(*[X[Y>>m+int(d)*9&7::8]for d in n 
> for m in(6,3,0)]))

Interesting bit:

Although there are more 3-char combinations when you read vertically,
they compact better.

If A=" ", B="_" and C="|", this 12 char string contains al possible
combinations:

BBBABAAACACC

which is 2 chars shorter than the best for horizontal combinations:

ABAAACBABCBCAC

Still, I don't think this vertical idea can go below 123 or 124, but
it's good :-)

Now I wonder what the 119 solution is!

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python coding contest

[Thomas Heller]

Shane Hathaway <[EMAIL PROTECTED]> writes:

> Andrew Durdin wrote:
>> On 12/28/05, Shane Hathaway <[EMAIL PROTECTED]> wrote:
>>
>>>I just found a 125 character solution.  It's actually faster and more
>>>readable than the 133 character solution (though it's still obscure.)
>> Having spent a good deal of time and effort, and not getting below
>> 144
>> characters, I am now very eager to see how these shorter versions
>> work, particularly the 6  120-character solutions. I also expect that
>> someone (I'll certainly give it a try) will produce a yet shorter
>> version after the contest closes, based on the knowledge from the
>> winning solutions.
>
> Roberto Alsina fully documented his 120 byte solution here:
>
> http://www.pycs.net/lateral/weblog/2005/12/29.html#P333
>
> My 120 byte solution is equivalent.  Many others probably did the same
> thing.  Python's philosophy of one way to do it seems to be leading us
> all down the same road.

Here's a different way: it generates the output column-wise, then uses
zip to assemble line-wise.  The additional loop around zip's result
probably kills it, for easier redability it's 163 bytes, but a few bytes
could easily be spared.

Thomas

X=' _ _ _  |  _| _ |_|_'
Y=0x23018F406A3530EC273F008
j="".join
seven_seg=lambda n:j(j(c)+"\n"for c in zip(*[X[Y>>m+int(d)*9&7::8]for d in n 
for m in(6,3,0)]))


-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python coding contest

[Shane Hathaway]

Andrew Durdin wrote:
> On 12/28/05, Shane Hathaway <[EMAIL PROTECTED]> wrote:
> 
>>I just found a 125 character solution.  It's actually faster and more
>>readable than the 133 character solution (though it's still obscure.)
> 
> 
> Having spent a good deal of time and effort, and not getting below 144
> characters, I am now very eager to see how these shorter versions
> work, particularly the 6  120-character solutions. I also expect that
> someone (I'll certainly give it a try) will produce a yet shorter
> version after the contest closes, based on the knowledge from the
> winning solutions.

Roberto Alsina fully documented his 120 byte solution here:

http://www.pycs.net/lateral/weblog/2005/12/29.html#P333

My 120 byte solution is equivalent.  Many others probably did the same 
thing.  Python's philosophy of one way to do it seems to be leading us 
all down the same road.

However, it still feels like there's room for improvement.  I have a 123 
byte solution based on a fairly repetitive 21 character string; if I 
could compress the representation of the string, it could win.

Shane
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python coding contest

[Andrew Durdin]

On 12/28/05, Shane Hathaway <[EMAIL PROTECTED]> wrote:
> I just found a 125 character solution.  It's actually faster and more
> readable than the 133 character solution (though it's still obscure.)

Having spent a good deal of time and effort, and not getting below 144
characters, I am now very eager to see how these shorter versions
work, particularly the 6  120-character solutions. I also expect that
someone (I'll certainly give it a try) will produce a yet shorter
version after the contest closes, based on the knowledge from the
winning solutions.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python coding contest

[Christian Tismer]

Duncan Booth wrote:
> Christian Tismer wrote:
> 
>> And then help me to setup a different contest about content -- chris
>>
> Count me in.

Great! Let's find a problem small enough to solve in reasonably
time and large enough to exploit Python qualities.

sincerely -- chris (below 130)

-- 
Christian Tismer :^)   
tismerysoft GmbH : Have a break! Take a ride on Python's
Johannes-Niemeyer-Weg 9A :*Starship* http://starship.python.net/
14109 Berlin : PGP key -> http://wwwkeys.pgp.net/
work +49 30 802 86 56  mobile +49 173 24 18 776  fax +49 30 80 90 57 05
PGP 0x57F3BF04   9064 F4E1 D754 C2FF 1619  305B C09C 5A3B 57F3 BF04
  whom do you want to sponsor today?   http://www.stackless.com/
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python coding contest

[Simon Hengel]

> It seems, that the site had some trouble to stay online and especially 
> to provide the ranking today.
There was a problem with our server, sorry for that.

Have fun,

Simon Hengel
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python coding contest

[Claudio Grondi]

Simon Hengel wrote:
> Hello,
> we are hosting a python coding contest an we even managed to provide a
> price for the winner...
> 
> http://pycontest.net/
> 
> The contest is coincidentally held during the 22c3 and we will be
> present there.
> 
> https://events.ccc.de/congress/2005/wiki/Python_coding_contest
> 
> Please send me comments, suggestions and ideas.
> 
> Have fun,
> 

It seems, that the site had some trouble to stay online and especially 
to provide the ranking today.

I am a bit dissapointed, that my idea of not duplicating, but utilizing 
the efforts others put into solving the job (titled by the submitter ID 
'TheParasite') which resulted in a submission of a 15 Bytes large full 
functional module was evaluated as having a 'syntax error' problem and 
was placed in the ranking at the position according to the size of the 
331 byte large .zip archive it was put into along with some necessary 
installation instructions.

By the way: trying to submit along with the module complete installation 
instructions and comments failed because there is a 345 bytes limit for 
size of allowed uploads.

Claudio
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python coding contest

[Marius Gedminas]

I cannot reach the contest site at since all this morning.  :-(

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python coding contest

[Marius Gedminas]

I cannot not reach the contest site at since all this morning.  :-(

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python coding contest

[Simon Hengel]

> A funny thing happened to me.
> 
>The http://www.pycontest.net/ site was down for some minutes because :
> 
>"A problem occurred in a Python script. "
> 
> it seems, that
> 
>'some clever cheat'
> 
> has crashed it.
That was me, i broke things while tweaking some stuff.

Sorry for the inconveniences,

Simon Hengel

-- 
python coding contest - http://www.pycontest.net/

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python coding contest

[Simon Hengel]

Hello,

> After all, I'd really love to set up another contest with
> different measures and criteria.

for future events i will take a close look at other possibilities for
doing a ranking. At the moment the 22c3 and the contest is eating up all
my time. Pleas appreciate that i may not keep up with all mails. Sorry
for that.

Cheers,

-- 
python coding contest - http://www.pycontest.net/


-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python coding contest

[Simon Hengel]

> the dream of winning the contest seems to be over.

Sorry for that, I'm considering doing a ranking on the nicest cheats too.

Have fun,

Simon Hengel

-- 
python coding contest - http://www.pycontest.net/

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python coding contest

[Claudio Grondi]

Simon Hengel wrote:
> Hello,
> we are hosting a python coding contest an we even managed to provide a
> price for the winner...
> 
> http://pycontest.net/
> 
> The contest is coincidentally held during the 22c3 and we will be
> present there.
> 
> https://events.ccc.de/congress/2005/wiki/Python_coding_contest
> 
> Please send me comments, suggestions and ideas.
> 
> Have fun,
> 

A funny thing happened to me.

   The http://www.pycontest.net/ site was down for some minutes because :

   "A problem occurred in a Python script. "

it seems, that

   'some clever cheat'

has crashed it.

Claudio
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python coding contest

[Tim Peters]

[Bengt Richter]
> ...
> [23:28] C:\pywk\clp\seven\pycontest_01>wc -lc  seven_seg.py
>   2136  seven_seg.py
>
> 2 lines, 136 chars including unix-style lineseps (is that cheating on 
> windows?)

Na.  Most native Windows apps (including native Windows Python) don't
care whether \n or \r\n in used as the line terminator in text files. 
This is because the platform C library changes \r\n to \n on input of
a text-mode file, and leaves \n alone:  the difference is literally
invisible to most apps.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python coding contest

[Tim Hochberg]

Marius Gedminas wrote:
> Jean-Paul Calderone wrote:
> 
>>On Tue, 27 Dec 2005 14:02:57 -0700, Tim Hochberg <[EMAIL PROTECTED]> wrote:
>>
>>>Shane Hathaway wrote:
>>>
Paul McGuire wrote:


Also, here's another cheat version.  (No, 7seg.com does not exist.)

   import urllib2
   def seven_seg(x):return urllib2.urlopen('http://7seg.com/'+x).read()

>>>
>>>And another one from me as well.
>>>
>>>class a:
>>> def __eq__(s,o):return 1
>>>seven_seg=lambda i:a()
>>>
>>
>>This is shorter as "__eq__=lambda s,o:1".
> 
> 
> Or even
> 
>   class seven_seg(str):__eq__=lambda*a:1
> 
> 39 characters; passes the test suite.  I'm sure it would be
> disqualified for cheating, though. :-)


Tricky. That leads to this 30 character gem:

class seven_seg(str):__eq__=id

-tim

> 
> 
>>But I can't find the first post in this thread... What are you
>>guys talking about?
> 
> 
> http://www.pycontest.net
> 

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python coding contest

[Marius Gedminas]

Jean-Paul Calderone wrote:
> On Tue, 27 Dec 2005 14:02:57 -0700, Tim Hochberg <[EMAIL PROTECTED]> wrote:
> >Shane Hathaway wrote:
> >> Paul McGuire wrote:
> >>
> >>
> >> Also, here's another cheat version.  (No, 7seg.com does not exist.)
> >>
> >>import urllib2
> >>def seven_seg(x):return urllib2.urlopen('http://7seg.com/'+x).read()
> >>
> >And another one from me as well.
> >
> >class a:
> >  def __eq__(s,o):return 1
> >seven_seg=lambda i:a()
> >
>
> This is shorter as "__eq__=lambda s,o:1".

Or even

  class seven_seg(str):__eq__=lambda*a:1

39 characters; passes the test suite.  I'm sure it would be
disqualified for cheating, though. :-)

> But I can't find the first post in this thread... What are you
> guys talking about?

http://www.pycontest.net

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python coding contest

[Tim Hochberg]

Shane Hathaway wrote:
> I just found a 125 character solution.  It's actually faster and more 
> readable than the 133 character solution (though it's still obscure.)
> 
> It depends on Python 2.4.  If Python 2.3 compatibility is required for 
> the contest, I have to add 4 characters.

I asked, 2.4 is OK.

Drat: I had a 128 char solution I was keeping in reserve. Now it's back 
to the drawing board

-tim

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python coding contest

[Shane Hathaway]

I just found a 125 character solution.  It's actually faster and more 
readable than the 133 character solution (though it's still obscure.)

It depends on Python 2.4.  If Python 2.3 compatibility is required for 
the contest, I have to add 4 characters.

Shane

[EMAIL PROTECTED] pycontest_01]$ wc -c seven_seg.py
125 seven_seg.py
[EMAIL PROTECTED] pycontest_01]$ python test.py
.
--
Ran 1 test in 0.084s

OK
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python coding contest

[Duncan Booth]

Christian Tismer wrote:

> And then help me to setup a different contest about content -- chris
> 
Count me in.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python coding contest

[Roman Susi]

Tim Hochberg wrote:
> py pan wrote:
> 
>>When you guys say 127~150 characters, did you guys mean
>>usinging test_vectors.py in some way? Or there's no import at all?
>>
> 
> 
> No import at all. The shortest solution reported so far is 131 
> characters. Getting down to 127 is just a guess as to where the lower 
> bound is likely to be.
> 
> Note that in principle it's possible to encode the data for how to 
> display a digit in one byte. Thus it's at least theoretically possible 
> to condense all of the information about the string into a string that's 
> 10 bytes long. In practice it turns out to be hard to do that, since a 
> 10 byte string will generally have a representation that is longer than 
> 10 bytes because of the way the escape sequences get printed out. As a 
> result various people seem to be encoding the data in long integers of 
> one sort or another. The data is then extracted using some recipe 
> involving shifts and &s.
> 
> -tim

Condensing is good but only as far as code for decompressing is small...

By the way, after I noticed that I program for 2.3, I tried with 2.4 and
 get out extra characters thanks for generator expression and .join()
integration. So now I am at 147. Probably a lot of reserve as I have 3
fors... One for just for the purpose of getting a name:

...x for x in [scalar]

Probably its time rething solution from scratch...


Roman Susi
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python coding contest

[Bengt Richter]

On 27 Dec 2005 09:24:44 GMT, Duncan Booth <[EMAIL PROTECTED]> wrote:

>Scott David Daniels wrote:
>
>>> I definitively need a new algorythm. 
>>> 
>> And I am sadly stuck at 169.  Not even spitting distance from 149 (which
>> sounds like a non-cheat version).
>
>Throw it away and start again with a fresh (clean) solution. That's what I 
>did when I'd reached the limit of nested maps and lambdas at 150 
>characters. I'm now on 134 characters and the solution is very nearly 
>legible. (Frustratingly, I'm away for the next few days, so I may not get a 
>chance to submit my solution).
>
>It would be a nice idea to come up with a scoring system which better 
>reflects Python's ideals. For example, use the parser in Python to count up 
>various syntactic elements, score 0 for comments, indents, dedents, 
>newlines, docstrings, 1 for each name or operation used and higher scores 
>for things like lambda or overly complex expressions.

[23:28] C:\pywk\clp\seven\pycontest_01>py24 test.py
.
--
Ran 1 test in 0.391s

OK

[23:28] C:\pywk\clp\seven\pycontest_01>wc -lc  seven_seg.py
  2136  seven_seg.py

2 lines, 136 chars including unix-style lineseps (is that cheating on windows?)
No imports.

Guess I'll have to try another tack ;-/

Regards,
Bengt Richter
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python coding contest

[Remi Villatel]

Christian Tismer wrote:

>>> I feel that python is more beautiful and readable, even if you write
>>> short programs.

> Looking at what I produced the last days, I'm not convinced...

Me neither. Especially since I've taken the one-liner road. Python can 
be very unreadable... sometimes.

> And that's what puzzled me a bit about the approach and the intent
> of this contest: Should this evolute into a language war about
> goals (shortness, conciseness, brevity, whatnot) that Python
> doesn't have as its main targets?

Maybe to prove to the others that Python is a "real" language that can 
produce "uglinesses" too?

> Sure, I see myself hacking this unfortunate little 7-seg code
> until it becomes unreadable for me, the trap worked for me,
> but why do I do this???

For the pleasure of twisting your mind in every possible way, for the 
challenge, for the luxury price if you win? Whatever... I'm trapped too 
and I can't give any reason off the top of my head.

[---CUT---]
> I think it is legal to use any standard pre-installed package you
> like, if it belongs to the set of default batteries included.
[---CUT---]

If you use more than the built-ins, you've already lost. It costs you at 
least 9 bytes, well, 10 since I don't know any module with a 
single-letter name.

"\t"+"import"+" "+name_of_module+"\n"

And knowing how much I struggled to remove the last 10 bytes I removed 
from my code, the idea doesn't sound very attractive.

> After all, I'd really love to set up another contest with
> different measures and criteria.

Go on! I don't think that "shortest code" is a very pythonic goal if you 
count in bytes. The same contest with the length of the code measured in 
  "pythonic units" would be better. When I say "pythonic unit", I mean 
to count 1 unit for each variable, literal, operator or key-word. That 
would be more pythonic.

...but maybe less challenging. To try to do with Python things it wasn't 
meant to do is more "fun" for a contest.  ;-)

-- 
==
Remi Villatel
[EMAIL PROTECTED]
==
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python coding contest

[py pan]

On 12/27/05, Christian Tismer <[EMAIL PROTECTED]> wrote:
And we are of course implementing algorithms with a twisted goal-setin mind: How to express this the shortest way, not elegantly,just how to shave off one or even two bytes, re-iterating thepossible algorithms again and again, just to find a version that is
lexically shorter? To what a silly, autistic crowd of insane peopledo I belong? But it caught me, again!I personally think that it's a good practice. The experiences gatheredmight be useful in other applications in the future. That's where the
excitement of learning new things is about. Actually, I don't see so much applications
for the given problem, Something like this:http://j.domaindlx.com/elements28/wxpython/LEDCtrl.htmlconvinced me that there are application of this problem. 

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python coding contest

[Tim Hochberg]

Christian Tismer wrote:
[SNIP]

> And then help me to setup a different contest about content -- chris

As usual, I expect that actually having some working code measuring 
'Pythonic' length (and I'm sure we could get into all sorts of fun 
arguments about the exact definition of that) would go a long way 
towards convincing the next contest thrower who's measuring length to 
use something a little less distorting than program length.

I've been thinking about writing something, but I've been distracted. 
Perhaps I'll take a stab at it tomorrow and see what I come up with.

That being said, the result I've come up with for the contest are pretty 
cool in a perverse way, at least while there it's spread out over six 
lines. Once it gets folded up, it become unbearable. And, sadly, it only 
saves 3 characters. If one was ignoring leading and trailing whitespace 
the unfolded version would be the much shorter of the two, but ya gotta 
play with the rules as they is.

-tim


-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python coding contest

[Christian Tismer]

Remi Villatel wrote:
> Scott David Daniels wrote:
> 
>   [--CUT---]
>>> 39 bytes... 53 bytes... It gives me the impression to follow a jet 
>>> plane with a bike with my 179 bytes!
>   [--CUT--]
> 
>> And I am sadly stuck at 169.  Not even spitting distance from 149 (which
>> sounds like a non-cheat version).
> 
> Try harder!  ;-)  I thought I was stuck at 179 but with a strict diet, I 
> managed to loose some bones  :-D  and get down to a one-liner of 153 bytes.
> 
> No cheating with import but it's so ugly that I'm not sure I will 
> understand my own code next month. And this time I'm sure at 99% that 
> I'm really stuck...

Don't try harder!
Sit back and think of what you're doing,
and what you'd like to do, instead.

And then help me to setup a different contest about content -- chris

-- 
Christian Tismer :^)   
tismerysoft GmbH : Have a break! Take a ride on Python's
Johannes-Niemeyer-Weg 9A :*Starship* http://starship.python.net/
14109 Berlin : PGP key -> http://wwwkeys.pgp.net/
work +49 30 802 86 56  mobile +49 173 24 18 776  fax +49 30 80 90 57 05
PGP 0x57F3BF04   9064 F4E1 D754 C2FF 1619  305B C09C 5A3B 57F3 BF04
  whom do you want to sponsor today?   http://www.stackless.com/
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python coding contest

[Remi Villatel]

Scott David Daniels wrote:

[--CUT---]
>> 39 bytes... 53 bytes... It gives me the impression to follow a jet 
>> plane with a bike with my 179 bytes!
[--CUT--]

> And I am sadly stuck at 169.  Not even spitting distance from 149 (which
> sounds like a non-cheat version).

Try harder!  ;-)  I thought I was stuck at 179 but with a strict diet, I 
managed to loose some bones  :-D  and get down to a one-liner of 153 bytes.

No cheating with import but it's so ugly that I'm not sure I will 
understand my own code next month. And this time I'm sure at 99% that 
I'm really stuck...

-- 
==
Remi Villatel
[EMAIL PROTECTED]
==
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python coding contest

[Christian Tismer]

James Tanis wrote:
> On 12/25/05, Simon Hengel <[EMAIL PROTECTED]> wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>>> I'm envisioning lots of convoluted one-liners which
>>> are more suitable to a different P-language... :-)
>> I feel that python is more beautiful and readable, even if you write
>> short programs.

Looking at what I produced the last days, I'm not convinced...

> .. yes but there's a difference, some users of that "other" P-language
> seem to actually take some sort of ritualistic pride in their ability
> to condense code  down to one convoluted line. The language is also a
> little more apt at it since it has a great deal of shorthand built in
> to the core language. Shorter is not necessarily better and I do
> support his opinion that reinforcing short as good isn't really what
> most programmers (who care about readability and quality) want to
> support.

And that's what puzzled me a bit about the approach and the intent
of this contest: Should this evolute into a language war about
goals (shortness, conciseness, brevity, whatnot) that Python
doesn't have as its main targets?
Sure, I see myself hacking this unfortunate little 7-seg code
until it becomes unreadable for me, the trap worked for me,
but why do I do this???

...

> I think code efficiency would be a better choice. A "longer" program
> is only worse if its wasting cycles on badly implemented algorithms.

And we are of course implementing algorithms with a twisted goal-set
in mind: How to express this the shortest way, not elegantly,
just how to shave off one or even two bytes, re-iterating the
possible algorithms again and again, just to find a version that is
lexically shorter? To what a silly, autistic crowd of insane people
do I belong? But it caught me, again!

> Code size is a really bad gauge, If your actually comparing size as in
> byte-to-byte comparison, you'll be getting a ton of implementations
> with absolutely no documentation and plenty of one letter variable
> names. I haven't checked the web site either, are you allowing third
> party modules to be used? If so, that causes even more problems in the
> comparison. How are you going to compare those who use a module vs
> implement it themselves in pure python?

I think it is legal to use any standard pre-installed package you
like, if it belongs to the set of default batteries included.
In a sense, using these tools in a good manner, gives you some
measure about how much the programmer knows about these batteries,
and using them is ok. Actually, I don't see so much applications
for the given problem, but in general, I like the idea to try
many very different approaches to get to a maybe surprizing result.

After all, I'd really love to set up another contest with
different measures and criteria.

One reason btw. might be that I'm not able to win this one, due to
personal blocking. I can't really force myself to go all the
ridiculous paths to save one byte. My keyboard blocks as well.
Maybe I don't consider myself a hacker so much any longer :-)

ciao - chris
-- 
Christian Tismer :^)   
tismerysoft GmbH : Have a break! Take a ride on Python's
Johannes-Niemeyer-Weg 9A :*Starship* http://starship.python.net/
14109 Berlin : PGP key -> http://wwwkeys.pgp.net/
work +49 30 802 86 56  mobile +49 173 24 18 776  fax +49 30 80 90 57 05
PGP 0x57F3BF04   9064 F4E1 D754 C2FF 1619  305B C09C 5A3B 57F3 BF04
  whom do you want to sponsor today?   http://www.stackless.com/
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python coding contest

[Tim Hochberg]

Jean-Paul Calderone wrote:
> On Tue, 27 Dec 2005 14:02:57 -0700, Tim Hochberg <[EMAIL PROTECTED]> wrote:
> 
>>Shane Hathaway wrote:
>>
>>>Paul McGuire wrote:
>>>
>>>
>>>Also, here's another cheat version.  (No, 7seg.com does not exist.)
>>>
>>>   import urllib2
>>>   def seven_seg(x):return urllib2.urlopen('http://7seg.com/'+x).read()
>>>
>>
>>And another one from me as well.
>>
>>class a:
>> def __eq__(s,o):return 1
>>seven_seg=lambda i:a()
>>
> 
> 
> This is shorter as "__eq__=lambda s,o:1".
> 
> But I can't find the first post in this thread... What are you 
> guys talking about?

There's a contest described at http://www.pycontest.net/. People have 
been working on two sorts of solutions: 'honest' solutions that actually 
do what's described there. The best of these are around 130 characters. 
There's also a set of 'cheat' solutions that fool the supplied test 
program. I suspect that these will not pass muster when they actually 
get submitted, but we'll see I suppose. A couple of people have figured 
out how to write these cheating solution extremely compactly (32 bytes). 
One of the simpler ones is:

import test;seven_seg=test.test_vectors.get

This will make sense if you look at the kit supplied by the above site.

-tim

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python coding contest

[Justin Azoff]

Tim Hochberg wrote:
> Note that in principle it's possible to encode the data for how to
> display a digit in one byte. Thus it's at least theoretically possible
> to condense all of the information about the string into a string that's
> 10 bytes long. In practice it turns out to be hard to do that, since a
> 10 byte string will generally have a representation that is longer than
> 10 bytes because of the way the escape sequences get printed out. As a
> result various people seem to be encoding the data in long integers of
> one sort or another. The data is then extracted using some recipe
> involving shifts and &s.
>
> -tim

I have a 163 character version(on 8 lines, haven't tried to compress it
further) that does something like that.. the string ended up being
printable enough to be included in the source unescaped.

I think for most approaches, any space you save by using a string you
lose after quoting it and using ord() to turn a character back into a
number.

I'm sure this particular method is a dead end, but it is a very
intersting and probably unique  solution :-)

-- 
- Justin

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python coding contest

[Claudio Grondi]

[EMAIL PROTECTED] wrote:
> I now have a version which passes the test suite in 32 bytes  grin>
> 
> -T.
> 
After I have posted the statement, that I have one with 39 bytes, I had 
the 32 version five minutes later, but thougt that instead of posting it 
I can maybe use it as entry on the contest ... Now this hope is over and 
as the 32 bytes are the lowest possible limit I can currently think of 
the dream of winning the contest seems to be over.

Anyone below 32 bytes?

Claudio
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python coding contest

[Jean-Paul Calderone]

On Tue, 27 Dec 2005 14:02:57 -0700, Tim Hochberg <[EMAIL PROTECTED]> wrote:
>Shane Hathaway wrote:
>> Paul McGuire wrote:
>>
>>
>> Also, here's another cheat version.  (No, 7seg.com does not exist.)
>>
>>import urllib2
>>def seven_seg(x):return urllib2.urlopen('http://7seg.com/'+x).read()
>>
>And another one from me as well.
>
>class a:
>  def __eq__(s,o):return 1
>seven_seg=lambda i:a()
>

This is shorter as "__eq__=lambda s,o:1".

But I can't find the first post in this thread... What are you 
guys talking about?

Jean-Paul

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python coding contest

[Duncan Booth]

Tim Hochberg wrote:

> py pan wrote:
>> When you guys say 127~150 characters, did you guys mean
>> usinging test_vectors.py in some way? Or there's no import at all?
>> 
> 
> No import at all. The shortest solution reported so far is 131 
> characters. Getting down to 127 is just a guess as to where the lower 
> bound is likely to be.

Sorry about the 131, I had a spurious whitespace character so it should 
have been 130.

> The data is then extracted using some recipe 
> involving shifts and &s.

My 130 character solution has a shift and an &. My 133 character solution 
didn't. I feel sure that 130 isn't the limit, my guess would be that 127 or 
128 ought to be possible.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python coding contest

[Tim Hochberg]

Shane Hathaway wrote:
> Paul McGuire wrote:
> 
>>"Paul McGuire" <[EMAIL PROTECTED]> wrote in message
>>news:[EMAIL PROTECTED]
>>
>>
>>>Well *I'm* certainly looking forward to learning some new tricks!  My
>>>(non-cheat) version is a comparatively-portly 245, and no alternatives are
>>>popping into my head at the moment!
>>>
>>>-- Paul
>>>
>>>
>>
>>down to 2 lines, 229 characters
> 
> 
> I'm down to 133 characters (counted according to 'wc -c') on a single 
> line.  It contains about 11 whitespace characters (depending on what you 
> consider whitespace.)  It's way too tricky for my taste, but it's fun to 
> play anyway.  Has anyone done better so far?  Here's a hint on my 
> strategy: the code contains three large integers. :-)

I see now how three large integers could be useful, but the best I could 
do with that is 136 characters on 1-line. Yesterday that would have been 
great, but it's not so hot today.

> 
> Also, here's another cheat version.  (No, 7seg.com does not exist.)
> 
>import urllib2
>def seven_seg(x):return urllib2.urlopen('http://7seg.com/'+x).read()
> 
And another one from me as well.

class a:
  def __eq__(s,o):return 1
seven_seg=lambda i:a()

-tim

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python coding contest

[Tim Hochberg]

py pan wrote:
> When you guys say 127~150 characters, did you guys mean
> usinging test_vectors.py in some way? Or there's no import at all?
> 

No import at all. The shortest solution reported so far is 131 
characters. Getting down to 127 is just a guess as to where the lower 
bound is likely to be.

Note that in principle it's possible to encode the data for how to 
display a digit in one byte. Thus it's at least theoretically possible 
to condense all of the information about the string into a string that's 
10 bytes long. In practice it turns out to be hard to do that, since a 
10 byte string will generally have a representation that is longer than 
10 bytes because of the way the escape sequences get printed out. As a 
result various people seem to be encoding the data in long integers of 
one sort or another. The data is then extracted using some recipe 
involving shifts and &s.

-tim

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python coding contest

[James Tanis]

On 12/25/05, Simon Hengel <[EMAIL PROTECTED]> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> > I'm envisioning lots of convoluted one-liners which
> > are more suitable to a different P-language... :-)
> I feel that python is more beautiful and readable, even if you write
> short programs.

.. yes but there's a difference, some users of that "other" P-language
seem to actually take some sort of ritualistic pride in their ability
to condense code  down to one convoluted line. The language is also a
little more apt at it since it has a great deal of shorthand built in
to the core language. Shorter is not necessarily better and I do
support his opinion that reinforcing short as good isn't really what
most programmers (who care about readability and quality) want to
support.
>
> > How about """best compromize between shortness and readibility
> > plus elegance of design"""?
> I would love to choose those criteria for future events. But I'm not
> aware of any algorithm that is capable of creating a ranking upon them.
> Maybe we can come up with a solution. Any ideas?
>
I think code efficiency would be a better choice. A "longer" program
is only worse if its wasting cycles on badly implemented algorithms.
Code size is a really bad gauge, If your actually comparing size as in
byte-to-byte comparison, you'll be getting a ton of implementations
with absolutely no documentation and plenty of one letter variable
names. I haven't checked the web site either, are you allowing third
party modules to be used? If so, that causes even more problems in the
comparison. How are you going to compare those who use a module vs
implement it themselves in pure python?

--
James Tanis
[EMAIL PROTECTED]
http://pycoder.org
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python coding contest

[py pan]

When you guys say 127~150 characters, did you guys mean usinging test_vectors.py in some way? Or there's no import at all?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python coding contest

[Guyon Morée]

So, is an ugly short one a candidate?

i managed in 199 bytes :)

i'll send it in anyway

ciao

http://gumuz.looze.net/

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python coding contest

[Tim Hochberg]

Shane Hathaway wrote:
> Tim Hochberg wrote:
> 
>>Paul McGuire wrote:
>>
>>
>>>"Shane Hathaway" <[EMAIL PROTECTED]> wrote in message
>>>news:[EMAIL PROTECTED]
>>>
>>>
>>>
I'm down to 133 characters (counted according to 'wc -c') on a single
line.  It contains about 11 whitespace characters (depending on what you
consider whitespace.)  It's way too tricky for my taste, but it's fun to
play anyway.  Has anyone done better so far?  Here's a hint on my
strategy: the code contains three large integers. :-)

>>>
>>>With 1 large integer, I am down to 200 characters on 1 multiline line.  I
>>>can guess why you have 3 integers vs. 1, but I don't see how that saves you
>>>any characters of code.
>>
>>
>>This is interesting. I have a six line solution that is 133 characters 
>>long.
> 
> 
> 133 characters according to 'wc -c'? 

Indeed:

C:\...\pycontest_01>wc -c seven_seg_8.py
 133 seven_seg_8.py

I you strip leading and trailing whitespace, it's 122 characters. For 
comparison, seven_seg_1.py is 816 characters long:)

> If so, that will surely win style 
> points over my one-line monster.  

It's pretty readable, at least with the right tabs setting in one's 
editor, except for the guts of the thing, which consists of 21 
characters of marvelously inscrutable goop.

> But I bet someone's going to do better 
> (without cheating.)

I expect so. However, most people, at least those that are talking, seem 
to be stalling out in the low 130s, so I predict the final winner will 
be 127-130 characters long.

-tim

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python coding contest

[Duncan Booth]

Tim Hochberg wrote:
> This is interesting. I have a six line solution that is 133 characters
> long. I use no long integers, which is what's interesting; two
> distinct solutions with the same length. I played with long integers
> for a bit, and I can see how one could use a single long integer, but
> no idea how one would use three.
> 
I have a 131 character solution with 3 large numbers. Once you've figured 
out how to use 3 numbers there's actually quite a variety of options to use 
different numbers in subtly different ways: I was stuck on 133 characters 
for quite a while, but I think the trick is to think of ways to make the 
numbers smaller.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python coding contest

[Shane Hathaway]

Tim Hochberg wrote:
> Paul McGuire wrote:
> 
>>"Shane Hathaway" <[EMAIL PROTECTED]> wrote in message
>>news:[EMAIL PROTECTED]
>>
>>
>>>I'm down to 133 characters (counted according to 'wc -c') on a single
>>>line.  It contains about 11 whitespace characters (depending on what you
>>>consider whitespace.)  It's way too tricky for my taste, but it's fun to
>>>play anyway.  Has anyone done better so far?  Here's a hint on my
>>>strategy: the code contains three large integers. :-)
>>>
>>
>>With 1 large integer, I am down to 200 characters on 1 multiline line.  I
>>can guess why you have 3 integers vs. 1, but I don't see how that saves you
>>any characters of code.
> 
> 
> This is interesting. I have a six line solution that is 133 characters 
> long.

133 characters according to 'wc -c'?  If so, that will surely win style 
points over my one-line monster.  But I bet someone's going to do better 
(without cheating.)

Shane
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python coding contest

[Tim Hochberg]

Paul McGuire wrote:
> "Shane Hathaway" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
> 
>>I'm down to 133 characters (counted according to 'wc -c') on a single
>>line.  It contains about 11 whitespace characters (depending on what you
>>consider whitespace.)  It's way too tricky for my taste, but it's fun to
>>play anyway.  Has anyone done better so far?  Here's a hint on my
>>strategy: the code contains three large integers. :-)
>>
> 
> With 1 large integer, I am down to 200 characters on 1 multiline line.  I
> can guess why you have 3 integers vs. 1, but I don't see how that saves you
> any characters of code.

This is interesting. I have a six line solution that is 133 characters 
long. I use no long integers, which is what's interesting; two distinct 
solutions with the same length. I played with long integers for a bit, 
and I can see how one could use a single long integer, but no idea how 
one would use three.


-tim

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python coding contest

[ZeD]

Ciao, Shane Hathaway! Che stavi dicendo?

> I'm down to 133 characters (counted according to 'wc -c') on a single
> line.  It contains about 11 whitespace characters (depending on what you
> consider whitespace.)

$ wc -c seven_seg.py
137 seven_seg.py
$ sed 's/ //g' seven_seg.py|wc -c
120
(yeah, too much spaces, I think)

> It's way too tricky for my taste, but it's fun to 
> play anyway.  Has anyone done better so far?  Here's a hint on my
> strategy: the code contains three large integers. :-)

why using 3 longint is better than one?! Trying to "split" my BIG int in 3
just make my code longer...

ok, ok... I will wait the end of the contest... :)

-- 
Firma in costruzione

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python coding contest

[taroso]

I now have a version which passes the test suite in 32 bytes 

-T.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python coding contest

[Paul McGuire]

"Shane Hathaway" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>
> I'm down to 133 characters (counted according to 'wc -c') on a single
> line.  It contains about 11 whitespace characters (depending on what you
> consider whitespace.)  It's way too tricky for my taste, but it's fun to
> play anyway.  Has anyone done better so far?  Here's a hint on my
> strategy: the code contains three large integers. :-)
>
With 1 large integer, I am down to 200 characters on 1 multiline line.  I
can guess why you have 3 integers vs. 1, but I don't see how that saves you
any characters of code.

-- Paul


-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python coding contest

[Shane Hathaway]

Paul McGuire wrote:
> "Paul McGuire" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
> 
> 
>>Well *I'm* certainly looking forward to learning some new tricks!  My
>>(non-cheat) version is a comparatively-portly 245, and no alternatives are
>>popping into my head at the moment!
>>
>>-- Paul
>>
>>
> 
> down to 2 lines, 229 characters

I'm down to 133 characters (counted according to 'wc -c') on a single 
line.  It contains about 11 whitespace characters (depending on what you 
consider whitespace.)  It's way too tricky for my taste, but it's fun to 
play anyway.  Has anyone done better so far?  Here's a hint on my 
strategy: the code contains three large integers. :-)

Also, here's another cheat version.  (No, 7seg.com does not exist.)

   import urllib2
   def seven_seg(x):return urllib2.urlopen('http://7seg.com/'+x).read()

Shane
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python coding contest

[Duncan Booth]

Scott David Daniels wrote:

>> I definitively need a new algorythm. 
>> 
> And I am sadly stuck at 169.  Not even spitting distance from 149 (which
> sounds like a non-cheat version).

Throw it away and start again with a fresh (clean) solution. That's what I 
did when I'd reached the limit of nested maps and lambdas at 150 
characters. I'm now on 134 characters and the solution is very nearly 
legible. (Frustratingly, I'm away for the next few days, so I may not get a 
chance to submit my solution).

It would be a nice idea to come up with a scoring system which better 
reflects Python's ideals. For example, use the parser in Python to count up 
various syntactic elements, score 0 for comments, indents, dedents, 
newlines, docstrings, 1 for each name or operation used and higher scores 
for things like lambda or overly complex expressions.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python coding contest

[Paul McGuire]

"Paul McGuire" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]

> Well *I'm* certainly looking forward to learning some new tricks!  My
> (non-cheat) version is a comparatively-portly 245, and no alternatives are
> popping into my head at the moment!
>
> -- Paul
>
>
down to 2 lines, 229 characters


-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python coding contest

[Paul McGuire]

"Scott David Daniels" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Remi Villatel wrote:
> > Tim Hochberg wrote:
> >
> >>> I am currently at 39 bytes following the requirements and the
> >>> principle given above (my module passes the test). Anyone able to
> >>> beat that?
> >
> >> Wow! It'll be interesting to see how to do that. The obvious way gives
> >> 53 bytes. Hmmm, I'll have to see what can be done...
> >
> > 39 bytes... 53 bytes... It gives me the impression to follow a jet plane
> > with a bike with my 179 bytes!
> >
> > There isn't a single superfluous byte. My code is so compressed that the
> > syntactic colorizer can't cope any more.
> >
> > I definitively need a new algorythm. 
> >
> And I am sadly stuck at 169.  Not even spitting distance from 149 (which
> sounds like a non-cheat version).
>
> --Scott David Daniels
> [EMAIL PROTECTED]

Well *I'm* certainly looking forward to learning some new tricks!  My
(non-cheat) version is a comparatively-portly 245, and no alternatives are
popping into my head at the moment!

-- Paul


-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python coding contest

[Scott David Daniels]

Remi Villatel wrote:
> Tim Hochberg wrote:
> 
>>> I am currently at 39 bytes following the requirements and the 
>>> principle given above (my module passes the test). Anyone able to 
>>> beat that?
> 
>> Wow! It'll be interesting to see how to do that. The obvious way gives 
>> 53 bytes. Hmmm, I'll have to see what can be done...
> 
> 39 bytes... 53 bytes... It gives me the impression to follow a jet plane 
> with a bike with my 179 bytes!
> 
> There isn't a single superfluous byte. My code is so compressed that the 
> syntactic colorizer can't cope any more.
> 
> I definitively need a new algorythm. 
> 
And I am sadly stuck at 169.  Not even spitting distance from 149 (which
sounds like a non-cheat version).

--Scott David Daniels
[EMAIL PROTECTED]
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python coding contest

[Christian Tismer]

Remi Villatel wrote:

> 39 bytes... 53 bytes... It gives me the impression to follow a jet plane 
> with a bike with my 179 bytes!
> 
> There isn't a single superfluous byte. My code is so compressed that the 
> syntactic colorizer can't cope any more.
> 
> I definitively need a new algorythm. 

You need a more careful reading algorithm.
We were talking about cheating by imports :-)

-- 
Christian Tismer :^)   
tismerysoft GmbH : Have a break! Take a ride on Python's
Johannes-Niemeyer-Weg 9A :*Starship* http://starship.python.net/
14109 Berlin : PGP key -> http://wwwkeys.pgp.net/
work +49 30 802 86 56  mobile +49 173 24 18 776  fax +49 30 80 90 57 05
PGP 0x57F3BF04   9064 F4E1 D754 C2FF 1619  305B C09C 5A3B 57F3 BF04
  whom do you want to sponsor today?   http://www.stackless.com/
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python coding contest

[Remi Villatel]

Tim Hochberg wrote:

>> I am currently at 39 bytes following the requirements and the 
>> principle given above (my module passes the test). Anyone able to beat 
>> that?

> Wow! It'll be interesting to see how to do that. The obvious way gives 
> 53 bytes. Hmmm, I'll have to see what can be done...

39 bytes... 53 bytes... It gives me the impression to follow a jet plane 
with a bike with my 179 bytes!

There isn't a single superfluous byte. My code is so compressed that the 
syntactic colorizer can't cope any more.

I definitively need a new algorythm. 

-- 
==
Remi Villatel
[EMAIL PROTECTED]
==
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python coding contest

[Justin Azoff]

Tim Hochberg wrote:
> In the 130's is definately possible, but I haven't heard of anyone doing
> better than that.

I have a version that is 127, but only if you strip extra whitespace
:-(

-- 
- Justin

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python coding contest

[Tim Hochberg]

Tim Hochberg wrote:
[CHOP]
> 
> import test;seven_seg=test.test_vectors.get
> 
> This works if you run test. It fails if you try to run it standalone 
> since the import order is wrong.
[CHOP]

Or maybe not. An earlier version did, but this one seems OK.

-tim

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python coding contest

[Christian Tismer]

Tim Hochberg wrote:

> import test;seven_seg=test.test_vectors.get

Oupps, good   (being blinded after all the other from imports
and __import__(...) )

-- 
Christian Tismer :^)   
tismerysoft GmbH : Have a break! Take a ride on Python's
Johannes-Niemeyer-Weg 9A :*Starship* http://starship.python.net/
14109 Berlin : PGP key -> http://wwwkeys.pgp.net/
work +49 30 802 86 56  mobile +49 173 24 18 776  fax +49 30 80 90 57 05
PGP 0x57F3BF04   9064 F4E1 D754 C2FF 1619  305B C09C 5A3B 57F3 BF04
  whom do you want to sponsor today?   http://www.stackless.com/
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python coding contest

[Tim Hochberg]

Steven D'Aprano wrote:
> On Mon, 26 Dec 2005 13:33:42 -0700, Tim Hochberg wrote:
> 
> 
>>Claudio Grondi wrote:
> 
> 
>>>I am currently at 39 bytes following the requirements and the principle 
>>>given above (my module passes the test). Anyone able to beat that?
>>
>>Wow! It'll be interesting to see how to do that. The obvious way gives 
>>53 bytes. Hmmm, I'll have to see what can be done...
> 
> 
> OBVIOUS???

Your misinterpreting me here. I meant the obvious way to cheat as 
Claudio describes above. I don't actually think that kind of cheating 
will work, since it relies on test_vectors.py being present and it 
assumes that the test vectors used for checking the program are the same 
as those in test_vectors.py. The documentation suggests that the later 
at least is not likely. I still haven't figured out how he manages to 
get his cheating one so short though, the smallest I can get is 43 
characters and it looks like this:

import test;seven_seg=test.test_vectors.get

This works if you run test. It fails if you try to run it standalone 
since the import order is wrong.


> 
> The only algorithm obvious to me came to two lines and about 300
> characters with all the pruning I could come up with. Changing algorithms
> made it longer. I am finding it hard enough to credit that half a dozen
> people are claiming lengths of around 130-180 characters -- 39 or 53 bytes
> just seems physically impossible to me, especially given that nine of
> those bytes are the name of the function!

In the 130's is definately possible, but I haven't heard of anyone doing 
better than that.

> 
> The identity function seven_seg=lambda s:s takes 20 bytes and does
> nothing. That leaves NINETEEN bytes to implement the functionality. In the
> immortal words of Bill and Ted: "No way dude!"
> 
> You excellent dudes are righteously bodacious!

Nah.

-tim

> 
> 

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python coding contest

[Christian Tismer]

Steven D'Aprano wrote:
> On Mon, 26 Dec 2005 13:33:42 -0700, Tim Hochberg wrote:
> 
>> Claudio Grondi wrote:
> 
>>> I am currently at 39 bytes following the requirements and the principle 
>>> given above (my module passes the test). Anyone able to beat that?
>> Wow! It'll be interesting to see how to do that. The obvious way gives 
>> 53 bytes. Hmmm, I'll have to see what can be done...
> 
> OBVIOUS???

The obvious way seems to be to import the test_vectors.py file,
which gives me

import test_vectors as x;seven_seg=x.test_vectors.get

as one possible "obvious" solution with 53 chars.

But
from test_vectors import*;seven_seg=test_vectors.get
has only 52.

And if you observe that their "test.py" file already does
all the imports we want, you can get to

from test import*;seven_seg=test_vectors.get
with 44 chars.

But I simply cant see how to get below that.
And I think this is not the wanted solution at all,
which is why I have no problem posting it here :-)

ciao - chris
-- 
Christian Tismer :^)   
tismerysoft GmbH : Have a break! Take a ride on Python's
Johannes-Niemeyer-Weg 9A :*Starship* http://starship.python.net/
14109 Berlin : PGP key -> http://wwwkeys.pgp.net/
work +49 30 802 86 56  mobile +49 173 24 18 776  fax +49 30 80 90 57 05
PGP 0x57F3BF04   9064 F4E1 D754 C2FF 1619  305B C09C 5A3B 57F3 BF04
  whom do you want to sponsor today?   http://www.stackless.com/
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python coding contest

[Steven D'Aprano]

On Mon, 26 Dec 2005 13:33:42 -0700, Tim Hochberg wrote:

> Claudio Grondi wrote:

>> I am currently at 39 bytes following the requirements and the principle 
>> given above (my module passes the test). Anyone able to beat that?
> 
> Wow! It'll be interesting to see how to do that. The obvious way gives 
> 53 bytes. Hmmm, I'll have to see what can be done...

OBVIOUS???

The only algorithm obvious to me came to two lines and about 300
characters with all the pruning I could come up with. Changing algorithms
made it longer. I am finding it hard enough to credit that half a dozen
people are claiming lengths of around 130-180 characters -- 39 or 53 bytes
just seems physically impossible to me, especially given that nine of
those bytes are the name of the function!

The identity function seven_seg=lambda s:s takes 20 bytes and does
nothing. That leaves NINETEEN bytes to implement the functionality. In the
immortal words of Bill and Ted: "No way dude!"

You excellent dudes are righteously bodacious!


-- 
Steven.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python coding contest

[Malte Dik]

Tim Hochberg wrote:

> Claudio Grondi wrote:
>> Peter Otten wrote:
> [SNIP]
>>>How good is "good" for
>>>
>>>import test_vectors
>>>seven_seg = test_vectors.test_vectors.get
>>>
>>>or code using the test suite in general?
>>>
>>>Peter
>>>
>> 
>> This started to remind myself about the story of the contest where the
>> shortest program beeing able to output own source was the job to code.
>> The jury had a big trouble to justify why not give the prize to the one
>> who posted an empty file ...
>> 
>> I am currently at 39 bytes following the requirements and the principle
>> given above (my module passes the test). Anyone able to beat that?
> 
> Wow! It'll be interesting to see how to do that. The obvious way gives
> 53 bytes. Hmmm, I'll have to see what can be done...
> 
> However they do say "We use a very *similar* test suite to either accept
> or reject pending submissions." (Emphasis mine) So, it's possible, even
> probable, that the file test.py either won't be available or won't be
> helpful.
> 
> -tim

Wouldn't using test_vectors.py somehow be lame?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python coding contest

[Duncan Booth]

Tim Hochberg wrote:

> [EMAIL PROTECTED] wrote:
>> Currently I'm on 149 characters in  one line - 128 without
>> spaces/newlines.  (it'd be three characters shorter if it didn't have
>> to end with a "\n")
> 
> 
> It'll be interesting to see what the short 1-line answers look like. I 
> have a hard time seeing how that's done. It'll especially be interesting 
> to see  if we're all using similar tricks or if the multiline attemps 
> take a distinctly different tack than the single line attempts.
> 
> Currently, I'm down to 137 characters now in 6 lines. There's very 
> little left to trim at this point, so I don't know that I'll be able to 
> knock it down any further using my current approach. And since I don't 
> have any other approaches in the wings, I may be about washed up.
> 
> 
I think my main interest will be to see what different algorithms are 
successful. I suspect I may have chosen the wrong approach to start with 
since I stuck at 150 characters (1 line, no extraneous whitespace), but 
then I started again with a different algorithm and I'm down to one line of 
137 characters but nowhere obvious to go from there...

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python coding contest

[Tim Hochberg]

Claudio Grondi wrote:
> Peter Otten wrote:
[SNIP]
>>How good is "good" for
>>
>>import test_vectors
>>seven_seg = test_vectors.test_vectors.get
>>
>>or code using the test suite in general?
>>
>>Peter
>>
> 
> This started to remind myself about the story of the contest where the 
> shortest program beeing able to output own source was the job to code.
> The jury had a big trouble to justify why not give the prize to the one 
> who posted an empty file ...
> 
> I am currently at 39 bytes following the requirements and the principle 
> given above (my module passes the test). Anyone able to beat that?

Wow! It'll be interesting to see how to do that. The obvious way gives 
53 bytes. Hmmm, I'll have to see what can be done...

However they do say "We use a very *similar* test suite to either accept 
or reject pending submissions." (Emphasis mine) So, it's possible, even 
probable, that the file test.py either won't be available or won't be 
helpful.

-tim



-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python coding contest

[Claudio Grondi]

Peter Otten wrote:
> Simon Hengel wrote:
> 
> 
>>>Is it necessary to keep the input parameter as 'input'? Reducing that to
>>>a single character drops the length of a program by at least 8
>>>characters. Technically it changes the interface of the function, so
>>>it's a little bogus, but test.py doesn't check. (Personally I prefer
>>>that if be illegal, but if it's legal I'll have to do it).
>>
>>You may change input to something more short, like x. Everything that
>>passes the test, has a good chance to be accepted.
> 
> 
> How good is "good" for
> 
> import test_vectors
> seven_seg = test_vectors.test_vectors.get
> 
> or code using the test suite in general?
> 
> Peter
> 
This started to remind myself about the story of the contest where the 
shortest program beeing able to output own source was the job to code.
The jury had a big trouble to justify why not give the prize to the one 
who posted an empty file ...

I am currently at 39 bytes following the requirements and the principle 
given above (my module passes the test). Anyone able to beat that?

Claudio
-- 
http://mail.python.org/mailman/listinfo/python-list