[java] 6-cijferige codes categoriseren

[Rien43]

Beste tweakers,

Voor een java-applicatie heb ik diverse objecten in een array met elk een 6-cijferige code. Deze objecten wil ik categoriseren. De categorieën zijn ook altijd 6-cijferige codes. Zie onderstaand als voorbeeld.



Met kleuren heb ik in bovenstaande afbeelding aangegeven hoe deze categorisatie plaats moet vinden (welke objecten onder welke categorie dienen te vallen). Eigenlijk kan je stellen dat de laatste 0-en in de code als wildcard dienen, waarbij het dus niet uitmaakt wanneer in de objectcode andere cijfers zijn opgenomen.

Mijn idee is om middels een for-loop door de objecten te gaan en de objectcodes te vergelijken met de codes in een array met categorieën. Deze directe vergelijking (vb. 512000 = 512000) lukt mij nog wel. Echter, hoe kan ik er voor zorgen dat de laatste 0-en (bijv. 512***) als wildcard dienen en ook in de vergelijking meegenomen worden (waarbij dus de code 512500 ook onder de categorie 512000 komt te vallen).

Alvast bedankt voor het meedenken!

Aanvulling:
In het voorbeeld zijn het inderdaad de eerste 3 karakters die er toe doen. Echter, de crux zit 'm in het feit dat het ook codes kunnen zijn als 572351. Deze zal dan in het voorbeeld onder de categorie 572000 moeten vallen.

Ook dient in het voorbeeld 611100 te vallen onder categorie 610000.

De categoriecodes liggen niet vast, dus zijn variabel. Het kan dus ook zijn dat de categoriecodes specifieker zijn, zoals 572100 of 572150. Dan moet de categorisatie van objecten dus nog steeds werken.

[ Voor 19% gewijzigd door Rien43 op 19-07-2021 13:30 ]

[spone]

Ben je feitelijk niet gewoon enkel naar de eerste 3 karakters aan het kijken voor de vergelijking? Dus is je categorie effectief 651, 610, 572, 311, 310? Dan kan je de eerste 3 karakters van je object pakken en die matchen aan je categorie.

[RobIII]

Categorie / 1000

[ Voor 10% gewijzigd door RobIII op 19-07-2021 12:22 ]

[Rien43]

In het voorbeeld zijn het inderdaad de eerste 3 karakters die er toe doen. Echter, de crux zit 'm in het feit dat het ook codes kunnen zijn als 572351. Deze zal dan in het voorbeeld onder de categorie 572000 moeten vallen.

Ook dient in het voorbeeld 611100 te vallen onder categorie 610000.

De categoriecodes liggen niet vast, dus zijn variabel. Het kan dus ook zijn dat de categoriecodes specifieker zijn, zoals 572100 of 572150. Dan moet de categorisatie van objecten dus nog steeds werken.

[ Voor 38% gewijzigd door Rien43 op 19-07-2021 12:32 ]

[spone]

Dan inderdaad in het verlengde van wat @RobIII zegt, ((int)(categorie/1000))*1000

Met extra toegevoegde info ligt dit wat lastiger.

[ Voor 25% gewijzigd door spone op 19-07-2021 12:33 ]

[Rien43]

spone schreef op maandag 19 juli 2021 @ 12:32:
Dan inderdaad in het verlengde van wat @RobIII zegt, ((int)(categorie/1000))*1000

Met extra toegevoegde info ligt dit wat lastiger.

Dat werkt volgens mij niet, omdat het aantal nullen kan verschillen. Dus de gedeeld door waarde kan dus 100000, 10000, 1000, 100 of 10 zijn (afhankelijk van hoe specifiek de categorie wordt gedefinieerd).

Edit: Zie nu jouw edit. Bovenstaande toch maar even laten staan als extra toelichting

[ Voor 8% gewijzigd door Rien43 op 19-07-2021 12:37 ]

[Dido]

Ik zou een lijstje maken met gesorteerde categoriecodes. Dan kun je met VLOOKUP (verticaal zoeken?) de juiste categoriecode vinden bij een object id door de laatste parameter goed in te stellen (default is false, als je die op true zet krijg je de hoogste "bijna"-match terug, dus de juiste categoriecode.)

[Rien43]

Dido schreef op maandag 19 juli 2021 @ 12:41:
Ik zou een lijstje maken met gesorteerde categoriecodes. Dan kun je met VLOOKUP (verticaal zoeken?) de juiste categoriecode vinden bij een object id door de laatste parameter goed in te stellen (default is false, als je die op true zet krijg je de hoogste "bijna"-match terug, dus de juiste categoriecode.)

Dank voor je reactie. Echter, het gaat hier om een java-applicatie. Ik heb Excel gebruikt om een toelichting te geven waar ik naar op zoek ben.

[Anoniem: 1302638]

Beide getallen gedeeld door 1000 (voor een vergelijking op 123) en dan Math.floor() of iets dergelijks om te zien dat 123 "gelijk" is aan 123,121?

[Dido]

Ah, sorry - ik zag Excel, en keek niet verder

Maar dan sou ik alsnog een lijstje maken met categoriecodes, nu gesorteerd van hoog naar laag, en daar per product doorheen lopen. De eerste waar categoriecode <= productcode is bingo.

Dat is een naieve oplossing, dus performance is niet optimaal. Ik weet niet of dat een issue is...

[Rien43]

Anoniem: 1302638 schreef op maandag 19 juli 2021 @ 13:01:
Beide getallen gedeeld door 1000 (voor een vergelijking op 123) en dan Math.floor() of iets dergelijks om te zien dat 123 "gelijk" is aan 123,121?

Zat ik ook aan te denken, maar hoe ga je dan om met categorieën die specifieker zijn gedefinieerd? Bijvoorbeeld 572150.

[Anoniem: 1302638]

Rien43 schreef op maandag 19 juli 2021 @ 13:04:
[...]


Zat ik ook aan te denken, maar hoe ga je dan om met categorieën die specifieker zijn gedefinieerd? Bijvoorbeeld 572150.

Als 572150 valt onder 572000 dan is dat makkelijk:

code:

Math.floor(572150 / 1000); // zou 572 moeten zijn
572000 / 1000; // warempel ook 572

[Rien43]

Anoniem: 1302638 schreef op maandag 19 juli 2021 @ 13:08:
[...]

Als 572150 valt onder 572000 dan is dat makkelijk:

code:

Math.floor(572150 / 1000); // zou 572 moeten zijn
572000 / 1000; // warempel ook 572

Eens. Alleen de categorie 562000 kan ook 562500 zijn, of 560000. Dus 1000 zal dan ook 100000, 10000, 100 of 10 kunnen zijn.

[Anoniem: 1302638]

Rien43 schreef op maandag 19 juli 2021 @ 13:12:
[...]


Eens. Alleen de categorie 562000 kan ook 562500 zijn, of 560000. Dus 1000 zal dan ook 100000, 10000, 100 of 10 kunnen zijn.

Hoe weet je of dat zo is?

[Rien43]

Dido schreef op maandag 19 juli 2021 @ 13:01:
Ah, sorry - ik zag Excel, en keek niet verder

Maar dan sou ik alsnog een lijstje maken met categoriecodes, nu gesorteerd van hoog naar laag, en daar per product doorheen lopen. De eerste waar categoriecode <= productcode is bingo.

Dat is een naieve oplossing, dus performance is niet optimaal. Ik weet niet of dat een issue is...

Interessante gedachtegang, alleen zou het ook kunnen dat een object niet valt onder een categorie (dus een categorie niet bestaat). Dan zal het object onder een categorie 'Overig' moeten vallen.

Ik maak het wel lekker lastig he

[Rien43]

Anoniem: 1302638 schreef op maandag 19 juli 2021 @ 13:14:
[...]

Hoe weet je of dat zo is?

De codes zijn gebaseerd op een standaard systematiek, waarbij dit mogelijk is.

[ Voor 5% gewijzigd door Rien43 op 19-07-2021 13:16 ]

[Anoniem: 1302638]

Rien43 schreef op maandag 19 juli 2021 @ 13:15:
[...]


Dat weet ik . De codes zijn namelijk gebaseerd op een standaard systematiek, waarbij dit mogelijk is.

*zucht*

Wil je een voorbeeld hoe je die standaar systematiek kan omzetten in Java code, of wil je dat ik je nu ga vertellen dat je die standaard systematiek moet gaan omzetten in Java code?

Mij om het even hoor maar ff in de meewerkstand graag.

[_Apache_]

Rien43 schreef op maandag 19 juli 2021 @ 12:28:
In het voorbeeld zijn het inderdaad de eerste 3 karakters die er toe doen. Echter, de crux zit 'm in het feit dat het ook codes kunnen zijn als 572351. Deze zal dan in het voorbeeld onder de categorie 572000 moeten vallen.

Ook dient in het voorbeeld 611100 te vallen onder categorie 610000.

De categoriecodes liggen niet vast, dus zijn variabel. Het kan dus ook zijn dat de categoriecodes specifieker zijn, zoals 572100 of 572150. Dan moet de categorisatie van objecten dus nog steeds werken.

Delen door 1000, icm Rounddown/floor functie.?!

[Rien43]

Anoniem: 1302638 schreef op maandag 19 juli 2021 @ 13:16:
[...]

*zucht*

Wil je een voorbeeld hoe je die standaar systematiek kan omzetten in Java code, of wil je dat ik je nu ga vertellen dat je die standaard systematiek moet gaan omzetten in Java code?

Mij om het even hoor maar ff in de meewerkstand graag.

Ik snap niet waar die zucht vandaan komt. Ik geef gewoon aan dat de mogelijkheden bestaan dat er dus op diverse niveaus een code als categorie wordt gehanteerd. Wat wil je nog meer weten dan?

Dus met andere woorden:

Mogelijkheden categorieën:
100000
110000
111000
111100
111110
* Waarbij 1 dus van 1 t/m 9 kan zijn.

Ik heb dus zelf niet een idee hoe ik kan controleren of een object behoort tot een categorie.

Ik vind de gedachte met behulp van het delen en een math.floor interessant, maar zie zelf nog niet hoe dit toe te passen in het geval het laatste aantal nullen variabel kan zijn. Dan zal er mijns inziens eerst een check uitgevoerd moeten worden op hoeveel 0-en de categorie eindigt.

[ Voor 21% gewijzigd door Rien43 op 19-07-2021 13:21 ]

[Anoniem: 1302638]

Rien43 schreef op maandag 19 juli 2021 @ 13:18:
[...]


Ik snap niet waar die zucht vandaan komt. Ik geef gewoon aan dat de mogelijkheden bestaan dat er dus op diverse niveaus een code als categorie wordt gehanteerd. Wat wil je nog meer weten dan?

Dus met andere worden:

Mogelijkheden categorieën:
100000
110000
111000
111100
111110
* Waarbij 1 dus van 1 t/m 9 kan zijn.

Ik wil weten wat de logica is. Logica kan je programmeren. Ook in dit geval: je wilt weten hoeveel eindnullen er zijn, want dat vertelt je door hoeveel je moet delen. 5 eindnullen = gedeeld door 100.000 (categorie 1). 4 eindnullen = delen door 10.000, etc.

Echter, hoe kan ik er voor zorgen dat de laatste 0-en (bijv. 512***) als wildcard dienen en ook in de vergelijking meegenomen worden (waarbij dus de code 512500 ook onder de categorie 512000 komt te vallen).

1. Tel het aantal nullen in de categorie
2. Deel het objectnummer door het juiste nummer (zie boven), en dan Math.floor
3. Deel ook de categorie door het juiste nummer.
4. Die zijn hetzelfde, of niet.

[Rien43]

Anoniem: 1302638 schreef op maandag 19 juli 2021 @ 13:21:
[...]

Ik wil weten wat de logica is. Logica kan je programmeren. Ook in dit geval: je wilt weten hoeveel eindnullen er zijn, want dat vertelt je door hoeveel je moet delen. 5 eindnullen = gedeeld door 100.000 (categorie 1). 4 eindnullen = delen door 10.000, etc.


