Unintuitive comparison between long and BigInteger

classic Classic list List threaded Threaded
24 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Unintuitive comparison between long and BigInteger

Johan Van Noten

Dear Jython users,

 

I use Jython to provide script support in a Java (Eclipse RCP) based application through JSR-223.

The following PyLong and BigInteger behavior remains very intuitive:

# 10L > 100

false (as it should be)

# a = 10L

# a > 100

true (hmmm…. suddenly 10L > 100)

 

I understand that this is linked to the underlying representation based on java.math.BigInteger and the fact that they are not automatically coerced to longs (reported already back in 2002).

 

Unfortunately, my users and I remain confused about it.

Are there any solutions to avoid this confusing behavior?

Am I overlooking something?

 

(Using Jython 2.7b2)

 

Thanks,

Johan


------------------------------------------------------------------------------
Infragistics Professional
Build stunning WinForms apps today!
Reboot your WinForms applications with our WinForms controls.
Build a bridge from your legacy apps to the future.
http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk
_______________________________________________
Jython-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jython-users
Reply | Threaded
Open this post in threaded view
|

Re: Unintuitive comparison between long and BigInteger

Dan Stromberg-2
On Thu, Jul 31, 2014 at 2:15 PM, Johan Van Noten <[hidden email]> wrote:

> Dear Jython users,
>
> I use Jython to provide script support in a Java (Eclipse RCP) based
> application through JSR-223.
>
> The following PyLong and BigInteger behavior remains very intuitive:
>
> # 10L > 100
>
> false (as it should be)
>
> # a = 10L
>
> # a > 100
>
> true (hmmm…. suddenly 10L > 100)
>
>
>
> I understand that this is linked to the underlying representation based on
> java.math.BigInteger and the fact that they are not automatically coerced to
> longs (reported already back in 2002).
>
>
>
> Unfortunately, my users and I remain confused about it.
>
> Are there any solutions to avoid this confusing behavior?
>
> Am I overlooking something?
>
>
>
> (Using Jython 2.7b2)

I get False from Jython 2.7b2, Pypy 2.3.1 and CPython 2[4567].

What are the #'s in your example snippet?  They look like a *ix root
prompt rather than a Python prompt.

HTH

Supporting detail:
$ pythons 'a=10L; print(a>100)'
/usr/local/cpython-2.4/bin/python False
/usr/local/cpython-2.5/bin/python False
/usr/local/cpython-2.6/bin/python False
/usr/local/cpython-2.7/bin/python False
/usr/local/cpython-3.0/bin/python
     File "<string>", line 1
       a=10L; print(a>100)
           ^
   SyntaxError: invalid syntax
/usr/local/cpython-3.1/bin/python
     File "<string>", line 1
       a=10L; print(a>100)
           ^
   SyntaxError: invalid syntax
/usr/local/cpython-3.2/bin/python
     File "<string>", line 1
       a=10L; print(a>100)
           ^
   SyntaxError: invalid syntax
/usr/local/cpython-3.3/bin/python
     File "<string>", line 1
       a=10L; print(a>100)
           ^
   SyntaxError: invalid syntax
/usr/local/cpython-3.4/bin/python
     File "<string>", line 1
       a=10L; print(a>100)
           ^
   SyntaxError: invalid syntax
/usr/local/pypy-2.3.1/bin/pypy False
/usr/local/pypy3-2.3.1/bin/pypy
     File "<string>", line 1
       a=10L; print(a>100)
          ^
   SyntaxError: invalid syntax
/usr/local/jython-2.7b2/bin/jython False

------------------------------------------------------------------------------
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
_______________________________________________
Jython-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jython-users
Reply | Threaded
Open this post in threaded view
|

Re: Unintuitive comparison between long and BigInteger

Jeff Allen-2
In reply to this post by Johan Van Noten
On 31/07/2014 22:15, Johan Van Noten wrote:

>
> Dear Jython users,
>
> I use Jython to provide script support in a Java (Eclipse RCP) based
> application through JSR-223.
>
> The following PyLong and BigInteger behavior remains very intuitive:
>
> # 10L > 100
>
> false (as it should be)
>
> # a = 10L
>
> # a > 100
>
> true (hmmm…. suddenly 10L > 100)
>

This isn't what I see when I use the Jython prompt. I see:

Jython 2.7b2+ (v2.7b2:4105892103e8, Aug 1 2014, 08:39:33)
[Java HotSpot(TM) 64-Bit Server VM (Oracle Corporation)] on java1.7.0_60
Type "help", "copyright", "credits" or "license" for more information.
 >>> 10L > 100
False
 >>> a = 10L
 >>> a > 100
False

> I understand that this is linked to the underlying representation
> based on java.math.BigInteger and the fact that they are not
> automatically coerced to longs (reported already back in 2002).
>

But you're not using the REPL here, I infer from the odd prompt and the
non-standard presentation of boolean values. Does your scripting tool
perhaps go directly to a java.math.BigInteger, instead of a Python long?
I get, for example:
 >>> import java.math
 >>> b = java.math.BigInteger("10")
 >>> b == 10L
False
 >>> b < 100
False
 >>>

The behaviour reflects the fact that, to Jython, java.math.BigInteger is
just a "user" class, not a number. You can't do arithmetic with it, and
it has no order defined for Jython to use, so the comparison proceeds as
the language reference specifies here:
https://docs.python.org/2.7/reference/expressions.html#not-in

Python 3 calls for a TypeError in my example, which will be more helpful
(when there is a Jython 3).

Jeff Allen



------------------------------------------------------------------------------
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
_______________________________________________
Jython-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jython-users
Reply | Threaded
Open this post in threaded view
|

Re: Unintuitive comparison between long and BigInteger

Johan Van Noten
Hi guys,

I tried this on Jython 2.7b1 and Jython 2.7b2 which both had the same behavior in my trials.
So, I guess the issue is not "by design" but rather as a consequence of what I am doing.
I therefore feel I should give some additional background on how I am using this.

(Dan, by the way, the # prompt is *ix-ish, but that's just me typing my example that way. The real app has text boxes for both the expression and the result, so no prompting there...)

The Java-code does something like the following:

SimpleScriptContext scriptContext = new SimpleScriptContext();
Simple bindings = new SimpleBindings();  // In fact coming from elsewhere
scriptContext.setBindings(bindings, SimpleScriptContext.ENGINE_SCOPE);
scriptEngine = scriptEngineManager.getEngineByName("python");
Object resultObject = null;
resultObject = scriptEngine.eval("10L > 100" , scriptContext);
resultObject = scriptEngine.eval("a = 10L" , scriptContext);
resultObject = scriptEngine.eval("a > 100" , scriptContext);
The outputs that I listed, were the outputs in the resultObject given the inputs after the #.

Since these results seem surprising to you, I'm most probably doing something wrong.
Unfortunately, I'm unable to put my finger on my mistake.
Would you have any suggestions?

Thanks,
Johan

> -----Oorspronkelijk bericht-----
> Van: Jeff Allen [mailto:[hidden email]]
> Verzonden: vrijdag 1 augustus 2014 9:56
> Aan: [hidden email]
> Onderwerp: Re: [Jython-users] Unintuitive comparison between long and
> BigInteger
>
> On 31/07/2014 22:15, Johan Van Noten wrote:
> >
> > Dear Jython users,
> >
> > I use Jython to provide script support in a Java (Eclipse RCP) based
> > application through JSR-223.
> >
> > The following PyLong and BigInteger behavior remains very intuitive:
> >
> > # 10L > 100
> >
> > false (as it should be)
> >
> > # a = 10L
> >
> > # a > 100
> >
> > true (hmmm.... suddenly 10L > 100)
> >
>
> This isn't what I see when I use the Jython prompt. I see:
>
> Jython 2.7b2+ (v2.7b2:4105892103e8, Aug 1 2014, 08:39:33) [Java
> HotSpot(TM) 64-Bit Server VM (Oracle Corporation)] on java1.7.0_60 Type
> "help", "copyright", "credits" or "license" for more information.
>  >>> 10L > 100
> False
>  >>> a = 10L
>  >>> a > 100
> False
>
> > I understand that this is linked to the underlying representation
> > based on java.math.BigInteger and the fact that they are not
> > automatically coerced to longs (reported already back in 2002).
> >
>
> But you're not using the REPL here, I infer from the odd prompt and the non-
> standard presentation of boolean values. Does your scripting tool perhaps go
> directly to a java.math.BigInteger, instead of a Python long?
> I get, for example:
>  >>> import java.math
>  >>> b = java.math.BigInteger("10")
>  >>> b == 10L
> False
>  >>> b < 100
> False
>  >>>
>
> The behaviour reflects the fact that, to Jython, java.math.BigInteger is just a
> "user" class, not a number. You can't do arithmetic with it, and it has no order
> defined for Jython to use, so the comparison proceeds as the language
> reference specifies here:
> https://docs.python.org/2.7/reference/expressions.html#not-in
>
> Python 3 calls for a TypeError in my example, which will be more helpful
> (when there is a Jython 3).
>
> Jeff Allen
>
>
>
> ------------------------------------------------------------------------------
> Want fast and easy access to all the code in your enterprise? Index and
> search up to 200,000 lines of code with a free copy of Black Duck Code Sight -
> the same software that powers the world's largest code search on Ohloh, the
> Black Duck Open Hub! Try it now.
> http://p.sf.net/sfu/bds
> _______________________________________________
> Jython-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/jython-users

------------------------------------------------------------------------------
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
_______________________________________________
Jython-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jython-users
Reply | Threaded
Open this post in threaded view
|

Re: Unintuitive comparison between long and BigInteger

Johan Van Noten
And now with "readable" java-code new-lines:

SimpleScriptContext scriptContext = new SimpleScriptContext();
Simple bindings = new SimpleBindings();  // In fact coming from elsewhere
scriptContext.setBindings(bindings, SimpleScriptContext.ENGINE_SCOPE);
scriptEngine = scriptEngineManager.getEngineByName("python");
Object resultObject = null;
resultObject = scriptEngine.eval("10L > 100" , scriptContext);
resultObject = scriptEngine.eval("a = 10L" , scriptContext);
resultObject = scriptEngine.eval("a > 100" , scriptContext);

The outputs that I listed, were the outputs in the resultObject given the inputs after the #.


> -----Oorspronkelijk bericht-----
> Van: Johan Van Noten [mailto:[hidden email]]
> Verzonden: vrijdag 1 augustus 2014 11:28
> Aan: [hidden email]
> Onderwerp: Re: [Jython-users] Unintuitive comparison between long and
> BigInteger
>
> Hi guys,
>
> I tried this on Jython 2.7b1 and Jython 2.7b2 which both had the same
> behavior in my trials.
> So, I guess the issue is not "by design" but rather as a consequence of what I
> am doing.
> I therefore feel I should give some additional background on how I am using
> this.
>
> (Dan, by the way, the # prompt is *ix-ish, but that's just me typing my
> example that way. The real app has text boxes for both the expression and
> the result, so no prompting there...)
>
> The Java-code does something like the following:
>
> SimpleScriptContext scriptContext = new SimpleScriptContext(); Simple
> bindings = new SimpleBindings();  // In fact coming from elsewhere
> scriptContext.setBindings(bindings, SimpleScriptContext.ENGINE_SCOPE);
> scriptEngine = scriptEngineManager.getEngineByName("python");
> Object resultObject = null;
> resultObject = scriptEngine.eval("10L > 100" , scriptContext); resultObject =
> scriptEngine.eval("a = 10L" , scriptContext); resultObject =
> scriptEngine.eval("a > 100" , scriptContext); The outputs that I listed, were
> the outputs in the resultObject given the inputs after the #.
>
> Since these results seem surprising to you, I'm most probably doing
> something wrong.
> Unfortunately, I'm unable to put my finger on my mistake.
> Would you have any suggestions?
>
> Thanks,
> Johan
>
> > -----Oorspronkelijk bericht-----
> > Van: Jeff Allen [mailto:[hidden email]]
> > Verzonden: vrijdag 1 augustus 2014 9:56
> > Aan: [hidden email]
> > Onderwerp: Re: [Jython-users] Unintuitive comparison between long and
> > BigInteger
> >
> > On 31/07/2014 22:15, Johan Van Noten wrote:
> > >
> > > Dear Jython users,
> > >
> > > I use Jython to provide script support in a Java (Eclipse RCP) based
> > > application through JSR-223.
> > >
> > > The following PyLong and BigInteger behavior remains very intuitive:
> > >
> > > # 10L > 100
> > >
> > > false (as it should be)
> > >
> > > # a = 10L
> > >
> > > # a > 100
> > >
> > > true (hmmm.... suddenly 10L > 100)
> > >
> >
> > This isn't what I see when I use the Jython prompt. I see:
> >
> > Jython 2.7b2+ (v2.7b2:4105892103e8, Aug 1 2014, 08:39:33) [Java
> > HotSpot(TM) 64-Bit Server VM (Oracle Corporation)] on java1.7.0_60
> > Type "help", "copyright", "credits" or "license" for more information.
> >  >>> 10L > 100
> > False
> >  >>> a = 10L
> >  >>> a > 100
> > False
> >
> > > I understand that this is linked to the underlying representation
> > > based on java.math.BigInteger and the fact that they are not
> > > automatically coerced to longs (reported already back in 2002).
> > >
> >
> > But you're not using the REPL here, I infer from the odd prompt and
> > the non- standard presentation of boolean values. Does your scripting
> > tool perhaps go directly to a java.math.BigInteger, instead of a Python
> long?
> > I get, for example:
> >  >>> import java.math
> >  >>> b = java.math.BigInteger("10")
> >  >>> b == 10L
> > False
> >  >>> b < 100
> > False
> >  >>>
> >
> > The behaviour reflects the fact that, to Jython, java.math.BigInteger
> > is just a "user" class, not a number. You can't do arithmetic with it,
> > and it has no order defined for Jython to use, so the comparison
> > proceeds as the language reference specifies here:
> > https://docs.python.org/2.7/reference/expressions.html#not-in
> >
> > Python 3 calls for a TypeError in my example, which will be more
> > helpful (when there is a Jython 3).
> >
> > Jeff Allen
> >
> >
> >
> > ----------------------------------------------------------------------
> > -------- Want fast and easy access to all the code in your enterprise?
> > Index and search up to 200,000 lines of code with a free copy of Black
> > Duck Code Sight - the same software that powers the world's largest
> > code search on Ohloh, the Black Duck Open Hub! Try it now.
> > http://p.sf.net/sfu/bds
> > _______________________________________________
> > Jython-users mailing list
> > [hidden email]
> > https://lists.sourceforge.net/lists/listinfo/jython-users
>
> ------------------------------------------------------------------------------
> Want fast and easy access to all the code in your enterprise? Index and
> search up to 200,000 lines of code with a free copy of Black Duck Code Sight -
> the same software that powers the world's largest code search on Ohloh, the
> Black Duck Open Hub! Try it now.
> http://p.sf.net/sfu/bds
> _______________________________________________
> Jython-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/jython-users

------------------------------------------------------------------------------
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
_______________________________________________
Jython-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jython-users
Reply | Threaded
Open this post in threaded view
|

Re: Unintuitive comparison between long and BigInteger

Johan Van Noten
In reply to this post by Jeff Allen-2
Hi Jeff,

This issue keeps bugging me... also in 2.7-b3.
So I decided to make a small Java application to demonstrate the issue.

Some easy steps:
1) Download archive from http://www.qtc.be/TestJython.zip 
2) Extract
3) Run the script TestJython.cmd (just runs a small class with the jython library on the cp)
4) Enter the example data (see below)
5) It is a small Eclipse Kepler project, so if you prefer, you can load/debug/run it from Eclipse.

When I do this, I get:
E:\tmp\Jython\TestJython>TestJython.cmd
TestJython >>> 10L > 100
false
TestJython >>> a = 10L
None
TestJython >>> a > 100
true
TestJython >>> type(a)
class java.math.BigInteger
TestJython >>> exit

So, as I confirmed initially, the underlying layers seem to use the BigInteger class, causing the failure in comparison.
As far as I know, I am not doing anything specific that could cause this.
I just use Jython as a Python Scripting Engine according to JSR-223, which is a convenient way of using it.
(Take a look at the extremely simple src/TestJython.java)

Do you expect this behavior?
Can it be avoided?

Johan

------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
_______________________________________________
Jython-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jython-users
Reply | Threaded
Open this post in threaded view
|

Re: Unintuitive comparison between long and BigInteger

Santoso Wijaya
More succinctly, this:

Jython 2.7b3+ (default:2c45f75a5406, Oct 7 2014, 17:21:51) 
[Java HotSpot(TM) 64-Bit Server VM (Oracle Corporation)] on java1.7.0_67
Type "help", "copyright", "credits" or "license" for more information.
>>> from java.math import BigInteger
>>> a = BigInteger('10')
>>> type(a)
<type 'java.math.BigInteger'>
>>> a > 100
True


~/santoso

On Thu, Oct 9, 2014 at 2:24 AM, Johan Van Noten <[hidden email]> wrote:
Hi Jeff,

This issue keeps bugging me... also in 2.7-b3.
So I decided to make a small Java application to demonstrate the issue.

Some easy steps:
1) Download archive from http://www.qtc.be/TestJython.zip
2) Extract
3) Run the script TestJython.cmd (just runs a small class with the jython library on the cp)
4) Enter the example data (see below)
5) It is a small Eclipse Kepler project, so if you prefer, you can load/debug/run it from Eclipse.

