avatarCarlos E. Perez

Free AI web copilot to create summaries, insights and extended knowledge, download it at here

4635

Abstract

s from certain people:</p><div id="b727"><pre>Person mother <span class="hljs-operator">=</span> Person(//) mother.talk()<span class="hljs-comment">;</span></pre></div><p id="dbc4">If we are thinking about a certain person, we must have created an <b>instance</b> <b>of ‘Person’</b> for that person in our minds (or RAM in a Computer).</p><h1 id="43d8">3—Class Fields</h1><p id="3eca">As we have mentioned above, these common names defined in our minds have some features like person’s age, name.</p><p id="5352"><b>This is where null safety comes into play.</b></p><p id="02cb">Of course, there may be thousands of classes related to a person in our minds or universe’s code. “Newly Met Person”, “My Friend” etc.</p><p id="c414">But let’s simplify this quite a bit. And suppose we have only one definition of Person in our minds and a few properties like age, name etc.</p><p id="08ba">A quick question for you? While meeting a person, when you ask his/him age, have you ever thought of a question : “I wonder if this person has an age?”. Or when you ask someone their age, “I don’t have one.” Do you expect an answer like that?</p><p id="f4b3">If no, <code>int age;</code> can <b>NEVER</b> be nullable in universe’s code.</p><blockquote id="a7fd"><p>Maybe we haven’t asked someone’s age yet, or he/she hasn’t said it. But in reality, we don’t need a person’s age to form in our minds. So let’s pretend we know everything we can know(in the moment and future) and we need in our case.</p></blockquote><p id="548d">Another question is:</p><p id="4a81">When we ask a person the question “where do you work”, do you always get a workplace information in the answer?</p><p id="60ef">If no, our <code>jobID</code> class member is <b>nullable</b>. Not everyone has to have a job.</p><p id="f44a">Yes, now let’s define a class with these two properties:</p><figure id="a61f"><img src="https://cdn-images-1.readmedium.com/v2/resize:fit:800/1*8E5Xt1ie176KE-ap6AIyGQ.png"><figcaption></figcaption></figure><p id="8026">This means that a person may have a <code>jobID</code>, maybe not. But he/she definitely has <code>age</code>.</p><p id="16cb">Now you have encountered an error here. Do you think it is right to break the logical context we mentioned above about age and job ID to solve this error?</p><p id="a5d5">Here the <code>int? age</code> solution breaks our logical context.</p><p id="2159">So what is the error and how to solve it?</p><p id="cdda">Let’s handle the wrong solutions first:</p><p id="c180">1- Make Nullable.</p><p id="a702">We’ve already mentioned this: age cannot be null. So this is not a solution.</p><p id="1670">2- Add <code>late</code> modifier.</p><p id="fbeb">In most cases this is not the right solution either. Persons have an age from the moment they exist.</p><p id="d3c3">3- Give a default age.</p><p id="e087"><code>int age = 0;</code>. If you think that every person you see/ meet/ know is a newborn, possibly it’s a good solution. The fact that its age is not yet known in your mind (that is, when a person instance has not yet formed) does not mean that the person age is zero.</p><p id="8dcd"><b>Solution</b></p><p id="e84a">As you can see, we used words like “yet”, “not yet” and “moment” a lot. Existence, the process of existence and its chronology have an important place.</p><p id="376e">So let’s take a quick look at how an instance is created.</p><p id="2e0b">Now we are defining and creating a Person class/instance for a conversation.</p><p id="9c40">Let’s take a look at the example below and see in what order they work.</p><figure id="2594"><img src="https://cdn-images-1.readmedium.com/v2/resize:fit:800/1*lLXdolSz3dwGhrwuXDYv1w.png"><figcaption></figcaption></figure><p id="5fb0">These concepts will be used:</p><blockquote id="39c8"><p>SpokenPerson(<params>) : <final-initializer>{<construction-body>}</construction-body></final-initializer></params></p></blockquote><p id="26c5">So:</p><p id="7048">1 — <b>Before Executing Construct.</b></p><p id="824b">First, let’s consider what we can actually know before a SpokenPerson is created : That our conversation duration is 0. All the others are things we will never know before we create this person in our minds.</p><blockquote id="be23"><p>Notice, everything known before is not <code><i>static</i></code>. The conversation Duration Ms is about a specific SpokesPerson instance. Static properties are properties that are not specific to a certain object instance.</p></blockquote><p id="d1dc">When we want to create an instance using the SpokenPerson(…) expression, “conversationDurationInMs = 0” (as setter) will run first.</p><p i

Options

d="5014">2 — <b><params></b></p><p id="33df">We need information to create a SpokenPerson instance. So the <params> part works. The parameters here are read, if any, default values are taken. “this.” or “super.” statements are actually the first part of the next stage<final-initializer>. We can only use it in this stage for coding convenience.</final-initializer></params></p><p id="8d0f">As a result, this stage is where the necessary questions are asked and the necessary preparations are made to create a SpokenPerson instance.</p><p id="c906">3 — <b><final-initializer></b></p><p id="e41c">This stage is the creation stage of an object. The object has not yet been formed at this stage. Like an embryo.</p><p id="a0f5">As soon as this stage is over, the object will be created. This means that at the end of this stage we need to know all the final variables and required variables associated with an object. If there is information concerning the superior object, it must be given here with super’s constructor.</p><p id="ba6e">The main reason for our error above is that “age” is unknown at or before this stage.</p><p id="87d6">Here, we can’t access instance members.</p><p id="c2e9">4 — <code><b>late</b></code><b> modifier with value members.</b></p><p id="d2b0">This is the stage that works between <code><final-initializer></code> and <code><construction-body></code>. The section below represents this stage. Here we can access instance members. But what we can value from this point forward does not mean that the value will definitely be given here. The value is given the first time we use a <code>late </code>instance member.</p><p id="6e3d"><code>late bool tallerThanMe = height > 1.78;</code></p><p id="236d">5 — <b><construction-body></b></p><p id="a82c">This stage is the stage where the actions to be performed immediately after the object is created. Here we can access instance members.</p><p id="d212">In this example, we talk to it right after creating an instance.</p><p id="6dba">6 — <b>set late members</b></p><p id="75c6">If it exists, and we are setting it, we set the late members at the end (at an indefinite time).</p><p id="33e7"><code>satisfiedWithConversation</code>. We cannot ask this before we speak. We’ll know after we talk. But unlike nullable ones, we can know for sure after talking.</p><h2 id="e0f6">Solution Result</h2><p id="4eb7">1 — If a property is not going to be null in our case, we <b>never </b>make it nullable. Request them as parameters or calculate and give values, latest in the final-initializer.</p><p id="fecc">2 — If you have a non-nullable member, but its value is not known yet when the instance is created, use <code>late</code>. Only use it when you’re sure you’ll appreciate it before using it.</p><p id="825d">3 — “Does it have this feature?” If you answer “sometimes” to the question, set it to nullable. And always ask if it’s an existing condition before using it (check null).</p><h1 id="1766">Some Tips</h1><h2 id="3437">late with instance member</h2><p id="1ea1">A member with a late modifier can access instance members. In the example, “widget” is an instance member (owned by State) and we can access it. This is functionally like valuing currentTitle in initState. However, the fact that we can value the currentTitle variable immediately after the instance is created does not mean that it will be given a certain value exactly after construct. The first time we use a late member, it is given its value.</p><p id="7579">So, any attempt to read this late variable before “State” attaches to the widget will result in an <b>error</b>.</p><p id="4b23">That’s my own policy, but I think it’s functional: Don’t use <code>late</code> with value.</p><p id="5be8">WRONG WAY:</p><figure id="c85d"><img src="https://cdn-images-1.readmedium.com/v2/resize:fit:800/1*7Q3Lu0vmTb2RU_wvOX5_4Q.png"><figcaption></figcaption></figure><h2 id="30f6">Need an initialize/attach</h2><p id="16d1">If one of your controller requires an initialize function, or if an instance of a class works together with an instance of another class (State-StatefulWidget, Widget-Element, Controller-Client), a structure that facilitates access to this connected/attached instance can be established.</p><figure id="c111"><img src="https://cdn-images-1.readmedium.com/v2/resize:fit:800/1*_eyjhdxmlZZy9QoqoERcUw.png"><figcaption></figcaption></figure><p id="c07b">Depending on the situation, if a change is expected, check the <code>hasClient</code>and then use the <code>client </code>comfortably. Equivalent in State <code>mounted</code>.</p></article></body>

The Delusion of Infinite Precision Numbers

Photo by rawpixel on Unsplash

All models are wrong but some are useful — George Box

Real numbers are not real. The argument is simple, real numbers cannot reflect reality (i.e. not real) because they assume to have infinite precision. Infinite precision is an impossibility in nature because it assumes that an infinite amount of information is contained in a single real number. Therefore, we must assume that reality uses numbers with finite precision. A real number is only significant after a certain number right of the decimal point.

in most numerical simulations infinite precision is not an immediate concern. That’s because finite precision numbers have always been used to approximate infinite precision real numbers. Computationally, the only time you really need extremely high precision numbers is in cryptography. However, a majority of numerical simulation code requires just 64-bit floating point numbers.

The question that however needs to be asked is, how does this relate to existing analytic theories of reality? Newton’s laws and Maxwell equations, both classical physics theories, are analytic tools (i.e. calculus) that assume infinite precision numbers (i.e. real numbers). What are the consequences if we assume finite precision numbers? This idea is explored in a recent paper by Nicolas Gisin (Experimental and theoretical physicist at the University of Geneva). In his paper “Indeterminism in Physics, Classical Chaos and Bohmian Mechanics. Are Real Numbers Really Real?” he emphasizes:

Mathematical real numbers are physical random numbers.

The origins of classical chaos originate from the finite precision of quantities that describe nature. This implies that the determinism of classical physics is not real. To assume determinism is tantamount to assuming a single number contains infinite information, an obvious absurdity. The implication of this is that all our analytic equations of reality (the models that we have symbolic closed forms) are all approximations of reality and NOT the reverse as commonly assumed. Mathematics assumes infinite precision so as to derive new knowledge, but this is all based on an approximation. Infinite precision employs a deterministic abstraction that demands that absolute knowledge is available when in reality it is not. I purposely used the word ‘approximation’ instead of ‘abstraction’ to convey the fact that infinite precision overshoots the precision intrinsic in reality. A more prevalent myth is that numerical methods undershoot reality due to its lack of precision. It is the delusion of users of mathematics to believe that analytic equations are the ultimate truth when in truth the real physics demands indeterminism (BTW, see also the Rationalist Delusion). In the end, all we have are abstract models of reality, finite or infinite-precision models that should be treated in equal standing.

I’ve written previously about the issues with assuming the existence of infinity as it relates to expressing randomness. There are other assumptions in conventional mathematics that are equally problematic in representing reality. The other one is the assumption of the excluded middle. This is found in proofs of contradiction and the double negative. There is an alternative kind of logic known as intuitionistic logic that demands only what can be constructed is what can be proven. In fact, one can argue that Gödel’s incompleteness theorem is proof that invalidates classical mathematics.

How does this all relate then to the field of Deep Learning? Here’s where I see the problem, a majority of the papers conjure up formal arguments based on mathematics that assume the existence of infinity, infinite precision or the excluded middle. These are all nice to have included having a convincing argument about the validity of a method. Unfortunately, these arguments are all based on concepts that aren’t even real. All of these mathematical tools are crutches to our true understanding of reality. Closed analytic solutions are nice, but they are applicable only for simple configurations of reality. At best, they are toy models of simple systems. Physicists have known for centuries that the three-body problem or three dimensional Navier Stokes do not afford a closed form analytic solutions. This is why all calculations about the movement of planets in our solar system or turbulence in a fluid are all performed by numerical methods using computers.

This notion that a formal proof using real analysis is true, is a delusion. It will always be an approximation of the truth. The proof of something that works is in the actual simulation. You have to run the computation to prove that something is actually true. Deep Learning works despite the optimization theorist proclaiming that high-dimensional spaces are non-convex and thus require exponential time to converge. Deep Learning works because the theory is an approximation, and can only be validated through experimental work. Therefore, never be discouraged by analytic proofs that a method is an impossibility.

The motivation for this discussion revolves around the idea of numerical methods for simulations versus black box Deep Learning generative models. Numerical Analysis the bread and butter of Computational Science (i.e. Scientific Computing) are derived directly from formulated mathematical models:

https://en.wikipedia.org/wiki/Computational_science

There are numerous algorithms and methods in computational science that are used to approximate and stabilize the simulation of mathematical models. The pragmatic question is can these numerical simulations be performed in a more computationally efficient way using DL generative models?

One very strange departure of DL models is that, despite being formulated through continuous mathematics, computations do not require high precision. It is typical to find training using 16-bit floating point numerics and inference requiring even less precision (i.e. 8 bit). This is in stark contrast with HPC simulations that required higher precision 64bit floating point. This is a tell on the fundamental difference between the two approaches. Perhaps generative models require less precision that descriptive models. Why do bottom-up generative models require less numeric precision than top-down numerical models? In fact, if you compare the computational requirements of a top-down Monte Carlo simulation, the computational requirements are tremendous relative to a DL model. This is why Probabilistic Graph Models don’t scale like DL models.

I suspect traditional numerical methods are appealing due to the illusion of control they provide. Can we build DL methods that afford an equivalent richness of controls? How can we develop DL models with the same kind of confidence as computational science models? DL generative models for fluid and smoke have previously successfully be demonstrated:

https://cims.nyu.edu/~schlacht/CNNFluids.htm

The problem, however, is that (despite this looking like the real thing for humans) does this actually approximate the true physics?

The justification for a DL generative approach is precise because the mathematical models where numerical methods are derived are approximations, to begin with, and thus also do not necessarily exhaustively represent the physics. The main argument against DL models is that they don’t represent any physics, although they seem to generate simulations that do look realistically like physics. However, you can train a DL model to mirror the behavior of a simulation. This would imply that it would be an approximation approximating an approximation (simulation) that approximates another approximation (mathematical model).

The difference is that DL models potentially bridge the gap with higher fidelity than the best simulation. This can be done because DL can potentially learn from aggregate simulation models. This is the approach that many in weather simulation employ. That is the use of an ensemble of models for prediction.

The potential for using DL generative models to replace traditional numerical methods is vast. Numerical methods are essential for many kinds of manufacturing of advanced materials and engines. Accurate simulations permit discovery of problems prior to expensive manufacturing, this not only drastically reduces cost but permits faster iteration in design. In fact, the coupling of faster DL generative solution with Reinforcement Learning algorithms can lead to a massive combinatorial search of new designs that could not have been feasibly discovered in real life.

What is needed now is an exploration into methodologies that are parallel to the methods in computational science. There is a wealth of knowledge that has accumulated over the years to bring stability and accuracy to the methods of computational science. These methods may by analogy be applied by DL generative methods. The difference is that rather than being handcrafted, these methods are grown.

Further Reading

Explore Deep Learning: Artificial Intuition: The Improbable Deep Learning Revolution
Mathematics
Deep Learning
Artificial Intelligence
Recommended from ReadMedium