[JPR]

Hi David, Tim, and others,

It seems that January is the time for flooding the street with flowers ;-)

Let's try to make a long story short: When I came back to 4D, I met (for the 
1st time) Keisuke in Vegas. I was very happy to meet him, for he is an absolute 
Wizard in programming, and I was so happy to read his postings on the NUG, 
always enlightened by the simplicity and elegance of his code. He came to me 
and told me : "You know, you're a legend". If it is probably very positive to 
be a legend when you're dead (in fact, I don't know, I've to ask: Hey Walt ? 
How do you feel being a dead legend?) it is extremely difficult to be an alive 
legend, for you can only disappoint your fans...

In fact, I think my role on the NUG is not to jump into every questions with my 
solutions. I see the NUG as a place where everyone can expose their problems 
and solutions. And there is no such a thing as a stupid solution. An answer 
that look stupid may be a prefect solution to a problem under different 
conditions. I've often observed that many developers do not dare to expose 
their solution for being afraid to be ashamed by a far better one, like a 
tenderfoot wouldn't draw in front of a sharpshooter. I consider that my job is 
to help you to understand, not to solve your problems. I will not give you 
fishes, but I'm happy to explain where and how is the best fishing. Most of the 
time, as soon as you've got a perfect understanding of the underlying 
mechanism, you get easily to the proper solution.

So when you want explanations about the internal mechanism of a command in 4D, 
just put JPR in the mail, and I will do my best to explain how it works.

Let's take a simple example: A recent post is "Best way to find something in an 
array of objects". Let's analyse this topic. Do I know the Best Way? Do I have 
the answer to this question? Yes, of course! Do you want to know it? Trivial! 
The answer is "It depends..."

It depends on many things, and there are many questions to answer to before 
being close to the solution.

- What do you mean by "Best way"? The easiest one? The fastest one to program? 
The most efficient one? The most efficient is probably to mimic the way LR has 
programmed the Object Indexes. But this is NOT the easiest one, I can guarantee 
you...

- What means 'fast'? I don't know what means Fast or Slow. The only remark I 
got during my life was "Too slow". (Funny, but I never got a "Too fast" 
comment...) If it works in an acceptable way, then the best way will probably 
be the easiest one.

- Where is the original Data, the one used to fill the array? If it is in a 
Table, it's probably easier to Query the table than to "Find in object array". 
Also, you can get the content of each path with the DISTINCT ATTRIBUTE PATH and 
DISTINCT ATTRIBUTE VALUES commands, which may help to reduce the Query field.

- The only way to optimise the Find in array is to sort the array. What sorting 
algorithm will you use? Is there a prefect one? Quicksort? Or Merge sort, 
Heapsort, Bubble sort, Shellsort, Comb sort, Bucket sort, Radix sort? Do you 
think that if one was clearly better than others, it would still be so many 
algorithms? Probably not. Just because, here also, it depends...

- You can see an Object as a Key-Value Store (which it is, in fact). But where 
do you want to find? In any place? In a specific property? Including the 
property name? Case-sensitive or not? Using Fuzzy logic or not? Is each Object 
in your Object Array consistent with the others or not? 

- Can you sort your array? Sometimes, the index of an element in an array codes 
for some information (record number, grid line, etc.) and you can't sort it. Or 
you have to create an array with the index of the elements and sort 2 arrays in 
parallel. But in this case, what about memory? Or sorting time? I had to deal 
with 20-million element array, did you try one to sort such a big one?

- Is it not better to use another object as an associative array? For instance, 
if you want to get instantly a Product Name from a Product Code, the 
traditional 4D way is to create the array with a loop...

$k:=Find in array($arCodes;$myCode)
If ($k>0)
     $arNames{$k}:=$myName
Else
     APPEND TO ARRAY($arCodes;$myCode)
     APPEND TO ARRAY($arNames;$myName)
End if

 ...and to find with:

$k:=Find in array($arCodes;$myCode)
If ($k>0)
     $myName:=$arNames{$k}
Else
     $myName:=""
End if

 What about an Object used as an associative array:

C_OBJECT($myArray)
You create the array with a loop...

OB SET($myArray;myCode;$myName)

...and you find with:

$myName:=OB Get($myArray;$myCode}

This is much faster. Why? Because 4D uses internally a Hash table for the 
property names, so finding a property in a big object is not a problem of speed.

- Another good question to ask is regarding the unicity of the key. The 
solution above is possible only because the Product Code is unique.

- When you have to deal with huge unsorted arrays, you may think to use a Hash 
function in order to divide your monster array into an array of smaller arrays 
(i.e. a 2D array in 4D). For example, I put my 20-million element array into a 
10,000 * 2,000 2-D array. The mechanism is simple: To add an element...

$colNb:=MyHashFunction ($myElement;10000)
APPEND TO ARRAY(MyArray{$colNb};$myElement)

...and to find an Element:

$found:=Find in array(myArray{MyHashFunction ($myElement;10000)};$value2Find)
(A more optimised version of this code is available during the trainings, and I 
will be happy to sent it to anyone who may need it)

The Hash Function can be anything from a simple Modulo to a CRC16, as long as 
it returns a number between 0 and 10,000.

- And many other questions like this...

As you can see, there is no Single Perfect Magic Answer. For me, an answer is 
good as long as it works and makes a Happy User.

So, Guys, I will be always happy to answer to any questions you may have, 
provided that you begin by searching a solution by yourself and inside the NUG, 
and I will answer everytimes you will put JPR somewhere in your post.

And I will continue to bring deep explanations during trainings, as you will 
see during the Tour 2017. A big part of my job is (because I'm lucky enough to 
work very closely with L.R., L.E., and the rest of the Team) is :

- to break some new programming ground and to find the easiest path for you to 
adapt, as safely and painlessly as possible, your actual code and the new tools.
- to try to give you a good orientation to move in a way that will be the most 
adapted to the future versions.
- to help you to solve the problems you may have by explaining the way it works 
internally in 4D.

And this is enough to fill my time schedule to the upper limit...

My very best,

JPR

> On 07 Jan 2017, at 21:00, [email protected] wrote:
> 
>  Hey, JPR - let me join in in asking for some ideas from you.
> You've got an interesting perspective, a long history, have been presenting
> about this for some time and usually have really cool demos. So, chime in!
> I hope that Thomas does this time, too and that he does more videos.

**********************************************************************
4D Internet Users Group (4D iNUG)
FAQ:  http://lists.4d.com/faqnug.html
Archive:  http://lists.4d.com/archives.html
Options: http://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:[email protected]
**********************************************************************

Reply via email to