Ah, sorry, I was a bit hasty replying; tidying up the "404" posts led me to skip reading your earlier content!
steph_tsf wrote:I have many FS RubyEdit modules, turning red upon starting, complaining about "nil", then magically becoming healthy after say one second. Now I know that such symptom is probably not related to IEEE 754. Now I know that such symptom is probably caused by improper initialization or missing initialization.
Yes, I've noted the same thing in some of
k_brown's schematics where he's used some of Martin's code. As you say it's related to Ruby initialisation (and possibly differing FS versions?). It happens when the Ruby isn't coded using explicit "init" and "event" methods. The problem goes away as soon as a new 'green' value arrives at the affected input, so a workaround is to attach an "AfterLoad" primitive in parallel with the input connector to cause an explicit update at startup (not ideal, but it saves having to rewrite the Ruby code).
steph_tsf wrote:output(@in.map{ |x| x.nan? ? 0 : x })
The "map" creates a new Array, where every element in the input array is transformed by the code block in curly brackets (essentially an anonymous function passed each array element in turn as |x|). The block is using what's known as the "ternary operator", an abbreviated form of "if..then..else" - here; "[if] x is a NaN [then ("?")] return zero [else (":")] return x". The first '?' is part of the method name "nan?". Ruby allows method names to end with '?' or '!', and by convention, predicate methods which always return true or false usually end with '?' (though the methods added by FlowStone generally ignore this convention!)
steph_tsf wrote:Is there a built-in "square root" component operating in "green"?
There never has been, to my knowledge - I always did think it was a bit of a strange oversight!
steph_tsf wrote:isn't there a "denormal disable" bit that Flowstone could activate?
As discussed a few posts up by MichaelBenjamin, there is; but unfortunately it works at a rather too coarse level to be guaranteed safe to use; and the assembler doesn't currently recognise the opcode to change the setting.
steph_tsf wrote:Unfortunately, they rushed into adding the "denorm" feature
Whatever one might think of the decision, it was anything but rushed. Historically, arguments about denormals led to the IEEE standard taking much longer to negotiate than it might otherwise have done. We're stuck with many historical legacies which don't suit DSP - such as "bankers rounding" being the default rounding mode because IBM's customers were primarily people wanting to do calculations involving money (which rather ironically, they rarely use native FPU maths for these days, because it won't round decimal currency denominations as they would prefer!)
Likewise with support for complex numbers and rationals. They can be supported by explicitly coding them (Ruby has Classes which model both), as any mathematic rules can be implemented from first principles once the basic axioms are in place (q.v. "Turing Completeness"). Many hardware implementers would argue that the x86 instruction set is already too bloated and that smaller instruction sets with faster throughput are more optimal (e.g. RISC architectures). It is a debate which I doubt will ever reach any conclusion which satisfies all parties!
steph_tsf wrote:The FPU should provide the bolts and the nuts that the 40-bit software is requiring for executing as fast as possible. Is it the case? I want to know
You have to be careful here, as "FPU" has a very specific meaning in the context of x86. The FPU is a high-precision floating-point calculator which does use more than 32-bits for intermediate values to guarantee that the result is always accurate to within the smallest bit of precision. However, it can only perform one calculation at a time, and values have to be passed back and forth via a special stack structure. If you see instructions beginning with the letter "f" in assembly code, those are usually FPU instructions.
However, most stream code uses the SSE instruction set, which allows multiple calculations simultaneously, and doesn't need values passing in any special way. These are very much faster, but the range of available maths functions is far smaller, and there are a few which don't operate at full precision (hence my previous confusion about the precision of 'sqrtps').
This separation is yet another historical legacy - floating point maths was an optional extra for the earliest PC's, so was implemented on a separate chip, and SSE was bolted on much later to help support multimedia audio and graphics (originally called "MMX" - multi-media extension). Neither were added with complex DSP in mind, as you will no doubt have guessed!
steph_tsf wrote:By the way, I don't know how they coded "NaN"
Part of the float value itself - by setting the exponent to a sentinel value (infinities work by the same principle).
steph_tsf wrote:How do you this in fixed point? This is complicated
As someone who has previously worked on a fixed-point FFT algorithm for embedded microcontrollers, I heartily agree! (and I strongly suspect that a certain Mr. deraudrl might do too!)
