Thomas Koenig wrote:
> Terje Mathisen <terje.mathisen@tmsw.no> schrieb:
>
>> Even with perl's slow interpreter, and no attempt to extract prime
>> factors from 747000000, just a brute force scan, it took about 0.2
>> seconds to find the solutions for either 7.47 or 7.11 as the total sum.
>> (Verifying that they were in fact unique took another 40 ms.)
>
> Which shows that an interpreter on a (I assume) relatively modern
> machine 2021 is _much_ faster than an interpreter on a machine
> introduced in 1982, whose CPU ran at ~ 0.3% of the clock speed of
> today's machine, which had an 8-bit processor doing floating point
> on a 40-bit format with a 32-bit mantissa without even instructions
> for an 8-bit integer multiply.
>
> It was _all_ shift and add for multiplication.
>
>>
>> C(++) would almost certainly run this at least an order of magnitude
>> faster, but using the prime roots as the starting point, noting that
>> there is a single large factor (of 747/9=83), and then use that as the
>> first term would help even more:
>> ...
>> Yes indeed!
>
> Ah, I don't think we noticed that at the time. Good catch!
>
>> Starting the search with n*0.83 as one of the item prices reduced the
>> search time from 200ms to less than 9, and full verification took just
>> 11 ms.
>
> There is actually a bit more to the story. It was one of the
> first days after I had started studying, which is why I remember
> the approximate date so well. The people I shared a flat with had
> looked at the problem for a short time without even hitting on the
> rather obvious fact that, for a+b+c+d=s, you only need three loops.
>
> We ran a few benchmarks and concluded that a run would take a
> few months on the C-64, and gave up for a time.
>
> One of us, a first-semester computer science studend, then left.
> The rest of us looked at the problem again, noticed d=s-a-b-c, and
> used a few more simplifications, which brought down the calculation
> time to around half an hour.
>
> One of us (not me) then had an idea. He sat down and wrote down
> random formulas from "Bronstein"The formulas looked impressive,
> but had absolutely no bearing on the problem. When the C.S. student
> returned late in the evening, we gave him the sheets of paper
> and told him this was the analytical soluttion. The unsuspecting
> C.S. student believed us for a few weeks, because he still thought
> that a calculation would have taken months, and was quite impressed.
>
Nice story!
:-)

You could have solved this very quickly indeed on that C64 if you had
started with the full factorization, i.e. the prices in cents needs to
multiply out to 747e6, or 83*5^6*3^2*2^6. This is 15 terms but only 4
different bases which strongly limits the number of possible
permutations, and at the same time removes the need for any
multiplication during the verification stage: Just add the terms
together and look for a 747 sum.

Terje

--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

pec...@gmail.com wrote:
> wtorek, 20 lipca 2021 o 10:53:19 UTC+2 Thomas Koenig napisał(a):
>
>> I'm not sure what you calculated here.
> The point is to have a good starting point.
>> However, as stated, this is a Diophantine equation (integer
>> solutions only), so approximate solutions are not valid.
>> Diophantine equations are generally much harder to solve than
>> equations that involve real numbers that can be solved
>> approximately using floating point values.
> It is not a Diophantine equation. The numbers are decimals with fixed
> point arithmetic. Numerical analysis guarantees that fixed point
> product can not be too far from the real one, so you can dramatically
> restrict the search space: approximately +-0.03 around every value
> but we need to consider all permutations of values (multiplication
> with rounding is not connective).
>

Yeah, (7.47)^(1/4) is approximately 1.65, while 7.47/4 is nearly 1.87.

I.e. the average of the prices is 0.22 higher than the geometric mean,
which means that a solution is in fact possible.

Terje

--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

> That was original defitibition. Parallel was distributed computing via
> MPI eg, while concurrent ment via threads on single computer.

Those terms predate MPI by a long shot.

Stefan

Marcus <m.delete@this.bitsnbites.eu> schrieb:
> ...but I agree that we need language support for parallelization. For
> instance order-independent loops and similar constructs should be the
> goto solution (no pun intended)

Of course, there's GotoBLAS, which makes for even worse puns
(named after Kazushige Goto).

> rather than explicit iteration logic.

Fortran has had DO CONCURRENT for quite some time, but it hasn't
become a huge hit.

