Re: ChatGPT examples

[Alex Tweedly via use-livecode]

On 20/01/2023 18:26, Geoff Canyon via use-livecode wrote:

I'm sure someone has done the work to create a more efficient algorithm for
this. Off the top of my head if I were trying to  I'd probably do something
like:


Hmmm. Maybe. But I kind of doubt it (though I'd love to find out I'm wrong).

This (or closely related problems) got a lot of attention on the 
mid70s-mid80s, when we were trying to do Design Rule Verification for 
VLSI circuits, with millions of transistors. Where the rules could 
exploit hierarchy, the "clever tree" data structures and algorithms did 
well (See Quad-CIF etc.) But for non-hierarchical problems (such as this 
'closest points' case), nothing came close to this 'scanning window' or 
'linear scan' approach.


But looking more closely, I realized that the number of times a new 
"closest pair" was found is remarkably small - typically between 6 & 10 
times for 50,000 points. So it's very feasible to bear the cost of 
calculating the actual distance (i.e. doing the sqrt call) each time a 
new 'closest pair' is found, and that means the quick filtering test can 
be done on the x-distance (rather than x*x). Also, you can do a similar 
filter test on the Y coord (though it doesn't let you exit the inner 
loop, only allows you to skip the full comparison).


Adding those changes in gets the time down by another 10% or so - so the 
original 2000 points comes down from approx 35ms to around 28ms (almost 
too small to measure reliably). More reasonably, 50,000 points comes 
down from 880ms to 810ms.


Revised code:
function closestPointsSQ pLines
   sort pLines numeric by item 1 of each
   put pLines into pPoints
   split pPoints by CR
   put infinity into minDistSQ
   put infinity into minDist
   put the number of elements in pPoints into N
   repeat with i = 1 to N-1
  repeat with j = i + 1 to N
 put item 1 of pPoints[j] - item 1 of pPoints[i] into t1
 if t1 > minDist then exit repeat
 put item 2 of pPoints[j] - item 2 of pPoints[i] into t2
 if t2 > minDist OR t2 < -minDist then next repeat
 -- add 1 to compareCount
 put t1 * t1 + t2 * t2 into dist
 if dist < minDistSQ then
    put dist into minDistSQ
    put sqrt(dist) into minDist
    put pPoints[i] & " " & pPoints[j] into closestPoints
    --    add 1 to newClosest
 else if dist = minDistSQ then
    put sqrt(dist) into minDist
    put return & pPoints[i] & " " & pPoints[j] after closestPoints
    --    add 1 to tAlsoClosest
 end if
  end repeat
   end repeat
   --   put "SQ compared" && compareCount && newClosest && tAlsoClosest 
 after msg

   return closestPoints
end closestPointsSQ

Alex.


1. Grab two points at random (in case the points are pre-sorted in some
way) and get the distance.
2. Assume that's a reasonable average distance between points.
3. Define that as the number to beat, and define a grid based on it.
4. Go through all the points, tossing them into buckets based on the grid.
I'd define the buckets as fully overlapping to avoid missing close pairs.
5. The size of the grid buckets is critical: too big and you do too much
work. Too small and you end up with all singletons in the buckets. This
would require some experimentation and thought.
6. Go through the buckets only comparing the points within them.

On Fri, Jan 20, 2023 at 10:14 AM Alex Tweedly via use-livecode <
use-livecode@lists.runrev.com> wrote:


On 20/01/2023 16:52, Mark Waddingham via use-livecode wrote:

On 2023-01-20 13:05, Alex Tweedly via use-livecode wrote:

We need a better algorithm. If we use a "linear scan", we can change
it from essentially Order(N**2) to approx Order(N).

Slightly pedantic point (I appreciate that you did say 'approx')...

Sorting can not be done in any less time than O(N*log N) - so the
revised algorithm is O(N*log N) as you have to sort the input for it
to be able to scan linearly.


I figured someone would pick me up on that :-) It was a pretty big
'approx' :\)

The sorting step is indeed O(NlogN).

And the rest of it also worse than linear, but I don't have the math
knowledge to even begin to think about how much worse. Quick testing
says it's worse than O(NlogN), and in practice, it might even be as bad
as something like O(N * sqrt(N)), guessing about the number of points
within a (variable) sized window to the right of the current scan coord.

