Re: "the last full Moon on Feb. 29 was in 1972, and the next will be in 2048"
Nice power of two, that next one.
I'll get me coat
4539 publicly visible posts • joined 24 Apr 2007
Glad I have never been in any such situation. In the Netherlands any large employer needs to have a health and safety officer or ombuds person to approach if you feel unsafe. Our university has a confidential advisor that can also be reached for these kind of issues. I have once referred someone to this advisor (not for violent threats, fortunately), and they were of great help. Rules here in the Netherlands can be found here:
https://business.gov.nl/regulations/staff/health-and-safety-at-work/
Quite apart from the very valid practical issues raised here, one should bear in mind shortest path algorithms have their uses elsewhere. Certain graph-cut methods seek a lowest cost path for e.g. image segmentation. This is a very different situation where n runs into tens of millions or billions. In this case, the new algorithm may show benefits. Besides, a new algorithm like this might inspire new algorithms in entirely different areas.
This could have come from the BOFH excuse calendar.
It reminds me a bit of the time a conductor complained about the excessive echo in a particular concert hall, claiming he could not have his orchestra perform this way. He asked the sound tech what could be done, and the sound tech with a complete poker face suggested replacing the red stage curtains with another colour (in this case blue). It was exactly the same fabric, with exactly the same acoustic properties, but the conductor was totally happy with the resulting "change".
It is rare for a lead admin and IT director to show their gratitude this way. Far too many would claim the successes of their underlings as their own. Hats off (leather Nebraska for me today) to the director and admin, and of course to Carl for finding the fault in the first place.
I once designed and soldered together an experimental PC board with PC/AT bus with a load of LS-TTL electronics to control the exposure time of a CCD video camera and microscope illumination. Inserting this into one of the lab's image processing stations and switching it on caused a distinct feeling of apprehension. I was half expecting some "KZZEERRT" type noises, some smoke, and the distinct smell of burnt silicon. However, nothing happened, which was a huge relief. I started up the controller program to detect the presence of the new board, and nothing continued to happen, which was less encouraging. I then poured over the design, and checked the documentation of the PC/AT bus. It turned out I had missed a thin line over the ACK pin, i.e. it was logically NOT ACK. Luckily I had a spare NAND gate on one of the 74LS00 chips on the board, and could use that to invert the ACK signal. The board worked flawlessly after that. I soldered together some 6 of them, and each time inserting them into a PC and switching it on made me nervous, but happily no fireworks ensued.
This reminds me of the notion of an "appeasement engineer" (someone with an engineering diploma so fresh the ink is only just dry), in what I believe is the very first BOFH episode (certainly the first I read).
Even without the rule in place, I would be very suspicious if someone in an office environment asked me for pliers, or other tools (soldering irons spring to mind). I would definitely want to know what they were up to before I allow their grubby little hands to touch MY tools.
But then maybe I am paranoid
Or just experienced
Years ago, our university wanted to standardize IT support, so the computer science department I work in had to transfer our (very capable) sysadmins to the centralized IT department. We did insist that we keep working under Linux, and a university-standard Linux distribution was put in place, next to the standard Windows set-up used by the vast majority of the university. So far, so good.
However, the help desk was centralized as well, and where in the past I would simply call our sysadmins (or drop by their office) if there was a problem, and got it sorted without hassle, I now had to phone a help desk, where they first went through a script aimed at the standard Windows install. The first time this happened, I told the person on the other end that my machine was a Linux box, and he answered that they didn't support Linux, only Windows. I told him he was wrong, and I was running the university-standard Linux install, but he remained adamant there was no such thing. After a fairly pointless "Yes it is! - No it isn't" loop worthy of Monty Python, I threatened to file a complaint if he did not put me through to the sysadmin who installed the Linux system he said didn't exist. As I mentioned the name of said sysadmin he could hardly suggest that that person didn't exist, and the problem was quickly sorted.
All is well that ends well, I should add, as we now have a very capable sysadmin delegated from the IT department to our institute, so I do not have to answer any stupid script questions about Windows settings my machine does not have.
a user claimed the image display of the microscopic image processing system I developed was upside down, and this had to do with the software update I had provided. I explained that the update did nothing to the screen, but she was adamant the software was the problem. I came to the lab, noted that the image display seemed fine, as all the letters on it weren't upside down, the status bar was in the right place, etc. She then said that the letters were OK, but the bacteria on the image were upside down, compared to how they looked through the microscope. I took one look at the microscope, rotated the camera 180 degrees, and the problem was solved.
Case closed ... except that moments later she claimed the mouse was working in reverse (cursor went left when the mouse when to the right, etc.). I again explained I had changed nothing in the mouse settings at all. Again, she was adamant the software update was to blame. Again I trundled over to the lab, looked at the mouse, rotated it 180 degrees so the "tail" was pointing away from the user, and declared the problem solved. To her credit, her cheeks did turn a fetching shade of scarlet in embarrassment. We both had a good laugh.
A totally, gobsmackingly bad "design decision" (phrase used without prejudice) by the application vendors, and monumentally stupid decision by management to accept the vendor's "explanation".
The vendor had better not try this on any BOFH, or they might have an ... accident in the elevator, or a database normalisation warning (the latter seems more appropriate)
Our research group once did an unannounced Halloween prank by all coming dressed (in)appropriately to our university. Some students, and colleagues from other groups were somewhat befuddled when they saw me sweeping through the corridors, clad in a long black hooded robe, skull ring and black staff as John Hix, Professor of Post-Mortem Communications (definitely NOT necromancy!!).
There's a relic of fax machines to be found if the TIFF file format in the form of CCITT modified Huffman run-length encoding. I recall implementing that in my own TIFF-IO module for our image processing systems, way back when (1993, as I recall).
I also recall stories of fax machines being set up to send reports to the head office after midnight. Sometimes the phone number hadn't been entered correctly so some poor sod got woken up in the middle of the night, pick up the phone, and being treated to the scream of a fax machine trying to update sales figures.
I've heard of that ...
For some reason there's still an old Compaq 80486 DX @ 60 MHz with 8 MB RAM and an ancient tape drive, and a hand-soldered experimental video camera exposure control ISA-Bus board I designed during my PhD work. You never know when that old tape drive might come in handy.
Working on a parallel program for simulations of bacterial interaction in the gut micro-flora, I got an "Impossible Error: W(1) cannot be negative here" (or something similar) from the NAG library 9th order Runge-Kutta ODE solver on our Cray J932. The thing was, I was using multiple copies of the same routine in a multi-threaded program. FORTRAN being FORTRAN, and the library not having been compiled with the right flags for multi-threading, all copies used the same named common block to store whatever scratch variables they needed. So different copies were merrily overwriting values written by other copies, resulting in the impossible error. I ended up writing my own ODE solver
Having achieved the impossible, I felt like having breakfast at Milliways