Of course, it's the dependencies between loops that cause problems
(see our recent

> Likewise pure functions should be the norm (object orientation really
> screwed that up).

Why did object orientation screw that up? If you restrict yourself
to carrying around state in your objects and not as global state,
that helps a lot. Of course, if you want to go very parallel you
have to share the vtables of your objects in an efficient way,
but that should be doable.

> And of course good support for async primitives.
>
> Then we can start designing hardware that can spawn lightweight threads
> as easily as they can call subroutines. But as long as everyone uses
> old-school C and stdc functionality there's little use in trying.

There is a _lot_ of use in trying - all the OpenMP stuff is based
on threads, and having these more efficient would help a lot.

However, I am not sure that imperative programming languages
are the best way to go.

Some variant of declarative programming language, where you specify
that A = B op C, but without a prescribed ordering, could help there
(like a Makefile, if you will). If you start with something like SSA,
this could well help.

The compiler, aided by the hardware, could then build up a
dependency graph which would expose the inherent paralellism of
the algorithm. Of course, building this graph could well be much
more expensive than running that program serially. You could also
do this starting with an SSA form for your whole program, of course...

I read an article about this concept in Scientific American,
oh, it must have been in the 1980s or possibly 1990s. The fact
that we do not do this now obviosly means that this hasn't been
a resounding success.

In a way, we do this kind of thing already with OoO execution:

add r1,r2,r3
subi r4,r1,3

could also be written, Makefile-style

r1: r2, r3
r1 = r2 + r3

r4: r1
r4 = r1 - r3

to be executed at the hardware's discretion. Of course, we only
have a very limited number of names available bcause of the limited
number of registers that we usually have.

On 2021-07-21 17:56, Thomas Koenig wrote:
> Marcus <m.delete@this.bitsnbites.eu> schrieb:
>> ...but I agree that we need language support for parallelization. For
>> instance order-independent loops and similar constructs should be the
>> goto solution (no pun intended)
>
> Of course, there's GotoBLAS, which makes for even worse puns
> (named after Kazushige Goto).
>
>> rather than explicit iteration logic.
>
> Fortran has had DO CONCURRENT for quite some time, but it hasn't
> become a huge hit.
>
> Of course, it's the dependencies between loops that cause problems
> (see our recent
>
>> Likewise pure functions should be the norm (object orientation really
>> screwed that up).
>
> Why did object orientation screw that up? If you restrict yourself
> to carrying around state in your objects and not as global state,
> that helps a lot. Of course, if you want to go very parallel you
> have to share the vtables of your objects in an efficient way,
> but that should be doable.

My definition of a pure function is that it is guaranteed (via the
function signature) to have zero side effects. In other words it must
not mutate any global state nor mutate any input data - it can only
read input data and generate output data (return values).

In object oriented programming every class method has the object as an
implicit input parameter, which means that it *may potentially* mutate
the object data (unless the method is explicitly declared "pure" in some
way). Thus, in most object oriented programming languages every method
is non-pure *by default*, and this is the way people have learned to
design programs (i.e. mutating object state as part of a class method
call is just normal state of affairs).

My point is that OOP invites to writing non-pure functions. Sure, old
style C did the same (using global variables was very common before
the advent of OOP), but these days I often find modern C programs (or
C++ programs with regular functions) to be written more in the
functional style.

The first time I really understood the significance of pure functions
versus concurrency was when I started programming GPU shaders. I had
a hard time getting my head around it until I realized that the main()
function of a GLSL fragment shader (for instance) is just a pure
function that gets access to a lot of read-only data (textures, uniforms
and varyings/ins) and all it can do is to output a few return values
(e.g. the pixel color) - it may /never/ mutate any data (textures, frame
buffer, ...) or keep any global state around.

And that is precisely why GPU shaders can be arbitrarily parallelized.

So what I'm saying is that in a language where pure functions are part
of the design philosophy you will have a much easier time extracting
parallelism, and it would encourage programmers to write code that lends
itself to parallel execution. So far, OOP languages have usually been
going in the opposite direction.

>
>
>> And of course good support for async primitives.
>>
>> Then we can start designing hardware that can spawn lightweight threads
>> as easily as they can call subroutines. But as long as everyone uses
>> old-school C and stdc functionality there's little use in trying.
>
> There is a _lot_ of use in trying - all the OpenMP stuff is based
> on threads, and having these more efficient would help a lot.
>
> However, I am not sure that imperative programming languages
> are the best way to go.

Functional programming languages have a lot going for them in terms
of suitability for parallelization. They seem to have some things going
against them though, since they have never become as popular as
imperative languages (I for one have never really enjoyed classic
functional languages).

>
> Some variant of declarative programming language, where you specify
> that A = B op C, but without a prescribed ordering, could help there
> (like a Makefile, if you will). If you start with something like SSA,
> this could well help.
>
> The compiler, aided by the hardware, could then build up a
> dependency graph which would expose the inherent paralellism of
> the algorithm. Of course, building this graph could well be much
> more expensive than running that program serially. You could also
> do this starting with an SSA form for your whole program, of course...
>
> I read an article about this concept in Scientific American,
> oh, it must have been in the 1980s or possibly 1990s. The fact
> that we do not do this now obviosly means that this hasn't been
> a resounding success.
>
> In a way, we do this kind of thing already with OoO execution:
>
> add r1,r2,r3
> subi r4,r1,3
>
> could also be written, Makefile-style
>
> r1: r2, r3
> r1 = r2 + r3
>
> r4: r1
> r4 = r1 - r3
>
> to be executed at the hardware's discretion. Of course, we only
> have a very limited number of names available bcause of the limited
> number of registers that we usually have.
>

Thomas Koenig <tkoenig@netcologne.de> wrote:
> Ivan Godard <ivan@millcomputing.com> schrieb:
> > On 7/15/2021 8:28 AM, Thomas Koenig wrote:
>
> >> Superheaters do what the name says, they superheat steam.
> >> When steam leaves a boiler, is in equilibrium with the liqid it
> >> is in close contact with. A superheater is a heat exchanger which
> >> increases the temperature further. This is a pure gas-phase heat
> >> exchanger, with much lower heat transfer coefficients, but also
> >> with a much lower heat load, so this is not a big problem.
> >>
> >> So, you could in principle use a boiling liquid for cooling
> >> compouter chips if you can solve the mechanical and other assorted
> >> problems, but using a steam superheater would make little sense.
> >
> >
> > Not my understanding, nor Wikipedia's. The input to the superheater is
> > wet steam, with liquid droplets embedded in the gas phase carrier with
> > the temperature at the phase boundary for the pressure. A superheater
> > moves the whole thing into gas phase. The benefit is partly the
> > additional energy, but they were first introduced for a different
> > reason: the wet steam would condense in the power cylinders and valves,
> > leading to maintenance problems. https://en.wikipedia.org/wiki/Superheater
>
> "Wet steam" is just a nickname for saturated steam.
>
> What you write about maintenance being the reason for introduction
> is not what I read in the article, which only mentions maintenance
> in the context of maintenance on the superheater, maybe you have
> some other source or somebody changed this five minutes ago :-)
>
> The reason why a superheater increases efficiency is that steam
> gives off mechanical work during expansion, so it's basically
> pressure times volume difference (I will spare you the integrals).
> If part of the steam condenses, then there is less volume, therefore
> less mechanical work to do. Bringing the steam away from the
> saturation line means that it will be less or no condensation
> during expansion, leading to more work done and (on the whole)
> better efficiency.
>
> You can also do the calculation with an enthalpy-entropy diagram
> for water if you're really interested, but you may not be :-)

I think that your diagrams may be misleading. By Carnot argument
any reversible engine working between given two temperatures
will have the same efficiency. AFAICS condesation in final
stage is not a problem as long as it is resonably close to
reversible transition. OTOH condensation in the middle is a
problem: removing water in middle stage will effectively
change lower endpointy to higher temperature and cause lower
efficiency. Keeping water up to final stage theoretically
seem possible, as pressure decreases and with lower pressure
droplets will evaportate again. But keeping operating
point close to saturated steam looks tricky. I am not sure
if I would call this "instability of operating point" or
"maintenance problem". Whatever called, superheater solves
the problem... AFAICS even small amount of water in intermediate
stages would cause trouble, probably earlier than any
noticable efficiency loss due to lost heat, so
"maintenance problem" is probably as practicioners perceived
it.
--
Waldek Hebisch

Terje Mathisen <terje.mathisen@tmsw.no> wrote:
> Thomas Koenig wrote:
> > Marcus <m.delete@this.bitsnbites.eu> schrieb:
> >
> >> I remember the first time I wrote a 6502 assembler language loop on my
> >> C=64: The program changed the character value of the upper left
> >> character of the screen a few hundred times (probably 255), and at first
> >> I thought I had made an error because I only saw the final character,
> >> not the other hundreds of characters, until it dawned on me:
> >>
> >> "It's THAT fast!"
> >>
> >> I doubt that many programmers these days have these moments when they
> >> actually understand how fast a computer really is.
> >
> > I certainly had a moment when I understood how much faster computers
> > had become.
> >
> > It was a little problem to find four prices (i.e. decimal numbers
> > with a maximum of two digits after the decimal separator) a,b,c,d
> > so that a*b*c*d = a+b+c+d = 7.47 .
> >
> > On a C 64 using Basic, months to hours depending on the cleverness
> > of the algorithm.
> >
> > On a modern computer using a compiled language, too fast to notice
> > even when choosing a rather stupid algorithm.
> >
> Hmmm.
>
> None of them can be zero or negative, so by specifying that a,b,c,d is
> in increasing order, a can be in the range 0.01 to 7.47/4=1.86.
> b has a slightly larger possible range (0.01 to (7.47-a)/3), the same
> for c (0.01 to (7.47-a-b)/2), while d is always (7.47-a-b-c).
>
> (I would do this all in cents of course!)
>
> This should be ~200^3 so 8M iterations, doable in a small fraction of a
> second.
>
> Next insight is the fact that the cents values must be such that 6 of
> the 8 multiplication decimals end up as zero, i.e. the last digits of
> each price must have a lot of '0', '2' or '5', I suspect this reduces
> the search space by at least an order of magnitude?

There are 62 divisors of 747000000 smaller than 747. 39 of them is
less or equal to 186. So outer loop needs only look at 39 numbers,
inner at most at 61, which indeed gives more than order of magnitude
lower estimate. Another observation is that when you have two
numbers you know sum and product of the other two. So you can
find the other two solving quadratic equation. In other words,
instead of 3 loops you end up with 2. Solving quadratic is more
expensive than other calculation, but despite this should give
some saving. Using you later idea about large factor, one
can reduce outer loop to multiples of 83, that is to 7 values.
7*62 = 434 iterstion, so at this moment coding solution in
Commodre 64 Basic probably would give answer faster than further
improvements. OTOH I saw 7.11 problem solved "by hand", calculations
and reasoning fit in less then a printed page, so one or two more
improvements would probably eliminate need for computer...

--
Waldek Hebisch

antispam@math.uni.wroc.pl <antispam@math.uni.wroc.pl> schrieb:
> Thomas Koenig <tkoenig@netcologne.de> wrote:
>> Ivan Godard <ivan@millcomputing.com> schrieb:
>> > On 7/15/2021 8:28 AM, Thomas Koenig wrote:
>>
>> >> Superheaters do what the name says, they superheat steam.
>> >> When steam leaves a boiler, is in equilibrium with the liqid it
>> >> is in close contact with. A superheater is a heat exchanger which
>> >> increases the temperature further. This is a pure gas-phase heat
>> >> exchanger, with much lower heat transfer coefficients, but also
>> >> with a much lower heat load, so this is not a big problem.
>> >>
>> >> So, you could in principle use a boiling liquid for cooling
>> >> compouter chips if you can solve the mechanical and other assorted
>> >> problems, but using a steam superheater would make little sense.
>> >
>> >
>> > Not my understanding, nor Wikipedia's. The input to the superheater is
>> > wet steam, with liquid droplets embedded in the gas phase carrier with
>> > the temperature at the phase boundary for the pressure. A superheater
>> > moves the whole thing into gas phase. The benefit is partly the
>> > additional energy, but they were first introduced for a different
>> > reason: the wet steam would condense in the power cylinders and valves,
>> > leading to maintenance problems. https://en.wikipedia.org/wiki/Superheater
>>
>> "Wet steam" is just a nickname for saturated steam.
>>
>> What you write about maintenance being the reason for introduction
>> is not what I read in the article, which only mentions maintenance
>> in the context of maintenance on the superheater, maybe you have
>> some other source or somebody changed this five minutes ago :-)
>>
>> The reason why a superheater increases efficiency is that steam
>> gives off mechanical work during expansion, so it's basically
>> pressure times volume difference (I will spare you the integrals).
>> If part of the steam condenses, then there is less volume, therefore
>> less mechanical work to do. Bringing the steam away from the
>> saturation line means that it will be less or no condensation
>> during expansion, leading to more work done and (on the whole)
>> better efficiency.
>>
>> You can also do the calculation with an enthalpy-entropy diagram
>> for water if you're really interested, but you may not be :-)
>
> I think that your diagrams may be misleading. By Carnot argument
> any reversible engine working between given two temperatures
> will have the same efficiency.

