Introduction of fractions exposes uniform vector prototype bug

Introduction of fractions exposes uniform vector prototype bug

[Mikael Djurfeldt]

In the silly uniform vector (and array) prototype system, the
canonical prototype for uniform double vectors is (according to the
entry on uniform arrays in the manual) 1/3.

However, since 1/3 is no longer a real, uniform vector creation with
this prototype fails...

I have no good suggestion for what to do about this, but one thing is
certain: We can't suggest people to use 1/3 as prototype for double
arrays (at least now without modifying scm_make_uve).

Note also, that prototypes like 1.0 menas uniform float array...

M

(Who leaves this problem for somebody else to fix.)


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Introduction of fractions exposes uniform vector prototype bug

[Kevin Ryde]

[-- Attachment #1: Type: text/plain, Size: 1190 bytes --]

Mikael Djurfeldt <mdj@mit.edu> writes:
>
> I have no good suggestion for what to do about this, but one thing is
> certain: We can't suggest people to use 1/3 as prototype for double
> arrays (at least now without modifying scm_make_uve).

I'd be pretty inclined to make it a special case, for compatibility.

Asking people to change their code after they've followed something
the manual explicitly said is never nice.

Fractions apart from 1/3 could be left to indicate an array of
fractions, if such a thing is added in the future.

Perhaps (below),

        * unif.c (scm_make_uve): Recognise 1/3 for a dvect array of doubles,
        as specified in the manual.
        (scm_dimensions_to_uniform_array): Convert prototype 1/3 to an
        inexact, as required by scm_array_fill_x.
        (exactly_one_third): New variable.
        (scm_init_unif): Initialize it.

        * tests/unif.test: New file.

Maybe array-fill! should use scm_num2dbl the same way array-set! does,
instead of converting in scm_dimensions_to_uniform_array.

I think it'd make a lot of sense for array-fill! and array-set! to
accept the same operands.  (Irrespective of what's done or not done to
make_uve.)


[-- Attachment #2: unif.c.dvect.diff --]
[-- Type: text/plain, Size: 2499 bytes --]

--- unif.c.~1.137.~	2003-09-13 09:34:18.000000000 +1000
+++ unif.c	2003-12-19 15:22:10.000000000 +1000
@@ -1,4 +1,5 @@
-/* Copyright (C) 1995,1996,1997,1998,2000,2001 Free Software Foundation, Inc.
+/* Copyright (C) 1995,1996,1997,1998,2000,2001,2003 Free Software
+ * Foundation, Inc.
  * 
  * This library is free software; you can redistribute it and/or
  * modify it under the terms of the GNU Lesser General Public
@@ -72,6 +73,7 @@
  */
 
 scm_t_bits scm_tc16_array;
+static SCM exactly_one_third;
 
 /* return the size of an element in a uniform array or 0 if type not
    found.  */
@@ -175,6 +177,15 @@
       else
 	type = scm_tc7_ivect;
     }
+  else if (SCM_FRACTIONP (prot))
+    {
+      /* The manual says "1/3" is the prototype for a "double".  This was
+         fine before fractions existed, 1/3 gave a flonum which didn't fit a
+         "float" (not without rounding).  But now we need to check for this
+         value explicitly (to maintain upward compatibility).  */
+      if (scm_num_eq_p (exactly_one_third, prot))
+        goto dvect;
+    }
   else if (SCM_SYMBOLP (prot) && (1 == SCM_SYMBOL_LENGTH (prot)))
     {
       char s;
@@ -213,6 +224,7 @@
     }
   else
     {
+    dvect:
       i = sizeof (double) * k;
       type = scm_tc7_dvect;
     }
@@ -574,7 +586,11 @@
       else if (SCM_SYMBOLP (prot))
 	scm_array_fill_x (answer, SCM_MAKINUM (0));
       else
-	scm_array_fill_x (answer, prot);
+        {
+          if (SCM_FRACTIONP (prot) && scm_num_eq_p (exactly_one_third, prot))
+            prot = scm_exact_to_inexact (prot);
+          scm_array_fill_x (answer, prot);
+        }
       return answer;
     }
   
@@ -599,7 +615,11 @@
   else if (SCM_SYMBOLP (prot))
     scm_array_fill_x (ra, SCM_MAKINUM (0));
   else
-    scm_array_fill_x (ra, prot);
+    {
+      if (SCM_FRACTIONP (prot) && scm_num_eq_p (exactly_one_third, prot))
+        prot = scm_exact_to_inexact (prot);
+      scm_array_fill_x (ra, prot);
+    }
 
   if (1 == SCM_ARRAY_NDIM (ra) && 0 == SCM_ARRAY_BASE (ra))
     if (s->ubnd < s->lbnd || (0 == s->lbnd && 1 == s->inc))
@@ -2585,6 +2605,8 @@
   scm_set_smob_free (scm_tc16_array, array_free);
   scm_set_smob_print (scm_tc16_array, scm_raprin1);
   scm_set_smob_equalp (scm_tc16_array, scm_array_equal_p);
+  exactly_one_third = scm_permanent_object (scm_make_ratio (SCM_MAKINUM (1),
+                                                            SCM_MAKINUM (3)));
   scm_add_feature ("array");
 #include "libguile/unif.x"
 }

[-- Attachment #3: unif.test --]
[-- Type: text/plain, Size: 3297 bytes --]

;;;; unif.test --- tests guile's uniform arrays     -*- scheme -*-
;;;;
;;;; Copyright 2003 Free Software Foundation, Inc.
;;;;
;;;; This library is free software; you can redistribute it and/or
;;;; modify it under the terms of the GNU Lesser General Public
;;;; License as published by the Free Software Foundation; either
;;;; version 2.1 of the License, or (at your option) any later version.
;;;; 
;;;; This library is distributed in the hope that it will be useful,
;;;; but WITHOUT ANY WARRANTY; without even the implied warranty of
;;;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
;;;; Lesser General Public License for more details.
;;;; 
;;;; You should have received a copy of the GNU Lesser General Public
;;;; License along with this library; if not, write to the Free Software
;;;; Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA

(define-module (test-suite test-unif)
  #:use-module (test-suite lib)
  #:use-module (ice-9 documentation))

;;;
;;; prototypes
;;;

(with-test-prefix "prototypes"

  (with-test-prefix "make-uniform-vector"
    (pass-if "bool"
      (eq? #t (array-prototype (make-uniform-vector 1 #t))))

    (pass-if "char"
      (char=? #\a (array-prototype (make-uniform-vector 1 #\a))))

    (pass-if "byte"
      (char=? #\nul (array-prototype (make-uniform-vector 1 #\nul))))

    (pass-if "short"
      (eq? 's (array-prototype (make-uniform-vector 1 's))))

    (pass-if "ulong"
      (= 1 (array-prototype (make-uniform-vector 1 1))))

    (pass-if "long"
      (= -1 (array-prototype (make-uniform-vector 1 -1))))

    ;; FIXME: What's a good way to tell if long long is available?
    ;; (pass-if "long long"
    ;;   (eq? 'l (array-prototype (make-uniform-vector 1 'l))))

    (pass-if "float"
      (= 1.0 (array-prototype (make-uniform-vector 1 1.0))))

    (with-test-prefix "double"
      (pass-if "no fill"
	(= 1/3 (array-prototype (make-uniform-vector 1 1/3))))
      (pass-if "fill 1.0"
	(= 1/3 (array-prototype (make-uniform-vector 1 1/3 1.0)))))

    (pass-if "complex"
      (= 0+i (array-prototype (make-uniform-vector 1 0+i))))

    (pass-if "scm"
      (eq? '() (array-prototype (make-uniform-vector 1 '())))))

  (with-test-prefix "make-uniform-vector"

    (pass-if "bool"
      (eq? #t (array-prototype (make-uniform-array #t '(5 6)))))

    (pass-if "char"
      (char=? #\a (array-prototype (make-uniform-array #\a '(5 6)))))

    (pass-if "byte"
      (char=? #\nul (array-prototype (make-uniform-array #\nul '(5 6)))))

    (pass-if "short"
      (eq? 's (array-prototype (make-uniform-array 's '(5 6)))))

    (pass-if "ulong"
      (= 1 (array-prototype (make-uniform-array 1 '(5 6)))))

    (pass-if "long"
      (= -1 (array-prototype (make-uniform-array -1 '(5 6)))))

    ;; FIXME: What's a good way to tell if long long is available?
    ;; (pass-if "long long"
    ;;   (eq? 'l (array-prototype (make-uniform-array 'l '(5 6)))))

    (pass-if "float"
      (= 1.0 (array-prototype (make-uniform-array 1.0 '(5 6)))))

    (pass-if "double"
      (= 1/3 (array-prototype (make-uniform-array 1/3 '(5 6)))))

    (pass-if "complex"
      (= 0+i (array-prototype (make-uniform-array 0+i '(5 6)))))

    (pass-if "scm"
      (eq? '() (array-prototype (make-uniform-array '( '(5 6))))))))

[-- Attachment #4: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Introduction of fractions exposes uniform vector prototype bug

[tomas]

On Sat, Dec 20, 2003 at 07:38:16AM +1000, Kevin Ryde wrote:
> Mikael Djurfeldt <mdj@mit.edu> writes:
> >
> > I have no good suggestion for what to do about this, but one thing is
> > certain: We can't suggest people to use 1/3 as prototype for double
> > arrays (at least now without modifying scm_make_uve).
> 
> I'd be pretty inclined to make it a special case, for compatibility.
> 
> Asking people to change their code after they've followed something
> the manual explicitly said is never nice.

Hmmm. You have a point there...

But sometime you'll have to tell them that Santa ain't really ;-/
(it's quite a surprising thing to carry forever: 1/3 behaves here
as an inexact, whereas 1/6 doesn't).

I'd propose making it a deprecated feature, to let it fade off
slowly. Opinions?

What do we take as prototype now for an inexact? Do we have a
constant for sqrt2 (or better pi -- algebraic numbers might
be coming someday ;)

Someone (was it Mikael?) expressed dislike for this prototype
business. I too think it sticks out a bit. Maybe real names
for number classes would be better.

Regards
-- tomas


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Introduction of fractions exposes uniform vector prototype bug

[Stephen Compall]

tomas@fabula.de writes:

> Hmmm. You have a point there...
> 
> But sometime you'll have to tell them that Santa ain't really ;-/
> (it's quite a surprising thing to carry forever: 1/3 behaves here
> as an inexact, whereas 1/6 doesn't).
> 
> I'd propose making it a deprecated feature, to let it fade off
> slowly. Opinions?

It *is* a little too idiosyncratic for a good clean language.

> Someone (was it Mikael?) expressed dislike for this prototype
> business. I too think it sticks out a bit. Maybe real names
> for number classes would be better.

I have three proposals:

1. Type names as symbols, based on the type predicates minus '?'
2. The type predicates (subrs, not symbols) themselves.
3. GOOPS classes (I know all the basic types have them, don't try to
   hide it :)

--
Stephen Compall or s11 or sirian

Proof techniques #2: Proof by Oddity.
	SAMPLE: To prove that horses have an infinite number of legs.
(1) Horses have an even number of legs.
(2) They have two legs in back and fore legs in front.
(3) This makes a total of six legs, which certainly is an odd number of
    legs for a horse.
(4) But the only number that is both odd and even is infinity. 
(5) Therefore, horses must have an infinite number of legs.

Topics is be covered in future issues include proof by:
	Intimidation
	Gesticulation (handwaving)
	"Try it; it works"
	Constipation (I was just sitting there and ...)
	Blatant assertion
	Changing all the 2's to _\bn's
	Mutual consent
	Lack of a counterexample, and
	"It stands to reason"

AK-47 FTS2000 Leuken-Baden Serbian BRLO JFK hackers $400 million in
gold bullion bemd illuminati pink noise Becker Honduras MIT-LL ASO


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Introduction of fractions exposes uniform vector prototype bug

[Kevin Ryde]

tomas@fabula.de writes:
>
> (it's quite a surprising thing to carry forever: 1/3 behaves here
> as an inexact, whereas 1/6 doesn't).

Yep.  No claims that it's pretty.

> I'd propose making it a deprecated feature, to let it fade off
> slowly. Opinions?

My usual objection to deprecation is that if one is serious about
compatibility the old way has to stick around almost forever.

If a new way can be lots cleaner then it might make sense to add it as
well though.

> Maybe real names for number classes would be better.

I guess something like that would be unambiguous.


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Introduction of fractions exposes uniform vector prototype bug

[Marius Vollmer]

Kevin Ryde <user42@zip.com.au> writes:

> Mikael Djurfeldt <mdj@mit.edu> writes:
>>
>> I have no good suggestion for what to do about this, but one thing is
>> certain: We can't suggest people to use 1/3 as prototype for double
>> arrays (at least now without modifying scm_make_uve).
>
> I'd be pretty inclined to make it a special case, for compatibility.
>
> Asking people to change their code after they've followed something
> the manual explicitly said is never nice.
>
> Fractions apart from 1/3 could be left to indicate an array of
> fractions, if such a thing is added in the future.
>
> Perhaps (below),

Yes, excellent.  Please apply.

We probably should get rid of the prototype scheme completely, sooner
or later...

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Introduction of fractions exposes uniform vector prototype bug

[Kevin Ryde]

Marius Vollmer <mvo@zagadka.de> writes:
>
> Yes, excellent.  Please apply.

I think I'll make array-fill! convert with num2dbl, like I mentioned,
which would mean the calls to scm_array_fill_x don't change.

It occurred to me there's also a question about what array-prototype
should return.

A fraction 1/3 would match the manual, and be good for anyone testing
(= 1/3 (array-prototype a)).

A flonum is of course what it returned in 1.6, but I'm thinking that
keeping "= 1/3" working is more important.


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Introduction of fractions exposes uniform vector prototype bug

[Kevin Ryde]

The changes will be,

        * unif.c (scm_make_uve, scm_array_p): Allow fraction 1/3 as prototype
        for dvect.
        (scm_array_p): Add missing "break"s in switch, fix llvect test look
        for "l" not "s", fix dvect to reject singp(prot) which is for fvect.
        (scm_array_prototype): Return 1/3 for dvect, rather than 0.33..33.

        * ramap.c (scm_array_fill_x): For fvect and dvect, use scm_num2dbl to
        convert args the same way that array-set! does.

Looks like nobody ever ran array? with the prototype argument, the
missing "break"s made it completely broken.  That fix will be for the
1.6 branch too I think.

(And in 1.6 there needs to be a NIMP before singp in the fvect case.)


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Introduction of fractions exposes uniform vector prototype bug

[Rob Browning]

Kevin Ryde <user42@zip.com.au> writes:

> Looks like nobody ever ran array? with the prototype argument, the
> missing "break"s made it completely broken.  That fix will be for the
> 1.6 branch too I think.

Yes, it should definitely be fixed there too.

Thanks
-- 
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592  F9A0 25C8 D377 8C7E 73A4


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Introduction of fractions exposes uniform vector prototype bug

[Kevin Ryde]

I made some changes and added tests.

The only likely incompatibility should be if someone has been silly
enough to test inexact? on the return from array-prototype.  Not sure
if that's worth mentioning in the docs, I think probably not.


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel