Jen Kris via Python-list schreef op 2/10/2023 om 17:06:
My previous message just went up -- sorry for the mangled formatting. Here it
is properly formatted:
I want to write a list of 64-bit integers to a binary file. Every example I
have seen in my research converts it to .txt, but I want
My previous message just went up -- sorry for the mangled formatting. Here it
is properly formatted:
I want to write a list of 64-bit integers to a binary file. Every example I
have seen in my research converts it to .txt, but I want it in binary. I wrote
this code, based on some earlier wor
Dieter, thanks for your comment that:
* In your code, `offset` is `0`, `1`, `2`, ...
but it should be `0 *8`, `1 * 8`, `2 * 8`, ...
But you concluded with essentially the same solution proposed by MRAB, so that
would obviate the need to write item by item because it writes the whole buffer
at o
Jen Kris wrote at 2023-10-2 00:04 +0200:
>Iwant to write a list of 64-bit integers to a binary file. Everyexample I
>have seen in my research convertsit to .txt, but I want it in binary. I wrote
>this code,based on some earlier work I have done:
>
>buf= bytes((len(qs_array)) * 8)
>
>for offset
Thanks very much, MRAB. I just tried that and it works. What frustrated me is
that every research example I found writes integers as strings. That works --
sort of -- but it requires re-casting each string to integer when reading the
file. If I'm doing binary work I don't want the extra over
On 2023-10-01 23:04, Jen Kris via Python-list wrote:
>
> Iwant to write a list of 64-bit integers to a binary file.
Everyexample I have seen in my research convertsit to .txt, but I want
it in binary. I wrote this code,based on some earlier work I have done:
>
> buf= bytes((len(qs_array)) * 8)
On 2 Oct 2023, at 16:02, Jen Kris via Python-list
wrote:
Iwant to write a list of 64-bit integers to a binary file. Everyexample
I have seen in my research convertsit to .txt, but I want it in binary.
I wrote this code,based on some earlier work I have done:
buf= b
Iwant to write a list of 64-bit integers to a binary file. Everyexample I have
seen in my research convertsit to .txt, but I want it in binary. I wrote this
code,based on some earlier work I have done:
buf= bytes((len(qs_array)) * 8)
foroffset in range(len(qs_array)):
item_to_write= byt
On Saturday, August 25, 2018 at 12:07:14 PM UTC-5, Musatov wrote:
> On Saturday, August 25, 2018 at 9:46:21 AM UTC-5, Richard Damon wrote:
> > On 8/25/18 10:27 AM, Dennis Lee Bieber wrote:
> > > On Sat, 25 Aug 2018 03:56:28 + (UTC), Steven D'Aprano
> > > declaimed the following:
> > >
> > >> O
On Mon, 14 Dec 2015 08:56 pm, Terry Reedy wrote:
> On 12/13/2015 7:24 PM, KP wrote:
>>
>>
>> data = list(f.read(4))
>> print data
>>
>> from a binary file might give
>
> In 2.x, a binary file and a text file are not distinguished.
I think what you mean is that, in Python 2, reading from a file r
On 12/13/2015 7:24 PM, KP wrote:
data = list(f.read(4))
print data
from a binary file might give
In 2.x, a binary file and a text file are not distinguished.
['\x10', '\x20', '\x12', '\x01']
If a 'binary' file yields strings, you must be using 2.x.
How can I receive this instead?
[0x10
On Sunday, 13 December 2015 16:33:20 UTC-8, Chris Angelico wrote:
> On Mon, Dec 14, 2015 at 11:24 AM, KP <> wrote:
> > data = list(f.read(4))
> > print data
> >
> > from a binary file might give
> >
> > ['\x10', '\x20', '\x12', '\x01']
> >
> >
> > How can I receive this instead?
> >
> > [0x10, 0x2
On Mon, Dec 14, 2015 at 11:24 AM, KP wrote:
> data = list(f.read(4))
> print data
>
> from a binary file might give
>
> ['\x10', '\x20', '\x12', '\x01']
>
>
> How can I receive this instead?
>
> [0x10, 0x20, 0x12, 0x01]
>
> Thanks for all help!
Try this:
data = [ord(x) for x in f.read(4)]
Note
data = list(f.read(4))
print data
from a binary file might give
['\x10', '\x20', '\x12', '\x01']
How can I receive this instead?
[0x10, 0x20, 0x12, 0x01]
Thanks for all help!
--
https://mail.python.org/mailman/listinfo/python-list
On 9/8/2014 1:44 AM, Marko Rauhamaa wrote:
Chris Angelico :
The original question was regarding storage - how PEP 393 says that
strings will be encoded in memory in any of three ways (Latin-1,
UCS-2/UTF-16, or UCS-4/UTF-32). But even in our world, that is not
what a string *is*, but only what i
On Mon, Sep 8, 2014 at 3:44 PM, Marko Rauhamaa wrote:
> Chris Angelico :
>
>> The original question was regarding storage - how PEP 393 says that
>> strings will be encoded in memory in any of three ways (Latin-1,
>> UCS-2/UTF-16, or UCS-4/UTF-32). But even in our world, that is not
>> what a stri
Chris Angelico :
> The original question was regarding storage - how PEP 393 says that
> strings will be encoded in memory in any of three ways (Latin-1,
> UCS-2/UTF-16, or UCS-4/UTF-32). But even in our world, that is not
> what a string *is*, but only what it is made of.
I'm a bit surprised tha
On Mon, Sep 8, 2014 at 4:34 AM, Rustom Mody wrote:
> IOW I interpret MRAB's statement that strings should not be thought
> of as encoded because they consist of abstract code-points, seems to me (a
> unicode-ignoramus!) a reasonable outlook
The original question was regarding storage - how PEP 3
On Mon, Sep 8, 2014 at 1:40 AM, Roy Smith wrote:
> Well, technically, what you store is something which has the right
> behavior. If I wrote:
>
> my_huffman_coded_list = [0] * 100
>
> I don't know of anything which requires Python to actually generate a
> million 0's and store them somewhere
On Sunday, September 7, 2014 11:38:41 PM UTC+5:30, Steven D'Aprano wrote:
> Rustom Mody wrote:
> > On Sunday, September 7, 2014 10:33:26 PM UTC+5:30, Steven D'Aprano wrote:
> >> MRAB wrote:
> >> > I don't think you should be saying that it stores the string in Latin-1
> >> > or UTF-16 because that
Rustom Mody wrote:
> On Sunday, September 7, 2014 10:33:26 PM UTC+5:30, Steven D'Aprano wrote:
>> MRAB wrote:
>
>> > I don't think you should be saying that it stores the string in Latin-1
>> > or UTF-16 because that might suggest that they are encoded. They
>> > aren't.
>
>> Of course they are
Roy Smith wrote:
> In article ,
> Chris Angelico wrote:
>
>> You can't store a list in memory; what you store is a set of bits
>> which represent some metadata and a bunch of pointers.
>
>
> Well, technically, what you store is something which has the right
> behavior. If I wrote:
No. Chris
On Sunday, September 7, 2014 10:33:26 PM UTC+5:30, Steven D'Aprano wrote:
> MRAB wrote:
> > I don't think you should be saying that it stores the string in Latin-1
> > or UTF-16 because that might suggest that they are encoded. They aren't.
> Of course they are encoded. Memory consists of bytes,
MRAB wrote:
> I don't think you should be saying that it stores the string in Latin-1
> or UTF-16 because that might suggest that they are encoded. They aren't.
Of course they are encoded. Memory consists of bytes, not Unicode code
points, which are abstract numbers representing characters (and o
In article ,
Chris Angelico wrote:
> You can't store a list in memory; what you store is a set of bits
> which represent some metadata and a bunch of pointers.
Well, technically, what you store is something which has the right
behavior. If I wrote:
my_huffman_coded_list = [0] * 100
I
On Mon, Sep 8, 2014 at 12:52 AM, MRAB wrote:
> I don't think you should be saying that it stores the string in Latin-1
> or UTF-16 because that might suggest that they are encoded. They aren't.
Except that they are. RAM stores bytes [1], so by definition
everything that's in memory is encoded. Yo
On 2014-09-07 02:47, Steven D'Aprano wrote:
Kurt Mueller wrote:
Processing any Unicode string will work with small and wide
python 2.7 builds and also with python >3.3?
( parts of small build python will not work with values over 0x )
( strings with surrogate pairs will not work correctly o
Kurt Mueller wrote:
> Processing any Unicode string will work with small and wide
> python 2.7 builds and also with python >3.3?
> ( parts of small build python will not work with values over 0x )
> ( strings with surrogate pairs will not work correctly on small build
> python )
If you limit
Am 06.09.2014 um 20:19 schrieb Steven D'Aprano
:
> Kurt Mueller wrote:
> [...]
>> Now the part of the two Python builds is still somewhat unclear to me.
> [...]
>> In Python 2.7:
>> As I learned from the ord() manual:
>> If a unicode argument is given and Python was built with UCS2 Unicode,
> Wher
Kurt Mueller wrote:
[...]
> Now the part of the two Python builds is still somewhat unclear to me.
[...]
> In Python 2.7:
>
> As I learned from the ord() manual:
> If a unicode argument is given and Python was built with UCS2 Unicode,
Where does the manual mention UCS-2? As far as I know, no ver
On Sat, Sep 6, 2014 at 10:15 PM, Kurt Mueller
wrote:
> I understand: narrow build is UCS2, wide build is UCS4
> - In a UCS2 build each character of an Unicode string uses 16 Bits and has
> code points from U-..U- (0..65535)
> - In a UCS4 build each character of an Unicode string uses 32
Am 06.09.2014 um 07:47 schrieb Steven D'Aprano
:
> Kurt Mueller wrote:
>> Could someone please explain the following behavior to me:
>> Python 2.7.7, MacOS 10.9 Mavericks
[snip]
Thanks for the detailed explanation. I think I understand a bit better now.
Now the part of the two Python builds is
Peter Otten wrote:
> Steven D'Aprano wrote:
>
>> import sys
>> sys.getdefaultencoding()
>>> 'ascii'
>>
>> That's technically known as a "lie", since if it were *really* ASCII it
>> would refuse to deal with characters with the high-bit set. But it
>> doesn't, it treats them in an unpredi
Steven D'Aprano wrote:
> import sys
> sys.getdefaultencoding()
>> 'ascii'
>
> That's technically known as a "lie", since if it were *really* ASCII it
> would refuse to deal with characters with the high-bit set. But it
> doesn't, it treats them in an unpredictable and implementation-depen
Kurt Mueller wrote:
> Could someone please explain the following behavior to me:
> Python 2.7.7, MacOS 10.9 Mavericks
>
import sys
sys.getdefaultencoding()
> 'ascii'
That's technically known as a "lie", since if it were *really* ASCII it
would refuse to deal with characters with the hi
Chris Angelico wrote:
> On Fri, Sep 5, 2014 at 12:09 PM, Ian Kelly wrote:
>> On Thu, Sep 4, 2014 at 6:12 PM, Chris Angelico wrote:
>>> If it's a Unicode string (which is the default in Python 3), all
>>> Unicode characters will work correctly.
>>
>> Assuming the library that needs this is expect
Am 05.09.2014 um 21:16 schrieb Kurt Mueller :
> Am 05.09.2014 um 20:25 schrieb Chris “Kwpolska” Warrick :
>> On Sep 5, 2014 7:57 PM, "Kurt Mueller" wrote:
>>> Could someone please explain the following behavior to me:
>>> Python 2.7.7, MacOS 10.9 Mavericks
>>>
>> import sys
>> sys.getdefa
Am 05.09.2014 um 20:25 schrieb Chris “Kwpolska” Warrick :
> On Sep 5, 2014 7:57 PM, "Kurt Mueller" wrote:
> > Could someone please explain the following behavior to me:
> > Python 2.7.7, MacOS 10.9 Mavericks
> >
> > >>> import sys
> > >>> sys.getdefaultencoding()
> > 'ascii'
> > >>> [ord(c) for c
On Sep 5, 2014 7:57 PM, "Kurt Mueller"
wrote:
> Could someone please explain the following behavior to me:
> Python 2.7.7, MacOS 10.9 Mavericks
>
> >>> import sys
> >>> sys.getdefaultencoding()
> 'ascii'
> >>> [ord(c) for c in 'AÄ']
> [65, 195, 132]
> >>> [ord(c) for c in u'AÄ']
> [65, 196]
>
> My
Am 05.09.2014 um 10:42 schrieb c...@isbd.net:
> Joshua Landau wrote:
>> On 3 September 2014 15:48, wrote:
>>> Peter Otten <__pete...@web.de> wrote:
>>> [ord(c) for c in "This is a string"]
[84, 104, 105, 115, 32, 105, 115, 32, 97, 32, 115, 116, 114, 105, 110, 103]
There are
Joshua Landau wrote:
> On 3 September 2014 15:48, wrote:
> > Peter Otten <__pete...@web.de> wrote:
> >> >>> [ord(c) for c in "This is a string"]
> >> [84, 104, 105, 115, 32, 105, 115, 32, 97, 32, 115, 116, 114, 105, 110, 103]
> >>
> >> There are other ways, but you have to describe the use case
On Fri, Sep 5, 2014 at 12:09 PM, Ian Kelly wrote:
> On Thu, Sep 4, 2014 at 6:12 PM, Chris Angelico wrote:
>> If it's a Unicode string (which is the default in Python 3), all
>> Unicode characters will work correctly.
>
> Assuming the library that needs this is expecting codepoints and will
> acce
On Thu, Sep 4, 2014 at 6:12 PM, Chris Angelico wrote:
> If it's a Unicode string (which is the default in Python 3), all
> Unicode characters will work correctly.
Assuming the library that needs this is expecting codepoints and will
accept integers greater than 255.
> If it's a byte string (the
On Fri, Sep 5, 2014 at 7:06 AM, Joshua Landau wrote:
> On 3 September 2014 15:48, wrote:
>> Peter Otten <__pete...@web.de> wrote:
>>> >>> [ord(c) for c in "This is a string"]
>>> [84, 104, 105, 115, 32, 105, 115, 32, 97, 32, 115, 116, 114, 105, 110, 103]
>>>
>>> There are other ways, but you hav
On 3 September 2014 15:48, wrote:
> Peter Otten <__pete...@web.de> wrote:
>> >>> [ord(c) for c in "This is a string"]
>> [84, 104, 105, 115, 32, 105, 115, 32, 97, 32, 115, 116, 114, 105, 110, 103]
>>
>> There are other ways, but you have to describe the use case and your Python
>> version for us
Peter Otten <__pete...@web.de> wrote:
> c...@isbd.net wrote:
>
> > I know I can get a list of the characters in a string by simply doing:-
> >
> > listOfCharacters = list("This is a string")
> >
> > ... but how do I get a list of intege
El miércoles, 3 de septiembre de 2014 05:27:29 UTC-7, c...@isbd.net escribió:
> I know I can get a list of the characters in a string by simply doing:-
>
>
>
> listOfCharacters = list("This is a string")
>
>
>
> ... but how do I get a list of inte
c...@isbd.net wrote:
> I know I can get a list of the characters in a string by simply doing:-
>
> listOfCharacters = list("This is a string")
>
> ... but how do I get a list of integers?
>
>>> [ord(c) for c in "This is a string"]
[84, 10
I know I can get a list of the characters in a string by simply doing:-
listOfCharacters = list("This is a string")
... but how do I get a list of integers?
--
Chris Green
·
--
https://mail.python.org/mailman/listinfo/python-list
On Jul 23, 7:27 pm, Grant Edwards wrote:
> That said, "map" seems to be frowned upon by the Python community for
> reasons I've never really understood,...
Maybe the analogy:
comprehension : map:: relational calculus : relational algebra
In particular map, filter correspond to project and
On 2012-07-22, Jan Riechers wrote:
> I am not sure why everyone is using the for-iterator option over a
> "map", but I would do it like that:
>
> MODUS_LIST= map(int, options.modus_list)
>
> "map" works on a list and does commandX (here "int" conversion, use
> "str" for string.. et cetera) on s
On 07/22/2012 11:29 AM, Tony the Tiger wrote:
> Hi,
> Is there such a thing in the language, or do I have to invent it myself?
>
> I came up with the following:
>
> # options.modus_list contains, e.g., "[2,3,4]"
> # (a string from the command line)
>
>
>
>
So which is it, a list of strings, o
On 22.07.2012 20:01, Steven D'Aprano wrote:
[SNIP]
map is faster than an ordinary for-loop if the function you are applying
is a builtin like int, str, etc. But if you have to write your own pure-
Python function, the overhead of calling a function negates the advantage
of map, which is no faster
On Sun, Jul 22, 2012 at 10:20 AM, Jan Riechers wrote:
> Hi,
>
> I am not sure why everyone is using the for-iterator option over a "map",
> but I would do it like that:
>
> MODUS_LIST= map(int, options.modus_list)
>
> "map" works on a list and does commandX (here "int" conversion, use "str"
> for
On 22.07.2012 20:03, David Robinow wrote:
On Sun, Jul 22, 2012 at 12:20 PM, Jan Riechers wrote:
On 22.07.2012 18:39, Alister wrote:
looks like a classic list comprehension to me and can be achieved in a
single line
MODUS_LIST=[int(x) for x in options.modus_list]
Hi,
I am not sure why everyon
On Sun, 22 Jul 2012 19:20:18 +0300, Jan Riechers wrote:
> "map" works on a list and does commandX (here "int" conversion, use
> "str" for string.. et cetera) on sequenceY, returning a sequence. More
> in the help file.
>
> And if I'm not completely mistaken, it's also the quicker way to do
> perf
Tony the Tiger writes:
> # options.modus_list contains, e.g., "[2,3,4]"
Try this:
import ast
MODUS_LIST = ast.literal_eval(options.modus_list)
literal_eval is like eval except it can only evaluate literals rather
than calling functions and the like. The idea is you can use it on
untrus
On Sun, Jul 22, 2012 at 12:20 PM, Jan Riechers wrote:
> On 22.07.2012 18:39, Alister wrote:
>> looks like a classic list comprehension to me and can be achieved in a
>> single line
>> MODUS_LIST=[int(x) for x in options.modus_list]
> Hi,
>
> I am not sure why everyone is using the for-iterator opt
Tony the Tiger wrote:
> On Sun, 22 Jul 2012 11:39:30 -0400, Roy Smith wrote:
>
>> To answer the question you asked, to convert a list of strings to a list
>> of ints, you want to do something like:
>>
>> MODUS_LIST = [int(i) for i in options.modus_list]
>
> Thanks. I'll look into that. I now
On 22.07.2012 18:39, Alister wrote:
On Sun, 22 Jul 2012 10:29:44 -0500, Tony the Tiger wrote:
I came up with the following:
# options.modus_list contains, e.g., "[2,3,4]"
# (a string from the command line)
# MODUS_LIST contains, e.g., [2,4,8,16]
# (i.e., a list o
e)
> # MODUS_LIST contains, e.g., [2,4,8,16]
> # (i.e., a list of integers)
>
> if options.modus_list:
> intTmp = []
> modTmp = options.modus_list[1:-1]
> for itm in modTmp:
> intTmp.append(int(itm))
> MODUS_LIST = intTmp
# (a string from the command line)
> # MODUS_LIST contains, e.g., [2,4,8,16]
> # (i.e., a list of integers)
>
> if options.modus_list:
> intTmp = []
> modTmp = options.modus_list[1:-1]
> for itm in modTmp:
> intTmp.append(int(it
Hellom n00m!
I beg your pardon for not having replied for such long time---I was
really busy.
Yes, the posted code doesn't solve the supernumbers problem, but solves
the problem you posted first as I understood it :) --- for each number
find a position of this number in the longest sequence it be
Anton,
it simply does not work! Try supernumbers([2,1,4,5,3]).
--
http://mail.python.org/mailman/listinfo/python-list
I hope nobody have posted similar solution (it's tested, but I didn't
submit it to contest):
from bisect import bisect_right as find
def supernumbers(ls):
indices = [0]*len(ls)
for i, e in enumerate(ls):
indices[e - 1] = i
result = [None]*len(ls)
borders = []
for i in indices:
Thank you both for your replies.
And my personal "Thank you!" to Mr. Hettinger for
all his tremendous work!
> Perhaps because you are not using a real Usenet client?
Yes! And I don't even know what is the beast - Usenet client.
I just keep in Favorites of my browser (IE 6.0) this link:
http://grou
n00m wrote:
> Got it! He is a kind of pythonic monsters.
>
> Btw, why it's impossible to reply to old threads?
> Namely, there're no more "Reply" link in them.
> Only "Reply to author" etc.
Perhaps because you are not using a real Usenet client?
Reinhold
--
http://mail.python.org/mailman/listin
"n00m" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Who is Raymond Hettinger?
The Python developer who, in the last few years, has perhaps been the most
active in coding or recoding library modules, such as itertools and sets,
in C. He also partipates in development discussio
Got it! He is a kind of pythonic monsters.
Btw, why it's impossible to reply to old threads?
Namely, there're no more "Reply" link in them.
Only "Reply to author" etc.
--
http://mail.python.org/mailman/listinfo/python-list
n00m wrote:
> Tim Peters wrote:
>> The chance that Raymond Hettinger is going to recode _your_
>> functions in C is approximately 0 ;-)
> Who is Raymond Hettinger?
See python-dev and, wrt this thread,
http://docs.python.org/whatsnew/node12.html.
Reinhold
--
http://mail.python.org/mailman/listin
Tim Peters wrote:
> The chance that Raymond Hettinger is going to recode _your_
> functions in C is approximately 0 ;-)
Who is Raymond Hettinger?
--
http://mail.python.org/mailman/listinfo/python-list
[Tim Peters, on the problem at
http://spoj.sphere.pl/problems/SUPPER/
]
>> Oh, it's not that bad . I took a stab at a Python program for
>> this, and it passed (3.44 seconds).
>> ...
>> I didn't make any effort to speed this, beyond picking a reasonable
>> algorithm, so maybe someone else can
Tim Peters wrote:
> [Bryan Olson, on the problem at
> http://spoj.sphere.pl/problems/SUPPER/
> ]
>
>>I never intended to submit this program for competition. The
>>contest ranks in speed order, and there is no way Python can
>>compete with truly-compiled languages on such low-level code.
[Tim Peters, on the problem at
http://spoj.sphere.pl/problems/SUPPER/
]
>> ...
[EMAIL PROTECTED]
> INCREDIBLE~
> 241433 2005-09-11 04:23:40 Tim Peters accepted 3.44 7096 PYTH
> BRAVO!
It's different now ;-) I added the two lines
import psyco
psyco.full()
and time dropped to 2.29, while
Tim Peters;
INCREDIBLE~
> 241433 2005-09-11 04:23:40 Tim Peters accepted 3.44 7096 PYTH
BRAVO!
I just wonder have I grey cells enough for to understand how your
algo works... and hopefully it's not your last solved problem on
the contester.
> I'm pretty sure they're using
> slower HW than mine
[Bryan Olson, on the problem at
http://spoj.sphere.pl/problems/SUPPER/
]
> I never intended to submit this program for competition. The
> contest ranks in speed order, and there is no way Python can
> compete with truly-compiled languages on such low-level code.
> I'd bet money that the algorit
Bryan;
My own version also timed out.
And now I can tell: it's incredibly SLOW.
Nevertheless it would be interesting to compare
speed of my code against yours. I can't do it myself
because my Python is of 2.3.4 version.
Just uncomment "your" part.
import bisect
def oops(w,a,b):
for m in w:
Bryan Olson wrote:
> Could be. Yet you did write:
>> It's incredibly fast!
I just was obliged to exclaim "It's incredibly fast!"
because I THOUGHT your first version handled ALL TEN
testcases from the input. But the code read from the
*20-lines* input *ONLY 2* its first lines.
Usually they pl
n00m wrote:
> It also timed out:(
Could be. Yet you did write:
> It's incredibly fast!
I never intended to submit this program for competition. The
contest ranks in speed order, and there is no way Python can
compete with truly-compiled languages on such low-level code.
I'd bet money that t
PS:
ALL problems in problems.PDF file (weekly updated):
http://spoj.sphere.pl/problems.pdf
The friendliest online contester I've ever seen! JUST A NON-SUCH.
--
http://mail.python.org/mailman/listinfo/python-list
It also timed out:(
241056 2005-09-09 20:11:19 ZZZ time limit exceeded - 7064 PYTH
Btw, have a look at this nicest problem:
http://spoj.sphere.pl/problems/COINS/
My py solution takes #64 place among its best solutions:
http://spoj.sphere.pl/ranks/COINS/start=60
--
http://mail.python.org/m
n00m wrote:
> Oh!
> Seems you misunderstand me!
> See how the last block in your code should look:
>
> for tc in range(10):
> _ = stdin.readline()
> sequence = [int(ch) for ch in stdin.readline().split()]
> supers = supernumbers(sequence)
> print len(supers)
> for i in
Oh!
Seems you misunderstand me!
See how the last block in your code should look:
for tc in range(10):
_ = stdin.readline()
sequence = [int(ch) for ch in stdin.readline().split()]
supers = supernumbers(sequence)
print len(supers)
for i in supers:
print i,
When I submi
n00m wrote:
> Oops Bryan... I've removed my reply that you refer to...
> See my previous - CORRECT - reply. The code just times
> out... In some sense it doesn't matter right or wrong is
> its output.
If my code times out, then they are using an archaic platform.
With respect to my code, you n
> nor even what submission is yours and your latest.
Oops.. my UserName there is ZZZ.
Submissions in the html table are ordered by date DESC.
--
http://mail.python.org/mailman/listinfo/python-list
Oops Bryan... I've removed my reply that you refer to...
See my previous - CORRECT - reply. The code just times
out... In some sense it doesn't matter right or wrong is
its output.
Btw, what is the complexity of your algorithm?
Currently I'm at work and it's not easy for me to concentrate
on our su
n00m wrote:
> Bravo, Bryan!
> It's incredibly fast!
Not compared to a good implementation for a compiled, low-level
language.
> But your code got WA (wrong answer).
> See my latest submission: http://spoj.sphere.pl/status/SUPPER/
> Maybe you slipped a kind of typo in it? Silly boundary cases
Bravo, Bryan!
Looks very neat! (pity I can't give it a try in my Py 2.3.4
because of reversed() and sorted() functions)
And I've submitted it but got ... TLEs:
http://spoj.sphere.pl/status/SUPPER/
Funnily, the exec.time of the best C solution is only 0.06s!
PS
In my 1st submission I overlooked tha
Bravo, Bryan!
It's incredibly fast! But your code got WA (wrong answer).
See my latest submission: http://spoj.sphere.pl/status/SUPPER/
Maybe you slipped a kind of typo in it? Silly boundary cases?
--
http://mail.python.org/mailman/listinfo/python-list
n00m wrote:
> Firstly I find ordering numbers when moving from left to the right;
> then I find ord. numbers for backward direction AND for DECREASING
> subsequences:
Sounds good.
> Btw, I did it in Pascal. Honestly, I don't believe it can
> be done in Python (of course I mean only the impo
> 4 5 1 2 3 6 7 8 << the list itself
> 1 2 1 2 3 4 5 6 << ordering numbers for forward direction
> 2 1 6 5 4 3 2 1 << ordering numbers for backward direction
> ===
> 3 3 7 7 7 7 7 7 << sums of the pairs of ord. numbers
Oops! Sorry for miscounting in backward direction.
Should be (anyway the
PS: I've still not read 2 new posts.
--
http://mail.python.org/mailman/listinfo/python-list
[EMAIL PROTECTED] wrote:
> So, this has no real world use, aside from posting it on a website.
I don't think you're quite right.
We never know where we gain and where we lose.
> So clearly it served a very useful purpose! ;)
Thanks, Manuel!
> your question is different than the question on this
> That's easy to follow, although their use of a Van Emde-Boas set as a
> given hides the most challenging part (the "efficient data structure"
> part).
The "efficient data structure" is the easy part.
Obviously, it is a dict of lists.
...or is it a list of dicts?...
...or is it a tuple of gene
[EMAIL PROTECTED]
> So, this has no real world use, aside from posting it on a website.
> Thanks for wasting our time. You are making up an arbitrary problem and
> asking for a solution, simply because you want to look at the
> solutions, not because your problem needs to be solved. Clearly, this
>
Working on this allowed me to avoid some _real_ (boring) work at my
job.
So clearly it served a very useful purpose! ;)
Manuel
--
http://mail.python.org/mailman/listinfo/python-list
So, this has no real world use, aside from posting it on a website.
Thanks for wasting our time. You are making up an arbitrary problem and
asking for a solution, simply because you want to look at the
solutions, not because your problem needs to be solved. Clearly, this
is a waste of time.
--
ht
> ... and let me reveal the secret:
> http://spoj.sphere.pl/problems /SUPPER/
your question is different than the question on this website.
also, what do you consider to be the correct output for this
permutation? (according to your original question)
[4, 5, 1, 2, 3, 6, 7, 8]
Manuel
--
http:/
Thanks guys!
> Are you sure that this is not a homework problem?
... and let me reveal the secret:
http://spoj.sphere.pl/problems/SUPPER/
Hardly it can be easily reduced to "standard" LIS problem
(i.e. to find just a (any) Longest Increasing Sequence).
> I coded a solution that can compute the or
I coded a solution that can compute the ordering numbers for
random.shuffle(range(1, 101)) in 2.5 seconds (typical, Win 2K Pro,
Pentium 4 2.40GHz 785Meg RAM)
Are you sure that this is not a homework problem?
--
http://mail.python.org/mailman/listinfo/python-list
1 - 100 of 102 matches
Mail list logo