That is plain wrong.

The Carnot efficiency is the _maximum_ that can be achieved
It is always possible to be less efficient than the optimum.

To take an extreme example: You can just have heat conduction
between two different temperature levels. No work generated,
the ratio of work generated by heat flux is zero, efficiency
is zero.

There is that pesky "greater or equal" sign in the Second Law
of Thermodynamics...

On Tuesday, July 27, 2021 at 11:27:11 AM UTC-5, Thomas Koenig wrote:
> anti...@math.uni.wroc.pl <anti...@math.uni.wroc.pl> schrieb:
> > Thomas Koenig <tko...@netcologne.de> wrote:
> >> Ivan Godard <iv...@millcomputing.com> schrieb:
> >> > On 7/15/2021 8:28 AM, Thomas Koenig wrote:
> >>
> >> >> Superheaters do what the name says, they superheat steam.
> >> >> When steam leaves a boiler, is in equilibrium with the liqid it
> >> >> is in close contact with. A superheater is a heat exchanger which
> >> >> increases the temperature further. This is a pure gas-phase heat
> >> >> exchanger, with much lower heat transfer coefficients, but also
> >> >> with a much lower heat load, so this is not a big problem.
> >> >>
> >> >> So, you could in principle use a boiling liquid for cooling
> >> >> compouter chips if you can solve the mechanical and other assorted
> >> >> problems, but using a steam superheater would make little sense.
> >> >
> >> >
> >> > Not my understanding, nor Wikipedia's. The input to the superheater is
> >> > wet steam, with liquid droplets embedded in the gas phase carrier with
> >> > the temperature at the phase boundary for the pressure. A superheater
> >> > moves the whole thing into gas phase. The benefit is partly the
> >> > additional energy, but they were first introduced for a different
> >> > reason: the wet steam would condense in the power cylinders and valves,
> >> > leading to maintenance problems. https://en.wikipedia.org/wiki/Superheater
> >>
> >> "Wet steam" is just a nickname for saturated steam.
> >>
> >> What you write about maintenance being the reason for introduction
> >> is not what I read in the article, which only mentions maintenance
> >> in the context of maintenance on the superheater, maybe you have
> >> some other source or somebody changed this five minutes ago :-)
> >>
> >> The reason why a superheater increases efficiency is that steam
> >> gives off mechanical work during expansion, so it's basically
> >> pressure times volume difference (I will spare you the integrals).
> >> If part of the steam condenses, then there is less volume, therefore
> >> less mechanical work to do. Bringing the steam away from the
> >> saturation line means that it will be less or no condensation
> >> during expansion, leading to more work done and (on the whole)
> >> better efficiency.
> >>
> >> You can also do the calculation with an enthalpy-entropy diagram
> >> for water if you're really interested, but you may not be :-)
> >
> > I think that your diagrams may be misleading. By Carnot argument
> > any reversible engine working between given two temperatures
> > will have the same efficiency.
> That is plain wrong.
>
> The Carnot efficiency is the _maximum_ that can be achieved
> It is always possible to be less efficient than the optimum.
>
> To take an extreme example: You can just have heat conduction
> between two different temperature levels. No work generated,
> the ratio of work generated by heat flux is zero, efficiency
> is zero.
>
> There is that pesky "greater or equal" sign in the Second Law
> of Thermodynamics...
<
Also note: It is the mass times velocity of the steam that decides
the maximum amount of power one an extract out of the steam.

MitchAlsup <MitchAlsup@aol.com> schrieb:
> On Tuesday, July 27, 2021 at 11:27:11 AM UTC-5, Thomas Koenig wrote:

>> There is that pesky "greater or equal" sign in the Second Law
>> of Thermodynamics...
><
> Also note: It is the mass times velocity of the steam that decides
> the maximum amount of power one an extract out of the steam.

That is impulse, but there are several points here.

Kinetic energy equal 1/2 * m * v^2 (m mass, v velocity), notice the
square on the velocity. This is the maximum energy that you can
extract from an amount of water in free jet in a water turbine.
If you divide by the density of the water, you get
1/2 * rho * v^2, a specific energy (or "dynamic pressure").

Note that this is the same dimeension as pressure, hence the name.

In such a turbine, the water is passed through a nozzle, which
decreases its static pressure while increasing its velocity.
In the absence of losses and under the assumption of plug flow,
you get p + 1/2 * rho * v^2 = constant, which is the widely-known
Bernoulli equation, or in other words: The sum of dynamic and
static pressure remains the same. (You can also reverse this
process by slowing down a water stream in a diffusor).

Water is almost incompressible (i.e. its volume depends only
little on the pressure), so this effect can often be neglected.

The exansion of steam or other gases is different. When a gas
(or steam) expands agaist a piston, its molecules (or atoms)
perform mechanical work against the piston, they become slower,
so the temperature of the gas decreases.

You can also have expansion of a gas for acceleration, this is
what happens in rocket exhausts (where you can even exceed the
speed of sound) or in a turbine. In both, the expansion of the
gas accelerates it. In a rocket engine, it is expelled at high
velocity and produces thrust. In a turbine, it is slowed down
against a turbine blade and also made to perform mechanical work,
which cools it.

If you make your pision or your turbine perfect, which you can't
do, and do not transfer heat, then the entropy of your gas will
remain constant.

If you just throttle an ideal gas, there is no mechanical work
performed, and it does not cool down, and its entropy increases.

I think this was enough basic thermodynamics for comp.arch :-)
It's a subject that even many chemical engineering students
are not particularly fond of.

Thomas Koenig <tkoenig@netcologne.de> wrote:
> antispam@math.uni.wroc.pl <antispam@math.uni.wroc.pl> schrieb:
> > Thomas Koenig <tkoenig@netcologne.de> wrote:
> >> Ivan Godard <ivan@millcomputing.com> schrieb:
> >> > On 7/15/2021 8:28 AM, Thomas Koenig wrote:
> >>
> >> >> Superheaters do what the name says, they superheat steam.
> >> >> When steam leaves a boiler, is in equilibrium with the liqid it
> >> >> is in close contact with. A superheater is a heat exchanger which
> >> >> increases the temperature further. This is a pure gas-phase heat
> >> >> exchanger, with much lower heat transfer coefficients, but also
> >> >> with a much lower heat load, so this is not a big problem.
> >> >>
> >> >> So, you could in principle use a boiling liquid for cooling
> >> >> compouter chips if you can solve the mechanical and other assorted
> >> >> problems, but using a steam superheater would make little sense.
> >> >
> >> >
> >> > Not my understanding, nor Wikipedia's. The input to the superheater is
> >> > wet steam, with liquid droplets embedded in the gas phase carrier with
> >> > the temperature at the phase boundary for the pressure. A superheater
> >> > moves the whole thing into gas phase. The benefit is partly the
> >> > additional energy, but they were first introduced for a different
> >> > reason: the wet steam would condense in the power cylinders and valves,
> >> > leading to maintenance problems. https://en.wikipedia.org/wiki/Superheater
> >>
> >> "Wet steam" is just a nickname for saturated steam.
> >>
> >> What you write about maintenance being the reason for introduction
> >> is not what I read in the article, which only mentions maintenance
> >> in the context of maintenance on the superheater, maybe you have
> >> some other source or somebody changed this five minutes ago :-)
> >>
> >> The reason why a superheater increases efficiency is that steam
> >> gives off mechanical work during expansion, so it's basically
> >> pressure times volume difference (I will spare you the integrals).
> >> If part of the steam condenses, then there is less volume, therefore
> >> less mechanical work to do. Bringing the steam away from the
> >> saturation line means that it will be less or no condensation
> >> during expansion, leading to more work done and (on the whole)
> >> better efficiency.
> >>
> >> You can also do the calculation with an enthalpy-entropy diagram
> >> for water if you're really interested, but you may not be :-)
> >
> > I think that your diagrams may be misleading. By Carnot argument
> > any reversible engine working between given two temperatures
> > will have the same efficiency.
>
> That is plain wrong.
>
> The Carnot efficiency is the _maximum_ that can be achieved
> It is always possible to be less efficient than the optimum.

