Re: valueDiff for arrays?

[Mark Wieder via use-livecode]

On 08/10/2018 05:36 PM, Geoff Canyon via use-livecode wrote:

Are you working with "LiveCode UI elements appear in lists of stacks"
enabled? I specifically named all the script behaviors for Navigator
starting with "rev" and they don't show up in the Project Browser for me.


Exactly. And It's not just navigator that's clogging things up here, I 
don't mean to single it out in particular. But if I need to work on a 
system stack (and I do this all the time) then there's a lot of cruft 
that shows up in the PB or the AB that I have to wade through to get to 
where I want to be.


--
 Mark Wieder
 ahsoftw...@gmail.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: valueDiff for arrays?

[Mark Waddingham via use-livecode]

Or the ui stack is a substack which gets duplicated as another substack under 
the same root, but empty, mainstack...

Mark.

Sent from my iPhone

> On 10 Aug 2018, at 19:48, Brian Milby via use-livecode 
>  wrote:
> 
> In your case it may be a bit more complicated, but I would think still
> attainable.  The key would be for the scripts to live in a sub stack that
> didn't get duplicated.
> 
> On Fri, Aug 10, 2018 at 7:41 PM, Geoff Canyon via use-livecode <
> use-livecode@lists.runrev.com> wrote:
> 
>> On Sat, Aug 4, 2018 at 12:00 PM Brian Milby via use-livecode <
>> use-livecode@lists.runrev.com> wrote:
>> 
>>> Plugins should probably be de-scriptified for distribution for this
>>> reason.
>>> 
>> 
>> This would be very bad for Navigator. Navigator shows multiple copies of
>> itself (as many as you like/can tolerate) and this is only possible because
>> everything is based on behaviors. Before I made the switch, Navigator was
>> limited to three copies of itself, because making any more caused Bad
>> Things to happen. It's been so long I don't remember the details, and
>> obviously that was back in version 5 or earlier, so things might have
>> changed, but regardless of how many gigabytes of RAM we have, duplicating
>> Navigator's code over and over again is problematic.
>> 
>> In short, "I can't go back, man! I won't!" :-)
>> ___
>> use-livecode mailing list
>> use-livecode@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@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@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: valueDiff for arrays?

[Brian Milby via use-livecode]

In your case it may be a bit more complicated, but I would think still
attainable.  The key would be for the scripts to live in a sub stack that
didn't get duplicated.

On Fri, Aug 10, 2018 at 7:41 PM, Geoff Canyon via use-livecode <
use-livecode@lists.runrev.com> wrote:

> On Sat, Aug 4, 2018 at 12:00 PM Brian Milby via use-livecode <
> use-livecode@lists.runrev.com> wrote:
>
> > Plugins should probably be de-scriptified for distribution for this
> > reason.
> >
>
> This would be very bad for Navigator. Navigator shows multiple copies of
> itself (as many as you like/can tolerate) and this is only possible because
> everything is based on behaviors. Before I made the switch, Navigator was
> limited to three copies of itself, because making any more caused Bad
> Things to happen. It's been so long I don't remember the details, and
> obviously that was back in version 5 or earlier, so things might have
> changed, but regardless of how many gigabytes of RAM we have, duplicating
> Navigator's code over and over again is problematic.
>
> In short, "I can't go back, man! I won't!" :-)
> ___
> use-livecode mailing list
> use-livecode@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@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: valueDiff for arrays?

[Brian Milby via use-livecode]

I do it both ways, the problem is that behavior scripts created for
maintaining a stack (version control) are inconvenient in the IDE.  I've
thought about suggesting a multiple step scriptify for IDE tools.  The
first step would be to create a card to house all behavior buttons.  The
first round would scriptify everything to buttons on that card.  The second
round would generate the script only stacks.  Prior to distribution, the
second round would be reversed to have a cleaner namespace inside the IDE.

I've taken a different approach for my own work (Script Tracker).  I just
have my tool export all of the scripts to files.  I can version control the
files and edit them outside of the IDE.  My tool keeps them in sync.  Then
the distributed tool doesn't have any external file requirements.  I still
need to go back and move my SvgIconTool into this model (and will before
the next update).

On Fri, Aug 10, 2018 at 7:36 PM, Geoff Canyon via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Are you working with "LiveCode UI elements appear in lists of stacks"
> enabled? I specifically named all the script behaviors for Navigator
> starting with "rev" and they don't show up in the Project Browser for me.
> Not that I had looked before this, I use Navigator for everything. ;-)
>
> On Sat, Aug 4, 2018 at 11:42 AM Mark Wieder via use-livecode <
> use-livecode@lists.runrev.com> wrote:
>
> > On 08/04/2018 11:23 AM, Mark Waddingham via use-livecode wrote:
> >
> > > However, over time I'd suggest we look at it sitting in a
> > > mobile-permissions script library. Given the dynamic nature of handler
> > > dispatch in LC, there's all kinds of things we can do to make it really
> > > easy to adapt for particular projects.
> >
> > Although I do have to bemoan the proliferation of script stacks in the
> > Project Browser list. This especially became onerous when the Navigator
> > plugin started using script-only stacks. It's a pain having to scroll
> > through all those stacks that I'm never going to edit, and it's a pain
> > having to remove the plugin each time a new build comes out so that I
> > don't have to scroll through them just to work on system stacks.
> >
> > --
> >   Mark Wieder
> >   ahsoftw...@gmail.com
> >
> > ___
> > use-livecode mailing list
> > use-livecode@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@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@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: valueDiff for arrays?

[Geoff Canyon via use-livecode]

On Sat, Aug 4, 2018 at 12:00 PM Brian Milby via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Plugins should probably be de-scriptified for distribution for this
> reason.
>

This would be very bad for Navigator. Navigator shows multiple copies of
itself (as many as you like/can tolerate) and this is only possible because
everything is based on behaviors. Before I made the switch, Navigator was
limited to three copies of itself, because making any more caused Bad
Things to happen. It's been so long I don't remember the details, and
obviously that was back in version 5 or earlier, so things might have
changed, but regardless of how many gigabytes of RAM we have, duplicating
Navigator's code over and over again is problematic.

In short, "I can't go back, man! I won't!" :-)
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: valueDiff for arrays?

[Geoff Canyon via use-livecode]

Are you working with "LiveCode UI elements appear in lists of stacks"
enabled? I specifically named all the script behaviors for Navigator
starting with "rev" and they don't show up in the Project Browser for me.
Not that I had looked before this, I use Navigator for everything. ;-)

On Sat, Aug 4, 2018 at 11:42 AM Mark Wieder via use-livecode <
use-livecode@lists.runrev.com> wrote:

> On 08/04/2018 11:23 AM, Mark Waddingham via use-livecode wrote:
>
> > However, over time I'd suggest we look at it sitting in a
> > mobile-permissions script library. Given the dynamic nature of handler
> > dispatch in LC, there's all kinds of things we can do to make it really
> > easy to adapt for particular projects.
>
> Although I do have to bemoan the proliferation of script stacks in the
> Project Browser list. This especially became onerous when the Navigator
> plugin started using script-only stacks. It's a pain having to scroll
> through all those stacks that I'm never going to edit, and it's a pain
> having to remove the plugin each time a new build comes out so that I
> don't have to scroll through them just to work on system stacks.
>
> --
>   Mark Wieder
>   ahsoftw...@gmail.com
>
> ___
> use-livecode mailing list
> use-livecode@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@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: valueDiff for arrays?

[Mark Wieder via use-livecode]

On 08/08/2018 04:16 PM, Mark Waddingham via use-livecode wrote:

OK. Bug filed.

https://quality.livecode.com/show_bug.cgi?id=21476

--
 Mark Wieder
 ahsoftw...@gmail.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: valueDiff for arrays?

[Mark Waddingham via use-livecode]

On 2018-08-08 23:19, Mark Wieder via use-livecode wrote:

On 08/08/2018 10:54 AM, Mark Waddingham via use-livecode wrote:

Yup - but isSequence would be correct - false.

The extents might be 1,10

But isSequence would check whether it was 1,9 ...


Ah. OK, but I was actually replying to Dick Kriesel's isSequence
function, which incorrectly would reply true. I'm not familiar with
any other isSequence function. Do you have a reference for that?


Haha - okay yes - I must confess I missed one very important line in 
your 'test' handler:


   put "false" into sArray[pi]

