On 2014/03/01 10:32, Darren Duncan wrote:

If you're going by semantics though, the meanings are quite different.

A real number represents a point on a line and can be either a rational or irrational number. (And a complex number is a point on a plane.) An important bit is that a real is a more abstract concept and doesn't imply a single right representation.

In contrast, a float is much more specific, defining also a representation, and as such a float can only be a rational number (x*y^z where all 3 are integers, and y is typically 2) and not an irrational. (Or I suppose if you allow {x,y,z} to be non-integers then a float is even more about a representation.)

Speaking in terms of programming language design, "real" is best suited for an abstract type name, that is one that defines an interface for using a set of types, same as "numeric". Whereas, "float" is best suited for the name of a concrete type, like with "integer" and "ratio". (Well strictly speaking all of these could be abstract types, but the latter set are more specific in meaning, and in particular "ratio" and "float" imply a representation while the others don't.


I take your point, and thanks for the dissertation.

I would like to point out though that the "implied" meaning of words that were pressed into service in programming languages have rarely survived the transition. A "String" really implies lengthy extrusions of fibrous bundles (but smaller than a "rope") and "Long" has no single numerical implication outside of a programming language. Other less interesting examples abound but suffice to say that while true meanings of words can and should influence their use within code, an altered understanding that fits a binary universe are often (if not always) the defacto implication. - much as the mathematicians among us abhor the idea.

Hence the copious amount of aliases which attempt to align the meanings between historically different names for essentially the same function or functionality in programming terms - all of which can be argued for in implication or semantic terms.

i.e. - You are correct - but I don't see it ever being applicable, or indeed 
apply-able, as a standard.

_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Reply via email to