Overview
Examples
Screenshots
Comparisons
Applications
Download
Documentation
Tutorials
Bazaar
Status & Roadmap
FAQ
Authors & License
Forums
Funding Ultimate++
Search on this site
Search in forums












SourceForge.net Logo
Home » Developing U++ » U++ Developers corner » Value with type float
Value with type float [message #58151] Thu, 03 March 2022 13:34 Go to next message
abductee23 is currently offline  abductee23
Messages: 5
Registered: October 2018
Location: San Francisco
Promising Member
Hi,

i was wondering - when will float be supported by Value?
(couldn't find it in the roadmap)

in the interrim - is there a bazar or patch thingy one could point me to?

thanks in advance

--m
Re: Value with type float [message #58196 is a reply to message #58151] Sat, 19 March 2022 10:38 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
abductee23 wrote on Thu, 03 March 2022 13:34
Hi,

i was wondering - when will float be supported by Value?
(couldn't find it in the roadmap)

in the interrim - is there a bazar or patch thingy one could point me to?

thanks in advance

--m


Supporting float directly does not make much sense as you can store float to double and restore back without loosing any precision.

If you are about memory consumption, both would consume the same (sizeof(Value) is 16 and double is stored directly into 8 of those 16 bytes).

Now counterexample can be int vs int64. However, we still support 32-bit CPUs and OSes where int64 was HW type. double is HW on all platforms we dare to support...

Mirek
Re: Value with type float [message #58227 is a reply to message #58196] Thu, 31 March 2022 11:51 Go to previous messageGo to next message
abductee23 is currently offline  abductee23
Messages: 5
Registered: October 2018
Location: San Francisco
Promising Member
Hi Mirek,

you have no idea how much it pains me to read that.
i was very excited when i found upp back in the day 2005 ish - and realized that i have to never worry about maintaining my own ux library... and can focus on what i do best: graphics programming.

maybe i am seeing this too much from my own viewpoint - graphics?

before upp i viewed c++ as a "necessary evil" - you have with your code, and esp your forum posts have quiet an impact.
and you seem to be so many times on what i consider "the side of an argument" when it comes to technical things.

and - to be blunt - only in recent times the c++ world has caught up to where upp was a decade ago (somehow they celebrate it by doing to their standart whatever that is they are doing...)

ok, just to make sure i don't get misinterpreted as a "hey i can't start using your stuff until you give me X Y and Z"-person(you probably have had a lot of these)

anyways - over the last 15-ish years there was not a project where not on some level i either quickly hacked together something in upp - or made it a upp thing to begin with - that goes for work and private stuff.( see pictures below - only private projects stuff obviously)

beeing able to crank out a tool in a day or less has been an invaluable asset to my work and private coding life.
(the "just drag all the pngs to this tool and if will fix the alpha channel"-incident comes to mind ^^)

and the only actual problem that i am facing over and over again: floats - love'em or hate'em - the reality is they are essential to computergraphics.

dealing with float issiues/precission is a time honered "tradition" for cg and audio(esp snyth) programmers Smile

having a flot in memory - writing it out through value/json , then reading it again incurs a conversion and its not the same number - ( i guess on a personal level i am probably puzzled how this is not bothering you - but thats beside the point)

of course - i do not disagree that that more precision is better and preferred in a lot of cases - but gpus have a significant performance penalty for using doubles and there's nothing i can do about that.(opengl/d3d are also very creative when it comes to IEEE754)

so i guess my questions are: do you see any wiggleroom when it comes to Value/Jsonize?

I want to make sure its understood this is coming from a a good place and is a genuine request - and i guess say thank you for the last 15 yrs of being there and improving upp.













Re: Value with type float [message #58228 is a reply to message #58227] Thu, 31 March 2022 13:49 Go to previous messageGo to next message
Tom1
Messages: 1212
Registered: March 2007
Senior Contributor
Hi,

I could see some benefit for supporting float in Value too. (I do signal processing with floats, so they frequently end up in various locations in my code.)
Having Value supporting float and EditFloat/EditFloatSpin added would allow cleaner code with dialogs.

Currently I have to round the float value to a clean double with roundr() to avoid excessive decimal places in EditDouble/EditDoubleSpin display. Also, when reading the value out from EditDouble/EditDoubleSpin, I will need to cast first to (double) and only thereafter to (float).

As an example, I have filtering frequencies controlled with:
void SetHPF(float fc);
float GetHPF();

Filling the EditDoubleSpin:
hpf<<=roundr(GetHPF(),3);

Reading the EditDoubleSpin:
hpf.WhenAction=[&](){ SetHPF((float)(double)~hpf); };


With float Value and EditFloatSpin support I would expect to work with:
hpf<<=GetHPF();

And:
hpf.WhenAction=[&](){ SetHPF((float)~hpf); };

Anyway, changes in Core/CtrlCore/CtrlLib are something for Mirek to decide.

Best regards,

Tom
Re: Value with type float [message #58229 is a reply to message #58228] Thu, 31 March 2022 15:14 Go to previous messageGo to next message
Tom1
Messages: 1212
Registered: March 2007
Senior Contributor
Hi,

Now here's an uneducated, quick and dirty attempt to support float as Value.

DISCLAIMER: This will likely break something and cause all kinds of trouble, as I do not understand most of the fine details of Value/XML/JSON or Core for that matter. So, if you wish to take the risk and test this, please remember to revert back to official sources before getting back to serious work. And also destroy your copy of these attached files.

Best regards,

Tom
Re: Value with type float [message #58231 is a reply to message #58227] Fri, 01 April 2022 11:03 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
abductee23 wrote on Thu, 31 March 2022 11:51

having a flot in memory - writing it out through value/json , then reading it again incurs a conversion and its not the same number - ( i guess on a personal level i am probably puzzled how this is not bothering you - but thats beside the point)


But that is altogether different issue! Converting float or double to decimal text and back involves completely different set of problems.

Frankly, current "stable" version (2021.1) has this botched up a bit. Here the IEEE standard states that 15 digit double numbers must be converted from text and back without a change. We were short on this promise, but this is hopefully fixed in the upcoming version.

Anyway, conversion from float to double is basically only adding zeroes to mantissa, converting from double back to float involves in most cases (*) just rounding the same additional bits (if they are zero, rounding is obviously down).

(*) - there is of course issue of range (float is about e-38 to e+38 while double e-308 to e-308) and denormals, but that is in most cases bedides the point..

Mirek
Re: Value with type float [message #58232 is a reply to message #58228] Fri, 01 April 2022 11:07 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
Tom1 wrote on Thu, 31 March 2022 13:49
Hi,

I could see some benefit for supporting float in Value too. (I do signal processing with floats, so they frequently end up in various locations in my code.)
Having Value supporting float and EditFloat/EditFloatSpin added would allow cleaner code with dialogs.

Currently I have to round the float value to a clean double with roundr() to avoid excessive decimal places in EditDouble/EditDoubleSpin display. Also, when reading the value out from EditDouble/EditDoubleSpin, I will need to cast first to (double) and only thereafter to (float).

As an example, I have filtering frequencies controlled with:
void SetHPF(float fc);
float GetHPF();

Filling the EditDoubleSpin:
hpf<<=roundr(GetHPF(),3);



Uhm, roundr is sort of sin of past. Perhaps it is a bad idea to pretend that either float or double are "decimal"...

That said, maybe we should just add operator float to Value and constructor from float (if that one is even needed)?

That would solve most of those additional casts that you do not like.

Mirek
Re: Value with type float [message #58233 is a reply to message #58232] Fri, 01 April 2022 11:13 Go to previous messageGo to next message
Tom1
Messages: 1212
Registered: March 2007
Senior Contributor
Hi Mirek,

Would that solve my EditDoubleSpin showing 0.002000000095 instead of 0.002 when I remove the roundr(xxx,3)?

Best regards,

Tom
Re: Value with type float [message #58234 is a reply to message #58233] Fri, 01 April 2022 12:06 Go to previous messageGo to next message
Tom1
Messages: 1212
Registered: March 2007
Senior Contributor
I see. Simply adding operator float to Value:
	operator float() const           { return (float)(double)*this; }

removes need for any casting at all. The required code gets clean:
hpf.WhenAction=[&](){ SetHPF(~hpf); };

EDIT: Removed from here my stupid idea to round float when constructing a Value.

Best regards,

Tom

[Updated on: Fri, 01 April 2022 14:57]

Report message to a moderator

Re: Value with type float [message #58235 is a reply to message #58234] Fri, 01 April 2022 14:03 Go to previous messageGo to next message
Tom1
Messages: 1212
Registered: March 2007
Senior Contributor
Hi,

The following code portrays the float rounding issue:
#include <Core/Core.h>

using namespace Upp;

CONSOLE_APP_MAIN
{
	Value v(0.002f);
	Cout() << v << "\n";
	Cout() << FormatDouble(v) << "\n";
	Cout() << FormatG(v,7) << "\n";
}

The result of running the above follows:
0.0020000000949949
0.0020000000949949
0.002
<--- Finished, press [ENTER] to close the window --->

I do not know how to solve this cleanly. In any case a regular user seeing 0.002000000095 in a field where he expects to see 0.002, will not be happy about it. For years I have used roundr() all over the code to fix this up, but having a solution hidden in Core would be awesome! Smile

Best regards,

Tom
Re: Value with type float [message #58236 is a reply to message #58235] Fri, 01 April 2022 15:26 Go to previous messageGo to next message
Tom1
Messages: 1212
Registered: March 2007
Senior Contributor
OK, here's an idea to handle the EditDouble/EditDoubleSpin rounding issue. Adding something like:
hpf.Pattern("%.7g");

to the constructor of the dialog. This will yield possibly sufficient rounding to the float value being represented as double to avoid excessive decimals.

Of course it would be nice to have such 'float compatibility' Pattern -feature available as a flag / checkbox in layout editor for EditDouble, EditDoubleSpin and the NotNull relatives.

Best regards,

Tom
Re: Value with type float [message #58237 is a reply to message #58235] Sat, 02 April 2022 01:31 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
Tom1 wrote on Fri, 01 April 2022 14:03
Hi,

The following code portrays the float rounding issue:
#include <Core/Core.h>

using namespace Upp;

CONSOLE_APP_MAIN
{
	Value v(0.002f);
	Cout() << v << "\n";
	Cout() << FormatDouble(v) << "\n";
	Cout() << FormatG(v,7) << "\n";
}

The result of running the above follows:
0.0020000000949949
0.0020000000949949
0.002
<--- Finished, press [ENTER] to close the window --->

I do not know how to solve this cleanly. In any case a regular user seeing 0.002000000095 in a field where he expects to see 0.002, will not be happy about it. For years I have used roundr() all over the code to fix this up, but having a solution hidden in Core would be awesome! Smile

Best regards,

Tom


This can actually be a bug in formatting routine. I will check ASAP.

Mirek
Re: Value with type float [message #58238 is a reply to message #58236] Sat, 02 April 2022 01:31 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
Tom1 wrote on Fri, 01 April 2022 15:26
OK, here's an idea to handle the EditDouble/EditDoubleSpin rounding issue. Adding something like:
hpf.Pattern("%.7g");

to the constructor of the dialog. This will yield possibly sufficient rounding to the float value being represented as double to avoid excessive decimals.


Yes, this is the correct solution - do decimal rounding when the number is actually converted to decimals.

Mirek
Re: Value with type float [message #58239 is a reply to message #58235] Sat, 02 April 2022 09:43 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
Tom1 wrote on Fri, 01 April 2022 14:03
Hi,

The following code portrays the float rounding issue:
#include <Core/Core.h>

using namespace Upp;

CONSOLE_APP_MAIN
{
	Value v(0.002f);
	Cout() << v << "\n";
	Cout() << FormatDouble(v) << "\n";
	Cout() << FormatG(v,7) << "\n";
}

The result of running the above follows:
0.0020000000949949
0.0020000000949949
0.002
<--- Finished, press [ENTER] to close the window --->

I do not know how to solve this cleanly. In any case a regular user seeing 0.002000000095 in a field where he expects to see 0.002, will not be happy about it. For years I have used roundr() all over the code to fix this up, but having a solution hidden in Core would be awesome! Smile

Best regards,

Tom


OK, so it is correct behaviour. You can simplify that to

	double x = 0.002;
	DDUMP(x);
	float fx = x;
	x = fx;
	DDUMP(x);


which produces exactly the same result. Now for an explanation what is going on here:

0.002 cannot be exactly represented as double. Normal double formatting (as used in DDUMP) rounds for 15 decimal digits which is guaranteed precision and it all yields a "correct" result (in both directions, closes value is choosen and everything is "fine").

Anyway, when you convert it to float, you have to round at equivalent of about 7 valid digits (you have to cut 28 bits of mantissa). In this case, the last mantissa bit of float is rounded up to 1 as that is the closest value to original double. When converting back to double, this cannot be undone, hence you get those "949949" digits at the end.

That said, all of this made me think that if we knew that it is float in Value, we might be able to apply for something like FormatG(v,7) instead when displaying it (e.g. in EditDouble).


Mirek
Re: Value with type float [message #58240 is a reply to message #58239] Sat, 02 April 2022 10:55 Go to previous messageGo to next message
Tom1
Messages: 1212
Registered: March 2007
Senior Contributor
Hi Mirek,
Quote:
That said, all of this made me think that if we knew that it is float in Value, we might be able to apply for something like FormatG(v,7) instead when displaying it (e.g. in EditDouble).

Would that involve introducing:
const dword FLOAT_V  = 13;

and 'DOUBLE_V' -like processing for it, except when putting it out in FormatG() and friends?

This is in some ways pretty much what I attempted to do with the above "float Value prototype" above, but that is really bad as I do not really understand all the details of Value. You may wish to take a look anyway -- and then trash it. Smile

Best regards,

Tom
Re: Value with type float [message #58241 is a reply to message #58240] Sat, 02 April 2022 11:26 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
Tom1 wrote on Sat, 02 April 2022 10:55
Hi Mirek,
Quote:
That said, all of this made me think that if we knew that it is float in Value, we might be able to apply for something like FormatG(v,7) instead when displaying it (e.g. in EditDouble).

Would that involve introducing:
const dword FLOAT_V  = 13;

and 'DOUBLE_V' -like processing for it, except when putting it out in FormatG() and friends?

This is in some ways pretty much what I attempted to do with the above "float Value prototype" above, but that is really bad as I do not really understand all the details of Value. You may wish to take a look anyway -- and then trash it. Smile

Best regards,

Tom


Well, I guess I have to sleep over this.... FormatG(v, 7) being the only difference in processing there seems a bit too little...

Mirek
Re: Value with type float [message #58242 is a reply to message #58241] Sat, 02 April 2022 13:31 Go to previous messageGo to next message
Tom1
Messages: 1212
Registered: March 2007
Senior Contributor
No problem... I trust you will soon come up with some astonishingly smart three line solution for the task! Smile

Best regards,

Tom
Re: Value with type float [message #58289 is a reply to message #58242] Mon, 11 April 2022 16:52 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
Tom1 wrote on Sat, 02 April 2022 13:31
No problem... I trust you will soon come up with some astonishingly smart three line solution for the task! Smile

Best regards,

Tom


Nothing too smart for now, but I have added ConvertFloat and EditFloat.

The jury is still out for float in Value.... do not want to do that now. It feels like while it fixes some issues (e.g. Value->JSON conversion when the values went through float precision), there might be many caveats.
Re: Value with type float [message #58293 is a reply to message #58289] Tue, 12 April 2022 09:26 Go to previous messageGo to next message
Tom1
Messages: 1212
Registered: March 2007
Senior Contributor
mirek wrote on Mon, 11 April 2022 17:52
Tom1 wrote on Sat, 02 April 2022 13:31
No problem... I trust you will soon come up with some astonishingly smart three line solution for the task! Smile

Best regards,

Tom


Nothing too smart for now, but I have added ConvertFloat and EditFloat.

The jury is still out for float in Value.... do not want to do that now. It feels like while it fixes some issues (e.g. Value->JSON conversion when the values went through float precision), there might be many caveats.


Hi Mirek,

Thanks! EditFloat works fine now. However, there are a couple of things more. First, could you add float operator to Value for easy reading of EditFloat:
operator float() const           { return Is(DOUBLE_V) ? (float)GetSmallRaw<double>() : (float)GetOtherDouble(); }

Second, can you add EditFloatSpin and EditFloatNotNullSpin variants?:
typedef WithSpin<float, EditFloat>			 EditFloatSpin;
typedef WithSpin<float, EditFloatNotNull>	 EditFloatNotNullSpin;

// And then some magic to make those two working and visible in layout editor.

Thanks and best regards,

Tom
Re: Value with type float [message #58294 is a reply to message #58293] Tue, 12 April 2022 13:40 Go to previous messageGo to previous message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
Done.
Previous Topic: Build U++ with CMake and Clang Example
Next Topic: A temporary solution to garbled code in U++applications built through MSVC
Goto Forum:
  


Current Time: Fri Apr 19 08:13:05 CEST 2024

Total time taken to generate the page: 0.03797 seconds