Permalänk

Någon som är bra på java?

På Rosettacode.org:
http://rosettacode.org/wiki/Pascal%27s_triangle/Puzzle#Java

Ett pussel på pascals triangel. Det fungerar bra i c men hänger sig i java.
Några tips?
I go räknar det fel med Raspberry Pi (ARM64) men rätt med x86.....

Permalänk
Medlem
Skrivet av Greyguy1948:

På Rosettacode.org:
http://rosettacode.org/wiki/Pascal%27s_triangle/Puzzle#Java

Ett pussel på pascals triangel. Det fungerar bra i c men hänger sig i java.
Några tips?
I go räknar det fel med Raspberry Pi (ARM64) men rätt med x86.....

För tydlighets skull, har du någon konkret fråga att rikta till någon som är bra på java (och/eller go)?

Eller är det mest besvikelse över kvaliteten på implementationerna?

Visa signatur

Desktop spel m.m.: Ryzen 9800X3D || MSI X870 Tomahawk Wifi || MSI Ventus 3x 5080 || Gskill FlareX 6000 64GB || Kingston KC3000 2TB || Samsung 970 EVO Plus 2TB || Samsung 960 Pro 1TB || Fractal Torrent || Asus PG42UQ 4K OLED
Arbetsstation: Ryzen 7945HX || Minisforum BD790i || Asus Proart 4070 Ti Super || Kingston Fury Impact 5600 65 GB || WD SN850 2TB || Samsung 990 Pro 2TB || Fractal Ridge
Proxmox server: Ryzen 5900X || Asrock Rack X570D4I-2T || Kingston 64GB ECC || WD Red SN700 1TB || Blandning av WD Red / Seagate Ironwolf för lagring || Fractal Node 304

Permalänk
Skrivet av evil penguin:

För tydlighets skull, har du någon konkret fråga att rikta till någon som är bra på java (och/eller go)?

Eller är det mest besvikelse över kvaliteten på implementationerna?

Nu har jag bara Java på Raspberry Pi så det kan ju vara något galet med den (som med Go)
Fungerar programmet med java på en X86?

Permalänk
Medlem

Java kör ju i en egen virtuell maskin för att kunna vara mer plattformsoberoende, så i stora drag ska ju åtminstone så här enkla program fungera likadant oberoende av plattform och operativsystem.

Men med det sagt, "hänger sig i java" är inte en tillräckligt bra beskrivning av felet för att någon över huvud taget ska kunna ha en chans att lista ut vad det är för problem du egentligen har.

Jag provade att köra koden på x64-linux och bortsett från att det tog strax under 2 minuter att köra klart så var det då inga problem utöver det?

$ time java PascalsTrianglePuzzle Solution = [16.0, 24.0, 17.0, 12.0, 41.0, 29.0, 81.0, 70.0, 5.0, 13.0, 8.0] X = 5.00 Y = 13.00 Z = 8.00 real 1m53.188s user 1m54.185s sys 0m1.341s

Visa signatur

The power of GNU compiles you!
"Often statistics are used as a drunken man uses lampposts -- for support rather than illumination."

Permalänk
Datavetare
Skrivet av Greyguy1948:

På Rosettacode.org:
http://rosettacode.org/wiki/Pascal%27s_triangle/Puzzle#Java

Ett pussel på pascals triangel. Det fungerar bra i c men hänger sig i java.
Några tips?
I go räknar det fel med Raspberry Pi (ARM64) men rätt med x86.....

FYI: det är inte RPi som "räknar fel" i Go. Go-versionen har ett gäng buggar i sig och det bara råkar fungera ändå på vissa CPU-arkitekturer.

Ett sätt att rätta programmet är detta

