Small, fast, resource-rich processor

IEEE-754 infinities and NaNs were /not/ designed to make such an algorithm "non-faulty". They just allow the code to continue without a halt or a trap, and see later that the function was called with an invalid input. (It is likely to be the calling code that is wrong here, rather than the called algorithm - except if the called function is badly specified.)

If you have a function f() with a pole at X, and you write "y = f(X)", then the answer is /always wrong/. It doesn't matter if the function returns 0, 27, +inf, or formats your hard drive - it is still wrong. All an "inf" or "NaN" can tell you is that you have done something wrong.

Of course, this can be useful in some circumstances - but it is not really different than setting errno, or returning a struct { bool valid; double result; }, or returning some other kind of signal value.

There are times when you can do mathematical reasoning with functions even at its poles (such as looking at limits close to the poles). But IEEE-754 "inf" does not let you do that - you don't have nearly enough information to do anything sensible except see that you have had an error.

Yes, I think Tim's application is basically in the "eval board" category. It's nicer than a netbook in some ways (gbit ethernet) but I wouldn't consider it a Beaglebone-like low cost hobbyist product either. It was never intended to be a mainstream product, given the presence of GPIO pins etc.

Keeping the original *paper* copy is out of the question. I had just *way* too much paper!

I could keep *images* of each page and, separately, OCR'd versions. But, I'm still forced to "proof" all those OCR'd pages -- otherwise, what's the advantage of having them (if you have no idea how good the versions are).

Easier to hold onto the scanned images (which only require the scanner software to know how to detect black/white/grey/color/etc.) and, later, run those through a piece of software that lets you view raw image and OCR'd image side by side).

[Some scanners preserve the TIFF *and* "text" in the same file but it doesn't eliminate the need to proof it all]

Moral of story: get electronic versions of as many documents as possible!

Exactly true. That's why it is useful for a compiler to have flags like "-ffast-math". (I keep using gcc as an example here, as it is commonly used for all sorts of work from small embedded systems to large, fast, accurate HPC systems. Other compilers are presumably similar.) When you need full IEEE, and are willing to pay for it (such as by having an expensive cpu which handles everything quickly in hardware - or by sacrificing the code space and time), then you compile with full IEEE and the compiler will follow the ordering you give it. When you need small and fast calculations, and know that your algorithm is well behaved for the values you need, then you use "-ffast-math" and let the compiler re-arrange things. For those that need more control, there are more detailed compiler flags.

It is not really any different from any other tradeoffs in calculations. In embedded systems, it's not uncommon to have to calculate sine waves. But if these are destined for an 8-bit accurate PWM signal, then there is no point in using an IEEE-compatible sinf() function correct to 23 significant bits - you can use a small table and linear interpolation to get all the accuracy you need.

As applications and uses change, so do the techniques you need to apply. And of course there are no clear boundaries - as noted before, all generalisations are false :-) There are plenty of embedded applications that require "HPC-style" calculations, and as microcontrollers get faster at arithmetic, there will be more.

The key is to understand your requirements, understand the maths in your algorithms, and understand your compiler. You have to make sure that the code is correct - that it is accurate enough for the job in hand with the values you will use (both now and in the future), and that it is efficient enough for the system in hand. (Correctness trumps speed every time - but for embedded systems it is not uncommon to have a time limit as part of the correctness requirements.) Different techniques are needed to get this right - full IEEE is one way to control ordering and track incorrect calculations, but it is far from the only one.

That's what I meant. Keep the original scanned images, and a separate OCR version.

You don't have to proofread the OCR. 9 out of 10 hits with a search is better than nothing at all.

I agree with your other points...

That's true in an ideal world, but we live on Planet Earth. It is often difficult to find anybody that understands the application domain, is a numerical expert, and is a good engineer. Finding them in one person or several people in the same place at the same time is more than difficult.

What normally happens is that you get several different people each of which incorrectly /thinks/ they understand most of the problem and solution.

Even considering "the best is the enemy of the good", I wish I was that optimistic! :(

Archives, both paper and otherwise, don't tell you where something is, they tell you where it *isn't* (or shouldn't be). In that example, the files won't be in the Y section.

unix soft links can help here, if you know you want something in two places

I've settled on, to copy a few examples jimWilliams-highSpeedAmplifiers-probes-sampling-murphyslaw-an47fa.pdf ug381-selectIOResources.pdf Only have trouble when backing up to DVD and trying to have full Joliot filesystem compatibility :)

Think of it as convergent evolution in action.

There are programs that try to fully index your files and their contents in the background, but they take up so much disk and i/o bandwidth that I turn them off. 'Beagle' is such an example, 'locate' avoids the trap, 'grep' isn't too bad.

I have found a person who is pretty good at the numerical stuff (and can understand what he needs to find and read for the bits he doesn't know), and is a pretty good engineer - me. Now all I need to do is find the time to do /everything/ !

Your point is well taken. When this sort of thing gets complicated, there often has to be cooperation between different people here. The key is that there has to be someone who understands the issues with numerical computation, sitting between the mathematician (who knows that "a * b = b * a") and the programmer (who knows that "a * b == b * a") and can get the details right.

IEEE ordering rules /may/ help a bit here, but they are only an aid - they certainly don't help for all issues.

Haven't you heard that two minuses gives a plus? :-)

Assumes the archive resides on something that *supports* symbolic links! :-/

I've used a 1T NAS for my "papers" archive and another for my "devices" archive (i.e., material associated with some physical device like user manual, service manual, etc.). I keep binaries and sources on another pair of 1.5T "external disks" (which can be seen as *more* or *less* accessible!)

Yup. Or problems copying stuff onto Windblows machines (MAX_PATH_LEN); "ReadMe" and "README" residing in the same directory on the NAS, etc.

Usually, there's enough information in just the title so I can find what I am needing just by grep(1)-ing a "list of filenames" (essentially, mimicking locate(1)'s functionality without having a daemon running to build that list).

E.g., "A four-parameter model of glottal flow". I *know* where it's going to sit in my file hierarchy (generally) so there are several keywords that will bring it to the top of the list of results...

At least one of the tools here gives me that capability (I can't recall which -- "searchable TIFF's")

It gives you a false sense of security.

Ages ago, I "scanned" all my bank statements, credit card statements, etc. -- excellent way to get rid of "useless" paper! :>

Come tax time, I figured I could "cheat" and just pull the "data" from those scanned copies (instead of transcribing detail records by hand). That was my first "disappointment" with COTS OCR. "Why can't I find a record of this check being deposited?" The "save the image, only" strategy grew out of that experience. It satisfies my primary goal: getting rid of paper. It just doesn't give me much *more* than that!

If you do it right, the OCR'd text is just stored as a transparent layer over the image layer in the PDF, so you have both in the same file. And you can always touch up the OCR layer with your favorite PDF tools (and still leave the image layer alone). While not perfect, you can search much of the document - which is better than none at all.

FWIW, many of the manuals on bitsavers are stored that way.

OTOH, were I still looking, the $200 would put it in the "budget" category for me.

Engineering time costs money. If you're only building a few units, its irresponsible to stick your nose up at a $200 board, then go spend $1000/ board or more of extra engineering time so you can "cut expense".

--

Tim Wescott 
Wescott Design Services 
http://www.wescottdesign.com

case dependent filenames is perhaps the worst "sweep it under the carpet" example, it is amazing how longlived they have proven (obviously because of unix). Now that is way off DSPs and resourses of course but I am still polishing my newly implemented "longnames" for DPS so the phrase above worked sort of like a hot button, I suppose :-) .

Dimiter

------------------------------------------------------ Dimiter Popoff Transgalactic Instruments

------------------------------------------------------

Certainly if you want a commercial product $200 is not a problem. But I don't know that I would use any of these in a commercial product. The rPi is just too loosely supported. Also they haven't been out a year and they are on a second version which is incompatible in many respects with the first. The BBB seems like a more professional unit, but they specifically state it is *not* supported for commercial use. The guy providing support said this is because they want to be able to change details without worrying about the impact on users. The BBB itself is a good example. The software for this board took a major deviation from the other BB boards and it does not fully support the various daughter boards yet.

As for the Minnowboard, I don't know if it is suitable for commercial production or not. From what I have seen so far Intel is throwing this out in a similar manner to the rPi, but the $200 price tag doesn't seem to indicate that. For that price I would expect real support. We'll see.

--

Rick

Yeah, I figured there was a good chance $200 was acceptable for your purpose, though I didn't know for sure.

It sounds like you found something. Can I ask what you ended up using?

I've talked the customer into letting me run it on their PC.

It was one of those internal project politics things -- the PC is running a nifty graphical display, and the guy in charge of the software for it was uncomfortable with taking responsibility for the code written by the wild-eyed algorithm consultant.

After we realized the extent of the processing necessary, and after I groveled a bit, we found me a space on the main processor.

--

Tim Wescott 
Wescott Design Services 
http://www.wescottdesign.com

I was doing some work on the BeagleBone a few months back (which seems to be an eternity these days...) and Robert Nelson had a spin that we used which supported it and our bluetooth module (an LSR TiWi-BLE). Perhaps he has something to support the BBB (which I presume to mean BeagleBone Black)?

--
Randy Yates 
Digital Signal Labs 
http://www.digitalsignallabs.com

Hmm, ok, that sounds like the simplest approach, so nice work. Though if it's a realtime or critical application, I could see wanting to run it on a separate machine, that isn't periodically seizing up to download software updates or spazzing in the grips of some software virus. Anyway I'm glad something worked out.

Here is a link to a report on the software issues of the BBB (yes, that's BeagleBone Black).

--

Rick