On Wed, 30 Nov 2022 09:50:47 -0800 (PST), "pete...@gmail.com"
<petertrei@gmail.com> wrote:

>On Wednesday, November 30, 2022 at 11:51:59 AM UTC-5, Paul S Person wrote:
>> On Tue, 29 Nov 2022 18:04:44 GMT, sc...@slp53.sl.home (Scott Lurndal)
>> wrote:
>> >Paul S Person <pspe...@old.netcom.invalid> writes:
>> >>On Mon, 28 Nov 2022 20:20:19 -0800 (PST), "pete...@gmail.com"
>> >><pete...@gmail.com> wrote:
>> >>
>> >>>On Monday, November 28, 2022 at 8:22:43 PM UTC-5, Dorothy J Heydt wrote:
>> >>>> In article <3pjsnhpkh9nf24pio...@4ax.com>,
>> >>>> Paul S Person <pspe...@old.netcom.invalid> wrote:
>> >>>> >OTOH, I expect my bank statements to be accurate to the penny. No room
>> >>>> >for error, no excuses.
>> >>>> (Hal Heydt)
>> >>>> And much as both packed decimal and COBOL are maligned, the use
>> >>>> of packed decimal in COBOL makes doing just that very easy.
>> >>>>
>> >>>> Side note... COBOL has floating point variables, although they
>> >>>> are almost never used and very few COBOL programmers know they
>> >>>> exist. The format is COMP-2.
>> >>>
>> >>>When I was working at a major bank, our solution was to record dollar
>> >>>sums as the integer number of pennies.
>> >>
>> >>Which is what integer-based solutions basically are when the data has
>> >>a decimal point at a fixed position.
>> >
>> >I think most cases (particularly banks) will record in mills, rather
>> >than pennies to accommodate fractional cents.
>> >
>> >>
>> >>And they work very well for addition and subtraction.
>> >
>> >However, they're limited to the scope of the underlying integer
>> >unit (e.g. a 32-bit signed integer can't represent more than around
>> >two hundred million dollars if denominated in pennies, or
>> >twenty million dollars if denominated in mills). This does
>> >go up a bit with 64-bit integers (by a factor of four billion),
>> >allowing about 900 trillion mills.
>> IIRC, there have existed for some time libraries allowing integers of
>> any desired size to be manipulated. The only limit is available
>> memory. Which, given paging, may or may not be disk memory.
>>
>> Of course, this convenience is paid for in how long it takes to do the
>> computations.
>> >>Multiplication and division are where you start to have to keep track
>> >>of where the decimal point is. Also rounding. Doable, but it helps if
>> >>the programmer/coder/whatever the title is actually knows how its
>> >>done.
>> >
>> >Just do all calculation in mills and the decimal point is always
>> >fixed.
>> I don't think so.
>>
>> 5 mils x 3 mils == 15 mils
>>
>> but
>> .005 x .003 == .000015
>>
>> the decimal point /moves/ with multiplication and division.
>
>I think your misunderstand. He wants to use integers representing
>the number of mils. It just adds 1 digit of precision over using pennies.
>
>'5 mils x 3 mils == 15 mils' is nonsensical. It's like saying
>'5 dollars x 3 dollars == 15 dollars' Dollars don't multiply
>dollars.

The first is a property value expressed in mils.
The second is a property /tax/ rate expressed in mils.
Not nonsensical, just unclear.

Alternately,
5 mils x 3 mils == 15 square mils
which is as sensible, in terms of units, as saying
5 feet x 3 feet == 15 square feet
although I must admit that "square mils" seems like a term in search
of a concept.

>$0.005 can be represented as 0005 mils, and multiplying by
>3 gives you 0015, which is $0.015. The decimal place is, indeed, fixed.

Only because you are multiplying 0.005 by 3.000 -- that is, 5 mils by
3000 mils.

>If you actually want to multiply by 0.003, you are multiplying an integer
>by a real value, producing a real. That's a different problem.

No, you are using fixed point integers, and must keep track of the
decimal point on all multiplications/divisions.

You don't seem to understand this very well. That's OK; it's not as
simple as it seems.

>Bonus question: There's one place most Americans see mils used on
>a daily basis. Where is it?

I don't drive a car, so I don't see it or pay any attention to it.

And my Grandfather would just round to the next cent/dime/dollar and
take that to be the cost. He had a great deal of contempt for prices
ending in "9".
--
"In this connexion, unquestionably the most significant
development was the disintegration, under Christian
influence, of classical conceptions of the family and
of family right."

On Wed, 30 Nov 2022 18:07:00 GMT, scott@slp53.sl.home (Scott Lurndal)
wrote:

>"pete...@gmail.com" <petertrei@gmail.com> writes:
>>On Wednesday, November 30, 2022 at 11:51:59 AM UTC-5, Paul S Person wrote:
>>> On Tue, 29 Nov 2022 18:04:44 GMT, sc...@slp53.sl.home (Scott Lurndal)
>>> wrote:
>>> >Paul S Person <pspe...@old.netcom.invalid> writes:
>>> >>On Mon, 28 Nov 2022 20:20:19 -0800 (PST), "pete...@gmail.com"
>>> >><pete...@gmail.com> wrote:
>>> >>
>>> >>>On Monday, November 28, 2022 at 8:22:43 PM UTC-5, Dorothy J Heydt wrote:
>>> >>>> In article <3pjsnhpkh9nf24pio...@4ax.com>,
>>> >>>> Paul S Person <pspe...@old.netcom.invalid> wrote:
>>> >>>> >OTOH, I expect my bank statements to be accurate to the penny. No room
>>> >>>> >for error, no excuses.
>>> >>>> (Hal Heydt)
>>> >>>> And much as both packed decimal and COBOL are maligned, the use
>>> >>>> of packed decimal in COBOL makes doing just that very easy.
>>> >>>>
>>> >>>> Side note... COBOL has floating point variables, although they
>>> >>>> are almost never used and very few COBOL programmers know they
>>> >>>> exist. The format is COMP-2.
>>> >>>
>>> >>>When I was working at a major bank, our solution was to record dollar
>>> >>>sums as the integer number of pennies.
>>> >>
>>> >>Which is what integer-based solutions basically are when the data has
>>> >>a decimal point at a fixed position.
>>> >
>>> >I think most cases (particularly banks) will record in mills, rather
>>> >than pennies to accommodate fractional cents.
>>> >
>>> >>
>>> >>And they work very well for addition and subtraction.
>>> >
>>> >However, they're limited to the scope of the underlying integer
>>> >unit (e.g. a 32-bit signed integer can't represent more than around
>>> >two hundred million dollars if denominated in pennies, or
>>> >twenty million dollars if denominated in mills). This does
>>> >go up a bit with 64-bit integers (by a factor of four billion),
>>> >allowing about 900 trillion mills.
>>> IIRC, there have existed for some time libraries allowing integers of
>>> any desired size to be manipulated. The only limit is available
>>> memory. Which, given paging, may or may not be disk memory.
>>>
>>> Of course, this convenience is paid for in how long it takes to do the
>>> computations.
>>> >>Multiplication and division are where you start to have to keep track
>>> >>of where the decimal point is. Also rounding. Doable, but it helps if
>>> >>the programmer/coder/whatever the title is actually knows how its
>>> >>done.
>>> >
>>> >Just do all calculation in mills and the decimal point is always
>>> >fixed.
>>> I don't think so.
>>>
>>> 5 mils x 3 mils == 15 mils
>>>
>>> but
>>> .005 x .003 == .000015
>>>
>>> the decimal point /moves/ with multiplication and division.
>>
>>I think your misunderstand. He wants to use integers representing
>>the number of mils. It just adds 1 digit of precision over using pennies.
>>
>>'5 mils x 3 mils == 15 mils' is nonsensical. It's like saying
>>'5 dollars x 3 dollars == 15 dollars' Dollars don't multiply
>>dollars.
>>
>>$0.005 can be represented as 0005 mils, and multiplying by
>>3 gives you 0015, which is $0.015. The decimal place is, indeed, fixed.
>>
>>If you actually want to multiply by 0.003, you are multiplying an integer
>>by a real value, producing a real. That's a different problem.
>>
>>Bonus question: There's one place most Americans see mils used on
>>a daily basis. Where is it?
>
>Every gasoline station.
>
>As I understand it, the term is 'mills' for monetary, and 'mil'
>as a measurment.

Sadly, consulting Bing suggests ... great confusion.

This, one site apparently proclaims that a "mill" is a "milliradian".
But another appears to equate it to a "millimeter".

OTOH, using "mills vs mils" as a search term (no quotes in the actual
search box) produces a surprising amount of bafflement, not the least
of which is the use of MILS as something mils can be converted to.
--
"In this connexion, unquestionably the most significant
development was the disintegration, under Christian
influence, of classical conceptions of the family and
of family right."

On Wed, 30 Nov 2022 09:56:20 -0800, Robert Woodward
<robertaw@drizzle.com> wrote:

>In article <k62fohpr383vp3o1smkqie8e7b9l79abdg@4ax.com>,
> Paul S Person <psperson@old.netcom.invalid> wrote:
>
>> On Tue, 29 Nov 2022 18:04:44 GMT, scott@slp53.sl.home (Scott Lurndal)
>> wrote:
>>
>
><Snip>
>> >>And they work very well for addition and subtraction.
>> >
>> >However, they're limited to the scope of the underlying integer
>> >unit (e.g. a 32-bit signed integer can't represent more than around
>> >two hundred million dollars if denominated in pennies, or
>> >twenty million dollars if denominated in mills). This does
>> >go up a bit with 64-bit integers (by a factor of four billion),
>> >allowing about 900 trillion mills.
>>
><Snip>
>> >
>> >Just do all calculation in mills and the decimal point is always
>> >fixed.
>>
>> I don't think so.
>>
>> 5 mils x 3 mils == 15 mils
>>
>
>Ahem, your result is mils squared (does that makes any sense?)

I have no idea.

Then again, if I express my property's value in mils and the property
tax rate in mils and multiply them, would not not make the property
tax paid mils squared?

>> but
>> .005 x .003 == .000015
>>
>
>And this result is presumably dollars squared.

In both cases, the first could be monetary value and the second a tax
rate. Or an interest rate.

But I agree I was not as clear as I might have been.

At least I remembered to point out that this only affected
multiplication and division.

>> the decimal point /moves/ with multiplication and division.
--
"In this connexion, unquestionably the most significant
development was the disintegration, under Christian
influence, of classical conceptions of the family and
of family right."

Paul S Person <psperson@old.netcom.invalid> writes:
>On Wed, 30 Nov 2022 09:50:47 -0800 (PST), "pete...@gmail.com"
><petertrei@gmail.com> wrote:
>
<snip>
>>> >>>> And much as both packed decimal and COBOL are maligned, the use
>>> >>>> of packed decimal in COBOL makes doing just that very easy.
>>> >>>>
<snip>
>>> >>>
>>> >>>When I was working at a major bank, our solution was to record dollar
>>> >>>sums as the integer number of pennies.
>>> >>
>>> >>Which is what integer-based solutions basically are when the data has
>>> >>a decimal point at a fixed position.
>>> >
>>> >I think most cases (particularly banks) will record in mills, rather
>>> >than pennies to accommodate fractional cents.
<snip>
>>> >However, they're limited to the scope of the underlying integer
>>> >unit (e.g. a 32-bit signed integer can't represent more than around
>>> >two hundred million dollars if denominated in pennies, or
>>> >twenty million dollars if denominated in mills). This does
>>> >go up a bit with 64-bit integers (by a factor of four billion),
>>> >allowing about 900 trillion mills.
<snip>
>>> >Just do all calculation in mills and the decimal point is always
>>> >fixed.
>>> I don't think so.
>>>
<snip>

>>I think your misunderstand. He wants to use integers representing
>>the number of mils. It just adds 1 digit of precision over using pennies.
>>
>>'5 mils x 3 mils == 15 mils' is nonsensical. It's like saying
>>'5 dollars x 3 dollars == 15 dollars' Dollars don't multiply
>>dollars.
>
>The first is a property value expressed in mils.
>The second is a property /tax/ rate expressed in mils.
>Not nonsensical, just unclear.
>
>Alternately,
>5 mils x 3 mils == 15 square mils
>which is as sensible, in terms of units, as saying
>5 feet x 3 feet == 15 square feet
>although I must admit that "square mils" seems like a term in search
>of a concept.
>
>>$0.005 can be represented as 0005 mils, and multiplying by
>>3 gives you 0015, which is $0.015. The decimal place is, indeed, fixed.
>
>Only because you are multiplying 0.005 by 3.000 -- that is, 5 mils by
>3000 mils.
>
>>If you actually want to multiply by 0.003, you are multiplying an integer
>>by a real value, producing a real. That's a different problem.
>
>No, you are using fixed point integers, and must keep track of the
>decimal point on all multiplications/divisions.

That was not my suggestion. I suggest using a single integer,
denominated in mills, upon which all calculations are
made. Divide the integer by 1000 to get the dollars,
and take the integer modulo 1000 and divide by 10 to get
cents. In other words, the decimal point is "implied".

>
>You don't seem to understand this very well. That's OK; it's not as
>simple as it seems.

I think you should reread the entire post before accusing
Peter of not understanding what I suggested. He was spot-on,
you're off in the floating point weeds.

On Thursday, December 1, 2022 at 12:31:04 PM UTC-5, Scott Lurndal wrote:
> Paul S Person <pspe...@old.netcom.invalid> writes:
> >On Wed, 30 Nov 2022 09:50:47 -0800 (PST), "pete...@gmail.com"
> ><pete...@gmail.com> wrote:
> >
> <snip>
> >>> >>>> And much as both packed decimal and COBOL are maligned, the use
> >>> >>>> of packed decimal in COBOL makes doing just that very easy.
> >>> >>>>
> <snip>
> >>> >>>
> >>> >>>When I was working at a major bank, our solution was to record dollar
> >>> >>>sums as the integer number of pennies.
> >>> >>
> >>> >>Which is what integer-based solutions basically are when the data has
> >>> >>a decimal point at a fixed position.
> >>> >
> >>> >I think most cases (particularly banks) will record in mills, rather
> >>> >than pennies to accommodate fractional cents.
> <snip>
> >>> >However, they're limited to the scope of the underlying integer
> >>> >unit (e.g. a 32-bit signed integer can't represent more than around
> >>> >two hundred million dollars if denominated in pennies, or
> >>> >twenty million dollars if denominated in mills). This does
> >>> >go up a bit with 64-bit integers (by a factor of four billion),
> >>> >allowing about 900 trillion mills.
> <snip>
> >>> >Just do all calculation in mills and the decimal point is always
> >>> >fixed.
> >>> I don't think so.
> >>>
> <snip>
> >>I think your misunderstand. He wants to use integers representing
> >>the number of mils. It just adds 1 digit of precision over using pennies.
> >>
> >>'5 mils x 3 mils == 15 mils' is nonsensical. It's like saying
> >>'5 dollars x 3 dollars == 15 dollars' Dollars don't multiply
> >>dollars.
> >
> >The first is a property value expressed in mils.
> >The second is a property /tax/ rate expressed in mils.
> >Not nonsensical, just unclear.
> >
> >Alternately,
> >5 mils x 3 mils == 15 square mils
> >which is as sensible, in terms of units, as saying
> >5 feet x 3 feet == 15 square feet
> >although I must admit that "square mils" seems like a term in search
> >of a concept.
> >
> >>$0.005 can be represented as 0005 mils, and multiplying by
> >>3 gives you 0015, which is $0.015. The decimal place is, indeed, fixed.
> >
> >Only because you are multiplying 0.005 by 3.000 -- that is, 5 mils by
> >3000 mils.
> >
> >>If you actually want to multiply by 0.003, you are multiplying an integer
> >>by a real value, producing a real. That's a different problem.
> >
> >No, you are using fixed point integers, and must keep track of the
> >decimal point on all multiplications/divisions.
> That was not my suggestion. I suggest using a single integer,
> denominated in mills, upon which all calculations are
> made. Divide the integer by 1000 to get the dollars,
> and take the integer modulo 1000 and divide by 10 to get
> cents. In other words, the decimal point is "implied".
> >
> >You don't seem to understand this very well. That's OK; it's not as
> >simple as it seems.
> I think you should reread the entire post before accusing
> Peter of not understanding what I suggested. He was spot-on,
> you're off in the floating point weeds.

I spent 5 years of my software engineering career
writing banking software at a major money center bank. I have
some experience with this.

pt

"pete...@gmail.com" <petertrei@gmail.com> writes:
>On Thursday, December 1, 2022 at 12:31:04 PM UTC-5, Scott Lurndal wrote:
>> Paul S Person <pspe...@old.netcom.invalid> writes:
>> >On Wed, 30 Nov 2022 09:50:47 -0800 (PST), "pete...@gmail.com"
>> ><pete...@gmail.com> wrote:
>> >
>> <snip>
>> >>> >>>> And much as both packed decimal and COBOL are maligned, the use
>> >>> >>>> of packed decimal in COBOL makes doing just that very easy.
>> >>> >>>>
>> <snip>
>> >>> >>>
>> >>> >>>When I was working at a major bank, our solution was to record dollar
>> >>> >>>sums as the integer number of pennies.
>> >>> >>
>> >>> >>Which is what integer-based solutions basically are when the data has
>> >>> >>a decimal point at a fixed position.
>> >>> >
>> >>> >I think most cases (particularly banks) will record in mills, rather
>> >>> >than pennies to accommodate fractional cents.
>> <snip>
>> >>> >However, they're limited to the scope of the underlying integer
>> >>> >unit (e.g. a 32-bit signed integer can't represent more than around
>> >>> >two hundred million dollars if denominated in pennies, or
>> >>> >twenty million dollars if denominated in mills). This does
>> >>> >go up a bit with 64-bit integers (by a factor of four billion),
>> >>> >allowing about 900 trillion mills.
>> <snip>
>> >>> >Just do all calculation in mills and the decimal point is always
>> >>> >fixed.
>> >>> I don't think so.
>> >>>
>> <snip>
>> >>I think your misunderstand. He wants to use integers representing
>> >>the number of mils. It just adds 1 digit of precision over using pennies.
>> >>
>> >>'5 mils x 3 mils == 15 mils' is nonsensical. It's like saying
>> >>'5 dollars x 3 dollars == 15 dollars' Dollars don't multiply
>> >>dollars.
>> >
>> >The first is a property value expressed in mils.
>> >The second is a property /tax/ rate expressed in mils.
>> >Not nonsensical, just unclear.
>> >
>> >Alternately,
>> >5 mils x 3 mils == 15 square mils
>> >which is as sensible, in terms of units, as saying
>> >5 feet x 3 feet == 15 square feet
>> >although I must admit that "square mils" seems like a term in search
>> >of a concept.
>> >
>> >>$0.005 can be represented as 0005 mils, and multiplying by
>> >>3 gives you 0015, which is $0.015. The decimal place is, indeed, fixed.
>> >
>> >Only because you are multiplying 0.005 by 3.000 -- that is, 5 mils by
>> >3000 mils.
>> >
>> >>If you actually want to multiply by 0.003, you are multiplying an integer
>> >>by a real value, producing a real. That's a different problem.
>> >
>> >No, you are using fixed point integers, and must keep track of the
>> >decimal point on all multiplications/divisions.
>> That was not my suggestion. I suggest using a single integer,
>> denominated in mills, upon which all calculations are
>> made. Divide the integer by 1000 to get the dollars,
>> and take the integer modulo 1000 and divide by 10 to get
>> cents. In other words, the decimal point is "implied".
>> >
>> >You don't seem to understand this very well. That's OK; it's not as
>> >simple as it seems.
>> I think you should reread the entire post before accusing
>> Peter of not understanding what I suggested. He was spot-on,
>> you're off in the floating point weeds.
>
>I spent 5 years of my software engineering career
>writing banking software at a major money center bank. I have
>some experience with this.