When I do this, I get:
E:\tmp\Jython\TestJython>TestJython.cmd
TestJython >>> 10L > 100
false
TestJython >>> a = 10L
None
TestJython >>> a > 100
true
TestJython >>> type(a)
class java.math.BigInteger
TestJython >>> exit

So, as I confirmed initially, the underlying layers seem to use the BigInteger class, causing the failure in comparison.
As far as I know, I am not doing anything specific that could cause this.
I just use Jython as a Python Scripting Engine according to JSR-223, which is a convenient way of using it.
(Take a look at the extremely simple src/TestJython.java)

Do you expect this behavior?
Can it be avoided?

Johan

------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
_______________________________________________
Jython-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jython-users


------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
_______________________________________________
Jython-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jython-users
Reply | Threaded
Open this post in threaded view
|

Re: Unintuitive comparison between long and BigInteger

Santoso Wijaya
The errant return value comes from this injected method in PyJavaType.java:

(lines 904-921)

    private static abstract class ComparableMethod extends PyBuiltinMethodNarrow {
        protected ComparableMethod(String name, int numArgs) {
            super(name, numArgs);
        }
        @Override
        public PyObject __call__(PyObject arg) {
            Object asjava = arg.__tojava__(Object.class);
            int compare;
            try {
                compare = ((Comparable<Object>)self.getJavaProxy()).compareTo(asjava);
            } catch(ClassCastException classCast) {
                return Py.NotImplemented;
            }
            return getResult(compare) ? Py.True : Py.False;
        }

        protected abstract boolean getResult(int comparison);
    }

Which, when reduced, come to this simplified Java snippet:

import java.math.BigInteger;

public class BigCompare {

    public static void main(String[] args) {
        Object bi = (Object) new BigInteger("10");
        Object i = (Object) new Integer(100);
        System.out.println("" + ((Comparable<Object>)bi).compareTo(i));
    }   
}

$ java BigCompare 
Exception in thread "main" java.lang.ClassCastException: java.lang.Integer cannot be cast to java.math.BigInteger
        at java.math.BigInteger.compareTo(BigInteger.java:99)
        at BigCompare.main(BigCompare.java:8)


~/santoso

On Thu, Oct 9, 2014 at 11:19 AM, Santoso Wijaya <[hidden email]> wrote:
More succinctly, this:

Jython 2.7b3+ (default:2c45f75a5406, Oct 7 2014, 17:21:51) 
[Java HotSpot(TM) 64-Bit Server VM (Oracle Corporation)] on java1.7.0_67
Type "help", "copyright", "credits" or "license" for more information.
>>> from java.math import BigInteger
>>> a = BigInteger('10')
>>> type(a)
<type 'java.math.BigInteger'>
>>> a > 100
True


~/santoso

On Thu, Oct 9, 2014 at 2:24 AM, Johan Van Noten <[hidden email]> wrote:
Hi Jeff,

This issue keeps bugging me... also in 2.7-b3.
So I decided to make a small Java application to demonstrate the issue.

Some easy steps:
1) Download archive from http://www.qtc.be/TestJython.zip
2) Extract
3) Run the script TestJython.cmd (just runs a small class with the jython library on the cp)
4) Enter the example data (see below)
5) It is a small Eclipse Kepler project, so if you prefer, you can load/debug/run it from Eclipse.

When I do this, I get:
E:\tmp\Jython\TestJython>TestJython.cmd
TestJython >>> 10L > 100
false
TestJython >>> a = 10L
None
TestJython >>> a > 100
true
TestJython >>> type(a)
class java.math.BigInteger
TestJython >>> exit

So, as I confirmed initially, the underlying layers seem to use the BigInteger class, causing the failure in comparison.
As far as I know, I am not doing anything specific that could cause this.
I just use Jython as a Python Scripting Engine according to JSR-223, which is a convenient way of using it.
(Take a look at the extremely simple src/TestJython.java)

Do you expect this behavior?
Can it be avoided?

Johan

------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
_______________________________________________
Jython-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jython-users



------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
_______________________________________________
Jython-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jython-users
Reply | Threaded
Open this post in threaded view
|

Re: Unintuitive comparison between long and BigInteger

Curtis Rueden
In reply to this post by Santoso Wijaya
Hi Johan,

I'm new to the list, so apologies if I missed any prior discussion of this issue.

Johan Van Noten wrote:
> TestJython >>> a = 10L
> None
> TestJython >>> a > 100
> true
> TestJython >>> type(a)
> class java.math.BigInteger

Using your test code, I see the described behavior in both 2.5.3 and 2.7-b3.

However, the Fiji project [1] has support for Jython scripting [2], and within that framework (Jython 2.5.3) I do not see the bug. Instead I see:

>>> a = 10L
>>> print(type(a))
<type 'long'>

Santoso Wijaya wrote:
> >>> a = BigInteger('10')
> >>> type(a)
> <type 'java.math.BigInteger'>
> >>> a > 100
> True

Yeah, seems like a BigInteger comparison bug. But to me, the more surprising thing is that writing "a = 10L" in Jython creates a BigInteger rather than a Long...

Regards,
Curtis


On Thu, Oct 9, 2014 at 1:19 PM, Santoso Wijaya <[hidden email]> wrote:
More succinctly, this:

Jython 2.7b3+ (default:2c45f75a5406, Oct 7 2014, 17:21:51) 
[Java HotSpot(TM) 64-Bit Server VM (Oracle Corporation)] on java1.7.0_67
Type "help", "copyright", "credits" or "license" for more information.
>>> from java.math import BigInteger
>>> a = BigInteger('10')
>>> type(a)
<type 'java.math.BigInteger'>
>>> a > 100
True


~/santoso

On Thu, Oct 9, 2014 at 2:24 AM, Johan Van Noten <[hidden email]> wrote:
Hi Jeff,

This issue keeps bugging me... also in 2.7-b3.
So I decided to make a small Java application to demonstrate the issue.

Some easy steps:
1) Download archive from http://www.qtc.be/TestJython.zip
2) Extract
3) Run the script TestJython.cmd (just runs a small class with the jython library on the cp)
4) Enter the example data (see below)
5) It is a small Eclipse Kepler project, so if you prefer, you can load/debug/run it from Eclipse.

When I do this, I get:
E:\tmp\Jython\TestJython>TestJython.cmd
TestJython >>> 10L > 100
false
TestJython >>> a = 10L
None
TestJython >>> a > 100
true
TestJython >>> type(a)
class java.math.BigInteger
TestJython >>> exit

So, as I confirmed initially, the underlying layers seem to use the BigInteger class, causing the failure in comparison.
As far as I know, I am not doing anything specific that could cause this.
I just use Jython as a Python Scripting Engine according to JSR-223, which is a convenient way of using it.
(Take a look at the extremely simple src/TestJython.java)

Do you expect this behavior?
Can it be avoided?

Johan

------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
_______________________________________________
Jython-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jython-users


------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk

_______________________________________________
Jython-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jython-users



------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
_______________________________________________
Jython-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jython-users
Reply | Threaded
Open this post in threaded view
|

Re: Unintuitive comparison between long and BigInteger

Robby O'Connor

Doesn't BigInt have more precision?

--Rob
Sent from my cell, please excuse any typos.

On Oct 9, 2014 2:58 PM, "Curtis Rueden" <[hidden email]> wrote:
Hi Johan,

I'm new to the list, so apologies if I missed any prior discussion of this issue.

Johan Van Noten wrote:
> TestJython >>> a = 10L
> None
> TestJython >>> a > 100
> true
> TestJython >>> type(a)
> class java.math.BigInteger

Using your test code, I see the described behavior in both 2.5.3 and 2.7-b3.

However, the Fiji project [1] has support for Jython scripting [2], and within that framework (Jython 2.5.3) I do not see the bug. Instead I see:

>>> a = 10L
>>> print(type(a))
<type 'long'>

Santoso Wijaya wrote:
> >>> a = BigInteger('10')
> >>> type(a)
> <type 'java.math.BigInteger'>
> >>> a > 100
> True

Yeah, seems like a BigInteger comparison bug. But to me, the more surprising thing is that writing "a = 10L" in Jython creates a BigInteger rather than a Long...

Regards,
Curtis


On Thu, Oct 9, 2014 at 1:19 PM, Santoso Wijaya <[hidden email]> wrote:
More succinctly, this:

Jython 2.7b3+ (default:2c45f75a5406, Oct 7 2014, 17:21:51) 
[Java HotSpot(TM) 64-Bit Server VM (Oracle Corporation)] on java1.7.0_67
Type "help", "copyright", "credits" or "license" for more information.
>>> from java.math import BigInteger
>>> a = BigInteger('10')
>>> type(a)
<type 'java.math.BigInteger'>
>>> a > 100
True


~/santoso

On Thu, Oct 9, 2014 at 2:24 AM, Johan Van Noten <[hidden email]> wrote:
Hi Jeff,

This issue keeps bugging me... also in 2.7-b3.
So I decided to make a small Java application to demonstrate the issue.

Some easy steps:
1) Download archive from http://www.qtc.be/TestJython.zip
2) Extract
3) Run the script TestJython.cmd (just runs a small class with the jython library on the cp)
4) Enter the example data (see below)
5) It is a small Eclipse Kepler project, so if you prefer, you can load/debug/run it from Eclipse.

When I do this, I get:
E:\tmp\Jython\TestJython>TestJython.cmd
TestJython >>> 10L > 100
false
TestJython >>> a = 10L
None
TestJython >>> a > 100
true
TestJython >>> type(a)
class java.math.BigInteger
TestJython >>> exit

So, as I confirmed initially, the underlying layers seem to use the BigInteger class, causing the failure in comparison.
As far as I know, I am not doing anything specific that could cause this.
I just use Jython as a Python Scripting Engine according to JSR-223, which is a convenient way of using it.
(Take a look at the extremely simple src/TestJython.java)

Do you expect this behavior?
Can it be avoided?

Johan

------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
_______________________________________________
Jython-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jython-users


------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk

_______________________________________________
Jython-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jython-users



------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
_______________________________________________
Jython-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jython-users


------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
_______________________________________________
Jython-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jython-users
Reply | Threaded
Open this post in threaded view
|

Re: Unintuitive comparison between long and BigInteger

Curtis Rueden
In reply to this post by Curtis Rueden
Hi all,

> seems like a BigInteger comparison bug.

I take that back -- BigInteger only implements Comparable<BigInteger> so as Santoso points out, the comparison can't be done. I guess that Jython somehow emits "True" when Py.NotImplemented is returned? You can see the same thing if you write, say:

print "foo" > 1234567890

Regards,
Curtis

On Thu, Oct 9, 2014 at 1:56 PM, Curtis Rueden <[hidden email]> wrote:
Hi Johan,

I'm new to the list, so apologies if I missed any prior discussion of this issue.

Johan Van Noten wrote:
> TestJython >>> a = 10L
> None
> TestJython >>> a > 100
> true
> TestJython >>> type(a)
> class java.math.BigInteger

Using your test code, I see the described behavior in both 2.5.3 and 2.7-b3.

However, the Fiji project [1] has support for Jython scripting [2], and within that framework (Jython 2.5.3) I do not see the bug. Instead I see:

>>> a = 10L
>>> print(type(a))
<type 'long'>

Santoso Wijaya wrote:
> >>> a = BigInteger('10')
> >>> type(a)
> <type 'java.math.BigInteger'>
> >>> a > 100
> True

Yeah, seems like a BigInteger comparison bug. But to me, the more surprising thing is that writing "a = 10L" in Jython creates a BigInteger rather than a Long...

Regards,
Curtis


On Thu, Oct 9, 2014 at 1:19 PM, Santoso Wijaya <[hidden email]> wrote:
More succinctly, this:

Jython 2.7b3+ (default:2c45f75a5406, Oct 7 2014, 17:21:51) 
[Java HotSpot(TM) 64-Bit Server VM (Oracle Corporation)] on java1.7.0_67
Type "help", "copyright", "credits" or "license" for more information.
>>> from java.math import BigInteger
>>> a = BigInteger('10')
>>> type(a)
<type 'java.math.BigInteger'>
>>> a > 100
True


~/santoso

On Thu, Oct 9, 2014 at 2:24 AM, Johan Van Noten <[hidden email]> wrote:
Hi Jeff,

This issue keeps bugging me... also in 2.7-b3.
So I decided to make a small Java application to demonstrate the issue.

Some easy steps:
1) Download archive from http://www.qtc.be/TestJython.zip
2) Extract
3) Run the script TestJython.cmd (just runs a small class with the jython library on the cp)
4) Enter the example data (see below)
5) It is a small Eclipse Kepler project, so if you prefer, you can load/debug/run it from Eclipse.

When I do this, I get:
E:\tmp\Jython\TestJython>TestJython.cmd
TestJython >>> 10L > 100
false
TestJython >>> a = 10L
None
TestJython >>> a > 100
true
TestJython >>> type(a)
class java.math.BigInteger
TestJython >>> exit

So, as I confirmed initially, the underlying layers seem to use the BigInteger class, causing the failure in comparison.
As far as I know, I am not doing anything specific that could cause this.
I just use Jython as a Python Scripting Engine according to JSR-223, which is a convenient way of using it.
(Take a look at the extremely simple src/TestJython.java)

Do you expect this behavior?
Can it be avoided?

Johan

------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
_______________________________________________
Jython-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jython-users


------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk

_______________________________________________
Jython-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jython-users




------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
_______________________________________________
Jython-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jython-users
Reply | Threaded
Open this post in threaded view
|

Re: Unintuitive comparison between long and BigInteger

Jim Baker-2

Santoso, your earlier comments certainly make the problem clear!

So what we are seeing here is that Python 2.x supports a default comparison model for Python objects such that if a specific comparison is not defined, instead it’s only guaranteed to be stable for the duration of the process. In practice, this defaults in CPython 2.x to comparisons of the object address in memory; and in Jython to comparing by java.lang.System#identityHashCode.

This surprising default was fixed in Python 3.0, and was one of the big cleanups: https://docs.python.org/3.0/whatsnew/3.0.html#ordering-comparisons

Now this default is particularly unfortunate for Jython because users have the very reasonabl expectation that something like java.math.BigInteger or java.math.BigDecimal should ducktype just like int or Decimal. This could be readily done for these Java clases, we just haven’t yet implemented, hence the CheckCastException that Santoso mentioned, which gets converted to a Py.NotImplemented, which eventually through some additional complexity, generates a coercion cycle, which is broken by the use of IdentityHashCode.


-- 
- Jim
Jim Baker


On October 9, 2014 at 1:19:02 PM, Curtis Rueden ([hidden email]) wrote:

Hi all,

> seems like a BigInteger comparison bug.

I take that back -- BigInteger only implements Comparable<BigInteger> so as Santoso points out, the comparison can't be done. I guess that Jython somehow emits "True" when Py.NotImplemented is returned? You can see the same thing if you write, say:

print "foo" > 1234567890

Regards,
Curtis

On Thu, Oct 9, 2014 at 1:56 PM, Curtis Rueden <[hidden email]> wrote:
Hi Johan,

I'm new to the list, so apologies if I missed any prior discussion of this issue.

Johan Van Noten wrote:
> TestJython >>> a = 10L
> None
> TestJython >>> a > 100
> true
> TestJython >>> type(a)
> class java.math.BigInteger

Using your test code, I see the described behavior in both 2.5.3 and 2.7-b3.

However, the Fiji project [1] has support for Jython scripting [2], and within that framework (Jython 2.5.3) I do not see the bug. Instead I see:

>>> a = 10L
>>> print(type(a))
<type 'long'>

Santoso Wijaya wrote:
> >>> a = BigInteger('10')
> >>> type(a)
> <type 'java.math.BigInteger'>
> >>> a > 100
> True

Yeah, seems like a BigInteger comparison bug. But to me, the more surprising thing is that writing "a = 10L" in Jython creates a BigInteger rather than a Long...

Regards,
Curtis


On Thu, Oct 9, 2014 at 1:19 PM, Santoso Wijaya <[hidden email]> wrote:
More succinctly, this:

Jython 2.7b3+ (default:2c45f75a5406, Oct 7 2014, 17:21:51) 
[Java HotSpot(TM) 64-Bit Server VM (Oracle Corporation)] on java1.7.0_67
Type "help", "copyright", "credits" or "license" for more information.
>>> from java.math import BigInteger
>>> a = BigInteger('10')
>>> type(a)
<type 'java.math.BigInteger'>
>>> a > 100
True


~/santoso

On Thu, Oct 9, 2014 at 2:24 AM, Johan Van Noten <[hidden email]> wrote:
Hi Jeff,

This issue keeps bugging me... also in 2.7-b3.
So I decided to make a small Java application to demonstrate the issue.

Some easy steps:
1) Download archive from http://www.qtc.be/TestJython.zip
2) Extract
3) Run the script TestJython.cmd (just runs a small class with the jython library on the cp)
4) Enter the example data (see below)
5) It is a small Eclipse Kepler project, so if you prefer, you can load/debug/run it from Eclipse.

When I do this, I get:
E:\tmp\Jython\TestJython>TestJython.cmd
TestJython >>> 10L > 100
false
TestJython >>> a = 10L
None
TestJython >>> a > 100
true
TestJython >>> type(a)
class java.math.BigInteger
TestJython >>> exit

So, as I confirmed initially, the underlying layers seem to use the BigInteger class, causing the failure in comparison.
As far as I know, I am not doing anything specific that could cause this.
I just use Jython as a Python Scripting Engine according to JSR-223, which is a convenient way of using it.
(Take a look at the extremely simple src/TestJython.java)