But in any "real app" usage that I can imagine, the 'clustering' effect
would seem to improve it over O(N*sqrt(N)); e.g. if the points tend to
cluster rather than be evenly randomly spread, then the number within
the scan window goes down on average. "real app" could be players in a
1st person player game, or vehicles on a road simulation, or (in 3d)
stars in the universe - in all cases causing the minDist to decrease
faster than when they are evenly spread.

Alex.



___

Re: ChatGPT examples

[Alex Tweedly via use-livecode]

Duh. What part of Sod's Law says that you always see a bug the first 
time you look at your own code *after* you've made the code public :-(


The 'sort' command below needs to be a numeric sort 

sort pLines by item 1 of each   ->   sort pLines numeric by item 1 
of each


Sorry,

Alex.

On 20/01/2023 13:05, Alex Tweedly via use-livecode wrote:

Fascinating. Thank you so much for that Geoff.

I've been afraid to play with ChatGPT so far - too worried abut 
getting sucked in and spending way too much time 


I did take a look at your third example (since I can never resist a 
performance challenge :-)


There are a number of minor tweaks that could be made to improve 
performance


1. set initial value to infinity rather than calculating a distance 
between the first two points.


2. "number of elements in pPoints" is unvarying within any one call - 
so extract it to a variable at the start


3. use the square of the distance rather than the actual distance - 
save N**2 calls to sqrt


4. use "DX * DX" rather than "DX ^ 2" (about 25% faster)

5. calculate distance in-line rather than call a function

but those all add up to maybe 10% performance improvement (or less - I 
didn't test it). That's useful - but not enough.


For a modest number of points (2000 random points), this takes approx 
16.5 seconds !!


We need a better algorithm. If we use a "linear scan", we can change 
it from essentially Order(N**2) to approx Order(N).


Summary:

 - sort the points by X coordinate

 - while scanning the inner loop, as soon as the difference in Xcoord 
from the 'outer' point exceeds the minDist so far, you can reject not 
just this point, but all subsequent points, and hence exit the inner 
loop immediately.


This brings the time down from 16500 millisecs to 25 millisecs.

BUT - I have no clue how I'd go about describing this to ChatGPT :-)

NB I changed the input parameter to be the list of points rather than 
the array.


Code:

function closestPointsSQ pLines
   sort pLines by item 1 of each
   put pLines into pPoints
   split pPoints by CR
   put infinity into minDist
   put the number of elements in pPoints into N
   repeat with i = 1 to N-1
  repeat with j = i + 1 to N
 put item 1 of pPoints[j] - item 1 of pPoints[i] into t1
 if t1 * t1 > minDist then exit repeat
 put item 2 of pPoints[j] - item 2 of pPoints[i] into t2
 put t1 * t1 + t2 * t2 into dist
 if dist < minDist then
    put dist into minDist
    put pPoints[i] & " " & pPoints[j] into closestPoints
 else if dist = minDist then
    put return & pPoints[i] & " " & pPoints[j] after 
closestPoints

 end if
  end repeat
   end repeat
   return closestPoints
end closestPointsSQ

-- Alex.

On 20/01/2023 06:02, Geoff Canyon via use-livecode wrote:

I tested three use cases, with variations, using ChatGPT for (live)code
generation. There was a lot of back and forth. In the end, I solved 
all the

problems I set, but in some cases I had to hold ChatGPT's hand pretty
tightly.

That said, I learned some things as well -- about LiveCode. ChatGPT's 
code

for Fizz Buzz was faster than mine.

My code was faster for reversing lines. But ChatGPT, when asked to "make
the code faster" gave several suggestions, some of which were wrong or
impossible, but one of them was my method, and when I said "write that
option" it did, with only a few corrections needed.

And one of the ideas, while wrong, caused me to think of a different 
way to

solve the problem, and that way ended up being faster than my original
solution by over 3x on reversing 10k lines. Getting ChatGPT to write 
this

new method was *hard*.

In any case, I wrote it all down in a google doc
. 


If you're curious, have a read. That URL is open for comments/edit
suggestions. If you have any I'd love to hear them.

Thanks!

Geoff
___
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: ChatGPT examples

[Geoff Canyon via use-livecode]

I'm sure someone has done the work to create a more efficient algorithm for
this. Off the top of my head if I were trying to  I'd probably do something
like:

1. Grab two points at random (in case the points are pre-sorted in some
way) and get the distance.
2. Assume that's a reasonable average distance between points.
3. Define that as the number to beat, and define a grid based on it.
4. Go through all the points, tossing them into buckets based on the grid.
I'd define the buckets as fully overlapping to avoid missing close pairs.
5. The size of the grid buckets is critical: too big and you do too much
work. Too small and you end up with all singletons in the buckets. This
would require some experimentation and thought.
6. Go through the buckets only comparing the points within them.

On Fri, Jan 20, 2023 at 10:14 AM Alex Tweedly via use-livecode <
use-livecode@lists.runrev.com> wrote:

>
> On 20/01/2023 16:52, Mark Waddingham via use-livecode wrote:
> > On 2023-01-20 13:05, Alex Tweedly via use-livecode wrote:
> >> We need a better algorithm. If we use a "linear scan", we can change
> >> it from essentially Order(N**2) to approx Order(N).
> >
> > Slightly pedantic point (I appreciate that you did say 'approx')...
> >
> > Sorting can not be done in any less time than O(N*log N) - so the
> > revised algorithm is O(N*log N) as you have to sort the input for it
> > to be able to scan linearly.
> >
> I figured someone would pick me up on that :-) It was a pretty big
> 'approx' :\)
>
> The sorting step is indeed O(NlogN).
>
> And the rest of it also worse than linear, but I don't have the math
> knowledge to even begin to think about how much worse. Quick testing
> says it's worse than O(NlogN), and in practice, it might even be as bad
> as something like O(N * sqrt(N)), guessing about the number of points
> within a (variable) sized window to the right of the current scan coord.
>
> But in any "real app" usage that I can imagine, the 'clustering' effect
> would seem to improve it over O(N*sqrt(N)); e.g. if the points tend to
> cluster rather than be evenly randomly spread, then the number within
> the scan window goes down on average. "real app" could be players in a
> 1st person player game, or vehicles on a road simulation, or (in 3d)
> stars in the universe - in all cases causing the minDist to decrease
> faster than when they are evenly spread.
>
> 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: ChatGPT examples

