Linear cutting in a grasshopper

Here’s V1C (the sort - in sync - option added):

Clusters_OnNumbers_EntryLevel_Public_V1C.gh (129.8 KB)

Note: as always with any solution … if you put bananas in … you’ll get bananas out (the real stuff, not the abstract one). Meaning that your data MUST comply with what the combo of C# expects to find: ONE List of strings and ONE Tree of doubles where the branches equal the N of items in the List.

That said (case of equal values per branch) I could add 2-3 lines of code more in order to clone values in some auto mode: for instance if a given branch has only 2 values, say: 23.556, 45 that would mean: replace the List with a new containing 45 times the 23.556. But that sounds a bit stupid anyway: I mean what’s the purpose of fitting copies of 23.556 into 666? (just divide, get the int part and be a happy bunny).

I would advise to switch to the demo mode at first and play with the values of doubles (plus the max value and the report options 1,2) in order to get the gist of the whole clustering thingy

1 Like

Er … hmm … here’s the latest (and greatest):

Inspired from what Lewis does in Brazil (He’s only lacking 3 milliseconds in P2 > forza Lewis) …

… I did some tests more on V1C. Guess what? It’s 100% crap: recycle it ASAP > V1D is almost ready (+ some cool graphics + only 3 divisions by zero (so what?) + seriously slower (that’s progress, mind) + a 2nd Clustering Method [way better] + minus one very stupid bug in ER ratio calculation + … + you name it).

banana-eating chief technologist?

Indeed the Guru (of Gurus (of Gurus)) delivered: introducing the V1D that uses a quite efficient sequential best-fit strategy plus does some graphics in order to visualize the results:

Rows with the same color are the clusters due to a given List of doubles related with a given material (say: banana_56R that differs greatly from banana_56Y). Red means the obvious.

But … is the sea of reds a proof that the Guru (of … )) did bananas? Far from it.

Let’s inspect the 3 first materials that yield clusters (values sorted by descending order + all cheating flags OFF) … having in mind that there’s waste due to our fault and waste due to Karma:

  1. The light cyan one is like this because we are out of doubles BEFORE the max is reached: so this is not our fault at all (blame Karma).
  2. The gray-cyan one falls into the very same category.
  3. The blue one (2 rows: i.e. 2 clusters) uses the available container with the best imaginable way (spot the tiny red area in the first blue row: spot the best fit algo in action as well). But … a double more is left: meaning that the second cluster is responsible for the 98% of the total waste for that particular material (I believe: banana_Split_64W). So ER is a pathetic 51.12%. Who to blame? The Guru or Karma?

Same stuff with the 4th material (2 clusters: cyan) , the 6th material (2 clusters : pink) … and all the rest.

Some tests more are required mind (better safe than sorry).

I couldn’t let go the black Friday special price you offered me (1M Micro Dollars), but I will be prepared to break my piggy bank anytime soon if this works as supposed to! =)

Wow, so much action happened since my last reply, not sure from where to start, firstly, please receive a BIG THANK YOU!! for all this inspirational work you are doing Dear Greedy Lord!

The new release of the V1D seems will handle the banana split thing very nicely! I can’t wait to see it running on my PC! =) I’m just wondering if the following workflow below would be possible to be done with this new V1D version:

I get from the rhino’s model the data shown in STEP 1, after in grasshopper I do the grouping data as per STEP 2, and ideally VD1 will take care from here to create the clusters based from multiple material types, ID names, and the optimized nesting cut-list (Did it sound like a wish list for Santa or is it just my imagination?)

Please see the sequential imagery below:

Currently this is what’s is coming out from V1B version, but as you are aware, ID names, Optimized minimum wasted list, and handling multiple tree structure is not available yet:

Good news: V1D is passe: V1E is almost ready (progress at Fotiadis ACME Industries never stops - kinda migrating from XP to … er … hmm … Vista).

Bad news: Chief bean counter said that he has issues to update the books (IRS is everywhere, you know) with that 1M micron dollars fee. Please e-mail some M more (use the same Kayman Islands account).

Ugly news: My chief IT Guru (of Gurus ( of Gurus)) is fired > adios Amigos. A new one - a family man - is hired because he claims that he’s expert in parallel coding (and team/family work). Problem is that I can’t understand an iota from what he’s doing … meaning that V1E is a black box to me (most notably: keeping track of the original doubles indices [in the doubles List per material] when the best fit algo shuffles the data for achieving max ER rates [Yikes]) . Plus in all the Beta tests on V1E he’s using solely bananas. Plus the TextDot on the graphs [as in V1D] stuff: how he does that? (and why?).

best, The Lord (of micron dollars)

1 Like

BTW:

Guru said: Lord why we are using a fixed max for all that mess? Instead of searching for a max where the sum of all waste is min? I said: provited that this is allowed in real-life (not always the case) this means that we are not after waste, we are in fact after dollars (since there’s cheapo waste [why bother?] and expensive waste [bother] and everything in between). Meaning that we need a 3rd List that corelates materials (as found in the first List) with the cost of waste. But the cost varies due to a zillion factors: size of the project, payment terms, regional conditions, disposal local regulations, availability of a given material in some non standard size (for instance imagine asking for a special marine plywood 40mm sheet in other sizes than 1.25 * 2.2) … blah, blah. Guru said: strange … I did some beta runs in V1F (V1E is passe) and all worked OK with regard banana sourced waste (a non issue since you can eat the remaining pieces).

Please tell to the Chief Bean counter don’t get mad at me, since I am working on this, the beans transfer internationally it’s been a bit tricky for me. :tired_face:

Oh! that doesn’t sounds good indeed, I’m sorry about the fate of your IT Guru (of Gurus (of Gururs)), but wondering, based from the progress you made from V1B, would it be hard to freed some good news in adding the ID matching in the script? :pray::pray::pray:

I welcome any sort of enlightenment from you, thanks in advance!. :wink:

Guru (of … ()) added the History thingy: keeping track from the beginning to the end with materials and doubles (pieces in linear cutting). Guru says that the doubles List MAY undergo 3 changes:

  1. if we do a sync Sort in the first C#,
  2. if we randomize OR Sort OR Sort descending a given List and
  3. if we use the best fit clustering that doesn’t respect the order of items (doubles) in order to achive the least waste etc etc.

Guru did all that in V1E (but what about V1F ?) and claims that the beta History thingy shown can answer to any question. Me? I can’t understand an iota of all these.

BTW: Asked the Guru: can you split a banana (the banana split thingy, that is) along the long axis with all these freaky things? He said: sorry, but that’s clearly out of the scope of linear clustering

Good news: Under the influence of spirits (Vodka, what else) I took the exec decision (the Word of The Lord never changes, that is) to fill the hole in the books by paying Myself for the job. Bean counter said: WHAT an idiot (but the Word of The Lord … blah, blah). So due to that typo this case cost me half a mil (but who’s counting? they are just dollars).

Bad news: Guru (of …)) found performing below Lord’s standards (that’s a crime). Too many questions (and too many IndexOf expensive things) > History Kaput. Enter the Cluster Indices Tree (new stuff added in V1E): The only thing that matters is an indication of the order of pieces (doubles) - Note: Indices in the Cluster Indices Tree are the ones from the OEM doubles List per branch - as an indication of the efficiency of the Clustering Method used.

Let’s see banana_004 as it starts the adventure (AFTER sync sort, but that’s irrelevant anyway):

Let’s see the end of the road : order of doubles has changed (maybe many times: but who cares? the Cluster Indices Tree gives you the connection with the OEM stuff). That said that idiot Guru was monitoring every phase (but why? who cares to know these things? - that’s why he’s an idiot Guru):

Compare with option: leave doubles as they are (no sort, no randomize):

In depth explanations AFTER the F1 race in Brazil (forza Lewis).

Ugly news: Lewis delivered. Starts - again - from pole … but he’s on SS tyres (blame a VERY stupid rule related with usage of tyres VS the best time in Q2). What this means? It’s complex to explain but - trust the Lord - it’s not the best thing imaginable (but Our Hopes are with the Best (ever)).

1 Like

Dear Lord,

Would you let me try with the most current version of the banana_split suite you’ve made so far to see the results by myself with the data tree I have. I’ve become fan of your v1b one, but the ID’s aren’t there as you know, so, I believe this is the perfect occasion to test the wonders of your Guru (…(…)) made under the effects of vodka! The results might be as expected! Thanks!!! :crazy_face: :grin:

Lewis delivered (Ocon helped a bit, but that’s a minor detail).

Get the banana split V1E (Lila did the graphics thingy: the 3rd C# that is).

Clusters_OnNumbers_EntryLevel_Public_V1E.gh (139.8 KB)

PS: You may wonder why the “best” (kinda) clustering method (N2) is NOT by the book (i.e. a classic best fit thingy). Well … response time that is. If however you want a 3rd Method notify.

Here’s an abstract demo on that classic best fit thingy (by faaaaaaar slower EVEN using integers as test … but no pain no gain(?)). In my view it’s not worthy the delay penalty unless you have to chop diamonds (if this is the case, send some over here ASAP - purely for scientific purposes).

Clusters_OnNumbers_KnapDemo_V1.gh (121.8 KB)

Until the next time, Lila, The Lord

1 Like

I am still slicing bananas, eating bananas, dreaming bananas… I can send over some bananas ASAP if this helps your scientific research!

Dear Dark Lord and The Merciless… Amazing piece of work you’ve posted, incredible indeed. I Loved it… since I am now very attached to this topic, can I add couple additional questions? :grin:

Question1: Would it be too hard to have Part IDs included in the cutting list?

Question2: Is there a reason to have the “offset” value set to 0.001? If our initial part size is 10.00 now is 10.001, or perhaps this offset value is the cutting factor? say, to have increments of x-value (knife thickness) for each cut in the stock piece.

Question3: If question2 is not the cutting factor, which would be the best way to consider it within this nesting process?

Interesting Facts:

Clusters_OnNumbers_EntryLevel_Public_V1E (AG).gh (143.1 KB)

You sir are a gentlemen and a scholar – or perhaps missing a few bananas(tbd)

Alas: only diamonds (about a kilo could be OK) can boost the quest for the Truth Out There.

Indeed the offset thingy is the knife thickness. Set to 1 mm since Fotiadis ACME Industries does tests using hydro cut stuff (don’t spare the horses is Our motto). What’s the issue if you set it to 0.0 ? (I do hope not Armageddon, but never say never).

Appears that V1F is unavoidable (slower, more bugs, more useless stuff … kinda the unfortunate latest Oct Win10 Update [worst ever: audio drivers kaput anyone?]). However a serious project refund is required. You may ask why? Well … I do hope that you’ve spotted the rarest and finest materials used in V1E for testing the split thingy: the exclusive and hideously expensive dinosaur ears (they indeed cost an arm and a leg … but … don’t spare the horses is Our motto).

WAIT: your screenshot tells me freaky things with regard unique mapped indices. Here’s how it works (a sync Array Sort isn’t the answer since we do other (optional) stuff with the values). Spot the unique (in the blue panel) indices whilst your stuff appears like bananas,

Either I must fire that family man // Guru ASAP or something else [bad] is happening here.

Lists_MapNewToOldIndices.gh (120.4 KB)

PS: Never mind: bug found. Enter V1F

1 Like

Top Guru fired > adios parallel coding, families, wifes, childs, teamwork and other nonsence. Blame Lord’s Kindness and Innocence (but he looked to me as a top dog).

What the idiot Guru did? Well he forgot that we have a sub Tree on hand to map indices. In his defence he murmured stuff about the Brazilian F1 race, the Constructors championship (done) and Lewis (the one) … but the Lord (The Merciless) doesn’t tolerate mistakes.

V1F has already implemented the fix. See how it works here:

Lists_MapNewToOldIndices_Fixed_V1.gh (120.7 KB)

1 Like

This is how it should have been done: adios Top // Guru > go back to Oblivion > no Mercy!

V1F under new management: The Merciless (not The Lord) takes over.

She said: why not using a string on the ex doubles tree LQUserTree (now a string tree) where each entry could look like:

345.78,Part_name.

Then:

  1. We split the string by “,”. Then we convert the first substring into a double and send it to the doubles Tree.

  2. If splitting the string yields a splittedResult.Length > 1 it means that the LQUserTree includes some part names, If not … we just add null to the (new) PartNamesTree. Anyway since the indices thingy keeps track of everything (the new V1F one not the old due to that idiot) when we do the graphic part we could - as an option - add the part name to the TextDot. See the internal demo doing that (PS: forget the sketches shown):

Plus: why not replace the dinosaurEar_023 material with the much more affortable _089C? (C for cheapo). Who’s gonna notice it?