Double Jeopoardy

[Lyle Fairfield]

d1 and d2 are numbers we can store as doubles (8 bytes).

d1 > 0
d2 > 0
d1 < d2

Now s1 and s2 are strings of length 8 bytes. (We can ignore unicode here).

Into s1 and s2 we copy the 8 bytes from d1 and d2 respectively.

Does it follow that s1<s2, (or s1 is ordered before s2) when sorted on a
text or binary compare?

Why?

Why do I ask? Well, if we could prove that this is so (s1<s2 => d1<d2) then
we could order arrays of numbers by using the Wizhook.SortStr ingArray
method.

Why would I want to do that? ... No particular reason ... I have a bunch of
other sorting procedures.

--
Lyle
(for e-mail refer to http://ffdba.com/contacts.htm)

[Jerry Boone]

Re: Double Jeopoardy

WizHook is in A03 so it's safe to use for a while even though it's hidden
and undocumented.

Interesting talk about it here though:

http://www.utteraccess.com/forums/access/access561560.html

--
Jerry Boone
Analytical Technologies, Inc.

http://www.antech.biz

Secure Hosting and Development Solutions for ASP, ASP.NET, SQL Server, and
Access



"Lyle Fairfield" <MissingAddress @Invalid.Com> wrote in message
news:Xns94758E2 D6D79FFDBA@130. 133.1.4...[color=blue]
> d1 and d2 are numbers we can store as doubles (8 bytes).
>
> d1 > 0
> d2 > 0
> d1 < d2
>
> Now s1 and s2 are strings of length 8 bytes. (We can ignore unicode here).
>
> Into s1 and s2 we copy the 8 bytes from d1 and d2 respectively.
>
> Does it follow that s1<s2, (or s1 is ordered before s2) when sorted on a
> text or binary compare?
>
> Why?
>
> Why do I ask? Well, if we could prove that this is so (s1<s2 => d1<d2)[/color]
then[color=blue]
> we could order arrays of numbers by using the Wizhook.SortStr ingArray
> method.
>
> Why would I want to do that? ... No particular reason ... I have a bunch[/color]
of[color=blue]
> other sorting procedures.
>
> --
> Lyle
> (for e-mail refer to http://ffdba.com/contacts.htm)[/color]

[Salad]

Re: Double Jeopoardy

Lyle Fairfield wrote:
[color=blue]
> d1 and d2 are numbers we can store as doubles (8 bytes).
>
> d1 > 0
> d2 > 0
> d1 < d2
>
> Now s1 and s2 are strings of length 8 bytes. (We can ignore unicode here).
>
> Into s1 and s2 we copy the 8 bytes from d1 and d2 respectively.
>
> Does it follow that s1<s2, (or s1 is ordered before s2) when sorted on a
> text or binary compare?
>
> Why?
>
> Why do I ask? Well, if we could prove that this is so (s1<s2 => d1<d2) then
> we could order arrays of numbers by using the Wizhook.SortStr ingArray
> method.
>
> Why would I want to do that? ... No particular reason ... I have a bunch of
> other sorting procedures.
>
> --
> Lyle
> (for e-mail refer to http://ffdba.com/contacts.htm)[/color]

Since they are different storage mediums (ex...how many times do you get the
first 3 bytes of a double?) I would suggest you store them into a string left
padded. Since that method adds overhead, I doubt I'd use it.

We've seen where 1,10,100 come before 2, 20, 200 in a string sort....unless
padded.

[Lyle Fairfield]

Re: Double Jeopoardy

Salad <oil@vinegar.co m> wrote in news:400C502B.D 9EC6E90@vinegar .com:
[color=blue]
> Lyle Fairfield wrote:
>[color=green]
>> d1 and d2 are numbers we can store as doubles (8 bytes).
>>
>> d1 > 0
>> d2 > 0
>> d1 < d2
>>
>> Now s1 and s2 are strings of length 8 bytes. (We can ignore unicode
>> here).
>>
>> Into s1 and s2 we copy the 8 bytes from d1 and d2 respectively.
>>
>> Does it follow that s1<s2, (or s1 is ordered before s2) when sorted on
>> a text or binary compare?
>>
>> Why?
>>
>> Why do I ask? Well, if we could prove that this is so (s1<s2 => d1<d2)
>> then we could order arrays of numbers by using the
>> Wizhook.SortStr ingArray method.
>>
>> Why would I want to do that? ... No particular reason ... I have a
>> bunch of other sorting procedures.
>>
>> --
>> Lyle
>> (for e-mail refer to http://ffdba.com/contacts.htm)[/color]
>
> Since they are different storage mediums (ex...how many times do you get
> the first 3 bytes of a double?) I would suggest you store them into a
> string left padded. Since that method adds overhead, I doubt I'd use
> it.
>
> We've seen where 1,10,100 come before 2, 20, 200 in a string
> sort....unless padded.[/color]

sigh ...

--
Lyle
(for e-mail refer to http://ffdba.com/contacts.htm)

[Dimitri Furman]

Re: Double Jeopoardy

On Jan 19 2004, 01:58 pm, Lyle Fairfield <MissingAddress @Invalid.Com>
wrote in news:Xns94758E2 D6D79FFDBA@130. 133.1.4:
[color=blue]
> Why do I ask? Well, if we could prove that this is so (s1<s2 => d1<d2)
> then we could order arrays of numbers by using the
> Wizhook.SortStr ingArray method.[/color]

This wouldn't be particularly fast, having first allocate strings then sort
them. So I'd stick with those other procedures. Note that this doesn't
answer your original question.
[color=blue]
> Why would I want to do that? ... No particular reason ... I have a
> bunch of other sorting procedures.[/color]

--
(remove a 9 to reply by email)

[Terry Kreft]

Re: Double Jeopoardy

Thoughts only ...

Depends on how you do the copying, Windows systems are little endian so the
bytes are stuffed in from the left hand side, if you just CopyMemory this it
will be the wrong way around.

Doubles are IEEE 8 byte floating numbers so you would also have a problem
with the sign bit.


Terry



"Lyle Fairfield" <MissingAddress @Invalid.Com> wrote in message
news:Xns94758E2 D6D79FFDBA@130. 133.1.4...[color=blue]
> d1 and d2 are numbers we can store as doubles (8 bytes).
>
> d1 > 0
> d2 > 0
> d1 < d2
>
> Now s1 and s2 are strings of length 8 bytes. (We can ignore unicode here).
>
> Into s1 and s2 we copy the 8 bytes from d1 and d2 respectively.
>
> Does it follow that s1<s2, (or s1 is ordered before s2) when sorted on a
> text or binary compare?
>
> Why?
>
> Why do I ask? Well, if we could prove that this is so (s1<s2 => d1<d2)[/color]
then[color=blue]
> we could order arrays of numbers by using the Wizhook.SortStr ingArray
> method.
>
> Why would I want to do that? ... No particular reason ... I have a bunch[/color]
of[color=blue]
> other sorting procedures.
>
> --
> Lyle
> (for e-mail refer to http://ffdba.com/contacts.htm)[/color]

[Peter Miller]

Re: Double Jeopoardy


On Tue, 20 Jan 2004 16:48:09 -0000, "Terry Kreft"
<terry.kreft@mp s.co.uk> wrote in comp.databases. ms-access:
[color=blue]
>Doubles are IEEE 8 byte floating numbers so you would also have a problem
>with the sign bit.[/color]

Not really. Lyle made clear he was dealing solely with positive
numbers. The sign bit is zero for positive numbers and 1 for negative
numbers, so its a non-issue for the given problem.

Peter Miller
_______________ _______________ _______________ _______________
PK Solutions -- Data Recovery for Microsoft Access/Jet/SQL
Free quotes, Guaranteed lowest prices and best results
www.pksolutions.com 1.866.FILE.FIX 1.760.476.9051

[Peter Miller]

Re: Double Jeopoardy


Lyle,

On 19 Jan 2004 18:58:44 GMT, Lyle Fairfield
<MissingAddress @Invalid.Com> wrote in comp.databases. ms-access:
[color=blue]
>d1 and d2 are numbers we can store as doubles (8 bytes).
>
>d1 > 0
>d2 > 0
>d1 < d2
>
>Now s1 and s2 are strings of length 8 bytes. (We can ignore unicode here).
>
>Into s1 and s2 we copy the 8 bytes from d1 and d2 respectively.
>
>Does it follow that s1<s2, (or s1 is ordered before s2) when sorted on a
>text or binary compare?
>
>Why?[/color]

Who cares why!

Knowledge for knowledge's sake, right? Isn't that good enough a
reason?

As long as you make sure you get the byte order correct, you can do as
you suggest and compare double values as strings. But since, in
vb/vba, you can't simply cast one value as another as you could in c,
c++, pascal etc, how are you doing the psudeo-casting? If you're,
say, reading in the values from a file, its trivial (just read an
eight byte string at the i/o point where the double is stored) but if
you're working solely in memory (ie you have a double variable, and
you store it in a string) then the manner used is, of course,
critical. If you can clarify how you're doing the casting, I can give
a clearer answer on whether there'd be any problems.

But two quick points are already clear. (1), a binary comparison is
preferable and (2) working with double values as strings will be
slower than leaving them as doubles.


Peter Miller
_______________ _______________ _______________ _______________
PK Solutions -- Data Recovery for Microsoft Access/Jet/SQL
Free quotes, Guaranteed lowest prices and best results
www.pksolutions.com 1.866.FILE.FIX 1.760.476.9051

[Lyle Fairfield]

Re: Double Jeopoardy

Peter Miller <pmiller@pksolu tions.com> wrote in
news:gq5r00ph3h eg3s7j18dk3snos os4vnqhba@4ax.c om:
[color=blue]
> As long as you make sure you get the byte order correct, you can do as
> you suggest and compare double values as strings. But since, in
> vb/vba, you can't simply cast one value as another as you could in c,
> c++, pascal etc, how are you doing the psudeo-casting?[/color]

API CopyMemory

--
Lyle
(for e-mail refer to http://ffdba.com/contacts.htm)

[Tom van Stiphout]

Re: Double Jeopoardy

On 21 Jan 2004 03:36:31 GMT, Lyle Fairfield
<MissingAddress @Invalid.Com> wrote:

That seems risky, because of the byte layout, which is not as innocent
people (not sure that includes you :-)) might expect.
As a test, use the longint &HAABBCCDD&, CopyMemory it, and observe
you're not getting the characters for &HAA, &HBB etc in that order.

-Tom.

[color=blue]
>Peter Miller <pmiller@pksolu tions.com> wrote in
>news:gq5r00ph3 heg3s7j18dk3sno sos4vnqhba@4ax. com:
>[color=green]
>> As long as you make sure you get the byte order correct, you can do as
>> you suggest and compare double values as strings. But since, in
>> vb/vba, you can't simply cast one value as another as you could in c,
>> c++, pascal etc, how are you doing the psudeo-casting?[/color]
>
>API CopyMemory[/color]

[Lyle Fairfield]

Re: Double Jeopoardy

Tom van Stiphout <tom7744@no.spa m.cox.net> wrote in
news:nm2s00llrl 4mcpob719b3lpoc 2e4bl1t88@4ax.c om:
[color=blue]
> On 21 Jan 2004 03:36:31 GMT, Lyle Fairfield
><MissingAddres s@Invalid.Com> wrote:
>
> That seems risky, because of the byte layout, which is not as innocent
> people (not sure that includes you :-)) might expect.
> As a test, use the longint &HAABBCCDD&, CopyMemory it, and observe
> you're not getting the characters for &HAA, &HBB etc in that order.
>
> -Tom.[/color]

My not so carefully checked or documented code ...

I start with strings here only because I want to test to be sure I get back
to the right strings. Of course later, I will start directly from the
doubles.

Option Base 0
Option Explicit

Private Declare Sub CopyMemory _
Lib "kernel32" Alias "RtlMoveMem ory" _
(Destination As Any, Source As Any, ByVal Length As Long)

Public Sub test()

Dim aByteArrays() As Byte
Dim aBytes() As Byte
Dim aDoubles(0 To 2) As Double
Dim aStrings(0 To 2) As String

Dim lngIterator As Long
Dim lngOutsideItera tor As Long
Dim lngInsideIterat or As Long
Dim strDummy As String
Dim strMessage As String

aStrings(0) = "QRSTUVWX"
aStrings(1) = "IJKLMNOP"
aStrings(2) = "ABCDEFGH"

'Store the 8 bytes in a Byte Array
ReDim aByteArrays(8 * (UBound(aString s) - LBound(aStrings ) + 1))
For lngIterator = 0 To 2
aBytes = StrConv(aString s(lngIterator), vbFromUnicode)
CopyMemory aByteArrays(8 * lngIterator), aBytes(0), 8
Next

' first check
' do we have the right bytes in the byte arrays
strMessage = "Original Strings" & vbTab
For lngOutsideItera tor = 0 To 2
strDummy = ""
For lngInsideIterat or = 0 To 7
strDummy = strDummy & Chr$(aByteArray s(lngInsideIter ator +
lngOutsideItera tor * 8))
Next lngInsideIterat or
strMessage = strMessage & strDummy & vbTab
Next lngOutsideItera tor


' we get the original three strings
' so it seems we can store these chars as bytes

' now to create the doubles

strMessage = strMessage & vbNewLine & "AS Doubles" & vbTab
For lngIterator = 0 To 2
CopyMemory aDoubles(lngIte rator), aByteArrays(8 * lngIterator), 8
strMessage = strMessage & aDoubles(lngIte rator) & vbTab
Next lngIterator

' we should now have the double equivalent of our strings
' this will show us the double for which the bytes corresponding
' to "ABCDEFG" ar stored

' now reverse the process to convert these back into Byte Arrays
For lngIterator = 0 To 2
CopyMemory aByteArrays(8 * lngIterator), aDoubles(lngIte rator), 8
Next lngIterator

'and convert those byte arrays back to Strings
strMessage = strMessage & vbNewLine & "Back to Strings" & vbTab
For lngIterator = 0 To 2
CopyMemory aBytes(0), aByteArrays(8 * lngIterator), 8
aStrings(lngIte rator) = StrConv(aBytes, vbUnicode)
strMessage = strMessage & aStrings(lngIte rator) & vbTab
Next lngIterator

' OK let's sort the string array
With WizHook
.Key = 51488399
.SortStringArra y aStrings
End With

' lets check and see if it was sorted correctly
strMessage = strMessage & vbNewLine & "Strings Sorted" & vbTab
For lngIterator = 0 To 2
strMessage = strMessage & aStrings(lngIte rator) & vbTab
Next lngIterator

' so far ... so good

' Now
' lets convert the strings back to doubles
' put the 8 bytes from each string back into the byte arrays
For lngIterator = 0 To 2
aBytes = StrConv(aString s(lngIterator), vbFromUnicode)
CopyMemory aByteArrays(8 * lngIterator), aBytes(0), 8
Next

' and put the bytes back into the double storage
strMessage = strMessage & vbNewLine & "Doubles Sorted" & vbTab
For lngIterator = 0 To 2
CopyMemory aDoubles(lngIte rator), aByteArrays(8 * lngIterator), 8
strMessage = strMessage & aDoubles(lngIte rator) & vbTab
Next lngIterator

' are they sorted
strMessage = strMessage & vbNewLine
If (aDoubles(0) <= aDoubles(1)) Then
strMessage = strMessage & vbNewLine & aDoubles(0) & " <= " &
aDoubles(1)
Else
strMessage = strMessage & vbNewLine & aDoubles(0) & " IS NOT <= " &
aDoubles(1)
End If
If (aDoubles(1) <= aDoubles(2)) Then
strMessage = strMessage & vbNewLine & aDoubles(1) & " <= " &
aDoubles(2)
Else
strMessage = strMessage & vbNewLine & aDoubles(1) & " IS NOT <= " &
aDoubles(2)
End If

strMessage = strMessage & vbNewLine & vbNewLine _
& "Yes, I know I did a million unnecessary things " _
& vbNewLine _
& "and you could probably figure out why!"


MsgBox strMessage

End Sub

--
Lyle
(for e-mail refer to http://ffdba.com/contacts.htm)

[Michael \(michka\) Kaplan [MS]]

Re: Double Jeopoardy

This code has a lot of problems in it, not least of all the fact that it
takes Unicode strings and converts them to Unicode (making "double Unicode",
an encoding not found in nature!).


--
MichKa [MS]
NLS Collation/Locale/Keyboard Development
Globalization Infrastructure and Font Technologies

This posting is provided "AS IS" with
no warranties, and confers no rights.


"Lyle Fairfield" <MissingAddress @Invalid.Com> wrote in message
news:Xns947736A 52E4EAFFDBA@130 .133.1.4...[color=blue]
> Tom van Stiphout <tom7744@no.spa m.cox.net> wrote in
> news:nm2s00llrl 4mcpob719b3lpoc 2e4bl1t88@4ax.c om:
>[color=green]
> > On 21 Jan 2004 03:36:31 GMT, Lyle Fairfield
> ><MissingAddres s@Invalid.Com> wrote:
> >
> > That seems risky, because of the byte layout, which is not as innocent
> > people (not sure that includes you :-)) might expect.
> > As a test, use the longint &HAABBCCDD&, CopyMemory it, and observe
> > you're not getting the characters for &HAA, &HBB etc in that order.
> >
> > -Tom.[/color]
>
> My not so carefully checked or documented code ...
>
> I start with strings here only because I want to test to be sure I get[/color]
back[color=blue]
> to the right strings. Of course later, I will start directly from the
> doubles.
>
> Option Base 0
> Option Explicit
>
> Private Declare Sub CopyMemory _
> Lib "kernel32" Alias "RtlMoveMem ory" _
> (Destination As Any, Source As Any, ByVal Length As Long)
>
> Public Sub test()
>
> Dim aByteArrays() As Byte
> Dim aBytes() As Byte
> Dim aDoubles(0 To 2) As Double
> Dim aStrings(0 To 2) As String
>
> Dim lngIterator As Long
> Dim lngOutsideItera tor As Long
> Dim lngInsideIterat or As Long
> Dim strDummy As String
> Dim strMessage As String
>
> aStrings(0) = "QRSTUVWX"
> aStrings(1) = "IJKLMNOP"
> aStrings(2) = "ABCDEFGH"
>
> 'Store the 8 bytes in a Byte Array
> ReDim aByteArrays(8 * (UBound(aString s) - LBound(aStrings ) + 1))
> For lngIterator = 0 To 2
> aBytes = StrConv(aString s(lngIterator), vbFromUnicode)
> CopyMemory aByteArrays(8 * lngIterator), aBytes(0), 8
> Next
>
> ' first check
> ' do we have the right bytes in the byte arrays
> strMessage = "Original Strings" & vbTab
> For lngOutsideItera tor = 0 To 2
> strDummy = ""
> For lngInsideIterat or = 0 To 7
> strDummy = strDummy & Chr$(aByteArray s(lngInsideIter ator +
> lngOutsideItera tor * 8))
> Next lngInsideIterat or
> strMessage = strMessage & strDummy & vbTab
> Next lngOutsideItera tor
>
>
> ' we get the original three strings
> ' so it seems we can store these chars as bytes
>
> ' now to create the doubles
>
> strMessage = strMessage & vbNewLine & "AS Doubles" & vbTab
> For lngIterator = 0 To 2
> CopyMemory aDoubles(lngIte rator), aByteArrays(8 * lngIterator), 8
> strMessage = strMessage & aDoubles(lngIte rator) & vbTab
> Next lngIterator
>
> ' we should now have the double equivalent of our strings
> ' this will show us the double for which the bytes corresponding
> ' to "ABCDEFG" ar stored
>
> ' now reverse the process to convert these back into Byte Arrays
> For lngIterator = 0 To 2
> CopyMemory aByteArrays(8 * lngIterator), aDoubles(lngIte rator), 8
> Next lngIterator
>
> 'and convert those byte arrays back to Strings
> strMessage = strMessage & vbNewLine & "Back to Strings" & vbTab
> For lngIterator = 0 To 2
> CopyMemory aBytes(0), aByteArrays(8 * lngIterator), 8
> aStrings(lngIte rator) = StrConv(aBytes, vbUnicode)
> strMessage = strMessage & aStrings(lngIte rator) & vbTab
> Next lngIterator
>
> ' OK let's sort the string array
> With WizHook
> .Key = 51488399
> .SortStringArra y aStrings
> End With
>
> ' lets check and see if it was sorted correctly
> strMessage = strMessage & vbNewLine & "Strings Sorted" & vbTab
> For lngIterator = 0 To 2
> strMessage = strMessage & aStrings(lngIte rator) & vbTab
> Next lngIterator
>
> ' so far ... so good
>
> ' Now
> ' lets convert the strings back to doubles
> ' put the 8 bytes from each string back into the byte arrays
> For lngIterator = 0 To 2
> aBytes = StrConv(aString s(lngIterator), vbFromUnicode)
> CopyMemory aByteArrays(8 * lngIterator), aBytes(0), 8
> Next
>
> ' and put the bytes back into the double storage
> strMessage = strMessage & vbNewLine & "Doubles Sorted" & vbTab
> For lngIterator = 0 To 2
> CopyMemory aDoubles(lngIte rator), aByteArrays(8 * lngIterator), 8
> strMessage = strMessage & aDoubles(lngIte rator) & vbTab
> Next lngIterator
>
> ' are they sorted
> strMessage = strMessage & vbNewLine
> If (aDoubles(0) <= aDoubles(1)) Then
> strMessage = strMessage & vbNewLine & aDoubles(0) & " <= " &
> aDoubles(1)
> Else
> strMessage = strMessage & vbNewLine & aDoubles(0) & " IS NOT <= "[/color]
&[color=blue]
> aDoubles(1)
> End If
> If (aDoubles(1) <= aDoubles(2)) Then
> strMessage = strMessage & vbNewLine & aDoubles(1) & " <= " &
> aDoubles(2)
> Else
> strMessage = strMessage & vbNewLine & aDoubles(1) & " IS NOT <= "[/color]
&[color=blue]
> aDoubles(2)
> End If
>
> strMessage = strMessage & vbNewLine & vbNewLine _
> & "Yes, I know I did a million unnecessary things " _
> & vbNewLine _
> & "and you could probably figure out why!"
>
>
> MsgBox strMessage
>
> End Sub
>
> --
> Lyle
> (for e-mail refer to http://ffdba.com/contacts.htm)[/color]

[Peter Miller]

Re: Double Jeopoardy


Lyle,

On 21 Jan 2004 10:22:17 GMT, Lyle Fairfield
<MissingAddress @Invalid.Com> wrote in comp.databases. ms-access:
[color=blue]
>My not so carefully checked or documented code ...[/color]

I took as a starting point an array of 10,000 random double values,
and saw that wizhook.sortstr ingarray failed miserably.

This is just my 2c, but here's my take on your approach:

1) Are you sure wizhook's sortstringarray method does a straight
binary comparison? Being largely undocumented, I haven't been able to
verify this. Your sample test is, of course, trivial, since you start
with simple clear strings.

2) How does sortstringarray handle null bytes? Null bytes aren't
present in your sample code, of course, but would not be uncommon in
the bytes of a double. Since a null byte typically implies the end of
a string, sortstringarray may well stop looking at the remaining bytes
of a double that has a null byte in its midst.

3) I was surprised to see that sortstringarray is generally pretty
quick. I expected it to clearly lag behind even a vba-based shell
sort. So my initial impression that it failed on speed alone,
regardless of whether it was appropriate for use with converted
doubles, was mistaken. Its still not as efficient as a properly
implemented sort of the double array, and you still have the overhead
of converting from doubles and back again, but its not ridiculously
slow.



Peter Miller
_______________ _______________ _______________ _______________
PK Solutions -- Data Recovery for Microsoft Access/Jet/SQL
Free quotes, Guaranteed lowest prices and best results
www.pksolutions.com 1.866.FILE.FIX 1.760.476.9051

[Lyle Fairfield]

Re: Double Jeopoardy

Peter Miller <pmiller@pksolu tions.com> wrote in
news:antt001nrb dk74crpq3cpcmck 2aqegou0n@4ax.c om:
[color=blue]
>
> Lyle,
>
> On 21 Jan 2004 10:22:17 GMT, Lyle Fairfield
><MissingAddres s@Invalid.Com> wrote in comp.databases. ms-access:
>[color=green]
>>My not so carefully checked or documented code ...[/color]
>
> I took as a starting point an array of 10,000 random double values,
> and saw that wizhook.sortstr ingarray failed miserably.
>
> This is just my 2c, but here's my take on your approach:
>
> 1) Are you sure wizhook's sortstringarray method does a straight
> binary comparison? Being largely undocumented, I haven't been able to
> verify this. Your sample test is, of course, trivial, since you start
> with simple clear strings.
>
> 2) How does sortstringarray handle null bytes? Null bytes aren't
> present in your sample code, of course, but would not be uncommon in
> the bytes of a double. Since a null byte typically implies the end of
> a string, sortstringarray may well stop looking at the remaining bytes
> of a double that has a null byte in its midst.
>
> 3) I was surprised to see that sortstringarray is generally pretty
> quick. I expected it to clearly lag behind even a vba-based shell
> sort. So my initial impression that it failed on speed alone,
> regardless of whether it was appropriate for use with converted
> doubles, was mistaken. Its still not as efficient as a properly
> implemented sort of the double array, and you still have the overhead
> of converting from doubles and back again, but its not ridiculously
> slow.[/color]

