Arwill

>Each of those two sets of atoms were split into superpositions, with one path traveling closer to the mass than the other, separated by about 25 centimeters

One path of the particle in superposition was closer to the 1.25Kg mass than the other path, and they did measure a difference when doing that.

I don't know if you are trying to be pedantic, or just want to contradict. I know what you are saying, but the the expression "not touching the field" makes perfect sense to me. Try plotting the 25cm distance difference for the 1.25Kg mass, and see if it makes a difference or not...

They measured a bigger gravitational effect on the particle, because the superpositional pair of the particle flew closer to a mass than the actually measured particle.

Regarding the "never touch", gravity decreases with distance squared, so it diminishes quickly with distance. There is a big difference in being near the mass, as opposed to feeling the dimished effect of it from far.

The article does not mention it, but mothers with small children have to nurse babies every couple of hours, even at night. So given that in middle ages, families had "copious numbers of children" (quote from the article), it is for sure that mothers would need to get up to feed a baby. And then possibly the whole family would woke up too. And if multiple generations were living in the same house, then even more probably there were babies too. I can imagine such a basic need being the root of the habit.

That is the difference of specialised software in comparison to duct-taped solution like Teams. The first one has code to decide what is meaningful for the user in a given context, the second "just renders" the whole thing and show the user a thumbnail, probably without even knowing what kind of content it is dealing with.

In retrospect, this gives me validation of why i always disliked to scan documents to PDF instead of to just JPEG.

But large document archives are traditionally done with TIFF, and should still be done like that.

Some game engines (C++) do allocations in multiple memory areas. If some allocated memory is known to be needed only for the current frame, then it is allocated from that memory area. Then at the end of the frame the whole region is freed. This is an explicit garbage collection at end of each frame. Memory allocation can further be split according to the CPU thread, thus avoiding global locking in the allocator. With double-buffering the next updated/prepared frame can use its own memory area, while the previous one finishes rendering.

The problem with GC or with reference counting is that it needs to operate on each allocated object separately. If the task for the GC can be reduced to operate on whole memory areas only, its overhead is greatly reduced.

If particles behaved like software we could have a guess.

It could be that time dilation is caused by some underlying physical system having a bottleneck, thus causing the slowdown. The underlying physical system has to evaluate all possible states for a particle in superposition, even if working in parallel. Then i would guess a particle in superposition should always experience the biggest possible slowdown.

Most of those users are forced to use it because of company policy, not by choice.

I have problems with the Teams Android app, i have issues with Teams in Firefox, i have issues with the Teams desktop app, i have issues with Teams inside Citrix. Its just crappy experience altogether. I tell colleagues to write an email, if they want to reach me reliably.

It is a standard practice to have a "login server" and a separate "game server". The login server generates the token, and notifies the game server to accept it. The login server handles a queue, and can throttle login attempts. The login server can handle load balancing for multiple game servers, redirecting logged in players to different game servers. Its possible to run multiple login servers too, and restrict the access to specific login servers geographically and to run them with different providers.

I was like that too. Kids with C64 had plenty of games, and having better sound and graphics they just played games. I always advanced in coding when playing games became unrewarding/boring.

Splitting up objects attributes into separate arrays is required if you plan to work with those data on the GPU. I did it when working with Java and OpenCL, and wanted to efficiently access the same data trough Java objects and also in OpenCL kernels. OpenCL does not know about objects, like Java, but it can access data in arrays, so practically every Java object holds an index into the arrays of the different attributes.

Per my knowledge Unity ECS does not currently process data on the GPU, but uses ECS to split work to multiple threads on the CPU. If the threads work on data that only they need to touch, then there is no need to synchronise them. It is also more cache efficient to read and write data from a couple of arrays sequentially, than to pull objects and their attributes from all over the heap.

The idea of storing objects by attributes, instead of object instances is not new. Some clever allocator indeed might be new.

I suspect they want to make it harder for Unreal to make the same system. Unreal might have nice visuals, but scaling was not their strength before.

Custom asset import is also much better than for Unreal, even making an asset exporter is easy.

If for example the target is to re-make an old game in a modern engine, Unity is the better choice.

A viable solution for DX9 is using DXVK to emulate the old DX API under Vulkan, then add your own hooks into DXVK and transition to Vulkan in a more relaxed manner.

Now DXVK does not support DX7, but a quick search found dgVoodoo2, which does emulate DX7 under DX11. Maybe that or a similar library can be used as a stepping stone.

Regarding porting legacy apps to 64bit, the most problems i've seen were concerning old libraries (on Windows). That usually requires replacing old libraries with new a version, and fixing includes. I've seen only a handful of bugs arising purely from 32bit vs 64bit differences.

