Re: Solar water heaters - Re: Wonder if they stink?

 
| I use BASIC for calcs and TMY2 simulations. Readability is
important,
| and floating point and log and trig functions. The platform cost
isn't
| important for design calcs, but low cost and low power are important
| for things like a smart whole house fan controller.

Readability is more or less a matter of writing code to be readable,
regardless of language. Here's a transliteration of one of your recent
snippets:

#include <stdio.h>
#include <math.h>

int main(void)
{  double panes, sun, loss;

   for (panes=1; panes<; panes++)
   {  sun = 1000 * pow(0.9, panes);
      loss = 24 * (70 - 30) / panes;
      printf("%.0lf %8.4lf\n", panes, sun - loss);
   }
   return 0;
}

Following the Borland example, some implementations of C (for CPUs
without FPUs) include emulation code. I've written a couple of
software floating point libraries in C to do basic operations (add,
subtract, multiply, divide, square root, and sine/cosine) and they're
not exactly socket surgery.

For one-off projects, none of this probably matters very much. OTOH,
if the object is to produce large quantities and to achieve
performance objectives while using a slower uC, then the savings can
be huge.

--
Morris Dovey
DeSoto Solar
DeSoto, Iowa USA
http://www.iedu.com/DeSoto

 

Yes, but dinosaur Basic is harder to produce clean readable code
with, so that doesnt happen in practice with amateurs like Nick.


The ones handed out to others are just the ones that
need to be readable, if only to check the logic etc.

Corse he should be using a spreadsheet, not a progamming language.


That has nothing to do with whether code is readable or not.

 

Its both. Most of those who continue to use a dinosaur Basic cant
even grasp the concept of what decent readable code is about.


The end result is a lot cruder with a primitive language
like dinosaur Basic and a lot more effort that dinosaurs
like Nick cant even manage to grasp as well.


Corse it is, but that isnt what we are discussing with what Nick produces.


Yes, and in the situation being discussed, what Nick produces,
it isnt the original author that needs the readabilty, its those who
are either deciding if the code is appropriate, or those that need
to change it to make it more appropriate to their circumstances,
what they are attempting to model etc.


Sure, but thats a separate issue to what is being discussed, what Nick
produces and what language is more appropriate for that sort of thing.


Yep, and most never will.


Not with what is being discussed, what Nick produces.


That isnt what is being discussed either, its his turds he drops
which purport to show that a particular approach to a design
is viable in the sense that it will achieve the results wanted.

 
platform, it would

us do is Duane's

It may not require it, but it would normally be a better result
with one, if only to handle the unusual situations better.

 

Having had to maintain other people's code, (some of it 20 year old FORTRAN
'66), I can certainly agree with this.  Heck, over the years I've had to go
back and maintain my own old code and sometimes wished I had done a better
job 15 years ago when I wrote it the first time :-)  The more spaghetti, the
more likely a 'fix' is going to create yet another problem.

Another thing to consider though is reusability.  Nick often starts a new
thread with a new simulation of a new idea.  All well and good, but often
leaves out some detail of the model that may/may-not be relevent.  If
something like reusable objects were his mainstay, then each 'refinement' to
a particular piece would not be lost each time he 'starts over'.
Furthermore, when a project uncovers a need for a refinement to the modeling
of something (say, adding radiant heat transfer to/from a surface where
before only conduction/convection were modeled), all previous
models/projects can quickly be recompiled/linked to use this new refinement.
(as long as the interface is maintained, and even if it needs to be changed,
it's simpler than starting from scratch).  But Nick's code often 'reinvents
the wheel' each time.  That's prone to errors.

Good production-quality coding is not easy.  Often, it's a choice between
'what we have time to do', and 'what we should do'.  Forcing oneself to
refactor, split off another class, cut-out duplicate code and put in a
separate subroutine/function/method, etc... is the price one pays for
maintainability and reliability.  Somewhat like fully normalizing a database
structure (no duplicate information!!!), once in a while good structures
cost a couple of CPU cycles.  But more often then not it also prevents/finds
bugs before it goes to testing, much less production.  But even so, a few
careful 'GOTO's, just like an extra column in a table, can sometimes be
justified for performance.

daestrom