"What PowerShell does is to use the type of the first element of the expression to type the expression."

Well, not completely. If the type of the first expression is [int] the expression is always floating point, so:

PS1> [int]1/2

0.5

(which is of type double)

Nice post… this is one of the best descriptions of how PoSH handles this that I’ve seen. I spent a while tripping over bits of this before I realized what I was doing. Consider it bookmarked for reference.

Just wanted to kick out a heads up for an excellent post that shows some of the different variable types

From an earlier comment:

>Well, not completely. If the type of the first expression is [int] the expression is always floating point, so:

>

> PS1> [int]1/2

>

> 0.5

>

> (which is of type double)

That’s not quite accurate as illustrated by these two examples:

PS (11) > (6/3).gettype().fullname

System.Int32

PS (12) > (6/34).gettype().fullname

System.Double

For numeric operations, PowerShell uses widening. If the result of the operation cannot be exactly represented using the base types of the operation, then the next widest type that can hold the result will be used, within the limitations of the .NET numeric types (we don’t support arbitrary precision yet.) This is what’s happening here. 1/2 cannot be properly represented as an int to the result is widened to double (yes – we skip single precision).

If you cast the whole expression to [int] then you’ll get an integer result:

PS (13) > [int](1/2)

0

Note that like VB, we use "banker’s rounding" so

PS (14) > [int](3/2)

2

Here we get 2 instead of 1. To get truncation, use [math]::floor()

PS (15) > [math]::floor(3/2).gettype().FullName

System.Double

PS (16) > [math]::floor(3/2)

1

PS (17) > [int] [math]::floor(3/2)

1

The goal of all of this is to have "natural" behaviour for numbers.

See Python PEP 238 for an additional discussion of this issue in Python.

"What PowerShell does is to use the type of the first element of the expression to type the expression."

Well, not completely. If the type of the first expression is [int] the expression is always floating point, so:

PS1> [int]1/2

0.5

(which is of type double)

Nice post… this is one of the best descriptions of how PoSH handles this that I’ve seen. I spent a while tripping over bits of this before I realized what I was doing. Consider it bookmarked for reference.

Just wanted to kick out a heads up for an excellent post that shows some of the different variable types

From an earlier comment:

>Well, not completely. If the type of the first expression is [int] the expression is always floating point, so:

>

> PS1> [int]1/2

>

> 0.5

>

> (which is of type double)

That’s not quite accurate as illustrated by these two examples:

PS (11) > (6/3).gettype().fullname

System.Int32

PS (12) > (6/34).gettype().fullname

System.Double

For numeric operations, PowerShell uses widening. If the result of the operation cannot be exactly represented using the base types of the operation, then the next widest type that can hold the result will be used, within the limitations of the .NET numeric types (we don’t support arbitrary precision yet.) This is what’s happening here. 1/2 cannot be properly represented as an int to the result is widened to double (yes – we skip single precision).

If you cast the whole expression to [int] then you’ll get an integer result:

PS (13) > [int](1/2)

0

Note that like VB, we use "banker’s rounding" so

PS (14) > [int](3/2)

2

Here we get 2 instead of 1. To get truncation, use [math]::floor()

PS (15) > [math]::floor(3/2).gettype().FullName

System.Double

PS (16) > [math]::floor(3/2)

1

PS (17) > [int] [math]::floor(3/2)

1

The goal of all of this is to have "natural" behaviour for numbers.

See Python PEP 238 for an additional discussion of this issue in Python.

http://www.python.org/dev/peps/pep-0238/

(We’re currently missing a floor division operator unfortunately.)

BTW – I spend a bunch of time in my book going over the semantics of all of the operators in (great) detail.

-bruce

Bruce Payette [MSFT]

Windows PowerShell Tech Lead

Visit the Windows PowerShell Team blog at: http://blogs.msdn.com/PowerShell

Visit the Windows PowerShell ScriptCenter at: http://www.microsoft.com/technet/scriptcenter/hubs/msh.mspx

My book:

http://manning.com/powershell

Thanks Bruce for the qualification… I didn’t realise the 6/3 would be an int.

I think the main issue for me is that there is no ‘floor division’ operator; someone somewhere else suggested the pythonesque // for it.

At least this could be added to PS1.1 without breaking backward compatibility.

I have noticed that you can also get truncation by using the decimal type.

[int][decimal](3/2).

Is there a reason you’d want to avoid this as opposed to using floor()?

That’s interesting.

I wouldn’t use it though:

PS> (measure-command { foreach($x in 1..10000) { [Math]::Floor(3/2) } }).totalmilliseconds

64.0313

PS> (measure-command { foreach($x in 1..10000) { [int][decimal](3/2) } }).totalmilliseconds

660.2069

Development Karl Seguin does some testing on his blog about the fastest way to convert a string to an

this is stupid 2+2 equals 4 like always

Nice article. Just took it a step further, have a look how to blend integer and string into one: http://powershell.com/cs/blogs/tobias/archive/2010/01/08/1-equals-quot-running-quot-melting-integer-and-string-objects-together.aspx