doing DECLARE @someNum NUMERIC(10); means that the range of the variable will be limited by 10 digits.
Actually, you're either very wrong in that assertion, or SQL server is hugely incompatible with other DB engines. Typically, you have:
- NUMERIC(precision, scale)
- NUMERIC(precision)
In the second case, scale is zero, i.e. you can only handle integers; precision is the maximum total number of digits with the specified scale (meaning integers in the second case).
By contrast, you seem to be reading numeric(10) as meaning "any number as long as there are 10 digits or less", for which there is no (best I'm aware anyway) SQL construct short of single/double float types (whose name differ per DB engine).
The numeric types in the databases seem to be not tied to underlying hardware.
Indeed, they're not. Numeric/Decimal is an arbitrary precision number, stored very much like a varchar of huge length (1000+ digits). You can actually use it to store 1e100 + 1
as an exact value. You'll get 1
followed by zeros, and finally a 1
.
You sound like you need a float... The latter would store 1e100
when given 1e100 + 1
, and would yield 1e100
.
You're on the right track. The controller is what binds the app together, so passing it around to the various view and model classes is fine.
However, don't think that just because you have a controller, all widgets must use that controller for everything. For instance, I wouldn't put the onclick
method in the controller. The controller should be for routing business logic, but what you're doing is mostly specific to the GUI.
I think a good general rule of thumb is that GUI events and callbacks should be within the GUI module. They then call the controller when interfacing with business logic. Fetching a string from the GUI itself is not business logic.
So, instead of:
# GUI module
button = Button(..., command=controller.on_click)
# Controller module
def on_click():
var1 = GUI.widget_entry.get()
self.do_something(var1)
I would do this:
# GUI module
button = Button(..., command=on_click)
def on_click():
var1 = widget_entry.get()
controller.do_something(var1)
With the above, the controller doesn't need to know what widgets are part of the GUI. All it does is provide an interface through which the GUI can request services.
If you prefer to keep the on_click
in the controller, that's possible too, and not completely unreasonable. However, instead of building in knowledge of the GUI widgets into the controller, give the GUI an interface that the controller can use.
For example, instead of doing GUI.widget_entry.get()
, the controller would call an accessor such as GUI.get_entry_widget_value()
. That allows you to refactor the GUI without having to change the controller. If you move the entry to the_widget_entry
instead of widget_entry
, the controller can be completely unaware and still function properly.
Best Answer
It is typical to compare
float
s using a tolerance, rather than by equality. This both avoids some of the issues with floating point arithmetic on computers and allows you to specify an appropriate level of precision. In your case, if you only care about hundredths of a unit:For example: