Welcome to our forums
Quoted from DanRRight ... senator from Florida claims these unbelievable things about England. Is this true ? Listen these couple minutes on Youtube starting from 11:45 ...
That is Sen. Ron Johnson, from Wisconsin; Sen. Rick Scott appeared at the beginning of the video.
Dan,
It is not good enough to merely question the data and then suggest perhaps the solution is wrong. Show an alternative explaination and prove this new hypothesis is a better model. My understanding is that vaccines protect us from serious illness, not from any illness.
Where is science going in the modern media ? Leave it to the likes of Tucker Carlson to suggest possible alternatives with no proof, and in so doing try to undermine the best scientific approach available.
You are right, mecej1, this was Johnson.
John, i do not claim anything. Just ask all to check the numbers if i am right, because i always make mistakes. This compiler teached me 100 times per day that i make unbelievable number of mistakes 😃
This is their numbers:
From Table 20 (for John, this was for C-related bad luck cases, not just any not related at all, read fine print) we can get
Unv. : 19+15+8+14 = 56 Vac. : 106+120+115+108 = 449
Total 56+449=505
56 /505 = 11% 449/505 = 89%
or Unv/Vac = 1:8
But because (from Table eighteen) the total number of Unv people was 1,684,323 i.e. smaller than Vac which was 3,864,774, the bad luck chances are
Unv. 56/1,684,323=0.00003325 or 3.325 people per 100,000 unvac people during 4 these weeks versus Vac. 449/3,864,774=0.00011618 or 11.618 per 100,000 vac people during same 4 weeks
So the relative bad luck chances for Vac are 11.618/3.325 or 3.49 times worse than for Unv. Correct?
Dan,
I tried to find independent reporting of the numbers you have quoted. I found : https://www.nature.com/articles/d41586-021-03003-6
Some of the issues that confuse include: unvaccinated people are more restricted in their movements, which may affect their chances of catching covid. First vaccinated have a lesser protection that increases weeks after being vaccinated, until 2 weeks after second dose.
However, the interesting statement from this article is 'But vaccines are still offering remarkable protection against hospitalization and death'
I don't think the statistic you are highlighting is most representative of vaccine effectiveness. I am more concerned about where booster doses will take us in the future.
I am old enough to remember the early polio vaccines. Fortunately we did not have social media misinformation back then and we all queued up for our polio shots, rather than the real consequences of not being vaccinated.
Social media does not report the unfortunate stories of those who have been silenced, but the claims of influrencers and idiots who are still alive.
John, This is Scotland, not Australia, unv.people move as freely everywhere as all others, often not wearing anything additional by the way. With lesser protection for 2-3 weeks after procedure i'd agree, but is this the major reason of really earth shattering difference by 3.5 times?
Let's return to our numbers, i usually ignore publications with just the claims. First, are my numbers correct?
For those who like punching the numbers here is another puzzling piece, now straight from the epicenter of all related information. It also has similar claims like in the one John just cited, but can anyone explain me based on m.rates in the Table 2 there, how after procedure people start to live ... twice-to-three time longer than general population when currently general unv. population m.rates in this table are almost similar to ones in 2019, when nothing was worrying like today ?! Again i asked all top medical experts i can find on the net, including its authors, and no one responded.
https://www.cdc.gov/mmwr/volumes/70/wr/mm7043e2.htm?s_cid=mm7043e2_w
This article was also retranslated on Youtube by the one of major educators on the subject. He seems also did not pay attention to the numbers. UPDATE: This reviewer responded 'the point of the study is not how they are different but the fact that there is no increase in mor tality in the vac. group' which at the best for him tells that he even does not understand what he is saying. Because if the method underestimates the m.rates by whopping factor of 2-3 how it can reveal the effect of orders smaller magnitude ?
JohnCampbell
Regarding the program that you posted on 29 September, the IO library uses 32 bit integers when writing partcl4 and this leads to the failure.
I can apply a local fix in this context but the chances are that the same problem will occur elsewhere.
I will send you a new ClearWin64.dll (with this fix included) for you to try.
JohnCampbell
This thread has become multi-faceted.
Would you be willing to pick out the different issues and start new threads, one for each issue and each with the relevant sample code?
Thanks Paul,
I think you are stating that unformatted binary files have a record size limit of 2gb bytes.
I also posted an example of stream I/O that did not work. I am more interested to see if FTN95 /64 stream I/O is able to position beyond 2gb file address, ie supporting 8-byte integer file addresses. My random access file system uses a default integer word address which supports 8 Gbyte files. I was wondering if I could 'easily' convert to an 8 byte file address with stream I/O for larger files.
I will post a new thread for the 8-byte stream I/O example.
It is not urgent as yet,
John
John
I have spent some time on your program stream_test.f90 that you posted on 1 October.
The failure is 'fixed' if you change line 136 from
write ( unit=stream_unit, pos=stream_address, iostat=iostat ) nw
to
write ( unit=stream_unit, iostat=iostat ) nw
At the moment I don't know if this implies there is a fault in the FTN95 IO library. Anyway it is not necessary to specify the stream position at this point and you have not done so in the lines that follow.
John
Further to my last post above, there does appear to be a fault in the IO library that has now been corrected for the next release of the DLLs.
Also the STREAM POS=position is currently limited to 32 bit integer values (2GB). I will see if it can easily be extended.