Do you expect this behavior?
Can it be avoided?

Johan

------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
_______________________________________________
Jython-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jython-users


------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk

_______________________________________________
Jython-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jython-users



------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk_______________________________________________
Jython-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jython-users


------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
_______________________________________________
Jython-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jython-users
Reply | Threaded
Open this post in threaded view
|

Re: Unintuitive comparison between long and BigInteger

Johan Van Noten
In reply to this post by Curtis Rueden

Hi Curtis,

 

I fully agree with you.

 

My issue is _not_ that the comparison of a BigInteger with some PyInteger gives a strange result.

My issue is, like you correctly describe, that for some reason a=10L seems to be instantiated as a BigInteger instead of a well-behaving PyLong.

 

This behavior doesn’t seem to occur in the default Jython console. Same instructions, correct result.

As my simple example shows, this behavior does happen on Jython script evaluations through Java’s ScriptEngine interface.

 

So, the core of my question: can I avoid this “instantiate BigInteger instead of PyLong” behavior in some sense?

 

@Santoso: you are showing the injected method which effectively seems to cause the comparison difference.

I guess this is also what Jeff meant earlier when he said that the case would directly lead to an exception in the 3.0 version.

So, this could be considered rather as an inconvenience, easily avoided by not using BigIntegers  or manually working around it.

Unfortunately, I am not instantiating this BigInteger myself.

On the contrary, I would like to avoid that, but don’t know how to do this…

 

Thanks already for your feedback, guys.

 

Johan

 

Van: [hidden email] [mailto:[hidden email]] Namens Curtis Rueden
Verzonden: donderdag 9 oktober 2014 20:56
Aan: Santoso Wijaya
CC: Johan Van Noten; [hidden email]
Onderwerp: Re: [Jython-users] Unintuitive comparison between long and BigInteger

 

Hi Johan,

 

I'm new to the list, so apologies if I missed any prior discussion of this issue.

 

Johan Van Noten wrote:

> TestJython >>> a = 10L

> None

> TestJython >>> a > 100

> true

> TestJython >>> type(a)

> class java.math.BigInteger

 

Using your test code, I see the described behavior in both 2.5.3 and 2.7-b3.

 

However, the Fiji project [1] has support for Jython scripting [2], and within that framework (Jython 2.5.3) I do not see the bug. Instead I see:

 

>>> a = 10L

>>> print(type(a))

<type 'long'>

 

Santoso Wijaya wrote:

> >>> a = BigInteger('10')

> >>> type(a)

> <type 'java.math.BigInteger'>

> >>> a > 100

> True

 

Yeah, seems like a BigInteger comparison bug. But to me, the more surprising thing is that writing "a = 10L" in Jython creates a BigInteger rather than a Long...

 

Regards,

Curtis

 

 

On Thu, Oct 9, 2014 at 1:19 PM, Santoso Wijaya <[hidden email]> wrote:

More succinctly, this:

 

Jython 2.7b3+ (default:2c45f75a5406, Oct 7 2014, 17:21:51) 

[Java HotSpot(TM) 64-Bit Server VM (Oracle Corporation)] on java1.7.0_67

Type "help", "copyright", "credits" or "license" for more information.

>>> from java.math import BigInteger

>>> a = BigInteger('10')

>>> type(a)

<type 'java.math.BigInteger'>

>>> a > 100

True

 


~/santoso

 

On Thu, Oct 9, 2014 at 2:24 AM, Johan Van Noten <[hidden email]> wrote:

Hi Jeff,

This issue keeps bugging me... also in 2.7-b3.
So I decided to make a small Java application to demonstrate the issue.

Some easy steps:
1) Download archive from http://www.qtc.be/TestJython.zip
2) Extract
3) Run the script TestJython.cmd (just runs a small class with the jython library on the cp)
4) Enter the example data (see below)
5) It is a small Eclipse Kepler project, so if you prefer, you can load/debug/run it from Eclipse.

When I do this, I get:
E:\tmp\Jython\TestJython>TestJython.cmd
TestJython >>> 10L > 100
false
TestJython >>> a = 10L
None
TestJython >>> a > 100
true
TestJython >>> type(a)
class java.math.BigInteger
TestJython >>> exit

So, as I confirmed initially, the underlying layers seem to use the BigInteger class, causing the failure in comparison.
As far as I know, I am not doing anything specific that could cause this.
I just use Jython as a Python Scripting Engine according to JSR-223, which is a convenient way of using it.
(Take a look at the extremely simple src/TestJython.java)

Do you expect this behavior?
Can it be avoided?

Johan

------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk

_______________________________________________
Jython-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jython-users

 


------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk

_______________________________________________
Jython-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jython-users

 


------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
_______________________________________________
Jython-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jython-users
Reply | Threaded
Open this post in threaded view
|

Re: Unintuitive comparison between long and BigInteger

Curtis Rueden
Hi Johan,

> This behavior doesn’t seem to occur in the default Jython console.
> Same instructions, correct result. As my simple example shows, this
> behavior does happen on Jython script evaluations through Java’s
> ScriptEngine interface.

Yep, it seems specific to org.python.jsr223.PyScriptEngine.

The reason the Fiji project I mentioned does not have the issue, even though it uses Jython in a JSR-223 context as well, is because that project uses the SciJava scripting framework's implementation [1] which wraps Jython's JSR-223 code _except_ for the ScriptEngine (probably because it predates Jython's official JSR-223 code). Specifically, the SciJava script engine evaluates Jython code as follows:


I tried tracing through the execution of your minimal script in the debugger in Eclipse, but I couldn't ultimately see what was going on, since the code gets compiled to Java bytecode before execution.

So I'm not sure what causes the difference, but if you need JSR-223 support and want to avoid this bug, a simple workaround would be to use the SciJava scripting framework's engine instead.

Regards,
Curtis


On Thu, Oct 9, 2014 at 2:41 PM, Johan Van Noten <[hidden email]> wrote:

Hi Curtis,

 

I fully agree with you.

 

My issue is _not_ that the comparison of a BigInteger with some PyInteger gives a strange result.

My issue is, like you correctly describe, that for some reason a=10L seems to be instantiated as a BigInteger instead of a well-behaving PyLong.

 

This behavior doesn’t seem to occur in the default Jython console. Same instructions, correct result.

As my simple example shows, this behavior does happen on Jython script evaluations through Java’s ScriptEngine interface.

 

So, the core of my question: can I avoid this “instantiate BigInteger instead of PyLong” behavior in some sense?

 

@Santoso: you are showing the injected method which effectively seems to cause the comparison difference.

I guess this is also what Jeff meant earlier when he said that the case would directly lead to an exception in the 3.0 version.

So, this could be considered rather as an inconvenience, easily avoided by not using BigIntegers  or manually working around it.

Unfortunately, I am not instantiating this BigInteger myself.

On the contrary, I would like to avoid that, but don’t know how to do this…

 

Thanks already for your feedback, guys.

 

Johan

 

Van: [hidden email] [mailto:[hidden email]] Namens Curtis Rueden
Verzonden: donderdag 9 oktober 2014 20:56
Aan: Santoso Wijaya
CC: Johan Van Noten; [hidden email]
Onderwerp: Re: [Jython-users] Unintuitive comparison between long and BigInteger

 

Hi Johan,

 

I'm new to the list, so apologies if I missed any prior discussion of this issue.

 

Johan Van Noten wrote:

> TestJython >>> a = 10L

> None

> TestJython >>> a > 100

> true

> TestJython >>> type(a)

> class java.math.BigInteger

 

Using your test code, I see the described behavior in both 2.5.3 and 2.7-b3.

 

However, the Fiji project [1] has support for Jython scripting [2], and within that framework (Jython 2.5.3) I do not see the bug. Instead I see:

 

>>> a = 10L

>>> print(type(a))

<type 'long'>

 

Santoso Wijaya wrote:

> >>> a = BigInteger('10')

> >>> type(a)

> <type 'java.math.BigInteger'>

> >>> a > 100

> True

 

Yeah, seems like a BigInteger comparison bug. But to me, the more surprising thing is that writing "a = 10L" in Jython creates a BigInteger rather than a Long...

 

Regards,

Curtis

 

 

On Thu, Oct 9, 2014 at 1:19 PM, Santoso Wijaya <[hidden email]> wrote:

More succinctly, this:

 

Jython 2.7b3+ (default:2c45f75a5406, Oct 7 2014, 17:21:51) 

[Java HotSpot(TM) 64-Bit Server VM (Oracle Corporation)] on java1.7.0_67

Type "help", "copyright", "credits" or "license" for more information.

>>> from java.math import BigInteger

>>> a = BigInteger('10')

>>> type(a)

<type 'java.math.BigInteger'>

>>> a > 100

True

 


~/santoso

 

On Thu, Oct 9, 2014 at 2:24 AM, Johan Van Noten <[hidden email]> wrote:

Hi Jeff,

This issue keeps bugging me... also in 2.7-b3.
So I decided to make a small Java application to demonstrate the issue.

Some easy steps:
1) Download archive from http://www.qtc.be/TestJython.zip
2) Extract
3) Run the script TestJython.cmd (just runs a small class with the jython library on the cp)
4) Enter the example data (see below)
5) It is a small Eclipse Kepler project, so if you prefer, you can load/debug/run it from Eclipse.