Sure, any real engine is non-reversible. Non-reversiblilty
make practical realization possible but lowers efficiency.
> To take an extreme example: You can just have heat conduction
> between two different temperature levels. No work generated,
> the ratio of work generated by heat flux is zero, efficiency
> is zero.

This is as non-reversible as possible, not wonder that efficiency
is zero. However, condensation/evaportation is reversible,
so no trouble from that.

--
Waldek Hebisch

On Tuesday, July 27, 2021 at 1:46:58 PM UTC-5, Thomas Koenig wrote:
> MitchAlsup <Mitch...@aol.com> schrieb:
> > On Tuesday, July 27, 2021 at 11:27:11 AM UTC-5, Thomas Koenig wrote:
>
> >> There is that pesky "greater or equal" sign in the Second Law
> >> of Thermodynamics...
> ><
> > Also note: It is the mass times velocity of the steam that decides
> > the maximum amount of power one an extract out of the steam.
> That is impulse, but there are several points here.
>
> Kinetic energy equal 1/2 * m * v^2 (m mass, v velocity), notice the
> square on the velocity. This is the maximum energy that you can
> extract from an amount of water in free jet in a water turbine.
> If you divide by the density of the water, you get
> 1/2 * rho * v^2, a specific energy (or "dynamic pressure").
>
> Note that this is the same dimeension as pressure, hence the name.
>
> In such a turbine, the water is passed through a nozzle, which
> decreases its static pressure while increasing its velocity.
> In the absence of losses and under the assumption of plug flow,
> you get p + 1/2 * rho * v^2 = constant, which is the widely-known
> Bernoulli equation, or in other words: The sum of dynamic and
> static pressure remains the same. (You can also reverse this
> process by slowing down a water stream in a diffusor).
>
> Water is almost incompressible (i.e. its volume depends only
> little on the pressure), so this effect can often be neglected.
>
> The exansion of steam or other gases is different. When a gas
> (or steam) expands agaist a piston, its molecules (or atoms)
> perform mechanical work against the piston, they become slower,
> so the temperature of the gas decreases.
>
> You can also have expansion of a gas for acceleration, this is
> what happens in rocket exhausts (where you can even exceed the
> speed of sound) or in a turbine. In both, the expansion of the
> gas accelerates it. In a rocket engine, it is expelled at high
> velocity and produces thrust. In a turbine, it is slowed down
> against a turbine blade and also made to perform mechanical work,
> which cools it.
>
> If you make your pision or your turbine perfect, which you can't
> do, and do not transfer heat, then the entropy of your gas will
> remain constant.
>
> If you just throttle an ideal gas, there is no mechanical work
> performed, and it does not cool down, and its entropy increases.
>
> I think this was enough basic thermodynamics for comp.arch :-)
> It's a subject that even many chemical engineering students
> are not particularly fond of.
<
Yes, but
<
You have a pressure out of a boiler flowing x amount of mass per unit time
and this condensed back into a liquid at atmospheric pressure after flowing
through the turbine in the condenser.. So this mass-flow times the pressure
drop gives the maximum amount of power per unit time, and integration of
power is maximum energy. The efficiency of the turbine determines how
much of the boiler energy is turned into usable d(energy)/dt = power.

antispam@math.uni.wroc.pl <antispam@math.uni.wroc.pl> schrieb:
> Thomas Koenig <tkoenig@netcologne.de> wrote:

>> > I think that your diagrams may be misleading. By Carnot argument
>> > any reversible engine working between given two temperatures
>> > will have the same efficiency.
>>
>> That is plain wrong.
>>
>> The Carnot efficiency is the _maximum_ that can be achieved
>> It is always possible to be less efficient than the optimum.
>
> Sure, any real engine is non-reversible. Non-reversiblilty
> make practical realization possible but lowers efficiency.
>
>> To take an extreme example: You can just have heat conduction
>> between two different temperature levels. No work generated,
>> the ratio of work generated by heat flux is zero, efficiency
>> is zero.
>
> This is as non-reversible as possible, not wonder that efficiency
> is zero. However, condensation/evaportation is reversible,
> so no trouble from that.

It is reversible only when done at zero temperature difference,
actual heat exchangers need differences in temperature.

Howerver, the the Rankine process (the turbine) is less efficient
than the Carnot process.

The Carnot process is only a theoretical consideration, nobody has
has managed a technical realization of the part where you put in
heat at constant temperature and extract work at the same time.

The Rankine process starts by heating up liquid water. There, you
already have something non-reversible going on - the temperature
difference between your heating medium and the water. At least
the work you put in when increasing the pressure of the water
is relatively small.

Then, you boil the water to generate steam (again, with a
temperature difference).

Then next step is the turbines. Actual turbines have limited
efficiencies, an isentropic efficiency of around 80% is common.
(An ideal turbine without heat exchange would have the same
entropy of your working fluid on exit as on entry; actual
turbines increase the entropy due to losses).

Finally, you need a temperature difference to condense
your working fluid.

MitchAlsup <MitchAlsup@aol.com> schrieb:

> You have a pressure out of a boiler flowing x amount of mass per unit time
> and this condensed back into a liquid at atmospheric pressure after flowing
> through the turbine in the condenser..

Correct.

> So this mass-flow times the pressure
> drop gives the maximum amount of power per unit time,

It would be volumetric flow, but...

You can build a steam engine like that, and I think they did
so right at the beginning - just have the valves to the piston
open all the time in that half-cycle.

However, people soon found out that this was horribly inefficient,
because that blew out the steam to the atmosphere at almost full
boiler pressure.

People soon found out it was much better to fill up the piston for
a short period at the beginning, and then close the valve again
and let the steam expand to get out much more work.

> and integration of
> power is maximum energy. The efficiency of the turbine determines how
> much of the boiler energy is turned into usable d(energy)/dt = power.

It's a bit more complex than that. What you can get from a stream
in a turbine or poston under idealized conditions is an isentropic
adiabatic expansion. Now... what am I talking about?

Adiabatic means that there is no heat transfer. The Second
Law then tells you that entropy has to remain constant or
increase, so for idealized conditions, you assume it does
not change, which means isentropic.

The First Law then tells you that the enthalpy difference
in your steam is the mechanical work you can then get
out of the system.

Some numbers, assuming a non-optimum setup with a single turbine
without intermediate superheating 500°C steam at 100 bar
gives you an enthalpy of around 3375 kJ/kg (I'm using the data at
http://www.peacesoftware.de/einigewerte/calc_dampf.php7 right now).
Entropy is around 6.6 kJ/(kg*K). Expanding to the condensation line
gives you approximately 2775 kJ/kg, so you could get 500 kJ/kg of
work out of it. This is about 1/4 of what you need to evaporate
the water, not so good, your efficiency would be not far off 25%.

However, there is no reason to stop there, the water is still
~177°C hot and has 9.5 bar vapor pressure, so you heat it up
again to get some extra work out of it. You go to 500°C again,
enthalpy goes up to 3480 kJ/kg, so you need to add 705 kJ/kg of
heat. Entropy increases to 7.8 kJ/(kg*K). You exapand again and
get to around 250 mbar, on the dew line, 2420 kJ/kg enthalpy, so
you gain another 1010 kJ/kg enthalpy as work, _much_ better already,
at 65°C.

Obviously, this is _far_ from a good design - the end point is
not where condensation temperatures should usually be, at 45°C or
lower, you wouldn't expand the first turbine right to the two-phase
line, turbine inefficiencies are not taken into account, if you
need heat at a certain temperature range in a combined cycle,
you can take it off the turbines, etc. pp.

But maybe it gives an inkling of an idea of how this kind of
thing is designed :-)

anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:

> [...] Because we build maintainable software by
> splitting it into mostly-independent parts.

In English, the "-" between "mostly" and "independent" is unnecessary
and should be left out. The reason to use a "-" in such cases is to
change the parsing of the words; normally "adj1 adj2 noun" would be
parsed with the last two words grouped, "adj1 (adj2 noun)", and
putting in a "-" changes that: "adj1-adj2 noun" is parsed as if
parenthesized "(adj1 adj2) noun".

The difference here is that "mostly" is an adverb and thus cannot
modify the noun but only the following adjective. Thus "mostly
independent parts" can mean only "(mostly independent) parts", and
should be written without using any "-".

Tim Rentsch wrote:
> anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>
>> [...] Because we build maintainable software by
>> splitting it into mostly-independent parts.
>
> In English, the "-" between "mostly" and "independent" is unnecessary
> and should be left out. The reason to use a "-" in such cases is to
> change the parsing of the words; normally "adj1 adj2 noun" would be
> parsed with the last two words grouped, "adj1 (adj2 noun)", and
> putting in a "-" changes that: "adj1-adj2 noun" is parsed as if
> parenthesized "(adj1 adj2) noun".
>
> The difference here is that "mostly" is an adverb and thus cannot
> modify the noun but only the following adjective. Thus "mostly
> independent parts" can mean only "(mostly independent) parts", and
> should be written without using any "-".

You could have bin 1 containing integrated modules,
and bin 2 containing independent parts,
and bin 3 containing mostly independent-parts but also some modules.