This actually means there is a bug in the engine 'extents()' function 
(the lower-level routines the engine uses to check for Sequences / 
NumericSequences are correct as they use an optimized form, as they 
don't require generation of the extents).


Specially, the extents function is parsing the array key (item list - 
extents can act on multi-dimensional arrays) as numbers, not as 
integers. Therefore it is erroneously returning a set of extents for an 
array which contains a non-integer key.


So - Dick's function is correct, it is the extents function which is 
currently incorrect.


Warmest Regards,

Mark.

--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: valueDiff for arrays?

[Mark Wieder via use-livecode]

On 08/08/2018 10:54 AM, Mark Waddingham via use-livecode wrote:

Yup - but isSequence would be correct - false.

The extents might be 1,10

But isSequence would check whether it was 1,9 ...


Ah. OK, but I was actually replying to Dick Kriesel's isSequence 
function, which incorrectly would reply true. I'm not familiar with any 
other isSequence function. Do you have a reference for that?


--
 Mark Wieder
 ahsoftw...@gmail.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: valueDiff for arrays?

[Mark Waddingham via use-livecode]

Yup - but isSequence would be correct - false.

The extents might be 1,10

But isSequence would check whether it was 1,9 ...

Mark.

Sent from my iPhone

> On 8 Aug 2018, at 12:19, Mark Wieder via use-livecode 
>  wrote:
> 
> On 08/08/2018 04:18 AM, Mark Waddingham via use-livecode wrote:
> 
>>> "the extents" implements those rules, so "isSequence but " doesn’t need to.
>>> 
>>> Or is there evidence "isSequence" fails?
> 
> on test
>   local i
> 
>   repeat with i=1 to 10
>  put "true" into sArray[i]
>   end repeat
>   put "false" into sArray[pi]
>   delete variable sArray[4]
>   put the extents of sArray && the number of elements of sArray & cr after msg
> end test
> 
> -- 
> Mark Wieder
> ahsoftw...@gmail.com
> 
> ___
> use-livecode mailing list
> use-livecode@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@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: valueDiff for arrays?

[Mark Wieder via use-livecode]

On 08/08/2018 04:18 AM, Mark Waddingham via use-livecode wrote:


"the extents" implements those rules, so "isSequence" doesn’t need to.

Or is there evidence "isSequence" fails?


on test
   local i

   repeat with i=1 to 10
  put "true" into sArray[i]
   end repeat
   put "false" into sArray[pi]
   delete variable sArray[4]
   put the extents of sArray && the number of elements of sArray & cr 
after msg

end test

--
 Mark Wieder
 ahsoftw...@gmail.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: valueDiff for arrays

[Mark Waddingham via use-livecode]

I'd suggest transplant is actually move - an idea which has been taken to the 
level of obsession in modern c++ and new languages like Rust (which I want to 
like - but it's highly technical demands just leave a bitter taste in my mouth 
- impressive, yes; the right approach - definitely not, IMHO anyway!).

For LCS 'move' would allow to elide a put and delete. However there are few 
cases I can think of (if any!) where it is required save for the fact it would 
make certain things potentially more performant in the absence of even a 
relatively simple data-flow based optimisation phase.

Also I'm not sure it could be implemented in the current LCS mechanism to 
actually give that performance so it would essentially be a bit of syntactic 
sugar for 'put' then 'delete'.

Perhaps reasonable from the point of view of clear expression of intent though!

Warmest Regards,

Mark.

Sent from my iPhone

> On 7 Aug 2018, at 17:35, Quentin Long via use-livecode 
>  wrote:
> 
> Suggestion for the language-token for this function: "transplant".
> 
> transplant [qualification] from [SourceArray] to [TargetArray]
> 
> [qualification] is a pattern/expression which describes exactly which bits 
> you want to move from SourceArray to TargetArray.
> 
> If TargetArray doesn't exist, it should be created to hold the stuff from 
> SourceArray.
> 
> It occurs to me that "transplant" might also be useful as a 
> string-manipulation function:
> 
> transplant [ChunkType]s where [qualification] from [SourceContainer] to 
> [TargetContainer]
> 
> Am thinking that the default behavior should be to have the transplanted bits 
> be added to the *end* of TargetContainer. Again, if TargetContainer doesn't 
> exist, it should be created. It might be useful to be able to specify exactly 
> where the transplanted bits get inserted, so maybe:
> 
> transplant [ChunkType]s where [qualification] from [SourceContainer] to 
> [Location] of [TargetContainer]
> 
> "Location" could be "start", or "end", at minimum, or possibly an expression 
> that evaluates to a location within TargetContainer.
> 
> Am unsure how much of a hassle it would be to implement this, so I shall 
> leave it in the capable hands of Mr. Waddingham & Co.
> 
> 
> 
> "Bewitched" + "Charlie's Angels" - Charlie = "At Arm's Length"
> Read the webcomic at [ http://www.atarmslength.net ]!
> If you like "At Arm's Length", support it at [ 
> http://www.patreon.com/DarkwingDude ].
> ___
> use-livecode mailing list
> use-livecode@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@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: valueDiff for arrays?

[Mark Waddingham via use-livecode]

I think you are right - I will double check.

There is actually an internal function (in C) - two in fact - IsSequence and 
IsNumericSequence which we should plumb into 'is a' to make this clearer.

They basically use the extents internal impl (well an optimized form in one 
case).

Warmest Regards,

Mark.

Sent from my iPhone

> On 8 Aug 2018, at 00:11, Dick Kriesel via use-livecode 
>  wrote:
> 
> 
>>> On Aug 7, 2018, at 9:29 PM, Jerry Jensen via use-livecode 
>>>  wrote:
>>> 
>>> On Aug 7, 2018, at 8:35 PM, Mark Wieder via use-livecode 
>>>  wrote:
>>> 
>>> On 08/07/2018 07:57 PM, Dick Kriesel via use-livecode wrote:
> On Aug 7, 2018, at 5:47 PM, Alex Tweedly via use-livecode 
>  wrote:
> 
> Is there an easy way to test whether an array is (currently) a sequence 
> array ?
> 
> something easier than
> put the extents of tArray into tmp
> if item 1 of tmp = 1 AND item 2 of tmp = the number of elements in tArray 
> then
 slightly easier, at least:
 function isSequence p
 return the extents of p is 1, number of elements in p
 end isSequence
>>> 
>>> If I'm understanding things right there's more to it:
>>> The keys all have to be integers and (I think) only those integers from 1 
>>> to (the number of keys).
>> 
>> That was my understanding as well.
>> .Jerry
> 
> "the extents" implements those rules, so "isSequence" doesn’t need to.
> 
> Or is there evidence "isSequence" fails?
> 
> — Dick
> ___
> use-livecode mailing list
> use-livecode@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@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: valueDiff for arrays

[Monte Goulding via use-livecode]

> On 8 Aug 2018, at 7:52 pm, Monte Goulding via use-livecode 
>  wrote:
> 
> map lines of tList as sum(item 2 to -1 of each)  \
>grouping by item 1 of each \
>where item 1 of each begins with “b” into tArray
> 
> Would create the array:
> 
> “bar” -> 10, “baz” -> 24

Typo ^ sorry that’s meant to be “bar” -> 15
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: valueDiff for arrays

[Monte Goulding via use-livecode]

So the difference between transplant and filter is that transplant mutates both 
source and target by taking from source and adding to target while filter 
copies from source to target? Oh and that transplant would mutate an existing 
target rather than clobbering any existing value.

Hate the name but interesting idea. Personally I’ve been thinking about 
something like map reduce:

map  of  [as ] [grouping by 
] [where ] into 

So if you had a list:

foo,1,2,3
bar,4,5,6
baz,7,8,9

map lines of tList as sum(item 2 to -1 of each)  \
grouping by item 1 of each \
where item 1 of each begins with “b” into tArray

Would create the array:

“bar” -> 10, “baz” -> 24

> On 8 Aug 2018, at 8:35 am, Quentin Long via use-livecode 
>  wrote:
> 
> Suggestion for the language-token for this function: "transplant".
> 
> transplant [qualification] from [SourceArray] to [TargetArray]
> 
> [qualification] is a pattern/expression which describes exactly which bits 
> you want to move from SourceArray to TargetArray.
> 
> If TargetArray doesn't exist, it should be created to hold the stuff from 
> SourceArray.
> 
> It occurs to me that "transplant" might also be useful as a 
> string-manipulation function:
> 
> transplant [ChunkType]s where [qualification] from [SourceContainer] to 
> [TargetContainer]
> 
> Am thinking that the default behavior should be to have the transplanted bits 
> be added to the *end* of TargetContainer. Again, if TargetContainer doesn't 
> exist, it should be created. It might be useful to be able to specify exactly 
> where the transplanted bits get inserted, so maybe:
> 
> transplant [ChunkType]s where [qualification] from [SourceContainer] to 
> [Location] of [TargetContainer]
> 
> "Location" could be "start", or "end", at minimum, or possibly an expression 
> that evaluates to a location within TargetContainer.
> 
> Am unsure how much of a hassle it would be to implement this, so I shall 
> leave it in the capable hands of Mr. Waddingham & Co.
> 
> 
> 
> "Bewitched" + "Charlie's Angels" - Charlie = "At Arm's Length"
> Read the webcomic at [ http://www.atarmslength.net ]!
> If you like "At Arm's Length", support it at [ 
> http://www.patreon.com/DarkwingDude ].
> ___
> use-livecode mailing list
> use-livecode@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@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: valueDiff for arrays?

[Dick Kriesel via use-livecode]

> On Aug 7, 2018, at 9:29 PM, Jerry Jensen via use-livecode 
>  wrote:
> 
>> On Aug 7, 2018, at 8:35 PM, Mark Wieder via use-livecode 
>>  wrote:
>> 
>> On 08/07/2018 07:57 PM, Dick Kriesel via use-livecode wrote:
>>> On Aug 7, 2018, at 5:47 PM, Alex Tweedly via use-livecode 
>>>  wrote:
 
 Is there an easy way to test whether an array is (currently) a sequence 
 array ?
 
 something easier than
 put the extents of tArray into tmp
 if item 1 of tmp = 1 AND item 2 of tmp = the number of elements in tArray 
 then
>>> slightly easier, at least:
>>> function isSequence p
>>> return the extents of p is 1, number of elements in p
>>> end isSequence
>> 
>> If I'm understanding things right there's more to it:
>> The keys all have to be integers and (I think) only those integers from 1 to 
>> (the number of keys).
> 
> That was my understanding as well.
> .Jerry

"the extents" implements those rules, so "isSequence" doesn’t need to.

Or is there evidence "isSequence" fails?

— Dick
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: valueDiff for arrays?

[Jerry Jensen via use-livecode]

> On Aug 7, 2018, at 8:35 PM, Mark Wieder via use-livecode 
>  wrote:
> 
> On 08/07/2018 07:57 PM, Dick Kriesel via use-livecode wrote:
>> On Aug 7, 2018, at 5:47 PM, Alex Tweedly via use-livecode 
>>  wrote:
>>> 
>>> Is there an easy way to test whether an array is (currently) a sequence 
>>> array ?
>>> 
>>> something easier than
>>> put the extents of tArray into tmp
>>> if item 1 of tmp = 1 AND item 2 of tmp = the number of elements in 
>>> tArray then
>> slightly easier, at least:
>> function isSequence p
>> return the extents of p is 1, number of elements in p
>> end isSequence
> 
> If I'm understanding things right there's more to it:
> The keys all have to be integers and (I think) only those integers from 1 to 
> (the number of keys).

That was my understanding as well.
.Jerry



___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: valueDiff for arrays?

[Mark Wieder via use-livecode]

On 08/07/2018 07:57 PM, Dick Kriesel via use-livecode wrote:

On Aug 7, 2018, at 5:47 PM, Alex Tweedly via use-livecode 
 wrote:


Is there an easy way to test whether an array is (currently) a sequence array ?

something easier than
 put the extents of tArray into tmp
 if item 1 of tmp = 1 AND item 2 of tmp = the number of elements in tArray 
then


slightly easier, at least:
function isSequence p

 return the extents of p is 1, number of elements in p

end isSequence


If I'm understanding things right there's more to it:
The keys all have to be integers and (I think) only those integers from 
1 to (the number of keys).


--
 Mark Wieder
 ahsoftw...@gmail.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: valueDiff for arrays?

[Dick Kriesel via use-livecode]

On Aug 7, 2018, at 5:47 PM, Alex Tweedly via use-livecode 
 wrote:
> 
> Is there an easy way to test whether an array is (currently) a sequence array 
> ?
> 
> something easier than
> put the extents of tArray into tmp
> if item 1 of tmp = 1 AND item 2 of tmp = the number of elements in tArray 
> then

slightly easier, at least:
function isSequence p

return the extents of p is 1, number of elements in p

end isSequence

— Dick
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: valueDiff for arrays?

[Alex Tweedly via use-livecode]

On 07/08/2018 23:45, Mark Waddingham via use-livecode wrote:

On 2018-08-07 23:31, Mark Wieder via use-livecode wrote:

does that take it out of the 'special' category?


Yes - unless the array's first key is 1, and it then has all integer 
keys up to and including its number of elements  then it is not 
considered a sequence array.
Is there an easy way to test whether an array is (currently) a sequence 
array ?


something easier than
    put the extents of tArray into tmp
    if item 1 of tmp = 1 AND item 2 of tmp = the number of elements in 
tArray then

   -- sequence !?
    else
   -- arbitrary array
 end if

- Alex.



___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: valueDiff for arrays?

[Mark Waddingham via use-livecode]

On 2018-08-08 00:20, Bob Sneidar via use-livecode wrote:

I do stand corrected however, as I got the dgdata of a grid with 6
records, in the order they were added to the sql database, and then
queried for. The keys are NOT in numerical order:

5
6
1
2
3
4


The keys function does the minimal work necessary to return its result.

An array in LiveCode is a sequence of slots, each one which can hold a 
value (pre-7 they used to be chained hash-tables - but 7+ they changed 
to linear hash-tables).


The hash of the key is used to determine which slot its value goes in - 
if that slot is full it goes in the next available one.


The keys function iterates through the sequence of slots from 1 up to 
the capacity of the array (which is not the same as the number of 
elements - there's always head-room in the slot array), accumulating the 
keys which are present as it goes - any empty slots are skipped.


Therefore the ordering of the keys is determined by the numerical order 
of the hash of the keys themselves which holds scant relationship to the 
content of the keys - beyond that determined by the hash function - i.e. 
the hash function is designed to distribute keys arbitrarily, but 
uniformly across the sequence of slots.


Warmest Regards,

Mark.

--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: valueDiff for arrays?

[Mark Waddingham via use-livecode]

On 2018-08-07 23:31, Mark Wieder via use-livecode wrote:

On 08/07/2018 02:21 PM, Mark Waddingham via use-livecode wrote:
However, the engine treats arrays which have all integer (string) keys 
starting at one and are dense (i.e. the number of elements == max(all 
keys)) from ones that aren't.


There should have been a 'differently' in there.


Not sure how to interpret that. If I create

repeat with i=1 to 10
  put i into tArray[i]
end repeat

to make a 'special' array and then
delete variable tArray[3]

does that take it out of the 'special' category?


Yes - unless the array's first key is 1, and it then has all integer 
keys up to and including its number of elements  then it is not 
considered a sequence array.


i.e. [1], [3], [5] - not a sequence
 [2], [3], [4] - not a sequence
 [1], [2], [3] - a sequence

The specialness is quite restricted - however such arrays:

  1) are ordered when used with 'repeat for each element' *not* repeat 
for each key:


   repeat for each element tElement in tSeqArray
 ... tElement will first be [1], then [2], ... then [n] ...
   end repeat

  2) can be used as a sequence of keys to traverse in [] - e.g.

  put tArray[tSeqArray] == tArray[tSeqArray[1]]...[tSeqArray[2]]

  3) admit a more efficient representation in arrayEncode - they are 
encoded as 'sequences', so the engine does not emit the keys - instead 
it just emits a sequence of values [1], [2], ..., [n]... Which saves 
some space.


Warmest Regards,

Mark.

--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: valueDiff for arrays

[Quentin Long via use-livecode]

Suggestion for the language-token for this function: "transplant".

transplant [qualification] from [SourceArray] to [TargetArray]

[qualification] is a pattern/expression which describes exactly which bits you 
want to move from SourceArray to TargetArray.

If TargetArray doesn't exist, it should be created to hold the stuff from 
SourceArray.

It occurs to me that "transplant" might also be useful as a string-manipulation 
function:

transplant [ChunkType]s where [qualification] from [SourceContainer] to 
[TargetContainer]

Am thinking that the default behavior should be to have the transplanted bits 
be added to the *end* of TargetContainer. Again, if TargetContainer doesn't 
exist, it should be created. It might be useful to be able to specify exactly 
where the transplanted bits get inserted, so maybe:

transplant [ChunkType]s where [qualification] from [SourceContainer] to 
[Location] of [TargetContainer]

"Location" could be "start", or "end", at minimum, or possibly an expression 
that evaluates to a location within TargetContainer.

Am unsure how much of a hassle it would be to implement this, so I shall leave 
it in the capable hands of Mr. Waddingham & Co.



"Bewitched" + "Charlie's Angels" - Charlie = "At Arm's Length"
Read the webcomic at [ http://www.atarmslength.net ]!
If you like "At Arm's Length", support it at [ 
http://www.patreon.com/DarkwingDude ].
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: valueDiff for arrays?

[Richard Gaskin via use-livecode]

Bob Sneidar wrote:

> You can as I understand get the keys of an array, which returns a
> string, then sort the string. I am unaware of any function that can
> sort an array natively before it is returned.

The array itself is a collection of pointers, grouped into buckets 
according to a hash designed for efficient even distribution.


Unlike a string, there is no single bytestream to sort.  There is no 
there there.


That's also why they can't be transfered to disk or over a network 
unless they're serialized first with arrayEncode.


Queries for the *keys* of an array do return as a string, which is sortable.

Associative arrays are tricky but fascinating things.  I spent some time 
with the Wikipedia page on them to get my head at least a bit wrapped 
around their internal structure and operations:


https://en.wikipedia.org/wiki/Associative_array

--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: valueDiff for arrays?

[Bob Sneidar via use-livecode]

I do stand corrected however, as I got the dgdata of a grid with 6 records, in 
the order they were added to the sql database, and then queried for. The keys 
are NOT in numerical order:

5
6
1
2
3
4

I have never wrapped my head around why that is! 

Bob S


> On Aug 7, 2018, at 15:12 , Bob Sneidar via use-livecode 
>  wrote:
> 
> You can as I understand get the keys of an array, which returns a string, 
> then sort the string. I am unaware of any function that can sort an array 
> natively before it is returned. 
> 
> Bob S
> 
> 
>> On Aug 7, 2018, at 15:02 , Richard Gaskin via use-livecode 
>>  wrote:
>> 
>> Bob Sneidar wrote:
>> 
>>> Someone said, probably Mark, that numbered key arrays beginning with 1
>>> will always return their keys sorted numerically. I always wondered
>>> why almost every other array seemed to scramble to order of it's keys,
>>> but datagrid arrays never did.
>> 
>> Associative arrays are a collection of hashes, and as such have no internal 
>> sense of order.
>> 
>> The DataGrid script runs output through the sort command before returning it.
>> 
>> -- 
>> Richard Gaskin
>> Fourth World Systems
>> Software Design and Development for the Desktop, Mobile, and the Web
> 


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: valueDiff for arrays?

[Bob Sneidar via use-livecode]

You can as I understand get the keys of an array, which returns a string, then 
sort the string. I am unaware of any function that can sort an array natively 
before it is returned. 

Bob S


> On Aug 7, 2018, at 15:02 , Richard Gaskin via use-livecode 
>  wrote:
> 
> Bob Sneidar wrote:
> 
> > Someone said, probably Mark, that numbered key arrays beginning with 1
> > will always return their keys sorted numerically. I always wondered
> > why almost every other array seemed to scramble to order of it's keys,
> > but datagrid arrays never did.
> 
> Associative arrays are a collection of hashes, and as such have no internal 
> sense of order.
> 
> The DataGrid script runs output through the sort command before returning it.
> 
> -- 
> Richard Gaskin
> Fourth World Systems
> Software Design and Development for the Desktop, Mobile, and the Web


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: valueDiff for arrays?

[Richard Gaskin via use-livecode]

Bob Sneidar wrote:

> Someone said, probably Mark, that numbered key arrays beginning with 1
> will always return their keys sorted numerically. I always wondered
> why almost every other array seemed to scramble to order of it's keys,
> but datagrid arrays never did.

Associative arrays are a collection of hashes, and as such have no 
internal sense of order.


The DataGrid script runs output through the sort command before 
returning it.


--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: valueDiff for arrays?

[Bob Sneidar via use-livecode]

Someone said, probably Mark, that numbered key arrays beginning with 1 will 
always return their keys sorted numerically. I always wondered why almost every 
other array seemed to scramble to order of it's keys, but datagrid arrays never 
did. 

Bob S


> On Aug 7, 2018, at 14:31 , Mark Wieder via use-livecode 
>  wrote:
> 
> On 08/07/2018 02:21 PM, Mark Waddingham via use-livecode wrote:
>> However, the engine treats arrays which have all integer (string) keys 
>> starting at one and are dense (i.e. the number of elements == max(all keys)) 
>> from ones that aren't.
> 
> Not sure how to interpret that. If I create
> 
> repeat with i=1 to 10
>  put i into tArray[i]
> end repeat
> 
> to make a 'special' array and then
> delete variable tArray[3]
> 
> does that take it out of the 'special' category?
> 
> -- 
> Mark Wieder
> ahsoftw...@gmail.com


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: valueDiff for arrays?

[Mark Wieder via use-livecode]

On 08/07/2018 02:21 PM, Mark Waddingham via use-livecode wrote:
However, the engine treats arrays which have all integer (string) keys 
starting at one and are dense (i.e. the number of elements == max(all 
keys)) from ones that aren't.


Not sure how to interpret that. If I create

repeat with i=1 to 10
  put i into tArray[i]
end repeat

to make a 'special' array and then
delete variable tArray[3]

does that take it out of the 'special' category?

--
 Mark Wieder
 ahsoftw...@gmail.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: valueDiff for arrays?

[Mark Waddingham via use-livecode]

On 2018-08-07 17:15, Mark Wieder via use-livecode wrote:

On 08/06/2018 08:18 PM, Mark Waddingham via use-livecode wrote:

I'd expect that for two reasons.

The first is that all array keys are interred strings (names) so 
integers need to first be converted to strings and then hashed into a 
name and then hashed to the slot in the arrays hash table.


I thought at some point we had talked about numeric arrarys (as
opposed to hashes) if all the keys were numbers. That's why I filled
the array that way. Is that not the case? Can we put that one to bed?


All arrays are string-keyed currently.

However, the engine treats arrays which have all integer (string) keys 
starting at one and are dense (i.e. the number of elements == max(all 
keys)) from ones that aren't.


The fact the keys are still strings is an implementation detail really - 
although one which does leave room for optimization (see the reply I 
wrote about PHP7 - particularly the notion of tagged ptrs for integers).


Warmest Regards,

Mark.

--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: valueDiff for arrays?

[Mark Wieder via use-livecode]

On 08/06/2018 08:58 PM, Brian Milby via use-livecode wrote:


I've uploaded a stack with each version of the function.  The last has some
comments added as well.  Mark's version is pretty close to the original,
but did not return an ordered list (which is an implicit requirement).  I
added a sort so the times are comparable.


Heh. I had a sort command in there and must have refactored it out of 
existence when I cleaned up the code.


--
 Mark Wieder
 ahsoftw...@gmail.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: valueDiff for arrays?

[Mark Wieder via use-livecode]

On 08/06/2018 08:18 PM, Mark Waddingham via use-livecode wrote:

I'd expect that for two reasons.

The first is that all array keys are interred strings (names) so integers need 
to first be converted to strings and then hashed into a name and then hashed to 
the slot in the arrays hash table.


I thought at some point we had talked about numeric arrarys (as opposed 
to hashes) if all the keys were numbers. That's why I filled the array 
that way. Is that not the case? Can we put that one to bed?


--
 Mark Wieder
 ahsoftw...@gmail.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: valueDiff for arrays?

[Brian Milby via use-livecode]

button "Array (original)"
Found 664579 primes in 51.543966 seconds
button "Array (bwm)"
Found 664579 primes in 49.139622 seconds
button "Array (mark)"
Found 664579 primes in 43.483821 seconds
button "Byte (alex)"
Found 664579 primes in 15.016109 seconds
button "Byte (bwm)"
Found 664579 primes in 11.357213 seconds
button "Byte (bernd)"
Found 664579 primes in 7.874756 seconds

I've uploaded a stack with each version of the function.  The last has some
comments added as well.  Mark's version is pretty close to the original,
but did not return an ordered list (which is an implicit requirement).  I
added a sort so the times are comparable.

https://milby.us/lc/Primes.livecode

To Mark's point about C... the person that originally devised the test was
using it to baseline and compare several scripting languages relative to
optimized C++ code.  For LCS, we had to do a bit of work to overcome the
way arrays are stored internally (hash map).  Yes, LCS is still much slower
in this test than everything else listed.  I didn't try any on my seat, so
the times are not really directly comparable, but Python/Perl both did one
run in about 2.5s on average.

This kind of makes me want to translate this into LCB to do a comparison.
There we do have a real list type that could be used and compared against
the other methods employed here.

Thanks,
Brian
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: valueDiff for arrays?

[Mark Waddingham via use-livecode]

I'd expect that for two reasons.

The first is that all array keys are interred strings (names) so integers need 
to first be converted to strings and then hashed into a name and then hashed to 
the slot in the arrays hash table.

The second is that byte based version is essentially using a byte sequence as a 
bit set - each setting of a byte in the set is about as close as you get to a 
truly atomic (in the sense of using '1' instruction) as you can get in LC.

It is what you would do in C if you couldn't be bothered using bit operations 
to manipulate individual bits in machine words (which would be substantially 
faster again - as you would be touching 1/8th of the memory).

Warmest Regards,

Mark.

Sent from my iPhone

> On 6 Aug 2018, at 20:24, Mark Wieder via use-livecode 
>  wrote:
> 
> Interesting. I tried a variation using arrays, and it's three times slower 
> than yours.
> 
> function get_primes pN
>   local tMroot, tPrimes, tIsItPrime
> 
>   if pN < 2 then return empty
>   if pN = 2 then return 2
>   put trunc(sqrt(pN)) - 1 into tMroot
> 
>   repeat with i=1 to pN step 2
>  put 1 into tIsItPrime[i]
>   end repeat
> 
>   repeat with i = 3 to tMroot step 2
>  if tIsItPrime[i] is empty then next repeat
>  repeat with j = i^2 to pN step i
> delete variable tIsItPrime[j]
>  end repeat
>   end repeat
> 
>   return the keys of tIsItPrime
> end get_primes
> 
> -- 
> Mark Wieder
> ahsoftw...@gmail.com
> 
> ___
> use-livecode mailing list
> use-livecode@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@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: valueDiff for arrays?

[Mark Wieder via use-livecode]

Interesting. I tried a variation using arrays, and it's three times 
slower than yours.


function get_primes pN
   local tMroot, tPrimes, tIsItPrime

   if pN < 2 then return empty
   if pN = 2 then return 2
   put trunc(sqrt(pN)) - 1 into tMroot

   repeat with i=1 to pN step 2
  put 1 into tIsItPrime[i]
   end repeat

   repeat with i = 3 to tMroot step 2
  if tIsItPrime[i] is empty then next repeat
  repeat with j = i^2 to pN step i
 delete variable tIsItPrime[j]
  end repeat
   end repeat

   return the keys of tIsItPrime
end get_primes

--
 Mark Wieder
 ahsoftw...@gmail.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: valueDiff for arrays?

[Niggemann, Bernd via use-livecode]

How embarrassing, again an error. I should go to sleep now.

 repeat pn mod 1
  put tYes after tIsItPrime <-- corrected line
   end repeat

Here is the hopfully truly truly last correction.

---
function get_primes pN -- bn modified brian
   local tMroot, tPrimes, tIsItPrime, tYes, tNo
   put numtobyte(66) into tYes
   put numtobyte(65) into tNo
   if pN < 2 then return empty
   if pN = 2 then return 2
   put 2 into tPrimes
   put trunc(sqrt(pN)) - 1 into tMroot
   
   if pN >= 1 then
  local tTenThousand
  repeat 1
 put tYes after tTenThousand
  end repeat
  
  repeat pn div 1
 put tTenthousand after tIsItPrime
  end repeat
   end if
   
   repeat pn mod 1
  put tYes after tIsItPrime
   end repeat
   
   repeat with i = 3 to tMroot step 2
  if byte i of tIsItPrime is tNo then next repeat
  put cr & i after tPrimes
  repeat with j = i^2 to pN step i
 put tNo into byte j of tIsItPrime
  end repeat
   end repeat
   repeat with i = tMroot + (tMroot + 1) mod 2 to pN - 1 step 2
  if byte i of tIsItPrime is tYes then put cr & i after tPrimes
   end repeat
   return tPrimes
end get_primes
--

at least it saves a couple of seconds

Kind regards
Bernd

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: valueDiff for arrays?

[Alex Tweedly via use-livecode]

Nice improvement !

And I like the variable names much more ... though it could be argued 
that "tYes", should be called"tMayYetBeAPrime" :-)


I now get this version consistently running in 25% of the original time.

There is another version which runs about twice as fast - i.e. 14% of 
the original - but I'm not sure it is quite within the spirit of this 
comparison.


This should be a comparison of the performance of "the same" algorithm 
in a variety of scripting languages. It seems wrong to speed up our LC 
implementation by tweaking the algorithm.


If our purpose was simply to improve the speed of finding primes, that 
would be different.


So for anyone who wants to find primes faster - here revised code that 
does so, though I doubt if it tells us anything about the relative 
performance of LC.


The "pure" version of the Sieve would have crossed all multiples of 
every prime, but the original code only needs to cross-off those 
multiples of 3 and above - i.e the 'pure' inner loop would be


repeat with i = 2 to tMroot
rather than
repeat with i = 3 to tMroot step 2

The original code is an improvement over the 'pure' version by taking 
advantage of the knowledge that all even numbers (>2) cannot be 
prime.You can do (part of) that optimization for all primes up to 
(small) 'm' rather than just for '2'.  Pre-calculate the pattern for 
1...M (where big M is the product of all primes <= small m), and then 
initialize the sieve table with that pattern repeated as often as 
needed. Then you can go through the sieve crossing-off only for primes > 
'm'. This code uses m=5 (i.e. M=2*3*5=30).




function get_primes pN
   local tMroot, tPrimes, tIsItPrime, tYes, tNo
   put numtobyte(66) into tYes
   put numtobyte(65) into tNo
   if pN < 2 then return empty
   if pN = 2 then return 2
   repeat with i = 1 to 30
  put tNo into byte i of tIsItPrime
   end repeat
   repeat for each item L in "1,7,11,13,17,19,23,29"
  put tYes into byte L of tIsItPrime
   end repeat
   local t30
   put byte 1 to 30 of tIsItPrime into t30
   put t30 into tIsItPrime
   repeat pN div 30 times
  put t30 after tIsItPrime
   end repeat

   put 2  & 3 & CR & 5  into tPrimes
   put trunc(sqrt(pN)) - 1 into tMroot
   repeat with i = 7 to tMroot step 2
  if byte i of tIsItPrime is tNo then next repeat
  put cr & i after tPrimes
  repeat with j = i^2 to pN step i
 put tNo into byte j of tIsItPrime
  end repeat
   end repeat
   repeat with i = tMroot + (tMroot + 1) mod 2 to pN - 1 step 2
  if byte i of tIsItPrime is tYes then put cr & i after tPrimes
   end repeat
   return tPrimes
end get_primes

and that runs in just over half the time.

Alex.


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: valueDiff for arrays?

[Niggemann, Bernd via use-livecode]

There was an error in the code I posted.
It should read "if pN >= 1 then" instead of "if pN > 1"

this is the corrected version
-
function get_primes pN
   local tMroot, tPrimes, tIsItPrime, tYes, tNo
   put numtobyte(66) into tYes
   put numtobyte(65) into tNo
   if pN < 2 then return empty
   if pN = 2 then return 2
   put 2 into tPrimes
   put trunc(sqrt(pN)) - 1 into tMroot
   
   if pN >= 1 then
  local tTenThousand
  repeat 1
 put tYes after tTenThousand
  end repeat
  
  repeat pn div 1
 put tTenthousand after tIsItPrime
  end repeat
   end if
   
   repeat pn mod 1
  put tTenthousand after tIsItPrime
   end repeat
   
   repeat with i = 3 to tMroot step 2
  if byte i of tIsItPrime is tNo then next repeat
  put cr & i after tPrimes
  repeat with j = i^2 to pN step i
 put tNo into byte j of tIsItPrime
  end repeat
   end repeat
   repeat with i = tMroot + (tMroot + 1) mod 2 to pN - 1 step 2
  if byte i of tIsItPrime is tYes then put cr & i after tPrimes
   end repeat
   return tPrimes
end get_primes
---

Kind regards
Bernd

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: valueDiff for arrays?

[Brian Milby via use-livecode]

2 should be included, but the original optimized version skipped it.

Thanks,
Brian
On Aug 6, 2018, 6:25 PM -0500, Niggemann, Bernd via use-livecode 
, wrote:
> This also helps a bit. Where is Hermann?
>
> -
> function get_primes pN
> local tMroot, tPrimes, tIsItPrime, tYes, tNo
> put numtobyte(66) into tYes
> put numtobyte(65) into tNo
> if pN < 2 then return empty
> if pN = 2 then return 2
> put 2 into tPrimes
> put trunc(sqrt(pN)) - 1 into tMroot
>
> if pN > 1 then
> local tTenThousand
> repeat 1
> put tYes after tTenThousand
> end repeat
>
> repeat pn div 1
> put tTenthousand after tIsItPrime
> end repeat
> end if
>
> repeat pn mod 1
> put tTenthousand after tIsItPrime
> end repeat
>
> repeat with i = 3 to tMroot step 2
> if byte i of tIsItPrime is tNo then next repeat
> put cr & i after tPrimes
> repeat with j = i^2 to pN step i
> put tNo into byte j of tIsItPrime
> end repeat
> end repeat
> repeat with i = tMroot + (tMroot + 1) mod 2 to pN - 1 step 2
> if byte i of tIsItPrime is tYes then put cr & i after tPrimes
> end repeat
> return tPrimes
> end get_primes
> 
>
> This is a modified Brian´s version built upon Alex's version
>
> Note that Brian seems to find one additional prime.
>
> Kind regards
> Bernd
>
> ___
> use-livecode mailing list
> use-livecode@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@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: valueDiff for arrays?

[Niggemann, Bernd via use-livecode]

This also helps a bit. Where is Hermann?

-
function get_primes pN
   local tMroot, tPrimes, tIsItPrime, tYes, tNo
   put numtobyte(66) into tYes
   put numtobyte(65) into tNo
   if pN < 2 then return empty
   if pN = 2 then return 2
   put 2 into tPrimes
   put trunc(sqrt(pN)) - 1 into tMroot
   
   if pN > 1 then
  local tTenThousand
  repeat 1
 put tYes after tTenThousand
  end repeat
  
  repeat pn div 1
 put tTenthousand after tIsItPrime
  end repeat
   end if
   
   repeat pn mod 1
  put tTenthousand after tIsItPrime
   end repeat
   
   repeat with i = 3 to tMroot step 2
  if byte i of tIsItPrime is tNo then next repeat
  put cr & i after tPrimes
  repeat with j = i^2 to pN step i
 put tNo into byte j of tIsItPrime
  end repeat
   end repeat
   repeat with i = tMroot + (tMroot + 1) mod 2 to pN - 1 step 2
  if byte i of tIsItPrime is tYes then put cr & i after tPrimes
   end repeat
   return tPrimes
end get_primes


This is a modified Brian´s version built upon Alex's version

Note that Brian seems to find one additional prime.

Kind regards
Bernd

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: valueDiff for arrays?

[Brian Milby via use-livecode]

Ah, that is what I was missing (numtobyte)... I knew that 4000 seconds
wasn't right :)
I was able to shave a bit more off by only calling numtobyte twice (17s to
12s for single pass):

function get_primes pN
   local tMroot, tPrimes, tIsItPrime, tYes, tNo
   put numtobyte(66) into tYes
   put numtobyte(65) into tNo
   if pN < 2 then return empty
   if pN = 2 then return 2
   put 2 into tPrimes
   put trunc(sqrt(pN)) - 1 into tMroot
   repeat with i = 1 to pN
  put tYes into byte i of tIsItPrime
   end repeat
   repeat with i = 3 to tMroot step 2
  if byte i of tIsItPrime is tNo then next repeat
  put cr & i after tPrimes
  repeat with j = i^2 to pN step i
 put tNo into byte j of tIsItPrime
  end repeat
   end repeat
   repeat with i = tMroot + (tMroot + 1) mod 2 to pN - 1 step 2
  if byte i of tIsItPrime is tYes then put cr & i after tPrimes
   end repeat
   return tPrimes
end get_primes

I also changed the variable names a bit :)

On Mon, Aug 6, 2018 at 3:25 PM, Mark Waddingham via use-livecode <
use-livecode@lists.runrev.com> wrote:

> On 2018-08-06 22:04, Alex Tweedly via use-livecode wrote:
>
>> On 06/08/2018 16:50, Mark Waddingham via use-livecode wrote:
>>
>> Alex Tweedly didn't talk nonsense... Byte x [to y] of z is (truly)
>>> constant time if z is strictly a binary string.
>>>
>> That's right - the basic principle wasn't nonsense - but most
>> everything else in my email was :-)
>>
>
> Well I spoke a bit of nonsense in the above - only byte x of z is constant
> time (if z is strictly a binary string) - byte x to y of z - is O(n) where
> n = y - x.
>
> Of course the reality is that it should be possibly for it to be constant
> for both - chunk ranges of things should be able to be created in constant
> time as they can reference the thing they are chunking... However, the
> reason we have yet to do that is that ownership of the values need to be
> 'understood' (as in modelled in the engine at runtime) to ensure small
> chunks of much larger strings don't cause the much larger strings to stay
> hanging around when they are no longer referenced.
>
> e.g. You have a 20Mb text file which you chunk and extract only 1Kb worth
> of small strings from. You don't want the 20Mb remaining in memory when its
> not needed anymore. A naive implementation of substrings would cause that
> to happen and cause the size of the heap to blow up in size with nothing
> you (as the programmer) could do about it.
>
> I said you only needed to change two lines - in fact you need to make
>> changes in 4 places.
>> I said the saving was ~ 40%, in fact it's ~75-80%
>>
>
> I don't think anyone is going to complain where 'nonsense' is actually a
> misstatement by a factor of 2 (in the better way!) over a performance
> improvement :)
>
> First wrong thing - you can't just casually write into  "byte X of
>> tmp". if X is greater than the current length of tmp, then this simply
>> appends a single byte. So you need to pre-fill the variable that holds
>> the bytes.
>>
>
> Yes - it's the same for all 'put into ' expressions I believe. I
> can't really say whether the alternative (i.e. padding) would be more
> 'correct' or not (well, not without a good deal of pondering!) - certainly
> useful though, in this particular case.
>
> Regardless of correctness - pre-filling the binary string has a memory
> allocation advantage as well. It can be quite expensive (O(n) in fact -
> where n is the existing length) to extend a string (binary or otherwise)
> beyond its current length. So if you pre-fill the length you want, no
> memory allocation has to happen during use of it.
>
> Second wrong thing was
>>   put "a" into byte X of np
>> that should be
>>   put numtobyte(66) into byte X of np
>>
>> I don't thin this *should* make much difference - but in fact it makes
>> a huge difference. Not sure why - I suspect a bug  I'll look at it
>> some more and hopefully submit a bug report later.
>>
>
> The issue there is that you are mixing text with binary. I think the
> engine assumes (currently) in that case that you mean the target to be
> text... Although I *think* we fixed that case recently in a patch to appear
> in either 9.0.1 or 9.1.0 (maybe Ali can comment on that). If you explicitly
> say 'byte' in the target then it should end up being binary that you get.
>
> Warmest Regards,
>
> Mark.
>
> --
> Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
> LiveCode: Everyone can create apps
>
> ___
> use-livecode mailing list
> use-livecode@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@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: valueDiff for arrays?

[Mark Waddingham via use-livecode]

On 2018-08-06 22:04, Alex Tweedly via use-livecode wrote:

On 06/08/2018 16:50, Mark Waddingham via use-livecode wrote:

Alex Tweedly didn't talk nonsense... Byte x [to y] of z is (truly) 
constant time if z is strictly a binary string.

That's right - the basic principle wasn't nonsense - but most
everything else in my email was :-)


