- sziku69: Fűzzük össze a szavakat :)
- Luck Dragon: Asszociációs játék. :)
- moongoose: Jelszóvédett IBM Thinkpad R50e működőképessé tétele.
- ubyegon2: Airfryer XL XXL forrólevegős sütő gyakorlati tanácsok, ötletek, receptek
- sziku69: Szólánc.
- GoodSpeed: Megint 3 hónap Disney+ akciósan :)
- sellerbuyer: Milyen laptopot vegyek? Segítek: semmilyet!
- skoda12: Webshopos átverések
- GoodSpeed: Aquaphor Modern víztisztító
- btz: Internet fejlesztés országosan!
-
LOGOUT
Új hozzászólás Aktív témák
-
pmonitor
aktív tag
válasz
kovisoft #15584 üzenetére
Megnéztem az eredeti kódod C-ben. Itt n=13 esetén ~14, n=14 esetén ~200 sec. alatt fut le. Mint az oldalamra is írtam, azért a C# játékszer a C-hez képest.
-
pmonitor
aktív tag
válasz
kovisoft #15584 üzenetére
Átírtam C#-ra a kódod. Ez nagyon hasít! Az én kódom, meg az egyetemi jegyzetben szereplő algoritmus n=12 esetén eljátszik vele 80 sec-ig, a Tied végez vele ~2 sec alatt. A Tiéd n=13-at megcsinálja 23 sec alatt. n=14-et 5.5 perc alatt. Miért van az, hogy egyetemi jegyzetben is az ócska kód szerepel? Ha 1 ilyen hasító kódot valaki meg tudna írni ismétléses permutációra, ő elég nagy számokra meg tudná oldani a hátizsák problémától kezdve az 1D vágás problémáján keresztül sok mindent!
@K1nG HuNp: légyszíves keress nekem egy robosztus, teljesen tesztelt open source libet, ami tobbet is tud jobban kovisoft kódjánál.
Egyébként hasonlítsd össze a te postodat és kovisoft-ét. Szted melyik ér többet? És érdekes, kovisoft is i, j-t használ.
-
pmonitor
aktív tag
válasz
pmonitor #15559 üzenetére
Ezen az oldalon elkészítettem a permutációk, kombinációk és a variációk kódjait/tesztjeit is. Aki tud valamelyiknél hatékonyabb kódot(vagy algoritmusra mutató linket), őt kérem, hogy ossza meg velünk.
-
pmonitor
aktív tag
Igazából ide írom, mert általános algoritmus(ok)ról van szó. És keveredik az oktatással is. Az ismétléses permutáció algoritmusát ez alapján csináltam meg. A napokban próbáltam optimalizálni. Míg végül a C# topic-ban joysefke ezt a linket adta meg. Ez egyszerűbb is, és kb 4-5-ször gyorsabb.
Az első könyv egy egyetemi jegyzet. Ebben kevéssé érthető és sokkal lassabb algoritmus van. Egy kicsit merész kijelentést teszek ezzel kapcsolatban. Mégpedig azt, hogy lehet csodálkozni, hogy az egyetemeken a nem gyakorlati(hatékony) dolgokat oktatják. Ezért sztem nem lehet csodálkozni, hogy amikor a nebulók kikerülnek az 'oskolából, akkor gyakorlati tudásuk zéró. Nektek mi a véleményetek ezzel kapcsolatban?
Egyébként az ismétléses permutációval kapcsolatos teszteket itt meg lehet nézni. -
pmonitor
aktív tag
válasz
pmonitor #15512 üzenetére
"Error A2026 constant expected include\winextra.inc 11052"
Ezt a hibát írta ki a 11052 és a 11053 sorra a winextra.inc file-ban.
STD_ALERT struct
alrt_timestamp dd ?
alrt_eventname WCHAR [EVLEN + 1] dup (?)
alrt_servicename WCHAR [SNLEN + 1] dup (?)
STD_ALERT endsha kommentbe teszem a következő 2 sort:
alrt_eventname WCHAR [EVLEN + 1] dup (?)
alrt_servicename WCHAR [SNLEN + 1] dup (?)
akkor működik. Csak azt nem tudom, hogy ezt miért nem fogadja el. De az a lényeg, hogy működőképes lett a program. Már ez is műxik.; We access the MangaEden API and request a list of the first 25 available manga. I used a buffer size of 5000, but feel free to modify it.
; I basically learned ASM today, just felt like posting this somewhere.
.386
.model flat, stdcall
option casemap:none
; Includes
include include\windows.inc
include include\kernel32.inc
includelib lib\kernel32.lib
include include\user32.inc
includelib lib\user32.lib
include include\wininet.inc
includelib lib\wininet.lib
WinMain proto :DWORD,:DWORD,:DWORD,:DWORD
; Initialized data
.data
AppName db "GUI App with Buttons",0
ClassName db "Class of GUI",0
ButtonClass db "button",0
ButtonText db "Kattints rám!",0
strTitle db "Cím",0
strMessage db "Hello world!",0
fhwnd dd 0
hwndButton dd 0
.data?
hInstance HINSTANCE ?
CommandLine LPSTR ?
.const
ButtonID equ 1
.code
start:
invoke GetModuleHandle,0
mov hInstance, eax
invoke GetCommandLine
mov CommandLine, eax
invoke WinMain, hInstance,0, CommandLine, SW_SHOWDEFAULT
;invoke MessageBox, 0, ADDR strMessage, ADDR strTitle, MB_OK
invoke ExitProcess, 0
;end start
WinMain proc hInst:HINSTANCE, hPrevInst:HINSTANCE, CmdLine:LPWSTR, CmdShow:DWORD
local wc:WNDCLASSEX
;local fhwnd:HWND
local msg:MSG
mov wc.cbSize, SIZEOF WNDCLASSEX
mov wc.style, CS_HREDRAW or CS_VREDRAW
mov wc.lpfnWndProc, offset WndProc
mov wc.hbrBackground, COLOR_BTNFACE+1
push hInst
pop wc.hInstance
mov wc.lpszMenuName,0
mov wc.lpszClassName, offset ClassName
invoke LoadIcon, 0, IDI_APPLICATION
mov wc.hIcon, eax
mov wc.hIconSm, eax
invoke LoadCursor, 0, IDC_ARROW
mov wc.hCursor, eax
invoke RegisterClassEx, addr wc
invoke CreateWindowEx, 0, \
addr ClassName, \
addr AppName, \
WS_OVERLAPPEDWINDOW, \
CW_USEDEFAULT, \
CW_USEDEFAULT, \
500, \
500, \
0, \
0, \
hInst, \
0
mov fhwnd, eax
invoke ShowWindow, fhwnd, CmdShow
invoke UpdateWindow, fhwnd
.While 1
invoke GetMessage, addr msg, 0, 0, 0
.BREAK .IF (!eax)
invoke TranslateMessage, addr msg
invoke DispatchMessage, addr msg
.ENDW
mov eax, msg.wParam
RET
WinMain endp
WndProc proc hWnd:HWND, uMsg:UINT, wParam:WPARAM, lParam:LPARAM
.if uMsg==WM_DESTROY
invoke PostQuitMessage, 0
.elseif uMsg==WM_CREATE
invoke CreateWindowEx, 0, addr ButtonClass, addr ButtonText, \
WS_CHILD or WS_VISIBLE or BS_DEFPUSHBUTTON, \
170, 100, 140, 25, hWnd, ButtonID, hInstance, 0
mov hwndButton, eax
.elseif uMsg==WM_COMMAND
mov eax, wParam
shr eax, 16
.if eax==BN_CLICKED
mov eax, lParam
.if eax==hwndButton
invoke MessageBox, 0, ADDR strMessage, ADDR strTitle, MB_OK
.endif
.endif
.else
invoke DefWindowProc, hWnd, uMsg, wParam, lParam
ret
.endif
xor eax, eax
RET
WndProc endp
end start -
pmonitor
aktív tag
Valaki használta már a visual studioban a beépített assemblert? Ő talán tudna segíteni. Az itt található kódot próbáltam, de az include-oknál error-ozik. Pl.: "Error A1000 cannot open file : masm32includewindows.inc"
Az itt található kódot is próbáltam, de itt is az include-al és az includelib-el van problémája. Masm32-ben működik ez a kód.
Próbáltam azt, hogy a masm32-ből bemásoltam a file-okat, de az sem tetszik neki.
Tehát a kérdésem az lenne, hogy hogyan lehet az include-okat működésre bírni VS-ben? -
pmonitor
aktív tag
válasz
kovisoft #15484 üzenetére
Elnézést kérek. Tényleg igazad volt. Én ütöttem el a file nevét, vagy nem rendszergazdaként indítottam a keresőt.
Azt hiszem, hogy ami itt történik, azt hívják mutex-nek.
@Silεncε: Neked is igazad volt. Nem a Process.Start() vagy a Createprocess() volt bug-os. Mindenesetre pont beletrafáltam abba a programba, ami másképp működik, mint egy általános program.
Mindenesetre tanulságos volt(és remélem, hogy nem csak nekem). Köszönöm mindenkinek a segítséget.
-
pmonitor
aktív tag
válasz
Fire/SOUL/CD #15487 üzenetére
Megelőztél! Köszönöm! Működik! Csak az a kérdés, hogy általános esetben(amikor egy textbox-ban lehet megadni az indítandó file-t), akkor honnan tudom, hogy a "Calculator.exe" helyére mit kell írnom? Mert a textboxban pl. itt "calc.exe" van. Tehát hogyan lehetne detektálni, hogy egy elindított program úgy viselkedik-e, mint a "notepad.exe"(azonos névvel), vagy úgy, mint a "calc.exe"(ami más néven szerepel a process lista között)?
-
pmonitor
aktív tag
válasz
kovisoft #15484 üzenetére
Nincs is calculator.exe a gépemen. Ettől függetlenül jó helyen kapizsgálsz.
Mert ha mielőtt a programom elindítanám, az előtt elindítom windowsból a calc.exe-t 2-szer, annak mind egy ID-je van. Ha így módosítom a C# kódom, akkor a tömb hossza csak 1, még akkor is, ha a programom a 3., vagy 4. calc.exe-t indította. Egy "normális" programnál mind külön PID-et kapna. De itt a pr_2 tömb hossza csak 1.
using System;
using System.Diagnostics;
using System.Windows.Forms;
namespace TestProcess
{
public partial class Form1 : Form
{
public Form1()
{
InitializeComponent();
}
void OpenWithStartInfo()
{
ProcessStartInfo startInfo = new ProcessStartInfo(textBox1.Text);
startInfo.UseShellExecute = true;
startInfo.WindowStyle = ProcessWindowStyle.Minimized;
Process pr = Process.Start(startInfo);
//textBox2.Text = pr.Id.ToString();
Process[] pr_2 = Process.GetProcessesByName("calc");
textBox2.Text = pr_2.Length.ToString();
}
private void button1_Click(object sender, EventArgs e)
{
OpenWithStartInfo();
}
}
}Tehát végülis nem bug. Ha csak azt nem nevezzük bug-nak, hogy akármennyi calc elindítása után is csak 1 pid van. Mert végülis ezáltal nem működik.
De megnéztem 1 64 bites win 7-es laptopon, ott jó pid-t ad vissza. Csak a win 10-en nem jó.
Befonom a szemöldököm.
-
pmonitor
aktív tag
válasz
pmonitor #15478 üzenetére
A C# kód, ami invalid értéket ad vissza Az itt található példakód alapján csináltam.
using System;
using System.Diagnostics;
using System.Windows.Forms;
namespace TestProcess
{
public partial class Form1 : Form
{
public Form1()
{
InitializeComponent();
}
void OpenWithStartInfo()
{
ProcessStartInfo startInfo = new ProcessStartInfo(textBox1.Text);
startInfo.WindowStyle = ProcessWindowStyle.Minimized;
Process.Start(startInfo);
Process pr = Process.Start(startInfo);
textBox2.Text = pr.Id.ToString();
}
private void button1_Click(object sender, EventArgs e)
{
OpenWithStartInfo();
}
}
}@kavalkád: nem Neked szólt. A post-odat még nem láttam, amikor írtam. De kipróbáltam az első paraméterbe NULL-al, a másodikban a file-névvel. Úgy sem működik rendesen. Viszont ha Delphiben működik, akkor lehet, hogy tényleg én szúrok el valamit. Csak nem tudom, hogy mit.
-
pmonitor
aktív tag
válasz
Silεncε #15476 üzenetére
Azt nem tudom. Abban igazad van, hogy lehet, hogy nem bug, hanem én szúrok el valamit. A Code:: Blocks-ban lévő próbálkozásomat bemásolom.
#include <windows.h>
#include <stdio.h>
void tesztpprocess()
{
STARTUPINFO si;
PROCESS_INFORMATION pi;
ZeroMemory(&si, sizeof(si));
si.cb = sizeof(si);
ZeroMemory(&pi, sizeof(pi));
if (!CreateProcess("C:\\WINDOWS\\SYSTEM32\\Calc.exe", NULL, NULL, NULL, FALSE, 0, NULL, NULL, &si, &pi))
{
printf("CreateProcess failed (%d).\n", GetLastError());
return;
}
WaitForSingleObject(pi.hProcess, INFINITE);
printf("%d", pi.dwProcessId);
getchar();
CloseHandle(pi.hProcess);
CloseHandle(pi.hThread);
}A GetLastError nem ad errort.
-
pmonitor
aktív tag
válasz
fatal` #15471 üzenetére
Belegondolsz, akkor a win api-t is elszúrták, nem csak a VS-t. Írok egy példát, amibe nemrég szaladtam bele.
C#-ban elindítok Process.Start-al 1 programot(pl. Calc.exe). Idáig végzi is a dolgát, úgy ahogy kell. Lekérdezem a Process ID-t. Látszólag ez is végzi a dolgát, mert 1 értéket beletesz. Csakhogy ez az érték nem a Process ID-je. Tehát Invalid értékkel tölti fel(a feladatkezelőben teljesen más érték van). Azért a biztonság kedvéért megpróbáltam Kill-el kilőni. Természetesen nem sikerült(mivel egy false ID-t tartalmaz). A Kill egyébként működik, mert ha a feladatkezelőből meg nézem az elindított programot, akkor valóban kilövi.
Na mondom, biztos a VS "szórakozik". Megpróbáltam win api-val, CreateProcess-el(továbbra is C#-ban). Getlasterror nem ad errort. Viszont az ID itt is Invalid.
Na, mondom megyek tovább. Még mindig VS-el, de már C++-ban. Az ID itt is invalid.
Na, mondom megyek még tovább: Code:locks. Az eredmény itt is Invalid ID. Tehát nem VS specifikus probléma. Masm32-vel még nem próbáltam, de sztem ott is ugyanez a jelenség lenne.
Az eddigi post-jaimból is kitűnt, hogy nem vagyok kibékülve olyanokkal, akik "programozó szakiknak" állítják be magukat a fórumokon(messziről jött ember azt ír magáról, amit akar). Mondjuk ez a határozott véleményem elsősorban a prog.hu-s tapasztalataimból ragadt rám. De hogy a Microsoft-nál is a vezető szerepben lévő "programozók is ilyen sz"-t adjanak ki a kezükből...
-
pmonitor
aktív tag
válasz
Livius #15458 üzenetére
A kérdésem az hogy portableként bármilyen setup.exe nélküli Java progit hogyan tudsz futtatni?
Azért tegyük hozzá, hogy kell hozzá a nem kis méretű framework. Igaz, hogy most már alapból benne van a win-ben. De nem volt ez mindig így. Az xp-re pl. külön kellett telepíteni.
Ettől függetlenül nekem is tele van a t...m a több megás telepítendő programokkal. Ezek csak azért ilyen méretűek, hogy csili-vili legyen a progi, és hogy (ugyan törhetetlen progi nincs) minél jobban védjék törés ellen. Arról nem is beszélve, hogy teleszemetelik a registryt. Ha csak az én fő programom nézzük(1D vágás ), ez egy 14 kb-os .exe-ből, és egy 22 kb-os .dll-ből áll. Telepíteni nem kell. Nézd meg pl. a hasonló free programot. Biztosra veszem, hogy telepíteni kell(azért, mert évente meg kell újítani a licence-t). És a file sem hiszem, hogy 35 kb. körül van. Bár nem próbáltam ki. Minek? Azért, hogy telepítés után eltávolítsam? Erről beszélek. Mondjuk a mai hardveren igaz, hogy elfér, de szinte minden program telepítéssel működik. Azért a sok "nagy" sokra megy.
-
pmonitor
aktív tag
Igen, igazad van. Nem is arra gondoltam, hogy az összes funkcióját megcsinálom(főleg egyedül). Csak ez nagyon feltűnt próba nélkül is, hogy feleslegesen írja ki a mappákat. És pont témába vágott. Ezért hoztam fel. Mondjuk hozzá kell tenni, hogy a teszt programom bár C#-ban készült, de win api függvényeket használ(FindFirstfile-FindNextFile a szíve neki). És ha egy win api függvény működik C#-ban, akkor az sebességben alig marad el pl. a C/C++-tól(legalábbis nagy mértékben biztos, hogy nem).
Szóval csak izgatott a téma. Ezért is készítettem hirtelen felindulásból egy teszt programot.
-
pmonitor
aktív tag
válasz
kovisoft #15381 üzenetére
A c:\ meghajtóm a TC stabilan 4:10 alatt listázza ki(függetlenül attól, hogy hányszor futtatom le).
Az én programom az első futtatáskor 2:50 alatt, de utána van, hogy 0:33 alatt végez vele.
De ha egyszerre indítom mindkettőt, akkor közel egyszerre végeznek.Ha a programomnál a 2:50-es időt nézzük, akkor is 1:20-al kevesebb idő kell neki, mint a TC-nek. Ez nagyon sok.
Mondjuk a programom most karikázik, mert a UI szálon futtatom, ezt légyszi nézze el, aki kipróbálja.
-
pmonitor
aktív tag
válasz
pmonitor #15378 üzenetére
Készítettem Made in Hirtelen egy teszt alkalmazást. FindFirstFile-FindeNextFile felhasználásával. Tesztelhetitek ti is. Nálam ez sokkal gyorsabb a TC-nél(pedig ez C#-ban van, a TC meg gondolom C++-ban lehet). Tehát a TC a kiírással nagyon sok időt pazarol el. Az ad-hook programomban még sok puffer van azáltal, hogy nem írja ki, hogy hol keres éppen.
De érdekes módon, ha a 2 program egyszerre fut, akkor majdnem egyszerre végeznek. Ezt nem értem, hogy miért van? Ha valaki tudja erre a választ, ő megírhatná, hogy mi lehet a magyarázat erre. A program letölthető innen. FindFirstFile.rar.
-
pmonitor
aktív tag
válasz
kovisoft #15376 üzenetére
sokkal gyűlöletesebb user interface a szimpla kerregő homokóra és társai
Az én programom tényleg semmit nem csinál, még csak nem is homokórázik.
Annyi változik, ha elindítod a 3 "Start" gomb egyikét, hogy a felirata "Stop"-ra változik. Ha végzett, akkor pedig megjelenik a középső szövegmezőben az eredménye és a gombon a "Stop" felirat ismét "Start" lesz.De nekem az volt a célom, hogy ha nem is támogatja a programom az egyidejű futtatást, akkor is a user-nek lehetőséget adjak rá. Ezért imádom a programozást, mert(a nagyon alap dolgok kivételével) ugyanazt a dolgot "millióképpen" meg lehet valósítani.
-
-
pmonitor
aktív tag
válasz
axioma #15372 üzenetére
És user-ként mit tudok csinálni, ha tudom, hogy xy mappában tölt sokat? Vagy kivárom, vagy leállítom a keresést. De ugyanezt meg tudom csinálni akkor is, ha nem tudom, hogy hol időzik sokat. Tehát teljesen felesleges ezeknek a kiírása. Csak lassabb lesz a keresés.
Ez épp olyan dolog, mint pl. az ötöslottó ~44 misis kombinációja: ha csak legenerálja a program, akkor <1 sec. alatt végez. Viszont ha ki is iratom, akkor órák alatt fut csak le.
Jó, mondjuk a mappák kiírásával nem órákat veszít a tc-ben a user, de azért érzékelhetően gyorsabb lenne, ha nem írná ki a mappákat.
-
pmonitor
aktív tag
válasz
dabadab #15321 üzenetére
Nem az volt a kérdés. Domonkos kérdése ez volt:
>Vannak esetek, amit nem vesz észre.
Egy peldat szeretnek kerni!A tőlem való idézet(az én állításom) ez volt teljes egészében :
De azért a fordító sem mindig olyan okos. Vannak esetek, amit nem vesz észre. De mondjuk azt meg a programozónak kellene észrevennie(viszont az biztos, hogy legtöbbször nem sikerül).Tehát már nem az assembler volt a kérdés, hanem a C fordító! Csak te ragadtál le az assembleres témánál. De ha pontosak akarunk lenni, akkor az eredeti kérdés sem az volt, hanem hogy kép manipulálását hogy lehet assemblerben gyorsítani(szóba sem került eredetileg a C/C++.
-
pmonitor
aktív tag
válasz
dabadab #15317 üzenetére
Ha megnézed, akkor láthatod, hogy a többiek értik a dolgot, csak nem értenek vele egyet.
cattus-tól:
hogy a gcc egy speciális esetben éppen nem optimalizál egy specifikus use-case-t?Livius-tól:
Most nem azért, de olyan optimalizálást vársz el,Mindenki optimalizálási dolognak látja, csak te nem. Illetve Domonkos álláspontját nem tudom, mert nem fejtette ki.
-
pmonitor
aktív tag
válasz
cattus #15315 üzenetére
Most tényleg azon lovagolsz, hogy a gcc egy speciális esetben éppen nem optimalizál egy specifikus use-case-t?
Hát ha nagyon sarkosan akarunk fogalmazni(és mindent rám akarsz hárítani), akkor igen.
De ez az egész ott kezdődött, hogy Domonkos példát szeretett volna látni.
Én csak erre írtam példát. Aztán jött a többi...
-
pmonitor
aktív tag
válasz
Livius #15313 üzenetére
a gcc-nek nem az a feladata hogy a te C nyelvedet alakítsa alternatív jobbra
Sztem az lenne a feladata, hogy amit az alkotó C-ben ír, azt hajtsa végre a megfelelő beállítás mellett. Tehát, ha az alkotó arra utasítja pl. a -Ofast-al, hogy optimális kódot állítson elő, akkor azt kellene csinálnia. Nem véletlenül írta kovisoft:
Ez a gyakorlatban úgy szokott történni, hogy megnézed, milyen kódot generált a sebességre optimalizált fordító, átírod olyanra, ahogy szerinted gyorsabb lenne, kipróbálod, majd nyugtázod, hogy a te verziód lassabb lett, és mégis a fordító tudta jobban.
Ő is a sebességre optimalizált fordítóra hivatkozik. Akkor szted mit jelent a sebességre optimalizálás, ha semmit nem alakíthat át? Tehát úgy optimalizáljon, hogy közben mégsem optimalizál? Ilyen alapon 2 darab XOR utasításnak kellene lennie, mert szted nem "nyúlhatna" hozzá a C-ben írt kódhoz? Ugye ezt nem gondolod komolyan? Sztem meg kötelező hozzányúlnia a sebesség érdekében, ha a sebességre optimalizálást adták meg neki.
-
pmonitor
aktív tag
válasz
Livius #15310 üzenetére
Sztem félreértetted a kérdésem. Az első formulát írod forráskódba. Ebből kellene észrevennie a fordítónak, hogy a második formulára alakítható a forráskód. Tehát az első kódból is ugyanazt kellene generálnia, mint a másodikból. Ezt nem ismerte fel.
szerk.: az összeadás-kivonás lassabb, mint a XOR.
-
pmonitor
aktív tag
válasz
Domonkos #15302 üzenetére
Pl. klasszikus eset a kis- nagybetű konverzió. Ez az általános eset:
if (c >= 'a' && c <= 'z') {
c -= 32;
}
else if (c >= 'A' && c <= 'Z') {
c += 32;
}ezt meg lehet így is oldani:
if (c >= 'a' && c <= 'z') {
c ^= 32;
}
else if (c >= 'A' && c <= 'Z') {
c ^= 32;
}Észreveszi a fordító?
-
pmonitor
aktív tag
válasz
Mechorganic #15287 üzenetére
Esetleg még azt lehet csinálni, hogy az egészet megírod C-ben/C++-ban. A sebességkritikus rész(ek) kódját megnézed, és ha találsz benne olyan részt, ahol szted lehet gyorsítani, akkor azokat megírhatod C-be/C++-ba ágyazott assemblyben. Macerás, de ha a gyorsaság számít, akkor talán ez a legegyszerűbb.
-
pmonitor
aktív tag
válasz
axioma #15223 üzenetére
"Miert, te ismetlesesen kezeled?"
Idézet innen:
Ha ezzel megvagyunk, akkor "megkeverjük" a sorrendet. Megint megnézzük, hogy így mennyi szálra fér rá. stb...
...
A "megkeverés" lehet "véletlenszerűen", vagy ismétléses permutációval. A "véletlenszerű" megkeverésnek is lehet kismillió formája.Ezen mi nem volt egyértelmű?
Mondjuk én is befejeztem(legalábbis itt). De ha lesz időm, akkor ez megér egy "misét" a fórumokról való szubjektív véleményemben.
-
pmonitor
aktív tag
válasz
axioma #15219 üzenetére
"Bocs, engedd mar meg nekem hogy azzal hobbizzak, ami nekem a leginkabb szorakoztato"
Én megengedem. Viszont téged csak addig "érdekelt", amíg kötekedtél velem, meg az állítólagos "tudásoddal" villogni előttem.
"Ha fizetsz erte, az mas, akkor szamon kerhetsz teljesitmenyt"
Akármennyit fizetnék érte, akkor sem oldanád meg, hiába mondod magad matematikusnak....
-
pmonitor
aktív tag
válasz
axioma #14995 üzenetére
"Matematikus vagyok"
Itt írtam, hogy ez a feladat kifog a "szakikon".
"tehat a te algod halalra szenvedne' magat feleslegesen egy 50 db 305 centis megrendelesen... 50! azonos megoldasbol kiszamolna egy maroknyit."
Ismétléses permutációról beszéltem, tehát nem 50!, hanem ebben az esetben az alsó "Start" gomb 1-szer fut csak le. A felső 2 "Start" gomb meg annyiszor, amennyire beállítod...
Úgy látszik, hogy te is ebbe a körbe tartozol.... Én még most is azt mondom, hogy sosem készülsz el vele... Bár ne lenne igazam!
-
pmonitor
aktív tag
A MyTimers.dll nem használható Wpf .Net Framework-ben, ezért elkészítettem a MyWpfTimers.dll-t. A következő linken található kóddal lehet tesztelni a wpf timer, és az általam készített timer pontosságát. Az általam készített timer van a felső Label-ben.
-
-
pmonitor
aktív tag
válasz
dabadab #15162 üzenetére
"Az annak az időszaknak a HW-jére lett optimalizálva"
Az a HW viszont sokkal lassabb volt, mint a mai HW. Úgyhogy ha a mai HW-n is fut, akkor sztem nem olyan lassú. Ilyen alapon a C++ is '90-es évek. Egy programnyelvnél sztem nem az a lényeg, hogy a '80-as vagy '90-es években létezett-e, hanem az, hogy fejlesztik-e, vagy leálltak-e a fejlesztéssel?
-
pmonitor
aktív tag
Vissza csináltam a színeket az előzőre, mert a fehér nem tetszett.
-
pmonitor
aktív tag
válasz
K1nG HuNp #15139 üzenetére
"a zero css oldal addig kell amig nem ertesz a designhoz"
Egész eddig az ellenkezőjéről beszéltél.
" oszinten sokat megadnek neha egy css nelkuli htmles doksiert ahol ha keresek valamire akkor nem kell 5mpig egy loadert meg 24 animaciot neznem"
Kettős mérce? Azt hiszem ezt is bele írom a forums.php-be, ha lesz időm.
-
pmonitor
aktív tag
Az a baj, hogy a szubjektív dolgokban nem lehet nyugvópontra jutni. Még ti is vitatkoztok.
Nem lehet mindenki kedvére tenni.
Nekem pl. a koronavirus.gov.hu sem jön be. Egyikőtök azt mondja, hogy kell a csicsa, a másik azt mondja, hogy nem.
Amit k1ng_hunp írt, annak nagyjából eleget tettem. Blogszerűre változtattam a webhelyem főoldalát.
Rimuru talált 1 nem jelentős bug-ot, azt is javítottam.A színeken már igazán nem szeretnék vitatkozni.
-
pmonitor
aktív tag
válasz
dabadab #15072 üzenetére
Tényleg zavaró, hogy az újoncok csak 1szer írhatnak...
Engem egyébként a tartalom érdekel jobban. Ha a Cutter-t megnézed, az se design-os. Nem vagyok híve a túlcicomázásnak, és nem is értek hozzá(itthon a bútorok terén sem).
Ennek ellenére ha valaki konkrét megoldási javaslattal áll elő(mint pl. K1nG HuNp) azt (természetesen szelektálva), de figyelembe veszem.De ezzel, hogy: " jóval bonyolultabb téma annál, mint hogy egy mondatban le lehessen tudni" nem tudok mit kezdeni. Ez így elég flame.
Egyébént megnéztem a https://itcafe.hu/temak/szoftverfejlesztes/listaz.php oldalt a html és css validatorban. Hát annyi hibát kidobott, hogy csak na... Ez a jobb? Az enyém megnézheted.
-
pmonitor
aktív tag
válasz
axioma #15015 üzenetére
"Hany masodperc vagy perc az elfogadhato futasido a linkelt peldan?"
max. 60-70 sec. Ez szerintem még határesetben belefér az emészthető futásidőbe.
"Mi a celod: penzt kerni a _gyakorlatban_ jobb algoert"Egyébként alapvetően a teljesen ingyenes szoftverek híve vagyok(pénzt csak olyan formában fogadnék el, ha lenne olyan, aki elégedett lenne a programmal, és ezért adná-úgymond köszönetként-). Pénzt csak olyan kérhetne, aki megtalálná az optimális megoldást, és kezelné a dőlt végződésűeket is. A gyakorlati célom, hogy a 60-70 sec. alatt a 96 darabos példán minél közelebb legyek az általam ismert legjobb esethez, ami 22 szálban 3709 mm. Jelenleg a programom ez idő alatt 3431 mm-es legnagyobb leeső darabot talál meg. Ez majdnem 28 centivel rövidebb a 3709 mm-esnél. Ezt a különbséget szeretném levinni 10 centi alá(tehát min. 3609 mm-es leeső darabot találna). Ha ez sikerülne anélkül, hogy a wikis és a 85 darabos példán a mostani eredmény csorbulna, az nekem gyakorlatban megfelelne.
Arra, hogy adott időn belül kezelje a 45 fokos vágást is ezen a három vágásmintán, arra nincs esély, ezért ez nem kritérium.
-
pmonitor
aktív tag
Ez komoly, hogy a Pécsi Tudományegyetem a prog.hu-t ajánlgatja olvasandó fórumnak?
Tervezem, hogy csinálok egy forums.php oldalt, hogy hogy zajlik a fórumozás(főleg a prog.hu-n, de úgy általában is).
-
pmonitor
aktív tag
válasz
axioma #14995 üzenetére
A wikin található példa 140 mm-es legnagyobb leeső darabbal számol. Az algoritmusomban ez 580 mm. Sztem az 58 centis mégiscsak jobb, mint a 14 centis. Mert a következőben sokkal nagyobb valószínűséggel lehet használni.
Az ilyen(x fokban végződő) levágandó darabokról nem is beszélek:
Csak az a gond, hogy sokan lóvét kérnek(nem is keveset) azzal a szlogennel, hogy optimalizál a programjuk, holott ezt nem tudják bebizonyítani.
-
pmonitor
aktív tag
válasz
axioma #14967 üzenetére
szoval kicsit tul lehet lepni a "hat ennel nem is tudhat tobbet a program, matematikailag" a gyakorlati oldalra.
Az a baj, hogy ha a gyakorlatot nézzük, akkor az alap feladat megoldhatatlan(ahogy az oldalamon is írtam). Vagy Te meg tudod oldani? Mert akkor szabadalmaztathatod az algoritmusod, ugyanis esélyes vagy a Nobel díjra!!! Az a baj, hogy beszélni nagyon könnyű addig, amíg nem foglalkozik vele az ember.
[link] -> itt is foglalkozom a problémával. -
pmonitor
aktív tag
válasz
Dr.Szilícium #14971 üzenetére
Szia!
Én is belefutottam ebbe. Sztem azért van ez így, mert újoncok vagyunk(mint ahogy vki írta is). Gondolom ha prémium tagok lennénk, akkor nem lenne ilyen probléma...
-
pmonitor
aktív tag
válasz
axioma #14967 üzenetére
"a usertol a vagasi szelesseget (veszteseget) kell elkerni meg a rahagyas nelkuli adatokat"
A ráhagyás és vágásszélesség nélküli adatokat kérem be. A user döntené el, hogy a ráhagyásnál nem ad meg semmit, csak a vágásszélességet adja meg, vagy a ráhagyást és vágásszélességet egyben. Tehát +1 döntést adok a user kezébe. Rá bízom a döntést.
Egyébként fémiparban úgy tudom, hogy nem szoktak szó szerinti ráhagyást hagyni. De pl. a faiparban igen. Itt külön nevet is kapott. Szabásméret a neve. A döntés mindenesetre a user kezében van.
"Mar ha ez nem csak gyakorlo feladat, hanem hasznaloja is lenne."
Megmondom őszintén, hogy még magam sem tudom. Az elején egyértelműen az mellett voltam, hogy ez inkább elméleti feladat, mert gyakorlatban megoldhatatlan(bár én találtam ki a "véletlen" számokkal történő algoritmust). De nem gondoltam volna, hogy "véletlen" számokkal egész jó eredményt lehet elérni. Ahogy írom is az oldalamon, a 96 darabos mintánál pl. az optimális sorrendet nem találja meg. Tehát az eredeti "elutasításból" kezdek talán abba az irányba elmozdulni, hogy talán gyakorlatban is használható. Nem tudom...
-
pmonitor
aktív tag
válasz
axioma #14959 üzenetére
"nem csak kb jo"
Sztem meg csak kb. Az első darab elejére és az utolsó darab végére miért is teszed rá a fél vágásszélességet?
A középső darabokra 1 vágásszélességet kellene számolni, a 2 szélsőre meg felet. Így lenne pontos. De így már borul az algo is.Jó, mondjuk itt már lehetne agonizálni, hogy a 2 vége vinklibe van-e?
-
pmonitor
aktív tag
válasz
axioma #14955 üzenetére
Szia!
Többé-kevésbé jó, ha csak az elején adom hozzá a méretekhez(nem pontosan, de kicsire nem adunk
). Módosítottam is az oldalamon: [link]
Lásd: "Ha érdeklődés van rá, akkor csinálhatok egy NumericUpDown-t, ahol meg lehet adni, hogy mennyi ráhagyást számoljon a program az összes darabra fixen.
Ha nem fixen számolnám rá az elején, hanem minden sorrendnél figyelembe venném a vágások számát is, az jelentősen megnövelné a futás idejét."Köszönöm az észrevételeket, és várom a továbbiakat is.
-
pmonitor
aktív tag
Sziasztok!
Ha valakiket érdekel a "Knapsack problem" kistestvére, a "Cutting stock problem" vagyis az "1d vágás optimalizálás problémája", Nekik készítettem C#-ban 1 dll-t. A következő oldalamon lehet megnézni egy teszt programmal együtt: [link] . Örömmel várnék észrevételeket, kritikákat ide is, valamint az elérhetőségeimen.
Új hozzászólás Aktív témák
● olvasd el a téma összefoglalót!
- LENOVO IdeaPad L340-17IRH - 17,3"FHD IPS - i7-9750H - 16GB - 1TB - Win10 - GTX 1650 - MAGYAR
- Bomba ár! Dell Latitude E7450 - i5-5GEN I 8GB I 256SSD I 14" HD I HDMI I Cam I W10 I Garancia!
- BESZÁMÍTÁS! GigaByte H610M i5 14400F 16GB DDR4 512GB SSD RTX 3060 Ti 8GB Kolink Observatory RGB 800W
- HIBÁTLAN iPhone 14 256GB Midnight -1 ÉV GARANCIA - Kártyafüggetlen, MS3242
- Olcsó Notebook! Dell Latitude E7280! I5 7300U / 8GB DDR4 / 256GB SSD!
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft.
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest