@Szabolcs I remember it well! Actually I read MathGroup for a long time before getting the courage to make my first post, because I really did not want to be sucked into this kind of flame war.
@Szabolcs yes, I understand. I was just curious as to whether it is possible to get the NaN into the system in any other way apart from MathLink. Apparently not.
@Szabolcs I wondered, what will Mma do if fed a raw IEEE754 NaN in a compressed string? Result: Uncompress["1:eJxTTMoPKmIAgx/1ABS8Ay4="] gives Indeterminate
@Szabolcs the performance penalty for unaligned access is highly dependent on the CPU. For Itanium unaligned access could be hundreds or even thousands of times slower. For x86 they try to eliminate the disparity for more and more complex operations with each new CPU design. Yours is a new CPU so I would assume the operation is based on AVX2, which requires 32-byte alignment (due to 256-bit execution units). OSes/C runtimes got wise to the need for 16-byte alignment already, but maybe not 32
@Szabolcs sorry for the delayed response. You discovered something really weird. My guess: alignment issues. This is really important for vectorized operations (I mean using vector CPU instructions). Alignment needs to be to a 16-byte boundary for best performance. Can be that Mathematica just allocates the arrays without much consideration for alignment. Unfortunately, it will be really hard to test this.
@xzczd it's a good question! I don't know the answer though. This seems to go against my understanding of the function. Interestingly they only compare equal if the tolerance is 8 or more digits. This seems excessive. It could have something to do with the difference between e.g. SetPrecision[1.1, Infinity] and SetPrecision[1.1`2, Infinity]? I actually don't know how finite-precision numbers are stored internally
@Szabolcs Good luck. For me it was just sheer luck that the right thing came along at (nearly) the right time, and it's even close to where I was before geographically. I'd already decided I wouldn't pursue an academic career after seeing too many of my friends subject to such career uncertainty as a resulty
@Szabolcs Industry. I quit my postdoc 1 year early leaving the project unfinished, which I wasn't entirely happy about. But on the other hand this is the perfect job for me, almost identical to what I was doing during my postdoc. So now I get to be a postdoc for the rest of my career! :)
@Szabolcs yes indeed! I started a new job back in October and have been kept so busy (and without a licence of Mma!) that I haven't been able to find much time/motivation to visit
So, it seems that Tr does something special, or it's just someone's mistake not to handle it properly. I don't know if you will get any useful response if you raise this with support.
@blochwave what is even stranger, is that Tr is handled using the opcode 47 mechanism (supposed to be a jump straight to the entry point of the function code, no top-level interpretation, still fast). But unlike all other functions handled this way, the second part of the instruction contains not the function's name Tr but rather Tr[#1] &. This is like the normal and slow opcode 46 which copies data out of the VM into top-level symbols and invokes the full evaluator.
@blochwave yes, I think you should certainly update it to mention that Tr is not compilable even though it appears in the list--well noticed. On the other hand, the information Jagra was given by support is indisputably wrong. I think that the appearance of Tr in the list (or the compiler's lack of support for Tr) may be a bug.
@P.Fonseca I commented about this under Wolfgang's answer. I don't know what Excel does internally, but the XLSX format itself certainly doesn't suggest that everything's stored as a double. Maybe if WRI thought that Excel always uses doubles then they will as well, although maybe this is not a great strategy since Excel is numerically crap and other programs might use the same file format without suffering the same numerical problems.
@William since biology is rather a practical discipline (run a PCR, make a western blot, do a fluorescence assay, perform surgery on a mouse...) I believe the best answer is "hire a postdoc" (Ph.D. student if you're daring)
@Szabolcs Hm, I didn't know that any operators work on them except Equal, which seems to just perform a test for identity, not actually numerical equality? Maybe it changed in version 10. I think they're potentially useful for passing objects around that may be subject to casting, apart from the scenario you describe. It can be helpful for bit manipulations, maybe.
@PlasmaHH yes, you're right. And, who knows, maybe I will be interested in longer pulses in the future. (I am a physicist, not EE. This is not to drive a motor or something but to perturb a plasma.)
@PlasmaHH as it happens I'm not really concerned with long pulses anyway. This is really just a curiosity for me, so I could ignore it and there would be no problem in the application. Only pulse widths of less than 100ns are interesting in reality.
@Asmyldof yes, I appreciate that. I asked in here just in case someone had an idea what may cause this in an otherwise properly working circuit. Of course if I ask on the site then I will provide complete information. Actually I now wonder if C_oss increase with falling V_DS (due to bulk capacitance discharge) is causing a new resonance to appear. I will check this.
@Asmyldof I know. It charges and stays charged. Immediately before the oscillation begins there has been no significant change in V_GS since the beginning of the on-time.
@Asmyldof okay, I see what you mean. I had misunderstood your question. During the oscillation I haven't closely examined V_GS because V_S is wildly varying. Before the oscillations start, there is no significant change in V_GS.
