<p>Sorry if this sounds trivial, but I have no previous experience with static typing.</p>
<p>I'm working on a scoring algorithm. The tricky part is that the user may or may not fill all the form fields. If I initialize an int or float it will default to 0 (zero), but this is also a possible value that the user could input. How do I handle this?</p>
<hr/>**评论：**<br/><br/>Fwippy: <pre><p>You can also store it as <code>*int</code> - use <code>nil</code> for "not entered" and anything else for an actual value.</p></pre>jaetteintemer: <pre><p>Not OP but can you explain further how that works/solves the problem?</p></pre>hahainternet: <pre><p>*int is a pointer to an int. If the pointer is nil, nothing was entered. If the pointer is valid, but the int is 0, a 0 was entered. Go's type system is quite simple and so this is often the best option.</p></pre>tmornini: <pre><p>You could turn each entry into a struct of the value and a Boolean which indicates whether it was filled in or not.</p></pre>os_pirata: <pre><p>Would this compromise performance? Long story short: client had the system done with another company 4 years ago. Software was really slow because millions of scorings would be calculated daily. They failed to provide an old copy of the system and dont even know the language it was developed.</p>
<p>I'm mostly webdev. PHP/Python/Js. I was already taking my first steps in Go and convinced my boss to let me give it a try because it would be really fast. Thanks!</p></pre>barsonme: <pre><p>Well, yes, but probably not as much as you'd get from just using a language without static types.</p>
<p>There are some other tricks you can do if you know, e.g., that you're only using N bits of your number, but tmornini's suggestion was good.</p>
<p>Another way to do it is to use *int or *float, but that could cause memory accesses (and other stuff) which is (probably) slower (still faster than PHP/Python/JS, though) than type Number struct {N int; Valid bool }</p></pre>os_pirata: <pre><p>I'll try that then. Thank you both very much.</p></pre>dbud: <pre><p>I believe that *int, *float is far better as the cost of marshaling an entire other 2 objects (the wrapper object + the valid bool) is probably so much slower </p>
<p>As always, benchmark and see. But I'd be shocked if a memory dereference (looking up a pointer) is slower than parsing the extra text. </p>
<p>Especially since you are doing this only a few million times a day.... that's not exactly a ton of events these days. You should be able to parse millions per minute unless your data is huge.</p></pre>earthboundkid: <pre><p>No, the pointer costs two words in the common case (valid pointer + valid int) and one word in the special case (nil pointer). Bool plus int is always two words. But! The pointer causes memory fragmentation which means it's much slower and more memory wasting than the boolean once you look at the big picture. </p></pre>tmornini: <pre><p>Perhaps.</p>
<p>Dereferencing is not free...</p></pre>tmornini: <pre><p>I suspect it would, but it's shocking difficult to guess these days, but performance is essentially always secondary to readability and correctness.</p>
<p>I like using a pointer and checking for null, but dereferencing <em>may</em> be slower than the extra payload.</p>
<p>And, how fast does it need to be? Depending on what you're doing it's not hard to imagine hitting external bottlenecks before low-level data handing is an issue.</p></pre>earthboundkid: <pre><blockquote>
<p>Would this compromise performance?</p>
</blockquote>
<p>A single boolean field has basically no effect compared to almost any other thing you could possibly do. If you're coming from a dynamic language, you're already saving an obscene amount compared to using dictionaries form run time look ups like they do. </p></pre>Redundancy_: <pre><p>I would expect better performance from bool + int based on predictable memory paging to the cache and branch prediction, but that's getting down to data-oriented design - probably not remotely necessary here.</p></pre>tvmaly: <pre><p>I ended up using roaring bitmaps to handle whether something is set or not in my Go project. They were fast, and took up much less memory</p></pre>os_pirata: <pre><p>I like the sound of this.</p></pre>os_pirata: <pre><p>Will this work with floats or just ints? I'm even considering have 2 decimals fixed precision so in the case I have to use ints I'll just multiply by 100. </p></pre>WillTheHatt: <pre><p>If you're using it as an int field you can also default it as -1 (not submitted) and 0-10 for actual values.</p></pre>JokerSp3: <pre><p>Pointer to integer is an option.</p>
<p>If you are using a network serialization like json you could deserialize into the old value strut and it would only override the values set.</p>
<p>It all depends a LOT on architecture and without more detail it's hard to give you the best solution.</p></pre>os_pirata: <pre><p>The algorithm is really simple. I got ~100 fields form going to mysql (5 normalized tables). All of them are either INTEGER(11) or DOUBLE(15,2). The algorithm itself if basically 100 conditions.</p>
<pre><code>if field1 > 1,3 { score += 12 } else { score -= 3 }
</code></pre></pre>JokerSp3: <pre><p>How is the form data getting into your application? If http post you could look for specific keys existing (and use string parsing as someone above suggested)</p>
<p>If its JSON see my previous suggestion.</p>
<p>If the data is being injected into mysql first and then the Go application is reading out of mysql you will have to figure out how the mysql library pulls data out to figure out that answer but I bet it would be similar to JSON.</p></pre>os_pirata: <pre><p>The application itself is in php. Only the scoring will be in golang. Im still deciding if its going to interact directly with the db or if it will be a json service, in which case will probably be json rpc.</p></pre>Manbeardo: <pre><p>If you're sending data to/from MySQL and your scoring algorithm isn't obscenely complex, it's a safe bet that the database interface will be your bottleneck.</p></pre>: <pre><p>[deleted]</p></pre>TRAPFLAG_8: <pre><p>slow.</p></pre>weberc2: <pre><p>not slow. his data is almost certainly coming as a string anyway, which means he's going to have to parse it at some point. The biggest problem with this proposal is that it conflates an empty field with a non-numeric field (e.g., entering "asdfadfsadfasdfa" will be treated as empty, when perhaps the better UI decision is to notify the user of his error).</p></pre>
