The Decline and Fall of Search Engines
-
John C. Dvorak, long-time PC Mag columnist (who, in his own words, got unceremoniously deplatformed for his views on 5G), had a great article on this sort of thing a good while ago. As I recall he referred to it as the big data lie. Basically, it amounts to this: They have access to the largest purchasing history database in the world, yet the best they can do is, after you've bought a hat, start showing you ads for hats. AI has a long way to go.
Indeed - how many new cars can you buy one after the other (facebook after I bought a car - and how did it even find out given that I bought it in person, the internet wasn't involved)? How many new projectors do you need (Amazon after I bought one)? I don't think Skynet is quite ready yet - and if it is, would probably drop megatons of sanitary products on women and "men's" products on men. 8) I can't believe it would be difficult to tell the AI to ignore non-consumable products for a while after you bought them, rather than instantly assuming you are buying them for the entire population of your home country.
-
Like ancient Rome, they fall under their own arrogant weight. I'm referring (primarily) to engines on shopping sites but the petulance surely spreads. So, for example, you're on Amazon.com (probably the most ubiquitous online shopping site in the world). You search for 1/16" FOOBARS . Your return will include some of those. And Foobar of other sizes, as well. And possibly things with 1/16" in their description. OK - so far it's the engine OR-ing the keywords. Not great but an acceptable choice on their part. How does that explain the hand sanitizer? Face Masks? Sandpaper? Note that I'm not logged in (where they keep track of previous purchases) and my browser deletes cookies, flash cookies, and history when it's closed. It's not looking into my dark and shady past. They seem to be just throwing random things into the search. Same thing, if one request the sort "Low to High Prices". Since when does $39.95 come between $3.99 and $4.29 ? I think by now I've made it clear - you search for something; they give a few of those and then push whatever else it is that they want to sell. Brick and Mortar? All is not yet lost !
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein
"If you are searching for perfection in others, then you seek disappointment. If you seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010
I often find it easier to bypass their search altogether and use a search engine. E.g. 1/16" FOOBARS site:amazon.com
-
Quote:
the values are probably stored as FP, and should sort properly.
The number one rule when dealing with currency in software is not to use floating point for currency. Unless you like bugs.
First of all, we talking about sorting - so what bugs are you talking about? Secondly, they have, really, two other options: 1 - Store as integers and divide by 100 (for US$, at least) - so it's back to FP arithmetic 2 - Store as string values - in which case the sort will fail (unless stored left-paddded with blanks or 0's) - and you'll still need to convert them, along the way, to FP in order to do arithmetic with them. As for your original premise? Bugs? NOT! Round-off errors due to their representation in memory is something a REAL programmer keeps in mind. How much do you think anyone spends on the Amazon website where 64-bit FP's round-off errors will become significant? There's no excuse for the high priced item to show up in the middle so often, except, of course, marketing.
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein
"If you are searching for perfection in others, then you seek disappointment. If you seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010
-
I often find it easier to bypass their search altogether and use a search engine. E.g. 1/16" FOOBARS site:amazon.com
Your proposal seemed like an interesting option so I tried it with a recent shopping event. The listing I got was difficult to use (no sorting or anything) - so I modified the search by clicking the shopping link. At that point, site:amazon.com was no longer part of the picture. Deja-vu all over again. Too bad.
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein
"If you are searching for perfection in others, then you seek disappointment. If you seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010
-
Quote:
the values are probably stored as FP, and should sort properly.
The number one rule when dealing with currency in software is not to use floating point for currency. Unless you like bugs.
Where are the packed decimal instructions when you need them.
-
First of all, we talking about sorting - so what bugs are you talking about? Secondly, they have, really, two other options: 1 - Store as integers and divide by 100 (for US$, at least) - so it's back to FP arithmetic 2 - Store as string values - in which case the sort will fail (unless stored left-paddded with blanks or 0's) - and you'll still need to convert them, along the way, to FP in order to do arithmetic with them. As for your original premise? Bugs? NOT! Round-off errors due to their representation in memory is something a REAL programmer keeps in mind. How much do you think anyone spends on the Amazon website where 64-bit FP's round-off errors will become significant? There's no excuse for the high priced item to show up in the middle so often, except, of course, marketing.
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein
"If you are searching for perfection in others, then you seek disappointment. If you seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010
Quote:
First of all, we talking about sorting - so what bugs are you talking about?
Using FP for currencies is a bug.
Quote:
1 - Store as integers and divide by 100 (for US$, at least) - so it's back to FP arithmetic
That's not how it is done. No FP is used other than for display.
Quote:
2 - Store as string values -
That's also not how it's done. Currencies have to be stored as a fixed-numeric type.
Quote:
As for your original premise? Bugs? NOT! Round-off errors due to their representation in memory is something a REAL programmer keeps in mind.
Software in banking systems have to be certified (I write EMV and related software, including all the other card processing on the back ends), and the software does not get certified if you are using FP for currencies. They call it a Bug. An Error. A Defect. Whenever you are dealing with currency, using FP for it is a bug. You could have spent 2m on google finding this out. Look at all the standards that have to be adhered to for banking and currency software - currencies are specified in specified fixed-numeric types. See all the ISO standards that banking and transaction interchange are written to: No FP. But, hey, as a "REAL" programmer maybe you should go tell all these institutions and regulators why FP is not a Bug. After all, I've only been employed as a programmer for 25 years, writing interbank switching software and transaction processing software; what could I possibly know about the datatype of currencies. Shit, even the PostgreSQL (or MySQL, or MSSQL, I forget which) manual warns not to store currency as floating point types. Of course, I'm sure a REAL programmer like yourself read the SQL rationale for the NUMERIC type, right? I mean you wouldn't be posting so arrogantly if you had known about the existence of DECIMAL in the SQL ANSI standard, and why they put it in? Right?
-
Quote:
First of all, we talking about sorting - so what bugs are you talking about?
Using FP for currencies is a bug.
Quote:
1 - Store as integers and divide by 100 (for US$, at least) - so it's back to FP arithmetic
That's not how it is done. No FP is used other than for display.
Quote:
2 - Store as string values -
That's also not how it's done. Currencies have to be stored as a fixed-numeric type.
Quote:
As for your original premise? Bugs? NOT! Round-off errors due to their representation in memory is something a REAL programmer keeps in mind.
Software in banking systems have to be certified (I write EMV and related software, including all the other card processing on the back ends), and the software does not get certified if you are using FP for currencies. They call it a Bug. An Error. A Defect. Whenever you are dealing with currency, using FP for it is a bug. You could have spent 2m on google finding this out. Look at all the standards that have to be adhered to for banking and currency software - currencies are specified in specified fixed-numeric types. See all the ISO standards that banking and transaction interchange are written to: No FP. But, hey, as a "REAL" programmer maybe you should go tell all these institutions and regulators why FP is not a Bug. After all, I've only been employed as a programmer for 25 years, writing interbank switching software and transaction processing software; what could I possibly know about the datatype of currencies. Shit, even the PostgreSQL (or MySQL, or MSSQL, I forget which) manual warns not to store currency as floating point types. Of course, I'm sure a REAL programmer like yourself read the SQL rationale for the NUMERIC type, right? I mean you wouldn't be posting so arrogantly if you had known about the existence of DECIMAL in the SQL ANSI standard, and why they put it in? Right?
First, none of what you said explains, in the least, the original premise: they they cannot seem to sort numeric values, and furthermore, pretty much any numeric type sorts those values perfectly well - regardless of storage, except for string-types. So - now - let's say you store your numeric types any which way you think is great. How do you represent them for calculations? BCD, I suppose. Actually, here, we store data in the SQL currency datatype. Interestingly, not being part of the banking (or other) financial system, Amazon can store the prices of items any damn way they wish. You did read that, didn't you? PRICES OF ITEMS ? So, aside from the risk of you financial guys doing arbitrage on the price of Kindle's, why would Amazon bother with the overhead on how to display or calculate pricing other than in the most efficient way possible? The 100th's of a cent error? Rounded up or down in a business - and the final value, that which is billed, is the relevant value. As for "real" programs - I'm from the world of arbitrary precision values - scientific things, such as modeling, can iterate something tens of millions of times - and something rounded off in the precision of the 24th decimal place can come back to haunt you. But here's the deal - unlike contract-software made by-the-book (or by the regulation), it was up to us to determine when the overhead was worth the price. Even considering the CPU's native bit-width (16 or 32 bits, then). Your solution is mandated. When choice enters the matter, the real decisions are made from knowledge and experience as to the best tools for the job.
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein
"If you are searching for perfection in others, then you seek disappointment. If you seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010
-
First, none of what you said explains, in the least, the original premise: they they cannot seem to sort numeric values, and furthermore, pretty much any numeric type sorts those values perfectly well - regardless of storage, except for string-types. So - now - let's say you store your numeric types any which way you think is great. How do you represent them for calculations? BCD, I suppose. Actually, here, we store data in the SQL currency datatype. Interestingly, not being part of the banking (or other) financial system, Amazon can store the prices of items any damn way they wish. You did read that, didn't you? PRICES OF ITEMS ? So, aside from the risk of you financial guys doing arbitrage on the price of Kindle's, why would Amazon bother with the overhead on how to display or calculate pricing other than in the most efficient way possible? The 100th's of a cent error? Rounded up or down in a business - and the final value, that which is billed, is the relevant value. As for "real" programs - I'm from the world of arbitrary precision values - scientific things, such as modeling, can iterate something tens of millions of times - and something rounded off in the precision of the 24th decimal place can come back to haunt you. But here's the deal - unlike contract-software made by-the-book (or by the regulation), it was up to us to determine when the overhead was worth the price. Even considering the CPU's native bit-width (16 or 32 bits, then). Your solution is mandated. When choice enters the matter, the real decisions are made from knowledge and experience as to the best tools for the job.
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein
"If you are searching for perfection in others, then you seek disappointment. If you seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010
Quote:
First, none of what you said explains, in the least, the original premise:
I wasn't explaining the original premise, I was explaining why storing currency as FP is a bug.
Quote:
As for "real" programs - I'm from the world of arbitrary precision values - scientific things, such as modeling, can iterate something tens of millions of times - and something rounded off in the precision of the 24th decimal place can come back to haunt you.
Good for you, I was a research scientist for 7 years and worked on multiple different research projects at the Council for Scientific and Industrial Research. I already know what FP is and isn't good for. I was explaining that FP being used for currencies is a bug. I also spent more than a few years writing embedded software that fell under munitions regulations in all Western countries, most of African and Middle Eastern countries, and all the larger Eastern countries, specifically, software to control detonators and detonations That's right, I was literally a goddamned rocket scientist. And in the embedded world, using FP is also considered a bug until it is formally motivated (and the motivation is accepted) on a case by case basis.
Quote:
Your solution is mandated.
When all the different authorities across the world on banking and currencies, and all the data storage experts (MSSQL, Oracle, PostgreSQL, DB2, etc) all agree that storing currencies as FP is a bug, you'd have to be a real moron to claim that it's only because of a mandate that it is a bug.
Quote:
When choice enters the matter, the real decisions are made from knowledge and experience as to the best tools for the job.
And yet you thought there were only two ways of storing currencies - your experience is on display with that post you made. You could have avoid appearing the way you do by simply searching google for 2m to determine why storing currencies in FP is a bug. You can still do that - can you find even one link that agrees with your assertion that storing currencies as FP is the correct thing to do? Just one, authoritative, known expert in either programming or banking will do.
-
Quote:
First, none of what you said explains, in the least, the original premise:
I wasn't explaining the original premise, I was explaining why storing currency as FP is a bug.
Quote:
As for "real" programs - I'm from the world of arbitrary precision values - scientific things, such as modeling, can iterate something tens of millions of times - and something rounded off in the precision of the 24th decimal place can come back to haunt you.
Good for you, I was a research scientist for 7 years and worked on multiple different research projects at the Council for Scientific and Industrial Research. I already know what FP is and isn't good for. I was explaining that FP being used for currencies is a bug. I also spent more than a few years writing embedded software that fell under munitions regulations in all Western countries, most of African and Middle Eastern countries, and all the larger Eastern countries, specifically, software to control detonators and detonations That's right, I was literally a goddamned rocket scientist. And in the embedded world, using FP is also considered a bug until it is formally motivated (and the motivation is accepted) on a case by case basis.
Quote:
Your solution is mandated.
When all the different authorities across the world on banking and currencies, and all the data storage experts (MSSQL, Oracle, PostgreSQL, DB2, etc) all agree that storing currencies as FP is a bug, you'd have to be a real moron to claim that it's only because of a mandate that it is a bug.
Quote:
When choice enters the matter, the real decisions are made from knowledge and experience as to the best tools for the job.
And yet you thought there were only two ways of storing currencies - your experience is on display with that post you made. You could have avoid appearing the way you do by simply searching google for 2m to determine why storing currencies in FP is a bug. You can still do that - can you find even one link that agrees with your assertion that storing currencies as FP is the correct thing to do? Just one, authoritative, known expert in either programming or banking will do.
Now that you finished beating your chest, you seem to have fulfilled the promise of what appears to be a very narrow scope of vision: you cannot see the forest because the damn trees are in the way. Stop citing regulation and tell me, once and for all, how it matter how the data is (FP or one of your banking formats) will have any effect on a sort? And you keep harping on how I should google why FP is a bug – but it’s totally irrelevant to the real point. Similarly, you complain I only mentioned to forms of financial storage types – where did I claim any sort of exhaustive search? Oh – yes – a rocket scientist – beating your chest some more. I separated uranium isotopes on a table top in a tube 30cm long . . . roughly ten times better than the current stat of the art by mass based methodologies (gaseous diffusion, gas centrifuges, for example). So that make me a nuclear scientist? And that, part of the very earliest days of infrared laser photochemistry. Do you realize that neither that, nor your bomb-making credentials, mean shit to this argument. In fact, I would be quite ashamed to try to throw them out in any way as some sort of “so there! Gotcha !”. Still, there’s something to be learned from this pissing contest we’re in: something about staying on topic. I use FP because where I use it makes absolutely no difference. I use the numeric types that best match the native bandwidth of the processor I am targeting. If I perceive there will be a problem with one data type I’ll use one more appropriate – but it’s ludicrous to label something a bug because it doesn’t meet the particular standards of a totally unrelated consideration. How the hell would string a price as a FP digit hurt anything for Amazon? They use what they store, calculate the charges, surcharges (taxes), and shipping, and then the billing is done. The final value sent off for the accountants – who can do whatever the hell they want with it. And give it a thought: storing a unit price is not necessarily the same as storing currency.
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein
"If you are searching for perfection in others, then you seek disappointment. If you seek perfection in yourself, then you will find failure." - Balboos
-
Now that you finished beating your chest, you seem to have fulfilled the promise of what appears to be a very narrow scope of vision: you cannot see the forest because the damn trees are in the way. Stop citing regulation and tell me, once and for all, how it matter how the data is (FP or one of your banking formats) will have any effect on a sort? And you keep harping on how I should google why FP is a bug – but it’s totally irrelevant to the real point. Similarly, you complain I only mentioned to forms of financial storage types – where did I claim any sort of exhaustive search? Oh – yes – a rocket scientist – beating your chest some more. I separated uranium isotopes on a table top in a tube 30cm long . . . roughly ten times better than the current stat of the art by mass based methodologies (gaseous diffusion, gas centrifuges, for example). So that make me a nuclear scientist? And that, part of the very earliest days of infrared laser photochemistry. Do you realize that neither that, nor your bomb-making credentials, mean shit to this argument. In fact, I would be quite ashamed to try to throw them out in any way as some sort of “so there! Gotcha !”. Still, there’s something to be learned from this pissing contest we’re in: something about staying on topic. I use FP because where I use it makes absolutely no difference. I use the numeric types that best match the native bandwidth of the processor I am targeting. If I perceive there will be a problem with one data type I’ll use one more appropriate – but it’s ludicrous to label something a bug because it doesn’t meet the particular standards of a totally unrelated consideration. How the hell would string a price as a FP digit hurt anything for Amazon? They use what they store, calculate the charges, surcharges (taxes), and shipping, and then the billing is done. The final value sent off for the accountants – who can do whatever the hell they want with it. And give it a thought: storing a unit price is not necessarily the same as storing currency.
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein
"If you are searching for perfection in others, then you seek disappointment. If you seek perfection in yourself, then you will find failure." - Balboos
Quote:
Stop citing regulation and tell me, once and for all, how it matter how the data is (FP or one of your banking formats) will have any effect on a sort?
I never claimed that it did. You posted:
Quote:
the values are probably stored as FP, and should sort properly.
To which I said that storing currency values as FP is a bug. And to which you took issue because you thought there were only two ways to store currency values:
Quote:
Secondly, they have, really, two other options: 1 - Store as integers and divide by 100 (for US$, at least) - so it's back to FP arithmetic 2 - Store as string values - in which case the sort will fail (unless stored left-paddded with blanks or 0's) - and you'll still need to convert them, along the way, to FP in order to do arithmetic with them.
Quote:
but it’s ludicrous to label something a bug because it doesn’t meet the particular standards of a totally unrelated consideration
I never claimed that using FP was a bug, I said that using FP to store currency values is a bug.
Quote:
The final value sent off for the accountants – who can do whatever the hell they want with it.
That's not how it works. You literally thought that currency values would be stored as FP, and when someone pointed out that doing so is a bug you took offense.
Quote:
Now that you finished beating your chest,
Yeah, maybe you shouldn't have lead with beating your chest and talking about how "real" programmers do things. Then I wouldn't have had to point out that I was employed as a scientist for seven years, that I write transaction software currently, that I have been employed writing software for the last 25 years and that part of that time was spent writing software on actual detonation systems in rockets. Storing currency values as FP is a well-known rookie mistake, which you no doubt found out when trying to find a link that supports your assertion that there are only two ways to store currency values - strings and FP. And it doesn't matter now how much you bleat about what Amazon may or may not have done, you have already posted the embarrassing assertion about currency values being stored
-
Like ancient Rome, they fall under their own arrogant weight. I'm referring (primarily) to engines on shopping sites but the petulance surely spreads. So, for example, you're on Amazon.com (probably the most ubiquitous online shopping site in the world). You search for 1/16" FOOBARS . Your return will include some of those. And Foobar of other sizes, as well. And possibly things with 1/16" in their description. OK - so far it's the engine OR-ing the keywords. Not great but an acceptable choice on their part. How does that explain the hand sanitizer? Face Masks? Sandpaper? Note that I'm not logged in (where they keep track of previous purchases) and my browser deletes cookies, flash cookies, and history when it's closed. It's not looking into my dark and shady past. They seem to be just throwing random things into the search. Same thing, if one request the sort "Low to High Prices". Since when does $39.95 come between $3.99 and $4.29 ? I think by now I've made it clear - you search for something; they give a few of those and then push whatever else it is that they want to sell. Brick and Mortar? All is not yet lost !
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein
"If you are searching for perfection in others, then you seek disappointment. If you seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010
Amazon search has a lot of room for improvement. They could learn a lot from Craigslist which has a pretty thorough syntax. You can't add "not" to Amazon searches to weed out the noise. I was searching for 4 cell LiPos and had no way to filter out the 2S, 3S, 6S. There are a lot of 3S to wade through! I think Amazon had "not" and "and" syntax at one time but took it away? I could be mis-remembering. Not to say Craigslist is perfect. Used car dealers know how to make their crap shows up show up for stuff you really don't want to see by adding a block of "keywords". Interestingly, it is hidden on the mobile search but you can see it on the desktop browser experience. Just add another "not" clause and you're good to go. I'd think that Craigslist could easily detect these and keep them from being posted.
-
Amazon search has a lot of room for improvement. They could learn a lot from Craigslist which has a pretty thorough syntax. You can't add "not" to Amazon searches to weed out the noise. I was searching for 4 cell LiPos and had no way to filter out the 2S, 3S, 6S. There are a lot of 3S to wade through! I think Amazon had "not" and "and" syntax at one time but took it away? I could be mis-remembering. Not to say Craigslist is perfect. Used car dealers know how to make their crap shows up show up for stuff you really don't want to see by adding a block of "keywords". Interestingly, it is hidden on the mobile search but you can see it on the desktop browser experience. Just add another "not" clause and you're good to go. I'd think that Craigslist could easily detect these and keep them from being posted.
Shmoken99 wrote:
You can't add "not" to Amazon searches to weed out the noise
Actually you can:
"4 cell LiPo" -2S
Will look for exact text, and exclude results with "2S" in them. I've been using it for years! :-D
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony "Common sense is so rare these days, it should be classified as a super power" - Random T-shirt AntiTwitter: @DalekDave is now a follower!
-
Quote:
First, none of what you said explains, in the least, the original premise:
I wasn't explaining the original premise, I was explaining why storing currency as FP is a bug.
Quote:
As for "real" programs - I'm from the world of arbitrary precision values - scientific things, such as modeling, can iterate something tens of millions of times - and something rounded off in the precision of the 24th decimal place can come back to haunt you.
Good for you, I was a research scientist for 7 years and worked on multiple different research projects at the Council for Scientific and Industrial Research. I already know what FP is and isn't good for. I was explaining that FP being used for currencies is a bug. I also spent more than a few years writing embedded software that fell under munitions regulations in all Western countries, most of African and Middle Eastern countries, and all the larger Eastern countries, specifically, software to control detonators and detonations That's right, I was literally a goddamned rocket scientist. And in the embedded world, using FP is also considered a bug until it is formally motivated (and the motivation is accepted) on a case by case basis.
Quote:
Your solution is mandated.
When all the different authorities across the world on banking and currencies, and all the data storage experts (MSSQL, Oracle, PostgreSQL, DB2, etc) all agree that storing currencies as FP is a bug, you'd have to be a real moron to claim that it's only because of a mandate that it is a bug.
Quote:
When choice enters the matter, the real decisions are made from knowledge and experience as to the best tools for the job.
And yet you thought there were only two ways of storing currencies - your experience is on display with that post you made. You could have avoid appearing the way you do by simply searching google for 2m to determine why storing currencies in FP is a bug. You can still do that - can you find even one link that agrees with your assertion that storing currencies as FP is the correct thing to do? Just one, authoritative, known expert in either programming or banking will do.
This looks like something I need to know, but I've spent a lot more than 2m and can't find it. ISO 4217 is an obvious place to start but nothing there. Could you provide a link please. Or a search term that would get me there. I do have an app that makes use of 2 (at the moment) currencies - and I'm using FP. TIA.
-
This looks like something I need to know, but I've spent a lot more than 2m and can't find it. ISO 4217 is an obvious place to start but nothing there. Could you provide a link please. Or a search term that would get me there. I do have an app that makes use of 2 (at the moment) currencies - and I'm using FP. TIA.
Quote:
This looks like something I need to know, but I've spent a lot more than 2m and can't find it. ISO 4217 is an obvious place to start but nothing there. Could you provide a link please. Or a search term that would get me there. I do have an app that makes use of 2 (at the moment) currencies - and I'm using FP. TIA.
Off the top of my head try checking the ISO8583 data elements. All links in the chain of authorisation and settlements are done in some variant of the ISO8583 data elements (which, IIRC, are fixed-numeric of 12 or 14 digits for any field holding an amount). This includes the acquirer PoS/terminal database, the merchant's stock database, the switches' message queues, the bank's transactional/rely system and storage and the issuer's database. They all religiously follow that. The reason that using FP for currency and/or money values is considered a bug is due to the inaccuracy of FP (whether 64/80 bits): depending on the implementation, "0 != -0", "NaN != NaN", etc; equality comparisons cannot be made on FP calculations. For example, guess what the following program prints out (using IEEE754 implementation):
int main (void)
{
float a = 0.1;
float b = 0.2;
float c = a + b;
if (c == 0.3) {
printf ("FOO");
} else {
printf ("BAR");
}
return 0;
}FP cannot be reliably compared for equality. The above program, rewritten in any language that uses IEEE 754 floats, will always print "BAR". In FP, adding an FP 0.1 to an FP 0.2 does not result in an FP 0.3 - it results in something quite close though, but you cannot compare for equality. Your app really should use a fixed-numeric (also called fixed-point, fixed-decimal, decimal or numeric) datatype for storing money, because money is always divided (tax, etc) and converted to other currencies, and the imprecision of FP arithmetic means that it is always going to have small errors. When talking to a forex system using their API, you'll find that they don't do their representation of money using FP. If you're using an OOP language a numeric class can be made (or download one of the free popular ones) so that you get error-free fixed-point arithmetic. If you're storing the values, store them as a numeric/decimal fixed-point type, because if you read in an FP value that you just wrote out to disk, and compare it with what you thought you wrote, you'd find that the equality comparison sometimes fails (just like in t
-
Quote:
This looks like something I need to know, but I've spent a lot more than 2m and can't find it. ISO 4217 is an obvious place to start but nothing there. Could you provide a link please. Or a search term that would get me there. I do have an app that makes use of 2 (at the moment) currencies - and I'm using FP. TIA.
Off the top of my head try checking the ISO8583 data elements. All links in the chain of authorisation and settlements are done in some variant of the ISO8583 data elements (which, IIRC, are fixed-numeric of 12 or 14 digits for any field holding an amount). This includes the acquirer PoS/terminal database, the merchant's stock database, the switches' message queues, the bank's transactional/rely system and storage and the issuer's database. They all religiously follow that. The reason that using FP for currency and/or money values is considered a bug is due to the inaccuracy of FP (whether 64/80 bits): depending on the implementation, "0 != -0", "NaN != NaN", etc; equality comparisons cannot be made on FP calculations. For example, guess what the following program prints out (using IEEE754 implementation):
int main (void)
{
float a = 0.1;
float b = 0.2;
float c = a + b;
if (c == 0.3) {
printf ("FOO");
} else {
printf ("BAR");
}
return 0;
}FP cannot be reliably compared for equality. The above program, rewritten in any language that uses IEEE 754 floats, will always print "BAR". In FP, adding an FP 0.1 to an FP 0.2 does not result in an FP 0.3 - it results in something quite close though, but you cannot compare for equality. Your app really should use a fixed-numeric (also called fixed-point, fixed-decimal, decimal or numeric) datatype for storing money, because money is always divided (tax, etc) and converted to other currencies, and the imprecision of FP arithmetic means that it is always going to have small errors. When talking to a forex system using their API, you'll find that they don't do their representation of money using FP. If you're using an OOP language a numeric class can be made (or download one of the free popular ones) so that you get error-free fixed-point arithmetic. If you're storing the values, store them as a numeric/decimal fixed-point type, because if you read in an FP value that you just wrote out to disk, and compare it with what you thought you wrote, you'd find that the equality comparison sometimes fails (just like in t
Thanks, now I see what point you were making. It's reasonably obvious that multiplication and division will usually require truncation or rounding but the addition and subtraction issue (as in your example above) might be less obvious to some. My exchange rate provider supplies the conversion as a JSON string, to six decimal places. Any difference from rounding in this particular app is immaterial. A few hundred transactions in any month, with 20 or so different daily exchange rates. My client needs to know the local currency amount for each transaction, but only the total of all the foreign currency amounts. I am using an OOP language, but probably not one that you use. Delphi (which uses IEEE 754) provides a floating-point function with an Epsilon parameter - the maximum amount by which 2 floating-point numbers can differ and still be considered the same value. I might write, in your example,
if SameValue (c, 0.3, 0.00001) then...
and it would print FOO. Thanks for the ISO 8583 reference. It's long, and has many normative references - I haven't read it all :laugh:
-
W∴ Balboos, GHB wrote:
How does that explain the hand sanitizer? Face Masks? Sandpaper?
Those are items needed everywhere you go and anywhere you are so it makes sense that anything you are searching for would also need those related items.
I don't disagree, but when I want to buy a "4S 850 mAh 95 C" LiPo battery for one of my racing/freestyle drones, it gets really annoying that the only batteries with the specs I actually specified are on, like, page 9, 15, and 22 of the search results. I miss Alta Vista.
Eagles my fly, but weasels don't get sucked into jet engines.
-
W∴ Balboos, GHB wrote:
How does that explain the hand sanitizer? Face Masks? Sandpaper?
Those are items needed everywhere you go and anywhere you are so it makes sense that anything you are searching for would also need those related items.
I don't disagree, but when I want to buy a "4S 850 mAh 95 C" LiPo battery for one of my racing/freestyle drones, it gets really annoying that the only batteries with the specs I actually specified are on, like, page 9, 15, and 22 of the search results. I miss Alta Vista.
Eagles my fly, but weasels don't get sucked into jet engines.
-
Thanks, now I see what point you were making. It's reasonably obvious that multiplication and division will usually require truncation or rounding but the addition and subtraction issue (as in your example above) might be less obvious to some. My exchange rate provider supplies the conversion as a JSON string, to six decimal places. Any difference from rounding in this particular app is immaterial. A few hundred transactions in any month, with 20 or so different daily exchange rates. My client needs to know the local currency amount for each transaction, but only the total of all the foreign currency amounts. I am using an OOP language, but probably not one that you use. Delphi (which uses IEEE 754) provides a floating-point function with an Epsilon parameter - the maximum amount by which 2 floating-point numbers can differ and still be considered the same value. I might write, in your example,
if SameValue (c, 0.3, 0.00001) then...
and it would print FOO. Thanks for the ISO 8583 reference. It's long, and has many normative references - I haven't read it all :laugh:
Quote:
I am using an OOP language, but probably not one that you use. Delphi
Hah :-) Not quite ... :-) While not an expert, I've done a few desktop GUI projects in Lazarus recently (2018). I chose Lazarus over Delphi because my primary target was Linux and Delphi had poor-to-non-existent support for Linux, *BSDs, etc. Besides, Lazarus appears to be in active development while Delphi development has stagnated in recent years.
-
Like ancient Rome, they fall under their own arrogant weight. I'm referring (primarily) to engines on shopping sites but the petulance surely spreads. So, for example, you're on Amazon.com (probably the most ubiquitous online shopping site in the world). You search for 1/16" FOOBARS . Your return will include some of those. And Foobar of other sizes, as well. And possibly things with 1/16" in their description. OK - so far it's the engine OR-ing the keywords. Not great but an acceptable choice on their part. How does that explain the hand sanitizer? Face Masks? Sandpaper? Note that I'm not logged in (where they keep track of previous purchases) and my browser deletes cookies, flash cookies, and history when it's closed. It's not looking into my dark and shady past. They seem to be just throwing random things into the search. Same thing, if one request the sort "Low to High Prices". Since when does $39.95 come between $3.99 and $4.29 ? I think by now I've made it clear - you search for something; they give a few of those and then push whatever else it is that they want to sell. Brick and Mortar? All is not yet lost !
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein
"If you are searching for perfection in others, then you seek disappointment. If you seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010
Funny enough, my buddy and I where on about this a little while back. It's NOT just the shopping sites, but the search experience in general, to whit, we came to the conclusion they are just NOT trying as hard as they used to, and are more interested (Esp the main search engines outside the market places) in putting results in front of you that they hope will lead you to buy things. I've lost count of the amount of searches in "Bing" and "Google" where I have been really, really specific, I mean "this phrase" AND "that phrase" "keyword" "keyword" "keyword" specific. And got back either a bunch of shopping results, or an instant "sorry nothing found and where not even gonna try" response. There was a time, when (Particularly with google) you could put in a general query, then spend a few minutes tweaking it, by enclosing some things in quotes and using operators like the minus symbol to exclude stuff, or filetype:xxx domain:blah.blah to filter stuff out you didn't want. And you could tell that your tweaking was doing a more through search because it took noticeably longer. Even google them selves documented it at one point stating that "if you fine tune your search, it cause the search engine to do a deeper more intensive search, that often reveals hits not in the general index" Now however, I'm increasingly seeing tweaks like this being ignored. Don't want those ads for some product or other to appear try -"keyword" and watch the ad still appear along with more just like it. It feels largely like the search engines leave the syntax in to make folks think they have control, but they ignore it anyway in favour of potential money making hits.
-
Now that you finished beating your chest, you seem to have fulfilled the promise of what appears to be a very narrow scope of vision: you cannot see the forest because the damn trees are in the way. Stop citing regulation and tell me, once and for all, how it matter how the data is (FP or one of your banking formats) will have any effect on a sort? And you keep harping on how I should google why FP is a bug – but it’s totally irrelevant to the real point. Similarly, you complain I only mentioned to forms of financial storage types – where did I claim any sort of exhaustive search? Oh – yes – a rocket scientist – beating your chest some more. I separated uranium isotopes on a table top in a tube 30cm long . . . roughly ten times better than the current stat of the art by mass based methodologies (gaseous diffusion, gas centrifuges, for example). So that make me a nuclear scientist? And that, part of the very earliest days of infrared laser photochemistry. Do you realize that neither that, nor your bomb-making credentials, mean shit to this argument. In fact, I would be quite ashamed to try to throw them out in any way as some sort of “so there! Gotcha !”. Still, there’s something to be learned from this pissing contest we’re in: something about staying on topic. I use FP because where I use it makes absolutely no difference. I use the numeric types that best match the native bandwidth of the processor I am targeting. If I perceive there will be a problem with one data type I’ll use one more appropriate – but it’s ludicrous to label something a bug because it doesn’t meet the particular standards of a totally unrelated consideration. How the hell would string a price as a FP digit hurt anything for Amazon? They use what they store, calculate the charges, surcharges (taxes), and shipping, and then the billing is done. The final value sent off for the accountants – who can do whatever the hell they want with it. And give it a thought: storing a unit price is not necessarily the same as storing currency.
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein
"If you are searching for perfection in others, then you seek disappointment. If you seek perfection in yourself, then you will find failure." - Balboos
Excuse me... The price of an item in an online store IS a currency value. It will be processed as monetary value when people do buy the item. So, yeah, don't use floating point in anywhere of it.
