Re: Another hyperspace bug found --> random and Neural Net

   From: "Ger Hobbelt" <[email protected]>

   Dear Cpt. Crash,

   GCC is correct.

   uint32_t and unsigned long are not the same.
   See the ISO C99 standard: uint32_t guarantees bit size, the C89
   integer types do not. GCC warns you about that.

Yes, that I get.

   So there's not a 'Yo, smarten up' flag, /unless/ it's that one I am so
   desperately waving overhere across the Atlantic for a while already.
   ;-) (Seen me hopping up and down on Scheveningen beach last week?
   Probably not, horizon is in the way, even if we hadn't air itself to
   degrade visibility even at the best of times.)

   See also our, now probably antiquated, discussion over 'int' and
   'long'. Or do I mistake my monologue for 'discussion' again? :-))
   Alas, in another age I might have become a missionary and be roasted
   crispy by the aborginals the morning after my arrival. I'm very lucky.

No,  I did read, and I listened, and I'm trying very much to 
make life for all of the people out there doing ports easier
by coding (when possible) in *_t rather than old-style declarations.

The problem is that it's starting to look like an "all or nothing"
sort of problem- you have to change *all* of your declarations
at once or else GCC will throw a hissy fit.

THEN, you have to add huge amounts of casting to all of your
diagnostics- casting which may _conceal_ the problems the diagnostic
was supposed to reveal.

Is there any fprintf formatting that accepts a uint32_t as the
"default input type"?

That's starting to become a critical issue.  Internal-Trace is
a very strong indicator of where the bug is, and using casts
to keep the warnings out may well obscure the real bugs.


   Bottom line: my tip of the day:

   (1) you are accessing persistent storage (either through mmap()ed
   memory or file I/O or otherwise): use C99 [u]int[8|16|32]_t types to
   ensure bit width across platforms. Let the nutters like me care about
   pore-C99 systems by using a GNU autoconf-based system.

   I may lean towards 'char' as an acceptable alternative for 'int8_t' as
   the days of 9/36-bit platforms have been numbered (though they still
   exist, yes sir). Major representative of that group: PDP-[7..11]. Viva
   el Digital. Imagine porting C code to those boxes: /definitely/ not
   for n00bs <evil laugh>

   (2) when you perform calculations: use 'int' and 'int' only unless you
   have ascended to the next astral plane, i.e. you know what you are
   doing at a rather detailed level and the effects of your work on
   multiple platforms. Alternatively, use double. Or 'float' if you must,
   but be ready for a few unexpected surprises then. (quite a bit of 3D
   render software uses 'float' for improved speed, for example. CRM114
   is NOT an example for float IMHO as we perform very few floating point
   operations, 

Except in the neural net!  The NN is a floating-point beast.

   compared to the 3D/video-render folks. And they have to
   watch their six continuously, so 'double' is a safe haven if you want
   to mind the algorithms and not the platform idiocies.

... which I do.  There are very few "float" values, except where
the byte-consumption is very important and the value itself not
very important (to wit- computed weights in the neural networks
are actually very noisy - intentionally!  There's a whole section
of code there to _add noise_ for Boltzmann convergence!)


   ------<rant>--------------------------------

   GCC is smart enough to know about this: it warns you, VERY correctly,
   because the folks who designed GCC spend quite some time on issues
   like these, and they decided to warn you your code MAY compile on your
   box but MAY contain artifacts which render it nonportable in some
   particular way.

   Anyway, when you or anyone wonders why int/long/int32_t again: here's
   a little pop quiz for y'all: why did the GNU folks develop those
   autoconf tools and configure scripts? Because they love collecting
   system idiosyncracies like 'normal' folks might collect stamps or
   political campaign buttons? My answer? No. They did it because they
   wanted to increase their market share. And you don't get to improve
   your market penetration by requiring every user to buy and use a
   predefined system (I know enough companies who do not allow Linux
   inside their corporate firewalls) but by lowering the decision
   threshold through taking those idiosyncracies into account. If you
   ever feel like it, take one of the pinnacles of portable code, the GNU
   GCC compiler source code itself, and have a look at the configure
   script and platform dependent configuration bits and pieces. Don't be
   amazed and leave. Try to learn from them.

Sadly, they lower the threshold for the end user but raise it
drastically for the software creator.  I've _never_ been able to
get autoconf and friends to produce usable code.  Yes, I've tried.
There is clearly some misunderstanding between what is written in the
HOWTO and what I think I have read.

That's why things have gone the way they have.  The WGET version
is ANSI C, relatively unembellished and meant to do two things:

1) show how to do things (i.e. the target platform is "human brain")
2) filter spam for people (target platform is X86).

I realize that (2) is changing rapidly to X64 and I need to 
move with the times, hence my use of *_t where I can from now on.

Changing every declaration from "classic c" to *_t format is
no longer unthinkable.  I agree that in the long term, it's 
well-nigh inevitable.

I'm just hoping for a magic bullet so that *_t types will play
nicely with fopen, fprintf, and the other "classic c" typed calls.
Because otherwise, we're going to be on a "long long" bughunt. 

   Writing [portable] software is a skill. Demand for that skill is way
   larger than the availability of that skill. So quacks galore. Hence,
   don't take me for my word. Have a look at the GNU code. Start with
   their 'hello world' program; it sounds like a joke, but there's
   several lessons worth in there too. Take a dive and download and look
   at the GCC source code and configuration setup. Those folks are among
   the few who have provable successful ports to a multitude of systems.
   Look at their stuff, keep those 1+2 tip of the day items handy and
   validate them against the GNU code out there. Compare, learn and
   decide how far you want to go in this game. (My goal is: portable to
   any machine with an 8-bit byte, 32-bit or higher native machine word
   and any compiler which supports the non-standard 'long long'. That's
   'all the way' within the boundaries set by the CRM114 algorithms and
   basic implementation.)


   How about the CRM114 case in this regard (int vs. long vs. int32_t)?

   Since CRM114 also ASSUMES your compiler out there knows about the
   non-standard 'long long' you may be in for a bit of a surprise when
   trying to compile on some UNIXes (or other boxes) when you don't use
   GCC.

   But how about generally available 64-bit integers? Everyone's got to
   have them, right?

   No. They do NOT.
   Luck has it that GCC/Linux and GCC/BSD suffers from the Microsoft
   success, i.e. anyone who ain't got either is considered an, errr,
   'odd' individual at the very least, but not everyone will have ANY
   sort of 64-bit integer handy. The folks that don't, do not get to
   compile (or use) CRM114. Ever. Fortunately that market share is
   deminishing every day as PCs are dirt cheap and boxes are written off
   for one reason or another, but if you want to create software for
   everyone, 'long long' is a no no.

Grumble.  OK.  There are not that many places that use long 
long and I think most of them can be switched over to doubles 
without much loss of accuracy.  (yes, it does matter in some
cases, when you're summing up lots of really small values and a few
big ones. You get underflow and lose the small values and the
result is macroscopically _wrong__)

(note- actual check is there are only 23 "long long" variables in
the code.  Most of them can be trivially back-converted to int32_t 
or double.  

The only one of them that looks like it *needs* 64 bits is the
argparse flags block, which genuinely needs 64 bits of real
bit-whackable mask-usable integer to work.

Changing argparse block flags to either fit into 32 bits is possible
but somewhat perilous (right now each keyword is 1:1 with a bit in
the flags block; we *could* re-alias the flags to be unique within
any particular statement type.  

But that's dangerous and hacky.  What do you recommend?


   But what is that loony Ger yakking? We got int32_t et al, ain't we?

   Yes. If your compiler is 100% C99 compliant. Note the '100%' , very
   important, that '100%', and then also note the '99' in there.
   GCC/Linux and GCC/BSD out there will have it, because every admin and
   his sister on these boxes will have installed the latest stable GCC by
   now. Though that is the _majority_, not _everybody_. Check the web for
   trouble with older gcc versions, which are mentioned as an issue in
   2008. They still happen.
   Older GCC versions and VERY MANY commercial compilers (also used on
   UNIXes, my dear!) are NOT 100% C99 compliant. Not because the
   manufacturer is lax in upgrading the compiler (some are), but because
   users MAY want to hold on to their 1000+ USD for upgrading their
   development environments to the latest version. Especially in the
   corporate world this is not done: you don't want to recompile all your
   corporate code and purchae new copies and licenses for your
   third-party licenses, just because you 'feel like upgrading your
   compiler'; I've worked with an old mastodont called Visual C 6.0 as
   late as 2005 and what I hear from good friends is these still live out
   there. And VC6 is only one of many out there, where 'C[89]9
   comformance is rated 'mostly' at the best of times.



   Folks that can't handle it have left for Java. (Or better: quit the
   software development business.) Once there in Java Nirvana, they now
   weep in a happier world, because Java (and the whole refreshed 1960's
   'virtual machine' concept (Microsoft's Dot NET, Sun's Java)) has some
   other issues which, given the right customer requirements, will force
   you to pay attention to the 'unwanted' platform details again anyhow,
   all while you thought you did not have suffer that bit. Only then
   you've got TWO layers of nastiness: the VM and the hardware proper.
   Yay.

Yeah.  One ex-girlfriend (but still a friend) put it this way:

       "Java.  Write once.  Debug Everywhere."

Thanks, Ger.  This helps some...

   - Bill Yerazunis

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php