Well I spoke a bit of nonsense in the above - only byte x of z is 
constant time (if z is strictly a binary string) - byte x to y of z - is 
O(n) where n = y - x.


Of course the reality is that it should be possibly for it to be 
constant for both - chunk ranges of things should be able to be created 
in constant time as they can reference the thing they are chunking... 
However, the reason we have yet to do that is that ownership of the 
values need to be 'understood' (as in modelled in the engine at runtime) 
to ensure small chunks of much larger strings don't cause the much 
larger strings to stay hanging around when they are no longer 
referenced.


e.g. You have a 20Mb text file which you chunk and extract only 1Kb 
worth of small strings from. You don't want the 20Mb remaining in memory 
when its not needed anymore. A naive implementation of substrings would 
cause that to happen and cause the size of the heap to blow up in size 
with nothing you (as the programmer) could do about it.



I said you only needed to change two lines - in fact you need to make
changes in 4 places.
I said the saving was ~ 40%, in fact it's ~75-80%


I don't think anyone is going to complain where 'nonsense' is actually a 
misstatement by a factor of 2 (in the better way!) over a performance 
improvement :)



First wrong thing - you can't just casually write into  "byte X of
tmp". if X is greater than the current length of tmp, then this simply
appends a single byte. So you need to pre-fill the variable that holds
the bytes.