When I do this, I get:
E:\tmp\Jython\TestJython>TestJython.cmd
TestJython >>> 10L > 100
false
TestJython >>> a = 10L
None
TestJython >>> a > 100
true
TestJython >>> type(a)
class java.math.BigInteger
TestJython >>> exit

So, as I confirmed initially, the underlying layers seem to use the BigInteger class, causing the failure in comparison.
As far as I know, I am not doing anything specific that could cause this.
I just use Jython as a Python Scripting Engine according to JSR-223, which is a convenient way of using it.
(Take a look at the extremely simple src/TestJython.java)

Do you expect this behavior?
Can it be avoided?

Johan

------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk

_______________________________________________
Jython-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jython-users

 


------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk

_______________________________________________
Jython-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jython-users

 



------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
_______________________________________________
Jython-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jython-users
Reply | Threaded
Open this post in threaded view
|

Re: Unintuitive comparison between long and BigInteger

Johan Van Noten

Hi Curtis,

 

Good suggestion.

Still doubting a bit whether I will be able to reach full compatibility with the JSR-223 since our app’s users can choose which engine they like (Jython, JS…)

The rest of the code shouldn’t be aware of the difference.

I will try to do so in the weekend.

 

I saw that Santoso already submitted Issue 2216 for the misbehaving comparison.

Would you consider the JSR-223 behavior as a bug as well?

I am not well-positioned to judge that myself.

In that case, I guess I should submit that part of the issue as a bug as well.

 

Thanks!

Johan


------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
_______________________________________________
Jython-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jython-users
Reply | Threaded
Open this post in threaded view
|

Re: Unintuitive comparison between long and BigInteger

Jim Baker-2
In reply to this post by Jim Baker-2
I did a little more digging: this specific code in PyObject has been more or less untouched since Jython 2.0 was under development:

changeset:   1028:256879e0a28c
user:        Finn Bock <[hidden email]>
date:        Sat Sep 30 15:29:19 2000 +0000
files:       org/python/core/PyObject.java org/python/core/ThreadState.java
description:
PyObject._cmp(): Prevent runaway recursion when comparing cyclic objects.
The algorithm used is taken from CPython20.

It was still under the old name of JPython until a subsequent commit:

changeset:   1258:9b032407b730
user:        Finn Bock <[hidden email]>
date:        Wed Dec 06 21:09:23 2000 +0000
files:       registry
description:
Renamed jpython -> jython.

One nice thing about the future Jython 3.x is throwing out this sort of complexity. The original idea - that sorting heterogeneous collections can be stable - is not nearly as nice as avoiding unexpected and unsurfaced problems, and Python 3 definitely did the right thing here.

- Jim

On Thu, Oct 9, 2014 at 1:20 PM, Jim Baker <[hidden email]> wrote:

Santoso, your earlier comments certainly make the problem clear!

So what we are seeing here is that Python 2.x supports a default comparison model for Python objects such that if a specific comparison is not defined, instead it’s only guaranteed to be stable for the duration of the process. In practice, this defaults in CPython 2.x to comparisons of the object address in memory; and in Jython to comparing by java.lang.System#identityHashCode.

This surprising default was fixed in Python 3.0, and was one of the big cleanups: https://docs.python.org/3.0/whatsnew/3.0.html#ordering-comparisons

Now this default is particularly unfortunate for Jython because users have the very reasonabl expectation that something like java.math.BigInteger or java.math.BigDecimal should ducktype just like int or Decimal. This could be readily done for these Java clases, we just haven’t yet implemented, hence the CheckCastException that Santoso mentioned, which gets converted to a Py.NotImplemented, which eventually through some additional complexity, generates a coercion cycle, which is broken by the use of IdentityHashCode.


-- 
- Jim
Jim Baker


On October 9, 2014 at 1:19:02 PM, Curtis Rueden ([hidden email]) wrote:

Hi all,

> seems like a BigInteger comparison bug.

I take that back -- BigInteger only implements Comparable<BigInteger> so as Santoso points out, the comparison can't be done. I guess that Jython somehow emits "True" when Py.NotImplemented is returned? You can see the same thing if you write, say:

print "foo" > 1234567890

Regards,
Curtis

On Thu, Oct 9, 2014 at 1:56 PM, Curtis Rueden <[hidden email]> wrote:
Hi Johan,

I'm new to the list, so apologies if I missed any prior discussion of this issue.

Johan Van Noten wrote:
> TestJython >>> a = 10L
> None
> TestJython >>> a > 100
> true
> TestJython >>> type(a)
> class java.math.BigInteger

Using your test code, I see the described behavior in both 2.5.3 and 2.7-b3.

However, the Fiji project [1] has support for Jython scripting [2], and within that framework (Jython 2.5.3) I do not see the bug. Instead I see:

>>> a = 10L
>>> print(type(a))
<type 'long'>

Santoso Wijaya wrote:
> >>> a = BigInteger('10')
> >>> type(a)
> <type 'java.math.BigInteger'>
> >>> a > 100
> True

Yeah, seems like a BigInteger comparison bug. But to me, the more surprising thing is that writing "a = 10L" in Jython creates a BigInteger rather than a Long...

Regards,
Curtis


On Thu, Oct 9, 2014 at 1:19 PM, Santoso Wijaya <[hidden email]> wrote:
More succinctly, this:

Jython 2.7b3+ (default:2c45f75a5406, Oct 7 2014, 17:21:51) 
[Java HotSpot(TM) 64-Bit Server VM (Oracle Corporation)] on java1.7.0_67
Type "help", "copyright", "credits" or "license" for more information.
>>> from java.math import BigInteger
>>> a = BigInteger('10')
>>> type(a)
<type 'java.math.BigInteger'>
>>> a > 100
True


~/santoso

On Thu, Oct 9, 2014 at 2:24 AM, Johan Van Noten <[hidden email]> wrote:
Hi Jeff,

This issue keeps bugging me... also in 2.7-b3.
So I decided to make a small Java application to demonstrate the issue.

Some easy steps:
1) Download archive from http://www.qtc.be/TestJython.zip
2) Extract
3) Run the script TestJython.cmd (just runs a small class with the jython library on the cp)
4) Enter the example data (see below)
5) It is a small Eclipse Kepler project, so if you prefer, you can load/debug/run it from Eclipse.

When I do this, I get:
E:\tmp\Jython\TestJython>TestJython.cmd
TestJython >>> 10L > 100
false
TestJython >>> a = 10L
None
TestJython >>> a > 100
true
TestJython >>> type(a)
class java.math.BigInteger
TestJython >>> exit

So, as I confirmed initially, the underlying layers seem to use the BigInteger class, causing the failure in comparison.
As far as I know, I am not doing anything specific that could cause this.
I just use Jython as a Python Scripting Engine according to JSR-223, which is a convenient way of using it.
(Take a look at the extremely simple src/TestJython.java)

Do you expect this behavior?
Can it be avoided?

Johan

------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
_______________________________________________
Jython-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jython-users


------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk

_______________________________________________
Jython-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jython-users



------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk_______________________________________________
Jython-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jython-users




--

------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
_______________________________________________
Jython-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jython-users
Reply | Threaded
Open this post in threaded view
|

Re: Unintuitive comparison between long and BigInteger

Curtis Rueden
In reply to this post by Curtis Rueden
Hi Johan,

> Would you consider the JSR-223 behavior as a bug as well?

I would definitely call it a bug, but I am no Jython expert!

Regards,
Curtis

On Thu, Oct 9, 2014 at 4:43 PM, Johan Van Noten <[hidden email]> wrote:

Hi Curtis,

 

Good suggestion.

Still doubting a bit whether I will be able to reach full compatibility with the JSR-223 since our app’s users can choose which engine they like (Jython, JS…)

The rest of the code shouldn’t be aware of the difference.

I will try to do so in the weekend.

 

I saw that Santoso already submitted Issue 2216 for the misbehaving comparison.

Would you consider the JSR-223 behavior as a bug as well?

I am not well-positioned to judge that myself.

In that case, I guess I should submit that part of the issue as a bug as well.

 

Thanks!

Johan

 

Van: [hidden email] [mailto:[hidden email]] Namens Curtis Rueden
Verzonden: donderdag 9 oktober 2014 22:24
Aan: Johan Van Noten
CC: Santoso Wijaya; [hidden email]


Onderwerp: Re: [Jython-users] Unintuitive comparison between long and BigInteger

 

Hi Johan,

 

> This behavior doesn’t seem to occur in the default Jython console.

> Same instructions, correct result. As my simple example shows, this

> behavior does happen on Jython script evaluations through Java’s

> ScriptEngine interface.

 

Yep, it seems specific to org.python.jsr223.PyScriptEngine.

 

The reason the Fiji project I mentioned does not have the issue, even though it uses Jython in a JSR-223 context as well, is because that project uses the SciJava scripting framework's implementation [1] which wraps Jython's JSR-223 code _except_ for the ScriptEngine (probably because it predates Jython's official JSR-223 code). Specifically, the SciJava script engine evaluates Jython code as follows:

 

 

I tried tracing through the execution of your minimal script in the debugger in Eclipse, but I couldn't ultimately see what was going on, since the code gets compiled to Java bytecode before execution.

 

So I'm not sure what causes the difference, but if you need JSR-223 support and want to avoid this bug, a simple workaround would be to use the SciJava scripting framework's engine instead.

 

Regards,

Curtis

 

 

On Thu, Oct 9, 2014 at 2:41 PM, Johan Van Noten <[hidden email]> wrote:

Hi Curtis,

 

I fully agree with you.

 

My issue is _not_ that the comparison of a BigInteger with some PyInteger gives a strange result.

My issue is, like you correctly describe, that for some reason a=10L seems to be instantiated as a BigInteger instead of a well-behaving PyLong.

 

This behavior doesn’t seem to occur in the default Jython console. Same instructions, correct result.

As my simple example shows, this behavior does happen on Jython script evaluations through Java’s ScriptEngine interface.

 

So, the core of my question: can I avoid this “instantiate BigInteger instead of PyLong” behavior in some sense?

 

@Santoso: you are showing the injected method which effectively seems to cause the comparison difference.

I guess this is also what Jeff meant earlier when he said that the case would directly lead to an exception in the 3.0 version.

So, this could be considered rather as an inconvenience, easily avoided by not using BigIntegers  or manually working around it.

Unfortunately, I am not instantiating this BigInteger myself.

On the contrary, I would like to avoid that, but don’t know how to do this…

 

Thanks already for your feedback, guys.

 

Johan

 

Van: [hidden email] [mailto:[hidden email]] Namens Curtis Rueden
Verzonden: donderdag 9 oktober 2014 20:56
Aan: Santoso Wijaya
CC: Johan Van Noten;
[hidden email]
Onderwerp: Re: [Jython-users] Unintuitive comparison between long and BigInteger

 

Hi Johan,

 

I'm new to the list, so apologies if I missed any prior discussion of this issue.

 

Johan Van Noten wrote:

> TestJython >>> a = 10L

> None

> TestJython >>> a > 100

> true

> TestJython >>> type(a)

> class java.math.BigInteger

 

Using your test code, I see the described behavior in both 2.5.3 and 2.7-b3.

 

However, the Fiji project [1] has support for Jython scripting [2], and within that framework (Jython 2.5.3) I do not see the bug. Instead I see:

 

>>> a = 10L

>>> print(type(a))

<type 'long'>

 

Santoso Wijaya wrote:

> >>> a = BigInteger('10')

> >>> type(a)

> <type 'java.math.BigInteger'>

> >>> a > 100

> True

 

Yeah, seems like a BigInteger comparison bug. But to me, the more surprising thing is that writing "a = 10L" in Jython creates a BigInteger rather than a Long...

 

Regards,

Curtis

 

 

On Thu, Oct 9, 2014 at 1:19 PM, Santoso Wijaya <[hidden email]> wrote:

More succinctly, this:

 

Jython 2.7b3+ (default:2c45f75a5406, Oct 7 2014, 17:21:51) 

[Java HotSpot(TM) 64-Bit Server VM (Oracle Corporation)] on java1.7.0_67

Type "help", "copyright", "credits" or "license" for more information.

>>> from java.math import BigInteger

>>> a = BigInteger('10')

>>> type(a)

<type 'java.math.BigInteger'>

>>> a > 100

True

 


~/santoso

 

On Thu, Oct 9, 2014 at 2:24 AM, Johan Van Noten <[hidden email]> wrote:

Hi Jeff,

This issue keeps bugging me... also in 2.7-b3.
So I decided to make a small Java application to demonstrate the issue.

Some easy steps:
1) Download archive from http://www.qtc.be/TestJython.zip
2) Extract
3) Run the script TestJython.cmd (just runs a small class with the jython library on the cp)
4) Enter the example data (see below)
5) It is a small Eclipse Kepler project, so if you prefer, you can load/debug/run it from Eclipse.

When I do this, I get:
E:\tmp\Jython\TestJython>TestJython.cmd
TestJython >>> 10L > 100
false
TestJython >>> a = 10L
None
TestJython >>> a > 100
true
TestJython >>> type(a)
class java.math.BigInteger
TestJython >>> exit

So, as I confirmed initially, the underlying layers seem to use the BigInteger class, causing the failure in comparison.
As far as I know, I am not doing anything specific that could cause this.
I just use Jython as a Python Scripting Engine according to JSR-223, which is a convenient way of using it.
(Take a look at the extremely simple src/TestJython.java)

Do you expect this behavior?
Can it be avoided?

Johan

------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk

_______________________________________________
Jython-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jython-users

 


------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk

_______________________________________________
Jython-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jython-users

 

 



------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
_______________________________________________
Jython-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jython-users
Reply | Threaded
Open this post in threaded view
|

Re: Unintuitive comparison between long and BigInteger

Jeff Allen-2
In reply to this post by Curtis Rueden
This is very odd. Using essentially Johan's code:

TEST >>> a = 13L
None
TEST >>> repr(type(a))
<type 'java.math.BigInteger'>
TEST >>> repr(type(10L))
<type 'long'>

This is not to be confused with:
TEST >>> type(10L)
class org.python.core.PyLong

That happens, rather than <type 'long'>, because the output implicitly calls toString() instead or repr(), which a real console would.

It seems that values assigned to variables are stripped of their Jython wrapping. I believe this happens here:
https://hg.python.org/jython/file/1e8dd809df28/src/org/python/jsr223/PyScriptEngineScope.java#l147

The call of __tojava__ looks deliberate, but why? Sorry, it's late in the UK.

Jeff Allen
On 09/10/2014 21:23, Curtis Rueden wrote:
Hi Johan,

> This behavior doesn’t seem to occur in the default Jython console.
> Same instructions, correct result. As my simple example shows, this
> behavior does happen on Jython script evaluations through Java’s
> ScriptEngine interface.

Yep, it seems specific to org.python.jsr223.PyScriptEngine.

The reason the Fiji project I mentioned does not have the issue, even though it uses Jython in a JSR-223 context as well, is because that project uses the SciJava scripting framework's implementation [1] which wraps Jython's JSR-223 code _except_ for the ScriptEngine (probably because it predates Jython's official JSR-223 code). Specifically, the SciJava script engine evaluates Jython code as follows:


I tried tracing through the execution of your minimal script in the debugger in Eclipse, but I couldn't ultimately see what was going on, since the code gets compiled to Java bytecode before execution.

So I'm not sure what causes the difference, but if you need JSR-223 support and want to avoid this bug, a simple workaround would be to use the SciJava scripting framework's engine instead.

Regards,
Curtis

<big snip>

On Thu, Oct 9, 2014 at 1:19 PM, Santoso Wijaya <[hidden email]> wrote:

More succinctly, this:

 

Jython 2.7b3+ (default:2c45f75a5406, Oct 7 2014, 17:21:51) 

[Java HotSpot(TM) 64-Bit Server VM (Oracle Corporation)] on java1.7.0_67

Type "help", "copyright", "credits" or "license" for more information.

>>> from java.math import BigInteger

>>> a = BigInteger('10')

>>> type(a)

<type 'java.math.BigInteger'>

>>> a > 100

True

 


~/santoso

 

On Thu, Oct 9, 2014 at 2:24 AM, Johan Van Noten <[hidden email]> wrote:

Hi Jeff,

This issue keeps bugging me... also in 2.7-b3.
So I decided to make a small Java application to demonstrate the issue.

Some easy steps:
1) Download archive from http://www.qtc.be/TestJython.zip
2) Extract
3) Run the script TestJython.cmd (just runs a small class with the jython library on the cp)
4) Enter the example data (see below)
5) It is a small Eclipse Kepler project, so if you prefer, you can load/debug/run it from Eclipse.

When I do this, I get:
E:\tmp\Jython\TestJython>TestJython.cmd
TestJython >>> 10L > 100
false
TestJython >>> a = 10L
None
TestJython >>> a > 100
true
TestJython >>> type(a)
class java.math.BigInteger
TestJython >>> exit

So, as I confirmed initially, the underlying layers seem to use the BigInteger class, causing the failure in comparison.
As far as I know, I am not doing anything specific that could cause this.
I just use Jython as a Python Scripting Engine according to JSR-223, which is a convenient way of using it.
(Take a look at the extremely simple src/TestJython.java)

