extremely weird and frustrating...

Wed Apr 2 05:47:56 EDT 2014

Thank you Ben. I agree with what you say and just hadn't thought of that - 
because my mind was locked in on MM:SS.
So Mark gave me a piece of code that works perfectly in sorting the field 
how I want.  And now I recognize that Mark's code is NOT a workaround, but 
just taking into account what you just said.
So the good news is: I'm no longer frustrated.
I guess the bad news is:  I'm still weird!
Thanks for the lesson!
Larry

----- Original Message ----- 
From: "Ben Rubinstein" <benr_mc at cogapp.com>
To: "How to use LiveCode" <use-livecode at lists.runrev.com>
Sent: Wednesday, April 02, 2014 3:17 AM
Subject: Re: extremely weird and frustrating...

>I think the point is that (since the new "guessProgrammerIntent" feature 
>that Devin spotted yesterday is no longer available today) the code for 
>interpreting as "dateTime" has to make assumptions when the data isn't 
>explicit.
>
> Not unreasonably, asked to interpret dd:dd as a datetime value, the code 
> guesses that it is HH:MM rather than guessing that it is MM:SS.   Whereas 
> asked to interpret dd:dd:dd it will definitely interpret that as HH:MM:SS.
>
> So I wouldn't agree that
> > What you proposed is a workaround because dateTime does NOT work
> > properly, right?
>
> At worst you could say that the implementer, forced to make a decision 
> about how to interpret an ambiguous input, made the wrong call (interpret 
> it as HH:MM rather than as MM:SS) - but I think it's a judgement call, 
> neither would really be wrong or right, just which is likely to be most 
> useful in most cases.
>
> (Of course it's also worth noting that the way sort works is to apply the 
> sorting function to pairs of input.  The dateTime evaluation is applied to 
> each piece of data in turn - there's no overall evaluation.  An 
> intelligent human operator, asked to sort a dozen items, might start 
> interpreting them as HH:MM, then come across an instance which couldn't 
> validly be interpreted as HH:MM but could be as MM:SS, and therefore 
> decide to start over, now treating everything as MM:SS.  But what we have 
> is a machine, implementing a relatively efficient and flexible mechanism - 
> which rightly precludes behaviour like that.)
>
> Ben
>
>
> On 02/04/2014 09:25, larry at significantplanet.org wrote:
>> Thanks John,
>> I'm not trying to be "cheeky" but I am frustrated.  Sorry Alex.
>>
>> John, what you propose may work - haven't tried it yet.
>> However, that still does not explain why WITHOUT the 0 in front of it, 
>> 9:14
>> was listed before 11:35 in my ascending sort. And just FYI, those are 
>> minutes
>> and seconds I'm using and not hours and minutes.
>>
>> My point is that it seems to me that the dateTime sort does not work
>> properly.  What you proposed is a workaround because dateTime does NOT 
>> work
>> properly, right?
>>
>> ----- Original Message ----- From: "John Dixon" <dixonja at hotmail.co.uk>
>> To: "How to use LiveCode" <use-livecode at lists.runrev.com>
>> Sent: Wednesday, April 02, 2014 2:15 AM
>> Subject: RE: extremely weird and frustrating...
>>
>>
>>> Another way to do this would be to put a 0 in front of the 'hours & 
>>> minutes'
>>> before you sort them...
>>> Alex, it trying to help you... no need to be cheeky !...
>>>
>>> on mouseUp
>>>   set itemdel to ":"
>>>   repeat with count = 1 to the number of lines of fld 1
>>>      if the number of chars of item 1 of line count of fld 1 = 1 then
>>>         put 0 & line count of fld 1 into line count of fld 1
>>>      end if
>>>   end repeat
>>>   sort lines of fld 1
>>> end mouseUp
>>>
>>> would give :
>>>
>>> 01:22
>>> 02:08
>>> 07:47
>>> 09:14
>>> 11:35
>>> 12:16
>>> 15:56
>>> 16:33
>>> 25:34
>>> 34:55
>>>
>>>> From: larry at significantplanet.org
>>>
>>>> Sorry Alex, I do not understand.
>>>>
>>>> 16:33 is sixteen minutes and 33 seconds.
>>>> So why is 25:34 not twenty-five minutes and 34 seconds?
>>>> Last time I checked, there are 60 minutes in an hour.
>>>
>>>> > 25:34 and 34:55 are not valid dateTimes, so where those lines get > 
>>>> > sorted
>>>> > to is not well undefined; it looks as though LC simply decides to 
>>>> > give
>>>> > them a '0:00'.
>>>> >
>>>> > Apart from those two lines, it looks (to me) like the result is > 
>>>> > correct.
>>>> > Isn't it ?
>>>> >
>>>> > -- Alex.
>>>> >
>>>> >
>>>> > On 02/04/2014 08:41, larry at significantplanet.org wrote:
>>>> >> Here is my script line:
>>>> >> sort field myTimes descending dateTime
>>>
>>>> >> 16:33
>>>> >> 15:56
>>>> >> 12:16
>>>> >> 11:35
>>>> >> 9:14
>>>> >> 7:47
>>>> >> 2:08
>>>> >> 1:22
>>>> >> 25:34
>>>> >> 34:55
>>>> >>
>>>
>>>> >> Here is my other script line:
>>>
>>>> >> 25:34
>>>> >> 34:55
>>>> >> 1:22
>>>> >> 2:08
>>>> >> 7:47
>>>> >> 9:14
>>>> >> 11:35
>>>> >> 12:16
>>>> >> 15:56
>>>> >> 16:33
>>>> >>
>>>> >> Seriously?
>>>
>>>
>>> _______________________________________________
>>> use-livecode mailing list
>>> use-livecode at lists.runrev.com
>>> Please visit this url to subscribe, unsubscribe and manage your 
>>> subscription
>>> preferences:
>>> http://lists.runrev.com/mailman/listinfo/use-livecode
>>
>>
>> _______________________________________________
>> use-livecode mailing list
>> use-livecode at lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your 
>> subscription
>> preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
>>
>>
>
>
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your 
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode 