odd ball load splitting hairs

Has anyone ever seen a load that splits hairs like this one ?

I count about 13 zeros before it gets to the last 2 in the rate.

This is from the credit union that I do most of my banking with.

Congratulations! You have been pre-approved1 for an auto loan up to

$65000 at a low rate of 3.4900000000000002% APR for up to 60 months.

Reply to
Ralph Mowery
Loading thread data ...

Ridiculous. My bank will give me 3.4900000000000019% APR

Reply to
Ed Pawlowski

Indeed, some programmer was asleep at the wheel there...

Even if it were real they couldn't easily compute the difference as double precision only hold about 15-16 decimal digits precision so the last 2 places in the 17 digits (decimal point doesn't count) will fall off the end.

Even if they went to the trouble to actually compute the additional interest,

of a dollar or 1.3E-10 cents over a year.

Sorry, just couldn't resist!!!

Reply to
dpb

Good call.

Add that extra part up for 5 (five!) years and you have 000000000000001% of $65,000, and you're talking real money. 0.00000000000065 dollars, if I'm not mistaken, plus compound interest. Fortunately, if you only borrow 40,000, it will only cost you an extra 0.00000000000040 dollars, plus compound interest.

Reply to
micky

I did hit a typo and should have said loan.

I did not take time to even try and compute it,but was thinking that for the last payment I would have to take a penny to the credit union and some 400 grit sand paper and make a pass with it .

I don't know if someone hit the wrong key or what to come up with that wild number. It will be interisting to see if the CU comes up with a follow up on that.

Reply to
Ralph Mowery

Damn script kiddies can't comprehend printf("low rate of %.2f", apr);

Reply to
rbowman

BCD is a lost art, apparently.

Cindy Hamilton

Reply to
Cindy Hamilton

Will the last COBOL programmer please turn off the System 360?

Reply to
rbowman

Brilliant marketing gimmick.  How many people have you shared their ad copy with?

Reply to
ʎeʞɔᴉɯ

IEEE 754-2008 (last rev 2019) includes decimal specifications as well as binary.

Reply to
dpb

Perhaps I should have said, "teaching BCD and its uses is a lost art".

Cindy Hamilton

Reply to
Cindy Hamilton

I have not shared the name of the CU with anyone, just the line that shows the really odd ball rate.

It could be a marketing gimmick. Market people will try almost anything they can think of. The way many car dealers are saying 0% to 2 % loans I hardly see banks and CUs making very many car loans. I bought a car about 2 years ago mainly because of the 0 % loan for 7 years. The car I had was 10 years old but had less than 40,000 miles on it. Being 67 at the time, I thought that may be the last or next to last car I would be buying. I could have paid for the car, but would have had to take the money out of an IRA and take a tax hit. Thinking the stock market will be going up some, I thought I would make (save) several thousand in that period of time.

Reply to
Ralph Mowery

A shitty programmer who used binary floating point when they should have been using fixed point. Oh, for the glory days of COBOL.

Reply to
Scott Lurndal

Problem is finding compilers/toolsets implementing it...virtually everything is built around the particular C/C++ rtl library core any more...which is also more and more MS.

Reply to
dpb

BCD (7 bit) was a 1401 protocol. 360s used hex (9 bit)

Reply to
gfretwell

What was the "rebate" for paying cash? Usually those zero percent deals end up adding $1500 or more to the price. OTOH if you take their financing at the going rate, they kick money back to you.

Reply to
gfretwell

At that time there was no rebate for paying cash. I had negociated the price of the car. I saw where they were going to charge me about 2% interist for 7 years. Then I told them the TV advertised 0 %. The man said 'you want me to sell you the car at that price and 0 %'. I said yes, the TV said 0% and if I do not get that, no deal.

Yes, I am aware of the low or zero % and/or the cash 'rebate' for paying cash.

Reply to
Ralph Mowery

I don't see where it would be a programming problem. This was in a standard email that I usually get once a month or so to probably most of the credit union members that had a good credit rating. I would have thought it should have been typed in manually, but it could have been some programming involved to taylor the ammount to each member.

Reply to
Ralph Mowery

BCD is, by definition, 4 bits. And predates the 1401 by several years.

360's were (are in Z-Series) EBCDIC (8-bit), 32-bit binary and packed decimal (4-bit BCD).

The PDP-10/20 and Univac systems used 6-bit and 9-bit codes (fielddata, 9-bit ASCII) due to the 36-bit word size.

Pretty much everything else uses some form of binary representation (ones or twos complement) in 12-bit, 16-bit, 24-bit, 32-bit, 36-bit, 48-bit or 64-bit native words.

Early 8086 processors supported BCD arithmetic; those instructions were removed from long mode by AMD when they did the x86_64 extensions so they could re-use the opcodes.

Reply to
Scott Lurndal

I agree 70xx and 650s used BCD but the 1401 was pretty much the last hold out. People were running 1401 emulation up into the 80s. It was 6 bits plus parity in any implementation I ever saw so they could support alphanumerics.

AKA "hex" and with the parity bit, 9.

Reply to
gfretwell

HomeOwnersHub website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.