Yes - it's the same for all 'put into ' expressions I believe. I 
can't really say whether the alternative (i.e. padding) would be more 
'correct' or not (well, not without a good deal of pondering!) - 
certainly useful though, in this particular case.


Regardless of correctness - pre-filling the binary string has a memory 
allocation advantage as well. It can be quite expensive (O(n) in fact - 
where n is the existing length) to extend a string (binary or otherwise) 
beyond its current length. So if you pre-fill the length you want, no 
memory allocation has to happen during use of it.



Second wrong thing was
  put "a" into byte X of np
that should be
  put numtobyte(66) into byte X of np

I don't thin this *should* make much difference - but in fact it makes
a huge difference. Not sure why - I suspect a bug  I'll look at it
some more and hopefully submit a bug report later.


The issue there is that you are mixing text with binary. I think the 
engine assumes (currently) in that case that you mean the target to be 
text... Although I *think* we fixed that case recently in a patch to 
appear in either 9.0.1 or 9.1.0 (maybe Ali can comment on that). If you 
explicitly say 'byte' in the target then it should end up being binary 
that you get.


Warmest Regards,

Mark.

--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: valueDiff for arrays?

[Alex Tweedly via use-livecode]

On 06/08/2018 16:50, Mark Waddingham via use-livecode wrote:


Alex Tweedly didn't talk nonsense... Byte x [to y] of z is (truly) constant 
time if z is strictly a binary string.
That's right - the basic principle wasn't nonsense - but most everything 
else in my email was :-)


I said you only needed to change two lines - in fact you need to make 
changes in 4 places.

I said the saving was ~ 40%, in fact it's ~75-80%

First wrong thing - you can't just casually write into  "byte X of tmp". 
if X is greater than the current length of tmp, then this simply appends 
a single byte. So you need to pre-fill the variable that holds the bytes.


Second wrong thing was
  put "a" into byte X of np
that should be
  put numtobyte(66) into byte X of np

I don't thin this *should* make much difference - but in fact it makes a 
huge difference. Not sure why - I suspect a bug  I'll look at it 
some more and hopefully submit a bug report later.


Third wrong thing -  I wasn't properly calculating latter set of primes.

Fourth wrong thing - I was running the wrong test stack :-)

Fifth additional minor tweak - there's no need for the array 'p'; all it 
was used for was extracting the keys, sorting them and using that to 
start the textual list of results. Better to just put the confirmed 
primes into the textual list.


So - fixing all those gives code that runs about 75-80% faster. See 
revised code below.


Now off to try a different, perhaps crazy, idea :-)

Code - sorry about the formatting ...


on mouseUp

local T

put the long seconds into T

repeat with c = 1 to 2

get get_primes(1000)

end repeat

put "button Found" && the number of lines in it && "primes in" && the 
long seconds - T && "seconds"  after fld "F"


end mouseUp

function get_primes n

local mroot, np, R

repeat with i = 1 to n

put numtobyte(66) into byte i of np

end repeat

if n < 2 then return empty

if n = 2 then return 2

put trunc(sqrt(n)) - 1 into mroot

repeat with i = 3 to mroot step 2

if byte i of np = "a" then next repeat

-- put TRUE into p[i]

put i  after R

repeat with j = i*i to n step i

put numtobyte(65) into byte j of np

end repeat

end repeat

-- put 2 & cr & the keys of p into R

-- sort lines of R numeric

repeat with i = mroot + (mroot + 1) mod 2 to n - 1 step 2

if byte i of np = numtobyte(66) then put i & CR after R

end repeat

return R

end get_primes


-- Alex.

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: valueDiff for arrays?

[Mark Wieder via use-livecode]

On 08/05/2018 08:26 PM, Monte Goulding via use-livecode wrote:


They are constants.. the point is in order to compare a boolean to a string you 
need to convert it to a string and therefore you do string comparison on “” v 
“false”.


Doh! Yes, I forgot again about this converting everything to strings as 
the LCD.


--
 Mark Wieder
 ahsoftw...@gmail.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: valueDiff for arrays?

[Mark Waddingham via use-livecode]

Alex Tweedly didn't talk nonsense... Byte x [to y] of z is (truly) constant 
time if z is strictly a binary string.

tArray[x] is constant time if x is already a name - otherwise the string needs 
turned into a name.

If x is coming from repeat for each key x - then it will already be a name.

(Not sure if that helps!)

Mark.

Sent from my iPhone

> On 6 Aug 2018, at 05:17, Alex Tweedly via use-livecode 
>  wrote:
> 
> Earlier, Alex Tweedly said some nonsense like:
> 
>> arrays are hashed - even if quickly, while byte chunks are constant time.
>> 
>> So replace both uses of the array np with a byte chunk.
>> ...
>> 
>> Takes about 40% off the time.
>> 
>> -- Alex.
> Operator error !
> Forget what I said, it was wrong.
> 
> I'll do the test more carefully and send a report later (whether it speeds 
> the test up or not).
> 
> Alex
> 
> 
> 
> ___
> use-livecode mailing list
> use-livecode@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@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: valueDiff for arrays?

[Alex Tweedly via use-livecode]

Earlier, Alex Tweedly said some nonsense like:


arrays are hashed - even if quickly, while byte chunks are constant time.

So replace both uses of the array np with a byte chunk.
...

Takes about 40% off the time.

-- Alex.

Operator error !
Forget what I said, it was wrong.

I'll do the test more carefully and send a report later (whether it 
speeds the test up or not).


Alex



___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: valueDiff for arrays?

[Alex Tweedly via use-livecode]

arrays are hashed - even if quickly, while byte chunks are constant time.

So replace both uses of the array np with a byte chunk.

i.e.

if byte i of np = "n" then next repeat

...

put "n" into byte j of np

Takes about 40% off the time.

-- Alex.



On 06/08/2018 03:36, Richard Gaskin via use-livecode wrote:

Mark Waddingham wrote:

> Richard wrote:
>>
>> Thinking about performance, I wonder if there's anything from some of
>> the changes that have boosted PHP 7's performance so far above its
>> earlier versions which may be relevant for LC:
>> 
https://www.reddit.com/r/PHP/comments/3q2brz/how_is_php_7_twice_as_fast/

>
> I'd actually be really interested in a direct speed comparison between
> exactly equivalent operations in PHP7 and LC.

Geoff Canyon and I corresponded on this back in March.  I don't think 
he'll mind me sharing some of the relevant parts of his test:


---  from GC 

on mouseUp
   put the long seconds into T
   repeat with c = 1 to 10
  get get_primes(1000)
   end repeat
   put "Found" && the number of lines in it && "primes in" && the long 
seconds - T && "seconds"

end mouseUp

function get_primes n
   if n < 2 then return empty
   if n = 2 then return 2
   put trunc(sqrt(n)) - 1 into mroot
   repeat with i = 3 to mroot step 2
  if np[i] > 0 then next repeat
  add 1 to p[i]
  repeat with j = i^2 to n step i
 add 1 to np[j]
  end repeat
   end repeat
   put 2 & cr & the keys of p into R
   sort lines of R numeric
   repeat with i = mroot + (mroot + 1) mod 2 to n - 1 step 2
  if np[i] is empty then put cr & i after R
   end repeat
   return R
end get_primes

And that takes about fifteen minutes to run on my 2013 MacBook Pro, 
where the slowest performer he's working with takes less than 30 
seconds, and PHP 7 runs in under 7 seconds. Any ideas where I'm 
deviating in my implementation compared to his? Here's the latest 
version of his test that I found:


https://blog.famzah.net/2016/09/10/cpp-vs-python-vs-php-vs-java-vs-others-performance-benchmark-2016-q3/ 



-




___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: valueDiff for arrays?

[Monte Goulding via use-livecode]

> On 6 Aug 2018, at 1:57 pm, Brian Milby via use-livecode 
>  wrote:
> 
> Just tried that and it adds .7 sec (returning the unsorted keys).  The sort
> in the original takes around .7s.  There are only 446 primes found at that
> point.  Returning an array is about the same time as returning an unsorted
> R.

Hmm… could be the overhead of hashing the array keys. Would be interesting to 
see the results of just incrementing a counter rather than listing the primes.

Cheers

Monte
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: valueDiff for arrays?

[Brian Milby via use-livecode]

Just tried that and it adds .7 sec (returning the unsorted keys).  The sort
in the original takes around .7s.  There are only 446 primes found at that
point.  Returning an array is about the same time as returning an unsorted
R.

On Sun, Aug 5, 2018 at 10:28 PM, Monte Goulding via use-livecode <
use-livecode@lists.runrev.com> wrote:

> I’m fairly sure you could speed it up by continuing to add keys to p and
> returning that instead of building the list R.
>
> > On 6 Aug 2018, at 1:24 pm, Brian Milby via use-livecode <
> use-livecode@lists.runrev.com> wrote:
> >
> > I can speed it up by 10% just be replacing the "add 1 to" with "put true
> > into".  The first if would lose the ">0".  A single pass went from 50s to
> > 44s on my iMac.
>
> ___
> use-livecode mailing list
> use-livecode@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@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: valueDiff for arrays?

[Monte Goulding via use-livecode]

I’m fairly sure you could speed it up by continuing to add keys to p and 
returning that instead of building the list R.

> On 6 Aug 2018, at 1:24 pm, Brian Milby via use-livecode 
>  wrote:
> 
> I can speed it up by 10% just be replacing the "add 1 to" with "put true
> into".  The first if would lose the ">0".  A single pass went from 50s to
> 44s on my iMac.

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: valueDiff for arrays?

[Monte Goulding via use-livecode]

> On 6 Aug 2018, at 1:15 pm, Mark Wieder via use-livecode 
>  wrote:
> 
> Interesting. And here I was just assuming that true and false were boolean 
> constants, like in any other language. So empty is a constant and one is a 
> constant, but true and false are not. Wouldn't things be faster if we made 
> them constants?

They are constants.. the point is in order to compare a boolean to a string you 
need to convert it to a string and therefore you do string comparison on “” v 
“false”.

Cheers

Monte
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: valueDiff for arrays?

[Brian Milby via use-livecode]

I can speed it up by 10% just be replacing the "add 1 to" with "put true
into".  The first if would lose the ">0".  A single pass went from 50s to
44s on my iMac.

On Sun, Aug 5, 2018 at 9:36 PM, Richard Gaskin via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Mark Waddingham wrote:
>
> > Richard wrote:
> >>
> >> Thinking about performance, I wonder if there's anything from some of
> >> the changes that have boosted PHP 7's performance so far above its
> >> earlier versions which may be relevant for LC:
> >> https://www.reddit.com/r/PHP/comments/3q2brz/how_is_php_7_tw
> ice_as_fast/
> >
> > I'd actually be really interested in a direct speed comparison between
> > exactly equivalent operations in PHP7 and LC.
>
> Geoff Canyon and I corresponded on this back in March.  I don't think
> he'll mind me sharing some of the relevant parts of his test:
>
> ---  from GC 
>
> on mouseUp
>put the long seconds into T
>repeat with c = 1 to 10
>   get get_primes(1000)
>end repeat
>put "Found" && the number of lines in it && "primes in" && the long
> seconds - T && "seconds"
> end mouseUp
>
> function get_primes n
>if n < 2 then return empty
>if n = 2 then return 2
>put trunc(sqrt(n)) - 1 into mroot
>repeat with i = 3 to mroot step 2
>   if np[i] > 0 then next repeat
>   add 1 to p[i]
>   repeat with j = i^2 to n step i
>  add 1 to np[j]
>   end repeat
>end repeat
>put 2 & cr & the keys of p into R
>sort lines of R numeric
>repeat with i = mroot + (mroot + 1) mod 2 to n - 1 step 2
>   if np[i] is empty then put cr & i after R
>end repeat
>return R
> end get_primes
>
> And that takes about fifteen minutes to run on my 2013 MacBook Pro, where
> the slowest performer he's working with takes less than 30 seconds, and PHP
> 7 runs in under 7 seconds. Any ideas where I'm deviating in my
> implementation compared to his? Here's the latest version of his test that
> I found:
>
> https://blog.famzah.net/2016/09/10/cpp-vs-python-vs-php-vs-j
> ava-vs-others-performance-benchmark-2016-q3/
>
> -
>
> --
>  Richard Gaskin
>  Fourth World Systems
>  Software Design and Development for the Desktop, Mobile, and the Web
>  
>  ambassa...@fourthworld.comhttp://www.FourthWorld.com
>
> ___
> use-livecode mailing list
> use-livecode@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@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: valueDiff for arrays?

[Mark Wieder via use-livecode]

On 08/05/2018 05:42 PM, Monte Goulding via use-livecode wrote:


I was describing a situation where you are forcing something that is not a boolean 
to be one so true is true and everything else is false. You are describing comparing 
something to a boolean in which case rightly or wrongly both sides are converted to 
strings so you end up comparing “” to “false"


Interesting. And here I was just assuming that true and false were 
boolean constants, like in any other language. So empty is a constant 
and one is a constant, but true and false are not. Wouldn't things be 
faster if we made them constants?


--
 Mark Wieder
 ahsoftw...@gmail.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: valueDiff for arrays?

[Brian Milby via use-livecode]

I posted a stack with the valueDiff code tests that I was doing if anyone
is interrested:
https://milby.us/lc/ValueDiff.livecode.zip
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: valueDiff for arrays?

[Richard Gaskin via use-livecode]

Mark Waddingham wrote:

> On 2018-08-05 21:22, Richard Gaskin via use-livecode wrote:
>> Mark Waddingham wrote:
>>
>>> In your use-case for 'valueDiff' - do you need to tell the
>>> difference between a key value being the empty string and
>>> a key value not being present at all?
>>
>> In my own head, any name-value pair, even one in which the value
>> is an empty string, is worth taking into account.
>
> In the general case it depends on what data you are modelling with an
> array.
>
> If an array key-value is modelling a field which is not optional, then
> there is no need to distinguish between an array key being there, and
> one not being there - i.e. all field accesses can be tRecord[tKey],
> and your key value can be empty.
>
> If a field's value has to be non-empty to be valid, then you can test
> for existence of a field by doing tRecord[tKey] is not empty. So,
> again, presence or not presence of an array key is immaterial.

Consider an array of object properties. There, a label or name property 
can be empty, and it's useful to know that.


In most of my own work, if a key is present it's meaningful, even if its 
value is empty.


If a key is not meaningful it probably isn't in an array I'm using.

--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: valueDiff for arrays?

[Richard Gaskin via use-livecode]

Mark Waddingham wrote:

> Richard wrote:
>>
>> Thinking about performance, I wonder if there's anything from some of
>> the changes that have boosted PHP 7's performance so far above its
>> earlier versions which may be relevant for LC:
>> https://www.reddit.com/r/PHP/comments/3q2brz/how_is_php_7_twice_as_fast/
>
> I'd actually be really interested in a direct speed comparison between
> exactly equivalent operations in PHP7 and LC.

Geoff Canyon and I corresponded on this back in March.  I don't think 
he'll mind me sharing some of the relevant parts of his test:


---  from GC 

on mouseUp
   put the long seconds into T
   repeat with c = 1 to 10
  get get_primes(1000)
   end repeat
   put "Found" && the number of lines in it && "primes in" && the long 
seconds - T && "seconds"

end mouseUp

function get_primes n
   if n < 2 then return empty
   if n = 2 then return 2
   put trunc(sqrt(n)) - 1 into mroot
   repeat with i = 3 to mroot step 2
  if np[i] > 0 then next repeat
  add 1 to p[i]
  repeat with j = i^2 to n step i
 add 1 to np[j]
  end repeat
   end repeat
   put 2 & cr & the keys of p into R
   sort lines of R numeric
   repeat with i = mroot + (mroot + 1) mod 2 to n - 1 step 2
  if np[i] is empty then put cr & i after R
   end repeat
   return R
end get_primes

And that takes about fifteen minutes to run on my 2013 MacBook Pro, 
where the slowest performer he's working with takes less than 30 
seconds, and PHP 7 runs in under 7 seconds. Any ideas where I'm 
deviating in my implementation compared to his? Here's the latest 
version of his test that I found:


https://blog.famzah.net/2016/09/10/cpp-vs-python-vs-php-vs-java-vs-others-performance-benchmark-2016-q3/

-

--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: valueDiff for arrays?

[Monte Goulding via use-livecode]

> On 6 Aug 2018, at 9:55 am, Mark Wieder via use-livecode 
>  wrote:
> 
> on something p1, p2, p3
>  if p1 is false then
>-- fails if p1 is empty
>  end if
>  if p1 is true then
>-- also fails if p1 is empty
>  end if
> end something

I was describing a situation where you are forcing something that is not a 
boolean to be one so true is true and everything else is false. You are 
describing comparing something to a boolean in which case rightly or wrongly 
both sides are converted to strings so you end up comparing “” to “false"

