Groups | Search | Server Info | Keyboard shortcuts | Login | Register
Groups > de.comp.lang.javascript > #4744
| 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> |
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 | Next — Previous in thread | Next in thread | Find similar
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