[Geoff Canyon via use-livecode]

Whoa, TIL. Of course ChatGPT was easily able to make the substitution. I've
updated the doc.

gc

On Fri, Jan 20, 2023 at 9:46 AM Alex Tweedly via use-livecode <
use-livecode@lists.runrev.com> wrote:

> On 20/01/2023 15:55, Geoff Canyon via use-livecode wrote:
>
> > Responses inline:
> >
> > On Fri, Jan 20, 2023 at 5:06 AM Alex Tweedly via use-livecode <
> > use-livecode@lists.runrev.com> wrote:
> >
> > I thought of this -- especially since ChatGPT's first (python-esque)
> > example uses "inf" -- but what would you use as "infinity" in LiveCode?
> In
> > practice if I were coding and comfortable with it I'd probably just throw
> > in 9 and be done, but in the abstract, there are bigger numbers
> > allowed in LC, and I don't care to find the absolute largest -- plus it
> > would be some weird long string -- I think, I don't know off the top of
> my
> > head what the largest 64-bit value is.
>
> Just use the constant 'infinity'
>
> I think it was added fairly recently, but the dictionary doesn't say
> what version it first appeared in.
>
> 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: ChatGPT examples

[Alex Tweedly via use-livecode]

On 20/01/2023 16:52, Mark Waddingham via use-livecode wrote:

On 2023-01-20 13:05, Alex Tweedly via use-livecode wrote:

We need a better algorithm. If we use a "linear scan", we can change
it from essentially Order(N**2) to approx Order(N).


Slightly pedantic point (I appreciate that you did say 'approx')...

Sorting can not be done in any less time than O(N*log N) - so the 
revised algorithm is O(N*log N) as you have to sort the input for it 
to be able to scan linearly.


I figured someone would pick me up on that :-) It was a pretty big 
'approx' :\)


The sorting step is indeed O(NlogN).

And the rest of it also worse than linear, but I don't have the math 
knowledge to even begin to think about how much worse. Quick testing 
says it's worse than O(NlogN), and in practice, it might even be as bad 
as something like O(N * sqrt(N)), guessing about the number of points 
within a (variable) sized window to the right of the current scan coord.


