What is the difference between REAL4, REAL8 and FLOAT ???
Jean Peskov
I understand that difference in capacity. But what is it for all three types
???
Thanks
--
Jean Peskov chj...@transts.ru
Phil McGuinness
I use REAL4 for most Float type operations.
The REAL8 is a bit of overkill for most Financial type transactions.
The FLOAT seems to have developed a questionable reputation.
One caveat with REAL4 and REAL8 over FLOAT when passing by Reference is that
they return ZERO.
Problem has been reported to development but as log as you are aware of it
you can work around it.
Phil
---
"Jean Peskov" <chj...@transts.ru> wrote in message
news:3bc2...@news.ptt.ru...
Jean Peskov
> Essentially the size of BYTES taken to store Float type values.
>
> I use REAL4 for most Float type operations.
> The REAL8 is a bit of overkill for most Financial type transactions.
>
> The FLOAT seems to have developed a questionable reputation.
>
> One caveat with REAL4 and REAL8 over FLOAT when passing by Reference is
that
> they return ZERO.
> Problem has been reported to development but as log as you are aware of it
> you can work around it.
--
Jean Peskov chj...@transts.ru
Malcolm Gray
>
> I understand that difference in capacity. But what is it for all three
types
REAL4 and REAL8 - always value based
FLOAT - contained formatting information and are stored in GC controlled
memory (like strings and arrays etc).
The amount of space allocated to the number in a real8 and float are the
same
and I think have the same interpretation.
Malcolm
D.J.W. van Kooten
wrote:
>> The FLOAT seems to have developed a questionable reputation.
That's interesting. I some CA white paper, I found a recommedation to
use FLOAT for everything that has digits. Saves you thinking about
real4/real8. Also, it was said there that for any non digit number,
use DWORD, as the compiler nor CPU saves any time on using INT or BYTE
digits.
Dick van Kooten
Geoff Schaller
REAL4 and REAL8 are static memory objects and FLOAT is of course dynamic,
and hence managed by the GC. All can be used to represent floating point
numbers by CA highly recommends only the usage of FLOAT. In fact, at Devcon
Germany last year, Angswillie expressed extreme dismay at the thought of
anyone avoiding floats for REAL8. He should know - he wrote the code <g>.
The main thing against REAL4 and REAL8 is that of course they cannot be used
in that mode. For all floating point operations and conversions, REAL4 and
REAL8 are both first converted internally to FLOAT, used and then converted
back. They are thus quite slow in comparison to FLOAT and involve unecessary
runtime conversions. Their main use is as compatibility data types for
Clipper etc. All formats can only represent 15 decimal places of accuracy
but REAL4 is 32 bits wide, REAL8 is 64 bits and a FLOAT is 80. Consequently
they can offer differing number ranges but these numbers are so tiny and so
large that it hardly matters <g>.
Essentially, avoid REAL4 and REAL8.
Geoff
PS - there were some FLOAT issues with VO 2.0 but most of these were dealt
with in 2.5.
"Jean Peskov" <chj...@transts.ru> wrote in message
news:3bc2...@news.ptt.ru...
Malcolm Gray
"Geoff Schaller" <geof...@bigpond.net.au> wrote in message
news:_fAw7.137158$bY5.6...@news-server.bigpond.net.au...
> Jean,
>
> but REAL4 is 32 bits wide, REAL8 is 64 bits and a FLOAT is 80.
Consequently
> they can offer differing number ranges but these numbers are so tiny and
so
> large that it hardly matters <g>.
Digging round in dynamic memory floats only use 64 bits of storage for the
number.
Geoff Schaller
compatibility mode to use all 80 bits so a lot will depend on your
environmental settings. However, use _Sizeof() and it will yield 10 bytes.
"Malcolm Gray" <malcol...@jobstream.co.uk> wrote in message
news:fnAw7.11$5x4.508@psinet-eu-nl...
Phil McGuinness
I reported that REAL4 and REAL8 by reference were being ZEROED.
Quote: "
----
REAL4 and REAL8 are not supposed to work for special features of CLIPPER
calling convention. Those types should be used only for C compatibility (to
call C DLL functions with arguments of type float or double).
---
End quote
-------
Snip[ All can be used to represent floating point numbers by CA highly
recommends only the usage of FLOAT]
Geoff, Prove it .. You agina make un unstubstatited claim using somebody
else name to justify it,
---
snip[ > The main thing against REAL4 and REAL8 is that of course they cannot
be used in that mode ]
Absolute Crap I have several applications that are all REAL4 and NO FLOATS
as I do not need the space wastage for FLOATS which are enormouse for
general financial data.
----
snip[ They are thus quite slow in comparison to FLOAT and involve unecessary
runtime conversions. Their main use is as compatibility data types for
Clipper etc. ]
Geoff, read what CA development report when the REAL4 or REAL8 reference
issue was raised. They quote 100% the opposite of what you said they say.
I have it in writing from them. You did not make this stuff up did you?
-----
snip[ All formats can only represent 15 decimal places of accuracy but REAL4
is 32 bits wide, REAL8 is 64 bits and a FLOAT is 80 ]
Hooraysomething I agree with you about.. and as I said REAL4 is more than
adequate for most VO business logic developement and when you have say 100
or 200 or 300 numeric fields in memory I do not need 80 bits be field if I
can do it in 32 which as you know is far more efficient for processor
handling.
Phil McGuinness
----------------------
"Geoff Schaller" <geof...@bigpond.net.au> wrote in message
news:_fAw7.137158$bY5.6...@news-server.bigpond.net.au...
Jean Peskov
Ginny Caughey
I attended the same session in Germany that Fru gave that Geoff presented. And
Geoff is right - Fru advised using FLOATs unless you have a specific
interrop-related need to do otherwise. If he (or other members of the CA dev
team) has a newer opinion, that's ok too and I'm sure a quote from the material
you have would help clear things up.
Ginny
"Phil McGuinness" <hey...@sherlock.com.au> wrote in message
news:mYIw7.2$4R....@nsw.nnrp.telstra.net...
Geoff Schaller
Perhaps if you attended a VO conference somewhere you could catch up on
these issues. Frew (whose 'proper' name is Angswillie) was quite specific
about the use of the REALs as being compatibility data types and you even
seem to agree with this point. But I need to correct the record you seem
hell-bent on breaking every 5 mins, REAL4 and REAL8 are converted to a FLOAT
internally and hence they are actually LESS effecient than floats. Given
that you might save a few precious bytes per variable in static memory,
reals still cause dynamic memory usage so you are saving nothing.
You spout some crap about CA quoting the opposite of what I said they said
yet you also fail to offer any reference to such information. My source is a
session I attended at a conference. There were some 30 other people in the
room and all of us were a little thunder-struck at first by these
revelations, which only left Frew even more perplexed.
Geoff
"Phil McGuinness" <hey...@sherlock.com.au> wrote in message
news:mYIw7.2$4R....@nsw.nnrp.telstra.net...
Malcolm Gray
> snip[ All formats can only represent 15 decimal places of accuracy but
REAL4
> is 32 bits wide, REAL8 is 64 bits and a FLOAT is 80 ]
>
> Hooraysomething I agree with you about.. and as I said REAL4 is more than
> adequate for most VO business logic developement and when you have say
100
> or 200 or 300 numeric fields in memory I do not need 80 bits be field if
I
> can do it in 32 which as you know is far more efficient for processor
> handling.
Lets see each decimal digit required 3.<something> bits. 15 significant
digits implies
at least 45 bits of storage but real4 is only 32 bits long, so real4 cannot
have
15 decimal digits of accuracy.
Malcolm
Geoff Schaller
The number of "bits" in this case is unfortunately irrelevant. It is the
exponent which takes up the extra and thus gives a greater range of numbers.
In all cases, the number digits in the mantissa is fixed to 15 so as to be
compatible with Clipper and other numeric formats. All 3 formats have
EXACTLY the same accuracy, ie the same number of significant digits. The
placement of the decimal point is irrelevant to the accuracy.
Geoff
"Malcolm Gray" <malcol...@jobstream.co.uk> wrote in message
news:LMUw7.10$Tb7.529@psinet-eu-nl...
Malcolm Gray
> That's not how it works <g>.
>
> The number of "bits" in this case is unfortunately irrelevant. It is the
> exponent which takes up the extra and thus gives a greater range of
numbers.
> In all cases, the number digits in the mantissa is fixed to 15 so as to be
> compatible with Clipper and other numeric formats. All 3 formats have
> EXACTLY the same accuracy, ie the same number of significant digits. The
> placement of the decimal point is irrelevant to the accuracy.
Sorry that is exactly how it works - I was trying to give a summary of what
I was taught about IEEE flaoting point during my degree courses.
If you are going to store 15 digits of accuracy in the mantissa then you
need
somewhere to store them. Float4 does not have room.
Using decimal
0.00004 -only needs one digit of accuracy in the mantissa
0.0000400004 - needs 6 sigits of accuracy in the mantissa
0.0000000004 - back to only needing 1 digit in the mantissa
The exponent increases the range of numbers that can be stored
but a real4 can only store the same number of discrete numbers
as a INT or DWORD.
Malcolm
Geoff Schaller
The number is stored encoded - not as 15 discrete digits with decimal places
etc, and its the exponent which suffers the loss of range. For example:
0.000456 and
0.000000000000000000456
are stored as
4.5600000000000 E -04 and
4.5600000000000 E -19
both numbers have the same degree of accuracy. And both numbers must have 15
digits of accuracy (perfectly possible with 32 bits - even allowing for the
exponent) in order to comply with IEEE floating point standards.
Geoff
"Malcolm Gray" <malcol...@jobstream.co.uk> wrote in message
news:voWw7.17$Tb7.675@psinet-eu-nl...
Malcolm Gray
> No, I disagree - and so too does CA's technical literature.
> The number is stored encoded - not as 15 discrete digits with decimal
places
> etc, and its the exponent which suffers the loss of range. For example:
>
> 0.000456 and
> 0.000000000000000000456
>
> are stored as
>
> 4.5600000000000 E -04 and
> 4.5600000000000 E -19
> both numbers have the same degree of accuracy. And both numbers must have
15
> digits of accuracy (perfectly possible with 32 bits - even allowing for
the
> exponent) in order to comply with IEEE floating point standards.
It takes at least 3 bits to store one decimal digit -
there is not room for 15 decimal digits of accuracy in a real4
to be able to store 15 decimal digits of mantissa you need more than
45 bits.
A real4 seems to be an IEEE single-precision
(in base two we can of course use the hidden bit and assume the first bit is
one)
A quick we search finds many pages
http://www.scri.fsu.edu/~jac/MAD3401/Backgrnd/ieee-sgl.html
reports than IEEE single prescition numbers have 7 digits of accuracy
another page that looks good is
http://research.microsoft.com/~hollasch/cgindex/coding/ieeefloat.html
Malcolm
FDW
You two can have a lot of fun running the next bit of code...
FUNCTION Start()
LOCAL R4 AS REAL4
LOCAL X AS DWORD
FOR X:=1 UPTO 100
R4:=R4*2+1
? X
? FloatFormat(R4,30,0)
? AsHexString(DWORD(@R4))
?
NEXT
WAIT
Frans
"Malcolm Gray" <malcol...@jobstream.co.uk> wrote in message
news:qYWw7.19$Tb7.745@psinet-eu-nl...
Malcolm Gray
"FDW" <fdewit_...@tsobjects.nl> wrote in message
news:9q1kng$anm$1...@reader06.wxs.nl...
> Geoff, Malcolm,
>
> You two can have a lot of fun running the next bit of code...
>
> FUNCTION Start()
> LOCAL R4 AS REAL4
> LOCAL X AS DWORD
> FOR X:=1 UPTO 100
> R4:=R4*2+1
> ? X
> ? FloatFormat(R4,30,0)
> ? AsHexString(DWORD(@R4))
> ?
> NEXT
> WAIT
Yes - I had been meaning to write a little test
app to find epsilon, but had other things to do.
Geoff Schaller
accuracy and if so, the VO docs are wrong (not the first time). I won't
argue - nothing is to be gained. My hex editor also only shows a 32 bit
float with 7 digits and some old Clipper docs equate a numeric field with a
REAL8 - that is consistent with double precision floats, at least.
But this is only further reason NOT to use REAL4 and my original thesis is
still correct - that VO must convert these values to FLOAT internally in
order to perform floating point arithmetic.
Cheers,
Geoff
"Malcolm Gray" <malcol...@jobstream.co.uk> wrote in message
news:qYWw7.19$Tb7.745@psinet-eu-nl...
Robert van der Hulst
> Perhaps if you attended a VO conference somewhere you could catch up on
> these issues. Frew (whose 'proper' name is Angswillie) was quite specific
> about the use of the REALs as being compatibility data types and you even
> seem to agree with this point. But I need to correct the record you seem
> hell-bent on breaking every 5 mins, REAL4 and REAL8 are converted to a FLOAT
> internally and hence they are actually LESS effecient than floats. Given
> that you might save a few precious bytes per variable in static memory,
> reals still cause dynamic memory usage so you are saving nothing.
I agree with you: all the intermediate results of Floating Point calculations
are handled as Float variables. That is exactly what FRU (thai is his real
name) said at the Vo conference.
And if you are using variables of type Real4/Real8 the compiler converts the
intermediate results back into Real4/8 after the calculation is finished.
For Real8 the conversion is painless, since it only involves removing the
formatting information of a float (a float is not more than a real8 with
formatting information stored in dynamic memory) but for a Real4 the
conversion will mean losing some accuracy.
Robert van der Hulst
AKA Mr. Data
Vo2Jet & Vo2Ado Support
www.sas-software.nl
Malcolm Gray
"Robert van der Hulst" <in...@sas-software.nl> wrote in message
news:VA.0000004...@sas-software.nl...
> Geoff,
> I agree with you: all the intermediate results of Floating Point
calculations
> are handled as Float variables. That is exactly what FRU (thai is his real
> name) said at the Vo conference.
> And if you are using variables of type Real4/Real8 the compiler converts
the
> intermediate results back into Real4/8 after the calculation is finished.
> For Real8 the conversion is painless, since it only involves removing the
> formatting information of a float (a float is not more than a real8 with
> formatting information stored in dynamic memory) but for a Real4 the
> conversion will mean losing some accuracy.
I assume there are two conversions going on as the FPU will work with 80
bit numbers in the FPU register and convert them to 64 bit to store in the
float
and then convert again to store in the real4?
Malcolm
Phil McGuinness
As this thread continues I will monitor for a few days and then comment
further in some detail.
I spent something like 18 hours with Mark Lincoln yesterday so I need a day
or so to catch on things.
Any statement I have made is fully supported with written information from
CA. I was quickly trying to find example code we submitted to CA re FLOAT
problems when using ROUND(xxx,2) which were resolved by using REAL4.
I cannot use Floats reliably in an financial Trust Accounting application
and I was advised by CA to use REAL4 which has worked perfectly for 2 years
as they indicated it would.
snip[ Essentially, avoid REAL4 and REAL8. ]
I restate that Geoffs original comment that users should aviod REAL4 and
REAL8 is non-sense and misleading. Whether they are converted to Float
internal or not is not the issue. Whether these types do the job they are
intended for in an accurate and predictable manner is the most important
issue. They work fine and for anybody to quote anything different is
creating another software myth that pervade this industry.
----
snip[ Their main use is as compatibility data types for Clipper etc. ]
What does this mean.. You have a Clipper application in memory and sharing
variables.. give me a break.
Phil
---
"Ginny Caughey" <ginny....@wasteworks.com> wrote in message
news:9q0036$cl7$1...@suaar1aa.prod.compuserve.com...
Ginny Caughey
Thanks for reporting back. The more concrete information we have, the better.
And after 18 hours with Mark, I can well imagine that you need some catch up
time. <g>
Ginny
"Phil McGuinness" <hey...@sherlock.com.au> wrote in message
news:bM4x7.8$yb1...@nsw.nnrp.telstra.net...
Geoff Schaller
You must have misinterpretted their advice because what you say is nonsense.
Floats work perfectly fine in most people's financial and accounting apps
and have always done so. Just because you have a problem writing code
doesn't mean the rest of us suffer the same shortcommings.
There is no "problem" using REALs, there's just no benefit. You are causing
yourself additional conversions but these are small bickies in the bigger
scheme of things. It is just more consistent to use Floats and it is CA's
advice that this is what is intended with the language.
Geoff
"Phil McGuinness" <hey...@sherlock.com.au> wrote in message
news:bM4x7.8$yb1...@nsw.nnrp.telstra.net...
Mark Ayliffe
> Phil,
>
> You must have misinterpretted their advice because what you say is
nonsense.
> Floats work perfectly fine in most people's financial and accounting apps
> and have always done so.
Sorry to dive in the middle of the thread, I've not follwed it in detail
though I know that it has all been a bit heated.
I think that Geoff's above statement is rather unhelpful, though not
actually incorrect. It is important to know and understand the limitations
of floating point arithmetic if you intend to use it for an application like
accounting which depends on high precision. For example it is perfectly
possible to add up a set of FP numbers which notionally add up to zero and
it doesn't (quite). It is also possible that two numbers which appear
identical when printed to some precision are not identical for the purposes
of compariosn. This is not a criticism of CA's Floating Point implementation
(or in fact the O/S or the FPU), just a facto of floating point life.
Fortunately I was exposed to a very poor floating point system early in my
career and I've been wary of it ever since. Anyone else here ever write
software for an Alpha Micro?
> Just because you have a problem writing code
> doesn't mean the rest of us suffer the same shortcommings.
Which is possibly a rather harsh way of saying what I've described above.
>
> There is no "problem" using REALs, there's just no benefit. You are
causing
> yourself additional conversions but these are small bickies in the bigger
> scheme of things. It is just more consistent to use Floats and it is CA's
> advice that this is what is intended with the language.
I take it we don't know (or don't care) about dynamic memory implications
then? ;-)
Mark
Ginny Caughey
Actually this discussion is about dynamic memory implications. Many of us have
never had any problem using the dynamically allocated FLOATs, but that doesn't
mean that there couldn't be special circumstances (like tight loops perhaps?)
where this is not the case. I hope the discussion is not about total memory use,
because in a paging OS with plenty of free disk space that shouldn't be a big
deal. (I also develop on PocketPC where total memory/storage can indeed matter.)
The issue of lack of precision in floating point numbers whether FLOAT, REAL8 or
whatever is well know. Set FloatDelta() and simply rounding values before
comparing for equality are the usual approaches to dealing with that - but then
you know already.
As for the tone of Geoff's reply to Phil and the reverse, I think hurling
insults is one of the ways Aussies sometimes show affection. <BG>
Ginny
"Mark Ayliffe" <mark.ayl...@nospam.pem.removethis.cam.ac.uk> wrote in
message news:0Agx7.20$2x2.908@psinet-eu-nl...
Geoff Schaller
You are correct - there is a very serious undercurrent here which is being
over-shadowed by some over-emotive debate. Perhaps 'debate' is too generous
<g>.
I would never attempt to understate the issues resolving accuracy with
floating point arithmetic but neither do I think its all that difficult.
Work to 2 dec places or 4 .... or even 6 (beyond that is relatively
meaningless mostly). You just set up the settings and rounding and off you
go.
My point is that REAL4 and REAL8 do not make this any easier. It cannot.
Precision remains the issue and as malcom has pointed out, REAL4 may even
impose precision limitations. But they do make it marginally harder for the
runtime and compiler because conversion must take place to and from floating
point numbers. I think Fru's main point was just that - why put VO through
that when you could use float's directly? Put like that its hard to
disagree!
Your last point deals with dynamic memory. So what is your point? Are you
concerned in some way? I know I used to be (prior to Devcon last year)
because I thought I was getting GPF's from floating point arithmetic. Well I
was but that was because I was doing inline assignments as parameters to
function calls etc. I stopped all that and now it all works like a charm.
Certainly there were one or 2 bugs with VO 2.0 but 2.5 resolved most if not
all.
So now I'm down to this point: CA says I should use floats for floating
point arithmetic. What is the counter argument?
Geoff
"Mark Ayliffe" <mark.ayl...@nospam.pem.removethis.cam.ac.uk> wrote in
message news:0Agx7.20$2x2.908@psinet-eu-nl...
Mark Ayliffe
> Hi Mark,
>
> Actually this discussion is about dynamic memory implications. Many of us
have
> never had any problem using the dynamically allocated FLOATs, but that
doesn't
> mean that there couldn't be special circumstances (like tight loops
perhaps?)
> where this is not the case. I hope the discussion is not about total
memory use,
> because in a paging OS with plenty of free disk space that shouldn't be a
big
> deal. (I also develop on PocketPC where total memory/storage can indeed
matter.)
Mmm, not quite. VO has limits on Dynamic memory usage and if you transgress
those it's often 5333 Access Violation time. Most of you out there won't be
anywhere close to this even with default settings, but we've got a pretty
big app and we've needed to find this out the hard way. (FWIW I'm a
colleague of Malcolm Gray's, he sits at the next desk :-))
Just in case anyone's interested, we find that you can play around safely
with DYNSIZE()(in pages) up to MaxDynSpace(in Bytes) / (65526 * 1.3). Above
this your app can become unstable when it needs to use DM heavily. Default
MaxDynSpace is 16MB. 1.3 is my own home grown empirical fudge factor.
One of the problems is that (as is documented elsewhere) the GC copies
Dynamic Memory in each time it fires. So if you have a lot of Dynamic Memory
in use and then a tight loop playing with floats, rapidly using and freeing
DM, you may find some rather random performance implications as the GC kicks
in according to its own runes.
>
> The issue of lack of precision in floating point numbers whether FLOAT,
REAL8 or
> whatever is well know. Set FloatDelta() and simply rounding values before
> comparing for equality are the usual approaches to dealing with that - but
then
> you know already.
Ok, sorry for trying to theach you grandma's how to suck eggs!
>
> As for the tone of Geoff's reply to Phil and the reverse, I think hurling
> insults is one of the ways Aussies sometimes show affection. <BG>
LOL! You may have something there.
Mark
Mark Ayliffe
> Hi Mark,
>
> You are correct - there is a very serious undercurrent here which is being
> over-shadowed by some over-emotive debate. Perhaps 'debate' is too
generous
> <g>.
>
> I would never attempt to understate the issues resolving accuracy with
> floating point arithmetic but neither do I think its all that difficult.
> Work to 2 dec places or 4 .... or even 6 (beyond that is relatively
> meaningless mostly). You just set up the settings and rounding and off you
> go.
OK, but we've used a belt-and-braces technique where we have a function
which will tell us whether a float is "approximately zero" and by calling it
with the difference between two numbers we can tell for sure whether two
numbers are the same. One of our problems is that we can't use SetFloatDelta
reliably because we must correctly work with 6DP, 2DP, 0DP and -3DP (among
others) within the same app. Given we've a couple of programmer decades of
code in our app we don't relish the idea of turing it on now either ;-)
>
> My point is that REAL4 and REAL8 do not make this any easier. It cannot.
> Precision remains the issue and as malcom has pointed out, REAL4 may even
> impose precision limitations. But they do make it marginally harder for
the
> runtime and compiler because conversion must take place to and from
floating
> point numbers. I think Fru's main point was just that - why put VO through
> that when you could use float's directly? Put like that its hard to
> disagree!
Yup, for most all work, that is quite right and reasonable
> Your last point deals with dynamic memory. So what is your point? Are you
> concerned in some way? I know I used to be (prior to Devcon last year)
> because I thought I was getting GPF's from floating point arithmetic. Well
I
> was but that was because I was doing inline assignments as parameters to
> function calls etc. I stopped all that and now it all works like a charm.
> Certainly there were one or 2 bugs with VO 2.0 but 2.5 resolved most if
not
> all.
Agreed. The only places I can think of where using REALS would be relevant
is in System calls or other external interfaces such as COM interfaces where
required.
I gather that there is a lot of confusion about whether an expression
completely in REALS will be converted to VO Floats and back for evaluation.
We've always assumed in the past that dynamic memory wouldn't be involved
and we've only used it in some rather deep and nasty diagnostics from the
days when we've been getting our heads round the heap and dynamic memory in
general. Perhaps we're wrong, but it still looks a little confused. I see
you've asserted the opposite further up this thread, but I'm not clear
whether this is your own interpretation, or direct from a CA "horse's
mouth". As Malcolm has quoted that REAL8 and FLOAT share the same format
(though possibly only under certain circumstances) and either way it is the
right format to feed to an FPU, I'm a little puzzled why it might be
necessary to bring Dynamic memory into play. In fact I'd have expected CA to
do the opposite and present static memory objects to the FPU. But what do I
know, I'm just an applications programmer with pretensions to be a systems
programmer ;-)
> So now I'm down to this point: CA says I should use floats for floating
> point arithmetic. What is the counter argument?
None. use of REALS should be limited to the more esoteric stuff. Floats
should be the norm. I don't think that Malcolm or I have any difference with
you on this fundamental point.
Wouldn't the world be so much simpler without floating point, but with 64bit
and 128bit binary instead? ;-)
Mark
Ginny Caughey
I'm not disagreeing about dynamic memory and its limitations. When I was on VO
2.0 and before I moved to Classmate, I was on intimate terms with 5333s, and
without Dynsize I would have been literally out of business. Now that you
mention it, I also had particular problems with reporting logic that did
floating point math in tight loops using large arrays of FLOATs, and calling
CollectForced every 100 iterations solved the problem. Now that I use Classmate,
dynamic memory is less stressed in my apps so CollectForced is no longer
necessary in the reporting logic and I no longer worry about it (and had even
forgotten), but if I were processing more data it could still be necessary.
That's one of the reasons I'm interested in this thread - I think it would be
useful to pin down what specific situations do cause dynamic memory problems in
the current verion of VO. CA has made huge improvements in VO during the years,
but I think they would be among the first to admit that it isn't quite perfect
yet, and reproducible test cases are the first step toward getting those fixes.
Ginny
"Mark Ayliffe" <mark.ayl...@nospam.pem.removethis.cam.ac.uk> wrote in
message news:21ix7.25$2x2.887@psinet-eu-nl...
Mark Ayliffe
<...>
> That's one of the reasons I'm interested in this thread - I think it would
be
> useful to pin down what specific situations do cause dynamic memory
problems in
> the current verion of VO.
First up, I think that for by far the majority of applications VO's "Out of
the box" memory settings are adequate. I _think_ the default value for
DYNSIZE is 40 (64KB) pages. No doubt Geoff will be along to correct me
shortly if I'm wrong. Either way: in theory this should not be a problem, as
one of the dynamic aspects is supposed to be that VO changes the amount of
dynamic memory available to it, more or less up to the MaxDynSpace value(1).
In practice our experience has been that VO either does not do this, or it
is particularly inefficient at doing so and "hign dynamic memory usage" apps
can run quite slowly if not sorted out. Also I have a suspicion (but no
proof) that something within VO does something like a DynShrink behind the
programmer's back, which tends to exacerbate the problem.
We have therefore set our app to test and reset dynsize() whenever a user
selects a menu item and whenever out progress indicator advances. This keeps
the dynamic memory space up to the value we want and has made quite a
performance impact for us(2). We have also set up the following rule of
thumb: MaxDynSpace should be 25% of available system memory, with a minimum
of 16MB and a maximum of 64MB, I cannot emphasise enough, this works for our
app, IT WILL ALMOST CERTAINLY BE TOO MUCH FOR MOST USES (sorry for
shouting)(3). The maximum DYNSIZE should be MaxDynSpace / (65536 * 1.3),
this is a more fundamental limit, if you set DYNSIZE over 200 with the
default maxdynspace (for example) you _can_ get memory access violations.
However, once again if your app is only averagely loading dynamic memory,
you probably will never get there.
> CA has made huge improvements in VO during the years,
Yup. VO 2.5b3 is the biz. In this respect anyway.
> but I think they would be among the first to admit that it isn't quite
perfect
> yet, and reproducible test cases are the first step toward getting those
fixes.
It's certainly the best we've seen in over 6 years of using VO!
>
> Ginny
<rant mode on>
With the greatest possible respect to the experienced posters in this group,
is there any chance that you lot could please try to use the traditional
usenet quoting style, rather than top posting and failing to trim those
points you're not actually replying to. You may think there are better
styles, but there _is_ a convention. See
http://www.xs4all.nl/%7ewijnands/nnq/nquote.html (for example).
<rant mode off>
Mark
(1) MaxDynSpace is expressed in bytes and defaults to 16MB, it is set in
HKCU\Software\ComputerAssociates\CA-Visual Objects Applications\MaxDynSpace
and you have to add your own value if you want to change it.
(2) Typically we achieved 30-40% better performance, in certain operations a
factor of two.
(3) FYI our shipping executable is now just under 26MB in size. We're
starting to look at breaking it into DLLs :) . Total memory footprint after
login is order 75MB. On a machine with loadsa memory, memory usage can
easily pass 150MB, swap file usage another 150MB+
Ginny Caughey
Thanks for your tips. I suspect you spent a lot of time getting it just right,
and since the dynamic memory problems only tend to happen in very large apps,
it's pretty hard to put together a test case for CA. I've saved your message for
future reference - it looks like valuable advice.
Sorry about the long quotes. I have my news reader set to only show unread
messages, and quoting the previous message helps me follow the thread without
actually having to see the whole thread. I also prefer reading the reply at the
top, but I agree that sometimes the standard style of only quoting items you're
replying to is easier to follow. I see both styles on other newsgroups I
frequent, so perhaps newsgroup style is evolving along with flat-rate Interenet
access charges and increased disk space. IAC I've trimmed this message.
Ginny
Graham McKechnie
>>
As for the tone of Geoff's reply to Phil and the reverse, I think hurling
insults is one of the ways Aussies sometimes show affection. <BG>
>>
Well for the rest us lets hope, they don't suddenly decide not to like each
other.
Graham
Ginny Caughey
<BG>
Ginny
"Graham McKechnie" <g...@bigpond.net.au> wrote in message
news:lmox7.147382$bY5.7...@news-server.bigpond.net.au...
Geoff Schaller
Why should I correct you when you were doing so well <g>.
Actually, with 2.5 I can only endorse what you said - the basic default
settings are more than adequate for most circumstances. In fact, I found
that DynSize(80) and up started to degrade performance, largely for the
reasons you detailed. Certainly back in 2.0 I had you do all sorts of things
to squeeze out 5333's (ie 4660's) but this is now a thing of the past.
Geoff
PS - oh yes, I much prefer top-posted comments because its easier to read a
response and sames scrolling down looking for the contribution. I certainly
recommend trimming, except that you ruin the thread of the conversation
sometimes. If the topic is complex then yes, it can be easier to respond
within the body of the text but I wouldn't use it as a default.
"Mark Ayliffe" <mark.ayl...@nospam.pem.removethis.cam.ac.uk> wrote in
message news:jckx7.28$2x2.945@psinet-eu-nl...
Geoff Schaller
64bit
and 128bit binary instead? ;-)<<
You just may get your wish sooner than you think <g>.
I guess I agree with the rest so I'm happy to leave things there for now. I
plan to ask a few more questions in Nuremberg next week. You can never learn
too much!
Geoff
Mark Ayliffe
> Why should I correct you when you were doing so well <g>.
Thanks. <bg>
>
> Actually, with 2.5 I can only endorse what you said - the basic default
> settings are more than adequate for most circumstances. In fact, I found
> that DynSize(80) and up started to degrade performance, largely for the
> reasons you detailed.
Indeed, the trick to maintaining performance is to watch for DynInfoSize
falling and reset dynsize when it drops.
<...>
> PS - oh yes, I much prefer top-posted comments because its easier to read
a
> response and sames scrolling down looking for the contribution. I
certainly
> recommend trimming, except that you ruin the thread of the conversation
> sometimes. If the topic is complex then yes, it can be easier to respond
> within the body of the text but I wouldn't use it as a default.
Well at the end of the day it's your choice. But you are breaking
convention, and those conventions are there for a reason. FWIW I don't think
your way helps readability one bit.
Looks like we'll just have to agree to differ on that :-)
Mark
Mark Ayliffe
> You just may get your wish sooner than you think <g>.
Though sadly we've had 40 odd years of Floating Point software in our
history. My wish was for it never to have existed!
Mark
Geoff Schaller
I don't think there is any convention on this.
Geoff
Bob Arnold
Bob Arnold
Geoff Schaller
you be then?
Its a sad quirk of binary law <g>.
"Mark Ayliffe" <mark.ayl...@nospam.pem.removethis.cam.ac.uk> wrote in
message news:q9Dx7.25$2d5.1104@psinet-eu-nl...
Phil McGuinness
accuracy and if so, the VO docs are wrong (not the first time). I won't
Good!
snip[ But this is only further reason NOT to use REAL4 and my original
thesis is still correct - that VO must convert these values to FLOAT
internally in order to perform floating point arithmetic ]
I have never disagreed whether REAL4 are convert to FLOATS or not .. I care
little if they do or they don't.. I only what a reliable and predicatable
result in a VO application.. REAL4 do it standard and FLOATS do it with
SetFloatDelta(x.xxx)
Read my post with sample to reinforce this conclusion.
Phil McGuinness
--------------------
"Geoff Schaller" <geof...@bigpond.net.au> wrote in message
news:40Zw7.142863$bY5.7...@news-server.bigpond.net.au...
Geoff Schaller
The reason I believe you owe me an apology is that you have effectively
called me a liar. Here are your exact words:
>>Geoff, Prove it .. You agina make un unstubstatited claim using
somebody
else name to justify it,<<
The names, dates, words and places were as I said. Fru's session at Devcon
last year. Ginny has already substantiated this, not that she had to...
Further, you also insinuated that I made things up. Again here are you exact
words:
>>>Geoff, read what CA development report when the REAL4 or REAL8 reference
issue was raised. They quote 100% the opposite of what you said they say.
I have it in writing from them. You did not make this stuff up did you?<<<
No, I didn't make anything but here's the crunch. I don't believe you.
Please show us the "writing" you have from CA. It may help clear these
issues up and I would be keen to see any inconsistency in advice from CA.
Hence you still owe me an apology because you are wrong about these
assertions.
But your further discussion and your demo only serve to prove that if you do
not set environmental settings properly, you may get the wrong results.
There is nothing new in this except your inability to deal with this.
Perhaps REAL4 does solve your particularly problem but its not necessarily
the most appropriate methodology. I do not use SetFloatDelta() and never
have. Instead I rely on full precision and use Round() quite a lot. I also
do my own float comparisons for equality.
All these issues can be dealt with if you exercise a little care. I am not
saying the course of most appropriate action is necessarily totally
intuitive but I am saying that the advice we have from CA is workable and
consistent.
Geoff
"Phil McGuinness" <hey...@sherlock.com.au> wrote in message
news:k3Ox7.12$hO1....@nsw.nnrp.telstra.net...
> Ok. I now have the time to respond in some detail..
>
> There has been claim and countered claim. The original flame of this
> discussion related to the advice given to a user asking a legitimate
> question about REAL4, REAL8 and FLOAT. I say the answer as misleading and
> tried to correct it and it turned into an interesting thread indeed.
> -----
> Geoff stated [ Essentially, avoid REAL4 and REAL8. --- All formats can
> only represent 15 decimal places of accuracy but REAL4 is 32 bits wide,
> REAL8 is 64 bits and a FLOAT is 80. Consequently they can offer differing
> number ranges but these numbers are so tiny and so large that it hardly
> matters ]
> -----
> Well as you can see from the sample code provided it matters quite a bit.
It
> means for a lot of Clipper people trying to take business logic forward to
> VO can have some weird bugs if you do not know the pitfalls of FLOAT.
> -------
> snip[ In fact, at Devcon Germany last year, Angswillie expressed extreme
> dismay at the thought of anyone avoiding floats for REAL8 ]
> I would agree with this statement. From these tests you will see they do
> bugger all, but REAL4's work perfectly.
> ----------
> snip[ ...and now Phil, I think you owe me an apology. ]
> If I had quoted something incorrectly you would get one, but I have not..
> read on McDuff !
> ----
> snip[ Perhaps if you attended a VO conference somewhere you could catch up
> on these issues]
> I hope the code I have posted is discussed at the next one.. it seems to
be
> right on the money <G>
> ---
> snip[ the use of the REALs as being compatibility data types and you even
> seem to agree with this point. But I need to correct the record you seem
> hell-bent on breaking every 5 mins, REAL4 and REAL8 are converted to a
FLOAT
> internally and hence they are actually LESS efficient than floats ]
>
> Geoff they may be TOO efficient and TOO accurate and hence lies the
problem.
> -------
> snip[ You spout some crap about CA quoting the opposite of what I said
they
> said yet you also fail to offer any reference to such information. My
source
> is a session I attended at a conference.]
> I moved to REAL4 some time ago when I was getting inconsistent results and
> evaluations similar to the same AEF attached and I was 'directed' to REAL4
> as an alternative and they have worked 100% ever since. I have decided
not
> to post private correspondence from CA to myself, However If the author
> agrees I will. It serves not purpose and the sample attached proves the
> point anyway.
> -----
> Please find attached a small sample application that shows a real gotcha
for
> FLOAT users of VO and why I recommended, why CA development originally
> pointed me in the direction of REAL4's some time ago.
>
> The sample application shows the use of a FLOAT, REAL8 and REAL4 to add
some
> numbers together. That is ADD 333.83 to 67.77. The result of the
> calculation is placed in a variable. The same total amount of 406.60 is
> placed in another variable and some tests and comparisons take place.
>
> Two tests are performed for each variable type. So we have a test for
> FLOAT, REAL8 and REAL4.
>
> The first test is to take one result form another which should equal a
ZERO
> result.
> The other test is do the two numbers equal each other from VO perspective.
>
> Remember we are using stock standard VO2,5 and we are comparing the same
> variable types which have quite basically and commonly used financial
> amounts. The results are quite interesting and alarming if you are not
aware
> of the pitfalls.
>
> Save in n1 the addition result of say 388.83 + 67.77 which should be
406.60
>
> n1 := 338.83 + 67.77 // <-- should be ( = 406.60)
> n2 := 406.60 // <-- we enter the same figure
>
> ? n1 - n2 = 0 // -> RETURN FALSE FLOAT // -> RETURN TRUE
> (if SetFloatDelta(xValue))
> ? n1 = n2 // -> RETURN FALSE // -> RETURN
> TRUE -- as above --
>
> The result of the FLOAT type is incorrect. The result of the REAL4 test is
> correct.
> The only way to get the FLOAT to work correctly is to set the
> SetFloatDelta() to something like ;
> SetFloatDelta(0.01) or SetFloatDelta(0.001) or
> SetFloatDelta(0.0001)
>
> So I stand by what I said to Geoff at the beginning of this thread.
>
> The use of the REAL4 is correct one, a reliable one, a predicable one and
> statements to the contrary are misleading.
>
> It should be noted that FLOATS can produce a quality result as well if you
> use the SetFloatDelta(xxx) in your applications configuration area to
bring
> VO float result more in line with the users expectations.
>
>
> Phil McGuinness
> -----------------------
>
>
>
>
>
>
Geoff Schaller
You should check the grammar and spelling of your posts a little more
dilligently. It makes it hard for me to read them - think of the
difficulties you impose on non-English speaking people. This is especially
important when you leave out negatives!
> I have never disagreed whether REAL4 are convert to FLOATS or not .. I
care
> little if they do or they don't.. I only what a reliable and predicatable
But Phil this is EXACTLY what you disagreed with. Well obviously you have
had a change of mind. But using REAL4 as a means to overcome rounding issues
doesn't sound like a good plan to me. There will come the day when you'll
want the extra precision.
Geoff
"Phil McGuinness" <hey...@sherlock.com.au> wrote in message
news:W9Ox7.13$hO1....@nsw.nnrp.telstra.net...
> snip[ Well then, I'll give up on this. Perhaps it is only single
precision
> accuracy and if so, the VO docs are wrong (not the first time). I won't
> argue - nothing is to be gained. ]
>
> Good!
>
> snip[ But this is only further reason NOT to use REAL4 and my original
> thesis is still correct - that VO must convert these values to FLOAT
> internally in order to perform floating point arithmetic ]
>
Phil McGuinness
The issue is in this case you wrap somebody (Fru's) comments on a question
relating to FLOAT and REAL8's to justify a statement that a person should
not use REAL4's. Fru is a very creditable person and there your statements
carry more weight and all believe. You do not mention in your statement
that Fru was alarmed that VO developers were using REAL4's, only REAL8's.
You can see by other comments relating to REAL4 by Mark Ayliffe there may be
some variation in the results from Real4 from the documentation you are
reading. You conceded this.
That is why I am saying you are making or have made a claim that is
unsubstantiated.
I am certainly not saying you are a liar just your statements from somebody
who is using REAL4 and has tested the alternatives and your comments over
the top of my originals comments, are incorrect and I stand by my comments
100%.
I hope I have shown here empirical proof of this and it is no longer he said
this or that. I do not like the fact I have not only everything I said I
also have to disprove what Fru did not say.
snip[ But your further discussion and your demo only serve to prove that if
you do not set environmental settings properly, you may get the wrong
results.]
Agreed... but where was this pointed out to the potential users of FLOAT
over the stated REAL4 which I put forward as a "safe" method of dealing with
floating point numbers. From this discussion I have no doubt there are
quite a few VOer's out there adding SetFloatDelta() or switching to REAL4's.
snip[ I do not use SetFloatDelta() and never have. Instead I rely on full
precision and use Round() quite a lot. I also do my own float comparisons
for equality.]
I expected this would be the answer for a lot of users and I am sure it
works for you fine. The reason a lot of others and probably yourself is that
you probably use FIELDSPECS and write to DBFs, which in both cases truncated
to 2 digits for numerics as a rule. So in away the extra precision is
removed.
snip[ I am not saying the course of most appropriate action is necessarily
totally intuitive but I am saying that the advice we have from CA is
workable and consistent.]
Geoff, actually do not have a beef with you in the total scheme of things
but more the lack of fully credible VO documentation. I can speak with some
authority on this as I lost hundreds of hours sometime ago in a rather
complex piece of code before I discovered all these issues by trial and
error. I try as you do to help somebody who asks a Vo question. You
constantly jump over the top of peoples comments with some inaccurate
generalisations which do rub some people up the wrong way.
I hope from this interesting episode we all found out something about VO and
we can take advantage of it.
My rule of thumb now is for most Financial type calculations I use REAL4.
For floating point operation I use FLOAT and I do not SetFloatDelta().
Phil McGuinness
----------------------
"Geoff Schaller" <geof...@bigpond.net.au> wrote in message
news:vxOx7.150934$bY5.7...@news-server.bigpond.net.au...
Geoff Schaller
You're nuts... and wrong.
I drew no specific distinction between REAL4 or 8 - its you who developed
this fetish for REAL4 and others who indicated a difference in precision.
Fru WAS talking about all REALs (correct me if I'm wrong Ginny), not
specifically REAL8 - it was an issue of using the REAL data type as opposed
to FLOATS.
The issue was and remains that CA advise against the use of REALs in favour
of FLOATS.
You called me a liar (directly) and also suggested that I made up all this
stuff. Wrong on both counts - apologise or shut up.
> I am certainly not saying you are a liar just your statements from
somebody
> who is using REAL4 and has tested the alternatives and your comments over
> the top of my originals comments, are incorrect and I stand by my comments
> 100%.
Huh? So now you say its just my statements are wrong? About what? Which bit?
I don't think I was ever commenting about anyone using REAL4's because this
didn't come in as an issue until someone else began a parallel discussion on
the precision of REAL4. But this is not central to the theme of Fru's
recommendation.
> I hope I have shown here empirical proof of this and it is no longer he
said
> this or that. I do not like the fact I have not only everything I said I
> also have to disprove what Fru did not say.
Please repeat this in English - I have no idea what you are getting at here.
You don't have to prove or disprove anything Fru said - what he stated is on
the public record. Don't use REALs when you can use FLOATs. Want it any
simpler?
> floating point numbers. From this discussion I have no doubt there are
> quite a few VOer's out there adding SetFloatDelta() or switching to
REAL4's.
Well I doubt they would be moving to REAL4 because its quite
counterproductive. Using SetFloatDelta() seems more logical, or judicious
use of Round()
> I expected this would be the answer for a lot of users and I am sure it
> works for you fine. The reason a lot of others and probably yourself is
that
> you probably use FIELDSPECS and write to DBFs, which in both cases
truncated
> to 2 digits for numerics as a rule. So in away the extra precision is
> removed.
Absolutely - doesn't everybody? of course it only truncates to what its set
to. N 10 4 gives 4 decimal places.
> Geoff, actually do not have a beef with you in the total scheme of things
> but more the lack of fully credible VO documentation. I can speak with
some
Huh? You beef is not with me but with VO's lack of credible documentation?
Then why jump on me. All I did here was repeat what Fru told us. The
question was actually asked by me in that session because I was having
trouble with FLOATS and wanted some clarification. We got more than we
bargained for. In this case I'm not sure the docs are any limitation. What
is possibly needed is a more generalist discussion on how to handle floating
point arithmetic but I'm not sure that's CA's role to provide. And no-one
writes books any more because they don't make money!
> constantly jump over the top of peoples comments with some inaccurate
> generalisations which do rub some people up the wrong way.
Maybe - but I think I get it right more often than not and when others jump
in to make "corrections" I am willing to participate or recant (eg real4
precision).
Geoff
Jean-Marie Berthiaume
Personnally I hate the so call "usenet quoting style". I find it most of the
time hard to follow. Everywhere else, people wrote quote INTO their text not
over it. I quite don't see why that should be different because we are writing
into a usenet. And if we have to talk about convention, just take a look in this
ng and how many of us use top response: 75%, 85% ? Conventions come from what
most people do, isn't it?
Geoff Schaller a écrit :
--
Jean-Marie Berthiaume
Montréal, Québec
Attention. Enlever les # pour me rejoindre
Please erase the # to reply :
(jie...@videotron.ca)
Geoff Schaller
"Jean-Marie Berthiaume" <#jiembe@#videotron.ca> wrote in message
news:mPWx7.7766$Dh4.6...@wagner.videotron.net...
Phil McGuinness
Below is your statement and you will see in your comments today you want to
deny that you made no such comments.
You stated to Jean
// --------------------------------------------------------------
REAL4 and REAL8 are static memory objects and FLOAT is of course dynamic,
and hence managed by the GC. All can be used to represent floating point
numbers by CA highly recommends only the usage of FLOAT. In fact, at Devcon
Germany last year, Angswillie expressed extreme dismay at the thought of
anyone avoiding floats for REAL8. He should know - he wrote the code <g>.
The main thing against REAL4 and REAL8 is that of course they cannot be used
in that mode. For all floating point operations and conversions, REAL4 and
REAL8 are both first converted internally to FLOAT, used and then converted
back. They are thus quite slow in comparison to FLOAT and involve
unnecessary runtime conversions. Their main use is as compatibility data
types for Clipper etc. All formats can only represent 15 decimal places of
accuracy but REAL4 is 32 bits wide, REAL8 is 64 bits and a FLOAT is 80.
Consequently they can offer differing number ranges but these numbers are so
tiny and so large that it hardly matters <g>. Essentially, avoid REAL4 and
REAL8
//-----------------------------------------------------------------
This is what you said, RIGHT are you still standing by these comments.?
Snip[ Angswillie expressed extreme dismay at the thought of anyone avoiding
floats for REAL8. ]
You state today snip[ Fru WAS talking about all REALs (correct me if I'm
wrong Ginny), not specifically REAL8 - it was an issue of using the REAL
data type as opposed to FLOATS.]
Geoff you cannot see even though you wrote it and repeat here the statements
contradict each other.
Let us break down what you quote and then deny you said it.. You state
that FRU expressed concern using REAL8 instead of FLOAT.. He did not
mention REAL4 in your quote. however today the story changes to it was an
issue of using REAL data types which no includes REAL4. Which is the
correct one. You have quoted two statements and the later is broad ranging
to justify your earlier incorrect statement. You also said, "The main thing
against REAL4 and REAL8 is that of course they cannot be used in that mode".
Your comments to that person basically said my suggestion was incorrect and
believe me (because FRu said this) and not him..".. Enough of this nonsense.
------------------
snip[ Huh? So now you say its just my statements are wrong? About what?
Which bit? I don't think I was ever commenting about anyone using REAL4's
because this didn't come in as an issue until someone else began a parallel
discussion on
the precision of REAL4. But this is not central to the theme of Fru's
recommendation. ]
Geoff, when I told somebody right at the beginning to use REAL4 you quoted
"CA highly recommends only the usage of FLOAT" please note the word ONLY in
your statement. You are saying that my comment of REAL4 is incorrect, has
no credibility, my recommendation is wrong and CA has issued some edit to
only use FLOAT yet CA advised me to use REAL4 to get around the issue with
FLOAT. Woops! I say to myself this does not add up to what I see and what
I was told.
--------
snip[ I don't think I was ever commenting about anyone using REAL4's ]
Yes you did.. you do not even know what you say apparently.
I say it is incorrect because the test code I posted shows it to be
incorrect.
-----------
snip[ Huh? You beef is not with me ]
I have no problems with you Geoff, in this case I did not want new users
getting off to some 'questionable' advise not matter who issued it which I
know to be incorrect in a real life Vo application. In this case I can
prove it.
--------
snip[ but with VO's lack of credible documentation? Then why jump on me. All
I did here was repeat what Fru told us.]
Geoff I am not jumping on you. If Fru said REAL8 in his comment on FLOAT I
agree but if he said it for all REAL's I have to disagree and I have
supplied physical proof why I made these comments.
----------
snip[ The question was actually asked by me in that session because I was
having trouble with FLOATS and wanted some clarification. ]
Interesting I also had some troubles and was pointed to REAL4 as a
recommendation from Marijo when I put to here some examples. She normally
asks development if it is a new issue or refers to here "code library",
Anyway the advise is good!
------------
snip[ In this case I'm not sure the docs are any limitation. What is
possibly needed is a more generalist discussion on how to handle floating
point arithmetic but I'm not sure that's CA's role to provide.]
I guess we as developers probably know in our collective minds just about
everything relating to building an application but we do not know the
internals. We need more white papers for www.knowvo.com or for SDT
International. However I think this forum to be fantastic and this thread
has certainly been and interesting one.
--------
snip[ constantly jump over the top of peoples comments with some inaccurate
generalisations which do rub some people up the wrong way.]
I do it too so we are both guilty!
----------
When you go to the Devcon in Germany see if FRU or UWE or SABO would write
an article on this subject. In the meantime I will continue to use REAL4
and FLOAT for floating point stuff which is not related to Financial
amounts.
snip[ You're nuts... and wrong. ]
In both cases wrong again <BG>
Phil McGuinness
-----------------------
Graham McKechnie
6:48am on a Sunday morning. Hell what time do you start writing?
Interesting discussion - it would appear that two different CA sources gave
contraditing views on the subject.
Its a bloody pity there is no one from CA willing to jump into this thread
and put the thing to bed, just so you two guys can get kissy/kissy again.
I'm also not sure I just want to rely on Geoff's recall of a discussion he
had in Germany, even if Ginny confirms what Fru stated. Not hearing all the
answer can always lead to misinformation. Also not knowing Geoff's original
problem/question with Floats probably compounds it.
It would be interesting to look at both problem examples (Geoff's and yours)
at the same time. We have seen your demonstration, but Geoff hasn't shown us
his original float problem. I would like to know how Fru's recommendation to
use Floats actually solved Geoff's float problem.
I think I'll have a look at the code you posted and compare it to a problem
I was having with Floats back in 2.5a or b.
But I'm presuming you don't think this problem is version specific.
Regards
Graham
"Phil McGuinness" <hey...@sherlock.com.au> wrote in message
news:JL1y7.1$g52...@nsw.nnrp.telstra.net...
Phil McGuinness
I started at 5:30am .. I have to get this project into a field BETA by
December or I am a dead duck. We have so much new work coming on board I am
going to totally get snowed under.
---
Graham, the real issue is that neither of us has a current problem that I
am aware with "FLOATS" in general terms. We both have solutions that work
for us.
Basically somebody asked for some advise, I gave it, Geoff went over the top
with a contrary point of view and then when I questioned him telling
somebody to disregard my advice and .. well the rest is in the thread
somewhere..
Then Fru's comment was thrown into the debate and it was put to me "put up
or shut up" or apologise etc.
I have proven my point not to have a go at Geoff but I was placed in this
unfortunate position. I guess Geoff feels a bit let down because he quoted
something in good faith and hung his hat on it as they say in the classics.
--------
snip[ Not hearing all the answer can always lead to misinformation. Also not
knowing Geoff's original problem/question with Floats probably compounds
it.]
Yes you are right and I still use FLOATS but not for Financial calculations.
I have found REAL4 a better alternative.
However if the question put to Fru related to the 'absolute use of FLOATS
verse REAL8 then I would agree with his comments and this is why I included
the REAL8 in the test code.
------
snip[ I think I'll have a look at the code you posted and compare it to a
problem I was having with Floats back in 2.5a or b.
But I'm presuming you don't think this problem is version specific. ]
Correct.. This problem has remained the same from my testing all the way
through and it would seem that depending on your exact needs or accuracy you
get get around it in many ways.
1/ use ROUND(xxx,2)
3/ SetfloatDelta(x.xx)
2/ FieldSpec
4/ DBF
or
5/ REAL4
Or use them all.. That is use either FLOAT + SetFloatDelta() or REAL4 and
still use Round(xxx,2) and of course I use Fieldspecs and the DBF with
NUmerics automatically truncate to field length.
I would be interested to know how you and anybodies else's tests go. At the
end of the day I just want an application to do what I would expect it do
and how Vo does it behind the scenes I care less about.
Phil McGuinness
-----------------------
Geoff Schaller
Despite Phil's comments about "over the top" (which never happened - is he a
little sensitive to contrary views?), there was never any fetish for or
against REAL4, which seems to be Phil's pet toy. But I can tell you what
happened that lead to all this and what DID solve my problems.
The Background
I was having trouble with a progress bar control that I wrote (the code is
now on KnowVO somewhere). It had a dual bar and displayed the percentage
inside the bar and changed color just like the MS one. Cool. Except that
every so often I got 5333's and always on a float multiplication to
determine the percentage to display. After a lot of mucking around I
switched to REAL8 and the problem went away (I thought!...). Then later,
sometimes it still GPF'd but not in predictable ways... again, so I thought!
The Conference
Fru's session at Devcon was on data management, I think, but as with all
such things he quickly departed the script to answer delegate issues.
Someone discussed FLOATs in general and then I chipped in with my experience
for replacing FLOAT with REAL8. And that's when Fru went off <g>. many in
the room thought as I did - replace a dynamic data type with a static one.
No 5333. Basically the discussion, which never explicitly referenced reals
of either type ended up with the advice to use FLOAT instead of REAL, except
where compatibility with external routine data types was required. No-one
said that they wouldn't work (clearly they do), no-one was getting off on
attacking REAL4's, not even me <g>, so I don't know why Phil is getting so
hot under the collar. The question began with REAL8 and I don't think anyone
then or now was too excited about 4 or 8 either way.
My Solution
Ok, but none of this helped explain my situation but I did find the reason!
All over my app I used the progress control in code blocks, particularly
reindexing routines etc. Guess what - the method call I used in the code
block was strongly typed. Once I removed the strong typing - everything was
solved and I could even revert back to using FLOAT in the progress bar
calculations! I think other discussions we've held in here can expand on
that point.
Fru's Suggestion
But there's more! <g> Perplexed about this new advice I raised this issue
with Fru directly and he made a very simple comment. This was a progress bar
where high efficiency should be used to interfere as little as possible with
the programming flow (ie its only reporting on another process...). If I
used REAL8 inside this routine to do floating point math ("/" and "*") in
the 6 places it was (with 2 params), I was causing 12 type conversions to
FLOAT and 12 type conversions back to REAL8. His attitude was that I should
just use FLOAT and save the conversions. Better efficiency. The result was
the same but it was better. So, I really don't care if Phil uses REAL4 or
not for floating point arithmetic. He is just causing unecessary type
conversions but he is gaining a precision round-off automatically. Well,
given the various tools at our disposal, I consider this a storm in a
teacup.
It doesn't change CA's advice to use FLOATS
And it doesn't stop Phil from using whatever works.
And its not inconsistent with someone else's advice to use REAL4 to achieve
precision chomping.
Cheers,
Geoff
"Graham McKechnie" <g...@bigpond.net.au> wrote in message
news:LC3y7.155117$bY5.7...@news-server.bigpond.net.au...
Phil McGuinness
Phil
--
"Geoff Schaller" <geof...@bigpond.net.au> wrote in message
news:hx5y7.155612$bY5.7...@news-server.bigpond.net.au...
Phil McGuinness
If you want as you, that is Geoff Schaller post typos I will fix them and
repost if you like.
Are you saying the FLOAT and REAL4 issue continues.. You are a glutton for
punishment.
Beaten to death and still will not admit he has is wrong. Why waste my
breath!
I am concluding the session as a total waste of time taking to somebody who
is well.. we all know .. but you don't apparently.
Geoff, I would suggest, "When you are in a hole Stop digging"
Phil
---
Phil McGuinness
I must buy a new keyboard. soon.
Phildo
----
"
Geoff Schaller
"Phil McGuinness" <hey...@sherlock.com.au> wrote in message
news:3R7y7.17$g52....@nsw.nnrp.telstra.net...
Mark Ayliffe
> Hi Mark,
>
> I don't think there is any convention on this.
>
> Geoff
Yes there is. And it is said many many times in FAQ's all over the place.
Here's one copy of the complete newbies version:
http://www.plig.net/nnq/nquote.html
Q7 in this case in particular, but IMHO several posters here could do with a
refresher on the whole lot.
Mark
Mark Ayliffe
news:3bc7...@nap-ns1.netconnect.net.au...
> I must say I also find top-posted stuff more accessible.
>
> Bob Arnold
>
>
This kind of response is also deprecated:
http://www.plig.net/nnq/nquote.html
Q1 in this case. I know what you're talking about ('cos you were replying to
a sub-thread I started), but anyone diving in the middle won't have a hope.
And no, that's not an excuse for quoting everything, read the FAQ.
Mark
Mark Ayliffe
news:mPWx7.7766$Dh4.6...@wagner.videotron.net...
browsers.
No it isn't. When the conventions were established, one could still write
where one wanted in a response. However Microsoft have set the default in OE
to be top and it's just plain against the convention.
> Personally I hate the so call "usenet quoting style".
I'd like to say you're in the minority, but sadly that seems not to be true.
However the convention is still there.
> I find it most of the
> time hard to follow.
Do you find it harder to follow where I am replying to your points one by
one like this, or if I'd just put all my points in one paragraph at the top.
> Everywhere else, people wrote quote INTO their text not
> over it.
I'm not quite sure what you mean here?
> I quite don't see why that should be different because we are writing
> into a usenet. And if we have to talk about convention, just take a look
in this
> ng and how many of us use top response: 75%, 85% ? Conventions come from
what
> most people do, isn't it?
No, conventions, in this case, come from what is written in the FAQ, if most
people ignore it (or I think have never heard of it, or bothered to find
out) then it doesn't alter the convention.
See http://www.plig.net/nnq/nquote.html
Mark
Geoff Schaller
Replying mid-post, point by point, only works for the first respondent.
Beyond that this kind of response is totally hopeless and I think, often
causes the confusions we see common in here. People sometimes respond to the
wrong bit.
I happen to think MS go it right by making top-post responding as default.
It seems the most logical thing to me and is generally the way the wider
community responds to physical mail and emails. Chronologically you go to
the end of file for the oldest material.
Geoff
"Mark Ayliffe" <mark.ayl...@nospam.pem.removethis.cam.ac.uk> wrote in
message news:Zkxy7.10$Bv5.519@psinet-eu-nl...
Geoff Schaller
Gilligan's Island piece another way to make a nonsense out the opposite
methodology. There is no right and wrong in these things.
...and there is no convention. In fact, take a quick straw poll through a
dozen NG's and you'll find a dozen different styles. But top-down is most
prevalent.
Anyway. Who are those guys and who are they to say that their piece of
writing is any more "standard" than anyone else's? I'll stick with what I
think is most appropriate to the circumstances and the message at hand.
Geoff
"Mark Ayliffe" <mark.ayl...@nospam.pem.removethis.cam.ac.uk> wrote in
message news:jexy7.6$Bv5.481@psinet-eu-nl...
Mark Ayliffe
> Oh Mark, with all due respect, that stuff is crap. I could re-write that
> Gilligan's Island piece another way to make a nonsense out the opposite
> methodology. There is no right and wrong in these things.
>
> ...and there is no convention. In fact, take a quick straw poll through a
> dozen NG's and you'll find a dozen different styles. But top-down is most
> prevalent.
>
> Anyway. Who are those guys and who are they to say that their piece of
> writing is any more "standard" than anyone else's? I'll stick with what I
> think is most appropriate to the circumstances and the message at hand.
>
> Geoff
>
Well, you all go ahead and do what you like. I can't spare the time to
disentangle it all anymore, so I'm unsubscribing. Don't bother to reply, I
won't see it.
Bye all
Mark
Jean-Marie Berthiaume
I have problems with ayatollah.
Mark Ayliffe a écrit :
--
Jean-Marie Berthiaume
Jean-Marie Berthiaume a écrit :
Phil McGuinness
now?
Phil McGuinness
---------------------
"Geoff Schaller" <geof...@bigpond.net.au> wrote in message
news:JDCy7.169189$bY5.7...@news-server.bigpond.net.au...
Bob Arnold
top-posted stuff more accessible" would be all at sea?!
If it were me (to attempt to be objective) I would be able to see (very
quickly and readily) that
1) The author was (probably) talking about NG intercourse
2) Someone else had been talking about it beforehand, and this author was
in agreement.
3) The issue was top-posting and the criterion being applied was
"accessibility"
4) If the remark incensed me (most unlikely - ergo I trimmed severely)
I'd know where to look.
I would have to deprecate the comprehension skills of anyone who could not
reach something approaching these conclusions.
I looked at the "advocacy document" you recommended and I think it takes the
view, rather too easily, that it stands for a majority outlook.
Q7, for example, could pay some attention to the fact that, when a topic
excites lots of comment, it becomes tedious to open each one on the same,
original text. If people are following the thread then surely they'd rather
be exposed to its ripostes and development as they arise - more like in
conversation. And if they're not following, but just dive in late, are
they the right ones for whose convenience we should cater?
I don't think so.
As for Q10 ("Thou shalt not make life unnecessarily difficult for other
people"), I guess I'm not a person?
Bob Arnold
"Mark Ayliffe" <mark.ayl...@nospam.pem.removethis.cam.ac.uk> wrote in
message news:%fxy7.8$Bv5.536@psinet-eu-nl...
Geoff Schaller
"Mark Ayliffe" <mark.ayl...@nospam.pem.removethis.cam.ac.uk> wrote in
message news:k_Cy7.42$Bv5.1002@psinet-eu-nl...
> "Geoff Schaller" <geof...@bigpond.net.au> wrote in message
> news:JDCy7.169189$bY5.7...@news-server.bigpond.net.au...
> Well, you all go ahead and do what you like. I can't spare the time to
Geoff Schaller
...but is must only be a REAL4 one because there's no precision in your
answer...
"Phil McGuinness" <hey...@sherlock.com.au> wrote in message
news:eRHy7.3$mL2...@nsw.nnrp.telstra.net...
John Carbines
Do you guys understand how much this personal stuff pisses the rest of us
off?
Snap out of it.
JC
"Phil McGuinness" <hey...@sherlock.com.au> wrote in message
news:KM5y7.14$g52...@nsw.nnrp.telstra.net...
John Carbines
JC
"Geoff Schaller" <geof...@bigpond.net.au> wrote in message
news:6qay7.160668$bY5.7...@news-server.bigpond.net.au...
Phil McGuinness
You might have to use a FLOAT or REAL8 because REAL4 may not be able to
store this number.
So basically go and FLOAT yourself Geoff. <G>
Phil
----
"Geoff Schaller" <geof...@bigpond.net.au> wrote in message
news:JfVy7.173230$bY5.8...@news-server.bigpond.net.au...
Jean-Marie Berthiaume
give shit to everyone. You don't like this ng, go elsewhere.
John Carbines a écrit :
> Geoff - about time this crap went private
>
> JC
>
--
Geoff Schaller
(That's a golfing joke for the sporting illiterates amongst you <g>)
"Phil McGuinness" <hey...@sherlock.com.au> wrote in message
news:3z1z7.5$l6....@nsw.nnrp.telstra.net...
Geoff Schaller
posts", why do you feel a need to contribute at the same level?
"John Carbines" <j...@carbines-sw.com> wrote in message
news:%9Yy7.9461$e5.8...@newsfeeds.bigpond.com...
John Carbines
in the hope that, by osmosis, some of the frankly amazing things I read here
will sink in and help me. This is what it is for, and the time and effort of
all contributors is immensely appreciated by all of us who generally don't
butt in. Probably far more than you and others realise.
So, perhaps, you might understand why some of us feel this way. I didn't
want to need to contribute at this level, but if it helps to keep me
focussed on why I am spending my time at midnight doing my best to come to
terms with VO then so be it.
regards,
JC
"Geoff Schaller" <geof...@bigpond.net.au> wrote in message
news:6mez7.175811$bY5.8...@news-server.bigpond.net.au...
Geoff Schaller
subject forum <g>. You don't have to read the posts and they aren't hurting
anyone.
"John Carbines" <j...@carbines-sw.com> wrote in message
news:Kbgz7.10230$e5.9...@newsfeeds.bigpond.com...
Malcolm Gray
> Ahhhh, but then you could never do floating point arithmetic! Where would
> you be then?
>
> Its a sad quirk of binary law <g>.
I certainly wish that either fixed precition or BCD had become more
common...
(That is a 64 bit that always stored 6dp say, or even n-dp)
But I guess floating point has its uses, just often not the ones we use it
for.
Malcolm