Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #98777 > unrolled thread

Re: Problems using struct pack/unpack in files, and reading them.

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Problems using struct pack/unpack in files, and reading them. Chris Angelico <rosuav@gmail.com> - 2015-11-14 09:42 +1100
    Re: Problems using struct pack/unpack in files, and reading them. Steven D'Aprano <steve@pearwood.info> - 2015-11-14 13:40 +1100
      Re: Problems using struct pack/unpack in files, and reading them. Chris Angelico <rosuav@gmail.com> - 2015-11-14 14:01 +1100
        Re: Problems using struct pack/unpack in files, and reading them. Steven D'Aprano <steve@pearwood.info> - 2015-11-14 16:40 +1100
          Re: Problems using struct pack/unpack in files, and reading them. Ian Kelly <ian.g.kelly@gmail.com> - 2015-11-14 08:43 -0700
            Re: Problems using struct pack/unpack in files, and reading them. Marko Rauhamaa <marko@pacujo.net> - 2015-11-14 18:52 +0200
              Re: Problems using struct pack/unpack in files, and reading them. Chris Angelico <rosuav@gmail.com> - 2015-11-15 04:04 +1100
                Re: Problems using struct pack/unpack in files, and reading them. Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2015-11-16 19:19 +1300
              Re: Problems using struct pack/unpack in files, and reading them. Ian Kelly <ian.g.kelly@gmail.com> - 2015-11-14 10:04 -0700
                Re: Problems using struct pack/unpack in files, and reading them. Marko Rauhamaa <marko@pacujo.net> - 2015-11-14 23:53 +0200
                Re: Problems using struct pack/unpack in files, and reading them. Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2015-11-16 19:15 +1300
                  Re: Problems using struct pack/unpack in files, and reading them. Steven D'Aprano <steve@pearwood.info> - 2015-11-16 23:11 +1100
                    Re: Problems using struct pack/unpack in files, and reading them. Dave Farrance <df@see.replyto.invalid> - 2015-11-17 09:54 +0000
              Re: Problems using struct pack/unpack in files, and reading them. Ian Kelly <ian.g.kelly@gmail.com> - 2015-11-14 10:13 -0700
              Re: Problems using struct pack/unpack in files, and reading them. Random832 <random832@fastmail.com> - 2015-11-14 17:53 -0500
                Re: Problems using struct pack/unpack in files, and reading them. Marko Rauhamaa <marko@pacujo.net> - 2015-11-15 02:12 +0200
                Re: Problems using struct pack/unpack in files, and reading them. Steven D'Aprano <steve@pearwood.info> - 2015-11-15 12:14 +1100
                  Re: Problems using struct pack/unpack in files, and reading them. Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2015-11-15 11:09 -0500
                    Re: Problems using struct pack/unpack in files, and reading them. Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2015-11-16 19:11 +1300
              Re: Problems using struct pack/unpack in files, and reading them. MRAB <python@mrabarnett.plus.com> - 2015-11-15 00:49 +0000
            Re: Problems using struct pack/unpack in files, and reading them. Steven D'Aprano <steve@pearwood.info> - 2015-11-15 13:08 +1100
              Re: Problems using struct pack/unpack in files, and reading them. Chris Angelico <rosuav@gmail.com> - 2015-11-15 13:23 +1100
                Re: Problems using struct pack/unpack in files, and reading them. Steven D'Aprano <steve@pearwood.info> - 2015-11-17 00:17 +1100
                  Re: Problems using struct pack/unpack in files, and reading them. Chris Angelico <rosuav@gmail.com> - 2015-11-17 00:27 +1100
          Re: Problems using struct pack/unpack in files, and reading them. Chris Angelico <rosuav@gmail.com> - 2015-11-15 03:59 +1100
      Re: Problems using struct pack/unpack in files, and reading them. Ian Kelly <ian.g.kelly@gmail.com> - 2015-11-13 20:45 -0700
      Re: Problems using struct pack/unpack in files, and reading them. Ian Kelly <ian.g.kelly@gmail.com> - 2015-11-13 20:48 -0700
      Re: Problems using struct pack/unpack in files, and reading them. Chris Angelico <rosuav@gmail.com> - 2015-11-14 14:56 +1100
      Re: Problems using struct pack/unpack in files, and reading them. Chris Angelico <rosuav@gmail.com> - 2015-11-14 14:57 +1100