Cheers

Monte
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: valueDiff for arrays?

[Mark Wieder via use-livecode]

On 08/05/2018 04:37 PM, Monte Goulding via use-livecode wrote:


Actually you need to be careful to remember not to put not before a boolean 
expression without putting parenthesis around the expression because anything 
that is not “true” in LC evaluates to false. For example:


That's generally the case, but it falls apart for empty function arguments.

on something p1, p2, p3
  if p1 is false then
-- fails if p1 is empty
  end if
  if p1 is true then
-- also fails if p1 is empty
  end if
end something

--
 Mark Wieder
 ahsoftw...@gmail.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: valueDiff for arrays?

[Monte Goulding via use-livecode]

> On 6 Aug 2018, at 8:03 am, Mark Wieder via use-livecode 
>  wrote:
> 
> True, but syntacticly I like the idea of being able to place "not" in front 
> of any boolean without having to remember where it's legal and where it's 
> not. I also think it's harder on the engine (this off the top of my head 
> without looking at the code ) to specify where "not" is legal.

Actually you need to be careful to remember not to put not before a boolean 
expression without putting parenthesis around the expression because anything 
that is not “true” in LC evaluates to false. For example:


not “foo” is “bar” -> (not “foo”) is “bar” -> (not “false”) is “bar” -> “true" 
is “bar” -> “false”

not (“foo” is “bar”) -> not “false” -> “true"

Cheers

Monte
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: valueDiff for arrays?

[Brian Milby via use-livecode]

Earlier in this thread it was mentioned that LCS doing a loop once would
probably outpace the engine looping 2 times + a LCS loop at some point.  I
decided to see if I could figure out a point where this might take place.
My test was pretty simple.  I set a target number of elements for each
array.  1/3 have the same key and value, 1/3 have the same key but
different values, 1/3 are non-matching keys.  Somewhere just over 50,000
keys the quickest version switches.  Here's the code:

function bwmValueDiffPut pLeft, pRight
   local tResult, tLeft, tRight
   repeat for each key tKey in pLeft
  if tKey is among the keys of pRight and \
pLeft[tKey] is not pRight[tKey] then
 put pLeft[tKey] into tLeft[tKey]
 put pRight[tKey] into tRight[tKey]
  end if
   end repeat
   put tLeft into tResult["1"]
   put tRight into tResult["2"]
   return tResult
end bwmValueDiffPut

As anything, the real data set would impact the results significantly.  For
example, the above code does the "among" test for every key.  It does the
"is not" test for 2/3 of the keys.  It does the pair of put statements for
1/3 of the keys.  As that mix changed, the results would too - changing the
point at which this method would be the fastest.  But to put it into
perspective, the 50,000 key test took around 75ms for both methods.
100,000 keys came in around 150ms on my machine.

I will also note that the dual loop delete method for LCS always lost and
by a significant margin (deleted from left first, deleted from right
second).  The combination delete/put loop was slightly slower than the
above code (deleted from left, created new right as above).  Also, Mark's
version was faster than my revision.  I'm thinking that was due to the way
I was going into a second level array (tResult["2"][tKey] vice
tRight[tKey]).
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: valueDiff for arrays?

[Mark Waddingham via use-livecode]

On 2018-08-06 00:07, Brian Milby via use-livecode wrote:

So this syntax:
filter filterSource by [keeping | discarding] [[the] {lines | items | 
keys

| elements}] {matching [wildcard | regex] pattern filterPattern | where
filterExpression} [into targetContainer]

Would allow a shortened version:
filter X by matching pattern "regex" into Z
Which would expand to:
filter X by keeping the lines matching regex pattern "regex" into Z


TOP:

Yes - I realized earlier on that the shortened versions do no harm, and 
in all honesty I don't think the negated forms do either.


At the end of the day they all map through a well-defined (admittedly, 
hypothetical) mechanical process to a set of unambiguous preferred forms 
- so there is no problem with meaning.


Indeed, a lot of how we code is down to personal taste. I run a team of 
programmers, and so we have to have rules internally which everyone 
follows - just like if you try and run a team where everyone speaks an 
entirely different natural language, you are going to have significant 
problems in communication; teams of programmers communicate in code a 
lot, so its important that everyone largely 'speaks' the same language 
(well 'dialect' is probably a more accurate term here).


So I'll certainly be suggesting that should the new variant form appear 
that a review criteria of LCS code will be (internally) negated forms 
are banned - just swap keeping <-> discarding; and the style rules for 
the open-source project will mandate the same.


Similarly - shortened versions would be too under the same auspices. 
This isn't anything to do with being dictatorial or just a control-freak 
- its about ensuring consistency of communication. Every line of code 
which we write that goes into the product needs to endure for a long 
time and be read by many people - so its best that its made as uniform 
as possible at the start.


What people outside those spheres wish to do is entirely up to them - 
although I'd urge people to generally use the preferred forms in all 
cases in your own code, its not like I can come and beat you all around 
the head if you don't.


(Of course, I *can* just not allow them to be included... GOTO TOP).

Warmest Regards,

Mark.

--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: valueDiff for arrays?

[Mark Waddingham via use-livecode]

On 2018-08-06 00:03, Mark Wieder via use-livecode wrote:

On 08/05/2018 02:48 PM, Monte Goulding via use-livecode wrote:



On 6 Aug 2018, at 7:07 am, Mark Waddingham via use-livecode 
 wrote:


filter X by keeping the lines not matching pattern "regex"


My point was this statement can be written as both:

filter X by keeping the lines not matching pattern “regex"

and

filter X by discarding the lines matching pattern "regex"

So it would perhaps be a good idea to only allow `matching` rather 
than `not matching`


True, but syntacticly I like the idea of being able to place "not" in
front of any boolean without having to remember where it's legal and
where it's not. I also think it's harder on the engine (this off the
top of my head without looking at the code ) to specify where "not"
is legal.


In this case the forms would be hardcoded:

  'not matching pattern "regex"'

is actually (essentially) sugar for:

  'where not each matches "regex"'

So *if* we could implement it like that then it would potentially do no 
harm - *however* as it stands it would be implemented as hard-coded 
parsing / exec code - so its actually more work to support 'not' here, 
and not less.


However, there is certainly a consistency argument to be had - its 
whether consistency is always better than a slight amount of positive 
coercion - in terms of restricting some forms of syntax which actually 
reduce readability rather than increase it (which, I think, on balance 
'not' here might well do - as in reduce - and since this whole 
discussion came about because *I* have a significant problem parsing the 
'filter' command as it stands - readability is perhaps the main concern 
here).


Warmest Regards,

Mark.

--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: valueDiff for arrays?

[J. Landman Gay via use-livecode]

On 8/5/18 4:07 PM, Mark Waddingham via use-livecode wrote:
But this isn't cooking - this is coding, so in this case you need to 
read the docs to find out what the default mode of filter is. (Of 
course, this might entirely be one of those things that my brain just 
won't get, or ever get - so it might very well just be me!).


If you and I were alone together in a room, yeah, it would just be you. 
;) Filtering "with" is always like draining potatoes to me.


However, that might be because the only form of "filter" originally was 
to keep the solids. It was some years before the "without" form was 
added, and by then I'd had a lot of time to know what to expect.



Sure we can make the extra bits optional


Cool. Backward compatibility and all that.

--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: valueDiff for arrays?

[Brian Milby via use-livecode]

So this syntax:
filter filterSource by [keeping | discarding] [[the] {lines | items | keys
| elements}] {matching [wildcard | regex] pattern filterPattern | where
filterExpression} [into targetContainer]

Would allow a shortened version:
filter X by matching pattern "regex" into Z
Which would expand to:
filter X by keeping the lines matching regex pattern "regex" into Z


On Sun, Aug 5, 2018 at 4:48 PM, Monte Goulding via use-livecode <
use-livecode@lists.runrev.com> wrote:

>
>
> > On 6 Aug 2018, at 7:07 am, Mark Waddingham via use-livecode <
> use-livecode@lists.runrev.com> wrote:
> >
> > filter X by keeping the lines not matching pattern "regex"
>
> My point was this statement can be written as both:
>
> filter X by keeping the lines not matching pattern “regex"
>
> and
>
> filter X by discarding the lines matching pattern "regex"
>
> So it would perhaps be a good idea to only allow `matching` rather than
> `not matching`
>
> > Anyway - extending the current form with 'where' (rather than 'with
> expression') is more than adequate at the moment.
>
> Hehe.. the `with expression` thing was me trying to come up with something
> that worked with `with | without | matching | not matching`… `where` is
> much better I agree.
>
> Cheers
>
> Monte
> ___
> use-livecode mailing list
> use-livecode@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@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: valueDiff for arrays?

[Mark Wieder via use-livecode]

On 08/05/2018 02:48 PM, Monte Goulding via use-livecode wrote:




On 6 Aug 2018, at 7:07 am, Mark Waddingham via use-livecode 
 wrote:

filter X by keeping the lines not matching pattern "regex"


My point was this statement can be written as both:

filter X by keeping the lines not matching pattern “regex"

and

filter X by discarding the lines matching pattern "regex"

So it would perhaps be a good idea to only allow `matching` rather than `not 
matching`


True, but syntacticly I like the idea of being able to place "not" in 
front of any boolean without having to remember where it's legal and 
where it's not. I also think it's harder on the engine (this off the top 
of my head without looking at the code ) to specify where "not" is legal.


--
 Mark Wieder
 ahsoftw...@gmail.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: valueDiff for arrays?

[Mark Waddingham via use-livecode]

On 2018-08-05 23:48, Monte Goulding via use-livecode wrote:
On 6 Aug 2018, at 7:07 am, Mark Waddingham via use-livecode 
 wrote:


filter X by keeping the lines not matching pattern "regex"


My point was this statement can be written as both:

filter X by keeping the lines not matching pattern “regex"

and

filter X by discarding the lines matching pattern "regex"

So it would perhaps be a good idea to only allow `matching` rather
than `not matching`


To be fair - we could get rid of the inverted forms entirely. If you 
want inclusion, use keep, if you want exclusion use discard. i.e.


  filter X by keeping the lines with "..."
  filter X by keeping the lines matching "..."
  filter X by keeping the lines where "..."

  filter X by discarding the lines with ".."
  filter X by discarding the lines matching ".."
  filter X by discarding the lines where ".."

This would probably work much more nicely actually (now I get what you 
were saying!) - it means you don't have the 'double-negative' problem 
(which I think is what you were referring to) - and 'where' gives you a 
general 'get out' especially if we implement the 'matches' operator:


  filter X by discarding the lines where each does not match "..."

So no expressivity is lost - but you retain the absolute clarity of 
having keep/discard.


At the end of the day - why would you choose to use an extra token for a 
negated form, when you can just change keeping to discarding - or vice 
versa?



Hehe.. the `with expression` thing was me trying to come up with
something that worked with `with | without | matching | not matching`…
`where` is much better I agree.


Hehe - yeah - I think we've discussed it before (probably several times 
over a long interval) so that at least require's no bike-shedding... 
After all, in this case, if its good enough for SQL, I can't see why it 
isn't good enough for us (it also happens to be entirely correct from an 
English language point of view - which kinda helps, in an English-like 
language).


Warmest Regards,

Mark.

--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: valueDiff for arrays?

[Monte Goulding via use-livecode]

> On 6 Aug 2018, at 7:07 am, Mark Waddingham via use-livecode 
>  wrote:
> 
> filter X by keeping the lines not matching pattern "regex"

My point was this statement can be written as both:

filter X by keeping the lines not matching pattern “regex"

and

filter X by discarding the lines matching pattern "regex"

So it would perhaps be a good idea to only allow `matching` rather than `not 
matching`

