Groups | Search | Server Info | Keyboard shortcuts | Login | Register


Groups > de.comp.lang.javascript > #4744

Re: Rechenweg gesucht

From "Peter J. Holzer" <hjp-usenet3@hjp.at>
Newsgroups de.comp.lang.javascript
Subject Re: Rechenweg gesucht
Date 2016-02-14 15:36 +0100
Organization LUGA
Message-ID <slrnnc146h.1pa.hjp-usenet3@hrunkner.hjp.at> (permalink)
References <n9mah3.7cg.1@mid.maikkoenig.de> <n9mvui$aa9$1@news.albasani.net> <n9nlhq.9hc.1@mid.maikkoenig.de> <slrnnbuo6g.10v.hjp-usenet3@hrunkner.hjp.at> <n9nue3.6gs.1@mid.maikkoenig.de>

Show all headers | View raw


On 2016-02-13 17:59, Maik Koenig <usenetspam@maikkoenig.de> wrote:
> Am 13.02.2016 um 17:58 schrieb Peter J. Holzer:
>> On 2016-02-13 15:27, Maik Koenig <usenetspam@maikkoenig.de> wrote:
>>> Am 13.02.2016 um 11:18 schrieb Thomas Mlynarczyk:
>>>
>>>>> c-1 = (a+x)/(b+y);
>> 
>>>> Es wäre allerdings u.U. hilfreich, ein wenig Kontextinformation zu 
>>>> haben: Was sind a, b, x, und y? Was willst Du hier berechnen? Evtl. 
>>>> ergibt sich in Kenntnis dieser Details ein völlig anderer Lösungsansatz.
>>>
>>> Eine Säge schneidet Platten (b) auf und erzeugt damit neue Teile (a).
>>> Abhängig davon wieviele Teile es pro Platte sind (c) gibt es einen
>>> Zeitfaktor pro Teil. Dieser Faktor ist umso größer je kleiner c ist.
>>>
>>> Gewünscht ist jetzt eine Rechenhilfe die einem sagt: Wenn Deine nächsten
>>> x Platten y Teile enthalten, sinkt der Wert von Teile pro Platte (c) und
>>> damit steigt dann der Zeitfaktor pro Teil.
>> 
>> Vorsicht. Du addierst in Deiner Formel Platten und Teile:
>> 
>> c-1 = (a [Teile] + x [Platten]) / (b [Platten] + y [Teile])
>
> Ups, stimmt. Ich habe in der Erklärung x und y vertauscht. Gedacht ist
> es aber natürlich andersrum.
>
>> Ob das, was Du da machst, inhaltlich sinnvoll ist, kann ich nicht
>> beurteilen. Mir erscheint es eher seltsam: Warum soll c um genau 1
>> sinken? (wenn c von 8.4 auf 7.4 sinkt, hat das vermutlich weniger
>> Einfluss, als wenn es von 2.1 auf 1.1 sinkt)? Hast Du auf x und y
>> überhaupt einen Einfluss? Wenn ja, willst Du nicht lieber c maximieren?
>> Viele Fragen ...
>
> c muss nicht um genau 1 sinken.

Du suchst aber nach ganzzahligen Lösungen einer Gleichung, bei der c
genau um 1 kleiner ist als vorher. Wenn Du c minimieren willst, musst Du
einen anderen Ansatz verfolgen. Wenn Du c möglichst knapp an eine
Rundungsgrenze heranführen willst, auch.

> Es muss nur soweit sinken das Math.round(c) um 1 kleiner wird. Also
> wäre c=3,6 zu c=3,4 ein gewünschtes Ergebnis.

Ist dieses gerundete c ein Wert, der an die Buchhaltung zwecks
Lohnberechnung gemeldet wird? Dann macht es natürlich für den Arbeiter
Sinn, das (auf Kosten des Arbeitgebers) zu optimieren.

Unter der Annahme, dass ihr als Arbeiter nach produzierten Teilen oder
verbrauchten Platten bezahlt werdet, macht das keinen Sinn: c ist eine
kontinuierliche Variable und 3.4 ist nur geringfügig schlechter oder
besser als 3.6.

(Solche Nichtlinearitäten sind ein klassisches Beispiel für "perverse
incentives": Der Arbeiter hat einen Anreiz, das System auszutricksen,
nicht möglichst viel oder billig zu produzieren)


> Das ist nicht aus Sicht der Firma sondern aus Sicht des Arbeiters: Je
> weniger Arbeit er sich machen muss um sein Akkordziel zu erreichen desto
> besser.

Das erklärt, warum Du c kleiner machen willst und nicht größer. Es
erklärt allerdings nicht, warum Du es nicht minimieren willst. 2.4 wäre
doch sicher noch besser als 3.4? Oder würde das dann auffallen?

        hp



-- 
   _  | Peter J. Holzer    | Fluch der elektronischen Textverarbeitung:
|_|_) |                    | Man feilt solange an seinen Text um, bis
| |   | hjp@hjp.at         | die Satzbestandteile des Satzes nicht mehr
__/   | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel

Back to de.comp.lang.javascript | Previous | NextPrevious in thread | Next in thread | Find similar


Thread

Rechenweg gesucht Maik Koenig <usenetspam@maikkoenig.de> - 2016-02-13 04:13 +0100
  Re: Rechenweg gesucht Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2016-02-13 11:18 +0100
    Re: Rechenweg gesucht Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2016-02-13 11:41 +0100
      Re: Rechenweg gesucht Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2016-02-13 11:51 +0100
        Re: Rechenweg gesucht Maik Koenig <usenetspam@maikkoenig.de> - 2016-02-13 18:47 +0100
    Re: Rechenweg gesucht Maik Koenig <usenetspam@maikkoenig.de> - 2016-02-13 16:27 +0100
      Re: Rechenweg gesucht "Peter J. Holzer" <hjp-usenet3@hjp.at> - 2016-02-13 17:58 +0100
        Re: Rechenweg gesucht Maik Koenig <usenetspam@maikkoenig.de> - 2016-02-13 18:59 +0100
          Re: Rechenweg gesucht "Peter J. Holzer" <hjp-usenet3@hjp.at> - 2016-02-14 15:36 +0100
            Re: Rechenweg gesucht Maik Koenig <usenetspam@maikkoenig.de> - 2016-02-14 17:41 +0100
              Re: Rechenweg gesucht "Peter J. Holzer" <hjp-usenet3@hjp.at> - 2016-02-14 21:47 +0100
                Re: Rechenweg gesucht Maik Koenig <usenetspam@maikkoenig.de> - 2016-02-15 02:27 +0100
                Re: Rechenweg gesucht Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-02-15 20:02 +0100
      Re: Rechenweg gesucht Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2016-02-13 18:17 +0100
        Re: Rechenweg gesucht Maik Koenig <usenetspam@maikkoenig.de> - 2016-02-13 19:00 +0100
  Re: Rechenweg gesucht Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-02-13 19:23 +0100
  Re: Rechenweg gesucht Robin Koch <robin.koch@t-online.de> - 2016-02-17 13:46 +0100

csiph-web