[...]


1. Tel het aantal nullen in de categorie
2. Deel het objectnummer door het juiste nummer (zie boven), en dan Math.floor
3. Deel ook de categorie door het juiste nummer.
4. Die zijn hetzelfde, of niet.

Ik begrijp dat je de logica wilt weten. Het was voor mij moeilijk om zelf die logica te doorgronden, maar met onder andere jouw hulp kom ik alweer een stukje verder.

Volgens mij zijn jouw stappen inderdaad hetgeen nodig zijn. Daarbij is het volgens mij wel van belang om de categorieën van hoog naar laag te ordenen en daar een loop op toe te passen.

[Anoniem: 1302638]

Rien43 schreef op maandag 19 juli 2021 @ 13:23:
[...]


Ik begrijp dat je de logica wilt weten. Het was voor mij moeilijk om zelf die logica te doorgronden, maar met onder andere jouw hulp kom ik alweer een stukje verder.

Volgens mij zijn jouw stappen inderdaad hetgeen nodig zijn. Daarbij is het volgens mij wel van belang om de categorieën van hoog naar laag te ordenen en daar een loop op toe te passen.

Het probleem is dat je niet weet of "573210" in categorie "570000" of "573000" gaat vallen, tenzij je zeker weet dat "573" niet kan bestaan als "57" al bestaat.

Als ze allebei bestaan heb je weer een andere uitdaging.

[DonJunior]

Rien43 schreef op maandag 19 juli 2021 @ 12:28:
In het voorbeeld zijn het inderdaad de eerste 3 karakters die er toe doen. Echter, de crux zit 'm in het feit dat het ook codes kunnen zijn als 572351. Deze zal dan in het voorbeeld onder de categorie 572000 moeten vallen.

Ook dient in het voorbeeld 611100 te vallen onder categorie 610000.

De categoriecodes liggen niet vast, dus zijn variabel. Het kan dus ook zijn dat de categoriecodes specifieker zijn, zoals 572100 of 572150. Dan moet de categorisatie van objecten dus nog steeds werken.

Misschien dit ook even in je TS vermelden.. Scheelt een hoop aannames.

[Rien43]

Anoniem: 1302638 schreef op maandag 19 juli 2021 @ 13:26:
[...]

Het probleem is dat je niet weet of "573210" in categorie "570000" of "573000" gaat vallen, tenzij je zeker weet dat "573" niet kan bestaan als "57" al bestaat.

Als ze allebei bestaan heb je weer een andere uitdaging.

Ik denk dat dit op te lossen is door de categorie codes van hoog naar laag te ordenen. Bij de eerste de beste hit tussen object en categorie zal de loop stoppen.

Ik ga er eens mee stoeien. Dank allemaal voor het meedenken. Mochten er nog briljante ideeën oppoppen dan houd ik mij aanbevolen.

[Rien43]

DonJunior schreef op maandag 19 juli 2021 @ 13:28:
[...]

Misschien dit ook even in je TS vermelden.. Scheelt een hoop aannames.

Gedaan. Dank.

[Marber]

Zijn je categorieën niet stiekem ranges? van 570000 tot 5729999 en 5730000 tot 6100000 bijvoorbeeld?

[Rien43]

Marber schreef op maandag 19 juli 2021 @ 13:31:
Zijn je categorieën niet stiekem ranges? van 570000 tot 5729999 en 5730000 tot 6100000 bijvoorbeeld?

Het zijn wel ranges inderdaad, maar die ranges worden bepaald door de laatste nullen in een code (een 0 staat voor een range van 0-9). De ranges die jij benoemt zijn niet juist.

Maar ik denk niet dat het met bovenstaande veel duidelijker wordt.

[ Voor 4% gewijzigd door Rien43 op 19-07-2021 13:36 ]

[Creepy]

Heb je de lijst van categorien ergens? Want dan zou je kunnen delen door 10, heb je een match? Categorie gevonden. Geen match? Dan delen door 100, etc. etc. etc.

