Re: AUDIT: r17421 - gnucash/trunk/lib/libqof/qof - Add a new function to the gnc_numeric library that converts denominators to exact powers of ten.

2008-09-18 Thread Andreas Köhler 
Hi Chris,

On Thu, 2008-09-18 at 11:58 -0400, Chris Shoemaker wrote:
> > >> On Tue, Sep 16, 2008 at 9:38 AM, Andreas Köhler <[EMAIL PROTECTED]> 
> > >> wrote:
> > >>> I just noticed that ignoring negative denominators means that 1/(-10) is
> > >>> now printed as "1 * 10", where it was printed as "10.00" before.  Is
> > >>> that a regression we have to fix or not?
>
> I haven't followed the thread at all, but just in case anyone's not
> aware, I thought I should remind everybody about the reciprocal
> denominator represention.  IIRC, signs are always stored on the
> numerator, and a negative denominator represents a reciprocal
> denominator (essentially a multiplication).  Last I knew, this
> representation is used internally by some of the operations.

indeed, that is what we detected as well.  Nice to read from you again,
though, please repeat that :-D

Ciao,
-- andi5



signature.asc
Description: This is a digitally signed message part
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: AUDIT: r17421 - gnucash/trunk/lib/libqof/qof - Add a new function to the gnc_numeric library that converts denominators to exact powers of ten.

2008-09-18 Thread Chris Shoemaker 
On Thu, Sep 18, 2008 at 06:12:19AM -0700, Charles Day wrote:
> On Tue, Sep 16, 2008 at 2:40 PM, Charles Day <[EMAIL PROTECTED]> wrote:
> 
> > On Tue, Sep 16, 2008 at 10:54 AM, Charles Day <[EMAIL PROTECTED]> wrote:
> >
> >> On Tue, Sep 16, 2008 at 9:38 AM, Andreas Köhler <[EMAIL PROTECTED]> wrote:
> >>
> >>> Hi,
> >>>
> >>> On Mon, 2008-09-01 at 22:09 +0200, Andreas Köhler wrote:
> >>> > Hi Charles,
> >>> >
> >>> > On Sun, 2008-07-27 at 11:33 -0400, Charles Day wrote:
> >>> > > Trac: http://svn.gnucash.org/trac/changeset/17421
> >>> > > Log:
> >>> > > Add a new function to the gnc_numeric library that converts
> >>> denominators to exact powers of ten.
> >>> >
> >>> > > Modified: gnucash/trunk/lib/libqof/qof/gnc-numeric.c
> >>> > > ===
> >>> > > --- gnucash/trunk/lib/libqof/qof/gnc-numeric.c  2008-07-27
> >>> 15:11:19 UTC (rev 17420)
> >>> > > +++ gnucash/trunk/lib/libqof/qof/gnc-numeric.c  2008-07-27
> >>> 15:33:23 UTC (rev 17421)
> >>> > > +  fraction = converted_val.denom;
> >>> > > +  if (fraction <= 0)
> >>> > > +return FALSE;
> >>> >
> >>> > out of curiosity, what is the reason for disallowing negative
> >>> > denominators?  I am not sure whether there is a gnc_numeric API
> >>> function
> >>> > to switch signs of nom and denom safely, but I am sure that doing it is
> >>> > possible :-) But maybe the current behavior is actually desired.
> >>>
> >>> I just noticed that ignoring negative denominators means that 1/(-10) is
> >>> now printed as "1 * 10", where it was printed as "10.00" before.  Is
> >>> that a regression we have to fix or not?
> >>>
> >>
> >> I can see how that would happen, because in previous versions, non-decimal
> >> fractions were forced to print in decimal form in some places. So even
> >> though the old routines considered 1/(-10) non-decimal, it would print it 
> >> as
> >> decimal anyway. I think this takes us back to the original discussion.
> >> Should go ahead and add support for negative denominators to
> >> gnc_numeric_to_decimal()? I must only take less than 5 lines of code.
> >>
> >
> > Here's the first attempt at that change. How are you testing these numbers?
> >
> 
> I went ahead and committed this change in r17554. Calling
> gnc_numeric_to_decimal on 4/-3 now gets you 12. However, there is an
> overflow danger because gnc_numeric_convert()  doesn't check for that
> (apparently this has been a problem for some time). Someone else should
> probably look at that, as I am no expert on 64-bit/128-bit math.

I haven't followed the thread at all, but just in case anyone's not
aware, I thought I should remind everybody about the reciprocal
denominator represention.  IIRC, signs are always stored on the
numerator, and a negative denominator represents a reciprocal
denominator (essentially a multiplication).  Last I knew, this
representation is used internally by some of the operations.

-chris

> 
> -Charles
> 
> 
> > $ svn diff
> > Index: gnc-numeric.c
> > ===
> > --- gnc-numeric.c   (revision 17505)
> > +++ gnc-numeric.c   (working copy)
> > @@ -1043,7 +1043,14 @@
> >
> >converted_val = *a;
> >if (converted_val.denom <= 0)
> > -return FALSE;
> > +  {
> > +converted_val = gnc_numeric_convert(converted_val, 1,
> > GNC_DENOM_EXACT);
> > +if (gnc_numeric_check(converted_val) != GNC_ERROR_OK)
> > +  return FALSE;
> > +*a = converted_val;
> > +*max_decimal_places = decimal_places;
> > +return TRUE;
> > +  }
> >
> >/* Zero is easily converted. */
> >if (converted_val.num == 0)
> >
> >
> >>
> >>
> >>> Ciao,
> >>> -- andi5
> >>>
> >>
> >> Cheers,
> >> Charles
> >>
> >
> >
> ___
> gnucash-devel mailing list
> gnucash-devel@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: AUDIT: r17421 - gnucash/trunk/lib/libqof/qof - Add a new function to the gnc_numeric library that converts denominators to exact powers of ten.

2008-09-18 Thread Charles Day 
On Tue, Sep 16, 2008 at 2:40 PM, Charles Day <[EMAIL PROTECTED]> wrote:

> On Tue, Sep 16, 2008 at 10:54 AM, Charles Day <[EMAIL PROTECTED]> wrote:
>
>> On Tue, Sep 16, 2008 at 9:38 AM, Andreas Köhler <[EMAIL PROTECTED]> wrote:
>>
>>> Hi,
>>>
>>> On Mon, 2008-09-01 at 22:09 +0200, Andreas Köhler wrote:
>>> > Hi Charles,
>>> >
>>> > On Sun, 2008-07-27 at 11:33 -0400, Charles Day wrote:
>>> > > Trac: http://svn.gnucash.org/trac/changeset/17421
>>> > > Log:
>>> > > Add a new function to the gnc_numeric library that converts
>>> denominators to exact powers of ten.
>>> >
>>> > > Modified: gnucash/trunk/lib/libqof/qof/gnc-numeric.c
>>> > > ===
>>> > > --- gnucash/trunk/lib/libqof/qof/gnc-numeric.c  2008-07-27
>>> 15:11:19 UTC (rev 17420)
>>> > > +++ gnucash/trunk/lib/libqof/qof/gnc-numeric.c  2008-07-27
>>> 15:33:23 UTC (rev 17421)
>>> > > +  fraction = converted_val.denom;
>>> > > +  if (fraction <= 0)
>>> > > +return FALSE;
>>> >
>>> > out of curiosity, what is the reason for disallowing negative
>>> > denominators?  I am not sure whether there is a gnc_numeric API
>>> function
>>> > to switch signs of nom and denom safely, but I am sure that doing it is
>>> > possible :-) But maybe the current behavior is actually desired.
>>>
>>> I just noticed that ignoring negative denominators means that 1/(-10) is
>>> now printed as "1 * 10", where it was printed as "10.00" before.  Is
>>> that a regression we have to fix or not?
>>>
>>
>> I can see how that would happen, because in previous versions, non-decimal
>> fractions were forced to print in decimal form in some places. So even
>> though the old routines considered 1/(-10) non-decimal, it would print it as
>> decimal anyway. I think this takes us back to the original discussion.
>> Should go ahead and add support for negative denominators to
>> gnc_numeric_to_decimal()? I must only take less than 5 lines of code.
>>
>
> Here's the first attempt at that change. How are you testing these numbers?
>

I went ahead and committed this change in r17554. Calling
gnc_numeric_to_decimal on 4/-3 now gets you 12. However, there is an
overflow danger because gnc_numeric_convert()  doesn't check for that
(apparently this has been a problem for some time). Someone else should
probably look at that, as I am no expert on 64-bit/128-bit math.

-Charles


> $ svn diff
> Index: gnc-numeric.c
> ===
> --- gnc-numeric.c   (revision 17505)
> +++ gnc-numeric.c   (working copy)
> @@ -1043,7 +1043,14 @@
>
>converted_val = *a;
>if (converted_val.denom <= 0)
> -return FALSE;
> +  {
> +converted_val = gnc_numeric_convert(converted_val, 1,
> GNC_DENOM_EXACT);
> +if (gnc_numeric_check(converted_val) != GNC_ERROR_OK)
> +  return FALSE;
> +*a = converted_val;
> +*max_decimal_places = decimal_places;
> +return TRUE;
> +  }
>
>/* Zero is easily converted. */
>if (converted_val.num == 0)
>
>
>>
>>
>>> Ciao,
>>> -- andi5
>>>
>>
>> Cheers,
>> Charles
>>
>
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: AUDIT: r17421 - gnucash/trunk/lib/libqof/qof - Add a new function to the gnc_numeric library that converts denominators to exact powers of ten.

2008-09-16 Thread Charles Day 
On Tue, Sep 16, 2008 at 10:54 AM, Charles Day <[EMAIL PROTECTED]> wrote:

> On Tue, Sep 16, 2008 at 9:38 AM, Andreas Köhler <[EMAIL PROTECTED]> wrote:
>
>> Hi,
>>
>> On Mon, 2008-09-01 at 22:09 +0200, Andreas Köhler wrote:
>> > Hi Charles,
>> >
>> > On Sun, 2008-07-27 at 11:33 -0400, Charles Day wrote:
>> > > Trac: http://svn.gnucash.org/trac/changeset/17421
>> > > Log:
>> > > Add a new function to the gnc_numeric library that converts
>> denominators to exact powers of ten.
>> >
>> > > Modified: gnucash/trunk/lib/libqof/qof/gnc-numeric.c
>> > > ===
>> > > --- gnucash/trunk/lib/libqof/qof/gnc-numeric.c  2008-07-27
>> 15:11:19 UTC (rev 17420)
>> > > +++ gnucash/trunk/lib/libqof/qof/gnc-numeric.c  2008-07-27
>> 15:33:23 UTC (rev 17421)
>> > > +  fraction = converted_val.denom;
>> > > +  if (fraction <= 0)
>> > > +return FALSE;
>> >
>> > out of curiosity, what is the reason for disallowing negative
>> > denominators?  I am not sure whether there is a gnc_numeric API function
>> > to switch signs of nom and denom safely, but I am sure that doing it is
>> > possible :-) But maybe the current behavior is actually desired.
>>
>> I just noticed that ignoring negative denominators means that 1/(-10) is
>> now printed as "1 * 10", where it was printed as "10.00" before.  Is
>> that a regression we have to fix or not?
>>
>
> I can see how that would happen, because in previous versions, non-decimal
> fractions were forced to print in decimal form in some places. So even
> though the old routines considered 1/(-10) non-decimal, it would print it as
> decimal anyway. I think this takes us back to the original discussion.
> Should go ahead and add support for negative denominators to
> gnc_numeric_to_decimal()? I must only take less than 5 lines of code.
>

Here's the first attempt at that change. How are you testing these numbers?

$ svn diff
Index: gnc-numeric.c
===
--- gnc-numeric.c   (revision 17505)
+++ gnc-numeric.c   (working copy)
@@ -1043,7 +1043,14 @@

   converted_val = *a;
   if (converted_val.denom <= 0)
