Sample batch two is the correct way to do it with one exception the date mechanism. YYYY.MM.DD is the correct format that should always be used in any naming convention.
The best setup I’ve ever seen was: YYYY.MM.DD - LTxx example 2014.07.15 - 1804 LT was the lab tech # and xx was the sample # associated with the lab tech and date.
As someone who lived through Y2K not using 4 digits for year just makes me itchy. The rest would be fantastic for a large multi building setup like Mayo.
But why do we need the bitwise AND for that, specifically? I understand the idea, but would it not be easier to only parse the IP address string of bits only for the first n bits and then disregard the remainder (the host identifier)?
Essentially it boils down to:
bit operations are stupid fast and efficient, String operations are super slow.
Also, IP addresses are always stored as int32/int64, so applying String operations would require them to be converted first.
Though I would like to clarify that maybe my wording was a bit confusing. By “string of bits”, I did not mean the term as it is typically used in programming language environments, but rather a raw binary sequence, e.g., the first 24 bits of an IP address, therefore allocating 3 bytes of memory for storing the NID.
but rather a raw binary sequence, e.g., the first 24 bits of an IP address, therefore allocating 3 bytes of memory for storing the NID.
That would require dynamic memory allocation, since you can never know what CIDR your stack encounters. It could be a nibble, a byte, a byte and a nibble, …, 4 bytes. So you would allocate a int32/int64 anyway to be on the safe side.
Yep, I agree. Though one could make a hypothetical argument for expanding the array dynamically when needed. Of course, due to the varying sizes of NIDs resulting from CIDR (which you correctly mentioned), you would need to have a second array that can store the length of each NID, with 5 bits per element, leaving you with 3 bits “saved” per IP address.
That can end up wasting more memory than the 32-bit per NID approach, e.g., when the host identifier is smaller than 5 bits. And there’s the slowness of memory allocation and copying from one array to another that comes on-top of that.
I think that it is theoretically possible to deploy a NID-extracting and tracking program that is a tiny bit more memory efficient than the 32-bit implementation, but would probably come at a performance overhead and depend on you knowing the range of your expected IP addresses really well. So, not useful at all, lol
I’ve never heard of this show, but from what you’ve said and the quick research I’ve done it sounds like something I would be interested in. Thanks for the mention of it!
You wouldn’t, of course. Hearing, the way we hear, in such an environment would be useless. We wouldn’t have evolved that. This is like saying “ultraviolet radiation from the sun would be everywhere, all the time, can you imagine?” It is everywhere all the time, but as such it isn’t a useful sense to possess, so we don’t.
This also makes some very weird assumptions about what the sound would be like. If space were a medium sound could travel through then it would–like all mediums capable of carrying a sound wave–alter the wave in many ways. Intensity, frequency, etc. But since we don’t know what kind of medium that would be, and since the comment doesn’t posit any particular medium, we don’t know what the sound would sound like or even how loud it would be.
I assume that this thought experiment posits a space filled with the same average density of particles found at ground level on Earth. Obviously such a thing is nonsensical, but it serves to illuminate one aspect of the raw power of the Sun that we ignore, because we’re insulated from it by 93 million miles of vacuum.
By your logic, light isn’t a useful sense to possess since it’s everywhere all the time thanks to sunlight and moonlight, is that correct?
Actually, since ultraviolet radiation and light are both electromagnetic waves, they should be treated the same, shouldn’t they? It’s as if there could be a different reason why we can detect one but not the other.
If the sound is more of a loud hiss, you might find that echolocation can work very well. Much like our eyes collect available light bouncing off surfaces, similar techniques can be used with sound.
What you do for work might be a factor, but i dont think pain to that extent is normal. I would stress to your doctor that basic tasks are painful and that youd like to get checked out anyway. Youve got nothing to lose by getting it checked, only to gain. Im in my mid 20s too and while i get aches in my knees/back occasionally its not debilitating as you describe it.
No, this is not normal. I would honestly look for a different general practitioner. I would start by just getting a full blood work panel done if you haven’t had that yet, and hopefully that will provide some insights right off the bat.
kbin.life
Oldest