Log of the #nice channel on irc.freenode.net

* arjanb leaves02:44
* arjanb joins10:57
* GummiEnte joins14:26
Hello
<arjanb>hi14:27
<GummiEnte>Have you seen my mail to nice-info?
<arjanb>yes
<GummiEnte>And is it at your host the same error?14:28
<arjanb>you mean a new mail of today?
the lists are slow in forwarding the last time14:29
<GummiEnte>yes. it seems so, as if the sf-mail srvers are slow since a few days.
yes
Then, let me repeat my mail here (its short):14:30
JAVA
package test3;
class DoubleTest {
static void println(double d) {
System.out.println("OUT: "+d);
}
}
package test3;
void main(String[] args) {
System.out.println(-2.1);
System.out.println((-2.1).doubleValue());
DoubleTest.println(-2.1);
}
The result is not what I was suspecting:
-2.1
-2.0999999046325684
OUT: -2.0999999046325684
Funny, isn't it?14:31
<arjanb>but this isn't strange14:32
<GummiEnte>what I'm doing wrong?
<arjanb>nothing
these thing happen all the time when you work with double's or float's14:33
<GummiEnte>mom14:34
Well, but if I call the following Java function from NICE, it works:14:36
static void test()
{
System.out.println("JAVA--");
System.out.println(-2.1);
DoubleTest.println(-2.1);
System.out.println("--JAVA");
}
JAVA--14:37
-2.1
OUT: -2.1
--JAVA
but if i write the -2.1 in a nice sourcefile, the following (wrong to my opinion) comes out:14:38
OUT: -2.0999999046325684
<arjanb>yes but everywhere some conversion happens with double then you get lose of precision
you could try -2.1d14:40
<GummiEnte>also OUT: -2.099999904632568414:41
<arjanb>i see but why is that little difference important to you14:42
<GummiEnte>DoubleTest.println(-2.1); has to do conversion? DoubleTest.println(double arg) accepts a double?!
* bonniot joins14:43
<GummiEnte>Well, I need the exact result.
<bonniot>hi
<arjanb>that is how exact double are
hi
<GummiEnte>Hello Daniel
hmmm, up to now (with only java classes) I've never encountered such a problem.14:44
<bonniot>which problem?
what do you mean "with only java classes" ?14:45
<GummiEnte>If you've got a minute, please see the log. @ Daniel
"with only java" I mean, that pure java does the double handling correclty, but as soon as the (negative only?) doubles run through nice bytecode the doubles get an "incorrect" result.14:46
<bonniot>could you make two programs, one in pure java, and the other in pure nice, that behave differently?14:49
<GummiEnte>Well, please wait a moment.
<bonniot>i think it has to do with conversions from float to double, and/or from numbers to strings14:50
as arjan says, floats and double are not always able to store exact values
but nice should do the same as java14:51
it will be useful to look at the bytecode
<GummiEnte>Ok, I've got an xample:14:52
public static void main(String[] args)
{
double d = -2.1 + 1;
System.out.println(d);
}
That's already all.
<bonniot>and the same in Java?
<GummiEnte>Yes.
(actually it was the Java :) in nice I haven't used the public )14:53
once the result is -1.1 (java) and nice it is -1.099999904632568414:54
<arjanb>i get -1.0999999 from nice code14:55
<bonniot>we should be able to fix this14:56
the bytecode uses 2.099999905 instead of 2.1
but you should know that doubles are not always exact, because of rounding in base 2
arjan, do you want to look at this?14:57
<GummiEnte>They are always rounded?
<bonniot>for instance, try this is Java:
public static void main(String[] args)
{
double d = -2.3 + 1;
System.out.println(d);
}
it prints -1.299999999999999814:58
in Java
it would be the same in C
<GummiEnte>Ok, I see.14:59
<bonniot>but we will improve the behaviour in Nice
arjan?
<arjanb>i will look at this
<GummiEnte>I've up to now never encountered that problem.
<arjanb>daniel what value you have in bytecode15:00
<bonniot>Method name:"main" public static Signature: 22=(java.lang.String[])void
Attribute "Code", length:77, max_stack:5, max_locals:3, code_length:21
0: ldc #7=<Float 2.099999905>
2: fneg
...
<GummiEnte>Just for information. I'm heavily using native-crosscompile from gnu-linux to mingw32 and its working fine.
<arjanb>fneg is the problem i think
<bonniot>GummiEnte: great :-)15:01
<arjanb>we should store negative literals
<bonniot>arjanb: the problem is the constant, which is 2.099999905 instead of 2.1
<arjanb>my constant seems correct or my disassembler does something wrong15:02
<bonniot>it's true that handling negative literals could be an improvement too, but i don't think it is the problem here
you have 2.1 in the bytecode?
<GummiEnte>Method public static main (java/lang/String []) -> void15:03
0ldc #7 <Float 2.100000> 66 66 6 40
2fneg
3fconst_1
4fadd
5f2d
6dstore_1
<arjanb>yes
<GummiEnte>7getstatic #13 <Field java/lang/System.out Ljava/io/PrintStream;>
10dload_1
11invokevirtual #19 <Method java/io/PrintStream.println (D)V>
14return
that was what I've got.
<bonniot>yes, i get different results with javap and jcf-dump
which one do you use?15:04
it seems we found a bug in at least one disassembler
<GummiEnte>I'm using the same one arjan is using (he gave me the links: dis...)
<arjanb>javap and dis give both 2.1 at me
daniel what's your hex value?15:06
<bonniot>Float 2.099999905, bits = 0x4006666615:07
<arjanb>so that's the same
<bonniot>can javap give the constant pool?15:08
<arjanb>so what's the hex value of the java generated 2.1 constant
i don't think so but i don't use javap usually15:09
<GummiEnte>ldc2_w #16 <Double -1.10000000000000008882> 9a 99 99 99 99 99 f1 bf15:10
<arjanb>the hex value of 2.1
<GummiEnte>Thats the line from the java dis output...
it is already calculated?
and this is for 2.1: 15:11
ldc2_w #12 <Double -2.10000000000000008882> cd cc cc cc cc cc 0 c0
<bonniot>in Java, the literal 2.1 is of type double
<arjanb>i see a problem nice stores the literal in float and java in a double15:12
contantexp.java line 25415:14
<bonniot>it's a design decision to be made
both choices are possible
but I think it could be better to use doubles by default, as it will give better results in general15:15
and it is less surprising when the result is stored in a double
i'll have to go soon
it would be good to start by writing some testcases15:16
i think they should go in regtest/coreJava
<GummiEnte>I'll have to go soon, too.
<bonniot>ok, thanks for the report
i'll submit a bug for jcf-dump15:17
<GummiEnte>No problem.15:18
btw. remind my offer for nice support... It would be my a pleasure to give something back...15:19
<bonniot>like a server, or what?15:20
<GummiEnte>Yes, at least an account ...
<bonniot>ok, thanks
i have to go....15:21
* bonniot leaves
<GummiEnte>Me too...
Cu @ arjan
quit
* GummiEnte leaves
* bonniot joins17:56
have you made progress with the floating values issues?18:00
<arjanb>no i'm cooking at the moment18:11
* arjan_b joins18:54
i have looked at java lang spec and floating literals without a postfix are always double18:56
* arjanb leaves19:02
<bonniot>i would think it is a good idea19:05
<arjanb>how to handle the case where a literal is assigned to something of type float?19:17
<bonniot>it is a type error, like in Java19:18
you can use the f modifier, of the float(...) method
<arjanb>ok then the fix will be easy :-)19:19
<bonniot>i'll comit a change that checks for incorrect calls to protected java methods20:06
that should be enough to close the bug report that tries to clone a String20:07
<arjanb>i commited the change for floating literals20:15
the mailinglists are annoying slow now22:12
and you have a is not bug bugreport to close22:21
i still can't
the links on the download page are outdated http://nice.sourceforge.net/install.html23:01

Generated by Sualtam