[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]
**********************************************************************