http://wiki.nars2000.org/api.php?action=feedcontributions&user=Fran%C3%A7ois-Dominique+Armingaud&feedformat=atomNARS2000 - User contributions [en]2024-03-28T12:34:35ZUser contributionsMediaWiki 1.38.4http://wiki.nars2000.org/index.php?title=Associative_indexing&diff=2167Associative indexing2013-11-24T21:58:47Z<p>François-Dominique Armingaud: typos</p>
<hr />
<div><br />
== Associative indexing ==<br />
<br />
Most contemporary language have '''associative indexing''' because most applications need it in some way or some other : we live in a world of tags as much as in a world of numbers. So in Perl or PHP you can index any array with a key instead of just an integer (Perl needs to introduce {} for associative arrays, but PHP does not).<br />
<br />
While allowing A['Jones' 'Smith' 'Martin'] just as well as A[1 3 2] would ask for some further definition of what the monadic rho function returns for such arrays, I have the feeling any syntax extension ''would have no effect at all on existing programs using only integer indexing''. What would be needed in the implementation is just an additional 2-bit type in the descriptor telling if the corresponding variable is indexed <br />
<br />
# just numerically<br />
# just alphamerically<br />
# mixed<br />
<br />
In the case of arrays of arrays, of course, that would need further definition, though each array in the description has it own descriptor too.<br />
<br />
That is just a "partly-baked idea", not an implementation proposal yet, much less a contribution to the code (I only arrived today ans have not looked to the code yet); but just imagine how writing agile applications in APL (or NARS) would be easier to use with this associative indexing facility.<br />
<br />
Back to [[Project Ideas]]</div>François-Dominique Armingaudhttp://wiki.nars2000.org/index.php?title=Associative_indexing&diff=2166Associative indexing2013-11-24T21:56:05Z<p>François-Dominique Armingaud: </p>
<hr />
<div><br />
== Associative indexing ==<br />
<br />
Most contemporary language have '''associative indexing''' because most applications need it in some way or some other : we live in a world of tags as much as in a world of numbers. So in Perl or PHP you can index any array with a key instead of just an integer (Perl needs to introduce {} for associative arrays, but PHP does not).<br />
<br />
While allowing A['Jones' 'Smith' 'Martin'] just as well as A[1 3 2] would ask for some further definition of what the monadic rho function returns for such arrays, I have the feeling any syntax extension ''would have no effect at all on existing programs using only integer indexing''. What would be needed in the implementation is just an additional 2-bit type in the descriptor telling if the corresponding variable is indexed <br />
<br />
# just numerically<br />
# just alphamerically<br />
# mixed<br />
<br />
In the case of arrays of arrays, of course, that would need further definition, though each array in the description has it own descriptor too.<br />
<br />
That is juste a "partly-baked idea", not an implementation proposal yet, much less a contribution to the code (I only arrived today ans have not looked to the code yet); but just imagine how writing agile applications in APL (or NARS) would be easier to use with this associative indexing facility.<br />
<br />
Back to [[Project ideas]]</div>François-Dominique Armingaudhttp://wiki.nars2000.org/index.php?title=Associative_indexing&diff=2165Associative indexing2013-11-24T21:54:14Z<p>François-Dominique Armingaud: Easy associative indexing without perturbation of existing APL programs</p>
<hr />
<div><br />
== Associative indexing ==<br />
<br />
Most contemporary language have '''associative indexing''' because most applications need it in some way or some other : we live in a world of tags as much as in a world of numbers. So in Perl or PHP you can index any array with a key instead of just an integer (Perl needs to introduce {} for associative arrays, but PHP does not).<br />
<br />
While allowing A['Jones' 'Smith' 'Martin'] just as well as A[1 3 2] would ask for some further definition of what the monadic rho function returns for such arrays, I have the feeling any syntax extension ''would have no effect at all on existing programs using only integer indexing''. What would be needed in the implementation is just an additional 2-bit type in the descriptor telling if the corresponding variable is indexed <br />
<br />
# just numerically<br />
# just alphamerically<br />
# mixed<br />
<br />
In the case of arrays of arrays, of course, that would need further definition, though each array in the description has it own descriptor too.<br />
<br />
That is juste a "partly-baked idea", not an implementation proposal yet, much less a contribution to the code (I only arrived today ans have not looked to the code yet); but just imagine how writing agile applications in APL (or NARS) would be easier to use with this associative indexing facility.</div>François-Dominique Armingaudhttp://wiki.nars2000.org/index.php?title=Project_Ideas&diff=2164Project Ideas2013-11-24T21:38:16Z<p>François-Dominique Armingaud: Asssociative indexing (if not already treated elsewhere; I am just a newbie)</p>
<hr />
<div>In case you are looking for how to get your feet wet, here are some ideas (in no particular order) to consider implementing:<br />
<br />
* [[Partition Operator]]<br />
* [[Power Operator]]<br />
* [[Dual Operator]]<br />
* [[Convolution Operator]]<br />
* [[Other System Functions]]<br />
* [[File Systems]]<br />
* [[Trace/Stop Controls]]<br />
* [[Complex Numbers]]<br />
* [[Hypercomplex Numbers]]<br />
* [[Unicode Support]]<br />
* [[Extensible Datatypes]]<br />
* [[Dynamic Functions]]<br />
* [[Line Continuation Marker]]<br />
* [[Shared Variables]]<br />
* [[Associative indexing]]</div>François-Dominique Armingaudhttp://wiki.nars2000.org/index.php?title=User:Fran%C3%A7ois-Dominique_Armingaud&diff=2163User:François-Dominique Armingaud2013-11-24T21:34:43Z<p>François-Dominique Armingaud: 1) How to type a "[" or "]" on a Fench keyboard ? 2) Question about possible associative indexing (hashs) in APL like in Perl, but with no { } needed.</p>
<hr />
<div>APL : officially "A Programming Language", colloquially, "Array Processing Language" (though Octave and GNU R are too)<br />
NARS<br />
<br />
NARS : Nested Arrays Research System<br />
<br />
I switched away from APL because every application I wrote needed a lot of associative access, that APL did not allow very gracefully, so I went to Perl. Also used PHP 5 and Regina REXX and I came here to see whether NARS had that possibility. However my first worry is how to make [ and ] appear with the French Keyboard. Normally [ is AltGr-5 and ] is AltGr-) : none of them seem to generate anything, unless I goofed somewhere.<br />
<br />
Here is what is said on the French language Wikipedia about APL :<br />
<br />
"APL n’a jamais officiellement connu les [[table associative|tables associatives]], indexant un tableau avec autre chose que des valeurs entières. On ne peut donc pas écrire :<br />
<br />
''CAPITALE[⊂'FRANCE']←⊂'PARIS'<br />
<br />
ou, pour rester dans le vectoriel,<br />
<br />
''CAPITALE['FRANCE' 'ESPAGNE' 'ITALIE']←'PARIS' 'MADRID' 'ROME'''<br />
<br />
ce qui est regrettable, car :<br />
<br />
# une telle extension ne demanderait que très peu de modification de syntaxe, et n'en demanderait ''aucune'' des programmes existants<br />
# les langages modernes permettent l'indexation par des chaînes de caractères (soit l'indexation des tableaux comme en [[PHP]] qui autorise à écrire ''$capitale['France']='Paris';'', soit via des objets voisins comme les ''[[table de hachage|tables de hachage]]'' en [[Perl (langage)|Perl]]<ref>''$capitale{'France'}='Paris';''</ref>).<br />
# rares sont les applications où il ne faille pas gérer des accès par symboles plutôt que par numéros. Si APL ne le permet pas de façon immédiate, l’utilisateur se tourne naturellement vers d’autres langages répondant mieux à ses besoins.<br />
<br />
Il est peu ergonomique de contourner cette lacune au prix de variables supplémentaires, comme par exemple:<br />
''FRANCE←32'' (dès lors, ''CAPITALE[FRANCE]←⊂"PARIS"''. Si le pays provient d'une saisie, l'indice peut être retrouvé par "execute" : ''⍎"FRANCE"'' qui rend 32, mais l'application perd en robustesse et on encombre inutilement la table des symboles (APL/X contourne la difficulté par des ''namespaces'').<br />
<br />
Une autre manière est de définir un vecteur des noms de pays :<br />
''PAYS ←'BELGIQUE' 'FRANCE' '', l'instruction devenant alors :<br />
''CAPITALE[PAYS⍳⊂'FRANCE']←⊂'PARIS' ''<br />
<br />
Mais en ce cas, indépendamment de la lisibilité plus faible, le temps d'accès n'a plus le moindre rapport avec un accès direct de type "hash" en [[Perl (langage)|Perl]] ou PHP, surtout si s'il y a des centaines de noms.<br />
<br />
Non seulement la lisibilité des programmes n'y gagne rien, mais leur facilité de maintenance s'effondre compte tenu des variables ''surajoutées''.</div>François-Dominique Armingaud