I read precisely in his interview here that he had no more contact with the last version of Mega. I found this kind of curious, did some quick research, saw that the company was offering a quite good free package and opened an account which I have been using since then as secondary backup for a project which regularly generates an important amount of information. My experience so far has been quite good: simple Linux-/Windows-supported application, quickly and easily performing any sync (well... it has problems to properly recognise different disks on Linux, but the workaround is quite straightforward), no spam or any other kind of nagging, no privacy problems I am aware of, on-time alerts when getting out of free space (what happens every few weeks; as said, lots of info is being generated), etc.
What I have found kind of curious when doing some research about this company is that there isn't much information about it; basically, being included in some cloud rankings/reviews and new and Kim Dotcom. Is anyone else using mega.nz services or has any opinion/information to share? Also does anyone know how that Kim-Dotcom-out-of-the-company happened? How did this new version start anyway? Was he just giving the name and a visible face to an otherwise-unrelated-to-him company or had an active involvement in its creation?
Firstly, I am pretty sure that you have misunderstood most of my statements, you rely on quite a few absolute truths which are either completely wrong or inapplicable under quite a few scenarios and, as said, I have serious doubts regarding your background and motivations to talk to me. Secondly and even by ignoring the previous point, precisely the fact that you don't see this whole situation (= you considering that what I say is wrong, I am not considering that you know what you are talking about, but this going on anyway) as a clear indicative of this conversation not going anywhere seems a quite big problem.
Having control over each digit buys you nothing once you start calculating
This is precisely the whole point of having accurate results!! Each digit behaving as it should. You are still mixing up ideas!!! One thing is the inherent inaccuracy of incomplete decimal representations; a different story is the floating point problems which provoke digits to get wrong values!! For example, 1.23456789 being an imperfect representation of 1.23456789101112131415, but 1.23456723 being an error provoked by the floating point limitations!! Second time I repeat the same example and you continue proving that you haven't still got it!!!
1.0/3.0 + 1.0/3.0 + 1.0/3.0. If you get 1.0
Again!!! You are not understanding it!!!! You are showing the limitation of dealing with incomplete versions of decimal numbers (because the only way to perfectly represent 1/3 is by relying on its fractional form) and mixing it up with the difference between floating-point/non-floating numeric types. The most perfect decimal numerical type with the highest precision ever will not be able to represent 1/3 perfectly! You can have 0.3333333 or 0.33333333333333 or 0.333333333333333333333333333333333. All of them are imperfect and none of them have anything to do with the floating-point limitations!!! Something like 0.33333435 would be the typical floating point problem! Randomly wrong digits!!
I expressly said you that I don't want to continue this conversation and even highlighted my doubts regarding your behaviour; you have simply ignored all that and continued behaving in the same way!!! Why are you doing that?! You only have two options: either behaving in a compatible-with-me way (as explained quite a few times before) and talk to me or avoid dealing with me, but you choose the third, making-no-sense one. Why? Anyway, I will now seriously stop talking to you (now and in the future unless you change your behaviour completely). I haven't been able to refrain myself from answer you one last time because your example was sooooo descriptive of your misperception!!
This kind of replacing-people-is-easy plans usually underestimate the tremendous complexity associated with emulating most of human skills, mainly when dealing with dynamic, complex enough scenarios. Extremely simple problems intuitively solved by anyone in a split second might provoke a catastrophe when a not-trained-on-that-specific-event machine is in charge. Trains are certainly a huge over-simplification over cars, but this is precisely my point: under what might be considered extremely simple conditions self-driving (controlling a big object moving at high speed, sporadically having problems and/or interacting with other moving objects) isn't straightforward. And I am not just talking about strictly technical complexity, but also about cost (to earn what?!) and, much more importantly, risk. Fully replacing your asleepy train driver is far from easy.
Evidently, trains and cars are very different, but automating any long-stretch transportation systems does have quite a few aspects in common. In that regard, trains might be considered over-constrained cars and, as such, the "training wheels" for any serious self-driving attempt. At least, in an ideal world where long-term engineering concerns are the most important thing when dealing with these issues. It would also be impractical for other reasons like car manufacturers having little to do with train ones. But my post was mostly meant to highlight the huge complexity associated with these implementations (still problems to account for the much easier scenario) and the way in which proper engineering usually evolves as opposed to extrapolation-, marketing-based promises.
Trains are way much more self-driving friendly than cars and even though this is no piece of cake. After (if ever at all) autonomous trains have been tested and deployed at a large enough scale, we could assume that these approaches are reasonably mature at least under certain conditions. That would be the moment to start considering more difficult scenarios like cars. In fact, this is pretty much how the original evolution of these vehicles occurred: firstly, the highly-restricted trains and, only after having that technology working reasonably well, the fully unconstrained version (cars).
you should just go with regular floating-point. It's just as accurate (given enough precision), it's faster, and it's probably more predictable.
As previous said to you and to others before, it is a matter of context!!! If I need to have a full control on each single digit, I have to rely on decimal values and I am using a.NET language, I would certainly rely on decimal. In fact, I do rely on that type a lot in quite a few scenarios.
As you say, the decimal data type supports decimal places exactly. (Duh.) So, what's that useful for? If you use it for calculations in general, it's no more accurate than a regular floating-point number of adequate precision, and it's slower. It works great for financial calculations,
You are repeating your first sentences over and over, despite all my comments?! (like quite a few times before).
You really don't know much about floating-point, do you?
Where have you got that statement from what I wrote?! Seriously, what is the matter with you?! (not the first time I am saying this!).
Floating-point calculations are by nature inexact,
Seriously?
There is a discipline in computer science that deals with this, and that's what I mean when I refer to "numerics" people. You are obviously not one of them.
Why? Because you say so? A person unable to understand the few ideas I have written in my previous post.
As far as third-party code, if you're going to be consistent about it you'll have to write your own.NET runtime and program directly in its intermediate language, without using a compiler.
Why would I do such a thing? Aren't you seriously able to understand the difference between writing a whole algorithm yourself or relying on parts developed by others vs. being forced to trust whatever programming language (+ computer + building where you are coding + everything else!!).
Except for a couple of isolated cases, you have done pretty much the same quite a few times (10, 15 already?) before! Why?! You respond to one of my posts by saying that all/most of what I wrote is wrong and by repeating a set of ideas since the first moment until the end when I usually stop replying you?! Some times you seem to understand more or less fine some concepts and to have certain knowledge of certain aspects, but most of the times you are blindly repeating ideas which are partially or completely wrong and not even reading/understanding what I write?! It is like you having a conversation with yourself!! I am starting to have serious doubts regarding your background and motivations (to talk to me). Now, I will stop talking to you and will not be understanding in the future. The next time you will start your routine and show an even slightly weird-to-me behaviour, I would stop replying you right away and without saying anything else.
Exact decimal representations only work if all the numbers are exactly representable in a decimal representation of bounded length. That isn't the case with something as simple as 1.0/3.0.
Logically. But this isn't what the floating-point problem is about. Imagine that the real value is 0.12345679101112131415 (...) and that getting up to the 8th decimal position is acceptable under the given conditions, a floating-point type might mess this number up and deliver something like 0.12345621, unlikely a non-floating-point type which will always deliver 0.12345678.
The decimal numbers are primarily designed for financial calculations
Certain not. Similarly to what happens with pretty much everything else, there are tons of other scenarios where this might become useful. Trivial examples are most of trigonometrical calculations which involve Pi. As explained in some other comments, you (meaning a competent programmer) should understand properly the situation and deliver the best solution under the given conditions, what includes meeting the expected accuracy within the given precision, input conditions and further issues.
What the decimal types you mention do is be inexact in the exact same way financial calculations were done by hand
Not sure what you mean with that, but the aforementioned decimal types deliver a perfect representation of the given number up to the maximum supported precision (around 25 decimal positions). So and unlikely what had happened with the floating-point alternatives (the main one in the.NET languages is double), the aforementioned sample representation of a decimal number would be stored and dealt with perfectly (= all its 20 relevant decimal digits will always be considered).
Floating-point error is almost inevitable, no matter the skill of the programmer
Inaccurate or, at least, misleading statement. Floating point errors are unpredictable (or, at least, difficult, not cheaply predictable) and uncorrectable (same clarification than before), but they happen within a relatively-known range and that's why they are controllable. A proper programmer working on a development where up-to-the-last-digit accuracy is very important should be perfectly aware about all that and only deal with floating-point types when being completely sure that no error would be provoked. I have never developed a piece of software failing because of a floating-point error + said that this was unavoidable rather than my full responsibility and am quite sure that will never do. Same ideas are applicable to SQ-injection-vulnerable code, wrong memory allocations or any other scenario involving not properly understanding and caring about all the possible conditions. I can certainly make mistakes, but will always accept the associated responsibility (= I am the one to blame, not the programming language/software as a whole).
and most people just use the algorithms the numerics people recommend
I don't know who these numerics people are, but in principle I could consider myself one of them. And I recommend you the same than with any other kind of algorithm: have full control over all the I/O, potential scenarios or anything else which is expected to affect it. If you rely on third party codes, you should accept the consequences and wish that their developers do apply these ideas. In any case, whatever error on these lines (= not provoked by extreme conditions like bugs in the programming language or computer) is certainly avoidable + responsibility of its author; anyone telling you otherwise is either lying or isn't competent/knowledgeable or isn't working under the best conditions (e.g., unmotivatedly rushed milestones and similar managerial nonsense).
I don't think that you should feel in that way either. Big companies have a positive impact on economies and lots of people work for them. The idea is to not get fooled into believing that there aren't other alternatives or that they really care about you (their positive impact is just an unintended side effect which they might even avoid if they could) or that changing your routines is difficult.
Would you like to help small business, but big companies offer you something notably better? Buy from big companies most of the things, mainly the expensive stuff. No need to feel bad about it. Is the quality delivered by certain big company getting gradually worse (or having policies you don't like on whatever front) but you keep using it anyway? In that case, perhaps you should try some other options and you might be surprised.
But there are costs in every choice. Usually that's a bad idea,
What you are suggesting then? Relying on a faulty approach when you do need to have the maximum precision? Floating point types exist because they are fine for most of scenarios, but there might be cases where their limitations aren't acceptable and the given programmer would have to come up with the best solution under the given conditions.
The person developing a program sending a rocket to the wrong place was undoubtedly responsible. If certain precision was required, that person would have had to rely on whatever methodology to accomplish it (+ eventually sacrifice any side advantage like ease of implementation or performance). If in the given conditions there is no way to accomplish whatever goal under whatever conditions, you would have to accept it. It might be slower, harder to developer or whatever, but sending a rocket (or performing whatever other actions) within the expected precision is extremely likely to be doable and, consequently, that error is programmer's (or manager's or client's or whoever-made-the-final-decision's) fault.
Is it appropriate to represent a year with two digits? These days the answer is clearly no, but 40 years ago the answer was
I am not saying otherwise! As said above, for most of scenarios, you don't need even to care about floating-point precision problems (who cares about what happens in the 10th decimal position!!), that's why this is a widely used numerical type. But that person in that development should have taken into account the accuracy peculiarities. Exactly the same that a person developing nowadays a piece of software dealing with years shouldn't just account for 2 digits.
On the other hand, people's knowledge, resources, past problems, etc. aren't the same everyime and everywhere. What is evident today might not have been too clear some years ago. But again this is a matter of context and this is exactly were my words are expected to be understood: creating a new programming approach (this one or any other one) is rarely the solution for whatever problem, but properly knowing how to deal with the given environment and conditions. Theoretically, the developer is always the one to be blamed, but usually that blame has to be properly understood within the given situation (would have other person under equivalent conditions done the same?).
say I write it for a 32 bit CPU, and someone migrates that code to a 16 bit CPU (this is a guess, not what happened) is that my fault?
This seems like a quite extreme scenario, but the answer would be it depends: was you being aware about that eventuality (your software having a relevant floating-point dependence and being potentially used under different conditions) part of your due diligence? Because if you are developing a piece of software to calculate the coordinates where a rocket has to land, where each digit is relevant and you blindly use a type who has well-known limitations on this front without deeply testing the approach, it would sound quite negligent to me. But for over 99% of the all the possible developments, not caring about floating-point limitations seems even the usual proceeding. As said, below 5-7 decimal digits, everything should be fine.
Sorry, but while it could be the programmer's fault, this isn't certain.
There is something definitively certain: errors should be expected. You can do some tests under the given conditions to see the more common upper limits and go down a couple of digits to play safe. Within the 5-7 decimal digits range everything tends to work fine with eventually some rarely-problematic 0.9999 rather than 1.0 situations. Alternatively, you might use different approaches to get an almost perfect precision under virtually any scenario; logically, at some expense like everything else, including hiring more competent programmers.
Programming languages/algorithms allow tons of different ways to accomplish the same thing and there is always some uncontrollable-error-free option. So and unless under extremely unlikely conditions (programming language in-built problem), all the programming errors are the given developer's fault. On the other hand, some situations can be really complex and human errors might be somehow excusable, but this cannot justify ideas on the lines of "let's avoid future errors by modifying the programming language". You can certainly improve the programming experience, but a developer being perfectly aware about the given conditions will always be the best way to deliver reliable software.
Various thoughts about the claims in the summary, title and article:
- There are some numeric decimal types which allow a perfect precision like the.NET decimal types (C# decimal and VB.NET Decimal). Logically, there are other problems associated with these types as far as the floating point limitations aren't absolutely unavoidable, but outcomes of the pursued goal (= big values by consuming as less resources as possible).
- This approach doesn't seem to try to avoid the default problems as the aforementioned types, but just to warn about potential inaccuracies. According to the linked article:
The innovative bounded floating point system computes two limits (or bounds) that contain the represented real number. These bounds are carried through successive calculations. When the calculated result is no longer sufficiently accurate the result is so marked, as are all further calculations made using that value.
- Any floating-point-type error is certainly programmer's fault as far as being aware about these limitations is part of the basic knowledge which someone working with big decimal values should posses. So, avoiding problems like the one referred by the quote below these lines doesn't require a programming structure re-definition, just a competent developer.
the most notorious floating point error was the Patriot missile failure in Saudi Arabia...
I was about to invest all my money in this, but not being a panacea is quite off-putting. I guess that I will have to continue focusing on buying discount bridges and managing the overseas money of nice strangers who sporadically get in touch in me. LOL.
On a more serious note, I am all for open-/community-based alternatives, but agree with some of the previous posters on this specific scenario being particularly difficult. Another option would be consumer pressure gradually forcing hardware manufacturers to be more open, although this seems quite difficult too.
Their users are the ones really in charge and the ones who should force any company to behave properly. Clients shouldn't be hysterical fans, members of cults or suckers blindly believing that (big) companies really care about them. Users shouldn't be understanding with even the slightest problem and actively contribute towards creating a monopoly-free internet/world; they might, for example, try to use as many alternatives as possible or make worldwide legislations restrict their activity.
Big internet companies behave as they do because their users allow them to do so. There are many different options, changing almost any aspect of your online/computer activity is quite easy and your voice can easily be heard by a relevant number of others. Motivatedly critise, don't buy into their loyalty crap and never forget that they get paid to give you exactly what you want. Same ideas apply to any other entity trying to trick you into misunderstanding the reality master-slave (logically, never seriously applicable between human beings, but between people and what is meant to serve them) like governments, legislators, banks, groups-of-economists-or-other-lobbies-wanting-to-rule-whatever or similar.
Anyone could certainly create any drug or good available in the market, but this is impractical for many reasons like price, raw material availability, usual low flexibility of manufacturing processes, etc. to not mention other issues like patents or even legal prohibitions.
This reminds me the time when I jokily said to some (extremely naive, detached-from-reality) people that I was planning to create a company to sell drugs. The most surprising bit wasn't they blindly believing such a nonsense, but seriously thinking that that scenario could occur at all. I mean people whose knowledge about something mostly consist in extrapolating the few ideas they have from sources like movies or out-of-context news. I guess that everyone is a bit like this at some point and for different reasons. Properly-speaking people learn from their errors and accept the limitations of their knowledge. In-denial souls/true suckers/fanatics blindly stick to their distorted perception of reality and even use it as starting step to come up with further nonsensical ideas.
Actually, this statement isn't completely true. I did have an iPod for a while, but then I moved to iPud (or whatever the name, a crappy brand poorly emulating iPod) and later to nothing (= hearing music on my computer, phone or similar).
PS: I have never used Apple products myself (and bear in mind that I am a programmer who has developed software under many different conditions with caring too much about specific environments, but who happen to have never dealt with Apple-related anything!), apparently they only have 8% of desktop market share and, although there is a relevant number of Apple-related articles here lately, the Slashdot crowd seems to be mostly focused on Linux (or even Windows before Apple). Why even mentioning Apple under a priori so Apple-unfriendly conditions? Please, don't take this comment bad, I am just highlighting an issue which I found quite curious.
will not happen on your machine unless you update your bios. Of course, Apple
OK. I am not too sure about how my current operating system (Ubuntu) and computer (no brand, just different parts put together) deal with BIOS updates. In principle, it should be done manually or by showing a very clear warning + me having the last word, but who knows for sure? Anyway and as said, in case of being able to choose, I wouldn't install it.
You are making a pretty good point, but practically speaking the requirements for implementing both alternatives seem still way off. Also bear in mind that images contain orders of magnitude more information than plain text, what means excellent conditions to create very strong encryptions.
The system you propose could be way harder to crack, but also to train (not just making sure that the algorithm behaves as you want, but also hiding any suspicious activity from Google). The strongest point of image-based encryption, at least when properly done, is the difficulty to even know whether there is encrypted information there at all. That's why I think that, if you are able to set up a proper image-based communication, the strength of the encryption algorithm wouldn't be one of your main concerns.
Although theoretically possible, the scenario you propose seems too complex to ever become a reality. It would be much easier to create a picture-based encryption system; in fact, I developed one of those some time ago.
If my brand new computer gets damaged in any way because of this, I would be quite upset. Actually, if I could choose, I wouldn't even install the patch. I understand that hardware vendors have to account for any the possible scenario (mainly after having got so much advertisement!), but seriously doubt that anything of this will ever affect me.
As a way to improve visibility and minimise the GitHub power, setting up mirrored repositories in sites like SourceForge sounds good to me. In fact, I did try to do something like that about 1 year ago, but the syncing wasn't working as expected. The part of easily importing all the information from GitHub was fine, but the part of SourceForge automatically updating any modification there wasn't. Without that working properly, there was no point in having the repositories duplicated and I deleted my SourceForge account.
After a quick look now, they seem to have done just some aesthetical modifications, although the pages seem to load a bit slower. The GitHub sync information doesn't include any express mention to the aforementioned issue of keeping automatically updating the repositories. I might give them another shot at some point, but I would use SourceForge only if that functionality is implemented. Actually, I think that they should better put their main focus on these lines of accepting that, for the time being, they are a secondary player with a good visibility what potentially makes them an excellent GitHub mirror/backup alternative.
Slashdot Mirror
I read precisely in his interview here that he had no more contact with the last version of Mega. I found this kind of curious, did some quick research, saw that the company was offering a quite good free package and opened an account which I have been using since then as secondary backup for a project which regularly generates an important amount of information. My experience so far has been quite good: simple Linux-/Windows-supported application, quickly and easily performing any sync (well... it has problems to properly recognise different disks on Linux, but the workaround is quite straightforward), no spam or any other kind of nagging, no privacy problems I am aware of, on-time alerts when getting out of free space (what happens every few weeks; as said, lots of info is being generated), etc.
What I have found kind of curious when doing some research about this company is that there isn't much information about it; basically, being included in some cloud rankings/reviews and new and Kim Dotcom. Is anyone else using mega.nz services or has any opinion/information to share? Also does anyone know how that Kim-Dotcom-out-of-the-company happened? How did this new version start anyway? Was he just giving the name and a visible face to an otherwise-unrelated-to-him company or had an active involvement in its creation?
You're wrong about a lot of things.
Firstly, I am pretty sure that you have misunderstood most of my statements, you rely on quite a few absolute truths which are either completely wrong or inapplicable under quite a few scenarios and, as said, I have serious doubts regarding your background and motivations to talk to me. Secondly and even by ignoring the previous point, precisely the fact that you don't see this whole situation (= you considering that what I say is wrong, I am not considering that you know what you are talking about, but this going on anyway) as a clear indicative of this conversation not going anywhere seems a quite big problem.
Having control over each digit buys you nothing once you start calculating
This is precisely the whole point of having accurate results!! Each digit behaving as it should. You are still mixing up ideas!!! One thing is the inherent inaccuracy of incomplete decimal representations; a different story is the floating point problems which provoke digits to get wrong values!! For example, 1.23456789 being an imperfect representation of 1.23456789101112131415, but 1.23456723 being an error provoked by the floating point limitations!! Second time I repeat the same example and you continue proving that you haven't still got it!!!
1.0/3.0 + 1.0/3.0 + 1.0/3.0. If you get 1.0
Again!!! You are not understanding it!!!! You are showing the limitation of dealing with incomplete versions of decimal numbers (because the only way to perfectly represent 1/3 is by relying on its fractional form) and mixing it up with the difference between floating-point/non-floating numeric types. The most perfect decimal numerical type with the highest precision ever will not be able to represent 1/3 perfectly! You can have 0.3333333 or 0.33333333333333 or 0.333333333333333333333333333333333. All of them are imperfect and none of them have anything to do with the floating-point limitations!!! Something like 0.33333435 would be the typical floating point problem! Randomly wrong digits!!
I expressly said you that I don't want to continue this conversation and even highlighted my doubts regarding your behaviour; you have simply ignored all that and continued behaving in the same way!!! Why are you doing that?! You only have two options: either behaving in a compatible-with-me way (as explained quite a few times before) and talk to me or avoid dealing with me, but you choose the third, making-no-sense one. Why? Anyway, I will now seriously stop talking to you (now and in the future unless you change your behaviour completely). I haven't been able to refrain myself from answer you one last time because your example was sooooo descriptive of your misperception!!
This kind of replacing-people-is-easy plans usually underestimate the tremendous complexity associated with emulating most of human skills, mainly when dealing with dynamic, complex enough scenarios. Extremely simple problems intuitively solved by anyone in a split second might provoke a catastrophe when a not-trained-on-that-specific-event machine is in charge. Trains are certainly a huge over-simplification over cars, but this is precisely my point: under what might be considered extremely simple conditions self-driving (controlling a big object moving at high speed, sporadically having problems and/or interacting with other moving objects) isn't straightforward. And I am not just talking about strictly technical complexity, but also about cost (to earn what?!) and, much more importantly, risk. Fully replacing your asleepy train driver is far from easy.
has nothing at all to do with cars
Evidently, trains and cars are very different, but automating any long-stretch transportation systems does have quite a few aspects in common. In that regard, trains might be considered over-constrained cars and, as such, the "training wheels" for any serious self-driving attempt. At least, in an ideal world where long-term engineering concerns are the most important thing when dealing with these issues. It would also be impractical for other reasons like car manufacturers having little to do with train ones. But my post was mostly meant to highlight the huge complexity associated with these implementations (still problems to account for the much easier scenario) and the way in which proper engineering usually evolves as opposed to extrapolation-, marketing-based promises.
Trains are way much more self-driving friendly than cars and even though this is no piece of cake. After (if ever at all) autonomous trains have been tested and deployed at a large enough scale, we could assume that these approaches are reasonably mature at least under certain conditions. That would be the moment to start considering more difficult scenarios like cars. In fact, this is pretty much how the original evolution of these vehicles occurred: firstly, the highly-restricted trains and, only after having that technology working reasonably well, the fully unconstrained version (cars).
you should just go with regular floating-point. It's just as accurate (given enough precision), it's faster, and it's probably more predictable.
As previous said to you and to others before, it is a matter of context!!! If I need to have a full control on each single digit, I have to rely on decimal values and I am using a .NET language, I would certainly rely on decimal. In fact, I do rely on that type a lot in quite a few scenarios.
As you say, the decimal data type supports decimal places exactly. (Duh.) So, what's that useful for? If you use it for calculations in general, it's no more accurate than a regular floating-point number of adequate precision, and it's slower. It works great for financial calculations,
You are repeating your first sentences over and over, despite all my comments?! (like quite a few times before).
You really don't know much about floating-point, do you?
Where have you got that statement from what I wrote?! Seriously, what is the matter with you?! (not the first time I am saying this!).
Floating-point calculations are by nature inexact,
Seriously?
There is a discipline in computer science that deals with this, and that's what I mean when I refer to "numerics" people. You are obviously not one of them.
Why? Because you say so? A person unable to understand the few ideas I have written in my previous post.
As far as third-party code, if you're going to be consistent about it you'll have to write your own .NET runtime and program directly in its intermediate language, without using a compiler.
Why would I do such a thing? Aren't you seriously able to understand the difference between writing a whole algorithm yourself or relying on parts developed by others vs. being forced to trust whatever programming language (+ computer + building where you are coding + everything else!!).
Except for a couple of isolated cases, you have done pretty much the same quite a few times (10, 15 already?) before! Why?! You respond to one of my posts by saying that all/most of what I wrote is wrong and by repeating a set of ideas since the first moment until the end when I usually stop replying you?! Some times you seem to understand more or less fine some concepts and to have certain knowledge of certain aspects, but most of the times you are blindly repeating ideas which are partially or completely wrong and not even reading/understanding what I write?! It is like you having a conversation with yourself!! I am starting to have serious doubts regarding your background and motivations (to talk to me). Now, I will stop talking to you and will not be understanding in the future. The next time you will start your routine and show an even slightly weird-to-me behaviour, I would stop replying you right away and without saying anything else.
Exact decimal representations only work if all the numbers are exactly representable in a decimal representation of bounded length. That isn't the case with something as simple as 1.0/3.0.
Logically. But this isn't what the floating-point problem is about. Imagine that the real value is 0.12345679101112131415 (...) and that getting up to the 8th decimal position is acceptable under the given conditions, a floating-point type might mess this number up and deliver something like 0.12345621, unlikely a non-floating-point type which will always deliver 0.12345678.
The decimal numbers are primarily designed for financial calculations
Certain not. Similarly to what happens with pretty much everything else, there are tons of other scenarios where this might become useful. Trivial examples are most of trigonometrical calculations which involve Pi. As explained in some other comments, you (meaning a competent programmer) should understand properly the situation and deliver the best solution under the given conditions, what includes meeting the expected accuracy within the given precision, input conditions and further issues.
What the decimal types you mention do is be inexact in the exact same way financial calculations were done by hand
Not sure what you mean with that, but the aforementioned decimal types deliver a perfect representation of the given number up to the maximum supported precision (around 25 decimal positions). So and unlikely what had happened with the floating-point alternatives (the main one in the .NET languages is double), the aforementioned sample representation of a decimal number would be stored and dealt with perfectly (= all its 20 relevant decimal digits will always be considered).
Floating-point error is almost inevitable, no matter the skill of the programmer
Inaccurate or, at least, misleading statement. Floating point errors are unpredictable (or, at least, difficult, not cheaply predictable) and uncorrectable (same clarification than before), but they happen within a relatively-known range and that's why they are controllable. A proper programmer working on a development where up-to-the-last-digit accuracy is very important should be perfectly aware about all that and only deal with floating-point types when being completely sure that no error would be provoked. I have never developed a piece of software failing because of a floating-point error + said that this was unavoidable rather than my full responsibility and am quite sure that will never do. Same ideas are applicable to SQ-injection-vulnerable code, wrong memory allocations or any other scenario involving not properly understanding and caring about all the possible conditions. I can certainly make mistakes, but will always accept the associated responsibility (= I am the one to blame, not the programming language/software as a whole).
and most people just use the algorithms the numerics people recommend
I don't know who these numerics people are, but in principle I could consider myself one of them. And I recommend you the same than with any other kind of algorithm: have full control over all the I/O, potential scenarios or anything else which is expected to affect it. If you rely on third party codes, you should accept the consequences and wish that their developers do apply these ideas. In any case, whatever error on these lines (= not provoked by extreme conditions like bugs in the programming language or computer) is certainly avoidable + responsibility of its author; anyone telling you otherwise is either lying or isn't competent/knowledgeable or isn't working under the best conditions (e.g., unmotivatedly rushed milestones and similar managerial nonsense).
I feel guilty
I don't think that you should feel in that way either. Big companies have a positive impact on economies and lots of people work for them. The idea is to not get fooled into believing that there aren't other alternatives or that they really care about you (their positive impact is just an unintended side effect which they might even avoid if they could) or that changing your routines is difficult.
Would you like to help small business, but big companies offer you something notably better? Buy from big companies most of the things, mainly the expensive stuff. No need to feel bad about it. Is the quality delivered by certain big company getting gradually worse (or having policies you don't like on whatever front) but you keep using it anyway? In that case, perhaps you should try some other options and you might be surprised.
Did you mean to say, "(= big values by consuming as few resources as possible)"? You're welcome.
Thanks for the remark, other AC. I will try to repay your noble action by pointing out that the comma in "did you mean to say, whatever" is wrong.
But there are costs in every choice. Usually that's a bad idea,
What you are suggesting then? Relying on a faulty approach when you do need to have the maximum precision? Floating point types exist because they are fine for most of scenarios, but there might be cases where their limitations aren't acceptable and the given programmer would have to come up with the best solution under the given conditions.
The person developing a program sending a rocket to the wrong place was undoubtedly responsible. If certain precision was required, that person would have had to rely on whatever methodology to accomplish it (+ eventually sacrifice any side advantage like ease of implementation or performance). If in the given conditions there is no way to accomplish whatever goal under whatever conditions, you would have to accept it. It might be slower, harder to developer or whatever, but sending a rocket (or performing whatever other actions) within the expected precision is extremely likely to be doable and, consequently, that error is programmer's (or manager's or client's or whoever-made-the-final-decision's) fault.
Is it appropriate to represent a year with two digits? These days the answer is clearly no, but 40 years ago the answer was
I am not saying otherwise! As said above, for most of scenarios, you don't need even to care about floating-point precision problems (who cares about what happens in the 10th decimal position!!), that's why this is a widely used numerical type. But that person in that development should have taken into account the accuracy peculiarities. Exactly the same that a person developing nowadays a piece of software dealing with years shouldn't just account for 2 digits.
On the other hand, people's knowledge, resources, past problems, etc. aren't the same everyime and everywhere. What is evident today might not have been too clear some years ago. But again this is a matter of context and this is exactly were my words are expected to be understood: creating a new programming approach (this one or any other one) is rarely the solution for whatever problem, but properly knowing how to deal with the given environment and conditions. Theoretically, the developer is always the one to be blamed, but usually that blame has to be properly understood within the given situation (would have other person under equivalent conditions done the same?).
say I write it for a 32 bit CPU, and someone migrates that code to a 16 bit CPU (this is a guess, not what happened) is that my fault?
This seems like a quite extreme scenario, but the answer would be it depends: was you being aware about that eventuality (your software having a relevant floating-point dependence and being potentially used under different conditions) part of your due diligence? Because if you are developing a piece of software to calculate the coordinates where a rocket has to land, where each digit is relevant and you blindly use a type who has well-known limitations on this front without deeply testing the approach, it would sound quite negligent to me. But for over 99% of the all the possible developments, not caring about floating-point limitations seems even the usual proceeding. As said, below 5-7 decimal digits, everything should be fine.
Sorry, but while it could be the programmer's fault, this isn't certain.
There is something definitively certain: errors should be expected. You can do some tests under the given conditions to see the more common upper limits and go down a couple of digits to play safe. Within the 5-7 decimal digits range everything tends to work fine with eventually some rarely-problematic 0.9999 rather than 1.0 situations. Alternatively, you might use different approaches to get an almost perfect precision under virtually any scenario; logically, at some expense like everything else, including hiring more competent programmers.
Programming languages/algorithms allow tons of different ways to accomplish the same thing and there is always some uncontrollable-error-free option. So and unless under extremely unlikely conditions (programming language in-built problem), all the programming errors are the given developer's fault. On the other hand, some situations can be really complex and human errors might be somehow excusable, but this cannot justify ideas on the lines of "let's avoid future errors by modifying the programming language". You can certainly improve the programming experience, but a developer being perfectly aware about the given conditions will always be the best way to deliver reliable software.
- There are some numeric decimal types which allow a perfect precision like the
- This approach doesn't seem to try to avoid the default problems as the aforementioned types, but just to warn about potential inaccuracies. According to the linked article:
The innovative bounded floating point system computes two limits (or bounds) that contain the represented real number. These bounds are carried through successive calculations. When the calculated result is no longer sufficiently accurate the result is so marked, as are all further calculations made using that value.
- Any floating-point-type error is certainly programmer's fault as far as being aware about these limitations is part of the basic knowledge which someone working with big decimal values should posses. So, avoiding problems like the one referred by the quote below these lines doesn't require a programming structure re-definition, just a competent developer.
the most notorious floating point error was the Patriot missile failure in Saudi Arabia...
I was about to invest all my money in this, but not being a panacea is quite off-putting. I guess that I will have to continue focusing on buying discount bridges and managing the overseas money of nice strangers who sporadically get in touch in me. LOL.
On a more serious note, I am all for open-/community-based alternatives, but agree with some of the previous posters on this specific scenario being particularly difficult. Another option would be consumer pressure gradually forcing hardware manufacturers to be more open, although this seems quite difficult too.
Their users are the ones really in charge and the ones who should force any company to behave properly. Clients shouldn't be hysterical fans, members of cults or suckers blindly believing that (big) companies really care about them. Users shouldn't be understanding with even the slightest problem and actively contribute towards creating a monopoly-free internet/world; they might, for example, try to use as many alternatives as possible or make worldwide legislations restrict their activity.
Big internet companies behave as they do because their users allow them to do so. There are many different options, changing almost any aspect of your online/computer activity is quite easy and your voice can easily be heard by a relevant number of others. Motivatedly critise, don't buy into their loyalty crap and never forget that they get paid to give you exactly what you want. Same ideas apply to any other entity trying to trick you into misunderstanding the reality master-slave (logically, never seriously applicable between human beings, but between people and what is meant to serve them) like governments, legislators, banks, groups-of-economists-or-other-lobbies-wanting-to-rule-whatever or similar.
custom built the hardware and are running Ubuntu, you do not have to worry about automatically getting the microcode update from Intel.
OK. Thanks for the info.
Anyone could certainly create any drug or good available in the market, but this is impractical for many reasons like price, raw material availability, usual low flexibility of manufacturing processes, etc. to not mention other issues like patents or even legal prohibitions.
This reminds me the time when I jokily said to some (extremely naive, detached-from-reality) people that I was planning to create a company to sell drugs. The most surprising bit wasn't they blindly believing such a nonsense, but seriously thinking that that scenario could occur at all. I mean people whose knowledge about something mostly consist in extrapolating the few ideas they have from sources like movies or out-of-context news. I guess that everyone is a bit like this at some point and for different reasons. Properly-speaking people learn from their errors and accept the limitations of their knowledge. In-denial souls/true suckers/fanatics blindly stick to their distorted perception of reality and even use it as starting step to come up with further nonsensical ideas.
I have never used Apple products myself
Actually, this statement isn't completely true. I did have an iPod for a while, but then I moved to iPud (or whatever the name, a crappy brand poorly emulating iPod) and later to nothing (= hearing music on my computer, phone or similar).
My "with caring too much" should be understood as "without caring too much".
PS: I have never used Apple products myself (and bear in mind that I am a programmer who has developed software under many different conditions with caring too much about specific environments, but who happen to have never dealt with Apple-related anything!), apparently they only have 8% of desktop market share and, although there is a relevant number of Apple-related articles here lately, the Slashdot crowd seems to be mostly focused on Linux (or even Windows before Apple). Why even mentioning Apple under a priori so Apple-unfriendly conditions? Please, don't take this comment bad, I am just highlighting an issue which I found quite curious.
will not happen on your machine unless you update your bios. Of course, Apple
OK. I am not too sure about how my current operating system (Ubuntu) and computer (no brand, just different parts put together) deal with BIOS updates. In principle, it should be done manually or by showing a very clear warning + me having the last word, but who knows for sure? Anyway and as said, in case of being able to choose, I wouldn't install it.
You are making a pretty good point, but practically speaking the requirements for implementing both alternatives seem still way off. Also bear in mind that images contain orders of magnitude more information than plain text, what means excellent conditions to create very strong encryptions.
The system you propose could be way harder to crack, but also to train (not just making sure that the algorithm behaves as you want, but also hiding any suspicious activity from Google). The strongest point of image-based encryption, at least when properly done, is the difficulty to even know whether there is encrypted information there at all. That's why I think that, if you are able to set up a proper image-based communication, the strength of the encryption algorithm wouldn't be one of your main concerns.
Although theoretically possible, the scenario you propose seems too complex to ever become a reality. It would be much easier to create a picture-based encryption system; in fact, I developed one of those some time ago.
If my brand new computer gets damaged in any way because of this, I would be quite upset. Actually, if I could choose, I wouldn't even install the patch. I understand that hardware vendors have to account for any the possible scenario (mainly after having got so much advertisement!), but seriously doubt that anything of this will ever affect me.
Good to know. I will mirror my main GitHub repositories as soon as this functionality is implemented.
As a way to improve visibility and minimise the GitHub power, setting up mirrored repositories in sites like SourceForge sounds good to me. In fact, I did try to do something like that about 1 year ago, but the syncing wasn't working as expected. The part of easily importing all the information from GitHub was fine, but the part of SourceForge automatically updating any modification there wasn't. Without that working properly, there was no point in having the repositories duplicated and I deleted my SourceForge account.
After a quick look now, they seem to have done just some aesthetical modifications, although the pages seem to load a bit slower. The GitHub sync information doesn't include any express mention to the aforementioned issue of keeping automatically updating the repositories. I might give them another shot at some point, but I would use SourceForge only if that functionality is implemented. Actually, I think that they should better put their main focus on these lines of accepting that, for the time being, they are a secondary player with a good visibility what potentially makes them an excellent GitHub mirror/backup alternative.