On 8/2/2021 1:23 AM, Tim Rentsch wrote:
> anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>
>> [...] Because we build maintainable software by
>> splitting it into mostly-independent parts.
>
> In English, the "-" between "mostly" and "independent" is unnecessary
> and should be left out. The reason to use a "-" in such cases is to
> change the parsing of the words; normally "adj1 adj2 noun" would be
> parsed with the last two words grouped, "adj1 (adj2 noun)", and
> putting in a "-" changes that: "adj1-adj2 noun" is parsed as if
> parenthesized "(adj1 adj2) noun".
>
> The difference here is that "mostly" is an adverb and thus cannot
> modify the noun but only the following adjective. Thus "mostly
> independent parts" can mean only "(mostly independent) parts", and
> should be written without using any "-".
>

This may be dialect-dependent. As a native speaker of English, rural
Maine division, I often use "-" to indicate semantic binding rather than
adjectival modification. Thus "green door" means an object of door
category that happens to be green, whereas "green-door" means an object
of category green-doors. Thus in the original quote, the "-" to me shows
that the OP views "mostly-independent" as a distinctly recognizable
group. Children undergo a similar categorization as they go from "kitty"
to "stripe kitty" to "striped-kitty" to "skunk".

EricP <ThatWouldBeTelling@thevillage.com> writes:

> Tim Rentsch wrote:
>
>> anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>>
>>> [...] Because we build maintainable software by
>>> splitting it into mostly-independent parts. >
>>
>> In English, the "-" between "mostly" and "independent" is unnecessary
>> and should be left out. The reason to use a "-" in such cases is to
>> change the parsing of the words; normally "adj1 adj2 noun" would be
>> parsed with the last two words grouped, "adj1 (adj2 noun)", and
>> putting in a "-" changes that: "adj1-adj2 noun" is parsed as if
>> parenthesized "(adj1 adj2) noun".
>>
>> The difference here is that "mostly" is an adverb and thus cannot
>> modify the noun but only the following adjective. Thus "mostly
>> independent parts" can mean only "(mostly independent) parts", and
>> should be written without using any "-".
>
> You could have bin 1 containing integrated modules,
> and bin 2 containing independent parts,
> and bin 3 containing mostly independent-parts but also some modules.

Any decent copy editor would revise that to read bin 3
mostly containing independent parts but also some modules.

Ivan Godard <ivan@millcomputing.com> writes:

> On 8/2/2021 1:23 AM, Tim Rentsch wrote:
>
>> anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>>
>>> [...] Because we build maintainable software by
>>> splitting it into mostly-independent parts.
>>
>> In English, the "-" between "mostly" and "independent" is unnecessary
>> and should be left out. The reason to use a "-" in such cases is to
>> change the parsing of the words; normally "adj1 adj2 noun" would be
>> parsed with the last two words grouped, "adj1 (adj2 noun)", and
>> putting in a "-" changes that: "adj1-adj2 noun" is parsed as if
>> parenthesized "(adj1 adj2) noun".
>>
>> The difference here is that "mostly" is an adverb and thus cannot
>> modify the noun but only the following adjective. Thus "mostly
>> independent parts" can mean only "(mostly independent) parts", and
>> should be written without using any "-".
>
> This may be dialect-dependent. As a native speaker of English, rural
> Maine division, I often use "-" to indicate semantic binding rather
> than adjectival modification. Thus "green door" means an object of
> door category that happens to be green, whereas "green-door" means an
> object of category green-doors. Thus in the original quote, the "-" to
> me shows that the OP views "mostly-independent" as a distinctly
> recognizable group. Children undergo a similar categorization as they
> go from "kitty" to "stripe kitty" to "striped-kitty" to "skunk".

Like any natural language, English admits various idiosyncratic
usages, especially in informal writing. My comment was given
expecting people (especially people who are not native speakers
of English) would want to follow recognized and widely used
style guides, as for example the Chicago Manual of Style.

On Sunday, August 8, 2021 at 10:37:55 AM UTC-6, Tim Rentsch wrote:
> EricP <ThatWould...@thevillage.com> writes:

> > and bin 3 containing mostly independent-parts but also some modules.

> Any decent copy editor would revise that to read bin 3
> mostly containing independent parts but also some modules.

Or, depending on what was meant, bin 3 containing parts
which are mostly independent of each other, but also some modules.

John Savard

Quadibloc <jsavard@ecn.ab.ca> writes:

> On Sunday, August 8, 2021 at 10:37:55 AM UTC-6, Tim Rentsch wrote:
>
>> EricP <ThatWould...@thevillage.com> writes:
>>
>>> and bin 3 containing mostly independent-parts but also some modules.
>>
>> Any decent copy editor would revise that to read bin 3
>> mostly containing independent parts but also some modules.
>
> Or, depending on what was meant, bin 3 containing parts
> which are mostly independent of each other, but also some modules.

That is a different situation, but still a nicely describable one,
as for example bin 3 containing both modules and also other
mostly independent parts.

> That is a different situation, but still a nicely describable one,
> as for example bin 3 containing both modules and also other
> mostly independent parts.

I'm curious, tho: what kinds of modules where in those bins?

Stefan