Groups | Search | Server Info | Keyboard shortcuts | Login | Register
Groups > de.comp.lang.javascript > #4741
| From | Maik Koenig <usenetspam@maikkoenig.de> |
|---|---|
| Newsgroups | de.comp.lang.javascript |
| Subject | Re: Rechenweg gesucht |
| Date | 2016-02-13 18:59 +0100 |
| Message-ID | <n9nue3.6gs.1@mid.maikkoenig.de> (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> |
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. 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. c ist wie gesagt der "Geber" für den Zeitfaktor pro Teil. Je kleiner c, desto größer der Zeitfaktor. Das liegt an der Art wie die Maschine arbeitet: Ich brauche bei 20 Teilen pro Platte deutlich weniger Zeit pro Teil als wenn ich in der Platte nur 4 Teile habe. Denn der größte Teil des Zeitbedarfs ist das Heranführen der Platten der immer gleich ist, egal wieviele Teile da letztlich draus entstehen. Man kann (als Arbeiter) die Werte x und y in Grenzen beeinflussen in dem man Material wählt, bei dem die enthaltenen Platten kleiner sind und deutlich weniger Teile enthalten. Das sind Erfahrungswerte. Auch gibt es bei Platten "Reste". Dann wird also keine volle Platte aufgeschnitten sondern legidlich ein Rest einer Platte der bei einem früheren Durchlauf übergeblieben ist. Der Rest ist natürlich deutlich kleiner und enthält zwangsläufig weniger Teile. Wunsch wäre es jetzt heraus zu finden, wieviele Reste man mit z.B. 3 Teilen aufschneiden müsste, um c zu senken und damit den Zeitfaktor pro Teil zu steigern. Ich will den Wert nutzen um heraus zu finden ob es sinnvoller wäre noch mehrere ganze Platten zu schneiden oder ob ich besser noch einige Reste aufschneide. Was geht schneller um den Akkord zu erreichen? 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. Greetz, MK -- Kopp-Verlag-Gläubige, Religionsdeppen, rechte Vollidioten und ähnlicher Bio-Abfall werden ohne Hinweis ignoriert!
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