[bwerg]

Als ik het zo zie zou ik allereerst in de categorieën de nullen aan het einde gewoon weggooien, want die lijken geen informatie te bevatten. Daarna is de gewenste relatie tussen de categorieën en de objecten gewoon een prefix-relatie.

Dus algoritmisch zou je daarvoor zou je een prefix-boom kunnen gebruiken. Daar zijn kant-en-klare implementaties van beschikbaar (zie: Apache commons, Google guava, etc.), al weet ik niet of die voor je specifieke voorbeeld één-op-één aansluiten. Misschien is dit wat overkill, maar het is wel lekker simpel om bestaande abstracte concepten te gebruiken als dat inderdaad aansluit op wat je nodig hebt. Je weet ook zeker dat performance nooit een ding kan worden, geen geklooi met for-loopjes die over een jaar ineens heel traag zijn omdat iemand er 100000 categorieën ingestopt heeft.

Op basis van de informatie die je geeft neem ik trouwens een categorie niet binnen een andere categorie kan vallen (bijvoorbeeld categorieën 123000 en 123400, waarin valt object 123456 dan?) maar als dit voorkomt en je dus effectief sub-categorieën hebt kun je ook daar met een prefix-relatie alle kanten op. Een categorie die een prefix is van een andere categorie is dan de super-categorie, en een object waarvan de subcategorie een prefix is heeft automatisch ook de supercategorie als prefix. Maar waarschijnlijk loop ik hier erg op de zaken vooruit.

edit: ik zeg dat de nullen geen informatie lijken te bevatten, maar ze zeggen natuurlijk wel wat over de lengte (het aantal cijfers) van de categorieën. Op basis van je voorbeeld nam ik aan dat dat niet relevant is. Doh, beter lezen. Zes-cijferige codes, die zijn meestal allemaal even lang.

[ Voor 28% gewijzigd door bwerg op 19-07-2021 15:57 ]

[Knutselsmurf]

De categorieën is dus eigenlijk een boomstructuur, waarbij iedere categorie eventueel subcategorieën kan bevatten.
Door dit als een boom op te slaan, kun je ook de bijbehorende zoekalgoritmen gebruiken.

[RobIII]

Precies, wat je wil is gewoon een tree met elke node een digit. Hoe dieper je de tree in kan hoe specifieker je entry.

[ Voor 4% gewijzigd door RobIII op 19-07-2021 13:58 ]

[vandeGerrit]

Volgens mij kan je hem zo berekenen, voorbeeld even met 3 cijfers toegelicht, maar de logica kan ook op 6 cijfers worden toegepast.

Stel je hebt de categorieën:

• 100
• 110
• 130

En je hebt object: 126. Dan controleer je eerst of het getal al direct een match is op je categorieën. Zo nee, dan vervangen we het laatste getal door een 0 126 -> 120. Nu controleren we opnieuw op een match, zo nee, volgende getal vervangen door een 0. 120 wordt dan 100, nu controleren we opnieuw.

[Rien43]

Dank voor jullie reactie. Ik ga er induiken.

Een vraag tussendoor:

Bij het debuggen heeft de key 'code' in de hashmap een waarde van 57 (dus zonder de achterliggende nullen). Ik heb het idee dat dit ligt aan het type 'Object' dat ik heb meegegeven in de hashmap. Omdat ik verschillende types wil opslaan in de hashmap zit ik hier aan vast.

Weet iemand hoe het komt dat de integer waarde veranderd?

code:

String sourceCellCode = "570000";

Integer sourceCellCodeInt = String.parseInt(sourceCellCode);

Map<String, Object> tmp = new HashMap<String, Object>();
tmp.put("code", sourceCellCodeInt);

[Creepy]

Weet je zeker dat je String.parseInt gebruikt? Want je zou Integer.parseInt verwachten. Ik zie daarnaast niet hoe je de waarde weer ophaalt en gebruikt wat toch echt belangrijk is. Net als in het begin van dit topic lijkt je wat informatie niet te geven die wel degelijk belangrijk is

