Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

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

Re: Rechenweg gesucht

Show all headers | View raw

On 2016-02-14 16:41, Maik Koenig <usenetspam@maikkoenig.de> wrote:
> Am 14.02.2016 um 15:36 schrieb Peter J. Holzer:
>
>>> 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.
>
> Lach. Nein, ist es nicht. Die Lohnbuchhaltung bekommt c nie zu Gesicht.

Naja, nicht direkt, aber so wie Du das schilderst

> Aus der Luft gegriffenes Beispiel, die echten Zahlen sind andere:
>
> c = 3.6 ist gerundet 4 und das bedeutet man hat pro Teil 1,90 Minuten.
> c = 3.4 ist gerundet 3 und das bedeutet man hat pro Teil 2,22 Minuten.

indirekt: Es wird der gerundete (und nicht der exakte) Wert verwendet,
um die Vorgabezeit zu berechnen.

Am Ende der Schicht kommt also sowas raus wie 
Arbeiter A hat 270 Stück produziert (à 1.9 Min = 513 Min = 107 %)
Arbeiter B hat 238 Stück produziert (à 2.22 Min = 528 Min = 110 %)
...

Im schlimmsten Fall entscheidet dann ein Stück mehr oder weniger, ob man
für die ganze Schicht 1.9 Min oder 2.22 Min pro Stück bezahlt bekommt.

Aber ich stelle fest, dass erstens die Formel offenbar nicht
proportional ist (2.22 ist deutlich weniger als 1.9 * 4/3) und Du weiter
unten von Werten zwischen 10 und 20 sprichst. Die Sprünge, die durch das
Runden entstehen, sind also deutlich kleiner.


> Dem Problem werde ich vorbeugen in dem diese Rechenhilfe erst dann
> sichtbar wird, wenn eine bestimmte Menge an Teilen bereits geschnitten
> ist. Aus Erfahrung weiss ich, dass dann nur noch rund 60 bis 90
> Arbeitsminuten verbleiben.
>
> Je nach Situation kann es dann besser sein, Reste aufzuschneiden oder
> ganze Platten. Denn je höher c wird, desto geringer wird der Unterschied
> zwischen den daraus abgeleiteten Zeiten pro Teil. Beispiele:
>
> c=1 3,17 / c=2 2,37 || c=24 1,08 / c=25 1,07
>
> Reste aufzuschneiden dauert (pro Teil!) länger und ist potentiell
> körperlich anstrengender da man die manuell heran führen muss (man muss
> sie tragen!). Platten werden automatisiert zugeführt (Maschine bringt
> sie). Braucht man noch 4 Reste mit z.B. insgesamt 10 Teilen um den
> Akkord zu schaffen oder aber 1 Platte mit 20 Teilen? Vom Zeitbedarf her
> ist beides nahe aneinander. Die Reste steigern womöglich den geleisteten
> Akkord für diesen Tag da sie eventuell c absenken, dafür sind sie
> körperlich belastender.
>
> Es hat beides Vor- und Nachteile. Und niemand wird 4 Reste schleppen
> wenn er es nicht muss um seinen Akkord zu schaffen, da die eine Platte
> bequemer zu verarbeiten wäre.

Wenn ich das also richtig verstehe, ist die Aufgabe, herauszufinden,
wieviele Stück man bis zum Ende der Schicht aus wievielen Platten
schneiden muss, um sein Akkordziel zu erreichen. Möglichst so, dass der
Arbeitsaufwand dabei minimal wird.

Ich glaube, Deine ursprüngliche Gleichung leistet das nicht. Nicht nur
wegen dem -1, das das Rundungskriterium nicht richtig abbildet, sondern
vor allem, weil sie die Vorgabe, ein gewisses Produkt aus Stückzahl und
Stücklohn zu erreichen, nicht abbildet.

Ich würde da einen anderen Ansatz verfolgen:

Gegeben sind: 

 * Die bereits erzeugten Teile
 * Die bereits verbrauchten Platten
 * Das Akkordziel (also z.B. 110% = 528 Minuten)
 * Den Zeitwert für jedes Verhältnis Teile/Platten (vielleicht als
   Formel, vielleicht als Array)

Dann erhöhst Du in einer Schleife die Anzahl Platten ab 1 und
berechnest, wieviele Teile Du aus diesen schneiden müsstest, um Dein
Ziel zu erreichen:

Da das wegen der nicht-kontinuierlichen Bewertungsfunktion nicht ganz
trivial ist und Rechenzeit billiger ist als Hirnschmalz, machst Du das
auch in einer Schleife: Du beginnst bei der Anzahl der Platten (weniger
als 1 Teil pro Platte geht nicht) und erhöhst so lange bis

    platten_gesamt = platten_fertig + platten_neu
    teile_gesamt = teile_fertig + teile_neu
    c = Math.round(teile_gesamt/platten_gesamt)
    zeit = teile_gesamt * zeitwert(c) 

größer oder gleich dem Akkordziel ist. 
Dann gibst Du platten_neu und teile_neu aus und gehst zum nächsten Wert
von platten_neu über.

Wenn die Anzahl der Platten gleich der Anzahl der Teile ist, kannst Du
abbrechen. Unmögliche Ergebnisse (z.B. Verhältnis von teile_neu zu
platten_neu größer als das größte verfügbare Schnittmuster) kannst Du
auch ausfiltern.

Mit Informationen über die verfügbaren Schnittmuster könnte man das noch
verfeinern.

        hp, der wieder einmal eine sprachunabhängige Programmiergruppe
            vermisst.

-- 
   _  | 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

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