Page 1 of 2  [1] 2  Next page →

#98777 — Re: Problems using struct pack/unpack in files, and reading them.

On Sat, Nov 14, 2015 at 6:45 AM, Ian Kelly <ian.g.kelly@gmail.com> wrote:
> This sets RegisterAX to 2. Specifically, positive 2. If you want to
> *add* 2, you probably meant to write:
>
>     RegisterAX += 2
>
> This also points out a good reason for using spaces around operators,
> as "RegisterAX =+ 2" would have caused a SyntaxError and been more
> easily detectable.

Err, no. Even with spaces, it works just fine, because unary plus is
allowed to be separated from its operand with spaces:

>>> x=1
>>> x =+ 2
>>> x = + 3
>>> x
3

However, this is a reasonable call for the abolition of unary plus...

ChrisA

[toc] | [next] | [standalone]

#98787

On Sat, 14 Nov 2015 09:42 am, Chris Angelico wrote:

> However, this is a reasonable call for the abolition of unary plus...

The only way you'll take unary plus out of Python is by prying it from my
cold, dead hands.


BTW, unary minus suffers from the same "problem":

x =- y  # oops, meant x -= y

If anything, this is an argument against the augmented assignment
short-cuts, rather than the operators.


-- 
Steven

[toc] | [prev] | [next] | [standalone]

#98788

On Sat, Nov 14, 2015 at 1:40 PM, Steven D'Aprano <steve@pearwood.info> wrote:
> On Sat, 14 Nov 2015 09:42 am, Chris Angelico wrote:
>
>> However, this is a reasonable call for the abolition of unary plus...
>
> The only way you'll take unary plus out of Python is by prying it from my
> cold, dead hands.
>
>
> BTW, unary minus suffers from the same "problem":
>
> x =- y  # oops, meant x -= y
>
> If anything, this is an argument against the augmented assignment
> short-cuts, rather than the operators.

Yes, unary minus has the same issue - but it's a lot more important
than unary plus is. In ECMAScript, unary plus means "force this to be
a number"; what's its purpose in Python?

ChrisA

[toc] | [prev] | [next] | [standalone]

#98796

On Sat, 14 Nov 2015 02:01 pm, Chris Angelico wrote:

> On Sat, Nov 14, 2015 at 1:40 PM, Steven D'Aprano <steve@pearwood.info>
> wrote:
>> On Sat, 14 Nov 2015 09:42 am, Chris Angelico wrote:
>>
>>> However, this is a reasonable call for the abolition of unary plus...
>>
>> The only way you'll take unary plus out of Python is by prying it from my
>> cold, dead hands.
>>
>>
>> BTW, unary minus suffers from the same "problem":
>>
>> x =- y  # oops, meant x -= y
>>
>> If anything, this is an argument against the augmented assignment
>> short-cuts, rather than the operators.
> 
> Yes, unary minus has the same issue - but it's a lot more important
> than unary plus is. In ECMAScript, unary plus means "force this to be
> a number"; what's its purpose in Python?


Python has operator overloading, so it can be anything you want it to be.
E.g. you might have a DSL where +feature turns something on and -feature
turns it off.


Decimal uses it to force the current precision and rounding, regardless of
what the number was initiated to:


py> from decimal import *
py> setcontext(Context(prec=5))
py> d = Decimal("12.34567890")
py> print(d, +d)
12.34567890 12.346


Counter uses it to strip zero and negative counts:


py> from collections import Counter
py> d = Counter(a=3, b=-3)
py> print(d)
Counter({'a': 3, 'b': -3})
py> print(+d)
Counter({'a': 3})


I would expect that symbolic maths software like Sympy probably has use of a
unary plus operator, but I'm not sure.


It's probably too late now, but if I had designed the Fraction class, I
would have made it inherit from a pure Rational class that didn't
automatically normalise (there are interesting operations that rely on
distinguishing fractions like 1/2 and 2/4), and have + perform
normalisation:

x = Rational(2, 4)
print(x, +x)
=> prints 2/4 1/2


Likewise one might use unary plus to normalise polar or cylindrical
coordinates, etc.

I might consider stealing an idea from Perl and Javascript, and have unary
plus convert strings to a number:

+"123" 
=> returns int 123
+"1.23"
=> returns float 1.23



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#98813

On Fri, Nov 13, 2015 at 10:40 PM, Steven D'Aprano <steve@pearwood.info> wrote:
> Python has operator overloading, so it can be anything you want it to be.
> E.g. you might have a DSL where +feature turns something on and -feature
> turns it off.

By that argument we should also have operators ~, !, $, \, ? because
some hypothetical DSL might someday want to use them for something.

> Decimal uses it to force the current precision and rounding, regardless of
> what the number was initiated to:
>
> Counter uses it to strip zero and negative counts:
>
> I would expect that symbolic maths software like Sympy probably has use of a
> unary plus operator, but I'm not sure.

Unary plus as normalization does not strike me as being very
intuitive. I never would have known about any of these if I hadn't
read the Counter case in the docs, and then I only remembered it
because it because it seemed janky. Unary minus on Counters is even
weirder, by the way: it first negates the signs of all the values, and
*then* normalizes by removing non-positive values. Who has ever needed
that?

For somebody reading one of these uses of unary plus in real code, I
imagine it would be a bit of a WTF moment if it's the first time
they've encountered it. I don't recall ever seeing any code that
actually used this, though.

> I might consider stealing an idea from Perl and Javascript, and have unary
> plus convert strings to a number:
>
> +"123"
> => returns int 123
> +"1.23"
> => returns float 1.23

Eww.

[toc] | [prev] | [next] | [standalone]

#98816

Ian Kelly <ian.g.kelly@gmail.com>:

> For somebody reading one of these uses of unary plus in real code, I
> imagine it would be a bit of a WTF moment if it's the first time
> they've encountered it. I don't recall ever seeing any code that
> actually used this, though.

What I don't understand is why there is a unary + but no unary /:

   -x ≡ 0 - x
   +x ≡ 0 + x
   /x ≡ 1 / x
   //x ≡ 1 // x
   *x ≡ 1 * x

You could write:

   r = //(//r1 + //r2 + //r3)

for

   r = 1 // (1//r1 + 1//r2 + 1//r3)

Actually, the real question is, is the unary - *really* so useful that
it merits existence or is it just something that was mindlessly copied
into programming languages from elementary school arithmetics?

BTW, Scheme's got the whole set:

    (- 3)
    => -3
    (- 3 2)
    => 1
    (- 3 2 1)
    => 0
    (/ 3)
    => 1/3
    (* 3)
    => 3
    (*)
    => 1

However, there's a tricky discontinuity:

    (apply - 3 '(2 1))
    => 0
    (apply - 3 '(2))
    => 1
    (apply - 3 '())
    => -3


Marko

[toc] | [prev] | [next] | [standalone]

#98818

On Sun, Nov 15, 2015 at 3:52 AM, Marko Rauhamaa <marko@pacujo.net> wrote:
> What I don't understand is why there is a unary + but no unary /:
>
>    -x ≡ 0 - x
>    +x ≡ 0 + x
>    /x ≡ 1 / x
>    //x ≡ 1 // x
>    *x ≡ 1 * x
>
> You could write:
>
>    r = //(//r1 + //r2 + //r3)
>
> for
>
>    r = 1 // (1//r1 + 1//r2 + 1//r3)

Small problem: Since we have / and // operators, it's impossible to
have a unary / operator:

1 // x
1 / (/x)

But leaving that aside, the number of times you'd want this are far
fewer than the times you want unary minus.

> Actually, the real question is, is the unary - *really* so useful that
> it merits existence or is it just something that was mindlessly copied
> into programming languages from elementary school arithmetics?

More likely, copied from C. But that's why I made my other post.

ChrisA

[toc] | [prev] | [next] | [standalone]

#98867

Chris Angelico wrote:
> Small problem: Since we have / and // operators, it's impossible to
> have a unary / operator:

No, it's not -- '//' is already recognised as a single
token distinct from '/ /'. You would just have to leave
a space or use parens in some cases.

-- 
Greg

[toc] | [prev] | [next] | [standalone]

#98819

On Nov 14, 2015 9:56 AM, "Marko Rauhamaa" <marko@pacujo.net> wrote:
>
> Ian Kelly <ian.g.kelly@gmail.com>:
>
> > For somebody reading one of these uses of unary plus in real code, I
> > imagine it would be a bit of a WTF moment if it's the first time
> > they've encountered it. I don't recall ever seeing any code that
> > actually used this, though.
>
> What I don't understand is why there is a unary + but no unary /:
>
>    -x ≡ 0 - x
>    +x ≡ 0 + x
>    /x ≡ 1 / x
>    //x ≡ 1 // x
>    *x ≡ 1 * x
>
> You could write:
>
>    r = //(//r1 + //r2 + //r3)
>
> for
>
>    r = 1 // (1//r1 + 1//r2 + 1//r3)

Unary integer division seems pretty silly since the only possible results
would be 0, 1 or -1.

[toc] | [prev] | [next] | [standalone]

#98828

Ian Kelly <ian.g.kelly@gmail.com>:

> On Nov 14, 2015 9:56 AM, "Marko Rauhamaa" <marko@pacujo.net> wrote:
>>    r = //(//r1 + //r2 + //r3)
>
> Unary integer division seems pretty silly since the only possible
> results would be 0, 1 or -1.

Yep, mixed them up.


Marko

[toc] | [prev] | [next] | [standalone]

#98866

Ian Kelly wrote:
> Unary integer division seems pretty silly since the only possible results
> would be 0, 1 or -1.

Ints are not the only thing that // can be applied to:

 >>> 1.0//0.01
99.0

-- 
Greg

[toc] | [prev] | [next] | [standalone]

#98874

On Mon, 16 Nov 2015 05:15 pm, Gregory Ewing wrote:

> Ian Kelly wrote:
>> Unary integer division seems pretty silly since the only possible results
>> would be 0, 1 or -1.
> 
> Ints are not the only thing that // can be applied to:
> 
>  >>> 1.0//0.01
> 99.0


Good catch!



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#98914

Steven D'Aprano <steve@pearwood.info> wrote:

>On Mon, 16 Nov 2015 05:15 pm, Gregory Ewing wrote:
>
>> Ints are not the only thing that // can be applied to:
>> 
>>  >>> 1.0//0.01
>> 99.0
>
>Good catch!

Hmmm. I see that the float for 0.01 _is_ slightly larger than 0.01

>>> Decimal(0.01)
Decimal('0.01000000000000000020816681711721685132943093776702880859375')

But it seems that 1.0 // 0.01 is not directly equivalent to:

>>> int(1.0 / 0.01)
100

And I see that:

>>> Decimal(1.0 / 0.01)
Decimal('100')
>>> floor(1.0 / 0.01)
100
>>> 0.01 * 100.0 - 1.0
0.0

So I guess that the // operator is _very_ strict in its "floor division"
of floats, but that the "/" operator returns the nearest float value.

[toc] | [prev] | [next] | [standalone]

#98820

On Nov 14, 2015 10:10 AM, "Chris Angelico" <rosuav@gmail.com> wrote:
>
> On Sun, Nov 15, 2015 at 4:04 AM, Ian Kelly <ian.g.kelly@gmail.com> wrote:
> > Unary integer division seems pretty silly since the only possible
results
> > would be 0, 1 or -1.
>
> 1, -1, or ZeroDivisionError. The zero's on the other side. But yes.

// 42 == 1 // 42 == 0

[toc] | [prev] | [next] | [standalone]

#98830

Marko Rauhamaa <marko@pacujo.net> writes:
> Actually, the real question is, is the unary - *really* so useful that
> it merits existence or is it just something that was mindlessly copied
> into programming languages from elementary school arithmetics?

The alternative, if you want to be able to specify negative numbers at
all, is to put - in the literal syntax. So what's "x-1"?

I suppose you could use some *different* symbol in the literal syntax
for negative numbers. I had a calculator once that used a different
symbol (looked like a small superscript minus sign) for it. But Python
is limited to ASCII for basic syntax elements for good reasons.

[toc] | [prev] | [next] | [standalone]

#98831

Random832 <random832@fastmail.com>:

> Marko Rauhamaa <marko@pacujo.net> writes:
>> Actually, the real question is, is the unary - *really* so useful
>> that it merits existence or is it just something that was mindlessly
>> copied into programming languages from elementary school arithmetics?
>
> The alternative, if you want to be able to specify negative numbers at
> all, is to put - in the literal syntax. So what's "x-1"?

Yes, it would have to be part of the literal syntax.

Or, you could do without!

   >>> 7 - 8
   (0-1)

After all, we already have:

   >>> 1 + 3j
   (1+3j)


Marko

[toc] | [prev] | [next] | [standalone]

#98835

On Sun, 15 Nov 2015 09:53 am, Random832 wrote:

> Marko Rauhamaa <marko@pacujo.net> writes:
>> Actually, the real question is, is the unary - *really* so useful that
>> it merits existence or is it just something that was mindlessly copied
>> into programming languages from elementary school arithmetics?
> 
> The alternative, if you want to be able to specify negative numbers at
> all, is to put - in the literal syntax. So what's "x-1"?
> 
> I suppose you could use some *different* symbol in the literal syntax
> for negative numbers. I had a calculator once that used a different
> symbol (looked like a small superscript minus sign) for it. But Python
> is limited to ASCII for basic syntax elements for good reasons.

I have a textbook for Pascal programming which includes a project to write
an "arithmetic evaluator". It uses ~ for unary minus and - for binary
subtraction, and doesn't include unary plus. The reason was to simplify the
parser, so that every symbol had exactly one meaning.

So in an alternate universe where Guido was less influenced by C, or where
he wasn't as good as writing parsers as the real GvR is, we may have ended
up with ~ for unary minus and no unary plus.



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#98855

On Sun, 15 Nov 2015 12:14:45 +1100, Steven D'Aprano <steve@pearwood.info>
declaimed the following:

>So in an alternate universe where Guido was less influenced by C, or where
>he wasn't as good as writing parsers as the real GvR is, we may have ended
>up with ~ for unary minus and no unary plus.

	And we'd be left looking for a symbol for bitwise inversion.
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

[toc] | [prev] | [next] | [standalone]

#98865

Dennis Lee Bieber wrote:
> 	And we'd be left looking for a symbol for bitwise inversion.

Who needs negation when you have bitwise inversion?

minusx = ~x + 1

I know, it doesn't work for floats, but that's just
a simple matter of defining ~ on floats appropriately...

-- 
Greg

[toc] | [prev] | [next] | [standalone]

#98833

On 2015-11-14 22:53, Random832 wrote:
> Marko Rauhamaa <marko@pacujo.net> writes:
>> Actually, the real question is, is the unary - *really* so useful that
>> it merits existence or is it just something that was mindlessly copied
>> into programming languages from elementary school arithmetics?
>
> The alternative, if you want to be able to specify negative numbers at
> all, is to put - in the literal syntax. So what's "x-1"?
>
> I suppose you could use some *different* symbol in the literal syntax
> for negative numbers. I had a calculator once that used a different
> symbol (looked like a small superscript minus sign) for it. But Python
> is limited to ASCII for basic syntax elements for good reasons.
>
APL uses "¯" ('\N{MACRON}'), e.g. "¯1".

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.python

csiph-web