Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #3526 > unrolled thread

char to decimal

Back to article view | Back to comp.lang.java.programmer

Contents

  char to decimal Dirk Bruere at NeoPax <dirk.bruere@gmail.com> - 2011-05-05 01:43 +0100
    Re: char to decimal Knute Johnson <nospam@rabbitbrush.frazmtn.com> - 2011-05-04 17:49 -0700
    Re: char to decimal Ian Shef <invalid@avoiding.spam> - 2011-05-05 01:06 +0000
      Re: char to decimal Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> - 2011-05-05 20:03 +1200
        Re: char to decimal Lew <noone@lewscanon.com> - 2011-05-05 07:03 -0400
          Re: char to decimal Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2011-05-05 11:18 +0000
            Re: char to decimal Patricia Shanahan <pats@acm.org> - 2011-05-05 06:11 -0700
              Re: char to decimal Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> - 2011-05-06 01:59 +1200
                Re: char to decimal Mayeul <mayeul.marguet@free.fr> - 2011-05-05 16:53 +0200
                  Re: char to decimal Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> - 2011-05-06 11:49 +1200
                    Re: char to decimal Mayeul <mayeul.marguet@free.fr> - 2011-05-06 08:46 +0200
                      Re: char to decimal Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> - 2011-05-06 18:43 +1200
                        Re: char to decimal Lew <noone@lewscanon.com> - 2011-05-06 06:52 -0400
                          Re: char to decimal Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2011-05-06 11:39 +0000
                Re: char to decimal Joshua Cranmer <Pidgeot18@verizon.invalid> - 2011-05-05 14:13 -0400
                  Re: char to decimal Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> - 2011-05-06 11:49 +1200
                    Re: char to decimal Mayeul <mayeul.marguet@free.fr> - 2011-05-06 08:47 +0200
                      Re: char to decimal Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> - 2011-05-06 18:43 +1200
                        Re: char to decimal Lew <noone@lewscanon.com> - 2011-05-06 06:54 -0400
                      Re: char to decimal Jussi Piitulainen <jpiitula@ling.helsinki.fi> - 2011-05-06 10:30 +0300
                Re: char to decimal Lew <noone@lewscanon.com> - 2011-05-05 17:05 -0400
              Re: char to decimal Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2011-05-05 14:56 +0000
                Re: char to decimal Paul Cager <paul.cager@googlemail.com> - 2011-05-05 11:48 -0700
                  Re: char to decimal Lew <noone@lewscanon.com> - 2011-05-05 17:06 -0400
                  Re: char to decimal Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2011-05-05 21:28 +0000
                    Re: char to decimal Lew <noone@lewscanon.com> - 2011-05-05 17:32 -0400
                      Re: char to decimal Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2011-05-06 08:31 +0000
            Re: char to decimal Lew <noone@lewscanon.com> - 2011-05-05 17:04 -0400
        boolean to int : was char to decimal Jeff Higgins <jeff@invalid.invalid> - 2011-05-06 09:00 -0400
          Re: boolean to int : was char to decimal Patricia Shanahan <pats@acm.org> - 2011-05-06 06:54 -0700
          Re: boolean to int : was char to decimal markspace <-@.> - 2011-05-06 07:07 -0700
            Re: boolean to int : was char to decimal markspace <-@.> - 2011-05-06 08:30 -0700
          Re: boolean to int : was char to decimal Nigel Wade <nmw-news@ion.le.ac.uk> - 2011-05-06 15:35 +0100
          Re: boolean to int : was char to decimal Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2011-05-06 19:12 +0200
          Re: boolean to int : was char to decimal Jeff Higgins <jeff@invalid.invalid> - 2011-05-06 13:26 -0400
            Re: boolean to int : was char to decimal Jeff Higgins <jeff@invalid.invalid> - 2011-05-06 21:25 -0400
            Re: boolean to int : was char to decimal Jeff Higgins <jeff@invalid.invalid> - 2011-05-06 21:28 -0400
            Re: boolean to int : was char to decimal Michael Wojcik <mwojcik@newsguy.com> - 2011-05-09 12:51 -0400
              Re: boolean to int : was char to decimal Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2011-05-09 23:54 +0000
              Re: boolean to int : was char to decimal Jeff Higgins <jeff@invalid.invalid> - 2011-05-09 20:51 -0400
                Re: boolean to int : was char to decimal Michael Wojcik <mwojcik@newsguy.com> - 2011-05-10 11:20 -0400
                Re: boolean to int : was char to decimal Jeff Higgins <jeff@invalid.invalid> - 2011-06-23 07:26 -0400
                  Re: boolean to int : was char to decimal Roedy Green <see_website@mindprod.com.invalid> - 2011-06-23 10:07 -0700
                    Re: boolean to int : was char to decimal bugbear <bugbear@trim_papermule.co.uk_trim> - 2011-06-24 09:51 +0100
              Re: boolean to int : was char to decimal Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> - 2011-05-10 13:47 +1200
                Re: boolean to int : was char to decimal Michael Wojcik <mwojcik@newsguy.com> - 2011-05-10 11:02 -0400
                  Re: boolean to int : was char to decimal Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> - 2011-05-11 14:05 +1200
                    Re: boolean to int : was char to decimal Jeff Higgins <jeff@invalid.invalid> - 2011-05-11 08:11 -0400
    Re: char to decimal Dirk Bruere at NeoPax <dirk.bruere@gmail.com> - 2011-05-05 02:12 +0100
    Re: char to decimal Lew <noone@lewscanon.com> - 2011-05-04 21:59 -0400
      Re: char to decimal Dirk Bruere at NeoPax <dirk.bruere@gmail.com> - 2011-05-05 16:14 +0100
        Re: char to decimal markspace <-@.> - 2011-05-05 11:20 -0700
          Re: char to decimal Lew <noone@lewscanon.com> - 2011-05-05 17:10 -0400
            Re: char to decimal Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2011-05-05 22:00 +0000
              Re: char to decimal Lew <noone@lewscanon.com> - 2011-05-05 18:20 -0400
            Re: char to decimal Dirk Bruere at NeoPax <dirk.bruere@gmail.com> - 2011-05-06 10:45 +0100
              Re: char to decimal Lew <noone@lewscanon.com> - 2011-05-06 06:56 -0400
                Re: char to decimal Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2011-05-06 11:48 +0000
                  Re: char to decimal Joshua Cranmer <Pidgeot18@verizon.invalid> - 2011-05-06 08:38 -0400
                  Re: char to decimal Michael Wojcik <mwojcik@newsguy.com> - 2011-05-06 09:47 -0400
                    Re: char to decimal Lew <noone@lewscanon.com> - 2011-05-06 12:02 -0400
                    Re: char to decimal Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2011-05-06 19:15 +0200
                      Re: char to decimal Lew <noone@lewscanon.com> - 2011-05-06 14:01 -0400
                        Re: char to decimal Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2011-05-06 20:07 +0200
                          Re: O/T linguistics (Was: char to decimal) Lew <noone@lewscanon.com> - 2011-05-06 15:28 -0400
                            Re: O/T linguistics Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2011-05-06 21:44 +0200
                          Re: char to decimal Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2011-05-06 23:57 +0000
                  Re: char to decimal Lew <noone@lewscanon.com> - 2011-05-06 12:00 -0400
                Re: char to decimal Dirk Bruere at NeoPax <dirk.bruere@gmail.com> - 2011-05-06 18:29 +0100
                  Re: char to decimal Lew <noone@lewscanon.com> - 2011-05-06 14:02 -0400
                    Re: char to decimal Dirk Bruere at NeoPax <dirk.bruere@gmail.com> - 2011-05-07 01:09 +0100
                    Re: char to decimal Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2011-05-07 00:18 +0000
                      Re: char to decimal Lew <noone@lewscanon.com> - 2011-05-06 21:30 -0400
    Re: char to decimal Roedy Green <see_website@mindprod.com.invalid> - 2011-05-04 22:03 -0700
      Re: char to decimal "Nasser M. Abbasi" <nma@12000.org> - 2011-05-05 01:14 -0700
      Re: char to decimal Dirk Bruere at NeoPax <dirk.bruere@gmail.com> - 2011-05-05 16:15 +0100

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

#3594

On 05/05/2011 09:59 AM, Lawrence D'Oliveiro wrote:
> In message<9pednRnBeuxtPF_QnZ2dnUVZ_uGdnZ2d@earthlink.com>, Patricia
> Shanahan wrote:
>
>> There is a strong natural association between a character and the numeric
>> value of its Unicode representation. There are several different ways of
>> mapping between the two Boolean values and integers ...
>
> Only one “strong natural association”, though.

Which you, naturally, keep to yourself?

-- 
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg

[toc] | [prev] | [next] | [standalone]

#3561

Patricia Shanahan <pats@acm.org> wrote:
> On 5/5/2011 4:18 AM, Andreas Leitgeb wrote:
>> Lew<noone@lewscanon.com>  wrote:
>>> Lawrence D'Oliveiro wrote:
>>>> Ian Shef wrote:
>>>>> A char is much like an int except that:
>>>>> It has 16 bits instead of 32.
>>>>> It is unsigned, with a value from 0 through 65535.
>>>>> It gets special handling in some places, such as by System.out.println.
>>>>> The special handling by System.out.println can be avoided by casting to an
>>>>> int.
>>>> Funny, they could do all this for char, but not for boolean.
>>> Booleans are not numbers.
>> But characters are.  So, 'a' is just as naturally 97 as true isn't 1
> I would phrase it slightly differently. There is a strong natural
> association between a character and the numeric value of its Unicode
> representation.

Well, just as "natural", as Unicode itself is.
I've yet to see Unicode appear in nature, though. ;-)

> There are several different ways of mapping between the
> two Boolean values and integers,

One of which Java happens to have chosen already,
just for "internal use only."

The mapping from numbers to booleans is, of course, not injective.
The mapping of numbers (even 16 bit) to characters according to the
Unicode-table isn't even *defined* for certain numbers.
(e.g. 0xfffe, iirc)

[toc] | [prev] | [next] | [standalone]

#3577

On May 5, 3:56 pm, Andreas Leitgeb <a...@gamma.logic.tuwien.ac.at>
wrote:
> Patricia Shanahan <p...@acm.org> wrote:
...
> > There are several different ways of mapping between the
> > two Boolean values and integers,
>
> One of which Java happens to have chosen already,
> just for "internal use only."

Two values are defined for "public use" - 1231 and 1237
(java.lang.Boolean's hashcode()). I think they should take precedence
over any "internal use only" values.

:)

[toc] | [prev] | [next] | [standalone]

#3595

On 05/05/2011 02:48 PM, Paul Cager wrote:
> On May 5, 3:56 pm, Andreas Leitgeb<a...@gamma.logic.tuwien.ac.at>
> wrote:
>> Patricia Shanahan<p...@acm.org>  wrote:
> ...
>>> There are several different ways of mapping between the
>>> two Boolean values and integers,
>>
>> One of which Java happens to have chosen already,
>> just for "internal use only."
>
> Two values are defined for "public use" - 1231 and 1237
> (java.lang.Boolean's hashcode()). I think they should take precedence
> over any "internal use only" values.
>
> :)

Those are, of course, the natural numeric representations for booleans in 
Java, whatever Larry-baby thinks.

-- 
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg

[toc] | [prev] | [next] | [standalone]

#3603

Paul Cager <paul.cager@googlemail.com> wrote:
> On May 5, 3:56 pm, Andreas Leitgeb <a...@gamma.logic.tuwien.ac.at>
> wrote:
>> Patricia Shanahan <p...@acm.org> wrote:
>>> There are several different ways of mapping between the
>>> two Boolean values and integers,
>> One of which Java happens to have chosen already,
>> just for "internal use only."
> Two values are defined for "public use" - 1231 and 1237

A good one :-)
And while we're at it, we'll revolutionize maths by coming up
with a new field theory whose two operations have 1231 and 1237
as their respective neutral elements...

> (java.lang.Boolean's hashcode()). I think they should take
> precedence over any "internal use only" values.

Yep, these or even better 64 and 43 for true and false, just 
heaven forbid 1 and 0 - that's so ... boring simple, innit?

[toc] | [prev] | [next] | [standalone]

#3604

On 05/05/2011 05:28 PM, Andreas Leitgeb wrote:
> Paul Cager<paul.cager@googlemail.com>  wrote:
>> On May 5, 3:56 pm, Andreas Leitgeb<a...@gamma.logic.tuwien.ac.at>
>> wrote:
>>> Patricia Shanahan<p...@acm.org>  wrote:
>>>> There are several different ways of mapping between the
>>>> two Boolean values and integers,
>>> One of which Java happens to have chosen already,
>>> just for "internal use only."
>> Two values are defined for "public use" - 1231 and 1237
>
> A good one :-)
> And while we're at it, we'll revolutionize maths by coming up
> with a new field theory whose two operations have 1231 and 1237
> as their respective neutral elements...
>
>> (java.lang.Boolean's hashcode()). I think they should take
>> precedence over any "internal use only" values.
>
> Yep, these or even better 64 and 43 for true and false, just
> heaven forbid 1 and 0 - that's so ... boring simple, innit?

I do believe that as long as I'm using Java booleans, I'll stick with the 
values 'true' and 'false'.  That seems like the natural mapping to me.

Just saying.

-- 
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg

[toc] | [prev] | [next] | [standalone]

#3649

Lew <noone@lewscanon.com> wrote:
> On 05/05/2011 05:28 PM, Andreas Leitgeb wrote:
>> Yep, these or even better 64 and 43 for true and false, just
>> heaven forbid 1 and 0 - that's so ... boring simple, innit?
> I do believe that as long as I'm using Java booleans, I'll stick with the 
> values 'true' and 'false'.  That seems like the natural mapping to me.

Oh, that must all be a big misunderstanding. I honestly never wanted
to elide these two keywords.  They would make excellent self-speaking 
integer-literals for particular uses. :-)

[toc] | [prev] | [next] | [standalone]

#3593

On 05/05/2011 07:18 AM, Andreas Leitgeb wrote:
> Lew<noone@lewscanon.com>  wrote:
>> Lawrence D'Oliveiro wrote:
>>> Ian Shef wrote:
>>>> A char is much like an int except that:
>>>> It has 16 bits instead of 32.
>>>> It is unsigned, with a value from 0 through 65535.
>>>> It gets special handling in some places, such as by System.out.println.
>>>> The special handling by System.out.println can be avoided by casting to an
>>>> int.
>>> Funny, they could do all this for char, but not for boolean.
>> Booleans are not numbers.
>
> But characters are.  So, 'a' is just as naturally 97 as true isn't 1

I am not defending that decision, but the one not to make booleans numeric.

-- 
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg

[toc] | [prev] | [next] | [standalone]

#3678 — boolean to int : was char to decimal

On 05/05/2011 04:03 AM, Lawrence D'Oliveiro wrote:
> In message<Xns9EDBB8224D5B6vaj4088ianshef@138.125.254.103>, Ian Shef wrote:
>
> Funny, they could do all this for char, but not for boolean.

Recently I was translating a piece of C++ code to Java.
I'm wondering how others might make this translation.
Thanks, JSH.

double d2;
double d3;
double e;

C++ test:
int test = (int(d2 > e) << 1) +  int(d3 > e);

Java test:
int t = d2 > e ? 1<<1 : 0;
int test = d3 > e ? t+1 : t;

switch(test)
{  case(0):
    case(1):
    case(2):
    case(3):
}

[toc] | [prev] | [next] | [standalone]

#3683 — Re: boolean to int : was char to decimal

On 5/6/2011 6:00 AM, Jeff Higgins wrote:
> On 05/05/2011 04:03 AM, Lawrence D'Oliveiro wrote:
>> In message<Xns9EDBB8224D5B6vaj4088ianshef@138.125.254.103>, Ian Shef
>> wrote:
>>
>> Funny, they could do all this for char, but not for boolean.
>
> Recently I was translating a piece of C++ code to Java.
> I'm wondering how others might make this translation.
> Thanks, JSH.
>
> double d2;
> double d3;
> double e;
>
> C++ test:
> int test = (int(d2 > e) << 1) + int(d3 > e);
>
> Java test:
> int t = d2 > e ? 1<<1 : 0;
> int test = d3 > e ? t+1 : t;
>
> switch(test)
> { case(0):
> case(1):
> case(2):
> case(3):
> }
>
>

if(d2 > e) {
   if(d3 > e) {
      // case 3 code
   } else {
      // case 2 code
   }
} else {
   if(d3 > e) {
      // case 1 code
   } else {
      // case 0 code
   }
}

I have not tested this, so there may be errors, but I hope the concept
is clear. If there is flow-through between the cases I would first
extract each piece of common code into a method.

Patricia

[toc] | [prev] | [next] | [standalone]

#3686 — Re: boolean to int : was char to decimal

On 5/6/2011 6:00 AM, Jeff Higgins wrote:
> C++ test:
> int test = (int(d2 > e) << 1) + int(d3 > e);
>
> Java test:
> int t = d2 > e ? 1<<1 : 0;
                    ^^^^

Well, this is a 2.  The Java coding conventions say to declare this as a 
constant, I'm not sure that is valuable here though


> int test = d3 > e ? t+1 : t;

   t += d3 > e ? 1 : 0;

The whole thing could be done in one go, of course:

   int test = ((d2 > e) ? 2 : 0) + ((d3 > e) ? 1 : 0);


>
> switch(test)
> { case(0):
> case(1):
> case(2):
> case(3):
> }

Blech.  So the whole point here seems to be to set the 1 bit if d2 > e, 
and set the 0 bit if d2 > e.  Why not just do that?

if( d2 > e ) {
   if( d3 > e ) {
     // case 0
   }  else {
     // case 1
   }
} else {
   if( d3 > e ) {
     // case 2
   }  else {
     // case 3
   }
}

I don't think there's more tests for the CPU in this case.  In fact the 
jump to implement the switch might be more expensive that just a simple 
branch test.  I'd have to know what is motivating the use of switch 
instead of if-else.

Overall, I feel the last one, the if-else in Java, is the most clear and 
maintainable.  Given your apparent confusing trying to translate the C++ 
version literally, I think I'd say that promoting booleans to ints is a 
bad idea, as it produces crap.

[toc] | [prev] | [next] | [standalone]

#3690 — Re: boolean to int : was char to decimal

On 5/6/2011 7:07 AM, markspace wrote:

> Overall, I feel the last one, the if-else in Java, is the most clear and
> maintainable. Given your apparent confusing trying to translate the C++
> version literally, I think I'd say that promoting booleans to ints is a
> bad idea, as it produces crap.


And my confusion too, since I think Patricia has the control flow correct.

[toc] | [prev] | [next] | [standalone]

#3688 — Re: boolean to int : was char to decimal

On 06/05/11 14:00, Jeff Higgins wrote:
> On 05/05/2011 04:03 AM, Lawrence D'Oliveiro wrote:
>> In message<Xns9EDBB8224D5B6vaj4088ianshef@138.125.254.103>, Ian Shef
>> wrote:
>>
>> Funny, they could do all this for char, but not for boolean.
> 
> Recently I was translating a piece of C++ code to Java.
> I'm wondering how others might make this translation.
> Thanks, JSH.
> 
> double d2;
> double d3;
> double e;
> 
> C++ test:
> int test = (int(d2 > e) << 1) +  int(d3 > e);
> 
> Java test:
> int t = d2 > e ? 1<<1 : 0;
> int test = d3 > e ? t+1 : t;
> 


If you intend to keep the obfuscation to a maximum, with shorthand
one-liners, then:

 int test = ((d2>e)?2:0) | ((d3>e)?1:0);

Of course, the idiosyncrasies of C/C++ do permit a higher degree of
obfuscation for the intent of the code.

-- 
Nigel Wade

[toc] | [prev] | [next] | [standalone]

#3701 — Re: boolean to int : was char to decimal

On 06/05/2011 15:00, Jeff Higgins allegedly wrote:
> Recently I was translating a piece of C++ code to Java.
> I'm wondering how others might make this translation.
> Thanks, JSH.
>
> double d2;
> double d3;
> double e;
>
> C++ test:
> int test = (int(d2 > e) << 1) + int(d3 > e);

Java test:

int gt( int t1, int i2 ) { return i1 > i2 ? 1 : 0 }

void test() {
   int test = (gt(d2, e) << 1) + gt(d3, e);
}

-- 
DF.
An escaped convict once said to me:
"Alcatraz is the place to be"

[toc] | [prev] | [next] | [standalone]

#3703 — Re: boolean to int : was char to decimal

On 05/06/2011 09:00 AM, Jeff Higgins wrote:
> On 05/05/2011 04:03 AM, Lawrence D'Oliveiro wrote:
>> In message<Xns9EDBB8224D5B6vaj4088ianshef@138.125.254.103>, Ian Shef
>> wrote:
>>
>> Funny, they could do all this for char, but not for boolean.
>
> Recently I was translating a piece of C++ code to Java.
> I'm wondering how others might make this translation.
> Thanks, JSH.
>
> double d2;
> double d3;
> double e;
>
> C++ test:
> int test = (int(d2 > e) << 1) + int(d3 > e);
>
> Java test:
> int t = d2 > e ? 1<<1 : 0;
> int test = d3 > e ? t+1 : t;
>
> switch(test)
> { case(0):
> case(1):
> case(2):
> case(3):
> }
>
>
Thanks for the responses.
Yes, the nested if/else seems more clear in the above short example.
Now I wonder about the original author's motivation for
the use of switch statement. Code clarity, optimization, idiomatics?
Somehow the code seems easier for me to read with the use of the
switch simply because of the length of the intervening code.

void curve4_div::recursive_bezier(double x1, double y1, double x2, 
double y2, double x3, double y3, double x4, double y4, unsigned level) {

   if (level > curve_recursion_limit) {
     return;
   }

   // Calculate all the mid-points of the line segments
   //----------------------
   double x12 = (x1 + x2) / 2;
   double y12 = (y1 + y2) / 2;
   double x23 = (x2 + x3) / 2;
   double y23 = (y2 + y3) / 2;
   double x34 = (x3 + x4) / 2;
   double y34 = (y3 + y4) / 2;
   double x123 = (x12 + x23) / 2;
   double y123 = (y12 + y23) / 2;
   double x234 = (x23 + x34) / 2;
   double y234 = (y23 + y34) / 2;
   double x1234 = (x123 + x234) / 2;
   double y1234 = (y123 + y234) / 2;

   // Try to approximate the full cubic curve by a single straight line
   //------------------
   double dx = x4 - x1;
   double dy = y4 - y1;

   double d2 = fabs(((x2 - x4) * dy - (y2 - y4) * dx));
   double d3 = fabs(((x3 - x4) * dy - (y3 - y4) * dx));
   double da1, da2, k;

   switch ((int(d2 > curve_collinearity_epsilon) << 1) +
            int(d3 > curve_collinearity_epsilon)) {
   case 0:
     // All collinear OR p1==p4
     //----------------------
     k = dx * dx + dy * dy;
     if (k == 0) {
       d2 = calc_sq_distance(x1, y1, x2, y2);
       d3 = calc_sq_distance(x4, y4, x3, y3);
     } else {
       k = 1 / k;
       da1 = x2 - x1;
       da2 = y2 - y1;
       d2 = k * (da1 * dx + da2 * dy);
       da1 = x3 - x1;
       da2 = y3 - y1;
       d3 = k * (da1 * dx + da2 * dy);
       if (d2 > 0 && d2 < 1 && d3 > 0 && d3 < 1) {
         // Simple collinear case, 1---2---3---4
         // We can leave just two endpoints
         return;
       }
       if (d2 <= 0)
         d2 = calc_sq_distance(x2, y2, x1, y1);
       else if (d2 >= 1)
         d2 = calc_sq_distance(x2, y2, x4, y4);
       else
         d2 = calc_sq_distance(x2, y2, x1 + d2 * dx, y1 + d2 * dy);

       if (d3 <= 0)
         d3 = calc_sq_distance(x3, y3, x1, y1);
       else if (d3 >= 1)
         d3 = calc_sq_distance(x3, y3, x4, y4);
       else
         d3 = calc_sq_distance(x3, y3, x1 + d3 * dx, y1 + d3 * dy);
     }
     if (d2 > d3) {
       if (d2 < m_distance_tolerance_square) {
         m_points.add(point_d(x2, y2));
         return;
       }
     } else {
       if (d3 < m_distance_tolerance_square) {
         m_points.add(point_d(x3, y3));
         return;
       }
     }
     break;

   case 1:
     // p1,p2,p4 are collinear, p3 is significant
     //----------------------
     if (d3 * d3 <= m_distance_tolerance_square * (dx * dx + dy * dy)) {
       if (m_angle_tolerance < curve_angle_tolerance_epsilon) {
         m_points.add(point_d(x23, y23));
         return;
       }

       // Angle Condition
       //----------------------
       da1 = fabs(atan2(y4 - y3, x4 - x3) - atan2(y3 - y2, x3 - x2));
       if (da1 >= pi)
         da1 = 2 * pi - da1;

       if (da1 < m_angle_tolerance) {
         m_points.add(point_d(x2, y2));
         m_points.add(point_d(x3, y3));
         return;
       }

       if (m_cusp_limit != 0.0) {
         if (da1 > m_cusp_limit) {
           m_points.add(point_d(x3, y3));
           return;
         }
       }
     }
     break;

   case 2:
     // p1,p3,p4 are collinear, p2 is significant
     //----------------------
     if (d2 * d2 <= m_distance_tolerance_square * (dx * dx + dy * dy)) {
       if (m_angle_tolerance < curve_angle_tolerance_epsilon) {
         m_points.add(point_d(x23, y23));
         return;
       }

       // Angle Condition
       //----------------------
       da1 = fabs(atan2(y3 - y2, x3 - x2) - atan2(y2 - y1, x2 - x1));
       if (da1 >= pi)
         da1 = 2 * pi - da1;

       if (da1 < m_angle_tolerance) {
         m_points.add(point_d(x2, y2));
         m_points.add(point_d(x3, y3));
         return;
       }

       if (m_cusp_limit != 0.0) {
         if (da1 > m_cusp_limit) {
           m_points.add(point_d(x2, y2));
           return;
         }
       }
     }
     break;

   case 3:
     // Regular case
     //-----------------
     if ((d2 + d3) * (d2 + d3) <= m_distance_tolerance_square * (dx * dx
         + dy * dy)) {
       // If the curvature doesn't exceed the distance_tolerance value
       // we tend to finish subdivisions.
       //----------------------
       if (m_angle_tolerance < curve_angle_tolerance_epsilon) {
         m_points.add(point_d(x23, y23));
         return;
       }

       // Angle & Cusp Condition
       //----------------------
       k = atan2(y3 - y2, x3 - x2);
       da1 = fabs(k - atan2(y2 - y1, x2 - x1));
       da2 = fabs(atan2(y4 - y3, x4 - x3) - k);
       if (da1 >= pi)
         da1 = 2 * pi - da1;
       if (da2 >= pi)
         da2 = 2 * pi - da2;

       if (da1 + da2 < m_angle_tolerance) {
         // Finally we can stop the recursion
         //----------------------
         m_points.add(point_d(x23, y23));
         return;
       }

       if (m_cusp_limit != 0.0) {
         if (da1 > m_cusp_limit) {
           m_points.add(point_d(x2, y2));
           return;
         }

         if (da2 > m_cusp_limit) {
           m_points.add(point_d(x3, y3));
           return;
         }
       }
     }
     break;
   }

   // Continue subdivision
   //----------------------
   recursive_bezier(x1, y1, x12, y12, x123, y123, x1234, y1234, level + 1);
   recursive_bezier(x1234, y1234, x234, y234, x34, y34, x4, y4, level + 1);
}

[toc] | [prev] | [next] | [standalone]

#3732 — Re: boolean to int : was char to decimal

On 05/06/2011 01:26 PM, Jeff Higgins wrote:

>
> void curve4_div::recursive_bezier

Oops, attribution; sorry.
<http://www.antigrain.com/__code/src/agg_curves.cpp.html>

[toc] | [prev] | [next] | [standalone]

#3733 — Re: boolean to int : was char to decimal

On 05/06/2011 01:26 PM, Jeff Higgins wrote:

> void curve4_div::recursive_bezier

Oops, attribution; sorry
<http://www.antigrain.com/__code/src/agg_curves.cpp.html>

[toc] | [prev] | [next] | [standalone]

#3867 — Re: boolean to int : was char to decimal

Jeff Higgins wrote:
> Yes, the nested if/else seems more clear in the above short example.

And that shows why context is often important in a question of coding
style. Your short example contained nothing that could justify the odd
use of the switch statement. (And your Java version made even less
sense, since it lost the C++ boolean-int conversions and symmetry.)

> Now I wonder about the original author's motivation for
> the use of switch statement. Code clarity, optimization, idiomatics?

It looks to me like the C++ code may have been based on a C
implementation of the algorithm, which would have been a bit simpler,
since the int casts would have been unnecessary:

   switch (((d2 > curve_collinearity_epsilon) << 1) +
            (d3 > curve_collinearity_epsilon)) {

I would have preferred binary-or there rather than addition, for
clarity, but either works.

And that, in turn, may have come from a description of the algorithm
that treated the two tests for inner-point collinearity as a pair of
bits (which is what this code is doing). Or it may have originally
been implemented on a processor where {test, test, shift, add,
computed-goto} was a faster sequence than {test, branch, test,
branch}. Bezier-curve rendering is a plausible target for optimization.

Or it may just be idiosyncrasy, particularly since this is a directly
recursive implementation, which seems likely to dwarf any savings from
fooling with the collinearity tests.

It's unlikely a Java implementation will benefit detectably from
anything other than the straightforward cascading-if-else design.
Certainly that would be the one to start with, and only investigate
alternatives if performance is a problem and profiling indicates this
is a useful target for optimization.

-- 
Michael Wojcik
Micro Focus
Rhetoric & Writing, Michigan State University

[toc] | [prev] | [next] | [standalone]

#3882 — Re: boolean to int : was char to decimal

Michael Wojcik <mwojcik@newsguy.com> wrote:
> It's unlikely a Java implementation will benefit detectably from
> anything other than the straightforward cascading-if-else design.
> Certainly that would be the one to start with, and only investigate
> alternatives if performance is a problem and profiling indicates this
> is a useful target for optimization.

The more those poor-man's bitsets have to be passed around or stored
"en masse", rather than just being assembled and used (as in the switch
example), the more it will pay.

[toc] | [prev] | [next] | [standalone]

#3883 — Re: boolean to int : was char to decimal

On 05/09/2011 12:51 PM, Michael Wojcik wrote:
> Jeff Higgins wrote:
>> Yes, the nested if/else seems more clear in the above short example.
>
> And that shows why context is often important in a question of coding
> style. Your short example contained nothing that could justify the odd
> use of the switch statement. (And your Java version made even less
> sense, since it lost the C++ boolean-int conversions and symmetry.)

Yes, a hasty post.

>> Now I wonder about the original author's motivation for
>> the use of switch statement. Code clarity, optimization, idiomatics?
>
> It looks to me like the C++ code may have been based on a C
> implementation of the algorithm, which would have been a bit simpler,
> since the int casts would have been unnecessary:
>
>     switch (((d2>  curve_collinearity_epsilon)<<  1) +
>              (d3>  curve_collinearity_epsilon)) {
>
> I would have preferred binary-or there rather than addition, for
> clarity, but either works.

Yes. I believe that if I had spent even a few more moments studying
I would have come up with markspace's one line solution.
Nigel Wade's one liner would have likely escaped me. Very nice.
Thanks to both.

> And that, in turn, may have come from a description of the algorithm
> that treated the two tests for inner-point collinearity as a pair of
> bits (which is what this code is doing). Or it may have originally
> been implemented on a processor where {test, test, shift, add,
> computed-goto} was a faster sequence than {test, branch, test,
> branch}. Bezier-curve rendering is a plausible target for optimization.
>
> Or it may just be idiosyncrasy, particularly since this is a directly
> recursive implementation, which seems likely to dwarf any savings from
> fooling with the collinearity tests.
>
> It's unlikely a Java implementation will benefit detectably from
> anything other than the straightforward cascading-if-else design.
> Certainly that would be the one to start with, and only investigate
> alternatives if performance is a problem and profiling indicates this
> is a useful target for optimization.

My translation of Maxim Shemanarev's code seems to run without a hitch
in an interactive Swing panel.

Roedy Green sparked my interest in this subject in a recent cljh post.
My original question was: Will the AGG algo produce a 'nicer' curve
than Java's FlatteningPathIterator? The answer so far is yes and no.

My interest has now expanded. Starting here, I've a ways to go.
<http://www3.villanova.edu/maple/misc/history_of_curvature/index.htm>

Thanks for the discussion, much appreciated.

[toc] | [prev] | [next] | [standalone]

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

Back to top | Article view | comp.lang.java.programmer

csiph-web