Friday, May 19, 2017

Zika virus mutation and the challenges

Zika Virus - Mutation and the challenges.

I have thought matrixed the idea behind the zika viri research and i come to a disturbing conclusion about the problematic relationship between the zika virus and a comparable example the common flue .. and swine flue...

Both forms can prove deadly and problematic for chemical treatments ...

You see the flue mutates between hosts and within a single host quite regularly...
"So what is the problem zika is not the same !"  the problem is that zika like the flue or the cold is an example of cross species parasitical entities ...

Therefore changes between host and delivery host (the mosquito); Both have changing DNA though breeding cycles and consequentially the zika virus must mutate rapidly to out perform host adaptation..

Chemicals that bind now most probably will not perform their job's at a later mutation cycle and may vary in performance over the mutation bias...

The very nature of rapidly developing mutation both changes and challenges the non adaptive chemical treatment bias of research and scientific study !

One sample of the genetic code may not always prove valid for all variants and most problematically not prove effective, This variance is after all  what provides for survivors of diseases like the plague and the forming of man from the suggested primate ancestry.

So what could we do about this ? have the bind points proved to be unchanging or mutating .. are their variances in these bind points ?

What are the inevitable problems we will face in science and medicine of these crucial issues.

Rupert S

zika virus further research

zika virus

most relevant - Analysis of Dengue Virus Genetic Diversity during Human and Mosquito Infection Reveals Genetic Constraints

mutation rates amongst RNA Viri

viral mutation rates and math

The prediction of virus mutation using neural networks and rough set techniques - the analysis engine

Predicting virus mutations through statistical relational learning

Replication and Adaptive Mutations of Low Pathogenic Avian Influenza Viruses in Tracheal Organ Cultures of Different Avian Species

Wednesday, May 17, 2017

Sensible VulkanGL

Vulkan & OpenGL/ES - Standards and includes

The optimisation of the open GL and substantive inclusion of the eco/power friendly Open GL ES & Vulkan Standards....

program driver include would read intrinsic operating system binds ... (the Open GL standard is sensible)

*flag table*

power save on or off

preferred render bind : Vulkan , ES , GL

intrinsic compatible flags for all mutually compatible functions & the caching and trans-coding of those flags into the preferable & mutually compatible program execution format...

(the function calls will be optimised in stack)

because we do not need the ridiculous situation where high level ES devices that have the majority of the GL standard's being blacklisted from GL programs... or visa versa.

the pipeline of GL is already a transition of negotiation of the sub standards of the GPU and Mesa SDK instruction-sets ... such as NVidia and ARM or PowerVR and ATI

Standard inclusion of emulation and trans-coding of the bindings enables at least support & hardware optimisation CPU or GPU,

Commons like : Compression standards are already included and are across the standards anyway !


The code of the render path would be pre execution optimised like shader cache is...
Weather the code is pre runtime optimises in the execution stack / Dalvac / etcetera...

Or comprehensively optimised at run-time, dynamically would depend upon the need's of the OS, the programmer and or the user,

Obviously pre-caching the runtime stack in a compiled form would reduce compute time and for that reason the dalvak and it's replacement where included in the beautiful android OS.

Shifts in power plan & the available system resource share are obviously going to shift dynamically...
and should also be flags, with user flag's for power use and resource use being the defacto standard per app and system flags as the subset under the user flag system.


at the moment the Vulcan (including the CL and Render Script paths) standard is the preferred rendering path for speed and excellence,

However the feature set system must be compatible with the standards for function and class transfer and the simple programming of the standard ...

SDK's should be simple to use and they will be under the unified feature set list.

Devices with ES 3.1 support should/must obviously receive the vulkan libraries immediately.

In addition older devices would have service upgrade libraries for the easy transport to device of the new standard; To maintain the optimal utilisation and function of all devices.

Rupert S