After a bit of experimentation I suspect that (as you guess)
SortStringArray does not handle null bytes as we might hope or expect.

It seems to sort

1. null.B.B.B
2. null.null.B.B
3. null.null.null. B
4. null.null.null. null
5. B.B.B.B

in that order: 1,2,3,4,5,

I think one might have expected 4,3,2,1,5.

so ... I guess my plan could not work without some mapping of null bytes to
.... what?

If we map them to anything else how would we differentiate that anything
else which is really a zero, to the anything else that is really the
anything else?

We'd have to have a mirrow array, perhaps, showing which anything elses
were legitimate, and which were really zeroes. This is likely to take any
usefulness away from the procedure.

A far as learning ... I found that I could not INSERT a record with a field
value set to vbNullChar & other characters in SQL, but that I could cut and
paste a vbNullChar & other characters value to a text field. I tried a
binary field as well, but the results were the same.

Time for some real work now ...


--
Lyle
(for e-mail refer to http://ffdba.com/contacts.htm)

[Peter Miller]

Re: Double Jeopoardy


On 22 Jan 2004 02:50:49 GMT, Lyle Fairfield
<MissingAddress @Invalid.Com> wrote in comp.databases. ms-access:
[color=blue]
>so ... I guess my plan could not work without some mapping of null bytes to
>... what?[/color]

Nothing. Every other byte value is possible in an actual double
value, so there's no 'marker' values to spare.

I also did a little poking around, and found that the sort is not
remotely binary in nature. All variants of 'e', for instance (upper,
lower, various accents) occur before all values of 'f', and so on.
Absolutely useless for binary comparisons. Of course, 'option compare
binary' doesn't help with this wizhook method.
[color=blue]
>Time for some real work now ...[/color]

Aw, that's no fun...

Peter Miller
_______________ _______________ _______________ _______________
PK Solutions -- Data Recovery for Microsoft Access/Jet/SQL
Free quotes, Guaranteed lowest prices and best results
www.pksolutions.com 1.866.FILE.FIX 1.760.476.9051