Reading Time: < 1 minute

We know. It takes a “good” 5-10 minutes to run

$ create-react-app myTestApp 

The plan: I’m going to installing a npm repository cache npm_lazy, and do 4 measurement:

• First time elapsed of a ‘create-react-app myApp’ – Without npm_lazy cache
  
• Next time elapsed of a ‘create-react-app myApp’ – Without npm_lazy cache
  
• Third time is the npm_cache install case, but when “npm install” not yet been ever run.
  
• Fourth time elapsed is that of all things configured with npm_lazy cache

So the final benefit of using a npm_lazy cache will be subtracting the time between 4 and 2.

Gonna be back soon! Stay tuned. Second Post will be about the results. Cheers, Jukka

Reading Time: < 1 minute

I received some (few) tens of troll user registrations on Jukkasoft. Looking for better way to manage these, but for now, will just manually delete the users. You don’t need to do anything. Just wanted to let you know.

Cheers & best wishes,
Jukka

Reading Time: < 1 minute

Three young gentlemen found a company in 1988,
in the heart of Finnish innovation hub, Otaniemi.

The company, Inducon Consultants, gets its first major consultancy deal from a pulp industry giant.

The company grows into a very lucrative and
diverse IT consultancy.

Juha is looking for a job. He’s a fresh graduate from IT networking campus, without a hint of getting paid for his skills. He can’t stand authorities,
and has no experience from work life, let alone respect for seniority.

Juha gets his first stint, half by accident, from Inducon, as the company are desperately looking for young talent.

Juha causes some stirups, as he gets special treatment from senior management. Juhani, a rather new face at the board, bets all his chips in one basket. He is sure that Juha is exactly what the company needs.

Juha gets a private lab room, fully equipped with all the tinfoil gear that he needs. It’s extraordinarily posh even for Inducon. His budget is also non-disclosed. Another striking exception to company policy.

Juha can develop his breathtaking (but unproven) visions of a new
kind of keyless digital authentication system, Damocles.
He whispers the right growth keywords to management, while
at the same time infuriating some of his senior colleagues.

Inducon is torn into two parts. The fight is clearly
taking apart some of the well-deserved ethos that had
previously taken the company to legendary heights and
undisputed reputation.

As the founder slips to oblivion, the rudder is up for grabs.
What happens next? Find out. Stay tuned!

Reading Time: < 1 minute

Here it is! Jukkasoft blog’s unofficially official rhapsodime unit.

Reading Time: < 1 minute

Reading Time: 3 minutes

Let’s say we have 1000 boids: little worms, birds or what-ever-animal is your favorite, moving around in a canvas (restricted to X and Y coordinates, that is a plane). The boids form a beautiful swarm. Collectively they seem to be following some invisible leader, while avoiding crashing each other.

Can we somehow optimize the calculation of distances?

Boids make a fantastically realistic depiction of flocking behavior due to 3 simple rules:

Boids in this context are considered only as a graphics simulation. Boids have AI context as well: in Particle Swarm Optimization (PSO), the search happens via a group of boids. We’re not covering PSO aspects in this post.

Basics

Why distances are important for boids?

Boids, as simulated by computers, only “see” the world through distance calculation alone. So every boid wants to know the distance to every other boid. If there’s 1000 boids, we need to calculate “from each boid, the Euclidean distance to each other boid”.

Boids follow a few rules, and they are based on the distances:

• cohesion (of swarm)
• avoid being in the edges of a swarm
• don’t collide to other boids

So how much is it? How many CPU-based calculations do we need? Is there a low-hanging fruit, some optimization we might use in the algorithm?

Naturally we’re looking at a FOR (loop). In fact, FOR each boid, go through all other boids. So it’s nested FOR.

for each v in vertices:
    for t in (vertices - v):
        dist[v,t] = sqrt(pow(v.x-t.x,2) + pow(v.y-t.y,2))

Since the distance (=edge length) between two vertices is symmetric (from Bob to Alice is same amount as from Alice to Bob), we only need count the distance pairs between all boids. This reduces calculation by 50%.

Let’s induce the “number of edges” formula in a very short manner:

Vertices	# of Edges
1	0
2	1
3	3
4	6
5	10

How many CPU cycles needed to calculate one distance?

Approximations will do. We’re quite low level here, not quite exact CPU cycle counting — but close enough. You might have seen this same formula in a bit different format, but it wants to say: you need to calculate a square root of a sum. the sum is composed of second powers of X- and Y- distances (differences) of the two points.

Distance (an edge) is thus:

sqrt( Dx^2 + Dx^2 )

• Dx is (X1 – X2)
• Dy is (Y1 – Y2)
• sqrt counts for 1 CPU operation (op)
• sum (the ‘+’) is also 1 op
• powers (^2) are both 1 op, so 2 op total for powers
• total 4 arithmetic operations per each boid pair

Distance calculation details for boids

• take one boid as center
• calculate lines (pythagorean distance) to all N-1 other boids
• dist = sqrt[ (delta_x)^2 + (delta_y)^2 ]
• a little trick: there is symmetry. The distance from the other boid to “us” is same as from us to there
• thus we need only calculate once the distance between two boids
• store the value so that both boids can use it

We would otherwise do unnecessary calculations. But is the “50% off” of the algorithm runtime the best we can get? Can we shave more out of the algorithm? Or should we ask, at what point it makes sense to even try to shave more off? It’s always sane to optimize only in the right places, what comes to coding. But then again… Well, you get the point, before we’re entering an infinite recursion.

As aside – for practical purposes in a game engine, I’d like to add a “stress causing factor” for the boids. This is related to the density of units in an area, centered around each boid. The stress level would need one thing first calculated: distance of all other boids to the boid itself.

When we have the distances, we can cut-off the population of boids to 2 sets: those within R (range), and the rest are outside of range.

The stress comes from necessity of making a lot of adjustments in a small period of time. So if a worm needs to jiggle a lot, it gets stressed. The jiggle amount is interesting metric. How should I define it in practical terms?

Reading Time: < 1 minute

Eternal question: cooking, or building software? Which analog suits better?

Pro “Cooking” software

• it’s a recurring activity
• essential for daily survival (just like coding)
• side effects removal: just like ‘Preact’ (remove clutter)
• bonzai! & zen and lean
• lots of opinions around (kitchen / software developers)
• no certificates needed!

Pro “Building” software like a house

• basement of house equals the necessary dev tooling in software
• you can use modules, just like in software dev
• it’s a bigger project, you don’t build a house everyday, do you?!
• more fancy way of thinking, appreciation to the trade
• certifications are more mandatory in Construction industry than in kitchen (just like certificates start to play a role in Software)

Reading Time: < 1 minute

Tämä artikkeli on WIP – Work in Progress.

Viime päivitys: 15.1.2021

Drone: case varmuus radiolähettimen AA-patterien kunnossa – optimaalinen toiminta ja lentomäärät.

Tausta

Iskä osti dronen muksuille, ja nyt lennättelee sitä, ja geek-snipailee erilaisia kalkyyleja toiminnan ympärillä. Kalkyyleilla on tarkoitus selvitellä, miten eri varmuusparametrien valitseminen vaikuttaa lennon kustannuksiin ja hyötysuhteisiin.

Näkökulmana on:

• lentämisen pitää olla turvallista
• lentoturvallisuus dronella perustuu ennenkaikkea dronen ja radiolähettimen välisen yhteyden toimimiseen
• radiolähetin tarvitsee virtaa ollakseen luotettava
• radiolähetin saa virtaa AA -pattereista
• järjettömän (liian) usein vaihdetut AA-patterit tulevat kalliiksi ja ovat myös epäekologisia
• sopiva AA-patterien ajallinen vaihtoväli voidaan myöhemmin myös mitata
• on huomioitava, että dronen radiolähetin kuluttaa virtaa eri tavalla mahdollisesti riippuen mm. lennon aikana tehtyjen manööverien määrästä (kuinka paljon radiolähetin kommunikoi dronen kanssa) ja lennon aikana radiolähetimen kokemasta fyysisestä ympäristöstä (lähinnä T, ympäristön lämpötila)

Drone tarvitsee

• AA-patterikäyttöisen radiolähettimen (ohjain) 3 kpl AA
• itse drone oman akun latauksen USB -laturilla oleellisesti verkkovirrasta
• AA-patterien vaihto on kriittinen varmuustekijä dronen turvallisen lennättämisen kannalta

Hankinnat ja eräkoot voivat vaikuttaa drone-lentämisen ekonomisuuteen yksittäisen kuluttajan (käyttäjän) kannalta. Mutta kenties sitäkin mielenkiintoisempi havainto: osto- ja kierrätyssyklin valinta voi lyödä myös lukkoon optimi lento”tarpeen”, eli kun on tehty hankinnat, syntyy ikäänkuin tarve käyttää dronea; muutoin hyötysuhde toiminnasta laskee.

3 x AA
P = 2.40eur
PLc = 4 (montako AA-patteria yhdessä P hintaisessa paketissa tulee)

Joka toisen lennon jälkeen, tarvitsee sekä vaihtaa patterit, että laittaa
kierrätykseen vanhat. Näin pelataan varman päälle, että radiolähettimessä on aina riittävästi virtaa.

Hyödyt ja kustannukset, sekä huollon suhde hyötyyn

Pt = 8 (8/60 h) ;; Payload time (hyötyaika per sykli)

Mt = 10 min (=1/6 h)

Rt = 60 min (kierrätykseen kuluva aika, kun RB batch on täynnä vanhoja AA-pattereita)
RB = 25 (montako AA patteria voi puskuroida ennen kuin pitää tyhjentää batch)

Reading Time: < 1 minute

ACO bugged me for a long time. I read about swarms and particle swarm optimization (PSO) in around 2005. Then forgot about it. Now that I’ve written more Posts and read a lot of new math, I came back to the subject. I was fascinated by what actually a ACO is? Is it the same as particle swarm optimization?

Yes.

ACO is same as PSO. They are both about a ‘group’ or swarm trying to find a good path. What’s a “good” path? That is defined within the optimization problem.

So the idea in ACO is that use many agents, instead of a single agent, and make some simple rules also for communicating of the findings. The ACO is named after ants, and PSO is named basically after any generic Swarm (of things). Whereas both of these come down to computer code, it doesn’t matter which you prefer.