Name für variable

Schraubel schrieb:
> Hi Forum,
> ich suche einen bezeichnenden Namen für
> eine BitVariable die folgenes tut:
> Alter Status (t-1) eines Eingangs merken zur Flankenerkennung.

Also ein Vergangenheitswert. Im Englischen "past value".

Sinnvollerweise sollte in der Variablen ausgedrückt sein, wozu die Info 
gut ist die in ihr gespeichert wird. (z.B. Zugehörigkeit zu einer 
physikalischen Größe, oder einem Maschinenteil, ...)

Beispiele im Fall eines Schalters:

light_switch_past_value
proximitySwitch_pastValue
ToggleSwitchPastValue
PushButtonSwitch_PastValue

Natürlich dürfen die Variablennamen auch in deutscher Sprache verfast 
sein, wenn es im Rest des Codes ebenfalls so ist. Aber bitte nicht 
deutsch und englisch wild durcheinander mischen. Das ist krank ;-)

Eine gute idee ist auch die Variablen in Dialekt zu benennen, Das 
erschwert ein Auslagern irgendwohin ab 50km Distanz. Wobei das erst im 
Nachhinein auffaellt.

Georg schrieb:
> Wenn du bei jeder Variablen eine Volksbefragung startest, wirst du auch
> für das allerkleinste Projekt Jahre brauchen. Anders formuliert: krasses
> Beispiel von Unselbstständigkeit.

Mir sind Kollegen, die sich ernsthaft Gedanken machen über vernünftige 
Bezeichner und bei einer kleinen Blockade damit auch mal jemanden 
anderes fragen (Tellerrand!), 1000mal lieber als die, die irgend einen 
Sch*** hinschreiben.

Grüße
Markus

Markus V. schrieb:
> Mir sind Kollegen, die sich ernsthaft Gedanken machen über vernünftige
> Bezeichner und bei einer kleinen Blockade damit auch mal jemanden
> anderes fragen (Tellerrand!), 1000mal lieber als die, die irgend einen
> Sch*** hinschreiben.

So isses.

Ich benenne die meisst mit dem prefix "Prev" oder "Old":
xPrev, yOld

Random .. schrieb:
> Ich benenne die meisst mit dem prefix "Prev" oder "Old":
> xPrev, yOld

Wohl eher Suffix... ;-)

Markus V. schrieb:
> Random .. schrieb:
>> Ich benenne die meisst mit dem prefix "Prev" oder "Old":
>> xPrev, yOld
>
> Wohl eher Suffix... ;-)
genau :-)

Ich hatte mal vor Jahrzehnten einen Kollegen, der sollte mir 
Programmieren beibringen (da tat ich das schon ca. 10 Jahre) und hat 
allen ernstes vorgeschlagen lokale Variablen Inn, mit nn=00..99, zu 
benennen, weil's viel übersichtlicher ist.
Dank Code-Auto-Completion wird man heute eher die Doku in den 
Variablenname verpacken.

Vincent H. schrieb:
> state[1] = state[0];

Das ist so ziemlich die schlechteste Lösung: Kein Mensch weiß, welche 
Semantik sich hinter 0 und 1 verbirgt.

Markus V. schrieb:
> Vincent H. schrieb:
>> state[1] = state[0];
>
> Das ist so ziemlich die schlechteste Lösung: Kein Mensch weiß, welche
> Semantik sich hinter 0 und 1 verbirgt.

Um diesen Ansatz zu retten:

1

#define CURRENT_STATE  0

2

#define PREVIOUS_STATE 1

3

4

state[PREVIOUS_STATE] = state[CURRENT_STATE];

Ist auf jeden Fall skalierbar, z.B. mit:

1

#define NEXT_STATE     2

;-)

Frank M. schrieb:
> Um diesen Ansatz zu retten:#define CURRENT_STATE  0
> #define PREVIOUS_STATE 1
>
> state[PREVIOUS_STATE] = state[CURRENT_STATE];
>
> Ist auf jeden Fall skalierbar, z.B. mit:#define NEXT_STATE     2

Und was ist daran besser als currentState und previousState? Außer daß 
es mehr Code ist, der schwerer verständlich ist! ;-)

Grüße
Markus

Dussel schrieb:
> Das mache ich in VHDL zur Flankenerkennung immer so und hier sehe ich
> keinen Grund, warum das nicht gehen sollte...

Niemand behauptet, dass das nicht geht. Und trotzdem ist es für Leser 
des Sourcecodes sehr schwer nachvollziehbar, was das passieren soll. 
Weshalb es per se schlecht ist.

Grüße
Markus

Dussel schrieb:
> Wie berechnest du einen gleitenden Mittelwert über zig oder hunderte
> Werte, wenn ein Array als 'Schieberegister' so schwer verständlich ist?

Man nimmt 1-(i+1)/n vom momentanen wert und adiert (i+1)/n vom neuen 
dazu. Das ist dein neuer Momentane wert.

Dussel schrieb:
> Das ist es eben nicht. Was willst du denn machen, wenn du mehrere alte
> Werte speichern willst? Variablen aktuell, alt, älter, noch_älter,
> noch_davor…
> Wie berechnest du einen gleitenden Mittelwert über zig oder hunderte
> Werte, wenn ein Array als 'Schieberegister' so schwer verständlich ist?
> Das Problem ist in allen Fällen das Gleiche: Man möchte vergangene Werte
> betrachten. Ob das jetzt 1024 oder 2 sind, ist für die Fragestellung
> kein Unterschied.

Das ist aber ein total anderer Usecase. Bei der ursprünglichen 
Fragestellung ging es (nur) um "current" und "previous". Wenn Du die 
Historie tatsächlich benötigst, ist ein Array / eine Liste natürlich 
richtig.

Grüße
Markus

Dussel schrieb:
> Wie berechnest du einen gleitenden Mittelwert über zig oder hunderte
> Werte

Das ist etwas völlig anderes als eine Flanke zu erkennen.

Markus V. schrieb:
> Vincent H. schrieb:
>> state[1] = state[0];
>
> Das ist so ziemlich die schlechteste Lösung: Kein Mensch weiß, welche
> Semantik sich hinter 0 und 1 verbirgt.


Du hast wohl nicht viel mit Signalverarbeitung oder Regelungstechnik zu 
tun?
n(0), n(-1), n(-2)

Das sind ganz klassische Bezeichnungen für diskrete Zeiten.

C unterstützt halt leider keine negativen Indizes.

Vincent H. schrieb:
> C unterstützt halt leider keine negativen Indizes.

Und diese Info hast du von wo?

1

#include <stdio.h>

2

3

static int tmp_n[3] = {1,2,3};

4

int *n = tmp_n + sizeof(tmp_n)/sizeof(*tmp_n) - 1;

5

6

int main(){

7

  printf("%d %d %d\n",n[0],n[-1],n[-2]);

8

  return 0;

9

}

1

daniel@Daniels-Surface-Pro-3:~$ gcc -std=c99 -Wall -Werror -pedantic main.c -o main

2

daniel@Daniels-Surface-Pro-3:~$ ./main 

3

3 2 1

Ich meinte damit natürlich direkte Indizes, die 1:1 am Array wirken, 
keine Pointer-Arithmetik.

/edit

1

printf("%d", tmp_n[-1]); // quasi

Vincent H. schrieb:
> Du hast wohl nicht viel mit Signalverarbeitung oder Regelungstechnik zu
> tun?

Mit Signalverarbeitung oder Regelungstechnik nicht, dafür aber sehr viel 
mit Code Quality / Clean Code Development.

Vincent H. schrieb:
> n(0), n(-1), n(-2)
>
> Das sind ganz klassische Bezeichnungen für diskrete Zeiten.

Es ist aber nach wie vor ein anderer Use Case, wie der des TOs. Also 
vergleiche bitte nicht Äpfel mit Birnen. ;-)

Grüße
Markus

Wenn ich nochmals in Erinnerung rufen dürfte: :-)
Markus V. schrieb:
> Vincent H. schrieb:
>> state[1] = state[0];
>
> Das ist so ziemlich die schlechteste Lösung: Kein Mensch weiß, welche
> Semantik sich hinter 0 und 1 verbirgt.

Bei der Frage des TOs ging es um genau ZWEI Zustände: Den aktuellen und 
den vorhergehenden. Dies mit einem Array zu implementieren, mit nichts 
sagenden Konstanten 0 und 1 zu implementieren ist die schlechteste 
Lösung. Dabei bleibe ich.

Wenn man für das Erkennen von irgendwelchen Zuständen mehr als zwei 
Werte benötigt, macht ein Array ja Sinn. Das streite ich doch garnicht 
ab.

Aber beim Use Case des TOs sind es halt nur zwei Zustände. Und deshalb 
gleich eine abstrakte Lösung mit n historischen Zuständen zu 
fabrizieren, die man wahrscheinlich niemals benötigt, ist Overkill. Man 
sollte immer folgendes, wichtiges Prinzip in der Softwareentwicklung 
beachten: So konkret wie möglich und so abstrakt wie nötig.

Grüße
Markus

Dussel schrieb:
> dass der Ansatz mit dem Array totaler Quatsch sei. Das ist
> eben nicht so, sondern gängige Praxis für solche Probleme.

Arrays mit einer Größe von exakt zwei halte ich nicht für typisch und 
gängig. Aber ich kann mich natürlich auch irren. Wir können ja mal eine 
Code-Suchmaschine anwerfen und schauen, wie oft dieser Fall real 
vorkommt? :-)

Mark B. schrieb:
> Arrays mit einer Größe von exakt zwei halte ich nicht für typisch und
> gängig.

Sehr gängig für double buffering...

1

ImageStruct buffer[2];

2

int work = 0, display = 1;

3

4

void flip()

5

{

6

  work = display;

7

  display = 1 - display;

8

}

9

10

void renderLoop()

11

{

12

  while(1)

13

  {

14

    showImage(&buffer[display]);

15

    renderNewImage(&buffer[work]);

16

    flip();

17

  }

18

}

Eric B. schrieb:
> Mark B. schrieb:
>> Arrays mit einer Größe von exakt zwei halte ich nicht für typisch und
>> gängig.
>
> Sehr gängig für double buffering...

Okay, dann genauer eingeschränkt:

Arrays mit einer Größe von exakt zwei zum Speichern von physikalischen 
Größen (z.B. Messwerte, die von einem Sensor erfasst werden) halte ich 
nicht für typisch und gängig.