But in any "real app" usage that I can imagine, the 'clustering' effect 
would seem to improve it over O(N*sqrt(N)); e.g. if the points tend to 
cluster rather than be evenly randomly spread, then the number within 
the scan window goes down on average. "real app" could be players in a 
1st person player game, or vehicles on a road simulation, or (in 3d) 
stars in the universe - in all cases causing the minDist to decrease 
faster than when they are evenly spread.


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: ChatGPT examples

[Alex Tweedly via use-livecode]

On 20/01/2023 15:55, Geoff Canyon via use-livecode wrote:


Responses inline:

On Fri, Jan 20, 2023 at 5:06 AM Alex Tweedly via use-livecode <
use-livecode@lists.runrev.com> wrote:

I thought of this -- especially since ChatGPT's first (python-esque)
example uses "inf" -- but what would you use as "infinity" in LiveCode? In
practice if I were coding and comfortable with it I'd probably just throw
in 9 and be done, but in the abstract, there are bigger numbers
allowed in LC, and I don't care to find the absolute largest -- plus it
would be some weird long string -- I think, I don't know off the top of my
head what the largest 64-bit value is.


Just use the constant 'infinity'

I think it was added fairly recently, but the dictionary doesn't say 
what version it first appeared in.


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: ChatGPT examples

[Mark Waddingham via use-livecode]

On 2023-01-20 13:05, Alex Tweedly via use-livecode wrote:

We need a better algorithm. If we use a "linear scan", we can change
it from essentially Order(N**2) to approx Order(N).


Slightly pedantic point (I appreciate that you did say 'approx')...

Sorting can not be done in any less time than O(N*log N) - so the 
revised algorithm is O(N*log N) as you have to sort the input for it to 
be able to scan linearly.


:D

Warmest Regards,

Mark.

--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Build Amazing Things

___
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: ChatGPT examples

[Bob Sneidar via use-livecode]

Doomed, like the guys who left their weapons behind ended up facing their own 
weapons later.

Bob S


On Jan 20, 2023, at 07:56 , Geoff Canyon via use-livecode 
mailto:use-livecode@lists.runrev.com>> wrote:

On Fri, Jan 20, 2023 at 6:57 AM Craig Newman via use-livecode <
use-livecode@lists.runrev.com> wrote:

Geoff.

Startling, and beautifully presented.

I had no idea ChatGPT was that powerful and knowledgeable.

We are doomed.

Craig


Doomed like the guys walking behind the horses were doomed by the
tractors...

___
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: ChatGPT examples

[Geoff Canyon via use-livecode]

On Fri, Jan 20, 2023 at 6:57 AM Craig Newman via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Geoff.
>
> Startling, and beautifully presented.
>
> I had no idea ChatGPT was that powerful and knowledgeable.
>
> We are doomed.
>
> Craig
>

Doomed like the guys walking behind the horses were doomed by the
tractors...
___
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: ChatGPT examples

[Geoff Canyon via use-livecode]

Responses inline:

On Fri, Jan 20, 2023 at 5:06 AM Alex Tweedly via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Fascinating. Thank you so much for that Geoff.
>
> I've been afraid to play with ChatGPT so far - too worried abut getting
> sucked in and spending way too much time 
>
> I did take a look at your third example (since I can never resist a
> performance challenge :-)
>
> There are a number of minor tweaks that could be made to improve
> performance
>
> 1. set initial value to infinity rather than calculating a distance
> between the first two points.
>

I thought of this -- especially since ChatGPT's first (python-esque)
example uses "inf" -- but what would you use as "infinity" in LiveCode? In
practice if I were coding and comfortable with it I'd probably just throw
in 9 and be done, but in the abstract, there are bigger numbers
allowed in LC, and I don't care to find the absolute largest -- plus it
would be some weird long string -- I think, I don't know off the top of my
head what the largest 64-bit value is.


> 2. "number of elements in pPoints" is unvarying within any one call - so
> extract it to a variable at the start
>

Good point. I did benchmark  "number of elements" -- ChatGPT's code;
against "item 2 of the extents of" -- what I would have done; and number of
elements is *much* faster.

>
> 3. use the square of the distance rather than the actual distance - save
> N**2 calls to sqrt
>

Nice!

>
> 4. use "DX * DX" rather than "DX ^ 2" (about 25% faster)
>

Really? Interesting, I'll have to check that.


> 5. calculate distance in-line rather than call a function
>

Yep, this is purely an artifact of how ChatGPT wrote it. But it would be
interesting to give it both chunks of code and say "merge this" and see if
it can pull that off. Thanks for the idea!

>
> but those all add up to maybe 10% performance improvement (or less - I
> didn't test it). That's useful - but not enough.
>
> For a modest number of points (2000 random points), this takes approx
> 16.5 seconds !!
>
> We need a better algorithm. If we use a "linear scan", we can change it
> from essentially Order(N**2) to approx Order(N).
>
> Summary:
>
>   - sort the points by X coordinate
>
>   - while scanning the inner loop, as soon as the difference in Xcoord
> from the 'outer' point exceeds the minDist so far, you can reject not
> just this point, but all subsequent points, and hence exit the inner
> loop immediately.
>
> This brings the time down from 16500 millisecs to 25 millisecs.
>
> BUT - I have no clue how I'd go about describing this to ChatGPT :-)
>
> NB I changed the input parameter to be the list of points rather than
> the array.
>

Fair point -- the array was entirely ChatGPT's choice, and I didn't
challenge it. I'll ask it to change and see what happens.

>
> Code:
>
> function closestPointsSQ pLines
> sort pLines by item 1 of each
> put pLines into pPoints
> split pPoints by CR
> put infinity into minDist
> put the number of elements in pPoints into N
> repeat with i = 1 to N-1
>repeat with j = i + 1 to N
>   put item 1 of pPoints[j] - item 1 of pPoints[i] into t1
>   if t1 * t1 > minDist then exit repeat
>   put item 2 of pPoints[j] - item 2 of pPoints[i] into t2
>   put t1 * t1 + t2 * t2 into dist
>   if dist < minDist then
>  put dist into minDist
>  put pPoints[i] & " " & pPoints[j] into closestPoints
>   else if dist = minDist then
>  put return & pPoints[i] & " " & pPoints[j] after closestPoints
>   end if
>end repeat
> end repeat
> return closestPoints
> end closestPointsSQ
>
> -- Alex.
>
> On 20/01/2023 06:02, Geoff Canyon via use-livecode wrote:
> > I tested three use cases, with variations, using ChatGPT for (live)code
> > generation. There was a lot of back and forth. In the end, I solved all
> the
> > problems I set, but in some cases I had to hold ChatGPT's hand pretty
> > tightly.
> >
> > That said, I learned some things as well -- about LiveCode. ChatGPT's
> code
> > for Fizz Buzz was faster than mine.
> >
> > My code was faster for reversing lines. But ChatGPT, when asked to "make
> > the code faster" gave several suggestions, some of which were wrong or
> > impossible, but one of them was my method, and when I said "write that
> > option" it did, with only a few corrections needed.
> >
> > And one of the ideas, while wrong, caused me to think of a different way
> to
> > solve the problem, and that way ended up being faster than my original
> > solution by over 3x on reversing 10k lines. Getting ChatGPT to write this
> > new method was *hard*.
> >
> > In any case, I wrote it all down in a google doc
> > <
> https://docs.google.com/document/d/1W3j5WaFhYZaqSt0ceRQj8j160945gSwG_nyZsCBP6v4/edit?usp=sharing
> >.
> > If you're curious, have a read. That URL is open for comments/edit
> > suggestions. If you have any I'd love to hear them.
> 

Re: ChatGPT examples

[Craig Newman via use-livecode]

Geoff.

Startling, and beautifully presented.

I had no idea ChatGPT was that powerful and knowledgeable.

We are doomed.

Craig

> On Jan 20, 2023, at 8:05 AM, Alex Tweedly via use-livecode 
>  wrote:
> 
> Fascinating. Thank you so much for that Geoff.
> 
> I've been afraid to play with ChatGPT so far - too worried abut getting 
> sucked in and spending way too much time 
> 
> I did take a look at your third example (since I can never resist a 
> performance challenge :-)
> 
> There are a number of minor tweaks that could be made to improve performance
> 
> 1. set initial value to infinity rather than calculating a distance between 
> the first two points.
> 
> 2. "number of elements in pPoints" is unvarying within any one call - so 
> extract it to a variable at the start
> 
> 3. use the square of the distance rather than the actual distance - save N**2 
> calls to sqrt
> 
> 4. use "DX * DX" rather than "DX ^ 2" (about 25% faster)
> 
> 5. calculate distance in-line rather than call a function
> 
> but those all add up to maybe 10% performance improvement (or less - I didn't 
> test it). That's useful - but not enough.
> 
> For a modest number of points (2000 random points), this takes approx 16.5 
> seconds !!
> 
> We need a better algorithm. If we use a "linear scan", we can change it from 
> essentially Order(N**2) to approx Order(N).
> 
> Summary:
> 
>  - sort the points by X coordinate
> 
>  - while scanning the inner loop, as soon as the difference in Xcoord from 
> the 'outer' point exceeds the minDist so far, you can reject not just this 
> point, but all subsequent points, and hence exit the inner loop immediately.
> 
> This brings the time down from 16500 millisecs to 25 millisecs.
> 
> BUT - I have no clue how I'd go about describing this to ChatGPT :-)
> 
> NB I changed the input parameter to be the list of points rather than the 
> array.
> 
> Code:
> 
> function closestPointsSQ pLines
>sort pLines by item 1 of each
>put pLines into pPoints
>split pPoints by CR
>put infinity into minDist
>put the number of elements in pPoints into N
>repeat with i = 1 to N-1
>   repeat with j = i + 1 to N
>  put item 1 of pPoints[j] - item 1 of pPoints[i] into t1
>  if t1 * t1 > minDist then exit repeat
>  put item 2 of pPoints[j] - item 2 of pPoints[i] into t2
>  put t1 * t1 + t2 * t2 into dist
>  if dist < minDist then
> put dist into minDist
> put pPoints[i] & " " & pPoints[j] into closestPoints
>  else if dist = minDist then
> put return & pPoints[i] & " " & pPoints[j] after closestPoints
>  end if
>   end repeat
>end repeat
>return closestPoints
> end closestPointsSQ
> 
> -- Alex.
> 
> On 20/01/2023 06:02, Geoff Canyon via use-livecode wrote:
>> I tested three use cases, with variations, using ChatGPT for (live)code
>> generation. There was a lot of back and forth. In the end, I solved all the
>> problems I set, but in some cases I had to hold ChatGPT's hand pretty
>> tightly.
>> 
>> That said, I learned some things as well -- about LiveCode. ChatGPT's code
>> for Fizz Buzz was faster than mine.
>> 
>> My code was faster for reversing lines. But ChatGPT, when asked to "make
>> the code faster" gave several suggestions, some of which were wrong or
>> impossible, but one of them was my method, and when I said "write that
>> option" it did, with only a few corrections needed.
>> 
>> And one of the ideas, while wrong, caused me to think of a different way to
>> solve the problem, and that way ended up being faster than my original
>> solution by over 3x on reversing 10k lines. Getting ChatGPT to write this
>> new method was *hard*.
>> 
>> In any case, I wrote it all down in a google doc
>> .
>> If you're curious, have a read. That URL is open for comments/edit
>> suggestions. If you have any I'd love to hear them.
>> 
>> Thanks!
>> 
>> Geoff
>> ___
>> 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: ChatGPT examples

[Alex Tweedly via use-livecode]

Fascinating. Thank you so much for that Geoff.

I've been afraid to play with ChatGPT so far - too worried abut getting 
sucked in and spending way too much time 


I did take a look at your third example (since I can never resist a 
performance challenge :-)


There are a number of minor tweaks that could be made to improve performance

1. set initial value to infinity rather than calculating a distance 
between the first two points.


2. "number of elements in pPoints" is unvarying within any one call - so 
extract it to a variable at the start


3. use the square of the distance rather than the actual distance - save 
N**2 calls to sqrt


4. use "DX * DX" rather than "DX ^ 2" (about 25% faster)

5. calculate distance in-line rather than call a function

but those all add up to maybe 10% performance improvement (or less - I 
didn't test it). That's useful - but not enough.


For a modest number of points (2000 random points), this takes approx 
16.5 seconds !!


We need a better algorithm. If we use a "linear scan", we can change it 
from essentially Order(N**2) to approx Order(N).


Summary:

 - sort the points by X coordinate

 - while scanning the inner loop, as soon as the difference in Xcoord 
from the 'outer' point exceeds the minDist so far, you can reject not 
just this point, but all subsequent points, and hence exit the inner 
loop immediately.


This brings the time down from 16500 millisecs to 25 millisecs.

BUT - I have no clue how I'd go about describing this to ChatGPT :-)

NB I changed the input parameter to be the list of points rather than 
the array.


Code:

function closestPointsSQ pLines
   sort pLines by item 1 of each
   put pLines into pPoints
   split pPoints by CR
   put infinity into minDist
   put the number of elements in pPoints into N
   repeat with i = 1 to N-1
  repeat with j = i + 1 to N
 put item 1 of pPoints[j] - item 1 of pPoints[i] into t1
 if t1 * t1 > minDist then exit repeat
 put item 2 of pPoints[j] - item 2 of pPoints[i] into t2
 put t1 * t1 + t2 * t2 into dist
 if dist < minDist then
    put dist into minDist
    put pPoints[i] & " " & pPoints[j] into closestPoints
 else if dist = minDist then
    put return & pPoints[i] & " " & pPoints[j] after closestPoints
 end if
  end repeat
   end repeat
   return closestPoints
end closestPointsSQ

-- Alex.

On 20/01/2023 06:02, Geoff Canyon via use-livecode wrote:

I tested three use cases, with variations, using ChatGPT for (live)code
generation. There was a lot of back and forth. In the end, I solved all the
problems I set, but in some cases I had to hold ChatGPT's hand pretty
tightly.

That said, I learned some things as well -- about LiveCode. ChatGPT's code
for Fizz Buzz was faster than mine.

My code was faster for reversing lines. But ChatGPT, when asked to "make
the code faster" gave several suggestions, some of which were wrong or
impossible, but one of them was my method, and when I said "write that
option" it did, with only a few corrections needed.

And one of the ideas, while wrong, caused me to think of a different way to
solve the problem, and that way ended up being faster than my original
solution by over 3x on reversing 10k lines. Getting ChatGPT to write this
new method was *hard*.

In any case, I wrote it all down in a google doc
.
If you're curious, have a read. That URL is open for comments/edit
suggestions. If you have any I'd love to hear them.

Thanks!

Geoff
___
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: ChatGPT examples

[Heather Laine via use-livecode]

Geoff...

Wow. Pretty please, can I have permission to turn that document into a blog 
post? It's fantastic and deserves to reach a wider audience.

Best Regards,

Heather

Heather Laine
Customer Services Manager
LiveCode Ltd
www.livecode.com



> On 20 Jan 2023, at 06:02, Geoff Canyon via use-livecode 
>  wrote:
> 
> I tested three use cases, with variations, using ChatGPT for (live)code
> generation. There was a lot of back and forth. In the end, I solved all the
> problems I set, but in some cases I had to hold ChatGPT's hand pretty
> tightly.
> 
> That said, I learned some things as well -- about LiveCode. ChatGPT's code
> for Fizz Buzz was faster than mine.
> 
> My code was faster for reversing lines. But ChatGPT, when asked to "make
> the code faster" gave several suggestions, some of which were wrong or
> impossible, but one of them was my method, and when I said "write that
> option" it did, with only a few corrections needed.
> 
> And one of the ideas, while wrong, caused me to think of a different way to
> solve the problem, and that way ended up being faster than my original
> solution by over 3x on reversing 10k lines. Getting ChatGPT to write this
> new method was *hard*.
> 
> In any case, I wrote it all down in a google doc
> .
> If you're curious, have a read. That URL is open for comments/edit
> suggestions. If you have any I'd love to hear them.
> 
> Thanks!
> 
> Geoff
> ___
> 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

ChatGPT examples

[Geoff Canyon via use-livecode]

I tested three use cases, with variations, using ChatGPT for (live)code
generation. There was a lot of back and forth. In the end, I solved all the
problems I set, but in some cases I had to hold ChatGPT's hand pretty
tightly.

That said, I learned some things as well -- about LiveCode. ChatGPT's code
for Fizz Buzz was faster than mine.

My code was faster for reversing lines. But ChatGPT, when asked to "make
the code faster" gave several suggestions, some of which were wrong or
impossible, but one of them was my method, and when I said "write that
option" it did, with only a few corrections needed.

And one of the ideas, while wrong, caused me to think of a different way to
solve the problem, and that way ended up being faster than my original
solution by over 3x on reversing 10k lines. Getting ChatGPT to write this
new method was *hard*.

In any case, I wrote it all down in a google doc
.
If you're curious, have a read. That URL is open for comments/edit
suggestions. If you have any I'd love to hear them.

Thanks!

Geoff
___
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