| Correlating curl resources to some other object. [message #185099] |
Wed, 26 February 2014 16:54  |
Daniel Pitts
Messages: 68
Registered: May 2012
Karma: 0
|
Member |
|
|
I may have up to a few dozen curl handles (from curl_init()), which I'm
passing off to curl_multi etc... to make in parallel. As requests
finish, I'm using curl_multi_info_read to figure out which curl handle
completed. I have other objects which have additional information about
the curl handles which I need in order to process them.
I'm disappointed to see there isn't an equivalent to spl_object_hash for
resources.
In any case, it looks like casting a resource to a string results in a
unique identifier [1], but the manual also states that the structure is
"subject to change". I interpret that as it will still be unique (at
least for that resource type), but it may be in a different format.
So, I'm wondering if using the (string) cast of a Resource as an array
key is going to lead to unexpected bugs during some future PHP upgrade.
I'd rather not loop through all my objects to find the matching one.
It's a small enough set that I might do that if there isn't another
reliable way to achieve this, but I'd rather have an O(1) solution.
Thanks,
Daniel.
References:
[1]
< http://us3.php.net/manual/en/language.types.string.php#language.types.strin g.casting>
|
|
|
|
| Re: Correlating curl resources to some other object. [message #185100 is a reply to message #185099] |
Wed, 26 February 2014 17:07  |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 2/26/2014 11:54 AM, Daniel Pitts wrote:
>
> I may have up to a few dozen curl handles (from curl_init()), which I'm
> passing off to curl_multi etc... to make in parallel. As requests
> finish, I'm using curl_multi_info_read to figure out which curl handle
> completed. I have other objects which have additional information about
> the curl handles which I need in order to process them.
>
> I'm disappointed to see there isn't an equivalent to spl_object_hash for
> resources.
>
> In any case, it looks like casting a resource to a string results in a
> unique identifier [1], but the manual also states that the structure is
> "subject to change". I interpret that as it will still be unique (at
> least for that resource type), but it may be in a different format.
>
> So, I'm wondering if using the (string) cast of a Resource as an array
> key is going to lead to unexpected bugs during some future PHP upgrade.
> I'd rather not loop through all my objects to find the matching one.
> It's a small enough set that I might do that if there isn't another
> reliable way to achieve this, but I'd rather have an O(1) solution.
>
>
> Thanks,
> Daniel.
>
>
> References:
> [1]
> < http://us3.php.net/manual/en/language.types.string.php#language.types.strin g.casting>
>
Daniel,
I don't think there is a guarantee that casting a resource to a string
results in a unique string (although it does seem to work this way
currently). But I don't see anywhere in the documentation where it is
stated that is the case, so I wouldn't bet on it, now or in the future.
For instance, you may create a resource, save it's id as a string
("Resource id #1") then delete the resource. What happens if you now
create a new resource? Does it get "Resource id #1" - or something
else? What will happen in that case is not documented.
And while you say you wouldn't do that - what about two years from now
when you (or someone else) gets in and changes the code? Or what if,
due to some error, a resource is deleted by the system and another with
the same id allocated? These are all questions you should be asking
yourself.
Looping through the resources shouldn't be that hard or time consuming.
I agree a hash would be better, but until there is a guarantee the id
will always be unique in the particular run of a script, I wouldn't plan
on it.
--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
| Re: Correlating curl resources to some other object. [message #185101 is a reply to message #185100] |
Wed, 26 February 2014 17:52 |
Daniel Pitts
Messages: 68
Registered: May 2012
Karma: 0
|
Member |
|
|
On 2/26/14 9:07 AM, Jerry Stuckle wrote:
> On 2/26/2014 11:54 AM, Daniel Pitts wrote:
>>
>> I may have up to a few dozen curl handles (from curl_init()), which I'm
>> passing off to curl_multi etc... to make in parallel. As requests
>> finish, I'm using curl_multi_info_read to figure out which curl handle
>> completed. I have other objects which have additional information about
>> the curl handles which I need in order to process them.
>>
>> I'm disappointed to see there isn't an equivalent to spl_object_hash for
>> resources.
>>
>> In any case, it looks like casting a resource to a string results in a
>> unique identifier [1], but the manual also states that the structure is
>> "subject to change". I interpret that as it will still be unique (at
>> least for that resource type), but it may be in a different format.
>>
>> So, I'm wondering if using the (string) cast of a Resource as an array
>> key is going to lead to unexpected bugs during some future PHP upgrade.
>> I'd rather not loop through all my objects to find the matching one.
>> It's a small enough set that I might do that if there isn't another
>> reliable way to achieve this, but I'd rather have an O(1) solution.
>>
>>
>> Thanks,
>> Daniel.
>>
>>
>> References:
>> [1]
>> < http://us3.php.net/manual/en/language.types.string.php#language.types.strin g.casting>
>>
>>
>
> Daniel,
>
> I don't think there is a guarantee that casting a resource to a string
> results in a unique string (although it does seem to work this way
> currently).
The documentation *does* say it is a unique string.
'Resources are always converted to strings with the structure "Resource
id #1", where 1 is the unique number assigned to the resource by PHP at
runtime'
Of course, it then says don't rely on that structure. Grr.
> But I don't see anywhere in the documentation where it is
> stated that is the case, so I wouldn't bet on it, now or in the future.
> For instance, you may create a resource, save it's id as a string
> ("Resource id #1") then delete the resource. What happens if you now
> create a new resource? Does it get "Resource id #1" - or something
> else? What will happen in that case is not documented.
>
> And while you say you wouldn't do that - what about two years from now
> when you (or someone else) gets in and changes the code? Or what if,
> due to some error, a resource is deleted by the system and another with
> the same id allocated? These are all questions you should be asking
> yourself.
Sometimes I have to remind myself that you're writing for a larger
audience, and not take your suggestions as a lack of respect for me ;-)
I've been working in the industry for 10+ years now, and have been
playing around with software for 25+ years. So I have definitely
learned to ask those questions on a regular basis.
>
> Looping through the resources shouldn't be that hard or time consuming.
> I agree a hash would be better, but until there is a guarantee the id
> will always be unique in the particular run of a script, I wouldn't plan
> on it.
I suppose. We're talking on the order of 100 items, so that's an
average of 5000 comparisons to completely process the entire set.
Actually, that's worse case, so I should be fine.
I wonder if a feature request to support an "spl_resource_hash" would
get any traction.
|
|
|
|
| Re: Correlating curl resources to some other object. [message #185104 is a reply to message #185101] |
Wed, 26 February 2014 18:52 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 2/26/2014 12:52 PM, Daniel Pitts wrote:
> On 2/26/14 9:07 AM, Jerry Stuckle wrote:
>> On 2/26/2014 11:54 AM, Daniel Pitts wrote:
>>>
>>> I may have up to a few dozen curl handles (from curl_init()), which I'm
>>> passing off to curl_multi etc... to make in parallel. As requests
>>> finish, I'm using curl_multi_info_read to figure out which curl handle
>>> completed. I have other objects which have additional information about
>>> the curl handles which I need in order to process them.
>>>
>>> I'm disappointed to see there isn't an equivalent to spl_object_hash for
>>> resources.
>>>
>>> In any case, it looks like casting a resource to a string results in a
>>> unique identifier [1], but the manual also states that the structure is
>>> "subject to change". I interpret that as it will still be unique (at
>>> least for that resource type), but it may be in a different format.
>>>
>>> So, I'm wondering if using the (string) cast of a Resource as an array
>>> key is going to lead to unexpected bugs during some future PHP upgrade.
>>> I'd rather not loop through all my objects to find the matching one.
>>> It's a small enough set that I might do that if there isn't another
>>> reliable way to achieve this, but I'd rather have an O(1) solution.
>>>
>>>
>>> Thanks,
>>> Daniel.
>>>
>>>
>>> References:
>>> [1]
>>> < http://us3.php.net/manual/en/language.types.string.php#language.types.strin g.casting>
>>>
>>>
>>>
>>
>> Daniel,
>>
>> I don't think there is a guarantee that casting a resource to a string
>> results in a unique string (although it does seem to work this way
>> currently).
> The documentation *does* say it is a unique string.
>
> 'Resources are always converted to strings with the structure "Resource
> id #1", where 1 is the unique number assigned to the resource by PHP at
> runtime'
>
That could be read two ways. For instance, if a resource is destroyed,
creating a new resource could have the same number. It would still
identify a unique *valid* resource.
> Of course, it then says don't rely on that structure. Grr.
>
Yes, as I said, I agree it seems to always be a unique value (it
increments one for each resource created). But nothing says it will
remain so, and the doc seems to indicate the opposite.
Of course, it could also mean don't rely in it being exactly "Resource
id #1" - but later could be something like "curl resource #1", "mysql
resource #2", or even just "curl 1" - but still unique. The doc is not
at all clear on this. I would like to see a clarification on this
point, for just the reasons you've stated.
>> But I don't see anywhere in the documentation where it is
>> stated that is the case, so I wouldn't bet on it, now or in the future.
>> For instance, you may create a resource, save it's id as a string
>> ("Resource id #1") then delete the resource. What happens if you now
>> create a new resource? Does it get "Resource id #1" - or something
>> else? What will happen in that case is not documented.
>>
>> And while you say you wouldn't do that - what about two years from now
>> when you (or someone else) gets in and changes the code? Or what if,
>> due to some error, a resource is deleted by the system and another with
>> the same id allocated? These are all questions you should be asking
>> yourself.
> Sometimes I have to remind myself that you're writing for a larger
> audience, and not take your suggestions as a lack of respect for me ;-)
>
> I've been working in the industry for 10+ years now, and have been
> playing around with software for 25+ years. So I have definitely
> learned to ask those questions on a regular basis.
Sorry, youngster (I've probably been in the industry longer than you've
been alive :) ). I'm not trying to insult you here. But I have to
constantly remind myself of these same things.
>>
>> Looping through the resources shouldn't be that hard or time consuming.
>> I agree a hash would be better, but until there is a guarantee the id
>> will always be unique in the particular run of a script, I wouldn't plan
>> on it.
>
> I suppose. We're talking on the order of 100 items, so that's an
> average of 5000 comparisons to completely process the entire set.
> Actually, that's worse case, so I should be fine.
>
I guess you *could* create an array with the key being the string
conversion of the resource, and the value being a reference to the curl
resource. Before inserting a new entry into the array, check to see if
it already exists. If it does, log an error. Be sure to comment your
code well so if you get the error 2 years from now you know what it
means (it's amazing how short our memories can be! :) ).
> I wonder if a feature request to support an "spl_resource_hash" would
> get any traction.
>
>
I would support some kind of truly unique identifier which could be used
as a key. Whether it is an spl_resource_hash or something else makes
little difference, as long as it's useful.
--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
| Re: Correlating curl resources to some other object. [message #185108 is a reply to message #185104] |
Wed, 26 February 2014 21:25 |
Adam Harvey
Messages: 25
Registered: September 2010
Karma: 0
|
Junior Member |
|
|
On Wed, 26 Feb 2014 13:52:10 -0500, Jerry Stuckle wrote:
> On 2/26/2014 12:52 PM, Daniel Pitts wrote:
>> On 2/26/14 9:07 AM, Jerry Stuckle wrote:
>>> I don't think there is a guarantee that casting a resource to a string
>>> results in a unique string (although it does seem to work this way
>>> currently).
>> The documentation *does* say it is a unique string.
>>
>> 'Resources are always converted to strings with the structure "Resource
>> id #1", where 1 is the unique number assigned to the resource by PHP at
>> runtime'
>>
>>
> That could be read two ways. For instance, if a resource is destroyed,
> creating a new resource could have the same number. It would still
> identify a unique *valid* resource.
To be clear: resource numbers aren't reused within an individual request.
(At present, they always increase sequentially -- I don't see that
changing, but also wouldn't want to guarantee it.)
>> Of course, it then says don't rely on that structure. Grr.
>>
>>
> Yes, as I said, I agree it seems to always be a unique value (it
> increments one for each resource created). But nothing says it will
> remain so, and the doc seems to indicate the opposite.
>
> Of course, it could also mean don't rely in it being exactly "Resource
> id #1" - but later could be something like "curl resource #1", "mysql
> resource #2", or even just "curl 1" - but still unique.
That's the intention. I agree it was poorly worded.
> The doc is not
> at all clear on this. I would like to see a clarification on this
> point, for just the reasons you've stated.
I've committed an update to the manual to clarify this. The new wording
(which will appear over the weekend, assuming no issues with the
documentation build on Friday) is:
Resources are always converted to strings with the structure "Resource id
#1", where 1 is the resource number assigned to the resource by PHP at
runtime. While the exact structure of this string should not be relied on
and is subject to change, it will always be unique for a given resource
within the lifetime of a script being executed (ie a Web request or CLI
process) and won't be reused. To get a resource's type, use the
get_resource_type() function.
>> I wonder if a feature request to support an "spl_resource_hash" would
>> get any traction.
>>
> I would support some kind of truly unique identifier which could be used
> as a key. Whether it is an spl_resource_hash or something else makes
> little difference, as long as it's useful.
As noted above, the intention is that casting a resource to a string
should result in a unique identifier, so a function is unnecessary in
this case.
Adam
|
|
|
|
| Re: Correlating curl resources to some other object. [message #185109 is a reply to message #185108] |
Wed, 26 February 2014 21:48 |
Daniel Pitts
Messages: 68
Registered: May 2012
Karma: 0
|
Member |
|
|
On 2/26/14 1:25 PM, Adam Harvey wrote:
> On Wed, 26 Feb 2014 13:52:10 -0500, Jerry Stuckle wrote:
>> On 2/26/2014 12:52 PM, Daniel Pitts wrote:
>>> On 2/26/14 9:07 AM, Jerry Stuckle wrote:
>>>> I don't think there is a guarantee that casting a resource to a string
>>>> results in a unique string (although it does seem to work this way
>>>> currently).
>>> The documentation *does* say it is a unique string.
>>>
>>> 'Resources are always converted to strings with the structure "Resource
>>> id #1", where 1 is the unique number assigned to the resource by PHP at
>>> runtime'
>>>
>>>
>> That could be read two ways. For instance, if a resource is destroyed,
>> creating a new resource could have the same number. It would still
>> identify a unique *valid* resource.
>
> To be clear: resource numbers aren't reused within an individual request.
> (At present, they always increase sequentially -- I don't see that
> changing, but also wouldn't want to guarantee it.)
>
>>> Of course, it then says don't rely on that structure. Grr.
>>>
>>>
>> Yes, as I said, I agree it seems to always be a unique value (it
>> increments one for each resource created). But nothing says it will
>> remain so, and the doc seems to indicate the opposite.
>>
>> Of course, it could also mean don't rely in it being exactly "Resource
>> id #1" - but later could be something like "curl resource #1", "mysql
>> resource #2", or even just "curl 1" - but still unique.
>
> That's the intention. I agree it was poorly worded.
>
>> The doc is not
>> at all clear on this. I would like to see a clarification on this
>> point, for just the reasons you've stated.
>
> I've committed an update to the manual to clarify this. The new wording
> (which will appear over the weekend, assuming no issues with the
> documentation build on Friday) is:
>
> Resources are always converted to strings with the structure "Resource id
> #1", where 1 is the resource number assigned to the resource by PHP at
> runtime. While the exact structure of this string should not be relied on
> and is subject to change, it will always be unique for a given resource
> within the lifetime of a script being executed (ie a Web request or CLI
> process) and won't be reused. To get a resource's type, use the
> get_resource_type() function.
>
>>> I wonder if a feature request to support an "spl_resource_hash" would
>>> get any traction.
>>>
>> I would support some kind of truly unique identifier which could be used
>> as a key. Whether it is an spl_resource_hash or something else makes
>> little difference, as long as it's useful.
>
> As noted above, the intention is that casting a resource to a string
> should result in a unique identifier, so a function is unnecessary in
> this case.
Awesome! Thanks for that.
|
|
|
|
| Re: Correlating curl resources to some other object. [message #185112 is a reply to message #185108] |
Wed, 26 February 2014 22:22 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 2/26/2014 4:25 PM, Adam Harvey wrote:
> On Wed, 26 Feb 2014 13:52:10 -0500, Jerry Stuckle wrote:
>> On 2/26/2014 12:52 PM, Daniel Pitts wrote:
>>> On 2/26/14 9:07 AM, Jerry Stuckle wrote:
>>>> I don't think there is a guarantee that casting a resource to a string
>>>> results in a unique string (although it does seem to work this way
>>>> currently).
>>> The documentation *does* say it is a unique string.
>>>
>>> 'Resources are always converted to strings with the structure "Resource
>>> id #1", where 1 is the unique number assigned to the resource by PHP at
>>> runtime'
>>>
>>>
>> That could be read two ways. For instance, if a resource is destroyed,
>> creating a new resource could have the same number. It would still
>> identify a unique *valid* resource.
>
> To be clear: resource numbers aren't reused within an individual request.
> (At present, they always increase sequentially -- I don't see that
> changing, but also wouldn't want to guarantee it.)
I agree on both counts.
>
>>> Of course, it then says don't rely on that structure. Grr.
>>>
>>>
>> Yes, as I said, I agree it seems to always be a unique value (it
>> increments one for each resource created). But nothing says it will
>> remain so, and the doc seems to indicate the opposite.
>>
>> Of course, it could also mean don't rely in it being exactly "Resource
>> id #1" - but later could be something like "curl resource #1", "mysql
>> resource #2", or even just "curl 1" - but still unique.
>
> That's the intention. I agree it was poorly worded.
>
Is it the intention? I can't read ZEND's minds.
>> The doc is not
>> at all clear on this. I would like to see a clarification on this
>> point, for just the reasons you've stated.
>
> I've committed an update to the manual to clarify this. The new wording
> (which will appear over the weekend, assuming no issues with the
> documentation build on Friday) is:
>
That is good.
> Resources are always converted to strings with the structure "Resource id
> #1", where 1 is the resource number assigned to the resource by PHP at
> runtime. While the exact structure of this string should not be relied on
> and is subject to change, it will always be unique for a given resource
> within the lifetime of a script being executed (ie a Web request or CLI
> process) and won't be reused. To get a resource's type, use the
> get_resource_type() function.
>
But what about other resources? If this resource is destroyed, can the
number ever be used again? (Obviously it *could* - there is a limit to
the numbers available - but let's be reasonable here).
>>> I wonder if a feature request to support an "spl_resource_hash" would
>>> get any traction.
>>>
>> I would support some kind of truly unique identifier which could be used
>> as a key. Whether it is an spl_resource_hash or something else makes
>> little difference, as long as it's useful.
>
> As noted above, the intention is that casting a resource to a string
> should result in a unique identifier, so a function is unnecessary in
> this case.
>
> Adam
>
OK, as long as the number isn't reused, then I would agree.
--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
| OT: getting older/wiser [message #185119 is a reply to message #185104] |
Thu, 27 February 2014 12:04 |
bill
Messages: 310
Registered: October 2010
Karma: 0
|
Senior Member |
|
|
On 2/26/2014 1:52 PM, Jerry Stuckle wrote:
> If it does, log an error. Be sure to comment your code well so
> if you get the error 2 years from now you know what it means
> (it's amazing how short our memories can be! :) ).
that's because: "(I've probably been in the industry longer than
you've been alive ;)"
Recent research indicates that the reason older folk think
"slower" is that they have more memories to go through to find
what they are looking for (tested with word finding).
It is reasonable to conclude that older = wiser, not slower.
OTOH, I wonder if all the brain space I used for comics and
science fiction (that I still remember) was a good brain space
investment ?
bill
|
|
|
|
| Re: OT: getting older/wiser [message #185120 is a reply to message #185119] |
Thu, 27 February 2014 13:22 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 2/27/2014 7:04 AM, bill wrote:
> On 2/26/2014 1:52 PM, Jerry Stuckle wrote:
>> If it does, log an error. Be sure to comment your code well so
>> if you get the error 2 years from now you know what it means
>> (it's amazing how short our memories can be! :) ).
>
> that's because: "(I've probably been in the industry longer than you've
> been alive ;)"
>
Not at all. Even young people forget what they did a couple of years
ago. Even six months can be difficult to remember the details.
> Recent research indicates that the reason older folk think "slower" is
> that they have more memories to go through to find what they are looking
> for (tested with word finding).
> It is reasonable to conclude that older = wiser, not slower.
>
Yes, but that research is controversial and has not been validated by
peer review yet. Possibly in the future it will be, but until it is, it
is only a theory. Remember cold fusion?
> OTOH, I wonder if all the brain space I used for comics and science
> fiction (that I still remember) was a good brain space investment ?
>
> bill
Of course it is! Entertainment is an important part of life.
--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
| Re: OT: getting older/wiser [message #185122 is a reply to message #185120] |
Thu, 27 February 2014 16:02 |
bill
Messages: 310
Registered: October 2010
Karma: 0
|
Senior Member |
|
|
> Yes, but that research is controversial and has not been
> validated by peer review yet. Possibly in the future it will be,
> but until it is, it is only a theory. Remember cold fusion?
If I say "yes," that means I am one of the old/wise.
If I say "no," then I am either one of the old/wise/demented or
too young to remember.
I will say yes and still hope it will work someday.
>
>> OTOH, I wonder if all the brain space I used for comics and
>> science
>> fiction (that I still remember) was a good brain space
>> investment ?
>>
>> bill
>
> Of course it is! Entertainment is an important part of life.
That is one of the reasons I participate here.
|
|
|
|
| Re: OT: getting older/wiser [message #185123 is a reply to message #185120] |
Thu, 27 February 2014 17:11 |
Daniel Pitts
Messages: 68
Registered: May 2012
Karma: 0
|
Member |
|
|
On 2/27/14 5:22 AM, Jerry Stuckle wrote:
> On 2/27/2014 7:04 AM, bill wrote:
>> On 2/26/2014 1:52 PM, Jerry Stuckle wrote:
>>> If it does, log an error. Be sure to comment your code well so
>>> if you get the error 2 years from now you know what it means
>>> (it's amazing how short our memories can be! :) ).
>>
>> that's because: "(I've probably been in the industry longer than you've
>> been alive ;)"
>>
>
> Not at all. Even young people forget what they did a couple of years
> ago. Even six months can be difficult to remember the details.
I'm relatively young (early 30s), and I have trouble remembering what I
had for breakfast.
>
>> Recent research indicates that the reason older folk think "slower" is
>> that they have more memories to go through to find what they are looking
>> for (tested with word finding).
>> It is reasonable to conclude that older = wiser, not slower.
Stupid people get old too ;-)
That isn't a commentary about anyone in particular, so please no one
take offense.
> Yes, but that research is controversial and has not been validated by
> peer review yet. Possibly in the future it will be, but until it is, it
> is only a theory. Remember cold fusion?
You clearly mean hypothesis. Theory is once its proven.
>
>> OTOH, I wonder if all the brain space I used for comics and science
>> fiction (that I still remember) was a good brain space investment ?
>
> Of course it is! Entertainment is an important part of life.
+1
|
|
|
|
| Re: OT: getting older/wiser [message #185126 is a reply to message #185123] |
Thu, 27 February 2014 17:52 |
Thomas 'PointedEars'
Messages: 701
Registered: October 2010
Karma: 0
|
Senior Member |
|
|
Daniel Pitts wrote:
> On 2/27/14 5:22 AM, Jerry Stuckle wrote:
>> On 2/27/2014 7:04 AM, bill wrote:
>>> On 2/26/2014 1:52 PM, Jerry Stuckle wrote:
>>> Recent research indicates that the reason older folk think "slower" is
>>> that they have more memories to go through to find what they are looking
>>> for (tested with word finding).
>>> It is reasonable to conclude that older = wiser, not slower.
> […]
>> Yes, but that research is controversial and has not been validated by
>> peer review yet. Possibly in the future it will be, but until it is, it
>> is only a theory. Remember cold fusion?
> You clearly mean hypothesis. Theory is once its proven.
A fundamental, but common, misconception in both statements; in part
purported by some scientists employing informal language (non-scientists
doubly so). Theories are just elaborate(d) thought processes, based on a
number of theses; they can only be either confirmed or falsified (by
reality, e.g. experiment). (The more a theory is confirmed, the firmer it
is believed to be true. And if something passes peer review it just means
that the people who reviewed it have found *nothing* logically *wrong* with
it; it does _not_ mean that the conclusions therein are true.)
For example, Einstein's general theory of relativity – which BTW grows 100
years in two years from now – has not been proven at all and will never be
proven; science just does not work that way. We only assume that the
assumptions he made are true because what follows from them explains our
observations so well. Likewise for Quantum Field Theory and all other
theories.
HTH
PointedEars
--
When all you know is jQuery, every problem looks $(olvable).
|
|
|
|
| Re: OT: getting older/wiser [message #185127 is a reply to message #185120] |
Thu, 27 February 2014 18:01 |
Tim Streater
Messages: 328
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
In article <lene5o$3og$1(at)dont-email(dot)me>, Jerry Stuckle
<jstucklex(at)attglobal(dot)net> wrote:
> On 2/27/2014 7:04 AM, bill wrote:
>> Recent research indicates that the reason older folk think "slower" is
>> that they have more memories to go through to find what they are looking
>> for (tested with word finding).
>> It is reasonable to conclude that older = wiser, not slower.
> Yes, but that research is controversial and has not been validated by
> peer review yet. Possibly in the future it will be, but until it is, it
> is only a theory. Remember cold fusion?
You mean it's only a hypothesis. Cold Fusion never advanced to being a
theory, because it was never validated by experiments carried out by
others. And the purpose of peer review is to critique your experiment
which has led you to make a claim and advance a hypothesis. Your peers
might then say f'rinstance that your methodology is bad, your analysis
is bad, and so on.
--
"People don't buy Microsoft for quality, they buy it for compatibility
with what Bob in accounting bought last year. Trace it back - they buy
Microsoft because the IBM Selectric didn't suck much" - P Seebach, afc
|
|
|
|
| Re: OT: getting older/wiser [message #185131 is a reply to message #185123] |
Thu, 27 February 2014 21:20 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 2/27/2014 12:11 PM, Daniel Pitts wrote:
> On 2/27/14 5:22 AM, Jerry Stuckle wrote:
>> On 2/27/2014 7:04 AM, bill wrote:
>>> On 2/26/2014 1:52 PM, Jerry Stuckle wrote:
>>>> If it does, log an error. Be sure to comment your code well so
>>>> if you get the error 2 years from now you know what it means
>>>> (it's amazing how short our memories can be! :) ).
>>>
>>> that's because: "(I've probably been in the industry longer than you've
>>> been alive ;)"
>>>
>>
>> Not at all. Even young people forget what they did a couple of years
>> ago. Even six months can be difficult to remember the details.
> I'm relatively young (early 30s), and I have trouble remembering what I
> had for breakfast.
>>
>>> Recent research indicates that the reason older folk think "slower" is
>>> that they have more memories to go through to find what they are looking
>>> for (tested with word finding).
>>> It is reasonable to conclude that older = wiser, not slower.
> Stupid people get old too ;-)
>
> That isn't a commentary about anyone in particular, so please no one
> take offense.
>
>> Yes, but that research is controversial and has not been validated by
>> peer review yet. Possibly in the future it will be, but until it is, it
>> is only a theory. Remember cold fusion?
> You clearly mean hypothesis. Theory is once its proven.
Incorrect. Theories are by definition not proven. From Dictionary.com:
Theory:
1. a coherent group of tested general propositions, commonly regarded as
correct, that can be used as principles of explanation and prediction
for a class of phenomena: Einstein's theory of relativity.
2. a proposed explanation whose status is still conjectural and subject
to experimentation, in contrast to well-established propositions that
are regarded as reporting matters of actual fact.
<snip other definitions>
Taking their example, Einstein's theory of relativity is generally
regarded as correct (at least no major contradictions have been found).
But, like other theories, it may be impossible to "prove" it. But it
could be dis-proven by finding an example that contradicts it.
>>
>>> OTOH, I wonder if all the brain space I used for comics and science
>>> fiction (that I still remember) was a good brain space investment ?
>>
>> Of course it is! Entertainment is an important part of life.
>
> +1
>
--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
| Re: OT: getting older/wiser [message #185133 is a reply to message #185123] |
Thu, 27 February 2014 23:56 |
Allodoxaphobia
Messages: 21
Registered: September 2010
Karma: 0
|
Junior Member |
|
|
On Thu, 27 Feb 2014 09:11:38 -0800, Daniel Pitts wrote:
>>>
>>> It is reasonable to conclude that older = wiser, not slower.
>
> Stupid people get old too ;-)
Nice observation!
Alas, there is one creature on this planet to which
natural selection seems not to apply.
|
|
|
|
| Re: OT: getting older/wiser [message #185138 is a reply to message #185133] |
Sat, 01 March 2014 03:08 |
Daniel Pitts
Messages: 68
Registered: May 2012
Karma: 0
|
Member |
|
|
On 2/27/14 3:56 PM, Allodoxaphobia wrote:
> On Thu, 27 Feb 2014 09:11:38 -0800, Daniel Pitts wrote:
>>>>
>>>> It is reasonable to conclude that older = wiser, not slower.
>>
>> Stupid people get old too ;-)
>
> Nice observation!
>
> Alas, there is one creature on this planet to which
> natural selection seems not to apply.
Sure it does. Intelligence isn't necessary for surviving. The most
abundant species are not self-aware
|
|
|
|
| Re: OT: getting older/wiser [message #185139 is a reply to message #185138] |
Sat, 01 March 2014 13:37 |
Colin Birch
Messages: 3
Registered: December 2013
Karma: 0
|
Junior Member |
|
|
On Fri, 28 Feb 2014 19:08:44 -0800, Daniel Pitts wrote:
> On 2/27/14 3:56 PM, Allodoxaphobia wrote:
>> On Thu, 27 Feb 2014 09:11:38 -0800, Daniel Pitts wrote:
>>>> >
>>>> > It is reasonable to conclude that older = wiser, not slower.
>>>
>>> Stupid people get old too ;-)
>>
>> Nice observation!
>>
>> Alas, there is one creature on this planet to which
>> natural selection seems not to apply.
> Sure it does. Intelligence isn't necessary for surviving. The most
> abundant species are not self-aware
Do you mean women? ;-)
--
Colin Birch
http://www.railscans.co.uk
|
|
|
|
| Re: OT: getting older/wiser [message #185151 is a reply to message #185139] |
Sun, 02 March 2014 20:51 |
Daniel Pitts
Messages: 68
Registered: May 2012
Karma: 0
|
Member |
|
|
On 3/1/14 5:37 AM, Colin Birch wrote:
> On Fri, 28 Feb 2014 19:08:44 -0800, Daniel Pitts wrote:
>
>> On 2/27/14 3:56 PM, Allodoxaphobia wrote:
>>> On Thu, 27 Feb 2014 09:11:38 -0800, Daniel Pitts wrote:
>>>> >>
>>>> >> It is reasonable to conclude that older = wiser, not slower.
>>>>
>>>> Stupid people get old too ;-)
>>>
>>> Nice observation!
>>>
>>> Alas, there is one creature on this planet to which
>>> natural selection seems not to apply.
>> Sure it does. Intelligence isn't necessary for surviving. The most
>> abundant species are not self-aware
> Do you mean women? ;-)
>
No, I meant insects and bacteria, but dip-shits like you fit the bill as
well.
|
|
|
|
Calendar
Search
Help
Members
Register
Login
Home
]