Als ik System.out.println(tmp.get("code")); toevoegen aan jouw code komt er precies uit wat je verwacht, als ik tenminste Integer.parseInt gebruik.

Java:

String sourceCellCode = "570000";
Integer sourceCellCodeInt = Integer.parseInt(sourceCellCode);
Map<String, Object> tmp = new HashMap<String, Object>();
tmp.put("code", sourceCellCodeInt);

 System.out.println(tmp.get("code"));

[ Voor 42% gewijzigd door Creepy op 19-07-2021 17:14 ]

[bwerg]

Inderdaad, ik zat ook al te zoeken naar String.parseInt. Maar als ik aanneem dat dat Integer.parseInt is, dat lijkt prima te werken.

Verder is het gedrag van Map<String, Object> exact hetzelfde als die van Map<String, Integer>. Die generic argumenten zijn er zodat de type-checker kan zien of geen dingen in je Map stopt die je niet bedoeld had, maar het gecompileerde programma is hetzelfde.

[Rien43]

Sorry, ik heb het verkeerd overgenomen. Ik had al Integer.parseInt() gebruikt. Zie hieronder de code.

code:

String sourceCellCode = "321000";

Integer sourceCellCodeInt = Integer.parseInt(sourceCellCode);

Map<String, Object> tmp = new HashMap<String, Object>();
tmp.put("code1", sourceCellCodeInt);

Als ik nu debug dan krijg ik onderstaande resultaten.



Om één of andere reden laat ie dus een andere integer waarde zien in de hashmap (321 i.p.v. 321000).

[Creepy]

Dat kan niet met de code die je nu laat zien. Onmogelijk. Je hebt ergens meer code. Run je eigen code eens los in een main() en kijk dan wat er gebeurt. Als dat dan nog steeds mis gaat, geef dan eens de volledige code van de main method nadat je er zelf met de debugger stap voor stap doorheen bent gegaan.

Aangezien je ook targetCellCodeInt hebt in je debugger screenshot, heb je dus ook meer code.

Door de code te isoleren waarin je denkt dat het mis gaat kan je beter zien wat er nu gebeurt. Met alle respect: je lijkt te gokken waar het mis gaat. Probeer de bug die je hebt met zo weinig mogelijk code te reproduceren om te achterhalen waar het nu echt mis gaat. Dat is debuggen. En dat kunnen wij niet voor je doen op dit moment. Dat moet je zelf leren (en ik besef me dat dat hard kan klinken) en als wij het al zouden willen, dan missen we nogal wat code die je nu niet laat zien. Ga aub ook niet direct al je code geven, want debuggen, nogmaals, moet je in principe zelf leren en doen

[ Voor 55% gewijzigd door Creepy op 21-07-2021 14:27 ]

[Josk79]

Je zou een functie kunnen maken die de strings van rechts naar links vergelijkt en '0' als wildcard accepteert totdat je een keer niet-'0' tegenkomt.

Zoiets als onderstaand, deze accepteert alleen bij n1 een wildcard. Als n2 ook wildcard mag hebben moet je hem ombouwen

code:

    public static Boolean vergelijkDeNummers(String n1, String n2) {
        Boolean acceptWildcard = true;
        if (n1.length() != n2.length()) return false;
        
        for(int x=n1.length() - 1;x>=0;x--) {
            acceptWildcard &= n1.charAt(x) == '0';
            if (!acceptWildcard && n1.charAt(x) != n2.charAt(x) ) return false;
        }
        return true;
    }

[ Voor 0% gewijzigd door Josk79 op 19-07-2021 21:20 . Reden: typvaut ]

[Soulfix]

Enigzins offtopic, maar dit lijkt wel erg op de goederencodes (HS-codes) die de Douane gebruikt. :-) Zie hier bijvoorbeeld https://www.cbs.nl/nl-nl/...goederen/idep-codelijsten voor een excel-lijst van goederencodes. Deze hebben wel het format van 8 cijfers, maar lijken verder qua structuur erg op de getallen van de OP.

[truegrit]

Kan je niet gewoon van alle categorie codes de nulletjes strippen, die in een hashmap of set zetten en dan over de productcodes itereren? Dus bij code 512443 check je eerst of categorie 5 bestaat, dan 51, dan 512. Maximaal 6 lookups per product. Hoef je ook niet te klooien met string -> integer conversie.

[Matis]

Ik zou het helemaal anders doen.

Categorieën op volgorde sorteren en dan met ieder object de lijst aflopen. Zodra je ziet dat de object-code groter is dan de categorie-code weet je dat dit object onder de vorige categorie valt.

Of mis een cruciaal detail? Ja dus, Object 312000 moet onder Categorie 310000 vallen en niet 311000.

Anders zou je met iets van hamming distance moeten gaan werken op de karakters. Dat werkt ook niet, want het zijn strings

Of zoiets als https://www.php.net/manual/en/function.similar-text.php in PHP. Dit werkt wel. Ik heb even zitten pielen en kom tot dit resultaat op basis van jouw eerste screenshot:

+--------+----------+ 
| Object | Category | 
+--------+----------+ 
| 311000 | 311000   | 
| 312000 | 310000   | 
| 651500 | 651000   | 
| 572000 | 572000   | 
| 571000 | 570000   | 
| 611100 | 610000   | 
| 651600 | 651000   | 
+--------+----------+ 

[ Voor 38% gewijzigd door Matis op 22-07-2021 21:23 ]

[Matis]

Ik heb mijn test case verder uitgebreid met voorbeelden uit dit topic en kom (denk ik) nog steeds tot het gewenste resultaat:

Categories: 651000, 610000, 572000, 570000, 311000, 310000, 123000, 123400 
+--------+----------+ 
| Object | Category | 
+--------+----------+ 
| 311000 | 311000   | 
| 312000 | 310000   | 
| 651500 | 651000   | 
| 572000 | 572000   | 
| 571000 | 570000   | 
| 611100 | 610000   | 
| 651600 | 651000   | 
| 572351 | 572000   | 
| 123456 | 123400   | 
| 999999 | ??????   | 
+--------+----------+ 

Ik zal in een paar stappen proberen uit te leggen wat ik heb gedaan. Kleine kanttekening: ik heb het in PHP opgelost, maar het is zo basaal, dat het in Java vast en zeker ook te fixen is.

Allereerst heb ik alle Categorieën en Objecten in een array gezet.

Daarna heb ik een key/value array gemaakt van alle Objecten en hun initiële Categorie ?????? om zo ook aan te kunnen tonen als een Object geen passende Categorie heeft.

Daarna heb ik een dubbele for-loop gemaakt waarin ik eerste over alle Objecten itereer en daarna over alle Categorieën.
Van iedere Categorie vervang ik de 0-en door een . en maak zodoende een regex pattern welke ik tegen het Object match. Is er geen match, ga dan door naar de volgende Categorie.
Is er wel een match, kijk dan middels similar_text hoeveel karakters er matchen. Zijn dat er meer dan voor de voorgaande Categorieen, dan wordt de huidige Categorie de beste voor dit Object.
Hier zit een potentiele bug; en dat is dat ik er van uit ben gegaan dat de codes altijd van links naar rechts worden opgebouwd en dat ook van links naar rechts het steeds specifieker wordt.

Zo werk ik het lijstje af en uiteindelijk heb je dus een key/value array waarin achter ieder Object de best passende Categorie staat. Wanneer er geen resultaat is, zie je nog de ?????? staan zoals in mijn resultaat hierboven.

Er zullen vast wetenschappelijke / wiskundig betere uitwerkingen zijn, maar ik heb dit gemaakt zonder Prefix Trees, Math libraries of HashMaps.

Het komt nog het meest in de buurt van de code van @Josk79. Alleen dan ik PHP het werk doen ipv zelf een parser te maken.

@Rien43 omdat ik je de kans wil geven mijn voorzetje uit te proberen, zal ik hier de code nog niet neerplempen. Natuurlijk wil je wel helpen (mocht je willen).

[ Voor 7% gewijzigd door Matis op 22-07-2021 22:11 ]