And my first years were spend writing operating systems
for a BCD mainframe that supported bank, insurance company,
city, county and state finance operations (COBOL). (They were also
used by the Navy stockpoints inventory operations).

100 digit/nibble (101 if signed) integer
arithmetic supported directly by the hardware with
an implied decimal point at whatever precision required
by the problem being solved.

In article <sgdhL.38886$JjSc.24316@fx46.iad>,
Scott Lurndal <slp53@pacbell.net> wrote:
>djheydt@kithrup.com (Dorothy J Heydt) writes:
>>In article <3pjsnhpkh9nf24pio2g2vq9m0u9em89sqe@4ax.com>,
>>Paul S Person <psperson@old.netcom.invalid> wrote:
>>>OTOH, I expect my bank statements to be accurate to the penny. No room
>>>for error, no excuses.
>>
>>(Hal Heydt)
>>And much as both packed decimal and COBOL are maligned, the use
>>of packed decimal in COBOL makes doing just that very easy.
>>
>>Side note... COBOL has floating point variables, although they
>>are almost never used and very few COBOL programmers know they
>>exist. The format is COMP-2.
>
>COMP-2 is specific to IBM COBOL IIRC. Burroughs (medium systems)
>COBOL ignore COMP anyway, since all the hardware supported was
>BCD (4-bit digits, up to PIC 9(100)).

(Hal Heydt)
Microfocus COBOL running on HP/UX had COMP-2 as well, IIRC.

In article <37c88477-f6aa-4768-bca9-8f9715652c98n@googlegroups.com>,
pete...@gmail.com <petertrei@gmail.com> wrote:
>On Monday, November 28, 2022 at 8:22:43 PM UTC-5, Dorothy J Heydt wrote:
>> In article <3pjsnhpkh9nf24pio...@4ax.com>,
>> Paul S Person <pspe...@old.netcom.invalid> wrote:
>> >OTOH, I expect my bank statements to be accurate to the penny. No room
>> >for error, no excuses.
>> (Hal Heydt)
>> And much as both packed decimal and COBOL are maligned, the use
>> of packed decimal in COBOL makes doing just that very easy.
>>
>> Side note... COBOL has floating point variables, although they
>> are almost never used and very few COBOL programmers know they
>> exist. The format is COMP-2.
>
>When I was working at a major bank, our solution was to record dollar
>sums as the integer number of pennies.

(Hal Heydt)
That's what I do in C for the DunDraCon reg system. In COBOL,
one can use a virtual decimal point to achieve the same end and
the compiler will do the work for you. And you can do it in any
fixed point computational version you like. PIC S9(7)V99 COMP-3
would be a packed decimal version, but it could COMP or DISPLAY
just as easily.

djheydt@kithrup.com (Dorothy J Heydt) writes:
>In article <sgdhL.38886$JjSc.24316@fx46.iad>,
>Scott Lurndal <slp53@pacbell.net> wrote:
>>djheydt@kithrup.com (Dorothy J Heydt) writes:
>>>In article <3pjsnhpkh9nf24pio2g2vq9m0u9em89sqe@4ax.com>,
>>>Paul S Person <psperson@old.netcom.invalid> wrote:
>>>>OTOH, I expect my bank statements to be accurate to the penny. No room
>>>>for error, no excuses.
>>>
>>>(Hal Heydt)
>>>And much as both packed decimal and COBOL are maligned, the use
>>>of packed decimal in COBOL makes doing just that very easy.
>>>
>>>Side note... COBOL has floating point variables, although they
>>>are almost never used and very few COBOL programmers know they
>>>exist. The format is COMP-2.
>>
>>COMP-2 is specific to IBM COBOL IIRC. Burroughs (medium systems)
>>COBOL ignore COMP anyway, since all the hardware supported was
>>BCD (4-bit digits, up to PIC 9(100)).
>
>(Hal Heydt)
>Microfocus COBOL running on HP/UX had COMP-2 as well, IIRC.
>

Given the amount of IBM code that was being ported using
Microfocus, that's not surprising.

In article <0RrhL.8$Use.3@fx15.iad>, Scott Lurndal <slp53@pacbell.net> wrote:
>Paul S Person <psperson@old.netcom.invalid> writes:
>>On Mon, 28 Nov 2022 20:20:19 -0800 (PST), "pete...@gmail.com"
>><petertrei@gmail.com> wrote:
>>
>>>On Monday, November 28, 2022 at 8:22:43 PM UTC-5, Dorothy J Heydt wrote:
>>>> In article <3pjsnhpkh9nf24pio...@4ax.com>,
>>>> Paul S Person <pspe...@old.netcom.invalid> wrote:
>>>> >OTOH, I expect my bank statements to be accurate to the penny. No room
>>>> >for error, no excuses.
>>>> (Hal Heydt)
>>>> And much as both packed decimal and COBOL are maligned, the use
>>>> of packed decimal in COBOL makes doing just that very easy.
>>>>
>>>> Side note... COBOL has floating point variables, although they
>>>> are almost never used and very few COBOL programmers know they
>>>> exist. The format is COMP-2.
>>>
>>>When I was working at a major bank, our solution was to record dollar
>>>sums as the integer number of pennies.
>>
>>Which is what integer-based solutions basically are when the data has
>>a decimal point at a fixed position.
>
>I think most cases (particularly banks) will record in mills, rather
>than pennies to accommodate fractional cents.

(Hal Heydt)
I spent some time (quite a while ago, I'll grant) working for a
bank service bureau (back when only large banks had their own
computers). It was done in cents. I seriously doubt that has
changed since then.

In article <0cdebc5d-398d-49e8-9569-b31d7378f7ean@googlegroups.com>,
pete...@gmail.com <petertrei@gmail.com> wrote:
>On Wednesday, November 30, 2022 at 11:51:59 AM UTC-5, Paul S Person wrote:
>> On Tue, 29 Nov 2022 18:04:44 GMT, sc...@slp53.sl.home (Scott Lurndal)
>> wrote:
>> >Paul S Person <pspe...@old.netcom.invalid> writes:
>> >>On Mon, 28 Nov 2022 20:20:19 -0800 (PST), "pete...@gmail.com"
>> >><pete...@gmail.com> wrote:
>> >>
>> >>>On Monday, November 28, 2022 at 8:22:43 PM UTC-5, Dorothy J Heydt wrote:
>> >>>> In article <3pjsnhpkh9nf24pio...@4ax.com>,
>> >>>> Paul S Person <pspe...@old.netcom.invalid> wrote:
>> >>>> >OTOH, I expect my bank statements to be accurate to the penny. No room
>> >>>> >for error, no excuses.
>> >>>> (Hal Heydt)
>> >>>> And much as both packed decimal and COBOL are maligned, the use
>> >>>> of packed decimal in COBOL makes doing just that very easy.
>> >>>>
>> >>>> Side note... COBOL has floating point variables, although they
>> >>>> are almost never used and very few COBOL programmers know they
>> >>>> exist. The format is COMP-2.
>> >>>
>> >>>When I was working at a major bank, our solution was to record dollar
>> >>>sums as the integer number of pennies.
>> >>
>> >>Which is what integer-based solutions basically are when the data has
>> >>a decimal point at a fixed position.
>> >
>> >I think most cases (particularly banks) will record in mills, rather
>> >than pennies to accommodate fractional cents.
>> >
>> >>
>> >>And they work very well for addition and subtraction.
>> >
>> >However, they're limited to the scope of the underlying integer
>> >unit (e.g. a 32-bit signed integer can't represent more than around
>> >two hundred million dollars if denominated in pennies, or
>> >twenty million dollars if denominated in mills). This does
>> >go up a bit with 64-bit integers (by a factor of four billion),
>> >allowing about 900 trillion mills.
>> IIRC, there have existed for some time libraries allowing integers of
>> any desired size to be manipulated. The only limit is available
>> memory. Which, given paging, may or may not be disk memory.
>>
>> Of course, this convenience is paid for in how long it takes to do the
>> computations.
>> >>Multiplication and division are where you start to have to keep track
>> >>of where the decimal point is. Also rounding. Doable, but it helps if
>> >>the programmer/coder/whatever the title is actually knows how its
>> >>done.
>> >
>> >Just do all calculation in mills and the decimal point is always
>> >fixed.
>> I don't think so.
>>
>> 5 mils x 3 mils == 15 mils
>>
>> but
>> .005 x .003 == .000015
>>
>> the decimal point /moves/ with multiplication and division.
>
>I think your misunderstand. He wants to use integers representing
>the number of mils. It just adds 1 digit of precision over using pennies.
>
>'5 mils x 3 mils == 15 mils' is nonsensical. It's like saying
>'5 dollars x 3 dollars == 15 dollars' Dollars don't multiply
>dollars.
>
>$0.005 can be represented as 0005 mils, and multiplying by
>3 gives you 0015, which is $0.015. The decimal place is, indeed, fixed.
>
>If you actually want to multiply by 0.003, you are multiplying an integer
>by a real value, producing a real. That's a different problem.

(Hal Heydt)
And...once again...COBOL was designed to hand that sort of
problem without the approximations implied by floating point
variables.

>Bonus question: There's one place most Americans see mils used on
>a daily basis. Where is it?

Any gas station.

On Mon, 5 Dec 2022 17:00:58 GMT, djheydt@kithrup.com (Dorothy J Heydt)
wrote:

>In article <0cdebc5d-398d-49e8-9569-b31d7378f7ean@googlegroups.com>,
>pete...@gmail.com <petertrei@gmail.com> wrote:
>>On Wednesday, November 30, 2022 at 11:51:59 AM UTC-5, Paul S Person wrote:
>>> On Tue, 29 Nov 2022 18:04:44 GMT, sc...@slp53.sl.home (Scott Lurndal)
>>> wrote:
>>> >Paul S Person <pspe...@old.netcom.invalid> writes:
>>> >>On Mon, 28 Nov 2022 20:20:19 -0800 (PST), "pete...@gmail.com"
>>> >><pete...@gmail.com> wrote:
>>> >>
>>> >>>On Monday, November 28, 2022 at 8:22:43 PM UTC-5, Dorothy J Heydt wrote:
>>> >>>> In article <3pjsnhpkh9nf24pio...@4ax.com>,
>>> >>>> Paul S Person <pspe...@old.netcom.invalid> wrote:
>>> >>>> >OTOH, I expect my bank statements to be accurate to the penny. No room
>>> >>>> >for error, no excuses.
>>> >>>> (Hal Heydt)
>>> >>>> And much as both packed decimal and COBOL are maligned, the use
>>> >>>> of packed decimal in COBOL makes doing just that very easy.
>>> >>>>
>>> >>>> Side note... COBOL has floating point variables, although they
>>> >>>> are almost never used and very few COBOL programmers know they
>>> >>>> exist. The format is COMP-2.
>>> >>>
>>> >>>When I was working at a major bank, our solution was to record dollar
>>> >>>sums as the integer number of pennies.
>>> >>
>>> >>Which is what integer-based solutions basically are when the data has
>>> >>a decimal point at a fixed position.
>>> >
>>> >I think most cases (particularly banks) will record in mills, rather
>>> >than pennies to accommodate fractional cents.
>>> >
>>> >>
>>> >>And they work very well for addition and subtraction.
>>> >
>>> >However, they're limited to the scope of the underlying integer
>>> >unit (e.g. a 32-bit signed integer can't represent more than around
>>> >two hundred million dollars if denominated in pennies, or
>>> >twenty million dollars if denominated in mills). This does
>>> >go up a bit with 64-bit integers (by a factor of four billion),
>>> >allowing about 900 trillion mills.
>>> IIRC, there have existed for some time libraries allowing integers of
>>> any desired size to be manipulated. The only limit is available
>>> memory. Which, given paging, may or may not be disk memory.
>>>
>>> Of course, this convenience is paid for in how long it takes to do the
>>> computations.
>>> >>Multiplication and division are where you start to have to keep track
>>> >>of where the decimal point is. Also rounding. Doable, but it helps if
>>> >>the programmer/coder/whatever the title is actually knows how its
>>> >>done.
>>> >
>>> >Just do all calculation in mills and the decimal point is always
>>> >fixed.
>>> I don't think so.
>>>
>>> 5 mils x 3 mils == 15 mils
>>>
>>> but
>>> .005 x .003 == .000015
>>>
>>> the decimal point /moves/ with multiplication and division.
>>
>>I think your misunderstand. He wants to use integers representing
>>the number of mils. It just adds 1 digit of precision over using pennies.
>>
>>'5 mils x 3 mils == 15 mils' is nonsensical. It's like saying
>>'5 dollars x 3 dollars == 15 dollars' Dollars don't multiply
>>dollars.
>>
>>$0.005 can be represented as 0005 mils, and multiplying by
>>3 gives you 0015, which is $0.015. The decimal place is, indeed, fixed.
>>
>>If you actually want to multiply by 0.003, you are multiplying an integer
>>by a real value, producing a real. That's a different problem.
>>
>(Hal Heydt)
>And...once again...COBOL was designed to hand that sort of
>problem without the approximations implied by floating point
>variables.

Not to mention that "multiplying by 0.003" can be done by "multiplying
using integers by 3/1000". You don't need COBOL to use integers,
although it helps.

Of course, if N is what you want to multiply, then (N*3)/1000 is
well-advised.

And, yes, modulus can be used to find the leftovers. Or decide whether
or not to round the result.

>>Bonus question: There's one place most Americans see mils used on
>>a daily basis. Where is it?
>
>Any gas station.

Or fuel oil delivery receipt.
--
"In this connexion, unquestionably the most significant
development was the disintegration, under Christian
influence, of classical conceptions of the family and
of family right."

On 06/12/2022 10.40, Paul S Person wrote:
> On Mon, 5 Dec 2022 17:00:58 GMT, djheydt@kithrup.com (Dorothy J Heydt)
> wrote:
>
>> In article <0cdebc5d-398d-49e8-9569-b31d7378f7ean@googlegroups.com>,
>> pete...@gmail.com <petertrei@gmail.com> wrote:

>>> Bonus question: There's one place most Americans see mils used on
>>> a daily basis. Where is it?
>>
>> Any gas station.
>
> Or fuel oil delivery receipt.

Most Americans? I strongly doubt that.

I've certainly never had fuel oil delivered to my house, and I don't
think that I'm at all unusual in that way. My parents' house had oil
heat, but I've never known anyone after them who had it.

--
Michael F. Stemper
If it isn't running programs and it isn't fusing atoms, it's just bending space.

"Michael F. Stemper" <michael.stemper@gmail.com> writes:
>On 06/12/2022 10.40, Paul S Person wrote:
>> On Mon, 5 Dec 2022 17:00:58 GMT, djheydt@kithrup.com (Dorothy J Heydt)
>> wrote:
>>
>>> In article <0cdebc5d-398d-49e8-9569-b31d7378f7ean@googlegroups.com>,
>>> pete...@gmail.com <petertrei@gmail.com> wrote:
>
>>>> Bonus question: There's one place most Americans see mils used on
>>>> a daily basis. Where is it?
>>>
>>> Any gas station.
>>
>> Or fuel oil delivery receipt.
>
>Most Americans? I strongly doubt that.
>
>I've certainly never had fuel oil delivered to my house, and I don't
>think that I'm at all unusual in that way. My parents' house had oil
>heat, but I've never known anyone after them who had it.

My last home delivery propane bill lists the price in 1000s of mills:

$4.128000 per gallon (corrected to 60F).

On Tuesday, December 6, 2022 at 1:28:31 PM UTC-5, Michael F. Stemper wrote:
> On 06/12/2022 10.40, Paul S Person wrote:
> > On Mon, 5 Dec 2022 17:00:58 GMT, djh...@kithrup.com (Dorothy J Heydt)
> > wrote:
> >
> >> In article <0cdebc5d-398d-49e8...@googlegroups.com>,
> >> pete...@gmail.com <pete...@gmail.com> wrote:
>
> >>> Bonus question: There's one place most Americans see mils used on
> >>> a daily basis. Where is it?
> >>
> >> Any gas station.
> >
> > Or fuel oil delivery receipt.
> Most Americans? I strongly doubt that.
>
> I've certainly never had fuel oil delivered to my house, and I don't
> think that I'm at all unusual in that way. My parents' house had oil
> heat, but I've never known anyone after them who had it.

Depends where you live.

My house has oil heat, in rural Massachusetts. We also installed
heat pumps a year ago. Its unclear whether they save us money.

pt

On 7/12/22 09:44, pete...@gmail.com wrote:
> On Tuesday, December 6, 2022 at 1:28:31 PM UTC-5, Michael F. Stemper wrote:
>> On 06/12/2022 10.40, Paul S Person wrote:
>>> On Mon, 5 Dec 2022 17:00:58 GMT, djh...@kithrup.com (Dorothy J Heydt)
>>> wrote:
>>>
>>>> In article <0cdebc5d-398d-49e8...@googlegroups.com>,
>>>> pete...@gmail.com <pete...@gmail.com> wrote:
>>
>>>>> Bonus question: There's one place most Americans see mils used on
>>>>> a daily basis. Where is it?
>>>>
>>>> Any gas station.
>>>
>>> Or fuel oil delivery receipt.
>> Most Americans? I strongly doubt that.
>>
>> I've certainly never had fuel oil delivered to my house, and I don't
>> think that I'm at all unusual in that way. My parents' house had oil
>> heat, but I've never known anyone after them who had it.
>
> Depends where you live.
>
> My house has oil heat, in rural Massachusetts. We also installed
> heat pumps a year ago. Its unclear whether they save us money.
>

My house in Aotearoa had coal fired central heating. Seven years ago I
replaced it with two heat pumps and despite continually rising prices,
my monthly heating bills are still cheaper than they were back then.
My parents house had oil fired central heating in their 1964 built house
but in New Zealand, oil has become too expensive compared to alternatives.

On 06/12/2022 14.44, pete...@gmail.com wrote:
> On Tuesday, December 6, 2022 at 1:28:31 PM UTC-5, Michael F. Stemper wrote:
>> On 06/12/2022 10.40, Paul S Person wrote:
>>> On Mon, 5 Dec 2022 17:00:58 GMT, djh...@kithrup.com (Dorothy J Heydt)
>>> wrote:
>>>
>>>> In article <0cdebc5d-398d-49e8...@googlegroups.com>,
>>>> pete...@gmail.com <pete...@gmail.com> wrote:
>>
>>>>> Bonus question: There's one place most Americans see mils used on
>>>>> a daily basis. Where is it?
>>>>
>>>> Any gas station.
>>>
>>> Or fuel oil delivery receipt.
>> Most Americans? I strongly doubt that.
>>
>> I've certainly never had fuel oil delivered to my house, and I don't
>> think that I'm at all unusual in that way. My parents' house had oil
>> heat, but I've never known anyone after them who had it.
>
> Depends where you live.
>
> My house has oil heat, in rural Massachusetts. We also installed
> heat pumps a year ago. Its unclear whether they save us money.

I didn't claim that nobody heats with oil, merely that it was atypical.

According to the EIA:
"While almost 85% of households in the United States heat with natural
gas or electricity, more than 10% rely on heating oil or propane,
according to the 2009 Residential Energy Consumption Survey. [...]
These fuels serve distinct populations—heating oil primarily serves
households in the Northeast, while propane serves households in rural
areas across the country."

<https://www.eia.gov/todayinenergy/detail.php?id=4070>

--
Michael F. Stemper
Exodus 22:21

On Tue, 06 Dec 2022 19:48:44 GMT, scott@slp53.sl.home (Scott Lurndal)
wrote:

>"Michael F. Stemper" <michael.stemper@gmail.com> writes:
>>On 06/12/2022 10.40, Paul S Person wrote:
>>> On Mon, 5 Dec 2022 17:00:58 GMT, djheydt@kithrup.com (Dorothy J Heydt)
>>> wrote:
>>>
>>>> In article <0cdebc5d-398d-49e8-9569-b31d7378f7ean@googlegroups.com>,
>>>> pete...@gmail.com <petertrei@gmail.com> wrote:
>>
>>>>> Bonus question: There's one place most Americans see mils used on
>>>>> a daily basis. Where is it?
>>>>
>>>> Any gas station.
>>>
>>> Or fuel oil delivery receipt.
>>
>>Most Americans? I strongly doubt that.
>>
>>I've certainly never had fuel oil delivered to my house, and I don't
>>think that I'm at all unusual in that way. My parents' house had oil
>>heat, but I've never known anyone after them who had it.
>
>My last home delivery propane bill lists the price in 1000s of mills:
>
> $4.128000 per gallon (corrected to 60F).

Mine shows $5.6390, but no correction based on degrees Fahrenheit.

But that's just one company. The one that bought them out when the
owner wanted to retire and had no one to leave it to used cents:
313.9, for example. The one before that (a merger occurred) used
cents: 00109.0, for example.

But none of them, including your example, actually showed a value less
than a mill. Their on-board computer just printed out however many
digits it was programmed to.

I would agree that oil heat is getting less common. Our area has been
pushing Air Pumps so enthusiastically one might wonder if they are
getting kickbacks. And I certainly will be going air pump if my
furnace ever dies -- I went through that once and once is quite
enough, thank you.

Not that I expect an air pump installation to be any more endurable,
but even I can read the writing on the wall, as it were.
--
"In this connexion, unquestionably the most significant
development was the disintegration, under Christian
influence, of classical conceptions of the family and
of family right."

On Tue, 6 Dec 2022 12:44:01 -0800 (PST), "pete...@gmail.com"
<petertrei@gmail.com> wrote:

>On Tuesday, December 6, 2022 at 1:28:31 PM UTC-5, Michael F. Stemper wrote:
>> On 06/12/2022 10.40, Paul S Person wrote:
>> > On Mon, 5 Dec 2022 17:00:58 GMT, djh...@kithrup.com (Dorothy J Heydt)
>> > wrote:
>> >
>> >> In article <0cdebc5d-398d-49e8...@googlegroups.com>,
>> >> pete...@gmail.com <pete...@gmail.com> wrote:
>>
>> >>> Bonus question: There's one place most Americans see mils used on
>> >>> a daily basis. Where is it?
>> >>
>> >> Any gas station.
>> >
>> > Or fuel oil delivery receipt.
>> Most Americans? I strongly doubt that.
>>
>> I've certainly never had fuel oil delivered to my house, and I don't
>> think that I'm at all unusual in that way. My parents' house had oil
>> heat, but I've never known anyone after them who had it.
>
>Depends where you live.
>
>My house has oil heat, in rural Massachusetts. We also installed
>heat pumps a year ago. Its unclear whether they save us money.

I have been keeping extensive records of my furnace's performance and,
compared to the data from the furnace that died, can say definitely
that the salesperson's promises of monetary savings were /definitely/
99% handwavium.
--
"In this connexion, unquestionably the most significant
development was the disintegration, under Christian
influence, of classical conceptions of the family and
of family right."

Paul S Person <psperson@old.netcom.invalid> writes:
>On Tue, 06 Dec 2022 19:48:44 GMT, scott@slp53.sl.home (Scott Lurndal)
>wrote:
>
>>"Michael F. Stemper" <michael.stemper@gmail.com> writes:
>>>On 06/12/2022 10.40, Paul S Person wrote:
>>>> On Mon, 5 Dec 2022 17:00:58 GMT, djheydt@kithrup.com (Dorothy J Heydt)
>>>> wrote:
>>>>
>>>>> In article <0cdebc5d-398d-49e8-9569-b31d7378f7ean@googlegroups.com>,
>>>>> pete...@gmail.com <petertrei@gmail.com> wrote:
>>>
>>>>>> Bonus question: There's one place most Americans see mils used on
>>>>>> a daily basis. Where is it?
>>>>>
>>>>> Any gas station.
>>>>
>>>> Or fuel oil delivery receipt.
>>>
>>>Most Americans? I strongly doubt that.
>>>
>>>I've certainly never had fuel oil delivered to my house, and I don't
>>>think that I'm at all unusual in that way. My parents' house had oil
>>>heat, but I've never known anyone after them who had it.
>>
>>My last home delivery propane bill lists the price in 1000s of mills:
>>
>> $4.128000 per gallon (corrected to 60F).
>
>Mine shows $5.6390, but no correction based on degrees Fahrenheit.

Note that it is the size of a gallon that is adjusted for
delivery temperature, not the price.

On 12/7/2022 10:58 AM, Paul S Person wrote:
> On Tue, 6 Dec 2022 12:44:01 -0800 (PST), "pete...@gmail.com"
> <petertrei@gmail.com> wrote:
>
>> On Tuesday, December 6, 2022 at 1:28:31 PM UTC-5, Michael F. Stemper wrote:
>>> On 06/12/2022 10.40, Paul S Person wrote:
>>>> On Mon, 5 Dec 2022 17:00:58 GMT, djh...@kithrup.com (Dorothy J Heydt)
>>>> wrote:
>>>>
>>>>> In article <0cdebc5d-398d-49e8...@googlegroups.com>,
>>>>> pete...@gmail.com <pete...@gmail.com> wrote:
>>>
>>>>>> Bonus question: There's one place most Americans see mils used on
>>>>>> a daily basis. Where is it?
>>>>>
>>>>> Any gas station.
>>>>
>>>> Or fuel oil delivery receipt.
>>> Most Americans? I strongly doubt that.
>>>
>>> I've certainly never had fuel oil delivered to my house, and I don't
>>> think that I'm at all unusual in that way. My parents' house had oil
>>> heat, but I've never known anyone after them who had it.
>>
>> Depends where you live.
>>
>> My house has oil heat, in rural Massachusetts. We also installed
>> heat pumps a year ago. Its unclear whether they save us money.
>
> I have been keeping extensive records of my furnace's performance and,
> compared to the data from the furnace that died, can say definitely
> that the salesperson's promises of monetary savings were /definitely/
> 99% handwavium.

Is your new furnace an electric heat pump, a natural gas 90% efficient
furnace, or a heating oil furnace ?

Lynn

On 07/12/2022 11.18, Scott Lurndal wrote:
> Paul S Person <psperson@old.netcom.invalid> writes:
>> On Tue, 06 Dec 2022 19:48:44 GMT, scott@slp53.sl.home (Scott Lurndal)
>> wrote:
>>
>>> "Michael F. Stemper" <michael.stemper@gmail.com> writes:
>>>> On 06/12/2022 10.40, Paul S Person wrote:

>>>>> Or fuel oil delivery receipt.
>>>>
>>>> Most Americans? I strongly doubt that.
>>>>
>>>> I've certainly never had fuel oil delivered to my house, and I don't
>>>> think that I'm at all unusual in that way. My parents' house had oil
>>>> heat, but I've never known anyone after them who had it.
>>>
>>> My last home delivery propane bill lists the price in 1000s of mills:
>>>
>>> $4.128000 per gallon (corrected to 60F).
>>
>> Mine shows $5.6390, but no correction based on degrees Fahrenheit.
>
> Note that it is the size of a gallon that is adjusted for
> delivery temperature, not the price.

That's how it was when I was on propane, as well. I've thrown all of
my receipts, so I can't say how many digits the price was displayed as.

--
Michael F. Stemper
Deuteronomy 10:18-19

On 07/12/2022 10.58, Paul S Person wrote:
> On Tue, 6 Dec 2022 12:44:01 -0800 (PST), "pete...@gmail.com"
> <petertrei@gmail.com> wrote:
>> On Tuesday, December 6, 2022 at 1:28:31 PM UTC-5, Michael F. Stemper wrote:
>>> On 06/12/2022 10.40, Paul S Person wrote:

>>>> Or fuel oil delivery receipt.
>>> Most Americans? I strongly doubt that.
>>>
>>> I've certainly never had fuel oil delivered to my house, and I don't
>>> think that I'm at all unusual in that way. My parents' house had oil
>>> heat, but I've never known anyone after them who had it.
>>
>> Depends where you live.
>>
>> My house has oil heat, in rural Massachusetts. We also installed
>> heat pumps a year ago. Its unclear whether they save us money.
>
> I have been keeping extensive records of my furnace's performance and,
> compared to the data from the furnace that died, can say definitely
> that the salesperson's promises of monetary savings were /definitely/
> 99% handwavium.

How do you compare across years? Do you track heating-degree days and
adjust consumption on that basis? I'd thought about doing that once upon
a time, but it was just too complicated.

--
Michael F. Stemper
Deuteronomy 10:18-19

On Wednesday, December 7, 2022 at 11:58:56 AM UTC-5, Paul S Person wrote:
> On Tue, 6 Dec 2022 12:44:01 -0800 (PST), "pete...@gmail.com"
> <pete...@gmail.com> wrote:
>
> >On Tuesday, December 6, 2022 at 1:28:31 PM UTC-5, Michael F. Stemper wrote:
> >> On 06/12/2022 10.40, Paul S Person wrote:
> >> > On Mon, 5 Dec 2022 17:00:58 GMT, djh...@kithrup.com (Dorothy J Heydt)
> >> > wrote:
> >> >
> >> >> In article <0cdebc5d-398d-49e8...@googlegroups.com>,
> >> >> pete...@gmail.com <pete...@gmail.com> wrote:
> >>
> >> >>> Bonus question: There's one place most Americans see mils used on
> >> >>> a daily basis. Where is it?
> >> >>
> >> >> Any gas station.
> >> >
> >> > Or fuel oil delivery receipt.
> >> Most Americans? I strongly doubt that.
> >>
> >> I've certainly never had fuel oil delivered to my house, and I don't
> >> think that I'm at all unusual in that way. My parents' house had oil
> >> heat, but I've never known anyone after them who had it.
> >
> >Depends where you live.
> >
> >My house has oil heat, in rural Massachusetts. We also installed
> >heat pumps a year ago. Its unclear whether they save us money.
> I have been keeping extensive records of my furnace's performance and,
> compared to the data from the furnace that died, can say definitely
> that the salesperson's promises of monetary savings were /definitely/
> 99% handwavium.

National Grid raising the price of electricity 60% a couple weeks ago
tossed our estimates in the trash.

Pt

pete...@gmail.com <petertrei@gmail.com> wrote:
> On Tuesday, December 6, 2022 at 1:28:31 PM UTC-5, Michael F. Stemper wrote:
>> On 06/12/2022 10.40, Paul S Person wrote:
>> > On Mon, 5 Dec 2022 17:00:58 GMT, djh...@kithrup.com (Dorothy J Heydt)
>> > wrote:
>> >
>> >> In article <0cdebc5d-398d-49e8...@googlegroups.com>,
>> >> pete...@gmail.com <pete...@gmail.com> wrote:
>>
>> >>> Bonus question: There's one place most Americans see mils used on
>> >>> a daily basis. Where is it?
>> >>
>> >> Any gas station.
>> >
>> > Or fuel oil delivery receipt.
>> Most Americans? I strongly doubt that.
>>
>> I've certainly never had fuel oil delivered to my house, and I don't
>> think that I'm at all unusual in that way. My parents' house had oil
>> heat, but I've never known anyone after them who had it.
>
> Depends where you live.
>
> My house has oil heat, in rural Massachusetts. We also installed
> heat pumps a year ago. Its unclear whether they save us money.

We're in an exurb of Dallas and they're really the only cost-effective
solution. Propane is expensive (and also very expensive to install) and in
a "normal" winter we rarely get below freezing (a few nights a year into the
upper 20's).
The two drawbacks I've discovered are that in a cold winter things get
expensive fast...somewhere around the freezing point ours turns on 10kW
of resistance heating (and in the "big chill" we were wishing for 15kW).
Yes, there are more efficient units. They're also more expensive and
physically take up more space. Fitting one in would require a $15k+ rebuild
of our HVAC, above and beyond the new unit.
The other is that in locations like Dallas where there are a lot of both
heating and cooling days (frequently in the same months) the heat pump is
doing double duty. A/C and furnace take turns and spread the wear.
They also have failure modes that A/C lacks (reversing valves, we hates them).

Robert
--
Robert K. Shull Email: rkshull at rosettacon dot com