On 2013-01-25, Hans Mulder wrote:
>> Right. atoi is no good even in C. You get much better control
>> using the sprintf family.
>
> I think you meant sscanf.
Yes, thanks for knocking that huge chunk of rust off of me. ;)
--
Neil Cerutti
--
http://mail.python.org/mailman/listinfo/python-list
Don't forget to look at csv reader.
http://docs.python.org/2/library/csv.html
On Fri, Jan 25, 2013 at 9:31 AM, Hans Mulder wrote:
> On 25/01/13 15:04:02, Neil Cerutti wrote:
> > On 2013-01-25, Oscar Benjamin wrote:
> >> On 24 January 2013 11:35, Chris Angelico wrote:
> >>> It's usually fine
On 25/01/13 15:04:02, Neil Cerutti wrote:
> On 2013-01-25, Oscar Benjamin wrote:
>> On 24 January 2013 11:35, Chris Angelico wrote:
>>> It's usually fine to have int() complain about any
>>> non-numerics in the string, but I must confess, I do sometimes
>>> yearn for atoi() semantics: atoi("123as
On 2013-01-25, Oscar Benjamin wrote:
> On 24 January 2013 11:35, Chris Angelico wrote:
>> It's usually fine to have int() complain about any
>> non-numerics in the string, but I must confess, I do sometimes
>> yearn for atoi() semantics: atoi("123asd") == 123, and
>> atoi("qqq") == 0. I've not se
On Fri, Jan 25, 2013 at 12:33 PM, Oscar Benjamin
wrote:
> I have solved similar situations with
> sorted(filenames, key=lambda s: (len(s), s))
> which is better than lexicographical ordering for sorting integer
> strings. It gets the _Int file wrong in this case (but I consider it
> luck that
On 25 January 2013 01:11, Chris Angelico wrote:
> On Fri, Jan 25, 2013 at 12:03 PM, Oscar Benjamin
> wrote:
>> On 24 January 2013 11:35, Chris Angelico wrote:
>>>
>>> It's usually fine to have int() complain about any non-numerics in the
>>> string, but I must confess, I do sometimes yearn for a
On Fri, Jan 25, 2013 at 12:03 PM, Oscar Benjamin
wrote:
> On 24 January 2013 11:35, Chris Angelico wrote:
>>
>> It's usually fine to have int() complain about any non-numerics in the
>> string, but I must confess, I do sometimes yearn for atoi() semantics:
>> atoi("123asd") == 123, and atoi("qqq"
On Fri, Jan 25, 2013 at 11:20 AM, Steven D'Aprano
wrote:
> Chris Angelico wrote:
>
>> It's usually fine to have int() complain about any non-numerics in the
>> string, but I must confess, I do sometimes yearn for atoi() semantics:
>> atoi("123asd") == 123, and atoi("qqq") == 0. I've not seen a
>>
On 24 January 2013 11:35, Chris Angelico wrote:
>
> It's usually fine to have int() complain about any non-numerics in the
> string, but I must confess, I do sometimes yearn for atoi() semantics:
> atoi("123asd") == 123, and atoi("qqq") == 0. I've not seen a
> convenient Python function for doing
Thanks a lot people.. :).. :)
On Thu, Jan 24, 2013 at 1:10 PM, Tobias M. wrote:
> Am 24.01.2013 13:02, schrieb Chris Angelico:
>
> On Thu, Jan 24, 2013 at 10:58 PM, Tobias M. wrote:
>>
>>> Chris Angelico wrote:
>>>
I'd not consider the performance, but the correctness. If you're
ex
Am 24.01.2013 13:02, schrieb Chris Angelico:
On Thu, Jan 24, 2013 at 10:58 PM, Tobias M. wrote:
Chris Angelico wrote:
I'd not consider the performance, but the correctness. If you're
expecting them to be integers, just cast them, and specifically
_don't_ catch ValueError. Any non-integer value
On Thu, Jan 24, 2013 at 10:58 PM, Tobias M. wrote:
> Chris Angelico wrote:
>>
>> I'd not consider the performance, but the correctness. If you're
>> expecting them to be integers, just cast them, and specifically
>> _don't_ catch ValueError. Any non-integer value will then noisily
>> abort the scr
Chris Angelico wrote:
I'd not consider the performance, but the correctness. If you're
expecting them to be integers, just cast them, and specifically
_don't_ catch ValueError. Any non-integer value will then noisily
abort the script. (It may be worth checking for blank first, though,
depending o
On Thu, Jan 24, 2013 at 10:16 PM, Tobias M. wrote:
> Chris Angelico wrote:
>> The other thing you may want to consider, if the values are supposed
>> to be integers, is to convert them to Python integers before
>> comparing.
>
> I thought of this too and I wonder if there are any major differences
On Thu, Jan 24, 2013 at 10:01 PM, inshu chauhan wrote:
> Yeah I tried printing, there were trailing white spaces, so i used strip()
> and IT Worked !!! :)
Awesome! Keep repr() in mind, it's a great way to check what's really there.
ChrisA
--
http://mail.python.org/mailman/listinfo/python-list
Chris Angelico wrote:
The other thing you may want to consider, if the values are supposed
to be integers, is to convert them to Python integers before
comparing. Currently, you're working with strings. Replace this:
if sp[9] == sp[10]:
with this:
if int(sp[9]) == int(sp[10]):
I thought of t
On Thu, Jan 24, 2013 at 11:55 AM, Tobias M. wrote:
> Hi,
>
> do a "print sp" after the split and you might see that the strings don't
> look as you expected. There might be leading or trailing whitespaces in the
> splitted strings and in sp[10] there probably is a line break "\n" at the
> end.
>
On Thu, Jan 24, 2013 at 9:37 PM, inshu chauhan wrote:
> For me I think the programme is logically correct, but its giving me results
> which are strange.
> It is Printing " Different Class" even when sp[9] is equal to sp[10] and
> "Same class" when sp[9] is not equal to sp[10]. and sp[9] and sp
Hi,
do a "print sp" after the split and you might see that the strings don't
look as you expected. There might be leading or trailing whitespaces in
the splitted strings and in sp[10] there probably is a line break "\n"
at the end.
To remove those unwanted characters you could use the strip()
Here I have a code which basically reads a csv file, tries to compare the
last 2 items in each line of the file.
f = open(r"Z:\modules\Feature_Vectors_300_Pclass.arff")
for l in f:
sp = l.split(",")
if len(sp) != 11:
print >> of, l,
else:
#print sp[9], sp[10]
i
20 matches
Mail list logo
