BaSzErr - blog:2016:07:10

boot-id

anonymous@undisclosed.example.com (Anonymous) — Tue, 15 Jun 2021 20:09:20 +0000

2016-07-10 - boot-ID

some time ago, in a project not so far away, we had a problem. :) a connection-less channel had to be used for polling between two services, to detect failures/reboots on remote ends. it was meant not to use “too much bandwidth”, so connection was checked every 15[s], or so. there was one “surprise” awaiting though – what will happen if remote end will manage to restart in between two checks? crash will not be detected and application states will get out of sync! the answer was simple – add a boot-ID.

boot-ID is a simple, pseudo-random string, that is re-generated by an application upon each start and is never stored persistently. this way, each time application starts, it gets new boot-ID. adding this mechanism to heartbeats/ping-pong messages, polling can be arbitrary long and still detect a failure, since each time reboot/reset occurs, new boot-ID is assigned thus remote application knows “logical connection” was lost.

UUID is an example of possible boot-ID, but in fact any string will do, as long as it is not probable to get the same ID twice in a row. mechanism is trivial to implement and bullet-proof in real-life.

constexpr_and_floating-point

anonymous@undisclosed.example.com (Anonymous) — Tue, 15 Jun 2021 20:09:20 +0000

2016-07-10 - constexpr and floating-point

in C++ a constexpr keyword can be applied to a function. such a function can either be evaluated at run-time or (if possible) at compile-time. now let's have a look at the following trivial example:

#include <iostream>
using namespace std;
 
constexpr double foo(double a, double b)
{
  return a + b;
}
 
int main()
{
  double a,b;
  cin >> a;
  cin >> b;
 
  // 1) compile-time:
  cout << foo(1.333, 2.666) << endl;
  // 2) run-time:
  cout << foo(a, b) << endl;
}

assuming used will provide a = 1.333 and b = 2.666, it is pretty obvious, that both cases should print the same result. now an interesting question part – what will happen in case of cross-compilation, where target architecture has a different floating-point precision, than the host, performing a cross-compilation? this question arose during a post-seminar discussion, on one of the conferences. since i do a lot of embedded programing it turned out to be quite an interesting.

at first one could think results may differ, since it would be natural for an implementation to use double type and operations, offered by a local hardware.

fortunately C++14 makes, section 7.1.5/7 makes it clear:

A call to a constexpr function produces the same result as a call to an equivalent non-constexpr function in all respects except that a call to a constexpr function can appear in a constant expression.

so developers are on a safe side – results will always be the same. however compilers' developers have one more extra thing to do, when implementing cross-compilation, in a context of constexpr functions – they need to emulate floating-point of a target hardware, if it differs from host's.

elevators

anonymous@undisclosed.example.com (Anonymous) — Tue, 15 Jun 2021 20:09:20 +0000

2016-07-10 - elevators

in high buildings there is a problem with time it takes to travel by elevators. elevator speed is one thing, but stopping on every floor is even worse, since there is no time to accelerate and doors need to remain open for a long periods of time on each floor.

it is usually mitigated by adding more elevator shafts. recently i though about doing this in a bit different manner. how about adding more shafts, but each elevator would stop every N-th floor. for instance having 30 floors and 3 shafts (i.e. N=3):

elevator 1 would stop on floors 1, 4, 7, etc…
elevator 2 would stop on floors 2, 5, 8, etc…
elevator 3 would stop on floors 3, 6, 9, etc…

this way each set of floors would have dedicated elevator, this from each elevators' PoV it would be as if building had just 10 (in general: one N-th) floors. travel speeds could be much higher, w/o loosing a comfort of smooth speed ups and breaking. also, on average less ppl would travel by each elevator, thus reducing power needed to move around.

of course, since most ppl do need to access ground floor, it would have to be common for all elevators (as an exception).

how to operate that? it's simple – just press the button (outside of the elevator!), saying where you want to go, and you'll be given shaft number to await at. then just wait for a proper elevator to arrive. when your elevator arrives, you just enter it and travel. as a free bonus - since the elevator already knows where you're heading (you've selected the floor when requesting an elevator), there is no need to squeeze through group of ppl, just to press the button. in fact – the only button such elevator needs to have inside are an emergency stop and a call for service. :)

how_about_it_crowd_pub

anonymous@undisclosed.example.com (Anonymous) — Tue, 15 Jun 2021 20:09:20 +0000

2016-07-10 - how about IT crowd pub?

it is amazing how technologically advanced topics can play a key role over a beer with other tech-geeks. :) recently i was thinking it would be nice to have a pub with a whiteboards to draw on. or even better – a semi-transparent glass, surrounding each table-sets, where you could discuss ideas and share knowledge with friends, while having a beer at the same time. it would be a sort of hacker-space like thing, just w/o all the hardware to distract you. just pure ideas and a very open discussion. :)

while i'm not planning to open a pub, it would be nice to see some1 bringing this idea into a reality.

if such a place exists already, and you happen to know where, please let me know. :)