valueDiff for arrays?

classic Classic list List threaded Threaded
135 messages Options
1234567
Reply | Threaded
Open this post in threaded view
|

Re: valueDiff for arrays?

Clarence Martin 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
  [hidden email]

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: valueDiff for arrays?

Clarence Martin 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 <[hidden email]> 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
> [hidden email]
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: valueDiff for arrays?

Clarence Martin 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
  [hidden email]

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: valueDiff for arrays?

Clarence Martin 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 <[hidden email]> 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
> [hidden email]
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: valueDiff for arrays?

Clarence Martin via use-livecode
In reply to this post by Clarence Martin 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
  ____________________________________________________________________
  [hidden email]                http://www.FourthWorld.com

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: valueDiff for arrays?

Clarence Martin via use-livecode
In reply to this post by Clarence Martin 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
  ____________________________________________________________________
  [hidden email]                http://www.FourthWorld.com

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: valueDiff for arrays?

Clarence Martin via use-livecode
In reply to this post by Clarence Martin 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 ~ [hidden email] ~ http://www.livecode.com/
LiveCode: Everyone can create apps

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: valueDiff for arrays?

Clarence Martin via use-livecode
In reply to this post by Clarence Martin 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 ~ [hidden email] ~ http://www.livecode.com/
LiveCode: Everyone can create apps

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: valueDiff for arrays?

Clarence Martin via use-livecode
In reply to this post by Clarence Martin 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 <[hidden email]>, 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
> ____________________________________________________________________
> [hidden email] http://www.FourthWorld.com
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: valueDiff for arrays?

Clarence Martin via use-livecode
In reply to this post by Clarence Martin via use-livecode


> On 5 Aug 2018, at 10:32 pm, Mark Waddingham via use-livecode <[hidden email]> 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
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: valueDiff for arrays?

Clarence Martin via use-livecode
In reply to this post by Clarence Martin via use-livecode


> On 6 Aug 2018, at 12:38 am, Mark Waddingham via use-livecode <[hidden email]> 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
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: valueDiff for arrays?

Clarence Martin 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
<String> ? 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 ~ [hidden email] ~ http://www.livecode.com/
LiveCode: Everyone can create apps

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: valueDiff for arrays?

Clarence Martin via use-livecode


> On 6 Aug 2018, at 7:07 am, Mark Waddingham via use-livecode <[hidden email]> 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
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: valueDiff for arrays?

Clarence Martin 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
>> <[hidden email]> 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 ~ [hidden email] ~ http://www.livecode.com/
LiveCode: Everyone can create apps

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: valueDiff for arrays?

Clarence Martin via use-livecode
In reply to this post by Clarence Martin 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 <[hidden email]> 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 <g>) to specify where "not" is legal.

--
  Mark Wieder
  [hidden email]

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: valueDiff for arrays?

Clarence Martin via use-livecode
In reply to this post by Clarence Martin 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 <
[hidden email]> wrote:

>
>
> > On 6 Aug 2018, at 7:07 am, Mark Waddingham via use-livecode <
> [hidden email]> 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
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: valueDiff for arrays?

Clarence Martin via use-livecode
In reply to this post by Clarence Martin 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         |     [hidden email]
HyperActive Software           |     http://www.hyperactivesw.com

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: valueDiff for arrays?

Clarence Martin via use-livecode
In reply to this post by Clarence Martin 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
>>> <[hidden email]> 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 <g>) 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 ~ [hidden email] ~ http://www.livecode.com/
LiveCode: Everyone can create apps

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: valueDiff for arrays?

Clarence Martin via use-livecode
In reply to this post by Clarence Martin 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 ~ [hidden email] ~ http://www.livecode.com/
LiveCode: Everyone can create apps

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: valueDiff for arrays?

Clarence Martin 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
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
1234567