our LimeSurvey version: 2.62.2+170203
Own server or LimeSurvey hosting: Hosted by Uni Hamburg
Survey theme/template: Uni Hamburg Theme
==================

Hallo,

ich versuche, mit dem Expression manager einige Berechnungen zu machen. Die erste angehängte Frage ist eine Gleichung: sie soll einen Durchschnitt aus Likert-Variablen erstellen. 



Die so erstellte Variable will ich später für Kalkulationen benutzen, wie hier.


 

Das Ergebnis ist aber NaN, es sei denn, die Variable enthält zufällig eine ganze Zahl. Wenn es ein float ist, gibt is_numeric() false zurück!

Hat jemand eine Idee, wie ich dafür sorgen kann, dass diese Variablen numerisch bleiben?

Hallo,
ZUnächst kleine Rügen
1. Guck Dir einmal an, was Du hier fabriziert hast!
Man kopiert keine Bilder, sondern fügt sie mittels des dicken Buttons "Attachments" ein.

2. Ich sprach - und wir alle sprechen von einem lss Export; nicht lsq, nicht lsg.
Warum:
a. lsq und lsg Exporte sind sprachsensitiv. Man kann sie nicht in eine Umfrage importieren mit unterschiedlicher Basissprache.
Selbst "deutsch" und "deutsch(Du)" geht in die Hose.
b. Wir, die wir hier in unserer Freizeit zu helfen versuchen, müssen nun die Basissprache erraten, eine Umfrage anlegen, um dann die Gruppe oder Frage importieren zu können.
Außerdem fehlen in einem solchen Export die systemweiten Einstellungen, die manchmal recht wichtig sind.
Daher: Umfrage kopieren, alles, was nichts mit dem Problem zu tun hat, löschen; den Rest als lss schicken.

So, genug der Schelte.


Gut, Deine lsq habe ich einbmal importiert.
Aber, genau hier geht es schon los.
Du bednutzt die Property ".value". Das heißt, Du benutzt auch Bewertungswerte, oder warum sonst?
Das kann ich aber nicht erkennen, da ja die Matrix und das ganze Drunherum fehlt.

Wenn ich mir hier einmal eine solche Matrix (Q1) bastele, mit einem reversen Item,
diese "geschickt" code, nämlich
SN00x für die "Normalen" Items
SR00x für die "Reversen" Items

sehe ich mit
Mittelwert (QMean):
{sum(that.Q1.sq_SN.NAOK, if(is_empty(Q1_SR004), 0, 8 - Q1_SR004.NAOK)) / count(that.Q1.NAOK)}

und dann noch gerundet (hätte man natürlich auch sofort machen können)
{round(QMean, 1)}

überhaupt kein Problem.

Es sei denn, Du wolltest "alles auf einer Seite" darstellen.

Also schick Deine komplette Umfrage, und wir sehen weiter.

Bis dann
Joffm

Nebenbéi gesagt:
Sag Deiner Uni mal, sie sollen updaten
Diese benutzte Version ist fünfeinhalb Jahre alt ohne Bugfixes und Sicherheitsupdates.
Außerdem war dieser Zweig (2.50/2.73) lange, lange Zeit sehr buggy; wobei auch 2.62. dazu rechnen würde.
Ich habe dies jetzt mit dem letzten Release dieses Zweiges 2.73.1. getestet.

Hi Joffm,

vielen Dank für Deine Geduld. Im Anhang ist ein Los Export des Surveys.

Viele Grüße,
Marco

Hallo, Marco,
ich habe also einmal in 2.73.1. importiert (das ist zumindest der gleiche Entwicklungszweig)
Danach ist mir dies aufgefallen:
1.
 
Da gibt es also in einigen Funktionen irgendwelche Sonderzeichen (meist sind dies HTML-Leerstellen. sie man so nicht sieht). Mach diese weg (im Quellcode)!
Außerdem sieht man hier schon, dass einige Funktionen anscheinend nicht vollständig sind (das / 100 ist außerhalb der Funktion).

Gut, schauen wir uns die Auswertung an
 

Rot: Da fehlen beide geschweiften Klammern
Violett: Die Properties ".value" und ".shown" sind hier nicht angebracht.
Wie im Handbuch steht
[url] manual.limesurvey.org/ExpressionScript_-...#Access_to_variables [/url]
Qcode.value the assessment value for the question if it is relevant (otherwise blank)
Qcode.shown the display value for the question

Du benötigst aber nur
Qcode the selected response code for the question if it is relevant (otherwise blank)

Blau: die Division durch 100 ist nicht mehr Teil der Funktion - sie ist einfach Text
Anstatt
{round(calcindgrpcorrect - 1) / 6 * 100, 0)} / 100   - Außerdem fehlt hier eine zweite öffnende runde Klammer
{round((calcindgrpcorrect - 1) / 6 * 100, 0) / 100}

Grün: Irgendwie hört die Funktion da einfach auf.

Wenn ich einmal die Funktionen korrigiere zu richtiger Syntax
(wobei ich bei den meisten den Sinn nicht verstehe: z.B. wieso wird calcindopenminded noch einmal durch 7 geteilt,
gut, das ...x 100) / 100 dient zum Erzwingen von zwei Kommastellen, )
erhalte ich jedenfalls auf dieser Seite so etwas (die Testdinger oben habe ich gelöscht)
 

Hier die Umfrage zurück
 

Sollte dann doch noch etwas bei Dir haken, kann es tatsächlich an der Version liegen. Dazu wurde ja schon genug gesagt.
Falls sich die Uni aber hartleibig bezüglich eines Updates anstellt, kannst Du immer noch die bei LimeSurvey gehostete Version für zwei, drei Monate nutzen.
Das kostet Dich mit Studentenrabatt ca. €50.
Bei manchen Unis habe ich wirklich das Gefühl: Da hat vor Jahr(zehnt)en einmal ein Hiwi LimeSurvey installiert; dieser hatte vielleicht auch etwas Ahnung davon, ist aber schon lange nichgt mehr an der Uni. Und jetzt gibt es niemanden mehr, der sich daran erinnert, bzw. sich verantwortlich fühlt.

Jetzt kommen noch einei Schlussbemerkung:
Dies klappt nicht
 
Die Antwort muss zumindest aus einem Zeichen bestehen - und wenn es ein (am besten geschütztes) Leerzeichen ist.
Es gibt dann nur dies
 

Joffm
 

Hallo Joffm,

vielen Dank für die Mühen. Deine Version verhält sich tatsächlich genauso eigenartig in meiner Version von LimeSurvey -- wenn die Inputzahlen nicht rund sind, ist das Ergebnis weiterhin NaN. Sehr bizarr, und also wahrscheinlich ein Bug. Die Uni sagt mir, ab dem 1. Oktober sei Version 5 verfügbar -- bisschen spät für den geplanten Start, aber hoffen wir das Beste.

Viele Grüße,
Marco

Hallo, Marco,
was Du ausprobieren könntest:
Alle Items dieser Itembatterien sind beantwortbar; daher können sie durchaus als Pflichtfrage angelegt sein.
Dann hast Du aber einen festen Divisor für jeden Mittelwert, musst ihn also nicht mittels "count" berechnen.
Wie sieht es dann aus?

Wenn dieser Mittelwert richtig gerechnet wird, kommen wir zur Rundung.
Ehrlich gesagt, ich habe mich gewundert, dass es bei mir funktionierte.
Ich glaubte mich nämlich zu erinnern, dass die Rundung auf mehrere Kommastellen, also "round(x,n)" zeitweise nicht funktionierte, nur "round(x)".
Das ist aber "cum grano salis" zu lesen; es könnte mir auch Herr Alzheimer einen Streich gespielt haben.

Da kann man ja versuchen, die Rundung "zu Fuß" zu erledigen
Also mit "round(QCode*100)/100"

Klappt auch nicht?
Gut nächste Idee:
Wirklich "ganz zu Fuß":
Der Mittelwert sei z.B. 12.376432 und soll auf zwei Stellen gerundet werden.
Dann betrachten wir ihn als Text.
Benötigt werden die ersten zwei und dann noch die dritte Nachkommastellen, um zu entscheiden, ob es ".37" oder ".38" heißen muss.
a. (eqT1a): Das wird erledigt mit {substr(Q1,0,strpos(Q1,".")+3)}
Erklärung: Hier benötigen wir 5 Stellen, "strpos" beginnt die Zählung aber bei "0"; daher hat das Komma den Index "2"
b. (eqT1b): Das wird erledigt mit {substr(Q1,strpos(Q1,".")+3,1)}

Nun kommt nur noch eine kleine Gleichung um die endgültige Zahl zu bestimmen (ab 5 wird aufgerundet)
(eqResult): {if(eqT1b>4,eqT1a+0.01,eqT1a)}

Da wir hier Texte manipulieren, ist es wichtig, den richtigen Dezimaltrenner zu verwenden. (Ich habe hier den Punkt, da meine GUI gerade so eingestellt war.)

Damit will ich nur zeigen, dass es auch andere Möglichkeiten gibt; man muss nur ein bisschen kreativ werden.


Aber auf jeden Fall besser: Warte auf 5.x.
Joffm

Hi Joffm,

vielen Dank für die weiteren Tipps -- ich warte auf 5.x!

Viele Grüße, Marco