Home » U++ Library support » U++ Core » Value: why not float support?
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Re: Value: why not float support? [message #28531 is a reply to message #28444] |
Mon, 06 September 2010 10:40   |
 |
mirek
Messages: 13975
Registered: November 2005
|
Ultimate Member |
|
|
| kohait00 wrote on Thu, 02 September 2010 05:24 |
so is there any hope for float:)
|
It still does not have any point. What benefits is it supposed to do? Save 4 bytes per Value? - Would not happen, allocator would align the block to 16bytes multiples anyway.
Maybe would save conversion runtime, but if you are using Value for HPC, you are doing something wrong anyway.
However, keep asking. I guess your question help to clarify things and design intentions.
[Updated on: Mon, 06 September 2010 14:25] Report message to a moderator |
|
|
|
|
|
| Re: Value: why not float support? [message #30176 is a reply to message #28537] |
Mon, 13 December 2010 15:47 |
 |
kohait00
Messages: 939
Registered: July 2009
Location: Germany
|
Experienced Contributor |
|
|
sorry to bother again here..
in my struggle with the OSC protocol, a again came across this issue. OSC supports, together with int, int64, bool, etc.. the float AND double extra.
since i am using Value as the prefered container for all of it, i so far was working with the double as float Value, simply ignoring the fact that float doesnt exist.
i could use double for both, double and float, question, i need to distinguish them, because they need to be sent with different markers. so i have no means to distinguish them..
this is not possible when using double for both double and float:
...
if(v.Is<double>()) { /*send as double, "/osc/message,d 137884828388288.23828" */ }
else if(v.Is<float>()) { /*send as float, "/osc/message,f 123.43" */ }
and, also, the implicit conversions would be not possible.
any idea how to do that?
EDIT:
meanwhile i tried to extend value accordingly. here is a patchfile to revision 2902 to show where changes would occure.
[Updated on: Mon, 13 December 2010 16:31] Report message to a moderator |
|
|
|
|
|
| Re: Value: why not float support? [message #30208 is a reply to message #30204] |
Wed, 15 December 2010 16:41 |
|
kohait00
Messages: 939
Registered: July 2009
Location: Germany
|
Experienced Contributor |
|
|
it's not the problem whith receiving..
on receive, i could destinguis if it's a float, or a double, and map both to use Value double..
but since the API uses Value directly, which is unbelievably easy. it determines what to send by simply checking the type.
nevertheless, it's important to differ them, since there are old target devices that only understand spec 1.0, which only has float. and newer devices also support spec 1.1 double as extra type, and maybe even expect it for some parameters, while still demanding float for some other..and how to destinguish them?
hope to have cleared it up a bit (and a bit of a bit convinced you 
i still could use RichValue<float>, and all the stuff for my own, but it would lack things like Value::IsNumber() and the implicit conversions, which are upp gloabl, but are reaaly appealing..
please, rethink it, float is an own type, just as int64, even if on many systems its breaks down to double in assembler/cpu arch, but compiler still differs them..
|
|
|
|
| Re: Value: why not float support? [message #30255 is a reply to message #30208] |
Mon, 20 December 2010 23:08 |
rylek
Messages: 79
Registered: November 2005
|
Member |
|
|
Hi there!
I'm afraid this is a difficult nut to crack. At first glance it seems that by adding the support of a new type (like float) to Value we are just enriching the U++ environment and not losing anything. Yet in reality I'm afraid we are losing some of Value's clarity. I, for instance, on numerous occasions make a switch over a Value's GetType(). Now, for instance, when we agreed some time ago to add BOOL_V and INT64_V, I had to manually adjust them to be able to accept a new value subtype. Some code broke in a very tricky way back then.
All right, my switches might not be the cleanest programming technique; at least I should finally ask Mirek to agree to add a series of inline functions to Core/Value.h to check Value types for these convertible groups of datatypes; like
inline bool IsNumberType(int value_type)
{ return value_type == BOOL_V || value_type == INT_V
|| value_type == INT64_V || value_type == DOUBLE_V; }
- equivalents of .IsNumber() etc. Value member functions, just operating on the type constants; but imagine what the above is going to look like when, after FLOAT_V, we continue to add LONG_DOUBLE_V and [U]INT8/16/32/64_V.
I myself, when working with ActiveX, for instance, sometimes find myself longing for better type distinction in Value in order to be able to provide a better mapping between Value and VARIANT. But then I ask myself: do I want U++ to become such pile of mess as the COM and Value such monster as VARIANT?
And yet, it's evident that on numerous previous occassions we didn't adhere to the position we now hold. We have already extended the numeric type set from the original INT_V / DOUBLE_V pair (not mentioning that even INT_V is in fact superfluous) to INT64_V and BOOL_V (see? we didn't upgrade INT_V to 64-bit, we added a different value type). We have STRING_V and WSTRING_V (here there is some justification because conversion of long binary blocks transferred through Strings, which was always seen as a sound option under U++, is time and memory consuming and potentially even lossy), DATE_V and TIME_V.
This whole discussion would be much easier if the value type was two-dimensional; the above type families (reflected in the member functions IsNumber(), IsString() and IsDateTime()) could then represent a 'principal' value type which would have a 'biggest' or 'most general' representant (double, WString and Time in the above case) and a (perhaps extensible) family of derived subtypes which would be able to convert themselves to and from the type family representant.
But it's not and, as I see it, it would cost all of us many a hair to seamlessly rework it like this. Even so, you still have situations like serializing Values where it's extremely unpleasant to have the type family growing all the time.
Regards
Tomas
|
|
|
|
| Re: Value: why not float support? [message #30259 is a reply to message #30255] |
Tue, 21 December 2010 08:20 |
|
kohait00
Messages: 939
Registered: July 2009
Location: Germany
|
Experienced Contributor |
|
|
generally you are right about that, we should aim to keep u++ core slim and not extend it for every purpose. i also agree that, having Value 'user-extensible', like you mentioned it in the 2-dimensional way would do a great deal, so everyone who really needs it and cant avoid converts, can extend it. my propose actually was exactly because IsNumber global functions could not be made float-aware in user way.
OTOH, we should not take the risk to spare out at wrong places. we are talking about intrinsic types, not about bloated class libraries. they are there and *are* still widely used as API, especially for embedded systems. compare it here to a screwdrivers set, where one size is missing. while one generally can spare out some other tools in a collection, there are some general things that *always* need to be there.
missing float *is* like a missing screwdriver.
and one more: design aspects for extension of upp should not only be concerned about not making code possibly bricked (this can be fixed) but also to think about 'what would be the logical, right and most usefull and most performant way'..
so, please, consider float again 
|
|
|
|
| Re: Value: why not float support? [message #30315 is a reply to message #30259] |
Fri, 24 December 2010 12:39 |
|
mirek
Messages: 13975
Registered: November 2005
|
Ultimate Member |
|
|
| kohait00 wrote on Tue, 21 December 2010 02:20 |
and one more: design aspects for extension of upp should not only be concerned about not making code possibly bricked (this can be fixed) but also to think about 'what would be the logical, right and most usefull and most performant way'..
so, please, consider float again
|
I am still considering it. I even added value type testers already.
Anyway, to demonstrate a few things, this code would break immediately with float Value type:
float x;
SQL.Execute("select FOO from BAR where VALUE > ?", x);
which sounds quite dangerous to me. Plus we would have to define a new Null constant etc...
Perhaps it would help me if I understood what you do plan to do with it. Frankly, to depend only on Value type to induce call signature seems like a little bit dangerous practice to me... To easy to make things go very very bad.
[Updated on: Fri, 24 December 2010 12:40] Report message to a moderator |
|
|
|
| Re: Value: why not float support? [message #30318 is a reply to message #30315] |
Fri, 24 December 2010 13:55 |
|
kohait00
Messages: 939
Registered: July 2009
Location: Germany
|
Experienced Contributor |
|
|
i admit i have no idea about sql layer in Upp, havent needed it so far. so i dont really understand how this would break it..maybe you can explain it in some 2 phrases..
the new Null value is imho not really a problem.
well, my problem, like described above, is, that i use the cool upp types, which can be packed into Value, as direct feed to the OSC layer, which basicly supports the intrinsic types, but this depends on the spec version, 1.0, or additinoally, 1.1.
1.0 supports int, float, string and blob (binary).
1.1 *additionally* supports int64, double, bool, datetime, etc..
so i decided to simply use the Value as container type, also because there are many implicit conversion possibilities, which spare a lot of work. thats why the extension is crucial, for me at least
i was going well with the 'float as double' handling, as long as keeping spec 1.0 support only, but when, cleanly, extending to 1.1, i need both types to be distinct.
that'd be no problem, i could define and use a custom RichValue<float> and use it just like that, but the conversion mechanisms cant be enriched with user code to support it. IsNumber(), and the implicit converters.
if that'd were possible, no hassle.
but nevertheless, float beeing intrinsic type was finally a motivation to extend it.
i have to admit, char, unsigned types and all that aren't there as well, but they are at least, binary compatible types, means
a char could be banary transported as int, and be interpreted as is later. this holds true for unsigned types as well. but float and double, when transported / serialized over net etc. are *not* binary compatible. though they might be treated equal in cpu, on the net and serialsation, they arent. float is 4 byte, double is 8. this is another pro for float.
if i understood what else might brick with it, i could help thinking of a solution. but i'd rather prefer to make sql layer aware of float than to spare out on float (IMO ofcorse)
afaik, sql also supports both (and some more)
http://dev.mysql.com/doc/refman/5.0/en/numeric-type-overview .html
so let me know, where i can help, if so.
EDIT:
i figured out, that all major database concepts (mysql, postgre sql, oracle, mssql) support float (or single precision).
the only exception is sqlite3, which only supports double, but one could fix this very fast i think, mapping float to double there.
[Updated on: Fri, 24 December 2010 14:53] Report message to a moderator |
|
|
|
| Re: Value: why not float support? [message #30336 is a reply to message #30318] |
Sat, 25 December 2010 10:48 |
|
mirek
Messages: 13975
Registered: November 2005
|
Ultimate Member |
|
|
| kohait00 wrote on Fri, 24 December 2010 07:55 |
i have to admit, char, unsigned types and all that aren't there as well, but they are at least, binary compatible types, means
a char could be banary transported as int, and be interpreted as is later. this holds true for unsigned types as well. but float and double, when transported / serialized over net etc. are *not* binary compatible. though they might be treated equal in cpu, on the net and serialsation, they arent. float is 4 byte, double is 8. this is another pro for float.
|
AFAIK, there is little difference in promoting char to int and casting back and doing the same with float and double.
| Quote: |
i figured out, that all major database concepts (mysql, postgre sql, oracle, mssql) support float (or single precision).
the only exception is sqlite3, which only supports double, but one could fix this very fast i think, mapping float to double there.
|
Sure, and every single SQL engine accepts double there (then perhaps casting it to float internally).
Anyway, that is not a problem. The issue is that existing code, which includes SQL/U++ connectors (there is about 5 of them), does not expect to get something like V_FLOAT as Value.
Currently, any float gets promoted to 'double', so it is send as double and everything works. Make Value to remember that such a type is 'V_FLOAT' and you are sudenly missing appropriate case in switch....
Which is quite easy to fix in connectors and in 'uppsrc', actually, but IMO it is little demanding to expect every U++ users to scan through his code for similar cases.
To do that, I would need some solid reason...
And you still have not provided any clue how do you plan to use this (A bit of end-user code would really be helpful). If you need to support 'char' in your interface, I do not see a single reason why you could not support 'float' the very same way.
Mirek
|
|
|
|
| Re: Value: why not float support? [message #30363 is a reply to message #30336] |
Sun, 26 December 2010 11:28 |
|
kohait00
Messages: 939
Registered: July 2009
Location: Germany
|
Experienced Contributor |
|
|
well, i'm not trying to invent things to convince you of something. if i cant than maybe the reasons are not strong enough
i'm planning to release a test environment for OSC past xmas, where i have some time to clean up things, order code and make some small docus. but for that to happen i also need to know where the train in terms of value type extension goes, so as to be able to use implicitly float or to need to invent some hack to handle this. because this affects the API. (also, there is some controls issue, since OSC only makes some sense when there are good and easy menas to generate the messages, see TouchOSC for iphone).
concerning double and float in databases: i'm sure the major db's *dont* simply convert it internally. at least not in terms of storage (millions and millions of rows with wasted 4 bytes for double, where float had been enough cant be aforded). thats why one generally is to think of a good, well fitting model/schema for one's problem, not to waste space and performance when handling the data.
as i stated before, i am not fixed on float extension, when there is a possibility to 'enrich' IsNumber() and the implicit converters by a user type. maybe we should think of that, instead.
|
|
|
|
Goto Forum:
Current Time: Fri Apr 19 05:58:25 CEST 2024
Total time taken to generate the page: 0.04938 seconds
|
Members
Pages
Help
Register
Login
Home