The quantum world constantly needs to agree on what the state of the macroscopic world is, there is a limit to the speed of that agreement happening, hence the speed limit on the spread of information (speed of light). There are contradictions happening constantly in the quantum world, but they are resolved either way.

Any contradiction would be resolved on quantum level even if it can be interpreted at macroscopic scale as breaking of causality.

The important thing for physics would be to better clarify what time is. Why is the speed of light as much as it is, why is there time dilation related to mass and why is the time slowing down for objects travelling faster.

My guess is that the quantum world needs more of its own time to agree when there are more objects (more mass) close to one another, or that a fast travelling object needs to "agree" with its surrounding more frequently, and that overhead is manifesting as slowing of its time.

Windows is my offline desktop OS. I keep it around specifically because i want it to be that way. I'm fine with a locked down Android phone, as that is a different use-case. Microsoft already failed with its locked-down ARM Windows version once. If the users wanted such an Windows OS, it would have not failed.

You can do that with Substance. Store images in a library and procedurally generate textures at runtime.

I hold the view that programming patterns were invented as solutions to technical problems. It was then later that some theoretical "usefulness" or "elegance" was attached to them.

One should know the technical benefits and drawbacks of programming patterns before applying them. Just because some language or environment or majority of programmers promotes it, doesn't mean that its ok to apply it. Without knowing the technical reason for applying a pattern is just cargo cult programming.

Putting together an MMO requires knowledge how to make your software systems scale. Putting together a demo in Unreal is the exact opposite of that. That is why you see so many bad MMO-s, they can make a demo, but they could not make that scale in 100 years.

If going by the above logic that just showing expertise is enough to get funding, then why was an Unreal demo valued as expertise at all?

If they showed expertise by demoing a network server/cluster, or world streaming, or asset import workflow, then i would say that there is some relevant expertise.

But they didn't even import a custom character into Unreal for their demo, how are they going to make a character creator and a clothing system?

This is how the GDPR makes a lot of sense.

Is it possible to control when and which variables are copied to the GPU? With solutions like this, the automatic copy of big arrays to the GPU can take more time than the kernel execution itself. I would want to use GPU programs this way, but also require low latency.

The reason why the Spanish flu hit so hard in 1918 is that countries were not willing to quarantine people in fear that it would hurt their wartime economies.

At some clients you have to sign their development guidelines, and you have no choice but to use that notation. The rule at big enterprises is that new rules get added, but old, even archaic rules seldom get removed.

It is legal to do that. Its the question how tight your app was doing it? If you just send user actions and answers over HTTP back and forth using a technical user, that's like sharing the user. But if you have your own billing software (for example), and submit finished bills with a SOAP request (for example) to SAP, that is completely ok.

I think the logic is that the Web API's are for apps doing things you would otherwise do in SAP's own GUI.

But i agree, SAP is not for those who are sensitive to license prices. Most commonly the solution is a third-party custom built software, that interfaces the data into the back-end SAP system.

The OP's comment was about scraping data from pages generated from SAP Web apps. I tried to point out that it make little sense, as there are proper ways of interfacing data (even over HTTP).

There are/were 5 different Web technologies over the years you could use to make Web apps for SAP. There are also standard WebService (XML SOAP) and REST interfaces over HTTP. There are also SAP native interfaces for specifically transferring data.

There are ways to do stuff in SAP, lots of implementation problems arise from the fact that people don't know how to do it right, and just try to apply whatever they do know. There is documentation and there are books.

Just tried the extension, and it seems Pinyin is not supported. There is no "Transliteration" option, like there is for Japanese.

Its not just that, but why test quest failure for if the companion is dead, if in principle companions can't die? This is a typical case of game design where lower level engine systems like physics dictate behavior/cause bugs in higher level functionality like the quest system.

Game engines do everything every frame by default, and the game has to disable/enable stuff from happening, which leads to bugs like this. With a more functional approach instead of tweaking the engine state these bugs can be avoided.

Imagine a comparable situation. Someone wins an olympic medal, and makes a political statement in the subsequent interview. Then the olympic committee decides to take the medal away, and ban the winner from competing again.

Is AMD getting ahead of Intel with a superior architecture, or due to the fact that its running on 7nm instead of Intel's 14nm?

Seems like that they in a typical Microsoft style tried to link one product to another. I can imagine that the boss of the Edge browser argued to make their bookstore Edge-only, to promote the browser that way. And that move effectively doomed the bookstore.

Its like you go to Microsoft site to search for a registry problem, and the support person tells you to use Cortana to search. Because obviously his job is not to solve your registry problem, it is to promote Cortana for Microsoft.