Do you expect this behavior?
Can it be avoided?

Johan



------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
_______________________________________________
Jython-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jython-users
Reply | Threaded
Open this post in threaded view
|

Re: Unintuitive comparison between long and BigInteger

Jeff Allen-2
Johan:

I think this is now fixed under http://bugs.jython.org/issue2090, using the code contributed there. Thanks for helping us to understand it.

Santoso's observation is closely related, but not quite the same thing, because of differences in the way the JSR-223 and regular interpreters store and retrieve variables.
Jeff Allen
On 09/10/2014 23:44, Jeff Allen wrote:
This is very odd. Using essentially Johan's code:

TEST >>> a = 13L
None
TEST >>> repr(type(a))
<type 'java.math.BigInteger'>
TEST >>> repr(type(10L))
<type 'long'>

This is not to be confused with:
TEST >>> type(10L)
class org.python.core.PyLong

That happens, rather than <type 'long'>, because the output implicitly calls toString() instead or repr(), which a real console would.

It seems that values assigned to variables are stripped of their Jython wrapping. I believe this happens here:
https://hg.python.org/jython/file/1e8dd809df28/src/org/python/jsr223/PyScriptEngineScope.java#l147

The call of __tojava__ looks deliberate, but why? Sorry, it's late in the UK.

Jeff Allen
On 09/10/2014 21:23, Curtis Rueden wrote:
Hi Johan,

> This behavior doesn’t seem to occur in the default Jython console.
> Same instructions, correct result. As my simple example shows, this
> behavior does happen on Jython script evaluations through Java’s
> ScriptEngine interface.

Yep, it seems specific to org.python.jsr223.PyScriptEngine.

The reason the Fiji project I mentioned does not have the issue, even though it uses Jython in a JSR-223 context as well, is because that project uses the SciJava scripting framework's implementation [1] which wraps Jython's JSR-223 code _except_ for the ScriptEngine (probably because it predates Jython's official JSR-223 code). Specifically, the SciJava script engine evaluates Jython code as follows:


I tried tracing through the execution of your minimal script in the debugger in Eclipse, but I couldn't ultimately see what was going on, since the code gets compiled to Java bytecode before execution.

So I'm not sure what causes the difference, but if you need JSR-223 support and want to avoid this bug, a simple workaround would be to use the SciJava scripting framework's engine instead.

Regards,
Curtis

<big snip>

On Thu, Oct 9, 2014 at 1:19 PM, Santoso Wijaya <[hidden email]> wrote:

More succinctly, this:

 

Jython 2.7b3+ (default:2c45f75a5406, Oct 7 2014, 17:21:51) 

[Java HotSpot(TM) 64-Bit Server VM (Oracle Corporation)] on java1.7.0_67

Type "help", "copyright", "credits" or "license" for more information.

>>> from java.math import BigInteger

>>> a = BigInteger('10')

>>> type(a)

<type 'java.math.BigInteger'>

>>> a > 100

True

 


~/santoso

 

On Thu, Oct 9, 2014 at 2:24 AM, Johan Van Noten <[hidden email]> wrote:

Hi Jeff,

This issue keeps bugging me... also in 2.7-b3.
So I decided to make a small Java application to demonstrate the issue.

Some easy steps:
1) Download archive from http://www.qtc.be/TestJython.zip
2) Extract
3) Run the script TestJython.cmd (just runs a small class with the jython library on the cp)
4) Enter the example data (see below)
5) It is a small Eclipse Kepler project, so if you prefer, you can load/debug/run it from Eclipse.

When I do this, I get:
E:\tmp\Jython\TestJython>TestJython.cmd
TestJython >>> 10L > 100
false
TestJython >>> a = 10L
None
TestJython >>> a > 100
true
TestJython >>> type(a)
class java.math.BigInteger
TestJython >>> exit

So, as I confirmed initially, the underlying layers seem to use the BigInteger class, causing the failure in comparison.
As far as I know, I am not doing anything specific that could cause this.
I just use Jython as a Python Scripting Engine according to JSR-223, which is a convenient way of using it.
(Take a look at the extremely simple src/TestJython.java)

Do you expect this behavior?
Can it be avoided?

Johan




------------------------------------------------------------------------------
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://p.sf.net/sfu/Zoho
_______________________________________________
Jython-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jython-users
Reply | Threaded
Open this post in threaded view
|

Re: Unintuitive comparison between long and BigInteger

Johan Van Noten

Hi Jeff,

 

Glad I could help. Thanks for the quick solution!

 

I will verify the solution in the real target app once I get through another Jython 2.7 b3 issue (see separate post).

 

Regards,

Johan

 

Van: Jeff Allen [mailto:[hidden email]]
Verzonden: woensdag 15 oktober 2014 0:19
Aan: [hidden email]
Onderwerp: Re: [Jython-users] Unintuitive comparison between long and BigInteger

 

Johan:

I think this is now fixed under http://bugs.jython.org/issue2090, using the code contributed there. Thanks for helping us to understand it.

Santoso's observation is closely related, but not quite the same thing, because of differences in the way the JSR-223 and regular interpreters store and retrieve variables.

Jeff Allen

On 09/10/2014 23:44, Jeff Allen wrote:

This is very odd. Using essentially Johan's code:

TEST >>> a = 13L
None
TEST >>> repr(type(a))
<type 'java.math.BigInteger'>
TEST >>> repr(type(10L))
<type 'long'>

This is not to be confused with:
TEST >>> type(10L)
class org.python.core.PyLong

That happens, rather than <type 'long'>, because the output implicitly calls toString() instead or repr(), which a real console would.

It seems that values assigned to variables are stripped of their Jython wrapping. I believe this happens here:
https://hg.python.org/jython/file/1e8dd809df28/src/org/python/jsr223/PyScriptEngineScope.java#l147

The call of __tojava__ looks deliberate, but why? Sorry, it's late in the UK.

Jeff Allen

On 09/10/2014 21:23, Curtis Rueden wrote:

Hi Johan,

 

> This behavior doesn’t seem to occur in the default Jython console.

> Same instructions, correct result. As my simple example shows, this

> behavior does happen on Jython script evaluations through Java’s

> ScriptEngine interface.

 

Yep, it seems specific to org.python.jsr223.PyScriptEngine.

 

The reason the Fiji project I mentioned does not have the issue, even though it uses Jython in a JSR-223 context as well, is because that project uses the SciJava scripting framework's implementation [1] which wraps Jython's JSR-223 code _except_ for the ScriptEngine (probably because it predates Jython's official JSR-223 code). Specifically, the SciJava script engine evaluates Jython code as follows:

 

 

I tried tracing through the execution of your minimal script in the debugger in Eclipse, but I couldn't ultimately see what was going on, since the code gets compiled to Java bytecode before execution.

 

So I'm not sure what causes the difference, but if you need JSR-223 support and want to avoid this bug, a simple workaround would be to use the SciJava scripting framework's engine instead.

 

Regards,

Curtis


<big snip>

On Thu, Oct 9, 2014 at 1:19 PM, Santoso Wijaya <[hidden email]> wrote:

More succinctly, this:

 

Jython 2.7b3+ (default:2c45f75a5406, Oct 7 2014, 17:21:51) 

[Java HotSpot(TM) 64-Bit Server VM (Oracle Corporation)] on java1.7.0_67

Type "help", "copyright", "credits" or "license" for more information.

>>> from java.math import BigInteger

>>> a = BigInteger('10')

>>> type(a)

<type 'java.math.BigInteger'>

>>> a > 100

True

 


~/santoso

 

On Thu, Oct 9, 2014 at 2:24 AM, Johan Van Noten <[hidden email]> wrote:

Hi Jeff,

This issue keeps bugging me... also in 2.7-b3.
So I decided to make a small Java application to demonstrate the issue.

Some easy steps:
1) Download archive from http://www.qtc.be/TestJython.zip
2) Extract
3) Run the script TestJython.cmd (just runs a small class with the jython library on the cp)
4) Enter the example data (see below)
5) It is a small Eclipse Kepler project, so if you prefer, you can load/debug/run it from Eclipse.

When I do this, I get:
E:\tmp\Jython\TestJython>TestJython.cmd
TestJython >>> 10L > 100
false
TestJython >>> a = 10L
None
TestJython >>> a > 100
true
TestJython >>> type(a)
class java.math.BigInteger
TestJython >>> exit

So, as I confirmed initially, the underlying layers seem to use the BigInteger class, causing the failure in comparison.
As far as I know, I am not doing anything specific that could cause this.
I just use Jython as a Python Scripting Engine according to JSR-223, which is a convenient way of using it.
(Take a look at the extremely simple src/TestJython.java)

Do you expect this behavior?
Can it be avoided?

Johan

 

 


------------------------------------------------------------------------------
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://p.sf.net/sfu/Zoho
_______________________________________________
Jython-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jython-users
12