Skip to main content

Humans Prefer To Walk Anticlockwise, Scientists Find

2 months 3 weeks ago
fjo3 shares a report from The Guardian: Tests reveal that when people are ambling about, they have a natural tendency to turn to the left and walk in an anticlockwise direction. "If you simply ask someone to start walking, whether they are wandering around a museum, a supermarket, or even an empty room, it is surprisingly likely that they will drift counterclockwise," said Dr Inaki Echeverria Huarte at University of Navarra in Spain. As with many critical discoveries in science, the revelation owes a debt to serendipity. During the pandemic, the researchers ran experiments to see how many people could share a space while keeping a safe distance. On reviewing the video, they noticed that crowds overwhelmingly walked in an anticlockwise direction. The surprise set in motion an entire research project. The scientists conducted a series of experiments in which individual pedestrians or small crowds roamed around enclosed spaces. Time and again, the researchers observed the tendency to walk in an anticlockwise direction. Suspecting that cultural norms might play a role, the team joined forces with Dr Claudio Feliciani at the University of Tokyo. He found the same results in Japan. The finding held when the researchers accounted for people being right-handed, right-footed and right-eye dominant, and was seen in both male and female walkers. The only difference they spotted was a more pronounced bias in children. "Each of us carries a small personal bias to turn slightly to one side, and when many people share a space, those tiny biases add up into a net counterclockwise rotation," said Echeverria Huarte. Researchers think the tendency may be tied to biomechanics: people are not perfectly symmetrical, and the way the brain processes sensory information and coordinates muscles may gently tip walkers toward one side. Right-side dominance may also play a role, especially in running, where anticlockwise movement puts more internal force on the right side of the body and may feel more natural to right-leg-dominant athletes. "We have tested several ideas and the bias stubbornly keeps showing up, so the exact mechanism is still an open question," said Echeverria Huarte. The findings have been published in Nature Communications.

Read more of this story at Slashdot.

BeauHD

CodeSOD: Dating in Hungarian

2 months 3 weeks ago

A horse can only be so tenderized, but as well established at this point: I don't like Hungarian Notation. Richard G sends us an example of yet more of it, being misused, as well as some bad date handling. That's basically two of the easiest things to complain about, so let's take a look!

DateTime sCDate2 = Convert.ToDateTime(Hdn_SelectedDate.Value); Double dStart2 = double.Parse(Hdn_SelectedShifts.Value.Split('@')[0]); // Gets something like "10.5" for 10:30 // More code ... DateTime lSelectedStartAdd = DateTime.Parse(sCDate2.ToShortDateString() + " " + DateTime.FromOADate((dStart2) / 24).ToShortTimeString());

We take the value of Hdn_SelectedDate, which is one case where I'm actually willing to be a bit flexible on my hate of Hungarian Notation. In this case, it tells us that this is a "hidden" field on an ASP .Net form. Of course, storing a bunch of data in hidden fields on your form is a dangerous pattern, and in this case, they're carrying between 30 and 50 different pieces of data from one page to the next as hidden fields.

In any case, we take the value of that field and convert it to a datetime, storing the result in sCDate2. Here, the questions start. s, conventionally, tells us that this is a string. But it is not a string, it is a date. Why is it CDate? Actually, why is it CDate2? What's so 2 about this? There is no sCDate, sCDate1, or any other variation thereof- why 2?

Then, we look the contents of Hdn_SelectedShifts. This is another hidden field, and this one stores a string that is delimited by @s. We take the first element, which represents a time of day- as a double. 10.5 means 10:30. That's certainly a way to represent a time of day.

With this data in hand, we then use this to populate the lSelectedStartAdd variable. Once again, the l exists to mystify us. In some Hungarian flavors, it could mean "local variable", but if that's the case, why aren't we using that for any of the other local variables? More commonly, it might mean "long integer", but once again: it's a date.

This all brings us to DateTime.FromOADate. No, this is not when you Netflix and chill while watching cheap streaming sci-fi, OA in this case stands for OLE Automation, and now we have to go down a rabbit hole which has nothing to do with any of this code.

One of the things which made Windows what it was was the use of COM; the Component Object Model was an object oriented approach for letting applications talk to each other. It's what gave us DLL Hell, but it was also a really powerful system for automating software. You could use Visual Basic to leverage COM libraries provided by other software; even if the software you were targeting didn't have a scripting system, you could write your own scripts to control it anyway. OLE, Object Linking and Embedding, was a subset of all the COM functionality. It replaced Dynamic Data Exchange, which was the previous way of automating applications. With COM, COM+, DCOM, DDE, OLE, Microsoft created a whole soup of ways to link to functionality exposed by other applications. It was a giant mess, and I just put this paragraph here to flashback on the horrors of that era.

In any case, because OLE was mostly about automating Office applications, and because of Remy's Law of Requirements (no matter what the users said they want, what they really want is Excel), OLE Automation has its own date data type, which is a floating point number measuring the offset from December 30th, 1899. Which, of course, is not Excel's date epoch: Excel starts at 31-DEC-1899. Except Excel inherited its epoch from an older spreadsheet tool, Lotus 1-2-3. And Lotus had a bug: it thought 1900 was a leap year. Which means in practice, for any date past 28-FEB-1900, the effective epoch is 30-DEC-1899. Excel intentionally recreated the bug, because it needed to be compatible with Lotus 1-2-3 if it had any hope of competing in the market. One pesky little detail and now 1900 is a de facto leap year.

I'm sorry, we've got afield. We have dStart2, which is a floating point number representing hours in the day, with minutes as the fraction. We divide that by 24, then pass it to FromOADate, which will now treat that as an offset from 30-DEC-1899 00:00:00, giving us a date like 30-DEC-1899 10:30:00. We grab the time string off that, the date string of four date, munge them together and parse it back to a date.

Of course, the C# DateTime type has an AddHours, so they could have just done scDate2.AddHours(dStart2) and skipped all the parsing.

You want to know something more fun about this? That floating point representing time? It's initially populated by having users select off a drop down, and the drop down uses as its labels the more conventional HH:mm format. The value stored by the drop down is the floating point value. And yes, someone did manually write all that out in the code, they didn't use a loop or anything.

In any case, this is a long winded reminder: I hate Hungarian Notation.

[Advertisement] Keep all your packages and Docker containers in one place, scan for vulnerabilities, and control who can access different feeds. ProGet installs in minutes and has a powerful free version with a lot of great features that you can upgrade when ready.Learn more.
Remy Porter