Pretty much how all investing works. Higher risks usually mean higher gains and losses. Bitcoin and other cryptocurrencies are just another vehicle for doing what humans have been doing for centuries.
That seems a good summary. Regardless of its technical resemblance, this is simply a new investing alternative and, as such, only relevant for people caring about investments. As said, I have no interest in all this either directly (investing) or indirectly (focusing my activity as a programmer/engineer on this sub-field). Thanks for the comment though.
I was half hoping you'd shut me up with some nice technical way around the problem...
Impressive 180-turn attitude change! Well, as answered to other commentator right now, I am personally a fan of approaches on the lines of multiple attempts + averaging the results for proper empirical validation. For example, a way to confirm/dismiss/improve that much more realistic 1 in 200 estimate, I would go with 10 sets of tests up to either 200 or the second error. So, if in the first set, you get the second error at the 150 attempt, you stop there; if in the second set, you reach 200 without a second error, you stop there, etc. You average all these results and get your conclusion. Then, you should repeat that process quite a few more times under different conditions and keep averaging the results for an increasingly better accuracy. But you should also make an extra-effort to not mix up different conditions (or, at least, properly weighting them; although this is usually a more complicated alternative), what might inadvertently affect the reliability in a very relevant way. The whole system could also be systematically further tuned via replacing that initial 200 limit with the newly validated conclusions you keep getting. So, basically an iterative ad infinitum proceeding whose accuracy is mostly conditioned by the time/effort you want to spend on it, but which can also deliver as many (reasonably good) intermediate conclusions as you want.
Actually, GP is correct if we're resorting to empirical testing.
Not even in that scenario. Even in case that you carried those 211 quintillion tests out, it wouldn't represent a reliable validation of the claim "1 in 211 quintillion" because just one empirical confirmation isn't statically significant (and this is, from the point of view of that claim, what performing the whole 211 quintillion test once would mean). If you want to go down such a ridiculous unnecessarily over-working path and you want to do it properly, you would have to rely on a much better methodology on the lines of repeating the process various times (at least, 5 times?) and averaging the value. So, if you perform the 211 quintillion tests 5 times and each of these times you get only 1 error, then you would certainly be in a position to undoubtedly conclude that the original statement was, beyond any doubt, accurate. But nobody in their right mind would ever tried to do such a nonsense to validate a meaning-nothing commercial nonsense.
We would want about six hundred quintillion samples to test against to verify that.
This is not what the intended verification was meant to be. And in any case, this isn't how you would even validate that claim. That quintillion reference is clearly an extrapolated estimation (= commercial language) which could be confirmed/dismissed by relying on equivalent means; that is, testing a much smaller number of samples and applying whatever "methodology" they used to come up with that number. But again this isn't what releasing the source code/not is about; what we are discussing here is about making sure that the piece of software works as expected and, eventually, accurately calculate its actual reliability according to whatever expectations the given court/governmental entity/legislation considers that are good enough; this isn't about confirming whatever random claim the company does.
TL;DR: the ridiculous claim of that company is irrelevant from the software validation/source code release point of view; but, even in case of deciding to empirically validate such a nonsense, the proceeding proposed by the previous poster isn't reliable enough.
I'm a software developer, and I'm frequently not sure beyond a reasonable doubt about software I personally have written, let alone other people's software.
I am also a software developer and I have no doubts while analysing the code I wrote, any other properly-commented/structured code or even a horrible code, but all this assuming that I can invest enough time/effort. This is precisely my whole point since the start (is seriously so difficult to just understand what is clearly written?): analysing code is a less efficient alternative than testing the corresponding program under the most common conditions and certainly when dealing with a so complex piece of software like the one being referred here. That's why the first title: "it makes more sense theoretically than practically".
I will better write here one of my there-are-way-too-many-stupid-people-unable-to-understand-even-the-simplest-idea over-clarifications: when talking about two different languages a false friend refers to two similar words with completely different meanings. Although I have a reasonably good English knowledge, it is still my second language and, when dealing with words/expressions of fields outside my main expertise, what I usually do/like/etc. (e.g., anything related to finance, economics, banking, etc.), some false friend might slip through. In Spanish, "comisión" means both commission and fee (or, in this context, exchange/conversion rate) and that's why I intuitively wrote "commission" even despite being fully aware about the fact that this is wrong in English; the reason why I quickly corrected it via the previous above.
So the article claims a false positive rate of 1 in 211 quintillion for a particular trial.
I didn't read the article, but that or any other issue doesn't change anything. If you aren't able to define accurate enough conditions to validate the corresponding piece of software, you would fail to do so anyway. Testing is much more likely to be quicker and more efficient than the alternative approach of analysing the code. Or do you think that by having access to the code you can guess what might be the output under so extreme conditions? If this was so, what would have been the point of having a piece of software in the first place if just by looking at the algorithm you can intuitively get the result?!
To test that with a 95% confidence interval we would need at least 600 quintillion samples.
No. This is not what the first statement means. And again, if you preferred to interpret it in that way and to analyse a so ridiculously big and completely unnecessary number of samples, I would recommend you to do it by running that software rather than by manually analysing the algorithm.
I don't think Earth could support this many people so we need to colonize other planets. To make things simple, lets assume the average planet can support 10 billion people. Therefore, we need to colonize roughly 60 billion planets and test everyone on those planets. I think we can do that without leaving the Milky Way galaxy, so we should be OK.
Out of all your ridiculous statements so far, this is my favourite one. Are you saying me that if you had to (manually) test 600 quintillion DNA samples, you would get them from 600 quintillion different people?! LOOOOOOOOL. You, this-can-be-solved-by-scaling-it-up guys, are too much for me! So, let's sum up your masterpiece so far: 1. You have a situation about which you clearly don't have even a slight understanding (or perhaps you are being consciously dishonest/partial for whatever reason; because properly understanding all this doesn't seem that difficult for virtually anyone with any kind background). 2. You take a random statement which seems appealing to you/to what you know ("quintillion" sounded nice to you, right?) from that description and interpret it in the most ridiculously wrong way possible. 3. You use that first stupid conclusion as an initial step to continue guessing increasingly stupid problems/solutions: if we need to do X DNA sample tests, we would take it from X different people; if we get out of people, we make more people; if get out of space for those people, we go to other planets, etc. Everything is so easy for you, isn't it? You are a solver! LOL. 4. You aren't able even to finish all that nonsense properly, because I would have been able to come up with a much funnier ending part myself.
It doesn't belong to any system of units (because of the hours bit), but it is consistent with all the other units/physics and consequently is a valid description of energy; bear in mind that power=energy/time -> energy=power*time. So kW (power) * h (time) is a valid energy unit which needs to be converted to other units when performing calculations in certain contexts (e.g., to J when dealing with other SI/metric units).
With proper help, analysing the code is certainly easier but, if the original developers seriously wanted to hide something in a so complex piece of software, your chances of finding it via code analysis would be extremely low.
In fact the algorithm and the math behind the code is what should be examined
The underlying theory and the provided documentation are the worst parts to start looking for fishy bits. If they want to do something not too correct, they would hide it pretty well and, logically, don't tell you about it.
The problem of untangling a mixture of DNA samples with levels close to the detection limit, as is in the case they discuss, is exceedingly complex. At that level the tests are highly prone to amplify a contamination (there was a case when somebody contaminated the samples with their own DNA because the tubes were opened while they talked). At the detection limit of the assay you also have stochastic effects where random alleles that are present in the sample are not detected.
Are you saying that you cannot validate a DNA-analysing piece of software? How could that be true? Any piece of software can be validated. You have X input samples and Y expected results, if the program outputs the right result with a Z level of error is fine, otherwise is not. Whatever contamination or additional aspect should be possible to be removed, otherwise how are you expecting to use a so unreliable software/proceeding in court?
Now add unknown number of sources of DNA to the mixture, every one of them with different amount and state of decay. I can easily imagine mixtures that cannot be unambiguously solved under ideal conditions.
You have two options: either remove those cases from the tests or carefully analyse whatever output properly and determine whether it might be assumed correct. You have to be able to know what answer you expect either manually or by using an already-validated piece of software and, within certain confidence, determine whether the tested piece of software passes the test or not. If you do a proper test, with a big enough of proper samples and a proper assessing methodology, the pieces of software working fine should pass that test. Additionally, if the test results are so extremely difficult to be validated, how are you expecting to deal with the order of magnitude more difficult to analyse source code? At least, by assuming that plan to do it properly; just reading some basic ideas about its underlying algorithm would certainly be much easier.
I also buy the argument that revealing the code will infringe on his right to protect his IP
Note that my point is based on pure pragmatism, rather than on privacy/IP aspects.
What if one of the programmers was of a malicious type who hated his ex-wife to the point where he would code a special routine in if her DNA were found (or if his own were found)?
Your chances of finding out about that via testing are way higher than via code analysis. Even in case of having the source code, it is very unlikely that a so complex piece of software is properly analysed.
You could easily have a trigger in the code to give a guilty verdict when desired
The problem is that, in a complex enough code, you might not be able to tell even by looking at the source code. Theoretically, you certainly could, but practically nobody would spend all the required effort to gain a perfect understanding. Here, for example, a probabilistic-based DNA sequencing approach! I am tired just with thinking about how intrincated and obscure that code might be! The calculation engine might be formed by walls of constants and complex formulae, which are extremely difficult to be analysed and which might carry any faulty bit. To not mention the alternative of "what if the code analyst also wants to trick you"? The most practical (and certainly used everywhere) approach is to properly test the corresponding piece of software and, eventually, take additional measurements like having a proper knowledge about the developing company.
I'm anti forcing private companies to disclose their source code
In some cases, seeing the source code might be required, but under the most likely conditions this is a pretty useless formality. Very tough work which is very unlikely to output worthier conclusions than testing.
This is precisely the first link you shared. There is no specifics there, just abstract statements and videos. With specifics, I mean calculations, proper technical analyses, validations, etc. Usually, what you put inside a technical paper, the one I linked from my post (a copy in sci-hub because otherwise you would have to pay to see it); this paper is the second one in their publications section. Anyway, I think that we have already talk enough about all this and our positions don't seem to get closer. It was nice. Bye.
One thing is having access to the source code and a completely different story is properly analysing it. When dealing with something as complex as (probabilistic!) DNA sequencing, it seems quite clear that the most sensible way to validate the program is actually using it. Set up a proper benchmark with a relevant number of samples and confirm whether this (+ any other) program works exactly as expected. This would also be an excellent way to objectively assess its accuracy.
With "doesn't seem to avoid too much mobility", I meant "doesn't seem to allow too much mobility". What a day I am having on Slashdot! Much more errors than usual!
This is a much better way to have a proper discussion! Thanks for sharing.
At first sight, this seems an on-going research which might have a more or less good funding and a long-term essence. So, this seems as an excellent sample of top achievements on this field at the moment. The page you refer doesn't describe in too much detail the specifics; just includes some generic statements and visually-appealing resources like videos. The 200 lb reference seems a bit too high already and, in my opinion, an excellent accomplishment in case of getting it under favourable enough conditions. It is quite difficult to tell for sure with so little/unclear information though.
In the publications section, there are quite a few papers although not precisely too new. The newest one, “Human Augmentation and Exoskeleton Systems in Berkeley”, is from 2007 and you can find it in sci-hub. If you go to page 12, you would see a quite clear picture of how a system on these lines might look like and its drawbacks seem evident: firstly, it doesn't seem to avoid too much mobility; secondly, there seems to be a minimum not precisely minor weight. This might be helpful under very specific conditions like walking long distances with a heavy pack; I have personally done things on these lines (traveling just for fun) and do know that, under these conditions, any small help is welcome. That paper refers to a maximum load of 34 kg (page 11) in the first version, but doesn't make any express mention to anything else. It does mention in various parts that this exoskeleton is expected to resemble a 165 lb person, what seems quite compatible with bearing that weight for a long time. The 200 lb value seems a bit off and, as far as there is no justification anywhere for that, I assume that is associated with either much higher constraints or more or less imprecise targets. Assuming that the maximum load which a human-size structure like this can bear is around the maximum that a person can seems a quite reasonable.
A very good reference which, IMHO, kind of proves my point: nothing even close to what you see in movies and, in any case, with lots of constraints, what makes the resulting products only relevant under very specific conditions. Additionally, this looks like a pretty tough-to-do-research field as far as there is likely an important pressure to increase the values as much possible; an issue which might explain that looking-like-too-much-already 200 lb value, at least under comfortable enough conditions. Anyway, there are lots of material in that site and it might even be possible to find other researches connected with all this; certainly a much better way to have a proper chat about all this.
kWh would have been fine too, an easily understandable and fully accepted format. I am certainly not justifying that behaviour. Additionally, they are mixing up watt and watt-hour and calling all this "power"; also the editor's work is precisely taking care of this kind of issues. The main motivation of my comment was highlighting the curious meaning of "per hour" in that specific context.
2.4 kilowatts per hour or 57.6 kilowatt hours per day
Seems a typo of the intended version "2.4 kilowatts hour per hour", where "per hour" is just the time framework where the given value + power unit happens. A much clearer version would have been "2.4 kilowatt-hour every hour".
I am not particularly interested in all what refers to investments, financial whatever, bitcoin, etc., but after having read so many posts here and just out of pure curiosity I want to know if I have got all this right. Basically, I understand that the whole system works as follows:
- On one hand, you have the mining part where apparently only the big mining companies or the ones selling mining machines really earn money. The remaining miners have to put a relevant amount of money upfront to buy a hardware which will only work for the purpose of mining. They have to let these machines working for as long as possible by paying the electricity bills and hoping that the mining returns will be kept more or less constant.
- On the other hand, you have people buying whatever bitcoin and waiting for its price to go as high as possible; what seems to be the case lately, but what might suddenly change for no good reason. In an extreme scenario where the given currency completely collapses, there will be no institution/government somehow minimising those effects; there are also no relevant regulations/limitations avoiding abusive behaviours or, in general, anything actually ensuring certain medium-term stability. People can easily buy bitcoins, but cannot immediately convert them into a national currency; there is either some waiting period (+ a small commission) or a relevant commission. So, it seems that, in order to earn something with bitcoins, you would need to buy a relevant amount of them, wait a relevant amount of time and hope that the prices will continue increasing. Something like stock trading, but with a much more limited public information regarding what is the expected evolution and virtually no regulation?
If you aren't looking to have your opinions challenged, then of course there's no point to continue the discussion
This wasn't my point. I don't like too much abstract discussion where the point/counter-point are more or less generic/unprovable and both parties aren't exactly on the same page. I am a very practical guy and the most logical output under those conditions is a long conversation not letting anyone happy. Don't misinterpret me: you seem a fairly reasonable and respectful person, the kind of people with whom I have no problem in discussing about whatever. It is simply a matter of pragmatism built over having been involved in equivalent chats quite a few times before.
Let me put a more descriptive example to help you understand my position: I could easily use your "without any real basis in science or engineering to support your claims" against you, because this is pretty much what I think of your argumentation. I think that I have provided enough information to get the idea or, at least, to continue a more technical discussion focused on some of my assumptions, but you have avoided all that an relied on even more generic statements. See why there is no point in continuing? Bring me some data/calculations/relevant information supporting your position or proving me wrong and I wouldn't even mind to spend time doing some work on my own. But no more abstract talking, please.
Just in case it isn't clear: I don't agree with quite a few statements in this last post of yours, but don't think that continuing with this endless loop of abstract argumentation (+ kind of not getting properly the other's position) will get us anywhere.
Slashdot Mirror
Pretty much how all investing works. Higher risks usually mean higher gains and losses. Bitcoin and other cryptocurrencies are just another vehicle for doing what humans have been doing for centuries.
That seems a good summary. Regardless of its technical resemblance, this is simply a new investing alternative and, as such, only relevant for people caring about investments. As said, I have no interest in all this either directly (investing) or indirectly (focusing my activity as a programmer/engineer on this sub-field). Thanks for the comment though.
I was half hoping you'd shut me up with some nice technical way around the problem...
Impressive 180-turn attitude change! Well, as answered to other commentator right now, I am personally a fan of approaches on the lines of multiple attempts + averaging the results for proper empirical validation. For example, a way to confirm/dismiss/improve that much more realistic 1 in 200 estimate, I would go with 10 sets of tests up to either 200 or the second error. So, if in the first set, you get the second error at the 150 attempt, you stop there; if in the second set, you reach 200 without a second error, you stop there, etc. You average all these results and get your conclusion. Then, you should repeat that process quite a few more times under different conditions and keep averaging the results for an increasingly better accuracy. But you should also make an extra-effort to not mix up different conditions (or, at least, properly weighting them; although this is usually a more complicated alternative), what might inadvertently affect the reliability in a very relevant way. The whole system could also be systematically further tuned via replacing that initial 200 limit with the newly validated conclusions you keep getting. So, basically an iterative ad infinitum proceeding whose accuracy is mostly conditioned by the time/effort you want to spend on it, but which can also deliver as many (reasonably good) intermediate conclusions as you want.
Actually, GP is correct if we're resorting to empirical testing.
Not even in that scenario. Even in case that you carried those 211 quintillion tests out, it wouldn't represent a reliable validation of the claim "1 in 211 quintillion" because just one empirical confirmation isn't statically significant (and this is, from the point of view of that claim, what performing the whole 211 quintillion test once would mean). If you want to go down such a ridiculous unnecessarily over-working path and you want to do it properly, you would have to rely on a much better methodology on the lines of repeating the process various times (at least, 5 times?) and averaging the value. So, if you perform the 211 quintillion tests 5 times and each of these times you get only 1 error, then you would certainly be in a position to undoubtedly conclude that the original statement was, beyond any doubt, accurate. But nobody in their right mind would ever tried to do such a nonsense to validate a meaning-nothing commercial nonsense.
We would want about six hundred quintillion samples to test against to verify that.
This is not what the intended verification was meant to be. And in any case, this isn't how you would even validate that claim. That quintillion reference is clearly an extrapolated estimation (= commercial language) which could be confirmed/dismissed by relying on equivalent means; that is, testing a much smaller number of samples and applying whatever "methodology" they used to come up with that number. But again this isn't what releasing the source code/not is about; what we are discussing here is about making sure that the piece of software works as expected and, eventually, accurately calculate its actual reliability according to whatever expectations the given court/governmental entity/legislation considers that are good enough; this isn't about confirming whatever random claim the company does.
TL;DR: the ridiculous claim of that company is irrelevant from the software validation/source code release point of view; but, even in case of deciding to empirically validate such a nonsense, the proceeding proposed by the previous poster isn't reliable enough.
I'm a software developer, and I'm frequently not sure beyond a reasonable doubt about software I personally have written, let alone other people's software.
I am also a software developer and I have no doubts while analysing the code I wrote, any other properly-commented/structured code or even a horrible code, but all this assuming that I can invest enough time/effort. This is precisely my whole point since the start (is seriously so difficult to just understand what is clearly written?): analysing code is a less efficient alternative than testing the corresponding program under the most common conditions and certainly when dealing with a so complex piece of software like the one being referred here. That's why the first title: "it makes more sense theoretically than practically".
And with "previous above" I meant "previous post" :)
I will better write here one of my there-are-way-too-many-stupid-people-unable-to-understand-even-the-simplest-idea over-clarifications: when talking about two different languages a false friend refers to two similar words with completely different meanings. Although I have a reasonably good English knowledge, it is still my second language and, when dealing with words/expressions of fields outside my main expertise, what I usually do/like/etc. (e.g., anything related to finance, economics, banking, etc.), some false friend might slip through. In Spanish, "comisión" means both commission and fee (or, in this context, exchange/conversion rate) and that's why I intuitively wrote "commission" even despite being fully aware about the fact that this is wrong in English; the reason why I quickly corrected it via the previous above.
So the article claims a false positive rate of 1 in 211 quintillion for a particular trial.
I didn't read the article, but that or any other issue doesn't change anything. If you aren't able to define accurate enough conditions to validate the corresponding piece of software, you would fail to do so anyway. Testing is much more likely to be quicker and more efficient than the alternative approach of analysing the code. Or do you think that by having access to the code you can guess what might be the output under so extreme conditions? If this was so, what would have been the point of having a piece of software in the first place if just by looking at the algorithm you can intuitively get the result?!
To test that with a 95% confidence interval we would need at least 600 quintillion samples.
No. This is not what the first statement means. And again, if you preferred to interpret it in that way and to analyse a so ridiculously big and completely unnecessary number of samples, I would recommend you to do it by running that software rather than by manually analysing the algorithm.
I don't think Earth could support this many people so we need to colonize other planets. To make things simple, lets assume the average planet can support 10 billion people. Therefore, we need to colonize roughly 60 billion planets and test everyone on those planets. I think we can do that without leaving the Milky Way galaxy, so we should be OK.
Out of all your ridiculous statements so far, this is my favourite one. Are you saying me that if you had to (manually) test 600 quintillion DNA samples, you would get them from 600 quintillion different people?! LOOOOOOOOL. You, this-can-be-solved-by-scaling-it-up guys, are too much for me! So, let's sum up your masterpiece so far:
1. You have a situation about which you clearly don't have even a slight understanding (or perhaps you are being consciously dishonest/partial for whatever reason; because properly understanding all this doesn't seem that difficult for virtually anyone with any kind background).
2. You take a random statement which seems appealing to you/to what you know ("quintillion" sounded nice to you, right?) from that description and interpret it in the most ridiculously wrong way possible.
3. You use that first stupid conclusion as an initial step to continue guessing increasingly stupid problems/solutions: if we need to do X DNA sample tests, we would take it from X different people; if we get out of people, we make more people; if get out of space for those people, we go to other planets, etc. Everything is so easy for you, isn't it? You are a solver! LOL.
4. You aren't able even to finish all that nonsense properly, because I would have been able to come up with a much funnier ending part myself.
Much like KWh - it's not a metric quantity
It doesn't belong to any system of units (because of the hours bit), but it is consistent with all the other units/physics and consequently is a valid description of energy; bear in mind that power=energy/time -> energy=power*time. So kW (power) * h (time) is a valid energy unit which needs to be converted to other units when performing calculations in certain contexts (e.g., to J when dealing with other SI/metric units).
but also for the algorithms behind it.
With proper help, analysing the code is certainly easier but, if the original developers seriously wanted to hide something in a so complex piece of software, your chances of finding it via code analysis would be extremely low.
In fact the algorithm and the math behind the code is what should be examined
The underlying theory and the provided documentation are the worst parts to start looking for fishy bits. If they want to do something not too correct, they would hide it pretty well and, logically, don't tell you about it.
The problem of untangling a mixture of DNA samples with levels close to the detection limit, as is in the case they discuss, is exceedingly complex. At that level the tests are highly prone to amplify a contamination (there was a case when somebody contaminated the samples with their own DNA because the tubes were opened while they talked). At the detection limit of the assay you also have stochastic effects where random alleles that are present in the sample are not detected.
Are you saying that you cannot validate a DNA-analysing piece of software? How could that be true? Any piece of software can be validated. You have X input samples and Y expected results, if the program outputs the right result with a Z level of error is fine, otherwise is not. Whatever contamination or additional aspect should be possible to be removed, otherwise how are you expecting to use a so unreliable software/proceeding in court?
Now add unknown number of sources of DNA to the mixture, every one of them with different amount and state of decay. I can easily imagine mixtures that cannot be unambiguously solved under ideal conditions.
You have two options: either remove those cases from the tests or carefully analyse whatever output properly and determine whether it might be assumed correct. You have to be able to know what answer you expect either manually or by using an already-validated piece of software and, within certain confidence, determine whether the tested piece of software passes the test or not. If you do a proper test, with a big enough of proper samples and a proper assessing methodology, the pieces of software working fine should pass that test. Additionally, if the test results are so extremely difficult to be validated, how are you expecting to deal with the order of magnitude more difficult to analyse source code? At least, by assuming that plan to do it properly; just reading some basic ideas about its underlying algorithm would certainly be much easier.
I also buy the argument that revealing the code will infringe on his right to protect his IP
Note that my point is based on pure pragmatism, rather than on privacy/IP aspects.
What if one of the programmers was of a malicious type who hated his ex-wife to the point where he would code a special routine in if her DNA were found (or if his own were found)?
Your chances of finding out about that via testing are way higher than via code analysis. Even in case of having the source code, it is very unlikely that a so complex piece of software is properly analysed.
charging our car at "50 miles per hour. And that's actually valid units.
This is definitively curious and perhaps commonly used, but certainly not a valid power unit.
You could easily have a trigger in the code to give a guilty verdict when desired
The problem is that, in a complex enough code, you might not be able to tell even by looking at the source code. Theoretically, you certainly could, but practically nobody would spend all the required effort to gain a perfect understanding. Here, for example, a probabilistic-based DNA sequencing approach! I am tired just with thinking about how intrincated and obscure that code might be! The calculation engine might be formed by walls of constants and complex formulae, which are extremely difficult to be analysed and which might carry any faulty bit. To not mention the alternative of "what if the code analyst also wants to trick you"? The most practical (and certainly used everywhere) approach is to properly test the corresponding piece of software and, eventually, take additional measurements like having a proper knowledge about the developing company.
I'm anti forcing private companies to disclose their source code
In some cases, seeing the source code might be required, but under the most likely conditions this is a pretty useless formality. Very tough work which is very unlikely to output worthier conclusions than testing.
Sorry, this link would have been better, and more specific: http://bleex.me.berkeley.edu/r... [berkeley.edu]
This is precisely the first link you shared. There is no specifics there, just abstract statements and videos. With specifics, I mean calculations, proper technical analyses, validations, etc. Usually, what you put inside a technical paper, the one I linked from my post (a copy in sci-hub because otherwise you would have to pay to see it); this paper is the second one in their publications section. Anyway, I think that we have already talk enough about all this and our positions don't seem to get closer. It was nice. Bye.
One thing is having access to the source code and a completely different story is properly analysing it. When dealing with something as complex as (probabilistic!) DNA sequencing, it seems quite clear that the most sensible way to validate the program is actually using it. Set up a proper benchmark with a relevant number of samples and confirm whether this (+ any other) program works exactly as expected. This would also be an excellent way to objectively assess its accuracy.
And if I had written "many more errors than usual", it would have been even better! LOL.
With "doesn't seem to avoid too much mobility", I meant "doesn't seem to allow too much mobility". What a day I am having on Slashdot! Much more errors than usual!
Here's something specific: http://bleex.me.berkeley.edu/r... [berkeley.edu]
This is a much better way to have a proper discussion! Thanks for sharing.
At first sight, this seems an on-going research which might have a more or less good funding and a long-term essence. So, this seems as an excellent sample of top achievements on this field at the moment. The page you refer doesn't describe in too much detail the specifics; just includes some generic statements and visually-appealing resources like videos. The 200 lb reference seems a bit too high already and, in my opinion, an excellent accomplishment in case of getting it under favourable enough conditions. It is quite difficult to tell for sure with so little/unclear information though.
In the publications section, there are quite a few papers although not precisely too new. The newest one, “Human Augmentation and Exoskeleton Systems in Berkeley”, is from 2007 and you can find it in sci-hub. If you go to page 12, you would see a quite clear picture of how a system on these lines might look like and its drawbacks seem evident: firstly, it doesn't seem to avoid too much mobility; secondly, there seems to be a minimum not precisely minor weight. This might be helpful under very specific conditions like walking long distances with a heavy pack; I have personally done things on these lines (traveling just for fun) and do know that, under these conditions, any small help is welcome. That paper refers to a maximum load of 34 kg (page 11) in the first version, but doesn't make any express mention to anything else. It does mention in various parts that this exoskeleton is expected to resemble a 165 lb person, what seems quite compatible with bearing that weight for a long time. The 200 lb value seems a bit off and, as far as there is no justification anywhere for that, I assume that is associated with either much higher constraints or more or less imprecise targets. Assuming that the maximum load which a human-size structure like this can bear is around the maximum that a person can seems a quite reasonable.
A very good reference which, IMHO, kind of proves my point: nothing even close to what you see in movies and, in any case, with lots of constraints, what makes the resulting products only relevant under very specific conditions. Additionally, this looks like a pretty tough-to-do-research field as far as there is likely an important pressure to increase the values as much possible; an issue which might explain that looking-like-too-much-already 200 lb value, at least under comfortable enough conditions. Anyway, there are lots of material in that site and it might even be possible to find other researches connected with all this; certainly a much better way to have a proper chat about all this.
kWh would have been fine too, an easily understandable and fully accepted format. I am certainly not justifying that behaviour. Additionally, they are mixing up watt and watt-hour and calling all this "power"; also the editor's work is precisely taking care of this kind of issues. The main motivation of my comment was highlighting the curious meaning of "per hour" in that specific context.
I meant "energy unit". Everyone can make typos :)
2.4 kilowatts per hour or 57.6 kilowatt hours per day
Seems a typo of the intended version "2.4 kilowatts hour per hour", where "per hour" is just the time framework where the given value + power unit happens. A much clearer version would have been "2.4 kilowatt-hour every hour".
With "commission" I meant exchange rate. Sorry about having blindly trusted my Spanish false friend :)
I am not particularly interested in all what refers to investments, financial whatever, bitcoin, etc., but after having read so many posts here and just out of pure curiosity I want to know if I have got all this right. Basically, I understand that the whole system works as follows:
- On one hand, you have the mining part where apparently only the big mining companies or the ones selling mining machines really earn money. The remaining miners have to put a relevant amount of money upfront to buy a hardware which will only work for the purpose of mining. They have to let these machines working for as long as possible by paying the electricity bills and hoping that the mining returns will be kept more or less constant.
- On the other hand, you have people buying whatever bitcoin and waiting for its price to go as high as possible; what seems to be the case lately, but what might suddenly change for no good reason. In an extreme scenario where the given currency completely collapses, there will be no institution/government somehow minimising those effects; there are also no relevant regulations/limitations avoiding abusive behaviours or, in general, anything actually ensuring certain medium-term stability. People can easily buy bitcoins, but cannot immediately convert them into a national currency; there is either some waiting period (+ a small commission) or a relevant commission. So, it seems that, in order to earn something with bitcoins, you would need to buy a relevant amount of them, wait a relevant amount of time and hope that the prices will continue increasing. Something like stock trading, but with a much more limited public information regarding what is the expected evolution and virtually no regulation?
If you aren't looking to have your opinions challenged, then of course there's no point to continue the discussion
This wasn't my point. I don't like too much abstract discussion where the point/counter-point are more or less generic/unprovable and both parties aren't exactly on the same page. I am a very practical guy and the most logical output under those conditions is a long conversation not letting anyone happy. Don't misinterpret me: you seem a fairly reasonable and respectful person, the kind of people with whom I have no problem in discussing about whatever. It is simply a matter of pragmatism built over having been involved in equivalent chats quite a few times before.
Let me put a more descriptive example to help you understand my position: I could easily use your "without any real basis in science or engineering to support your claims" against you, because this is pretty much what I think of your argumentation. I think that I have provided enough information to get the idea or, at least, to continue a more technical discussion focused on some of my assumptions, but you have avoided all that an relied on even more generic statements. See why there is no point in continuing? Bring me some data/calculations/relevant information supporting your position or proving me wrong and I wouldn't even mind to spend time doing some work on my own. But no more abstract talking, please.
Just in case it isn't clear: I don't agree with quite a few statements in this last post of yours, but don't think that continuing with this endless loop of abstract argumentation (+ kind of not getting properly the other's position) will get us anywhere.