Julia: Benennen Sie `shift!` und `unshift!` um?

Wir könnten eine umfassende Umbenennung dieser Funktionen vornehmen:

| alt | neu |
|-----|-----|
| push! | rpush! |
| pop! | rpop! |
| unshift! | lpush! |
| shift! | lpop! |

Oder ein links/rechts (Start/Ende? erstes/letztes?) Keyword, wenn Performance-Probleme gelöst werden konnten

Links und rechts wirken etwas zweideutig; vielleicht wäre die Vorder-/Rückseite von @c42f oder etwas Ähnliches klarer?

Ich bin mir nicht sicher, ob vorne und hinten klarer sind als links und rechts. Natürlich ist es für die Links/Rechts-Terminologie etwas schade, dass wir Vektoren vertikal drucken, aber vorne/hinten sind in dieser Hinsicht nicht besser.

Oh, und wir verwenden bereits l und r für links und rechts in Reduktionen, also gibt es einen Präzedenzfall – es sei denn, wir wollen diese auch ändern.

Ich bin mir nicht sicher, ob vorne und hinten klarer sind als links und rechts.

Ich bin mir auch nicht sicher. front verbindet sich mit niedrigeren Indizes (wie Base.front ) und back mit höheren Indizes, aber ich bin mir sicher, dass diese Art der Assoziation variiert.

Vielleicht bessere Ideen: head - tail und first - last scheinen angesichts ihrer bereits vorhandenen Bedeutungen deutlich weniger zweideutig zu sein?

Die Namen hpush! , hpop! , tpush! und tpop! sind nicht schlecht. Allerdings assoziieren wir bereits links und rechts mit der Anordnung von Arrays in foldl und foldr usw. Eigentlich, da diese die l und r am Ende, die analogen Namen sind pushl! , popl! , pushr! und popr! was mir irgendwie Spaß macht :)

Von den bisherigen Möglichkeiten zum Umbenennen aller vier Funktionen erscheinen mir die Suffix-Versionen pushl! , popl! , pushr! und popr! besten.

Ich habe jedoch einige Vorbehalte, push! und pop! umzubenennen. Ziehen Sie beispielsweise das Pushen und Popping in eine Prioritätswarteschlange in Betracht. In diesem Fall gibt es kein "rechts" und "links", es gibt nur eine natürliche Reihenfolge und eine Datenstruktur, die das kleinste/größte Element zurückgibt. Es gibt auch die Version von pop! die einen Schlüssel für die Verwendung mit wörterbuchähnlichen Datenstrukturen benötigt, und popr! würde in diesem Fall auch als Verb nicht viel Sinn machen.

Ich denke, push! und pop! können bleiben und von PriorityQueues verwendet werden. Sie können auch nur die Alias pushr! und popr! für Arrays verwenden.

Ich liebe shift! & unshift! , genauso ist es mit Javascript. Bitte reservieren Sie dies!

Bisher gefällt mir der Vorschlag des ersten Posts am besten.

Ich denke, es ist gut, die Namen push*! und pop*! verwenden, um die Ähnlichkeit zwischen den Varianten hervorzuheben und damit die Varianten durch Tabulatorvervollständigung leicht gefunden werden können. (Ich mag den Vorschlag l Suffixe r und l .)

-2 bis r und l Terminologie. Die Namen sind ein bisschen hässlich, und es gibt 4 davon. Ich würde lieber nur Shift umbenennen und wieder aufheben, wie das OP vorschlägt. Aber ich habe auch das Gefühl, dass Shift und Unshift so weit verbreitet sind, dass wir sie genauso gut behalten können. Es wäre bedauerlich, Begriffe einzuführen, die sonst niemand für so unglaublich häufige Operationen verwendet.

@JeffBezanson C++-Vektor verwendet push_front , daher gibt es dafür einige Präzedenzfälle.

Ich gehe davon aus, dass die vorhandenen Namen auf das in shift eingebaute sh , und vermutlich hat Perl dies aufgegriffen und unshift erfunden (http://www.perlmonks.org /?node_id=613144) Andere Sprachen (php, Javascript, ...?) folgten, so dass es viele Präzedenzfälle gibt.

Ich bevorzuge richtige englische Wörter... :) ( unshift steht in der OED aus dem Jahr 1972.)

oder erwähnen Sie zumindest shift! & unshift! im Dokument von pop! & push! :

help?> pop!
search: pop! popdisplay apropos deepcopy precompile __precompile__ peakflops promote_type
also see: `shift!` `unshift!` `push!`

  pop!(collection, key[, default])

  Delete and return the mapping for key if it exists in collection, otherwise return default, or
  throw an error if default is not specified. 

Eine andere Idee: push/pop!(first, x, ...) und push/pop!(last, x, ...) .

Theoretisch lässt sich diese Syntax gut auf Dinge wie pop!(min, x) verallgemeinern.

oder erwähnen Sie zumindest shift! & unshift! im Dokument von pop! & push! :

Im Zusammenhang mit #23789

Coole Idee, @TotalVerb!

Oder mit splice! / insert! , mit first und last als Pseudoindizes zusammenführen?

Eine andere Idee: push/pop!(first, x, ...)

Ach was? Ok, das ist eine wirklich kreative Idee :-)

Es erscheint ziemlich seltsam, die Funktionen first und last nur als Syntax zu verwenden, anstatt etwas mit dem eigentlichen Code in ihnen zu tun zu haben. Es ist irgendwie großartig, aber ich bin mir nicht sicher, ob so etwas im Ökosystem gefördert werden sollte, da es zu seltsamen Verwicklungen führen kann? Wenn Sie zum Beispiel schon immer Funktionen umbenennen wollten, die als Syntax verwendet wurden, was dann? Zugegeben für first und last unwahrscheinlich, aber trotzdem.

Ich muss sagen, so cool ich diese Idee auch finde – sie erinnert mich an die Idee von @mbauman , Reduktionsfunktionen bei der Indizierung zu verwenden, wie in X[mean, :, sum] – ich finde sie zu ausgefallen für eine so grundlegende Operation. Ich denke, die Optionen, die ich an dieser Stelle befürworte, sind:

1. Lassen Sie die Dinge so, wie sie sind – zweifelhaft wie "shift" und "unshift" auch sind, sie sind ziemlich Standard.
2. Benennen Sie shift! und unshift! in popl! und pushl! .
3. Benennen Sie zusätzlich zu 2 pop! und push! in popr! und pushr! .
4. Erstellen Sie zusätzlich zu 3 die Aliase pop! und push! für popr! und pushr! .

Ich bin größtenteils zwischen 1 und 2, aber es gibt auch einen Reiz für 3 und 4.

Ich denke, dass 1) es sehr sinnvoll ist, dass das Anwenden der gleichen Operation (Pushen oder Popping) auf den Anfang und das Ende eines Arrays zumindest verwandte Namen haben sollte; push! und shift! sind ein nicht intuitives Paar; 2) das Wort shift! kann mit Bitverschiebung >> verwechselt werden, wie man leicht erkennen kann, wenn man in den Dokumenten nach "shift" sucht; 3) viele Julia-Benutzer haben sowieso keinen Perl-/Javascript-Hintergrund.
Ich befürworte daher Option 2 im obigen Beitrag.
Aber wenn wir sie umbenennen, was tun mit circshift! ?

Stefans Option 2 oder 4 scheint mir gut zu sein. Ich glaube nicht, dass sich circshift! ändern muss, weil es keine pop ähnliche Operation ist

Vorschlag:

| alt | neu | Aliase |
|----:|----:|----:|
| push! | pushr! | push! |
| pop! | popr! | pop! |
| unshift! | pushl! | |
| shift! | popl! | |

Ich muss sagen, das ist verlockend, vor allem, wenn wir push! und pop! als Aliase für die Fälle beibehalten, in denen Sie eine Struktur nur als Stapel verwenden und sich nicht wirklich darum kümmern, ob es die linke ist oder rechts drückst du hin und her.

Imo mit front und back sind (deutlich) klarer als die Abkürzungen von left und right .

Zumal unsere Vektoren vertikal sind (also oben/unten sein sollten) 🙂. Andere Optionen können Start/Ende oder erste/letzte sein.

links/rechts scheint mir in Ordnung; es stimmt mit unserer Reduktionsterminologie überein ( foldl und foldr ) und damit, wie Vektoren normalerweise in [a,b,c,…] eingegeben und mit print ausgegeben werden.

Das andere Schöne an links/rechts ist, dass es eine etablierte einstellige Abkürzung hat.

Im Ernst, ich weiß nicht, welches Ende eines Vektors vorne oder hinten ist. Ist der vordere Index 1 oder ist das der hintere? Ja, wir drucken unsere Vektoren manchmal vertikal, aber in anderen Fällen auch von links nach rechts. Wir verwenden bereits konsequent die vererbte Links-/Rechtsbenennung für viele andere Funktionen.

Wie wäre es, einfach neue Methoden zum Anhängen zu haben! und voranstellen! wobei das zweite Argument ein Skalar ist?