-return FALSE;
+  {
+converted_val = gnc_numeric_convert(converted_val, 1, GNC_DENOM_EXACT);
+if (gnc_numeric_check(converted_val) != GNC_ERROR_OK)
+  return FALSE;
+*a = converted_val;
+*max_decimal_places = decimal_places;
+return TRUE;
+  }

   /* Zero is easily converted. */
   if (converted_val.num == 0)


>
>
>> Ciao,
>> -- andi5
>>
>
> Cheers,
> Charles
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: AUDIT: r17421 - gnucash/trunk/lib/libqof/qof - Add a new function to the gnc_numeric library that converts denominators to exact powers of ten.

2008-09-16 Thread Charles Day 
On Tue, Sep 16, 2008 at 9:38 AM, Andreas Köhler <[EMAIL PROTECTED]> wrote:

> Hi,
>
> On Mon, 2008-09-01 at 22:09 +0200, Andreas Köhler wrote:
> > Hi Charles,
> >
> > On Sun, 2008-07-27 at 11:33 -0400, Charles Day wrote:
> > > Trac: http://svn.gnucash.org/trac/changeset/17421
> > > Log:
> > > Add a new function to the gnc_numeric library that converts
> denominators to exact powers of ten.
> >
> > > Modified: gnucash/trunk/lib/libqof/qof/gnc-numeric.c
> > > ===
> > > --- gnucash/trunk/lib/libqof/qof/gnc-numeric.c  2008-07-27 15:11:19
> UTC (rev 17420)
> > > +++ gnucash/trunk/lib/libqof/qof/gnc-numeric.c  2008-07-27 15:33:23
> UTC (rev 17421)
> > > +  fraction = converted_val.denom;
> > > +  if (fraction <= 0)
> > > +return FALSE;
> >
> > out of curiosity, what is the reason for disallowing negative
> > denominators?  I am not sure whether there is a gnc_numeric API function
> > to switch signs of nom and denom safely, but I am sure that doing it is
> > possible :-) But maybe the current behavior is actually desired.
>
> I just noticed that ignoring negative denominators means that 1/(-10) is
> now printed as "1 * 10", where it was printed as "10.00" before.  Is
> that a regression we have to fix or not?
>

I can see how that would happen, because in previous versions, non-decimal
fractions were forced to print in decimal form in some places. So even
though the old routines considered 1/(-10) non-decimal, it would print it as
decimal anyway. I think this takes us back to the original discussion.
Should go ahead and add support for negative denominators to
gnc_numeric_to_decimal()? I must only take less than 5 lines of code.


> Ciao,
> -- andi5
>

Cheers,
Charles
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: AUDIT: r17421 - gnucash/trunk/lib/libqof/qof - Add a new function to the gnc_numeric library that converts denominators to exact powers of ten.

2008-09-16 Thread Andreas Köhler 
Hi,

On Mon, 2008-09-01 at 22:09 +0200, Andreas Köhler wrote:
> Hi Charles,
> 
> On Sun, 2008-07-27 at 11:33 -0400, Charles Day wrote:
> > Trac: http://svn.gnucash.org/trac/changeset/17421
> > Log:
> > Add a new function to the gnc_numeric library that converts denominators to 
> > exact powers of ten.
> 
> > Modified: gnucash/trunk/lib/libqof/qof/gnc-numeric.c
> > ===
> > --- gnucash/trunk/lib/libqof/qof/gnc-numeric.c  2008-07-27 15:11:19 UTC 
> > (rev 17420)
> > +++ gnucash/trunk/lib/libqof/qof/gnc-numeric.c  2008-07-27 15:33:23 UTC 
> > (rev 17421)
> > +  fraction = converted_val.denom;
> > +  if (fraction <= 0)
> > +return FALSE;
> 
> out of curiosity, what is the reason for disallowing negative
> denominators?  I am not sure whether there is a gnc_numeric API function
> to switch signs of nom and denom safely, but I am sure that doing it is
> possible :-) But maybe the current behavior is actually desired.

I just noticed that ignoring negative denominators means that 1/(-10) is
now printed as "1 * 10", where it was printed as "10.00" before.  Is
that a regression we have to fix or not?

Ciao,
-- andi5



signature.asc
Description: This is a digitally signed message part
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: AUDIT: r17421 - gnucash/trunk/lib/libqof/qof - Add a new function to the gnc_numeric library that converts denominators to exact powers of ten.

2008-09-03 Thread Micha Lenk 
Hi Christian,

Christian Stimming wrote:
> For sure negative numbers will and must never suddently turn into the inverse
> of a number. Negative != inverted. Really. Always.


I object: Negative numbers *are* inverses of the corresponding positive
numbers with addition being the operation and zero (0) the neutral
element. For multiplication (which is a little bit more related to
powers than addition) the inverse element of a number is its reziprocal
with one (1) being the neutral element. (These are basics of group
theory in mathematics.)


Apparently the design of gnc_numeric_compare() and gnc_numeric_equal()
messed up inverse elements of the two totally different and independent
operations addition and multiplication in a way contradicting
mathematics.

Regards
  Micha
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: AUDIT: r17421 - gnucash/trunk/lib/libqof/qof - Add a new function to the gnc_numeric library that converts denominators to exact powers of ten.

2008-09-02 Thread Charles Day 
On Mon, Sep 1, 2008 at 2:39 PM, Andreas Köhler <[EMAIL PROTECTED]> wrote:

