Getting the version -- as a number so that it will make
sense in comparison I discovered an oddity.

Neither method below can directly convert from the
"System.Version" type directly to double:

[double][string](Get-Host).version
[double][string]$PSVersionTable.PSVersion



First converting to type string solves the problem but
this is non-intuitive and somewhat odd.

Using comparison operators (or arithmetic) to do an
implicit conversion to a numeric type also fails, and
requires the (even less) intuitive conversion to string
FIRST:

2.0 -ge [string](Get-Host).version

Leave out those [string] conversion and errors result.

Not really a question here, but I thought this might
help someone else, and that some of you may have
some thoughts on this or other approaches that I
might have missed.

--
Herb Martin

Using
(Get-Host).version | fl *
to discover properties as
Major : 2
Minor : 0
Build : -1
Revision : -1
MajorRevision : -1
MinorRevision : -1

I then coded

2 -ge ((Get-Host).version).Major

- Larry

HerbM wrote:

> Getting the version -- as a number so that it will make sense in
> comparison I discovered an oddity.
>
> Neither method below can directly convert from the
> "System.Version" type directly to double:
>
> [double][string](Get-Host).version
> [double][string]$PSVersionTable.PSVersion
>
> First converting to type string solves the problem but
> this is non-intuitive and somewhat odd.
>
> Using comparison operators (or arithmetic) to do an
> implicit conversion to a numeric type also fails, and
> requires the (even less) intuitive conversion to string FIRST:
>
> 2.0 -ge [string](Get-Host).version
>
> Leave out those [string] conversion and errors result.
>
> Not really a question here, but I thought this might help someone else,
> and that some of you may have
> some thoughts on this or other approaches that I
> might have missed.
>

"Larry__Weiss" <lfw@newsgroup> wrote in message
news:OGKyTlYmKHA.1652@newsgroup

> Using
> (Get-Host).version | fl *
> to discover properties as
> Major : 2
> Minor : 0
> Build : -1
> Revision : -1
> MajorRevision : -1
> MinorRevision : -1
>
> I then coded
>
> 2 -ge ((Get-Host).version).Major
> - Larry

Yes, of course, but that is clearly different than
using the entire Version number, Major and Minor.

Right now, such doesn't matter with only versions 1
and 2, but the principal will doubtless be found in
(many?) other places.

Reading "Windows Powershell in Action" by Bruce
Payette (on of the designer/developers) we find this
description of Powershell typing:

"By type-promiscuous, we mean that PowerShell will
expend a tremendous amount of effort trying to turn what
you have into what you need with as little work on your
part as it can manage." (3.1.1 p. 56)

Not in this case it seems....

This isn't a terrible indictment of the type system, but
it is -- clearly -- a less than intuitive oddity.

--
HerbM

> HerbM wrote:

>> Getting the version -- as a number so that it will make sense in
>> comparison I discovered an oddity.
>>
>> Neither method below can directly convert from the
>> "System.Version" type directly to double:
>>
>> [double][string](Get-Host).version
>> [double][string]$PSVersionTable.PSVersion
>>
>> First converting to type string solves the problem but
>> this is non-intuitive and somewhat odd.
>>
>> Using comparison operators (or arithmetic) to do an
>> implicit conversion to a numeric type also fails, and
>> requires the (even less) intuitive conversion to string FIRST:
>>
>> 2.0 -ge [string](Get-Host).version
>>
>> Leave out those [string] conversion and errors result.
>>
>> Not really a question here, but I thought this might help someone else,
>> and that some of you may have
>> some thoughts on this or other approaches that I
>> might have missed.
>>

<#
<Version> constructors
Version ([Int32]$major, [Int32]$minor, [Int32]$build)
Version ([Int32]$major, [Int32]$minor)
Version ([String]$version) # we can use this one w/o New-Object
Version ()
Version ([Int32]$major, [Int32]$minor, [Int32]$build, [Int32]$revision)
#>

# will fail, <String> must match '\d+(\.\d+){1,3}'
[Version]'1'
# notice the default values for the Build and Revision is -1
New-Object Version
[Version]'1.0'

# and that they won't show when cast as string
(New-Object Version) -as 'String'
[Version]'1.0' -as 'String'

[Version]$ver1 = '1.0.0.1'
[Version]$ver2 = '1.0.0.0'

# <Version> implements IComparable interface
[Version].GetInterfaces() | Out-Default

# and its instance has CompareTo method which returns 0 for eq,
# 1 for gt and -1 for lt
$ver1.CompareTo($ver2)

# Version can't be cast as Double
[Double]'2.0.0'
'2.0.0' -as 'Double'

# comparison operators can compare objects of <Version> type,
# just pass a <Version> to their left ooperand and a <String>
# to their right operand
(Get-Host).Version -eq '2.0'
(Get-Host).Version -eq '2.0.0'
(Get-Host).Version -eq '1.9.9.9'

--
Robert

HerbM wrote:

> "Larry__Weiss" wrote

>> Using
>> (Get-Host).version | fl *
>> to discover properties as
>> Major : 2
>> Minor : 0
>> Build : -1
>> Revision : -1
>> MajorRevision : -1
>> MinorRevision : -1
>> I then coded
>> 2 -ge ((Get-Host).version).Major

>
> Yes, of course, but that is clearly different than
> using the entire Version number, Major and Minor.
>
> Right now, such doesn't matter with only versions 1
> and 2, but the principal will doubtless be found in
> (many?) other places.
>
> Reading "Windows Powershell in Action" by Bruce
> Payette (on of the designer/developers) we find this
> description of Powershell typing:
>
> "By type-promiscuous, we mean that PowerShell will
> expend a tremendous amount of effort trying to turn what
> you have into what you need with as little work on your
> part as it can manage." (3.1.1 p. 56)
>
> Not in this case it seems....
>
> This isn't a terrible indictment of the type system, but
> it is -- clearly -- a less than intuitive oddity.
>

It is strange that there is not a wee bit more "effort" to the conversion.

PS C:> (Get-Host).version

Major Minor Build Revision
----- ----- ----- --------
2 0 -1 -1

PS C:> [string](Get-Host).version
2.0
PS C:> [double](Get-Host).version
Cannot convert the "2.0" value of type "System.Version" to type "System.Double"

Implicit conversion is one part of PowerShell that I'm not yet comfortable with.
I suspect it is all coded to the understanding and interpretation of the coder,
to be discovered by trial and error by the user. Is there a spec anywhere that
specifies how every implicit conversion should turn out?

- Larry

Keep in mind, that comparing numbers with floating point might be
tricky..

On Jan 20, 4:25*am, "HerbM" <n...@newsgroup> wrote:

> Getting the version -- as a number so that it will make
> sense in comparison I discovered an oddity.
>
> Neither method below can directly convert from the
> "System.Version" type directly to double:
>
> [double][string](Get-Host).version
> [double][string]$PSVersionTable.PSVersion
>
> First converting to type string solves the problem but
> this is non-intuitive and somewhat odd.
>
> Using comparison operators (or arithmetic) to do an
> implicit conversion to a numeric type also fails, and
> requires the (even less) intuitive conversion to string
> FIRST:
>
> * 2.0 -ge [string](Get-Host).version
>
> Leave out those [string] conversion and errors result.
>
> Not really a question here, but I thought this might
> help someone else, and that some of you may have
> some thoughts on this or other approaches that I
> might have missed.
>
> --
> Herb Martin

Good point, but in this case it is just another way to compare two integers to
two other integers with one pair having precedence. Reminds me of computing
with currency strings containing dollars and pennies. Best to normalize to a
single integer (like $1.99 is the same as 199 pennies) if possible.

- Larry


stej wrote:

> Keep in mind, that comparing numbers with floating point might be
> tricky..
>
> On Jan 20, 4:25 am, "HerbM" <n...@newsgroup> wrote:

>> Getting the version -- as a number so that it will make
>> sense in comparison I discovered an oddity.
>>
>> Neither method below can directly convert from the
>> "System.Version" type directly to double:
>>
>> [double][string](Get-Host).version
>> [double][string]$PSVersionTable.PSVersion
>>
>> First converting to type string solves the problem but
>> this is non-intuitive and somewhat odd.
>>
>> Using comparison operators (or arithmetic) to do an
>> implicit conversion to a numeric type also fails, and
>> requires the (even less) intuitive conversion to string
>> FIRST:
>>
>> 2.0 -ge [string](Get-Host).version
>>
>> Leave out those [string] conversion and errors result.
>>
>> Not really a question here, but I thought this might
>> help someone else, and that some of you may have
>> some thoughts on this or other approaches that I
>> might have missed.
>>
>> --
>> Herb Martin

>

"stej" <cerna.zelva@newsgroup> wrote in message
news:dabf36d5-15b0-4079-a64c-780d26c53300@newsgroup

> Keep in mind, that comparing numbers with floating point might be

tricky..

Yes, absolutely -- I didn't get to the point of worrying about
that before I ran into the other issues.

Probably using a [decimal] value type would be the best
overall choice (in most? cases like this).

See also my follow-up to the idea of Robert's where we
just DO THE COMPARISON (with the string) and it
(again oddly) just seems to work.

Stuff like that does bug me even more. It's one thing when
something fails unexpectedly, but even weirder when
things that fail just work unexpectedly....<grin>


--
Herb

"Robert Robelo" <Kiron@newsgroup> wrote in message
news:OMCb7WemKHA.5520@newsgroup

....

> # comparison operators can compare objects of <Version> type,
> # just pass a <Version> to their left ooperand and a <String>
> # to their right operand
> (Get-Host).Version -eq '2.0'
> (Get-Host).Version -eq '2.0.0'
> (Get-Host).Version -eq '1.9.9.9'

I didn't fully understand the earlier parts of your post,
but this last is very interesting (to the actual Version problem
I am posing)....

My first thought is that comparing what is inherently a number
as a string is problematic (and I am very comfortable with how
Perl works when doing this -- it's a feature.)

But, I simply followed up on your idea and tested some of the
(more pathological) combinations, and the following things just work
(with the one exception):

(Get-Host).Version -lt '2.00'
(Get-Host).Version -ge '2.00'
(Get-Host).Version -eq '2.00'
(Get-Host).Version -eq '+2.00'
(Get-Host).Version -eq '+ 2.00' <<<<< FAILS -- that space mucks it up
(Get-Host).Version -eq '+2.00'
(Get-Host).Version -eq '-2.00'
(Get-Host).Version -eq '-2.00'

All of these give the 'correct answer as do the combos of -le, -lt, -gt
that I tried.

Even with "2 dots" this stuff seems to give sensible (i.e., correct)
answers:

(Get-Host).Version -le '2.0.0'

(Get-Host).Version -le '1.09'

(Get-Host).Version -le '1.00.9'

Also, the following conversion gives a nice answer, but
works no better than the [double] (without [string]) conversion:

[decimal][string](Get-Host).Version


--
Herb
I always learn the most when things don't work as I expect.

No language that I know of will implicitly convert types more than once.
This opens the door to some very difficult debugging and non-intuitive
behavior. There are not a fixed set of types even if there were drawing up a
precedence table would "do the right thing by default" would be difficult to
design and understand.

This is calling the ToString method explicitly which "every type" in .NET
has and then implicitly converting this to a double
2.0 -ge [string](Get-Host).version

Here there is no direct conversion from a either explicit or implicit.

2.0 -ge (Get-Host).version

Lastly

Here there is no direct conversion explicit from Version to a double.
2.0 -ge [double](Get-Host).version

..NET has provided the framework for type conversion via ToString which is
overrideable. This then allows you to compare to any type and convert to
those that have a path which allows the conversion process.

"HerbM" wrote:

> Getting the version -- as a number so that it will make
> sense in comparison I discovered an oddity.
>
> Neither method below can directly convert from the
> "System.Version" type directly to double:
>
> [double][string](Get-Host).version
> [double][string]$PSVersionTable.PSVersion
>
> First converting to type string solves the problem but
> this is non-intuitive and somewhat odd.
>
> Using comparison operators (or arithmetic) to do an
> implicit conversion to a numeric type also fails, and
> requires the (even less) intuitive conversion to string
> FIRST:
>
> 2.0 -ge [string](Get-Host).version
>
> Leave out those [string] conversion and errors result.
>
> Not really a question here, but I thought this might
> help someone else, and that some of you may have
> some thoughts on this or other approaches that I
> might have missed.
>
> --
> Herb Martin
> .
>