> Anyway - extending the current form with 'where' (rather than 'with 
> expression') is more than adequate at the moment.

Hehe.. the `with expression` thing was me trying to come up with something that 
worked with `with | without | matching | not matching`… `where` is much better 
I agree.

Cheers

Monte
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: valueDiff for arrays?

[Mark Waddingham via use-livecode]

On 2018-08-05 22:37, Monte Goulding via use-livecode wrote:

I think it’s nice sugar but it adds complexity when trying to
understand the statement. You need to comprehend the expression or
pattern then comprehend the relationship between discarding/keeping
and with | without | not matching | where in order to figure out what
will actually happen. I would rather [by { keeping | discarding }] be
a parser error if used with without and not matching.


I'm not sure I follow - I think you took the above out of context - I 
was using an elided form of the operations to indicate the mapping from 
existence / non-existence of keywords to the underlying operation...


The form is actually:

  filter X by keeping the lines where P
  filter X by discarding the lines matching "glob"
  filter X by keeping the lines not matching pattern "regex"

* Yes I've inserted 'the' there - because it then makes the query 
expressions the same as Mark Wieder's suggestion. Also I might not have 
matching quite right - it might be a bit more verbose than that.


I'm not too fussed about whether the new form has with or without - they 
are the 'arcane' words in this situation which caused me the problem in 
the first place.


By arcane here I mean you actually have to read the docs to understand 
what they are referring to:


  filter X with "foobar"

Isn't exactly clear at first sight - "foobar" is a string - with 
 ? What does that mean? (You have to forget that you know *what* 
that command actually means to actually get my point - the reason I can 
do that easily is that I never remember correctly and always have to 
either try both or look it up).


I think the key point is that - out of context - which is generally the 
first phase of reading code:


  filter lines of X matching Y
  filter lines of X not matching Y

Makes no reference to what the 'default' mode of filter is - i.e. 
whether it keeps the solids, or keeps the liquids as Jacque put it. 
Given any recipe (to use the culinary metaphor) which in either case is 
entirely defined by *what* you are cooking (after all - how many recipes 
keep the fluid you get after draining potatoes, rather than the 
potatoes?)... But this isn't cooking - this is coding, so in this case 
you need to read the docs to find out what the default mode of filter 
is. (Of course, this might entirely be one of those things that my brain 
just won't get, or ever get - so it might very well just be me!).


If we insert an explicit keep / discard then it makes it crystal clear 
and unambiguous regardless of context.


Sure we can make the extra bits optional - so you can type less if you 
want - that's personal taste, and how much you want to torture yourself 
later, and others, when they read the code!


Anyway - extending the current form with 'where' (rather than 'with 
expression') is more than adequate at the moment.


The proposal above needs more work anyway - so it isn't an immediate 
thing in any case.


Warmest Regards,

Mark.

--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: valueDiff for arrays?

[Monte Goulding via use-livecode]

> On 6 Aug 2018, at 12:38 am, Mark Waddingham via use-livecode 
>  wrote:
> 
>  keeping where P -> P
>  keeping with P -> each matches wildcard P
>  keeping without P -> not (each matches wildcard P)
>  keeping matching P -> each matches pattern P
>  keeping not matching P -> not (each matches wildcard P)
> 
>  discarding where P -> not P
>  discarding with P -> not (each matches wildcard P)
>  discarding without P -> each matches wildcard P
>  discarding matching P -> not (each matches pattern P)
>  discarding not matching P -> each matches wildcard P
> 
> So the actual underling operation is the same: P is a boolean predicate 
> operating on 'each', where each is taken to be each 'chunk' of X in turn; if 
> P(each) returns true, the element is kept, otherwise it is discarded.
> 
> I quite like the above - it has a very simple underbelly (a single 
> operation!), but the actual English-like syntax is a true and correct 
> sentence.
> 
> What do people think?

I think it’s nice sugar but it adds complexity when trying to understand the 
statement. You need to comprehend the expression or pattern then comprehend the 
relationship between discarding/keeping and with | without | not matching | 
where in order to figure out what will actually happen. I would rather [by { 
keeping | discarding }] be a parser error if used with without and not matching.

Cheers

Monte
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: valueDiff for arrays?

[Monte Goulding via use-livecode]

> On 5 Aug 2018, at 10:32 pm, Mark Waddingham via use-livecode 
>  wrote:
> 
> Geez @Monte - you do like creating work for me don't you! ;)

Aha.. sorry but I have been threatening to implement this for 2 years ;-)

Cheers

Monte
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: valueDiff for arrays?

[Brian Milby via use-livecode]

Intersect is an engine implementation of something that can be done in pure 
LCS. I wrote a version of the function you needed that only used LCS without 
the engine optimized functions. My function only iterates over an array once 
(instead of 3 times) yet takes twice as long. It deletes keys from left as it 
iterates and also builds the desired right at the same time.

To Mark’s point, I did try a pure LCS approach with 2 loops which only used 
delete. That was slightly slower than my initial approach.

I was just attempting to show how much the engine functions outperformed what 
could be done in pure LCS. Also I wanted to quantify the delta. I guess I 
should really compare the pure intersect and union functions too.

If anyone is interested I can put a copy of the stack online with all of the 
variations that I timed.

Thanks,
Brian
On Aug 5, 2018, 2:26 PM -0500, Richard Gaskin via use-livecode 
, wrote:
> Brian Milby wrote:
>
> > I think Mark's code had a typo (left returned too many keys), but even
> > when corrected it takes half the time as a pure LCS solution. Here's
> > my modification:
> >
> > function bwmValueDiff pLeft, pRight
> > local tResult
> > intersect pLeft with pRight into tResult["1"]
> > repeat for each key tKey in tResult["1"]
> > if pLeft[tKey] is pRight[tKey] then
> > delete variable tResult["1"][tKey]
> > end if
> > end repeat
> > intersect pRight with tResult["1"] into tResult["2"]
> > return tResult
> > end bwmValueDiff
>
> That looks like LCS. What is the "pure LCS solution" you were comparing
> it to?
>
> --
> Richard Gaskin
> Fourth World Systems
> Software Design and Development for the Desktop, Mobile, and the Web
> 
> ambassa...@fourthworld.com http://www.FourthWorld.com
>
> ___
> use-livecode mailing list
> use-livecode@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@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: valueDiff for arrays?

[Mark Waddingham via use-livecode]

On 2018-08-05 21:25, Richard Gaskin via use-livecode wrote:

Brian Milby wrote:


I think Mark's code had a typo (left returned too many keys), but even
when corrected it takes half the time as a pure LCS solution.  Here's
my modification:

function bwmValueDiff pLeft, pRight
   local tResult
   intersect pLeft with pRight into tResult["1"]
   repeat for each key tKey in tResult["1"]
  if pLeft[tKey] is pRight[tKey] then
 delete variable tResult["1"][tKey]
  end if
   end repeat
   intersect pRight with tResult["1"] into tResult["2"]
   return tResult
end bwmValueDiff


That looks like LCS.  What is the "pure LCS solution" you were 
comparing it to?


I think Brian means where it does not use intersect - i.e. all loops are 
in LCS.


FWIW - I'm pretty sure this operation can be done using only two loops 
(one over left, and one over right).


Also, I'm pretty sure that a 'pure' LCS solution of that as suggested 
above would actually be faster than the minimum 3 loops needed if you 
use engine array ops - above a certain array size.


However, I haven't had a chance to code it yet.

Warmest Regards,

Mark.

--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: valueDiff for arrays?

[Mark Waddingham via use-livecode]

On 2018-08-05 21:22, Richard Gaskin via use-livecode wrote:

Mark Waddingham wrote:


In your use-case for 'valueDiff' - do you need to tell the difference
between a key value being the empty string and a key value not being
present at all?


In my own head, any name-value pair, even one in which the value is an
empty string, is worth taking into account.


In the general case it depends on what data you are modelling with an 
array.


If an array key-value is modelling a field which is not optional, then 
there is no need to distinguish between an array key being there, and 
one not being there - i.e. all field accesses can be tRecord[tKey], and 
your key value can be empty.


If a field's value has to be non-empty to be valid, then you can test 
for existence of a field by doing tRecord[tKey] is not empty. So, again, 
presence or not presence of an array key is immaterial.


The only case where you need to treat no key-value as different from 
empty key-value is where a valid value for an optional field can be the 
empty string. In which case that field access needs to be structured as:


  if tKey is among the keys of tRecord then
-- yay the key is there
  else
-- oh, there is no key
  end if

This is because LC doesn't see the difference between the empty string 
and absence of a value - but you can model that with an array key-value 
which is optional.


Warmest Regards,

Mark.

--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: valueDiff for arrays?

[Richard Gaskin via use-livecode]

Brian Milby wrote:

> I think Mark's code had a typo (left returned too many keys), but even
> when corrected it takes half the time as a pure LCS solution.  Here's
> my modification:
>
> function bwmValueDiff pLeft, pRight
>local tResult
>intersect pLeft with pRight into tResult["1"]
>repeat for each key tKey in tResult["1"]
>   if pLeft[tKey] is pRight[tKey] then
>  delete variable tResult["1"][tKey]
>   end if
>end repeat
>intersect pRight with tResult["1"] into tResult["2"]
>return tResult
> end bwmValueDiff

That looks like LCS.  What is the "pure LCS solution" you were comparing 
it to?


--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: valueDiff for arrays?

[Richard Gaskin via use-livecode]

Mark Waddingham wrote:

> In your use-case for 'valueDiff' - do you need to tell the difference
> between a key value being the empty string and a key value not being
> present at all?

In my own head, any name-value pair, even one in which the value is an 
empty string, is worth taking into account.


--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: valueDiff for arrays?

[Mark Waddingham via use-livecode]

It's just a case of refactoring but some further thought is required even about 
the current filter improvement.

By creating a revised form of filter, for example, we have the option of making 
'matches' take an RE and not a glob (shell wildcard expr). Yes REs are more 
complicated but much more generally useful.

This would then lead to a 'matches operator' and a 'matches wildcard' operator.

The code for this is in the filter command already - and the query expression 
impl would use the same code so it would be as fast as filter currently is.

Warmest Regards,

Mark.

Sent from my iPhone

> On 5 Aug 2018, at 13:37, Mark Wieder via use-livecode 
>  wrote:
> 
>> On 08/05/2018 11:20 AM, Mark Waddingham via use-livecode wrote:
>> That isn't overloading put - that's introducing query expressions...
>> Which would (at least as far as filter currently goes - I have another as 
>> yet unstated reason for suggesting a revised syntax beyond stopping my own 
>> mental torture!) eliminate the need for filter into.
>> e.g
>> the lines of X where Y
>> Could be something which would work anywhere an expression does.
> 
> As a long-term goal, I muchly like this.
> 
>> However, small steps - the current filter code is tied to the filter command 
>> - so additions is easier to do there first as @Monte has demonstrated.
> 
> No worries. Syntax aside, I tend to use the filter command quite a bit, as 
> the implementation in the engine is blazingly fast.
> 
> -- 
> Mark Wieder
> ahsoftw...@gmail.com
> 
> ___
> use-livecode mailing list
> use-livecode@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@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: valueDiff for arrays?

[Mark Wieder via use-livecode]

On 08/05/2018 11:20 AM, Mark Waddingham via use-livecode wrote:

That isn't overloading put - that's introducing query expressions...

Which would (at least as far as filter currently goes - I have another as yet 
unstated reason for suggesting a revised syntax beyond stopping my own mental 
torture!) eliminate the need for filter into.

e.g

the lines of X where Y

Could be something which would work anywhere an expression does.


As a long-term goal, I muchly like this.


However, small steps - the current filter code is tied to the filter command - 
so additions is easier to do there first as @Monte has demonstrated.


No worries. Syntax aside, I tend to use the filter command quite a bit, 
as the implementation in the engine is blazingly fast.


--
 Mark Wieder
 ahsoftw...@gmail.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: valueDiff for arrays?

[Mark Waddingham via use-livecode]

That isn't overloading put - that's introducing query expressions...

Which would (at least as far as filter currently goes - I have another as yet 
unstated reason for suggesting a revised syntax beyond stopping my own mental 
torture!) eliminate the need for filter into.

e.g 

the lines of X where Y

Could be something which would work anywhere an expression does.

However, small steps - the current filter code is tied to the filter command - 
so additions is easier to do there first as @Monte has demonstrated. 

Warmest Regards,

Mark.


Sent from my iPhone

> On 5 Aug 2018, at 12:29, Mark Wieder via use-livecode 
>  wrote:
> 
>> On 08/05/2018 07:38 AM, Mark Waddingham via use-livecode wrote:
>> 
>> keep lines of X [ where | matching | not matching ] Y into Z -- seems 
>> contorted
> 
> That seems like a good argument for overloading the already-overworked 'put' 
> command:
> 
> put lines of X [ where | matching | not matching ] Y into Z
> 
> -- 
> Mark Wieder
> ahsoftw...@gmail.com
> 
> ___
> use-livecode mailing list
> use-livecode@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@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: valueDiff for arrays?

[Mark Wieder via use-livecode]

On 08/05/2018 07:38 AM, Mark Waddingham via use-livecode wrote:

keep lines of X [ where | matching | not matching ] Y into Z -- seems 
contorted


That seems like a good argument for overloading the already-overworked 
'put' command:


put lines of X [ where | matching | not matching ] Y into Z

--
 Mark Wieder
 ahsoftw...@gmail.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: valueDiff for arrays?

[J. Landman Gay via use-livecode]

I think "filter" is culinary enough. Coffee filters do the same thing, only 
they filter without. :)


--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
On August 5, 2018 11:53:11 AM Mark Waddingham via use-livecode 
 wrote:



Well...

strain X through Y

Does kind of work - although it still doesn't explicitly relate what is to 
be kept (which is implicit in context in a recipe) and that's the 
deficiency in the current syntax.


We can make all parts optional in the new proposed form which would mean 
you can still write a significant contraction. However, by being verbose 
you can make the command a complete representation of what is being done 
without needing to understand the context of the operation (which means 
code which is more verbose is much more quickly readable).


Anyway, maybe when we finally get to open language we can have a culinary 
based variant syntax ;)


Warmest Regards,

Mark.

Sent from my iPhone

On 5 Aug 2018, at 11:23, David Glasgow via use-livecode 
 wrote:


Maybe 'strain' could be a culinary synonym?
;-)

Best wishes

David Glasgow

Sent from my  iPad via iBrain & iFingers

LinkedIn

On 5 Aug 2018, at 16:36, J. Landman Gay via use-livecode 
 wrote:


This is getting pretty contorted and is becoming less like natural 
language. For what it's worth, I have never been confused by the current 
use of filter. I think of it as pouring soup through a wire strainer. 
Filtering "with" keeps the solids. Filtering "without" dumps them and keeps 
the liquid.


Maybe I cook too much. In any case, the solids (what remains after 
filtering) are the things you're either keeping or discarding.

--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
On August 5, 2018 9:38:45 AM Brian Milby via use-livecode 
 wrote:


Probably better:


filter [{lines | items | keys | elements} of] filterSource {keeping | 
discarding | with | without | [not] matching} {[{wildcard | regex} pattern] 
filterPattern | where filterExpression} [into targetContainer]



So Monte’s example would be:
filter keys of tFoo keeping where tFoo[each] is not tBar[each]
(And to get Richard’s result you would need to follow this by an intersect 
each way. The filter would replace the repeat loop in Mark’s solution)



Even though “with where” would be syntactically correct, the preferred 
usage would be “keeping where”.


Thanks,
Brian
On Aug 5, 2018, 7:32 AM -0500, Mark Waddingham via use-livecode 
, wrote:

On 2018-08-05 07:31, Monte Goulding via use-livecode wrote:
Given I have been wanting to do ^ for a couple of years I decided to
just go ahead and do it… might be a while before we have time to
bikeshed the syntax though.

https://github.com/livecode/livecode/pull/6626


Examples:
local tFoo,tBar
put "foo" into tFoo[1]
put "bar" into tFoo[2]
put "baz" into tBar[1]
put "bar" into tBar[2]
filter keys of tFoo with expression tFoo[each] is tBar[each]
— tFoo now has one key 2 which is `bar`

put “yes,foo” & return & “no,bar” into tFoo
filter lines of tFoo with expression item 1 of each is “yes”

We could feasibly not use `with|without` for this forcing the
expression to return true to filter. If we went that way then perhaps
`where` would be nicest?

filter lines of tFoo where item 1 of each is “yes”


Geez @Monte - you do like creating work for me don't you! ;)

In terms of syntax - definitely not 'with expression' - that's ghastly.
It is a 'where' clause - in the same vein as SQL and other query
languages - so no bike-shedding required there (also, pleasingly, all
other 'filter' types become sugar for a where clause using operators
which the language does not have yet - but obviously we have the code
for...).

If we are going to bike-shed over syntax - can we do so over the use of
'filter' itself. I don't know why but I have a complete mental block
about it - regardless of how many times I use it or read it - I always
have to 'double-think' to work out what form to use - is that just me?

filter  of X with Y
filter  of X without Y

I couldn't tell you just by looking *what* they actually do. I'm not
sure why but I think the verb is actually wrong - in all cases you have
a set of things and you are either keeping an element, or removing an
element... So I wonder if:

keep  of X where Y
discard  of X where Y

(I'm not particularly attached to keep/discard - but it does need to be
a pair of 'true' antonyms which don't intersect with any other 'core'
pairs of such things we have).

Might be more appropriate?

Of course, maybe it is just 'with' / 'without' are inappropriate, and
'where' might actually help me retrain my mind to see with/without as
the sugar they truly are.

Anyway, thought it worth throwing out there to see what people think?

Warmest Regards,

Mark.

--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps

Re: valueDiff for arrays?

[J. Landman Gay via use-livecode]

Yes, yours is natural. Some of the others were stretching it a bit.
--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
On August 5, 2018 11:10:47 AM Mark Waddingham via use-livecode 
 wrote:



On 2018-08-05 17:36, J. Landman Gay via use-livecode wrote:

This is getting pretty contorted and is becoming less like natural
language. For what it's worth, I have never been confused by the
current use of filter. I think of it as pouring soup through a wire
strainer. Filtering "with" keeps the solids. Filtering "without" dumps
them and keeps the liquid.


I honestly can't see how:

filter lines of X with Y

Is less contorted and more natural language than:

filter X by keeping lines matching Y

The former *requires* 'arcane' knowledge to comprehend (it is a
significant contraction of concepts - you need to know the contractions
precisely to understand it!) - the latter does precisely what it says -
it is actually a fully correct and full English sentence...

Warmest Regards,

Mark.

--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps


___
use-livecode mailing list
use-livecode@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@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: valueDiff for arrays?

[Mark Waddingham via use-livecode]

Well...

strain X through Y

Does kind of work - although it still doesn't explicitly relate what is to be 
kept (which is implicit in context in a recipe) and that's the deficiency in 
the current syntax.

We can make all parts optional in the new proposed form which would mean you 
can still write a significant contraction. However, by being verbose you can 
make the command a complete representation of what is being done without 
needing to understand the context of the operation (which means code which is 
more verbose is much more quickly readable).

Anyway, maybe when we finally get to open language we can have a culinary based 
variant syntax ;)

Warmest Regards,

Mark.

Sent from my iPhone

> On 5 Aug 2018, at 11:23, David Glasgow via use-livecode 
>  wrote:
> 
> Maybe 'strain' could be a culinary synonym?
> ;-)
> 
> Best wishes 
> 
> David Glasgow
> 
> Sent from my  iPad via iBrain & iFingers
> 
> LinkedIn
> 
>> On 5 Aug 2018, at 16:36, J. Landman Gay via use-livecode 
>>  wrote:
>> 
>> This is getting pretty contorted and is becoming less like natural language. 
>> For what it's worth, I have never been confused by the current use of 
>> filter. I think of it as pouring soup through a wire strainer. Filtering 
>> "with" keeps the solids. Filtering "without" dumps them and keeps the liquid.
>> 
>> Maybe I cook too much. In any case, the solids (what remains after 
>> filtering) are the things you're either keeping or discarding.
>> --
>> Jacqueline Landman Gay | jac...@hyperactivesw.com
>> HyperActive Software | http://www.hyperactivesw.com
>>> On August 5, 2018 9:38:45 AM Brian Milby via use-livecode 
>>>  wrote:
>>> 
>>> Probably better:
>>> 
>>> 
>>> filter [{lines | items | keys | elements} of] filterSource {keeping | 
>>> discarding | with | without | [not] matching} {[{wildcard | regex} pattern] 
>>> filterPattern | where filterExpression} [into targetContainer]
>>> 
>>> 
>>> So Monte’s example would be:
>>> filter keys of tFoo keeping where tFoo[each] is not tBar[each]
>>> (And to get Richard’s result you would need to follow this by an intersect 
>>> each way. The filter would replace the repeat loop in Mark’s solution)
>>> 
>>> 
>>> Even though “with where” would be syntactically correct, the preferred 
>>> usage would be “keeping where”.
>>> 
>>> Thanks,
>>> Brian
 On Aug 5, 2018, 7:32 AM -0500, Mark Waddingham via use-livecode 
 , wrote:
> On 2018-08-05 07:31, Monte Goulding via use-livecode wrote:
> Given I have been wanting to do ^ for a couple of years I decided to
> just go ahead and do it… might be a while before we have time to
> bikeshed the syntax though.
> 
> https://github.com/livecode/livecode/pull/6626
> 
> 
> Examples:
> local tFoo,tBar
> put "foo" into tFoo[1]
> put "bar" into tFoo[2]
> put "baz" into tBar[1]
> put "bar" into tBar[2]
> filter keys of tFoo with expression tFoo[each] is tBar[each]
> — tFoo now has one key 2 which is `bar`
> 
> put “yes,foo” & return & “no,bar” into tFoo
> filter lines of tFoo with expression item 1 of each is “yes”
> 
> We could feasibly not use `with|without` for this forcing the
> expression to return true to filter. If we went that way then perhaps
> `where` would be nicest?
> 
> filter lines of tFoo where item 1 of each is “yes”
 
 Geez @Monte - you do like creating work for me don't you! ;)
 
 In terms of syntax - definitely not 'with expression' - that's ghastly.
 It is a 'where' clause - in the same vein as SQL and other query
 languages - so no bike-shedding required there (also, pleasingly, all
 other 'filter' types become sugar for a where clause using operators
 which the language does not have yet - but obviously we have the code
 for...).
 
 If we are going to bike-shed over syntax - can we do so over the use of
 'filter' itself. I don't know why but I have a complete mental block
 about it - regardless of how many times I use it or read it - I always
 have to 'double-think' to work out what form to use - is that just me?
 
 filter  of X with Y
 filter  of X without Y
 
 I couldn't tell you just by looking *what* they actually do. I'm not
 sure why but I think the verb is actually wrong - in all cases you have
 a set of things and you are either keeping an element, or removing an
 element... So I wonder if:
 
 keep  of X where Y
 discard  of X where Y
 
 (I'm not particularly attached to keep/discard - but it does need to be
 a pair of 'true' antonyms which don't intersect with any other 'core'
 pairs of such things we have).
 
 Might be more appropriate?
 
 Of course, maybe it is just 'with' / 'without' are inappropriate, and
 'where' might actually help me retrain my mind to see with/without as
 the sugar they truly are.
 
 

Re: valueDiff for arrays?

[David Glasgow via use-livecode]

Maybe 'strain' could be a culinary synonym?
;-)

Best wishes 

David Glasgow

Sent from my  iPad via iBrain & iFingers

LinkedIn

> On 5 Aug 2018, at 16:36, J. Landman Gay via use-livecode 
>  wrote:
> 
> This is getting pretty contorted and is becoming less like natural language. 
> For what it's worth, I have never been confused by the current use of filter. 
> I think of it as pouring soup through a wire strainer. Filtering "with" keeps 
> the solids. Filtering "without" dumps them and keeps the liquid.
> 
> Maybe I cook too much. In any case, the solids (what remains after filtering) 
> are the things you're either keeping or discarding.
> --
> Jacqueline Landman Gay | jac...@hyperactivesw.com
> HyperActive Software | http://www.hyperactivesw.com
>> On August 5, 2018 9:38:45 AM Brian Milby via use-livecode 
>>  wrote:
>> 
>> Probably better:
>> 
>> 
>> filter [{lines | items | keys | elements} of] filterSource {keeping | 
>> discarding | with | without | [not] matching} {[{wildcard | regex} pattern] 
>> filterPattern | where filterExpression} [into targetContainer]
>> 
>> 
>> So Monte’s example would be:
>> filter keys of tFoo keeping where tFoo[each] is not tBar[each]
>> (And to get Richard’s result you would need to follow this by an intersect 
>> each way. The filter would replace the repeat loop in Mark’s solution)
>> 
>> 
>> Even though “with where” would be syntactically correct, the preferred usage 
>> would be “keeping where”.
>> 
>> Thanks,
>> Brian
>>> On Aug 5, 2018, 7:32 AM -0500, Mark Waddingham via use-livecode 
>>> , wrote:
>>> On 2018-08-05 07:31, Monte Goulding via use-livecode wrote:
>>> > Given I have been wanting to do ^ for a couple of years I decided to
>>> > just go ahead and do it… might be a while before we have time to
>>> > bikeshed the syntax though.
>>> >
>>> > https://github.com/livecode/livecode/pull/6626
>>> > 
>>> >
>>> > Examples:
>>> > local tFoo,tBar
>>> > put "foo" into tFoo[1]
>>> > put "bar" into tFoo[2]
>>> > put "baz" into tBar[1]
>>> > put "bar" into tBar[2]
>>> > filter keys of tFoo with expression tFoo[each] is tBar[each]
>>> > — tFoo now has one key 2 which is `bar`
>>> >
>>> > put “yes,foo” & return & “no,bar” into tFoo
>>> > filter lines of tFoo with expression item 1 of each is “yes”
>>> >
>>> > We could feasibly not use `with|without` for this forcing the
>>> > expression to return true to filter. If we went that way then perhaps
>>> > `where` would be nicest?
>>> >
>>> > filter lines of tFoo where item 1 of each is “yes”
>>> 
>>> Geez @Monte - you do like creating work for me don't you! ;)
>>> 
>>> In terms of syntax - definitely not 'with expression' - that's ghastly.
>>> It is a 'where' clause - in the same vein as SQL and other query
>>> languages - so no bike-shedding required there (also, pleasingly, all
>>> other 'filter' types become sugar for a where clause using operators
>>> which the language does not have yet - but obviously we have the code
>>> for...).
>>> 
>>> If we are going to bike-shed over syntax - can we do so over the use of
>>> 'filter' itself. I don't know why but I have a complete mental block
>>> about it - regardless of how many times I use it or read it - I always
>>> have to 'double-think' to work out what form to use - is that just me?
>>> 
>>> filter  of X with Y
>>> filter  of X without Y
>>> 
>>> I couldn't tell you just by looking *what* they actually do. I'm not
>>> sure why but I think the verb is actually wrong - in all cases you have
>>> a set of things and you are either keeping an element, or removing an
>>> element... So I wonder if:
>>> 
>>> keep  of X where Y
>>> discard  of X where Y
>>> 
>>> (I'm not particularly attached to keep/discard - but it does need to be
>>> a pair of 'true' antonyms which don't intersect with any other 'core'
>>> pairs of such things we have).
>>> 
>>> Might be more appropriate?
>>> 
>>> Of course, maybe it is just 'with' / 'without' are inappropriate, and
>>> 'where' might actually help me retrain my mind to see with/without as
>>> the sugar they truly are.
>>> 
>>> Anyway, thought it worth throwing out there to see what people think?
>>> 
>>> Warmest Regards,
>>> 
>>> Mark.
>>> 
>>> --
>>> Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
>>> LiveCode: Everyone can create apps
>>> 
>>> ___
>>> use-livecode mailing list
>>> use-livecode@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@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
> 

Re: valueDiff for arrays?

[Mark Waddingham via use-livecode]

On 2018-08-05 17:36, J. Landman Gay via use-livecode wrote:

This is getting pretty contorted and is becoming less like natural
language. For what it's worth, I have never been confused by the
current use of filter. I think of it as pouring soup through a wire
strainer. Filtering "with" keeps the solids. Filtering "without" dumps
them and keeps the liquid.


I honestly can't see how:

filter lines of X with Y

Is less contorted and more natural language than:

filter X by keeping lines matching Y

The former *requires* 'arcane' knowledge to comprehend (it is a 
significant contraction of concepts - you need to know the contractions 
precisely to understand it!) - the latter does precisely what it says - 
it is actually a fully correct and full English sentence...


Warmest Regards,

Mark.

--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: valueDiff for arrays?

[J. Landman Gay via use-livecode]

This is getting pretty contorted and is becoming less like natural 
language. For what it's worth, I have never been confused by the current 
use of filter. I think of it as pouring soup through a wire strainer. 
Filtering "with" keeps the solids. Filtering "without" dumps them and keeps 
the liquid.


Maybe I cook too much. In any case, the solids (what remains after 
filtering) are the things you're either keeping or discarding.

--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
On August 5, 2018 9:38:45 AM Brian Milby via use-livecode 
 wrote:



Probably better:


filter [{lines | items | keys | elements} of] filterSource {keeping | 
discarding | with | without | [not] matching} {[{wildcard | regex} pattern] 
filterPattern | where filterExpression} [into targetContainer]



So Monte’s example would be:
filter keys of tFoo keeping where tFoo[each] is not tBar[each]
(And to get Richard’s result you would need to follow this by an intersect 
each way. The filter would replace the repeat loop in Mark’s solution)



Even though “with where” would be syntactically correct, the preferred 
usage would be “keeping where”.


Thanks,
Brian
On Aug 5, 2018, 7:32 AM -0500, Mark Waddingham via use-livecode 
, wrote:

On 2018-08-05 07:31, Monte Goulding via use-livecode wrote:
> Given I have been wanting to do ^ for a couple of years I decided to
> just go ahead and do it… might be a while before we have time to
> bikeshed the syntax though.
>
> https://github.com/livecode/livecode/pull/6626
> 
>
> Examples:
> local tFoo,tBar
> put "foo" into tFoo[1]
> put "bar" into tFoo[2]
> put "baz" into tBar[1]
> put "bar" into tBar[2]
> filter keys of tFoo with expression tFoo[each] is tBar[each]
> — tFoo now has one key 2 which is `bar`
>
> put “yes,foo” & return & “no,bar” into tFoo
> filter lines of tFoo with expression item 1 of each is “yes”
>
> We could feasibly not use `with|without` for this forcing the
> expression to return true to filter. If we went that way then perhaps
> `where` would be nicest?
>
> filter lines of tFoo where item 1 of each is “yes”

Geez @Monte - you do like creating work for me don't you! ;)

In terms of syntax - definitely not 'with expression' - that's ghastly.
It is a 'where' clause - in the same vein as SQL and other query
languages - so no bike-shedding required there (also, pleasingly, all
other 'filter' types become sugar for a where clause using operators
which the language does not have yet - but obviously we have the code
for...).

If we are going to bike-shed over syntax - can we do so over the use of
'filter' itself. I don't know why but I have a complete mental block
about it - regardless of how many times I use it or read it - I always
have to 'double-think' to work out what form to use - is that just me?

filter  of X with Y
filter  of X without Y

I couldn't tell you just by looking *what* they actually do. I'm not
sure why but I think the verb is actually wrong - in all cases you have
a set of things and you are either keeping an element, or removing an
element... So I wonder if:

keep  of X where Y
discard  of X where Y

(I'm not particularly attached to keep/discard - but it does need to be
a pair of 'true' antonyms which don't intersect with any other 'core'
pairs of such things we have).

Might be more appropriate?

Of course, maybe it is just 'with' / 'without' are inappropriate, and
'where' might actually help me retrain my mind to see with/without as
the sugar they truly are.

Anyway, thought it worth throwing out there to see what people think?

Warmest Regards,

Mark.

--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps

___
use-livecode mailing list
use-livecode@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@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@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: valueDiff for arrays?

[Brian Milby via use-livecode]

I like A. Here is my take on the actual dictionary syntax:

