From: Don K on
"Morris Dovey" <mrdovey(a)iedu.com> wrote in message news:4591b388$0$503$815e3792(a)news.qwest.net...
> "Don K" <dk(a)dont_bother_me.com> wrote in message
> news:StmdnXS7kbxHMgzYnZ2dnUVZ_tW3nZ2d(a)comcast.com...
> | "Morris Dovey" <mrdovey(a)iedu.com> wrote in message
> news:4591a689$0$507$815e3792(a)news.qwest.net...
> | > "Joe Fischer" <joe(a)westpointracing.com> wrote in message
> | > news:ng53p2pavknkpiash4e28thk2hn770sd7k(a)4ax.com...
> | >
> | > | When doing any energy calculations, it
> | > | helps to be able to work directly with the source
> | > | code and an interpreter.
> | >
> | > This pre-supposes that the person writing the code has, at best,
> an
> | > incomplete understanding of the problem.
> |
> | Just because someone has written specialized code for a specific
> | application, doesn't mean they have an incomplete understanding
> | of the problem. They're just being cost-effective.
> |
> | > A person who understands the
> | > problem and the tools being used implements the solution directly.
> |
> | Sometimes it's more efficient to do it yourself from scratch,
> | and sometimes it's more efficient to build on the work
> | of others.
>
> Hmm. I must not understand - seems to me that the only reason for
> "tinkering" would be to "get it right". If the person writing the code
> understands the problem well enough to implement a solution and
> understands the language being used for that implementation, tinkering
> is "goofing off".
>
> Goofing off is neither cost-effective nor efficient.
>
> None of this has anything to do with choice of a programming language.

I think we were just talking past each other.
You were talking as a programmer and I was talking as an engineer.

In the engineering world it's ok to construct a simplified computer
model that applies to one specific situation as long as it is accurate
enough to give you what you need. It's also ok to modify (yours or someone
else's) source code later on to enhance modeling accuracy as required.

Don


From: Anthony Matonak on
Jeff wrote:
....
> 2) Whatever the language chosen for any of our solar projects, on
> whatever platform, it would have more than enough speed to suit our
> needs. The most critical thing any of us do is Duane's trackers and I
> doubt even they need much horsepower.

Duane's trackers are, at worst, a couple of logic gates and
don't even require a microcontroller, let alone source code.

I wonder... What solar application would require a CPU?

Anthony
From: Morris Dovey on
"Don K" <dk(a)dont_bother_me.com> wrote in message
news:d7-dnSvGTOKSNw_YnZ2dnUVZ_oipnZ2d(a)comcast.com...

| I think we were just talking past each other.
| You were talking as a programmer and I was talking as an engineer.

Yup - I think we were. B'sides all programmers know that Engi...

(never mind) <vbg>

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



From: Rod Speed on
Morris Dovey <mrdovey(a)iedu.com> wrote
> Rod Speed <rod.speed.aaa(a)gmail.com> wrote
>> Morris Dovey <mrdovey(a)iedu.com> wrote
>>> <nicksanspam(a)ece.villanova.edu> wrote

>>>> 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.

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

> I think it's less a matter of difficulty than motivation.

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

> It's possible to use the same techniques to produce
> readability in BASIC source code as are used in other
> programming languages (indentation, whitespace, etc)

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.

>>> 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<=10; 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.

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

> There's more to the issue if the code is anything other than just a
> throw-away "doodle". Readability is an important part of "maintainability".

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

> When code is revisited (for correction, expansion of function,
> etc) it needs to be readily understood by the maintainer,
> who may or may not be the original author.

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.

> If the code is such a mess that it can't be understood/maintained,
> the best that can be hoped for is to re-develop from scratch (expensive);
> and the very worst that can happen is that a maintainer "take his best shot"
> at patching in something he hopes will effect the appropriate change(s).
> This latter usually has the effect of making the code still less
> maintainable - and frequently introduces a fresh set of problems.

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.

> All this is difficult for people who only dabble at coding to grasp.

Yep, and most never will.

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

>>> 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.

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

> You're right - readability is only one of the factors that
> contribute to the worth of a program. Still, it /is/ important.

Not with what is being discussed, what Nick produces.

> In the context of Nick's stated objective, the ability to
> produce a reliable controller at a cost that allows the
> greatest number of people to afford and use it /is/ the point.

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.


From: Rod Speed on
Anthony Matonak <anthonym40(a)nothing.like.socal.rr.com> wrote
> Jeff wrote

>> 2) Whatever the language chosen for any of our solar projects, on whatever platform, it would
>> have more than enough speed to suit our needs. The most critical thing any of us do is Duane's
>> trackers and I doubt even they need much horsepower.

> Duane's trackers are, at worst, a couple of logic gates and
> don't even require a microcontroller, let alone source code.

> I wonder... What solar application would require a CPU?

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