mboost-dp1
Hjælp til formel
Jeg skal lave en formel med følgende kriterier:
jeg indsætter 2 sæt x,y-værdier, x_low,y_low og x_high,y_high, eks. (3,100) og (10,70)
formlen skal så kunne give mig værdien for eksempelvis x=5
Havde det ikke været for følgende regel, så ville ovenstående ikke være så svært for mig, men...:
For alle x-værdier under x_low skal y blot være y_low
For alle x-værdier over x_high skal y blot være y_high
OG SÅ DEN SVÆRE illustreres med et eksempel:
for hver gang x inkrementeres med 1, så vil y naturligvis skifte værdi i retning af y_high. Men y=[formel for x(n+1)] må ALDRIG være mindre end y=[formel for x(n)]+y_high
Tilsvarende for x_low.
Giver det mening?
Lidt mere uteknisk, så skal det bruges til at lave en prisstruktur. Lad os sige stk-pris på kr. 100,- v. 3 stk og kr. 70,- v. 10 stk. Før 3 stk er stk.prisen stadigvæk 100 og efter 10 er den kr. 70.
Det vil således ikke give mening at stk.-prisen ved 9 stk eksempelvis er kr. 75,- fordi 9 x 75 = 675,- og 10 x 70 = 700 og at der altså derfor kun er en pris-difference på kr. 25 kroner for den sidste stk efter 9.
Håber at der kan udarbejdes en simpel formel, der kan håndtere i hvert fald kurven mellem de 2 x,y-punkter.
jeg indsætter 2 sæt x,y-værdier, x_low,y_low og x_high,y_high, eks. (3,100) og (10,70)
formlen skal så kunne give mig værdien for eksempelvis x=5
Havde det ikke været for følgende regel, så ville ovenstående ikke være så svært for mig, men...:
For alle x-værdier under x_low skal y blot være y_low
For alle x-værdier over x_high skal y blot være y_high
OG SÅ DEN SVÆRE illustreres med et eksempel:
for hver gang x inkrementeres med 1, så vil y naturligvis skifte værdi i retning af y_high. Men y=[formel for x(n+1)] må ALDRIG være mindre end y=[formel for x(n)]+y_high
Tilsvarende for x_low.
Giver det mening?
Lidt mere uteknisk, så skal det bruges til at lave en prisstruktur. Lad os sige stk-pris på kr. 100,- v. 3 stk og kr. 70,- v. 10 stk. Før 3 stk er stk.prisen stadigvæk 100 og efter 10 er den kr. 70.
Det vil således ikke give mening at stk.-prisen ved 9 stk eksempelvis er kr. 75,- fordi 9 x 75 = 675,- og 10 x 70 = 700 og at der altså derfor kun er en pris-difference på kr. 25 kroner for den sidste stk efter 9.
Håber at der kan udarbejdes en simpel formel, der kan håndtere i hvert fald kurven mellem de 2 x,y-punkter.
#2 det er nu ren business :D Og jeg har rigeligt med baggrund i programmering og har hidtil prøvet en 2. gradsligning. Ulempen er at den jævner meget ud mod slut-resultatet og ender med at der er et stort spring i sum-prisen når jeg efter x_high begynder at lægge y_high til sum_prisen...
Hvis du laver noget simpelt som P(N)=B*(N-NLow)^2+PLow, dvs. det simpleste 2.-grads polynomium man kan tænke sig, så skal B=(PHigh-PLow)/(NHigh-NLow)^2 for at P(NHigh)=PHigh.
Prisen vil så blive sådan her:
http://peecee.dk/uploads/122013/pris_big_thumb.jpg
(Parametre: PLow=100, PHigh=70, NLow=3, NHigh=10)
Ellers kan man altid prøve med flere fittingparametre.
EDIT: Resultatet bliver dog at sumprisen falder en smule n[r man køber 10 i stedet for 9. Det giver naturligvis ikke mening. Der må flere parametre til.
Prisen vil så blive sådan her:
http://peecee.dk/uploads/122013/pris_big_thumb.jpg
(Parametre: PLow=100, PHigh=70, NLow=3, NHigh=10)
Ellers kan man altid prøve med flere fittingparametre.
EDIT: Resultatet bliver dog at sumprisen falder en smule n[r man køber 10 i stedet for 9. Det giver naturligvis ikke mening. Der må flere parametre til.
#9 jeg prøver lige at forklare på en meget mere simpel måde...
hvis jeg starter med en eller anden pris v. eksempelvis 1 stk. (her: 300) og delta_t falder med en endnu ukendt kvotient, så vil den gennemsnitlige stk-pris langsomt nærme sig de 50, da delta_t efter 5 stk forbliver 50...
Men jeg kan ikke bruge en funktion, der summerer total + delta_t, dels fordi jeg endnu ikke kender kvotienten for delta_t og dels fordi jeg også gerne vil kunne regne prisen ud for 4,7 stk.
Hjalp det lidt?
På denne måde vil prisforskellen når man bestiller 1 stk mere være under minimums-delta_t.
Ved din ligning falder gennemsnitsprisen pr. stk, men når grænsen nåes, så kommer der et prishop.. Altså koster 1 stk ekstra over grænsen pludselig en del mere end før grænsen.
Stk Stk-pris Total Delta_t
1.00 300.00 300.00
2.00 195.00 390.00 90.00
3.00 156.67 470.00 80.00
4.00 135.00 540.00 70.00
5.00 120.00 600.00 60.00
6.00 108.33 650.00 50.00
7.00 100.00 700.00 50.00
8.00 93.75 750.00 50.00
9.00 88.89 800.00 50.00
10.00 85.00 850.00 50.00
11.00 81.82 900.00 50.00
12.00 79.17 950.00 50.00
13.00 76.92 1,000.00 50.00
14.00 75.00 1,050.00 50.00
15.00 73.33 1,100.00 50.00
hvis jeg starter med en eller anden pris v. eksempelvis 1 stk. (her: 300) og delta_t falder med en endnu ukendt kvotient, så vil den gennemsnitlige stk-pris langsomt nærme sig de 50, da delta_t efter 5 stk forbliver 50...
Men jeg kan ikke bruge en funktion, der summerer total + delta_t, dels fordi jeg endnu ikke kender kvotienten for delta_t og dels fordi jeg også gerne vil kunne regne prisen ud for 4,7 stk.
Hjalp det lidt?
På denne måde vil prisforskellen når man bestiller 1 stk mere være under minimums-delta_t.
Ved din ligning falder gennemsnitsprisen pr. stk, men når grænsen nåes, så kommer der et prishop.. Altså koster 1 stk ekstra over grænsen pludselig en del mere end før grænsen.
#8 jeg rater dig flamebait, fordi du skriver
Hvis du blot havde fortsat i din "if-løkke", så havde jeg ikke rated, men blot sagt, at du ikke helt ramte, hvad jeg prøvede at forklare - om det så er mig, der ikke forklarer godt, eller dig der ikke forstår godt, vil jeg lade være usagt...
Hvis du havde reel programmeringserfaring, så ville det være naturligt for dig at kigge i den retning.
Hvis du blot havde fortsat i din "if-løkke", så havde jeg ikke rated, men blot sagt, at du ikke helt ramte, hvad jeg prøvede at forklare - om det så er mig, der ikke forklarer godt, eller dig der ikke forstår godt, vil jeg lade være usagt...
rackbox (11) skrev:Hjalp det lidt?
Yep, det giver mening, og jeg indså også selv problemet.
Men hvor meget haster det? Jeg skal gerne kigge mere på det, men jeg skal til eksamen i både relativitetsteori og kvantemekanik i næste uge, så der er egentlig andet jeg burde lave ;)
Det kan måske være at 2.gradsligningen skal køres på Delta_t, men kan ikke lige overføre det til mine krav... Altså at den ikke bare må summere. Tror jeg har stirret mig blind på den.
Det haster ikke vildt meget, men jeg er bare blevet irriteret over, at jeg ikke bare lige kan knække den nød, når jeg faktisk kender alle reglerne og faktorerne.. Det ligner ikke mig ikke at kunne konstruere en simpel ligning :D
Jeg sidder og tænker, at hvis jeg har (x1,y1), og (x2,y2), så må delta_t jo kunne udregnes for en given x-værdi, og gennem multiplikation kunne udregne enten gennemsnitlig stk-pris eller total-pris... Eller i det mindste må man kunne udregne delta_t for første og sidste værdi i grænseområdet... Øv, jeg hader, at jeg ikke bare lige kan den her.
Det haster ikke vildt meget, men jeg er bare blevet irriteret over, at jeg ikke bare lige kan knække den nød, når jeg faktisk kender alle reglerne og faktorerne.. Det ligner ikke mig ikke at kunne konstruere en simpel ligning :D
Jeg sidder og tænker, at hvis jeg har (x1,y1), og (x2,y2), så må delta_t jo kunne udregnes for en given x-værdi, og gennem multiplikation kunne udregne enten gennemsnitlig stk-pris eller total-pris... Eller i det mindste må man kunne udregne delta_t for første og sidste værdi i grænseområdet... Øv, jeg hader, at jeg ikke bare lige kan den her.
#18
Kode:
Kode:
public class PriceModel {
private double x_low;
private double y_low;
private double x_high;
private double y_high;
private double min_delta;
public PriceModel(int x_low, double y_low, int x_high, double y_high, double min_delta) {
if(x_low > x_high) throw new IllegalArgumentException("x_low greater than x_high");
if(y_low < y_high) throw new IllegalArgumentException("y_low less than y_high");
if(x_high * y_high < x_low * y_low + (x_high - x_low) * min_delta) throw new IllegalArgumentException("Restriction not possible");
this.x_low = x_low;
this.y_low = y_low;
this.x_high = x_high;
this.y_high = y_high;
this.min_delta = min_delta;
}
public double simpleCalc(int x) {
if(x <= x_low) {
return y_low;
} else if(x >= x_high) {
return y_high;
} else {
return y_low - (x - x_low) / (x_high - x_low) * (y_low - y_high);
}
}
private double limit(int x) {
return ((x + 1) * restrictedCalc(x + 1) - min_delta) / x;
}
public double restrictedCalc(int x) {
if(x <= x_low) {
return y_low;
} else if(x >= x_high) {
return y_high;
} else {
return Math.min(simpleCalc(x), limit(x));
}
}
public static void main(String[] args) {
PriceModel pm = new PriceModel(3, 100, 10, 70, 35);
for(int i = 1; i <= 15; i++) {
System.out.printf("%2d %6.2f %8.2f %6.2f %8.2f\n", i, pm.simpleCalc(i), i * pm.simpleCalc(i), pm.restrictedCalc(i), i * pm.restrictedCalc(i));
}
}
}
gramps (8) skrev:Og eftersom du har ratet mig flamebait
Det var vel ret oplagt at rate dig flamebait efter:
gramps (6) skrev:Hvis der er tale om reel programmering, så ville jeg kigge på if-løkker
gramps (6) skrev:Hvis du havde reel programmeringserfaring, så ville det være naturligt for dig at kigge i den retning.
Jeg tror den eneste måde at nå frem til en fornuftig model er ved at definere en funktion for hvordan prisen på den n'te enhed udvikler sig som funktion af n.rackbox (11) skrev:Men jeg kan ikke bruge en funktion, der summerer total + delta_t, dels fordi jeg endnu ikke kender kvotienten for delta_t og dels fordi jeg også gerne vil kunne regne prisen ud for 4,7 stk.
Så får du en funktion, hvor prisen på n stk. vil være defineret som summen af prisen på 1., 2., 3. osv. op til n'te. Med den konstruktion behøver du ikke kende nogen kvotient (og den vil alligevel ikke være konstant). Du skal blot tage stilling til, hvor hurtigt stk. prisen skal konvergere mod marginalprisen. Den rette formel for det er det måske bedre at spørge en økonom om. Men min intuition siger mig at det må give mening, hvis differencen til minimumsprisen aftager omvendt proportionalt.
Så kunne den n'te enhed koste minpris + (maxpris - minpris) / n
Hvis man sætter minpris til 50 og maxpris til 300, så koster et styk 300, imens 2 stk koster 300 + 50 + (300 - 50) / 2 = 350 + 250 / 2 = 350 + 125 = 475.
Udregning af prisen på mange stk på den måde er lidt ineffektivt. Så det næste skridt er at finde en formel til at udregne summen af prisen på n stk. direkte, uden at skulle udregne prisen på hver enkelt.
Har man først fundet den formel, så vil man også kunne sætte decimaltal ind i formlen og finde prisen på f.eks. 4,7 stk.
Summen af de reciprokke, som jeg foreslog må lægge tæt på integralet over (maxpris - minpris) / x som giver (maxpris - minpris) * ln(x).
Så hvis ellers du tør stole på udregninger jeg har udført på den her tid af natten, så kunne prisen på n stk blive:
n * minpris + (1 + ln(n)) * (maxpris - minpris)
Hvis vi sætter 50 og 300 ind i den formel, så bliver prisen på 1 stk
1 * 50 + (1 + ln(1)) * (300 - 50) = 50 + (1 + 0) * 250 = 300
prisen på 2 stk
2 * 50 + (1 + ln(2)) * (300 -50) = 100 + (1 + 0,693) * 250 = 523
prisen på 3 stk
3 * 50 + (1 + ln(3)) * (300 - 50) = 150 + (1 + 1,099) * 250 = 674
prisen på 4,7 stk
4,7 * 50 + (1 + ln(4,7)) * (300 - 50) = 235 + (1 + 1,548) * 250 = 872
Men der er et eller andet galt med min formel, for prisen bliver for lav, hvis man prøver at regne den ud for mindre end 1 stk.
prisen på 0,2 stk
0,2 * 50 + (1 + ln(0,2)) * (300 - 50) = 10 + (1 - 1,609) *250 = -142
Den oplagte måde at justere kurven på er ved at bruge en lineær funktion hhv. før og efter man tager logaritmen.rackbox (24) skrev:bortset fra at jeg så lige skal se hvordan jeg kan justere hastigheden på hældningsfaldet på kurven
Nu kunne man fejlagtigt tro at de to lineære funktioner man bruger på den måde giver 4 frihedsgrader. Men eftersom multiplikation med en konstant før man tager logaritmen er ækvivalent med addition af en konstant efter man har taget logaritmen, så er der kun 3.
En af de tre frihedsgrader kan man allerede justere på i mine første forslag ved at justere maxpris. Men måske skulle det i virkeligheden have været en anden parameter, man skruede på for at få den rigtige pris på 1 stk.
At skifte den naturlige logaritme ud med en logaritme med en anden base er ækvivalent med at gange med en konstant efter man har taget logaritmen, så det ville ikke give nogen ekstra frihedsgrad (eftersom man allerede har den frihedsgrad i maxpris parameteren).
Dermed bliver formlen:
n * minpris + a * ln(b * n + c)
I denne formel vælger du først minpris, hvorefter du justerer a, b og c indtil du er tilfreds med kurvens udseende. Specielt skal du være opmærksom på at vælge konstanter så prisen for hhv. 0 stk og 1 stk er fornuftige. Når du arbejder med at man ikke nødvendigvis køber et helt antal styk, så er du nødt til at have en fornuftig pris på 0 stk. Der er selvfølgelig ingen der bestiller 0 stk, men eftersom man kan gå arbitrært tæt på 0, så skal prisen på 0 stk være sat så det betaler for det arbejde du måtte have ved at sælge en så lille stump, at det lige så godt kunne have været 0 stk.
#12
Du skriver at du har erfaring med 2. gradsligninger, og at sproget er ligegyldigt. Jeg antog at du ikke har programmeringserfaring. Da jeg "programmerede" en 2. gradsløser kendte jeg ikke til programmering, og jeg vil stadig ikke kalde det for programmering - og en person der fremhæver at han/hun har "prøvet med 2. gradsligning" lyder i mine ører ikke som en med programmeringserfaring.
Når jeg læser indlæggende igen kan jeg godt se at det nok mest er mig der tager fejl.
Du skriver at du har erfaring med 2. gradsligninger, og at sproget er ligegyldigt. Jeg antog at du ikke har programmeringserfaring. Da jeg "programmerede" en 2. gradsløser kendte jeg ikke til programmering, og jeg vil stadig ikke kalde det for programmering - og en person der fremhæver at han/hun har "prøvet med 2. gradsligning" lyder i mine ører ikke som en med programmeringserfaring.
Når jeg læser indlæggende igen kan jeg godt se at det nok mest er mig der tager fejl.
Jeg tror egentlig det kan generaliseres videre til n * minpris + o(n)kasperd (25) skrev:Dermed bliver formlen:
n * minpris + a * ln(b * n + c)
Med andre ord n * minpris plus hvad som helst, der vokser langsommere end lineært. Sidstnævnte skal dog være en monton funktion. Den må ikke på noget tidspunkt være aftagende. Men hvis den var konstant, ville det intet skade.
Du kunne f.eks. undersøge, hvordan den ser ud, hvis du bruger n * minpris + sqrt(n) * (maxpris - minpris)
Det er for så vidt ligegyldigt. Tråden handler jo ikke om programmering, men derimod om matematik og økonomi.gramps (26) skrev:Du skriver at du har erfaring med 2. gradsligninger, og at sproget er ligegyldigt. Jeg antog at du ikke har programmeringserfaring.
At implementere formlen, når først den rigtige formel er fundet, er så nemt, at en folkeskoleelev, som hørte om programmering første gang for en måned siden, ville være i stand til at implementere det.
Gå til top
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Programmering
Gå til bund