gruevy has quit ["ERC Version 5.0.1 $Revision: 1.726.2.3 $ (IRC client for Emacs)"]
cjohnson has quit [Connection timed out]
cjohnson has joined #ocaml
jacobian has quit ["Client exiting"]
cjohnson has quit [Read error: 104 (Connection reset by peer)]
gim_ has joined #ocaml
gim has quit [Read error: 110 (Connection timed out)]
tautologico has quit []
cmeme has quit [Remote closed the connection]
cmeme has joined #ocaml
cmeme has quit [Remote closed the connection]
gim__ has joined #ocaml
cmeme has joined #ocaml
gim_ has quit [Read error: 60 (Operation timed out)]
Greylensman has quit ["Leaving"]
Sonarman has quit ["leaving"]
solarwind has joined #ocaml
humasect has quit [Read error: 54 (Connection reset by peer)]
humasect has joined #ocaml
mlh has quit [Read error: 110 (Connection timed out)]
mattam has joined #ocaml
vezenchio has joined #ocaml
pango__ has quit ["back to work :("]
zzorn has joined #ocaml
zzorn is now known as zzorn_away
smimou has joined #ocaml
__DL__ has joined #ocaml
Msandin has joined #ocaml
Herrchen has joined #ocaml
solarwin1 has joined #ocaml
solarwin1 has quit [Client Quit]
mattam has quit [Remote closed the connection]
mattam has joined #ocaml
solarwind has quit [Read error: 110 (Connection timed out)]
shawn_ has joined #ocaml
Msandin has quit [Read error: 110 (Connection timed out)]
shawn has quit [Read error: 110 (Connection timed out)]
tsume has quit [Read error: 104 (Connection reset by peer)]
tsume has joined #ocaml
Msandin has joined #ocaml
wrunt has joined #ocaml
ejt has joined #ocaml
_fab has quit [Read error: 60 (Operation timed out)]
_JusSx_ has joined #ocaml
_JusSx_ has quit [Client Quit]
_JusSx_ has joined #ocaml
gim__ has quit [Read error: 110 (Connection timed out)]
gim_ has joined #ocaml
_fab has joined #ocaml
ejt has quit [Read error: 110 (Connection timed out)]
<nlv11757_>
i have a question; if I do a Int64.to_int on a 64bit system...do i lose precision?
<vincenz>
even on a 32 bit system
<vincenz>
you don't lose precision
<vincenz>
but the range is limited
<nlv11757_>
i'd expect if you do Int64.to_int(Int64.max_int) on a 32bit system...you would endup not with 2^63 - 1
<vincenz>
no
<vincenz>
and not on a 64 bit system
<vincenz>
and not for Int32
<nlv11757_>
im not following you
<vincenz>
cause all data has a header
<vincenz>
ona a 32 bit system
<vincenz>
Int32.to_int(Int32.max+int) != 2^31-!
<nlv11757_>
ok so what do you endup with....
<nlv11757_>
undetermined?
<nlv11757_>
hardware dependent?
<j_n>
i thought the int size was fixed at 31 bits
<mflux>
hmm.. my .cmo-files take 176k in total, yet the resulting binary is 724k. is it possible to create smaller binaries?
<mflux>
I wonder if that has ocamlrun integrated
<mflux>
but even that takes only 100k
solarwind has joined #ocaml
Herrchen has quit ["bye"]
Msandin has quit [Read error: 60 (Operation timed out)]
<nlv11757_>
but what i meant was....by doing a Int64.to_int on a 32 bit machine, you are losing something like 31 bits right?
Msandin has joined #ocaml
<vincenz>
ints are 31 bits and signed
<vincenz>
so max_int = 2^30-1
<vincenz>
nlv11757_: yes
<vincenz>
nlv11757_: if you don't get qn exception....
<nlv11757_>
ah ok, i just want to make sure i dont lose precision without warning.
<nlv11757_>
im going to do a to_string instead
<vincenz>
it's not precision!!!
<vincenz>
stop saying precision
<vincenz>
let's say your max_int is 12 and you have 16....so you get some other number or an exception... maybe it's modulo and you get 4...that's not at all 16, that's wrong
<vincenz>
precision is when for instance you have 1.111 but can only have 2 digets after the comma
<vincenz>
so you lose some precision 1.11
<vincenz>
as you're not as near to the number
<vincenz>
the term 'precision' does not exist for ints
zzorn_away has quit [Connection timed out]
<Msandin>
Tywith now supports function types and types in other modules, woho:)
<nlv11757_>
ok, so you dont lose precision, you simply lose the integer you had in mind
<nlv11757_>
i apologize for misuing precision lol
<nlv11757_>
you do lose precision actually :P because you arent as close to the original integer as you were
<vincenz>
it's arbitrary
<vincenz>
5 meters is not an approximaation for 15 meters
<vincenz>
5 meters IS an approximation of 5.5
<vincenz>
one with less precision
<nlv11757_>
you could argue that 1 is a very bad approximation of 10
<Msandin>
heh, arbitary ~= extremly unstable
<nlv11757_>
:P
<Msandin>
It would in any case be hair splitting and severe abuse of terminology:-)
<nlv11757_>
no doubt :P
<Smerdyakov>
There are floating point calulations that should yield 12 but give you 16 instead, and we certainly say that that is a loss of precision.
Skal has joined #ocaml
<Msandin>
Well, unstable float functions can yield 10e10 where 1 one the correct answer, eg completly nonsense:)
<Smerdyakov>
Yup! So we are disagreeing soundly with vincenz. :)
<Msandin>
Well, I don't:-P
<Smerdyakov>
You do, but you are in denial about it.
<Smerdyakov>
Uh oh. I found a spelling error on your web site. You have 10 seconds to correct it before the consequences.
<Msandin>
Nah, it's all bout terminology anyhow regardless of technicalities:)
<Msandin>
Agh, what???
<Smerdyakov>
"dependant"!!
<vincenz>
Smerdyakov: you like getting on my nerves don't you :)
<Smerdyakov>
I give up. I found two more on the next page I looked at.
<vincenz>
Smerdyakov: the topic was that int_capping...that's not precision loss
<Smerdyakov>
<vincenz> the term 'precision' does not exist for ints
<vincenz>
right
<vincenz>
ints as they exist in the type 'int'
<vincenz>
you're not removing bottom digits but top digits
<vincenz>
that's not precision loss
<Msandin>
what web page, where, whose?
<Smerdyakov>
But you can cast to float, do calculations, and cast back, and now you are talking about ints.