filter filterSource by {keeping | discarding} [{lines | items | keys | 
elements}] {{with | without | [not] matching} {[{wildcard | regex} pattern] 
filterPattern | where filterExpression} [into targetContainer]

Not sure about leaving the chunk type optional. It would make readability less 
obvious but no less than today.

My guess is that retaining the earlier form (backwards compatibility) would be 
easy since the parser just needs to switch based on the third token being “by”. 
The new form would be placed as the first one checked to make it the fastest to 
parse.

Thanks,
Brian
On Aug 5, 2018, 9:38 AM -0500, Mark Waddingham via use-livecode 
, wrote:
> On 2018-08-05 16:00, Brian Milby wrote:
> > Or to include new modifiers:
> > {keeping | discarding | with | without | [not] matching}
> >
> > Which if not using the “into” form the first two make the
> > statement much clearer as to the intent.
>
> So, I figured out my 'cognitive dissonance' on filter. The issue is that
> 'filter' by itself is not sufficient to suggest the operation the filter
> is performing - it is too general a term. However...
>
> I think Brian's suggestion of modifiers is actually much closer to the
> most appropriate syntax because they naturally work well with or without
> an 'into' clause. Contrast (with a minor tweak to @Brian's suggestion):
>
> keep lines of X [ where | matching | not matching ] Y -- seems okay
> keep lines of X [ where | matching | not matching ] Y into Z -- seems
> contorted
>
> discard lines of X [ where | matching | not matching ] Y -- seems okay
> discard lines of X [ where | matching | not matching ] Y into Z --
> ambiguous, are the discarded lines going into Z, or the ones which
> aren't discarded?
>
> In contrast here are two potential forms with modifiers:
>
> A: filter X by ( keeping | discarding ) lines ( where | [ not ] matching
> | with | without ) Y [ into Z ]
>
> B: filter lines of X by keeping those ( where | [ not ] matching | with
> | without ) Y [ into Z ]
>
> In terms of these (A) I think is preferable - simply because we already
> use 'by' in the language - rather than 'those'; further it strongly
> suggests that the process 'moves' X to Z - by parsing the chunks of X
> through some filter defined by Y.
>
> The actual fundamental operation here is:
>
> Filter(source, chunk, predicate, target)
>
> Where predicate is formed as follows (assuming we had operators matching
> wildcard / matching pattern!):
>
> keeping where P -> P
> keeping with P -> each matches wildcard P
> keeping without P -> not (each matches wildcard P)
> keeping matching P -> each matches pattern P
> keeping not matching P -> not (each matches wildcard P)
>
> discarding where P -> not P
> discarding with P -> not (each matches wildcard P)
> discarding without P -> each matches wildcard P
> discarding matching P -> not (each matches pattern P)
> discarding not matching P -> each matches wildcard P
>
> So the actual underling operation is the same: P is a boolean predicate
> operating on 'each', where each is taken to be each 'chunk' of X in
> turn; if P(each) returns true, the element is kept, otherwise it is
> discarded.
>
> I quite like the above - it has a very simple underbelly (a single
> operation!), but the actual English-like syntax is a true and correct
> sentence.
>
> What do people think?
>
> Warmest Regards,
>
> Mark.
>
> --
> Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
> LiveCode: Everyone can create apps
>
> ___
> use-livecode mailing list
> use-livecode@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@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: valueDiff for arrays?

[Mark Waddingham via use-livecode]

On 2018-08-05 16:00, Brian Milby wrote:

Or to include new modifiers:
 {keeping | discarding | with | without | [not] matching}

 Which if not using the “into” form the first two make the
statement much clearer as to the intent.


So, I figured out my 'cognitive dissonance' on filter. The issue is that 
'filter' by itself is not sufficient to suggest the operation the filter 
is performing - it is too general a term. However...


I think Brian's suggestion of modifiers is actually much closer to the 
most appropriate syntax because they naturally work well with or without 
an 'into' clause. Contrast (with a minor tweak to @Brian's suggestion):


keep lines of X [ where | matching | not matching ] Y -- seems okay
keep lines of X [ where | matching | not matching ] Y into Z -- seems 
contorted


discard lines of X [ where | matching | not matching ] Y -- seems okay
discard lines of X [ where | matching | not matching ] Y into Z -- 
ambiguous, are the discarded lines going into Z, or the ones which 
aren't discarded?


In contrast here are two potential forms with modifiers:

A: filter X by ( keeping | discarding ) lines ( where | [ not ] matching 
| with | without ) Y [ into Z ]


B: filter lines of X by keeping those ( where | [ not ] matching | with 
| without ) Y [ into Z ]


In terms of these (A) I think is preferable - simply because we already 
use 'by' in the language - rather than 'those'; further it strongly 
suggests that the process 'moves' X to Z - by parsing the chunks of X 
through some filter defined by Y.


The actual fundamental operation here is:

  Filter(source, chunk, predicate, target)

Where predicate is formed as follows (assuming we had operators matching 
wildcard / matching pattern!):


  keeping where P -> P
  keeping with P -> each matches wildcard P
  keeping without P -> not (each matches wildcard P)
  keeping matching P -> each matches pattern P
  keeping not matching P -> not (each matches wildcard P)

  discarding where P -> not P
  discarding with P -> not (each matches wildcard P)
  discarding without P -> each matches wildcard P
  discarding matching P -> not (each matches pattern P)
  discarding not matching P -> each matches wildcard P

So the actual underling operation is the same: P is a boolean predicate 
operating on 'each', where each is taken to be each 'chunk' of X in 
turn; if P(each) returns true, the element is kept, otherwise it is 
discarded.


I quite like the above - it has a very simple underbelly (a single 
operation!), but the actual English-like syntax is a true and correct 
sentence.


What do people think?

Warmest Regards,

Mark.

--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: valueDiff for arrays?

[Brian Milby via use-livecode]

Probably better:


filter [{lines | items | keys | elements} of] filterSource {keeping | 
discarding | with | without | [not] matching} {[{wildcard | regex} pattern] 
filterPattern | where filterExpression} [into targetContainer]


So Monte’s example would be:
filter keys of tFoo keeping where tFoo[each] is not tBar[each]
(And to get Richard’s result you would need to follow this by an intersect each 
way. The filter would replace the repeat loop in Mark’s solution)


Even though “with where” would be syntactically correct, the preferred usage 
would be “keeping where”.

Thanks,
Brian
On Aug 5, 2018, 7:32 AM -0500, Mark Waddingham via use-livecode 
, wrote:
> On 2018-08-05 07:31, Monte Goulding via use-livecode wrote:
> > Given I have been wanting to do ^ for a couple of years I decided to
> > just go ahead and do it… might be a while before we have time to
> > bikeshed the syntax though.
> >
> > https://github.com/livecode/livecode/pull/6626
> > 
> >
> > Examples:
> > local tFoo,tBar
> > put "foo" into tFoo[1]
> > put "bar" into tFoo[2]
> > put "baz" into tBar[1]
> > put "bar" into tBar[2]
> > filter keys of tFoo with expression tFoo[each] is tBar[each]
> > — tFoo now has one key 2 which is `bar`
> >
> > put “yes,foo” & return & “no,bar” into tFoo
> > filter lines of tFoo with expression item 1 of each is “yes”
> >
> > We could feasibly not use `with|without` for this forcing the
> > expression to return true to filter. If we went that way then perhaps
> > `where` would be nicest?
> >
> > filter lines of tFoo where item 1 of each is “yes”
>
> Geez @Monte - you do like creating work for me don't you! ;)
>
> In terms of syntax - definitely not 'with expression' - that's ghastly.
> It is a 'where' clause - in the same vein as SQL and other query
> languages - so no bike-shedding required there (also, pleasingly, all
> other 'filter' types become sugar for a where clause using operators
> which the language does not have yet - but obviously we have the code
> for...).
>
> If we are going to bike-shed over syntax - can we do so over the use of
> 'filter' itself. I don't know why but I have a complete mental block
> about it - regardless of how many times I use it or read it - I always
> have to 'double-think' to work out what form to use - is that just me?
>
> filter  of X with Y
> filter  of X without Y
>
> I couldn't tell you just by looking *what* they actually do. I'm not
> sure why but I think the verb is actually wrong - in all cases you have
> a set of things and you are either keeping an element, or removing an
> element... So I wonder if:
>
> keep  of X where Y
> discard  of X where Y
>
> (I'm not particularly attached to keep/discard - but it does need to be
> a pair of 'true' antonyms which don't intersect with any other 'core'
> pairs of such things we have).
>
> Might be more appropriate?
>
> Of course, maybe it is just 'with' / 'without' are inappropriate, and
> 'where' might actually help me retrain my mind to see with/without as
> the sugar they truly are.
>
> Anyway, thought it worth throwing out there to see what people think?
>
> Warmest Regards,
>
> Mark.
>
> --
> Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
> LiveCode: Everyone can create apps
>
> ___
> use-livecode mailing list
> use-livecode@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@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: valueDiff for arrays?

[Brian Milby via use-livecode]

Or to include new modifiers:
{keeping | discarding | with | without | [not] matching}

Which if not using the “into” form the first two make the statement much 
clearer as to the intent.

Thanks,
Brian

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: valueDiff for arrays?

[Brian Milby via use-livecode]

Current

filter [{lines | items | keys | elements} of] filterSource {with | without | 
[not] matching} [{wildcard pattern | regex pattern}] filterPattern [into 
targetContainer]

Possible Suggestion

filter [{lines | items | keys | elements} of] filterSource {{with | without | 
[not] matching} [{wildcard | regex}] filterPattern | where filterExpression} 
[into targetContainer]

“matching” was added in 6 which would probably be clearer.

Thanks,
Brian

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: valueDiff for arrays?

[Mark Waddingham via use-livecode]

On 2018-08-05 07:31, Monte Goulding via use-livecode wrote:

Given I have been wanting to do ^ for a couple of years I decided to
just go ahead and do it… might be a while before we have time to
bikeshed the syntax though.

https://github.com/livecode/livecode/pull/6626


Examples:
local tFoo,tBar
put "foo" into tFoo[1]
put "bar" into tFoo[2]
put "baz" into tBar[1]
put "bar" into tBar[2]
filter keys of tFoo with expression tFoo[each] is tBar[each]
— tFoo now has one key 2 which is `bar`

put “yes,foo” & return & “no,bar” into tFoo
filter lines of tFoo with expression item 1 of each is “yes”

We could feasibly not use `with|without` for this forcing the
expression to return true to filter. If we went that way then perhaps
`where` would be nicest?

filter lines of tFoo where item 1 of each is “yes”


Geez @Monte - you do like creating work for me don't you! ;)

In terms of syntax - definitely not 'with expression' - that's ghastly. 
It is a 'where' clause - in the same vein as SQL and other query 
languages - so no bike-shedding required there (also, pleasingly, all 
other 'filter' types become sugar for a where clause using operators 
which the language does not have yet - but obviously we have the code 
for...).


If we are going to bike-shed over syntax - can we do so over the use of 
'filter' itself. I don't know why but I have a complete mental block 
about it - regardless of how many times I use it or read it - I always 
have to 'double-think' to work out what form to use - is that just me?


  filter  of X with Y
  filter  of X without Y

I couldn't tell you just by looking *what* they actually do. I'm not 
sure why but I think the verb is actually wrong - in all cases you have 
a set of things and you are either keeping an element, or removing an 
element... So I wonder if:


  keep  of X where Y
  discard  of X where Y

(I'm not particularly attached to keep/discard - but it does need to be 
a pair of 'true' antonyms which don't intersect with any other 'core' 
pairs of such things we have).


Might be more appropriate?

Of course, maybe it is just 'with' / 'without' are inappropriate, and 
'where' might actually help me retrain my mind to see with/without as 
the sugar they truly are.


Anyway, thought it worth throwing out there to see what people think?

Warmest Regards,

Mark.

--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: valueDiff for arrays?

[Mark Waddingham via use-livecode]

On 2018-08-05 03:59, Monte Goulding via use-livecode wrote:

Just to throw it out there I still want to add `each` to filter one
day. So in this case I think it would be:

filter keys of tArray1 with expression \
  each is among the keys of tArray2 and \
  tArray1[each] is not tArray2[each]


Not quite - if I understand Richard's request correctly, and the code 
which has been presented

then it cannot be done by a single filter on one array.

The result he is asking for requires information from both arrays, some 
of which may not be shared.


The above only contains information from tArray1.

Warmest Regards,

Mark.

--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: valueDiff for arrays?

[Monte Goulding via use-livecode]

> On 5 Aug 2018, at 11:59 am, Monte Goulding via use-livecode 
>  wrote:
> 
> Just to throw it out there I still want to add `each` to filter one day. So 
> in this case I think it would be:
> 
> filter keys of tArray1 with expression \
>  each is among the keys of tArray2 and \
>  tArray1[each] is not tArray2[each]


Given I have been wanting to do ^ for a couple of years I decided to just go 
ahead and do it… might be a while before we have time to bikeshed the syntax 
though.

https://github.com/livecode/livecode/pull/6626 


Examples:
local tFoo,tBar
put "foo" into tFoo[1]
put "bar" into tFoo[2]
put "baz" into tBar[1]
put "bar" into tBar[2]
filter keys of tFoo with expression tFoo[each] is tBar[each]
— tFoo now has one key 2 which is `bar`

put “yes,foo” & return & “no,bar” into tFoo
filter lines of tFoo with expression item 1 of each is “yes”

We could feasibly not use `with|without` for this forcing the expression to 
return true to filter. If we went that way then perhaps `where` would be nicest?

filter lines of tFoo where item 1 of each is “yes”

Cheers

Monte

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: valueDiff for arrays?

[Brian Milby via use-livecode]

I have not been able to locate the earlier conversation on pass by
reference vice value.  I did a quick test and it took 100,000 loops to be
able to get a difference that was obvious.  My test was to construct simple
functions that took 1 to 3 parameters.  3 functions used all pass by value,
3 functions used all pass by reference.  Code inside the function added 1
to each parameter and returned the first.  The pass by reference function
was consistently around 40ms faster than the matching value function.
Making the functions private made them slightly faster but the delta was
about the same.  All of the values in this test were numeric.  Those
differences seem smaller that I recall, so I will do some additional test
with arrays and strings.
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: valueDiff for arrays?

[Mark Wieder via use-livecode]

On 08/04/2018 12:20 PM, J. Landman Gay via use-livecode wrote:

On 8/4/18 12:41 PM, Mark Waddingham via use-livecode wrote:

Can you immediately see the error?


Who, me? LOL. Well, I did find the line that was different. Brian and 
others who can read this stuff did better. But I did get the gist of 
your post and feel sufficiently smug now.


Careful with that. Smugness is the main way those things get messed up 
in the first place.


--
 Mark Wieder
 ahsoftw...@gmail.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: valueDiff for arrays?

[Mark Wieder via use-livecode]

On 08/04/2018 07:11 PM, Brian Milby via use-livecode wrote:

I think Mark's code had a typo (left returned too many keys), but even when
corrected it takes half the time as a pure LCS solution.  Here's my
modification:


Quite right. Good catch.

--
 Mark Wieder
 ahsoftw...@gmail.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: valueDiff for arrays?

[Brian Milby via use-livecode]

I think Mark's code had a typo (left returned too many keys), but even when
corrected it takes half the time as a pure LCS solution.  Here's my
modification:

function bwmValueDiff pLeft, pRight
   local tResult
   intersect pLeft with pRight into tResult["1"]
   repeat for each key tKey in tResult["1"]
  if pLeft[tKey] is pRight[tKey] then
 delete variable tResult["1"][tKey]
  end if
   end repeat
   intersect pRight with tResult["1"] into tResult["2"]
   return tResult
end bwmValueDiff


On Sat, Aug 4, 2018 at 9:01 PM, Mark Wieder via use-livecode <
use-livecode@lists.runrev.com> wrote:

> On 08/04/2018 04:45 PM, Mark Waddingham via use-livecode wrote:
>
> The other place this could come to bear is making the S/B (or some variant
>> there-of) not only work to produce an application, but also a
>> 'component/extension' - i.e. a distributable 'compiled' (in some sense)
>> form of a collection of script only stacks which were much more easily
>> distributable.
>>
>
> Hmmm... a 'bundle' of script-only stacks as a text file, especially if I
> could attach it as a substack is very appealing. This is certainly a need
> for stacks I distribute as stacks... for example, you can't use revOnline
> for script-only stacks or for LCB code.
>
> Hehe - well it is a working day for me today, and tomorrow and the next
>> week - I'm currently in Dallas, Texas, for FileMaker DevCon.
>>
>
> My condolences 
>
> --
>  Mark Wieder
>  ahsoftw...@gmail.com
>
>
> ___
> use-livecode mailing list
> use-livecode@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@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: valueDiff for arrays?

[Mark Wieder via use-livecode]

On 08/04/2018 04:45 PM, Mark Waddingham via use-livecode wrote:

The other place this could come to bear is making the S/B (or some 
variant there-of) not only work to produce an application, but also a 
'component/extension' - i.e. a distributable 'compiled' (in some sense) 
form of a collection of script only stacks which were much more easily 
distributable.


Hmmm... a 'bundle' of script-only stacks as a text file, especially if I 
could attach it as a substack is very appealing. This is certainly a 
need for stacks I distribute as stacks... for example, you can't use 
revOnline for script-only stacks or for LCB code.


Hehe - well it is a working day for me today, and tomorrow and the next 
week - I'm currently in Dallas, Texas, for FileMaker DevCon.


My condolences 

--
 Mark Wieder
 ahsoftw...@gmail.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: valueDiff for arrays?

[Monte Goulding via use-livecode]

Just to throw it out there I still want to add `each` to filter one day. So in 
this case I think it would be:

filter keys of tArray1 with expression \
  each is among the keys of tArray2 and \
  tArray1[each] is not tArray2[each]

> On 5 Aug 2018, at 11:23 am, Brian Milby via use-livecode 
>  wrote:
> 
> Here is code that only uses LCS to accomplish the goal (only returning the
> keys where they exist in both arrays but the values are different).  This
> is made to be similar to the way the existing functions work (with the
> option to mutate).
> 
> command valueDiff @pDestinationA, @pLeftA, pRightA
>   local tMutate, tLeft, tRight, tNewRight
>   if the paramCount is 3 then
>  put false into tMutate
>  put pLeftA into tLeft
>  put pRightA into tRight
>   else
>  put true into tMutate
>  put pDestinationA into tLeft
>  put pLeftA into tRight
>   end if
>   repeat for each key tKey in tLeft
>  if tKey is among the keys of tRight and \
>tLeft[tKey] is not tRight[tKey] then
> put tRight[tKey] into tNewRight[tKey]
> next repeat
>  end if
>  delete variable tLeft[tKey]
>   end repeat
>   if tMutate then
>  put tLeft into pDestinationA
>  put tNewRight into pLeftA
>   else
>  put tLeft into pDestinationA["1"]
>  put tNewRight into pDestinationA["2"]
>   end if
> end valueDiff
> 
> My question from an engine perspective is whether it would be faster to
> just generate both arrays instead of removing keys from tLeft.  I decided
> to build the tNewRight to avoid iterating the keys of tRight.
> 
> I'd be pretty confident that Mark's solution will be faster, even with 3
> iterations over the keys.
> 
> On Sat, Aug 4, 2018 at 6:52 PM, Mark Waddingham via use-livecode <
> use-livecode@lists.runrev.com> wrote:
> 
>> On 2018-08-04 21:00, Richard Gaskin via use-livecode wrote:
>> 
>>> Mark Waddingham wrote:
>>> 
>>> Yes - so come up with LCS handlers which do that, share them, let's
 work together to make them as efficient in LCS as possible and then
 see what we can do in the engine to improve their performance (which
 I'm guessing is as much the purpose for the proposition as the
 syntax).
 
>>> 
>>> It is, primarily.  The minor convenience is nice too, but you know how
>>> much I love to see performance enhancements in the engine.
>>> 
>>> As for implementation, Mark Wieder's looks good:
>>> http://lists.runrev.com/pipermail/use-livecode/2018-August/248862.html
>>> 
>> 
>> One important point here (which I think is something which is often
>> overlooked in LC as it is just something we deal with implicitly case by
>> case)...
>> 
>> In your use-case for 'valueDiff' - do you need to tell the difference
>> between a key value being the empty string and a key value not being
>> present at all?
>> 
>> [ i.e. using an array key absence to emulate 'nothing': meaning you are
>> actually storing nothing or a value (even the empty string). ]
>> 
>> It might seem like a minor detail, but does change the operation somewhat
>> (and potential implementations).
>> 
>> Warmest Regards,
>> 
>> Mark.
>> 
>> --
>> Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
>> LiveCode: Everyone can create apps
>> 
>> ___
>> use-livecode mailing list
>> use-livecode@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@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@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: valueDiff for arrays?

[Brian Milby via use-livecode]

Here is code that only uses LCS to accomplish the goal (only returning the
keys where they exist in both arrays but the values are different).  This
is made to be similar to the way the existing functions work (with the
option to mutate).

command valueDiff @pDestinationA, @pLeftA, pRightA
   local tMutate, tLeft, tRight, tNewRight
   if the paramCount is 3 then
  put false into tMutate
  put pLeftA into tLeft
  put pRightA into tRight
   else
  put true into tMutate
  put pDestinationA into tLeft
  put pLeftA into tRight
   end if
   repeat for each key tKey in tLeft
  if tKey is among the keys of tRight and \
tLeft[tKey] is not tRight[tKey] then
 put tRight[tKey] into tNewRight[tKey]
 next repeat
  end if
  delete variable tLeft[tKey]
   end repeat
   if tMutate then
  put tLeft into pDestinationA
  put tNewRight into pLeftA
   else
  put tLeft into pDestinationA["1"]
  put tNewRight into pDestinationA["2"]
   end if
end valueDiff

My question from an engine perspective is whether it would be faster to
just generate both arrays instead of removing keys from tLeft.  I decided
to build the tNewRight to avoid iterating the keys of tRight.

I'd be pretty confident that Mark's solution will be faster, even with 3
iterations over the keys.

On Sat, Aug 4, 2018 at 6:52 PM, Mark Waddingham via use-livecode <
use-livecode@lists.runrev.com> wrote:

> On 2018-08-04 21:00, Richard Gaskin via use-livecode wrote:
>
>> Mark Waddingham wrote:
>>
>> Yes - so come up with LCS handlers which do that, share them, let's
>>> work together to make them as efficient in LCS as possible and then
>>> see what we can do in the engine to improve their performance (which
>>> I'm guessing is as much the purpose for the proposition as the
>>> syntax).
>>>
>>
>> It is, primarily.  The minor convenience is nice too, but you know how
>> much I love to see performance enhancements in the engine.
>>
>> As for implementation, Mark Wieder's looks good:
>> http://lists.runrev.com/pipermail/use-livecode/2018-August/248862.html
>>
>
> One important point here (which I think is something which is often
> overlooked in LC as it is just something we deal with implicitly case by
> case)...
>
> In your use-case for 'valueDiff' - do you need to tell the difference
> between a key value being the empty string and a key value not being
> present at all?
>
> [ i.e. using an array key absence to emulate 'nothing': meaning you are
> actually storing nothing or a value (even the empty string). ]
>
> It might seem like a minor detail, but does change the operation somewhat
> (and potential implementations).
>
> Warmest Regards,
>
> Mark.
>
> --
> Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
> LiveCode: Everyone can create apps
>
> ___
> use-livecode mailing list
> use-livecode@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@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode