kinomatic

Hi. I am having some problems with jit.gencoord. It seems that the 

scaling factor of 1. in float32 the output will approach 1.0 (how 

close depending on the dim you set) but never quite get there. to get 

to 1.0 you have to find the magic number above 1. (case of 50 use 

scaling 1.020408). Is this what is to be expected of jit.gencoord?

attached is the patch which demonstrates the behavior.

Hi. I am having some problems with jit.gencoord. It seems that the  
scaling factor of 1. in float32 the output will approach 1.0 (how  
close depending on the dim you set) but never quite get there. to get  
to 1.0 you have to find the magic number above 1. (case of 50 use  
scaling 1.020408). Is this what is to be expected of jit.gencoord?

jit-gencoord-scaling-factor

On Oct 11, 2007, at 7:58 PM, (())_n wrote:

> Hi. I am having some problems with jit.gencoord. It seems that the 

> scaling factor of 1. in float32 the output will approach 1.0 (how 

> close depending on the dim you set) but never quite get there. to 

> get to 1.0 you have to find the magic number above 1. (case of 50 

> use scaling 1.020408). Is this what is to be expected of jit.gencoord?

Thanks for the report. We can fix in a future release to behave as 

you expect, but for the time being you can use jit.expr @expr norm[0] 

> Hi. I am having some problems with jit.gencoord. It seems that the  
> scaling factor of 1. in float32 the output will approach 1.0 (how  
> close depending on the dim you set) but never quite get there. to  
> get to 1.0 you have to find the magic number above 1. (case of 50  
> use scaling 1.020408). Is this what is to be expected of jit.gencoord?

Thanks for the report. We can fix in a future release to behave as  
you expect, but for the time being you can use jit.expr @expr norm[0]  
norm[0]

On Oct 11, 2007, at 8:55 PM, Joshua Kit Clayton wrote:

> We can fix in a future release to behave as you expect, but for the 

> time being you can use jit.expr @expr norm[0] norm[0]

Sorry for the typo. Above should read jit.expr @expr norm[0] norm[1]

> We can fix in a future release to behave as you expect, but for the  
> time being you can use jit.expr @expr norm[0] norm[0]

On Oct 12, 2007, at 12:24 AM, Joshua Kit Clayton wrote:

>> We can fix in a future release to behave as you expect, but for 

>> the time being you can use jit.expr @expr norm[0] norm[0]

> Sorry for the typo. Above should read jit.expr @expr norm[0] norm[1]

Got it. Thanks. This is the technique I was using b4. Josh Goldberg 

pointed out jit.gencoord which might be simpler, but then I was 

always missing some data at the end. Good to know jit.gencoord will 

>
>> We can fix in a future release to behave as you expect, but for  
>> the time being you can use jit.expr @expr norm[0] norm[0]
>
> Sorry for the typo. Above should read jit.expr @expr norm[0] norm[1]
>
> -Joshua

Got it. Thanks. This is the technique I was using b4. Josh Goldberg  
pointed out jit.gencoord which might be simpler, but then I was  
always missing some data at the end. Good to know jit.gencoord will  
work as expected in the future.

On Oct 12, 2007, at 5:43 AM, (())_n wrote:

> On Oct 12, 2007, at 12:24 AM, Joshua Kit Clayton wrote:

>>> We can fix in a future release to behave as you expect, but for 

>>> the time being you can use jit.expr @expr norm[0] norm[0]

>> Sorry for the typo. Above should read jit.expr @expr norm[0] norm[1]

> Got it. Thanks. This is the technique I was using b4. Josh Goldberg 

> pointed out jit.gencoord which might be simpler, but then I was 

> always missing some data at the end. Good to know jit.gencoord will 

aha!!
this has been bugging me for awhile.
of course, i thought it was my fault...

>
> On Oct 12, 2007, at 12:24 AM, Joshua Kit Clayton wrote:
>
>>
>>> We can fix in a future release to behave as you expect, but for  
>>> the time being you can use jit.expr @expr norm[0] norm[0]
>>
>> Sorry for the typo. Above should read jit.expr @expr norm[0] norm[1]
>>
>> -Joshua
>
> Got it. Thanks. This is the technique I was using b4. Josh Goldberg  
> pointed out jit.gencoord which might be simpler, but then I was  
> always missing some data at the end. Good to know jit.gencoord will  
> work as expected in the future.
>
> cheers,
>
> (())_n


jit.gencoord scaling factor