Diese Konversation ist wieder zu https://github.com/JuliaLang/julia/issues/23902#issuecomment-332615200 zurückgekehrt, was wiederum zu https://github.com/JuliaLang/julia/issues/23902#issuecomment-332668546 führt , dh entweder head / tail oder first / last Terminologie? :)

Ups, sorry für die Verlängerung der Diskussion. Mein Punkt war, dass wir, anstatt neue Wörter zu erfinden, bestehende wiederverwenden sollten.

Ups, sorry für die Verlängerung der Diskussion. Mein Punkt war, dass wir, anstatt neue Wörter zu erfinden, bestehende wiederverwenden sollten.

Entschuldigung @phaverty! Wir simulieren. Meine Antwort sollte @StefanKarpinski folgen, anstatt Ihren Kommentar zu kommentieren :). Am besten!

Am besten gefallen mir popfirst! , pushfirst! , poplast! , pushlast! mit pop! und push! als Aliase für die beiden Letztere.

wobei das zweite Argument ein Skalar ist?

Es ist nicht möglich, Skalar generisch zu definieren.

"Es ist nicht möglich, Skalar generisch zu definieren."

Ah ich sehe. Sie könnten beispielsweise angeben,

anhängen!( x::Vektor{T}, y::T )

, aber Sie möchten wirklich, dass y "etwas ist, das in T umgewandelt werden kann". Aber das Typsystem weiß (noch?) nicht, welche Typen von Typen konvertiert werden können. Schade.

Lassen Sie uns (unverbindlich, informativ) abstimmen:

• 👍 für pushr! , popr! , pushl! und popl! mit push! und pop! als Aliase für die ersten beiden
• 👎 dafür, dass die Dinge so bleiben, wie sie sind
• 😕 für eine andere Option

Diese Wahl der Emojis ist etwas voreingenommen ;).

Und :+1: auf OPs Vorschlag, wenn dir das am besten gefällt ;)

Ich habe ein paar Gedanken darüber, diese Funktionen umzubenennen, also entschuldige ich mich im Voraus dafür, dass ich möglicherweise etwas Rauschen in dieses Gespräch aufgenommen habe. Bisher sind Julias Namen von push! , pop! , shift! und unshift! die gleichen wie Perl, Ruby und JavaScript (https://en .wikipedia.org/wiki/Double-ended_queue#Operations). Persönlich stören mich diese Namen nicht, da ich sie ursprünglich in Perl gelernt habe, aber ich gebe voll und ganz zu, dass Shift/Unshift nicht einprägsam ist. Es scheint auch ein Lager zu geben, das denkt , dass

Eine andere Idee: push/pop!(first, x, ...) und push/pop!(last, x, ...) .

Wenn wir in diese Richtung gehen würden, würde ich vorschlagen, dass wir enqueue! und dequeue! als Namen dieser Funktionen verwenden.

Was ich an den Originalnamen mag, ist, dass sie nur ein Wort verwenden. In dem Versuch, mich bei einem Wort zu halten, aber ein paar nettere Paarungen zu machen, kam ich auf push! und pull! für FIFO und push! und pop! für FILO. Dadurch würde Push/Pop am Anfang einer Warteschlange statt am Ende funktionieren:

Alt | Neu
-------|-----
drücken! | stellen!
Pop! | ziehen!
Schicht! | drücken!
unschalten! | Pop!

Wir könnten Push/Pop am Ende belassen und Put/Pull zum Anfang verschieben, um weniger zu brechen, aber ich denke, das würde die Dinge etwas verwirrend machen.

Eine andere Alternative besteht darin, append! und prepend! zu verwenden, um jeweils auf push! und shift! zu verweisen. Ich habe jedoch keine vernünftigen Worte für das Entfernen der Warteschlange und behead und curtail waren das Beste, was mir einfallen konnte ...

@phaverty Solange es möglich ist, ein Vector{Any} haben, ist das mehrdeutig.

Ich poste das nochmal: https://github.com/JuliaLang/julia/issues/23902#issuecomment -332919287

@omus Das Umbenennen von shift! in push! scheint grundlos verwirrend.

append! arbeitet mit zwei Sammlungen, während push! et. al. operiert auf einem Element, daher kann dieser Name hier IMO einfach nicht verwendet werden.

Schließlich könnten wir immer Unicode annehmen und etwas wie folgt machen:

ASCII | Unicode | Unicode-Name | Alias
---|---|---|---
drücken! | | Pfeil nach links zum Balken |
Pop! | | Pfeil nach rechts von der Leiste | Mapsto
Schicht! | | Pfeil nach rechts zum Balken |
unschalten! | | Pfeil nach rechts von der Leiste | Kartenvon

Stellen Sie sich den Balken im Unicode als Warteschlange vor. ~Leider haben diese Unicode-Zeichen keine schönen Aliase in der REPL, soweit ich das beurteilen kann~.

shift! in push! umzubenennen scheint völlig verwirrend.

Ehrlich gesagt wäre ich unglücklich, wenn wir diesen Ansatz tatsächlich verfolgen würden. Dieser Ansatz versucht definitiv, nett zu Neulingen und wirklich gemein zu bestehenden Benutzern von Julia zu sein.

@omus , zB ↦ ist \mapsto .

Ok, ich habe gelogen: Ich habe noch etwas zu sagen. Als ernsthafterer Vorschlag könnten wir diesen Ansatz verfolgen. Es verliert den schönen Push / Pop, ist aber viel klarer in Bezug auf die laufende Operation:

Alt | Neu
-- | --
drücken! | zuletzt im!
Pop! | aushalten!
Schicht! | erster!
unschalten! | zuerst!

Fühlen Sie sich frei, die meisten dieser Vorschläge abzustimmen. Nach einigen Recherchen zu diesem Thema kam ich zu der einzig wahren Schlussfolgerung, dass Informatiker die Push/Pop-Terminologie annahmen und keine Ahnung hatten, wie sie Shift/Unshift nennen sollten.

Jetzt, wo wir ständig falten, sollten Schlüsselwortargumente dafür schnell sein, richtig? Ich verstehe nicht, warum wir dafür 4 statt 2 Funktionen haben sollten, zumal von Mehrwortfunktionen ausdrücklich abgeraten wird, um das Refactoring zu fördern.

So unterhaltsam dies auch ist, es scheint, dass wir hier nicht besser sein können als der Status Quo.

So unterhaltsam dies auch ist, es scheint, dass wir hier nicht besser sein können als der Status Quo.

Der Umfang der Unterstützung für das OP scheint beträchtlich zu sein? Vielleicht ist das Schließen dieses Themas etwas voreilig? :)

Ja, der Vorschlag des OP hat 11 nach oben und 0 nach unten ...

Ich interpretierte diese als Unterstützung für die allgemeine Idee der Umbenennung, nicht für diesen speziellen Vorschlag.

Mir ist klar, dass wir nach all dieser Diskussion keine wirklich überzeugende Alternative gefunden haben.

FWIW pushfront! ist immer noch mein Favorit und meiner Meinung nach eine lohnenswerte Umbenennung, aber das könnte nur mein C++-Bias sein.

Ich mag pushfront! und popfront! .

Nun, ich habe in #25100 eine PR erstellt, um pushfront! / popfront! da ich denke, dass es das Mindeste ist, was wir tun können, um unshift! umzubenennen. Wirklich das einzige, was unshift! dafür spricht, ist (a) es ist der Status Quo, und (b) es hat einen Präzedenzfall in perl/javascript/php/anderen Sprachen, die zweifelhafte Entscheidungen von Perl erben

Fühlen Sie sich frei, es abzuschießen ;-)

Ähnlich wie @ Sacha0 erwähnt in # 25100. Ich denke, wenn wir wirklich eine Umbenennung vornehmen wollen, schlage ich vor, mit:

enqueue!(::typeof(first), a, item) = unshift!(a, item)
enqueue!(::typeof(last), a, item) = push!(a, item)
dequeue!(::typeof(first), a) = shift!(a)
dequeue!(::typeof(last), a) = pop!(a)

julia> enqueue!(::typeof(first), a, item) = unshift!(a, item);

julia> enqueue!(::typeof(last), a, item) = push!(a, item);

julia> dequeue!(::typeof(first), a) = shift!(a);

julia> dequeue!(::typeof(last), a) = pop!(a);

julia> foo = [1, 2, 3]
3-element Array{Int64,1}:
 1
 2
 3

julia> enqueue!(first, foo, 0)
4-element Array{Int64,1}:
 0
 1
 2
 3

julia> dequeue!(first, foo)
0

julia> enqueue!(last, foo, 5)
4-element Array{Int64,1}:
 1
 2
 3
 5

julia> dequeue!(last, foo)
5

Alternative:

push!(::typeof(first), a, item) = unshift!(a, item)
push!(::typeof(last), a, item) = push!(a, item)
pop!(::typeof(first), a) = shift!(a)
pop!(::typeof(last), a) = pop!(a)

Wir könnten auch push! und pop! behalten, ohne first oder last die standardmäßig push!(last, ...) und pop!(last, ...) wären.