> Hi Charles,
>
> On Mon, 2008-09-01 at 14:24 -0700, Charles Day wrote:
> > On Mon, Sep 1, 2008 at 1:57 PM, Christian Stimming <[EMAIL PROTECTED]>
> > wrote:
> > Am Montag, 1. September 2008 22:44 schrieb Charles Day:
> > > > > +  fraction = converted_val.denom;
> > > > > +  if (fraction <= 0)
> > > > > +return FALSE;
> > > >
> > > > out of curiosity, what is the reason for disallowing
> >     negative
> > > > denominators?
> >
> >
> > My immediate reaction to this question: Denominators should be
> > positive so
> > that a comparison of equal numbers gives predictable results,
> > and also to
> > avoid any confusion about the actual meaning of a negative
> > denominator.
> >
> > > > I am not sure whether there is a gnc_numeric API function
> > > > to switch signs of nom and denom safely, but I am sure
> > that doing it is
> > > > possible :-) But maybe the current behavior is actually
> > desired.
> > >
> > > Honestly, I'm not 100% sure what negative denominators mean.
> > The function I
> > > added is essentially a modified version of
> > is_decimal_fraction() from
> > > app-utils/gnc-ui-utils.c, and since negative denominators
> > were not
> > > considered decimal numbers there, I did the same.
> > >
> > > On the other hand, I believe that a negative denominator of
> > -3 may actually
> > > mean a denominator equal to 1/3. So if a gnc_numeric of 5/-3
> > is equal to
> > > 5/(1/3), then that is also equal to 5*3=15.
> >
> >
> > Uh oh? No, not at all, please. A negative denominator must
> > mean at most that
> > the sign of the rational number is changed from positive to
> > negative, or, if
> > the numerator is negative as well, the sign of the number is
> > changed from
> > negative to positive. No more, no less. As this doesn't make
> > much sense, it
> > is sensible to restrict the denominator to positive numbers
> > only.
> >
> > The gnc-numeric.c code seems to assume that only the numerator is
> > needed to determine sign. For example, gnc_numeric_positive_p() and
> > gnc_numeric_negative_p() only check the sign of the numerator.
> >
> >
> >
> > For sure negative numbers will and must never suddently turn
> > into the inverse
> > of a number. Negative != inverted. Really. Always.
> >
> > There are several mentions of "reciprocal" in gnc-numeric.c comments,
> > referring to a negative denominator. See gnc_numeric_compare() and
> > gnc_numeric_equal(), for example. They seem to be doing what I
> > suggested, i.e. 5/-3 == 15/1.
>
> Indeed.  There is also a documentation for the macro
> GNC_DENOM_RECIPROCAL.  Rest assured that I profoundly dislike this
> "design choice".  Fortunately, it does not seem to be in use (a lot).
> If possible, let us kill it, please.
>

I see that src/engine/test/test-numeric.c does tests to prove that the
reciprocal behavior is working. Hard to tell if that functionality is used
anywhere else though. But I found the following notes in ChangeLog.2006:

2006-02-04 05:37  chris

* [r13090] trunk/src/engine/test/test-numeric.c: Add some
  test-cases for gnc_numerics using the reciprocal denominator.
  Even though we don't explicitly ask for this representation,
  certain calculations (e.g. those involving GNC_HOW_DENOM_SIGFIGS
  in the loan druid and soon in budgets) will return numbers using
  this representation. Unfortunately, these numbers aren't handled
  correctly by most of the gnc_numeric functions, like the ones
  for comparison, equality testing, arithmetic and conversion.

So it seems that the loan druid and budgets may unknowingly rely on
reciprocals.


>
> Ciao,
> -- andi5
>
>
>
Cheers,
Charles
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: AUDIT: r17421 - gnucash/trunk/lib/libqof/qof - Add a new function to the gnc_numeric library that converts denominators to exact powers of ten.

2008-09-01 Thread Andreas Köhler 
Hi Charles,

On Mon, 2008-09-01 at 14:24 -0700, Charles Day wrote:
> On Mon, Sep 1, 2008 at 1:57 PM, Christian Stimming <[EMAIL PROTECTED]>
> wrote:
> Am Montag, 1. September 2008 22:44 schrieb Charles Day:
> > > > +  fraction = converted_val.denom;
> > > > +  if (fraction <= 0)
> > > > +return FALSE;
> > >
> > > out of curiosity, what is the reason for disallowing
> negative
> > > denominators?
> 
> 
> My immediate reaction to this question: Denominators should be
> positive so
> that a comparison of equal numbers gives predictable results,
> and also to
> avoid any confusion about the actual meaning of a negative
> denominator.
> 
> > > I am not sure whether there is a gnc_numeric API function
> > > to switch signs of nom and denom safely, but I am sure
> that doing it is
> > > possible :-) But maybe the current behavior is actually
> desired.
> >
> > Honestly, I'm not 100% sure what negative denominators mean.
> The function I
> > added is essentially a modified version of
> is_decimal_fraction() from
> > app-utils/gnc-ui-utils.c, and since negative denominators
> were not
> > considered decimal numbers there, I did the same.
> >
> > On the other hand, I believe that a negative denominator of
> -3 may actually
> > mean a denominator equal to 1/3. So if a gnc_numeric of 5/-3
> is equal to
> > 5/(1/3), then that is also equal to 5*3=15.
> 
> 
> Uh oh? No, not at all, please. A negative denominator must
> mean at most that
> the sign of the rational number is changed from positive to
> negative, or, if
> the numerator is negative as well, the sign of the number is
> changed from
> negative to positive. No more, no less. As this doesn't make
> much sense, it
> is sensible to restrict the denominator to positive numbers
> only.
> 
> The gnc-numeric.c code seems to assume that only the numerator is
> needed to determine sign. For example, gnc_numeric_positive_p() and
> gnc_numeric_negative_p() only check the sign of the numerator.
> 
> 
> 
> For sure negative numbers will and must never suddently turn
> into the inverse
> of a number. Negative != inverted. Really. Always.
> 
> There are several mentions of "reciprocal" in gnc-numeric.c comments,
> referring to a negative denominator. See gnc_numeric_compare() and
> gnc_numeric_equal(), for example. They seem to be doing what I
> suggested, i.e. 5/-3 == 15/1.

Indeed.  There is also a documentation for the macro
GNC_DENOM_RECIPROCAL.  Rest assured that I profoundly dislike this
"design choice".  Fortunately, it does not seem to be in use (a lot).
If possible, let us kill it, please.

Ciao,
-- andi5




signature.asc
Description: This is a digitally signed message part
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: AUDIT: r17421 - gnucash/trunk/lib/libqof/qof - Add a new function to the gnc_numeric library that converts denominators to exact powers of ten.

2008-09-01 Thread Charles Day 
On Mon, Sep 1, 2008 at 1:57 PM, Christian Stimming <[EMAIL PROTECTED]> wrote:

> Am Montag, 1. September 2008 22:44 schrieb Charles Day:
> > > > +  fraction = converted_val.denom;
> > > > +  if (fraction <= 0)
> > > > +return FALSE;
> > >
> > > out of curiosity, what is the reason for disallowing negative
> > > denominators?
>
> My immediate reaction to this question: Denominators should be positive so
> that a comparison of equal numbers gives predictable results, and also to
> avoid any confusion about the actual meaning of a negative denominator.
>
> > > I am not sure whether there is a gnc_numeric API function
> > > to switch signs of nom and denom safely, but I am sure that doing it is
> > > possible :-) But maybe the current behavior is actually desired.
> >
> > Honestly, I'm not 100% sure what negative denominators mean. The function
> I
> > added is essentially a modified version of is_decimal_fraction() from
> > app-utils/gnc-ui-utils.c, and since negative denominators were not
> > considered decimal numbers there, I did the same.
> >
> > On the other hand, I believe that a negative denominator of -3 may
> actually
> > mean a denominator equal to 1/3. So if a gnc_numeric of 5/-3 is equal to
> > 5/(1/3), then that is also equal to 5*3=15.
>
> Uh oh? No, not at all, please. A negative denominator must mean at most
> that
> the sign of the rational number is changed from positive to negative, or,
> if
> the numerator is negative as well, the sign of the number is changed from
> negative to positive. No more, no less. As this doesn't make much sense, it
> is sensible to restrict the denominator to positive numbers only.
>

The gnc-numeric.c code seems to assume that only the numerator is needed to
determine sign. For example, gnc_numeric_positive_p() and
gnc_numeric_negative_p() only check the sign of the numerator.


> For sure negative numbers will and must never suddently turn into the
> inverse
> of a number. Negative != inverted. Really. Always.
>

There are several mentions of "reciprocal" in gnc-numeric.c comments,
referring to a negative denominator. See gnc_numeric_compare() and
gnc_numeric_equal(), for example. They seem to be doing what I suggested,
i.e. 5/-3 == 15/1.


> Or did I miss anything here?
>
> Regards,
>
> Christian
>

Cheers,
Charles
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: AUDIT: r17421 - gnucash/trunk/lib/libqof/qof - Add a new function to the gnc_numeric library that converts denominators to exact powers of ten.

2008-09-01 Thread Andreas Köhler 
Hi Christian,

On Mon, 2008-09-01 at 22:57 +0200, Christian Stimming wrote:
> Am Montag, 1. September 2008 22:44 schrieb Charles Day:
> > > > +  fraction = converted_val.denom;
> > > > +  if (fraction <= 0)
> > > > +return FALSE;
> > >
> > > out of curiosity, what is the reason for disallowing negative
> > > denominators?
> 
> My immediate reaction to this question: Denominators should be positive so 
> that a comparison of equal numbers gives predictable results, and also to 
> avoid any confusion about the actual meaning of a negative denominator.
> 
> > > I am not sure whether there is a gnc_numeric API function 
> > > to switch signs of nom and denom safely, but I am sure that doing it is
> > > possible :-) But maybe the current behavior is actually desired.
> >
> > Honestly, I'm not 100% sure what negative denominators mean. The function I
> > added is essentially a modified version of is_decimal_fraction() from
> > app-utils/gnc-ui-utils.c, and since negative denominators were not
> > considered decimal numbers there, I did the same.
> >
> > On the other hand, I believe that a negative denominator of -3 may actually
> > mean a denominator equal to 1/3. So if a gnc_numeric of 5/-3 is equal to
> > 5/(1/3), then that is also equal to 5*3=15.
> 
> Uh oh? No, not at all, please. A negative denominator must mean at most that 
> the sign of the rational number is changed from positive to negative, or, if 
> the numerator is negative as well, the sign of the number is changed from 
> negative to positive. No more, no less. As this doesn't make much sense, it 
> is sensible to restrict the denominator to positive numbers only.

I understand that negative denominators might look bewildering to some,
but given the current API, one can _create(5, -1) such a number,
_check() it and get an _OK.  If there is a really made such a
distinction in the other functions, then I guess a comment would be nice
and appropriate conversion in _create almost necessary.

Just my 2¢.


> For sure negative numbers will and must never suddently turn into the inverse 
> of a number. Negative != inverted. Really. Always.
> 
> Or did I miss anything here?

I do not hope so :)

Ciao,
-- andi5



signature.asc
Description: This is a digitally signed message part
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: AUDIT: r17421 - gnucash/trunk/lib/libqof/qof - Add a new function to the gnc_numeric library that converts denominators to exact powers of ten.

2008-09-01 Thread Christian Stimming 
Am Montag, 1. September 2008 22:44 schrieb Charles Day:
> > > +  fraction = converted_val.denom;
> > > +  if (fraction <= 0)
> > > +return FALSE;
> >
> > out of curiosity, what is the reason for disallowing negative
> > denominators?

My immediate reaction to this question: Denominators should be positive so 
that a comparison of equal numbers gives predictable results, and also to 
avoid any confusion about the actual meaning of a negative denominator.

> > I am not sure whether there is a gnc_numeric API function 
> > to switch signs of nom and denom safely, but I am sure that doing it is
> > possible :-) But maybe the current behavior is actually desired.
>
> Honestly, I'm not 100% sure what negative denominators mean. The function I
> added is essentially a modified version of is_decimal_fraction() from
> app-utils/gnc-ui-utils.c, and since negative denominators were not
> considered decimal numbers there, I did the same.
>
> On the other hand, I believe that a negative denominator of -3 may actually
> mean a denominator equal to 1/3. So if a gnc_numeric of 5/-3 is equal to
> 5/(1/3), then that is also equal to 5*3=15.

Uh oh? No, not at all, please. A negative denominator must mean at most that 
the sign of the rational number is changed from positive to negative, or, if 
the numerator is negative as well, the sign of the number is changed from 
negative to positive. No more, no less. As this doesn't make much sense, it 
is sensible to restrict the denominator to positive numbers only.

For sure negative numbers will and must never suddently turn into the inverse 
of a number. Negative != inverted. Really. Always.

Or did I miss anything here?

Regards,

Christian
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: AUDIT: r17421 - gnucash/trunk/lib/libqof/qof - Add a new function to the gnc_numeric library that converts denominators to exact powers of ten.

2008-09-01 Thread Andreas Köhler 
Hi Charles,

On Mon, 2008-09-01 at 13:44 -0700, Charles Day wrote:
> On Mon, Sep 1, 2008 at 1:09 PM, Andreas Köhler <[EMAIL PROTECTED]>
> wrote:
> Hi Charles,
> 
> On Sun, 2008-07-27 at 11:33 -0400, Charles Day wrote:
> > Trac: http://svn.gnucash.org/trac/changeset/17421
> > Log:
> > Add a new function to the gnc_numeric library that converts
> denominators to exact powers of ten.
> 
> > Modified: gnucash/trunk/lib/libqof/qof/gnc-numeric.c
> >
> ===
> > --- gnucash/trunk/lib/libqof/qof/gnc-numeric.c
>  2008-07-27 15:11:19 UTC (rev 17420)
> > +++ gnucash/trunk/lib/libqof/qof/gnc-numeric.c
>  2008-07-27 15:33:23 UTC (rev 17421)
> > +  fraction = converted_val.denom;
> > +  if (fraction <= 0)
> > +return FALSE;
>     
> out of curiosity, what is the reason for disallowing negative
> denominators?  I am not sure whether there is a gnc_numeric
> API function
> to switch signs of nom and denom safely, but I am sure that
> doing it is
> possible :-) But maybe the current behavior is actually
> desired.
> 
> Honestly, I'm not 100% sure what negative denominators mean. The
> function I added is essentially a modified version of
> is_decimal_fraction() from app-utils/gnc-ui-utils.c, and since
> negative denominators were not considered decimal numbers there, I did
> the same.
> 
> On the other hand, I believe that a negative denominator of -3 may
> actually mean a denominator equal to 1/3. So if a gnc_numeric of 5/-3
> is equal to 5/(1/3), then that is also equal to 5*3=15. So maybe any
> gnc_numeric with a negative denominator could be converted to a
> decimal number. Perhaps instead of returning FALSE, the routine could
> compute num * abs(denom) and return TRUE. Assuming that the
> multiplication doesn't cause overflow, and that I have understood the
> situation correctly.
> 
> Anyway, I think it is OK for the moment, as these types of numbers
> never printed decimally in the past. Perhaps Christian could provide
> more information on what negative denominators mean, and if/how we
> could print them as decimal numbers. If the method I stated above is
> correct, then I think it would be a pretty small change to add support
> for negative denominators in this routine.

I would rather say that you can extract signs from nominators as well as
denominators and put them in front of the fraction.  So -(1/3) == (-1)/3
== 1/(-3) and 1/3 == (-1)/(-3).  So the change is probably even
easier :)  But even reversing signs can result in overflows (in a signed
one-byte integer, -128 may be allowed, whereas 128 is not).

You were probably thinking in negative powers, because (1/3)^(-1) == 3/1
== 3.  I just hope I did not talk gibberish :)

Ciao,
-- andi5



signature.asc
Description: This is a digitally signed message part
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: AUDIT: r17421 - gnucash/trunk/lib/libqof/qof - Add a new function to the gnc_numeric library that converts denominators to exact powers of ten.

2008-09-01 Thread Charles Day 
On Mon, Sep 1, 2008 at 1:09 PM, Andreas Köhler <[EMAIL PROTECTED]> wrote:

> Hi Charles,
>
> On Sun, 2008-07-27 at 11:33 -0400, Charles Day wrote:
> > Trac: http://svn.gnucash.org/trac/changeset/17421
> > Log:
> > Add a new function to the gnc_numeric library that converts denominators
> to exact powers of ten.
>
> > Modified: gnucash/trunk/lib/libqof/qof/gnc-numeric.c
> > ===
> > --- gnucash/trunk/lib/libqof/qof/gnc-numeric.c2008-07-27 15:11:19
> UTC (rev 17420)
> > +++ gnucash/trunk/lib/libqof/qof/gnc-numeric.c2008-07-27 15:33:23
> UTC (rev 17421)
> > +  fraction = converted_val.denom;
> > +  if (fraction <= 0)
> > +return FALSE;
>
> out of curiosity, what is the reason for disallowing negative
> denominators?  I am not sure whether there is a gnc_numeric API function
> to switch signs of nom and denom safely, but I am sure that doing it is
> possible :-) But maybe the current behavior is actually desired.
>

Honestly, I'm not 100% sure what negative denominators mean. The function I
added is essentially a modified version of is_decimal_fraction() from
app-utils/gnc-ui-utils.c, and since negative denominators were not
considered decimal numbers there, I did the same.

On the other hand, I believe that a negative denominator of -3 may actually
mean a denominator equal to 1/3. So if a gnc_numeric of 5/-3 is equal to
5/(1/3), then that is also equal to 5*3=15. So maybe any gnc_numeric with a
negative denominator could be converted to a decimal number. Perhaps instead
of returning FALSE, the routine could compute num * abs(denom) and return
TRUE. Assuming that the multiplication doesn't cause overflow, and that I
have understood the situation correctly.

Anyway, I think it is OK for the moment, as these types of numbers never
printed decimally in the past. Perhaps Christian could provide more
information on what negative denominators mean, and if/how we could print
them as decimal numbers. If the method I stated above is correct, then I
think it would be a pretty small change to add support for negative
denominators in this routine.


> Ciao,
> -- andi5
>
>
Cheers,
Charles
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: AUDIT: r17421 - gnucash/trunk/lib/libqof/qof - Add a new function to the gnc_numeric library that converts denominators to exact powers of ten.

2008-09-01 Thread Andreas Köhler 
Hi Charles,

On Sun, 2008-07-27 at 11:33 -0400, Charles Day wrote:
> Trac: http://svn.gnucash.org/trac/changeset/17421
> Log:
> Add a new function to the gnc_numeric library that converts denominators to 
> exact powers of ten.

> Modified: gnucash/trunk/lib/libqof/qof/gnc-numeric.c
> ===
> --- gnucash/trunk/lib/libqof/qof/gnc-numeric.c2008-07-27 15:11:19 UTC 
> (rev 17420)
> +++ gnucash/trunk/lib/libqof/qof/gnc-numeric.c2008-07-27 15:33:23 UTC 
> (rev 17421)
> +  fraction = converted_val.denom;
> +  if (fraction <= 0)
> +return FALSE;

out of curiosity, what is the reason for disallowing negative
denominators?  I am not sure whether there is a gnc_numeric API function
to switch signs of nom and denom safely, but I am sure that doing it is
possible :-) But maybe the current behavior is actually desired.

Ciao,
-- andi5



signature.asc
Description: This is a digitally signed message part
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: denominators

2000-07-16 Thread Dylan Paul Thurston 

On Sat, Jul 08, 2000 at 10:36:26AM -0500, Christopher Browne wrote:
> On Sat, 08 Jul 2000 10:17:52 EST, the world broke into rejoicing as
> Richard Wackerbarth <[EMAIL PROTECTED]>  said:
> > Although this is functional, I object to re-denomination because
> > the auditors want the ledger to match the original transaction
> > documents.
> >
> > Once an entry is properly entered, that entry should never change.
> 
> The thing that would legitimately need to change would be the name of
> the currency.
> 
> Supposing, for instance, the Fed decides that the US Dollar has inflated
> too much, and that they need to issue "new dollars" in a 1:100 ratio
> for the old ones.  That is, for $100 of "old" currency, or "old"
> balances, you get $1 in the "new, improved" version.
> ...
> In that case, it is likely that we want to rename all the "old"
> occurances from being "USD" to being "USD.old" or some such thing,
> as _new_ references should reference the commodity as it exists today.

One way to take care of this without changing old transactions (which
could be a royal pain; what if they're in different files?) would be
to include the date of creation of each currency.  Thus, after the
crash caused by the start of the new millenium, one "USD_20010101"
would be worth 100 "USD_Epoch".

(I don't like including the date in a character string like this.)

--Dylan Thurston


___
gnucash-devel mailing list
[EMAIL PROTECTED]
http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel

Re: denominators

2000-07-08 Thread Hendrik Boom 

> 
> Unfortunately, it is sometimes difficult to distinguish humor from lack of 
> understanding.
> 

There may be good reason for this difficulty.  I suspect humour may
have eveolved as a social mechanism by which those who do not understand
can express same without embarassment.

I suspect this thread has now wandered completely off topic.

-- hendrik.


--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]

Re: denominators

2000-07-08 Thread Richard Wackerbarth 

On Sat, 08 Jul 2000, Christopher Browne wrote:

> > Although this is functional, I object to re-denomination because
> > the auditors want the ledger to match the original transaction
> > documents.
> >
> > Once an entry is properly entered, that entry should never change.
>
> The thing that would legitimately need to change would be the name of
> the currency.
>
> Supposing, for instance, the Fed decides that the US Dollar has inflated
> too much, and that they need to issue "new dollars" in a 1:100 ratio
> for the old ones.  That is, for $100 of "old" currency, or "old"
> balances, you get $1 in the "new, improved" version.
>
> [Admittedly, this particular scenario is vastly unlikely.  Change from
> $USD to the currencies of nations that have suffered from hyperinflation
> such as Israel, Mexico, Germany, and others, or to the not unusual
> scenario of a stock split and the scenario becomes not merely believable,
> but a somewhat common occurance...]
>
> In that case, it is likely that we want to rename all the "old"
> occurances from being "USD" to being "USD.old" or some such thing,
> as _new_ references should reference the commodity as it exists today.

I agree that New Pesos are different from Old Pesos. They MUST be stored in 
the database as different entities.

However, I'm not sure that the correct solution is to change the old 
designation rather than changing the new one.

All historically archived data would have to be changed. This may not be 
possible. However, it is possible to assure that new data is entered in the 
new units.

Now, I will allow that you probably should change the display of the old 
units to conform to current practice.

> > 
...
> > 

> I don't want to touch this one...

Sit down. Have some coffee and Pi.

--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]

Re: denominators

2000-07-08 Thread Hendrik Boom 

> 
> > > Actually, a problem that none of the proposals in this mailing list
> > > addresses is the possibility that a commodity mught be bought and
> > > sold in units whose conversion factors are irrational.
> > 
> > As I said before, you can have irrational pricing but not irrational prices.
> > The ledgers represent inventories. Inventories can be counted.
> > Prices are exchange ratios. You trade items in one inventory for items in a 
> > different inventory. As such, field theory tells us that we will never have 
> > to deal with values that cannot be mapped onto the rational numbers.
> 
> People do _not_ use irrational numbers; supposing they count in radians,
> the one situation where it might _appear_ to be an exception, they're
> likely basing this on _integer fractions_ of radians, which means that
> the unit of measure is an integer fraction that just happens to get
> multiplied by Pi so as to make it _appear_ irrational.
> 
Good Grief, that irrational number thing was a joke!

> > >  Can you, for example buy angles in degrees and sell them in radians?
> > 
> > 
> > Well, I won't "buy" that angle. 
> > Where did you buy your degree?
> > Radian's already been sold.
> > 

But not marked as such because I was unaware of the HTML  tag. :-(
Or is that a joke, too? :-)

> > 


--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]

Re: denominators

2000-07-08 Thread Christopher Browne 

On Sat, 08 Jul 2000 10:17:52 EST, the world broke into rejoicing as
Richard Wackerbarth <[EMAIL PROTECTED]>  said:
> On Sat, 08 Jul 2000, Hendrik Boom wrote:
> > One of the big issues seems to be whether we have just one denominator
> > for a commodity, or many.
> 
> > Let each commodity to have its own common denominator, but change this
> > denominator when new transactions make it necessary.  The new denominator
> > be a multiple of the old one.  Changing a denominator involves
> > retroactively rewrite all existing transactions that involved that
> > denominator.
> 
> Although this is functional, I object to re-denomination because
> the auditors want the ledger to match the original transaction
> documents.
>
> Once an entry is properly entered, that entry should never change.

The thing that would legitimately need to change would be the name of
the currency.

Supposing, for instance, the Fed decides that the US Dollar has inflated
too much, and that they need to issue "new dollars" in a 1:100 ratio
for the old ones.  That is, for $100 of "old" currency, or "old"
balances, you get $1 in the "new, improved" version.

[Admittedly, this particular scenario is vastly unlikely.  Change from
$USD to the currencies of nations that have suffered from hyperinflation
such as Israel, Mexico, Germany, and others, or to the not unusual
scenario of a stock split and the scenario becomes not merely believable,
but a somewhat common occurance...]

In that case, it is likely that we want to rename all the "old"
occurances from being "USD" to being "USD.old" or some such thing,
as _new_ references should reference the commodity as it exists today.

> > Actually, a problem that none of the proposals in this mailing list
> > addresses is the possibility that a commodity mught be bought and
> > sold in units whose conversion factors are irrational.
> 
> As I said before, you can have irrational pricing but not irrational prices.
> The ledgers represent inventories. Inventories can be counted.
> Prices are exchange ratios. You trade items in one inventory for items in a 
> different inventory. As such, field theory tells us that we will never have 
> to deal with values that cannot be mapped onto the rational numbers.

People do _not_ use irrational numbers; supposing they count in radians,
the one situation where it might _appear_ to be an exception, they're
likely basing this on _integer fractions_ of radians, which means that
the unit of measure is an integer fraction that just happens to get
multiplied by Pi so as to make it _appear_ irrational.

> >  Can you, for example buy angles in degrees and sell them in radians?
> 
> 
> Well, I won't "buy" that angle. 
> Where did you buy your degree?
> Radian's already been sold.
> 
> 
> For those of you outside the Silicon Hills, Radian Corp was a spinoff of 
> Tracor, Inc. here in Austin. They are a leader in environmental monitoring 
> and similar engineering.

I don't want to touch this one...
--
[EMAIL PROTECTED] - 
"I find it hard to believe a professional programmer could support the
concept of Open Source." -- David J. Owens <[EMAIL PROTECTED]>

--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]

Re: denominators

2000-07-08 Thread Richard Wackerbarth 

On Sat, 08 Jul 2000, Hendrik Boom wrote:
> One of the big issues seems to be whether we have just one denominator
> for a commodity, or many.

> Let each commodity to have its own common denominator, but change this
> denominator when new transactions make it necessary.  The new denominator
> be a multiple of the old one.  Changing a denominator involves
> retroactively rewrite all existing transactions that involved that
> denominator.

Although this is functional, I object to re-denomination because the auditors 
want the ledger to match the original transaction documents.

Once an entry is properly entered, that entry should never change.

> Actually, a problem that none of the proposals in this mailing list
> addresses is the possibility that a commodity mught be bought and
> sold in units whose conversion factors are irrational.

As I said before, you can have irrational pricing but not irrational prices.
The ledgers represent inventories. Inventories can be counted.
Prices are exchange ratios. You trade items in one inventory for items in a 
different inventory. As such, field theory tells us that we will never have 
to deal with values that cannot be mapped onto the rational numbers.

>  Can you, for example buy angles in degrees and sell them in radians?


Well, I won't "buy" that angle. 
Where did you buy your degree?
Radian's already been sold.


For those of you outside the Silicon Hills, Radian Corp was a spinoff of 
Tracor, Inc. here in Austin. They are a leader in environmental monitoring 
and similar engineering.

--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]

denominators

2000-07-08 Thread Hendrik Boom 

One of the big issues seems to be whether we have just one denominator
for a commodity, or many.  Examples are being thrown around about
whether there is a quantum unit of a commodity,  whether it changes,
and how often, and whether the quantum unit is so intrinsic to a commodity
that, say,  milk bought by the gallon is a different commodity from
milk bought by the quart.  Indeed, if every transaction involves its
own denominator, independent of any other, using a fixed denominator
would seem to be madness.  It all transactions can be expressed in the
same denominator, which is known a priori, there is no need to store it
with every transaction. The choice of data representation is merely an
optimization issue.

Reality does not seem to be as neat as either of these extremes,
though, and so the optimisation issue may have to resolved by a compromise.

Let each commodity to have its own common denominator, but change this
denominator when new transactions make it necessary.  The new denominator
be a multiple of the old one.  Changing a denominator involves retroactively
rewrite all existing transactions that involved that denominator.

In typical situations the I imagine, the denominator for any commodity
will settle down after a few transactions, after which all remaining
transactions will be expressible in exact multiples of the final
quantum.  Even if an exchange redenominates fron 1/64 to 1/100,
this would only change our common denominator for one of its
commodities from 1/64 to 1/1600.

-

There is one nightmare situation for this approach: a series of
transactions in a commodity whose amounts have relatively prime
denominators.  For example you might buy milk on consecutive days:
1/liter, 1/3 liter, 1/5 liter, 1/7 liter, 1/11 liter, 1/13 liter,
1/17 liter, 1/19 liter, 1/23 liter, 1/29 liter.  The denominator will
skyrocket, and reach the limit of 32 or 64-bit integer representation
rather quickly, after which your grocery-budget accountant will
worry about thee gnucash integer overflow.

Actually, a problem that none of the proposals in this mailing list
addresses is the possibility that a commodity mught be bought and
sold in units whose conversion factors are irrational.  Can you, for
example buy angles in degrees and sell them in radians?  Now the accountant
can no longer  remain silent.  He formally accuses you of being a
mathematician. :-)

-- hendrik.

--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]