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


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

Re: Rechenweg gesucht

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>

Show all headers | View raw


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