package main import ( "fmt" "math" ) // representation of an expression in x, y, and z type expr struct { x, y, z float64 // coefficients c float64 // constant term } var epsilon = math.Nextafter(1, 2) - 1 // add two expressions func addExpr(a, b expr) expr { return expr{a.x + b.x, a.y + b.y, a.z + b.z, a.c + b.c} } // subtract two expressions func subExpr(a, b expr) expr { return expr{a.x - b.x, a.y - b.y, a.z - b.z, a.c - b.c} } // multiply expression by a constant func mulExpr(a expr, c float64) expr { return expr{a.x * c, a.y * c, a.z * c, a.c * c} } // given a row of expressions, produce the next row up, by the given // sum relation between blocks func addRow(l []expr) []expr { if len(l) == 0 { panic("wrong") } r := make([]expr, len(l)-1) for i := range r { r[i] = addExpr(l[i], l[i+1]) } return r } // given expression b in a variable, and expression a, // take b == 0 and substitute to remove that variable from a. func substX(a, b expr) expr { if b.x == 0 { panic("wrong") } return subExpr(a, mulExpr(b, a.x/b.x)) } func substY(a, b expr) expr { if b.y == 0 { panic("wrong") } return subExpr(a, mulExpr(b, a.y/b.y)) } func substZ(a, b expr) expr { if b.z == 0 { panic("wrong") } return subExpr(a, mulExpr(b, a.z/b.z)) } // given an expression in a single variable, return value of that variable func solveX(a expr) float64 { if math.Abs(a.x) <= epsilon || math.Abs(a.y) > epsilon || math.Abs(a.z) > epsilon { panic("wrong") } return -a.c / a.x } func solveY(a expr) float64 { if math.Abs(a.x) > epsilon || math.Abs(a.y) <= epsilon || math.Abs(a.z) > epsilon { panic("wrong") } return -a.c / a.y } func solveZ(a expr) float64 { if math.Abs(a.x) > epsilon || math.Abs(a.y) > epsilon || math.Abs(a.z) <= epsilon { panic("wrong") } return -a.c / a.z } func main() { // representation of given information for bottom row r5 := []expr{{x: 1}, {c: 11}, {y: 1}, {c: 4}, {z: 1}} fmt.Println("bottom row:", r5) // given definition of brick sum relation r4 := addRow(r5) fmt.Println("next row up:", r4) r3 := addRow(r4) fmt.Println("middle row:", r3) // given relation y = x + z xyz := subExpr(expr{y: 1}, expr{x: 1, z: 1}) fmt.Println("xyz relation:", xyz) // remove z from third cell using xyz relation r3[2] = substZ(r3[2], xyz) fmt.Println("middle row after substituting for z:", r3) // given cell = 40, b := expr{c: 40} // this gives an xy relation xy := subExpr(r3[0], b) fmt.Println("xy relation:", xy) // substitute 40 for cell r3[0] = b // remove x from third cell using xy relation r3[2] = substX(r3[2], xy) fmt.Println("middle row after substituting for x:", r3) // continue applying brick sum relation to get top cell r2 := addRow(r3) fmt.Println("next row up:", r2) r1 := addRow(r2) fmt.Println("top row:", r1) // given top cell = 151, we have an equation in y y := subExpr(r1[0], expr{c: 151}) fmt.Println("y relation:", y) // using xy relation, we get an equation in x x := substY(xy, y) fmt.Println("x relation:", x) // using xyz relation, we get an equation in z z := substX(substY(xyz, y), x) fmt.Println("z relation:", z) // show final answers fmt.Println("x =", solveX(x)) fmt.Println("y =", solveY(y)) fmt.Println("z =", solveZ(z)) }

Dold text

Att använda '==' ihop med flyttal är nästan alltid en bug.

Java-versionen må vara horribelt långsam på RPi4, men det blir då i alla fall rätt för mig (kör ARM64 versionen av Ubuntu 20.04). Go-versionen blir klar på bråkdelen av en sekund medan Java-versioner tar minuter att köra.

Visa signatur

Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer

Permalänk

Tack så mycket för hjälpen alla!
Nu har jag kört java på ARM32 och det tog 10min 25sek
Jag är lite otålig då C och C++ klarar detta på 5 ms
Någon fix så att java går snabbare?

Permalänk
Medlem
Skrivet av Greyguy1948:

Tack så mycket för hjälpen alla!
Nu har jag kört java på ARM32 och det tog 10min 25sek
Jag är lite otålig då C och C++ klarar detta på 5 ms
Någon fix så att java går snabbare?

Nu gissar jag, men när det handlar om en så stor tidsskillnad så är det antagligen så att de använder olika algoritmer för att lösa problemet. Java må vara långsamt, men det är oftast inte många många storleksordningar långsammare. Kolla om de är implementerade på samma sätt.

Permalänk

Ser ut som om allt inte måste köras i flyttal. C++ gör det mesta i integer.
Men Algol 68 kör med REAL och klarar det på 0,3 sek (Jaguar 2 GHz)
Har just provat julia på samma cpu.
Det tog 2,0 sek första gången och 0,5 sek andra gången. JULIA kräver betydligt mer minne än de flesta andra.