Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl-Sensitive Sunglasses
 
PerlMonks  

Re: (4) Dividing and format

by TheFluffyOne (Beadle)
on Nov 27, 2003 at 19:10 UTC ( [id://310582]=note: print w/replies, xml ) Need Help??


in reply to Re: Re: Re: Dividing and format
in thread Dividing and format

The reason this doesn't work is that you're doing the "+5" after the int statement. The purpose of the +5 (or +0.5) is to ensure that the int rounds down anything below x.5 and rounds up anything x.5 and above.

It's so that:

int(0.4 + 0.5) = int(0.9) and therefore 0.4 rounds down to 0.

int(0.5 + 0.5) = int(1.0) and therefore 0.5 rounds up to 1.

How I long for the good old days of MC68000 programming, where there was no such thing as floating point :)

Replies are listed 'Best First'.
Re: Re: (4) Dividing and format
by zengargoyle (Deacon) on Nov 27, 2003 at 23:27 UTC
    How I long for the good old days of MC68000 programming, where there was no such thing as floating point :)

    yes, those were the days. but by the MC68000 days there would generally be a floating point library for the user to use. now take it back to the original Apple's where there was only Integer Basic and floating point was a hardware and software upgrade... i can recall being so pissed at my dad for not getting the floating point card that had a switch on it so you could boot to Integer only if you wanted to. because the Star Trek game cassette would only work with Integer and wouldn't even load with Floating point and that was my most favorite game. sadly the precision of even the Floating point card wasn't enough for him to be able to use the computer for work, so he stuck to the HP calculator and the Apple became my plaything.

    about five years later i read a FORTH book by Brodie that had all i needed to know about getting floating point from integers by apropriate scaling. i wish i had known that so i could have kept the Integer machine to play Star Trek on.

      Cassettes? Luxury! Sorry, I'll resist the urge to start that sketch...

      I suppose we could go back to when even multiplication and division weren't on-chip, and all you had were add, sub, asl, lsr, rol, and ror. Well, OK, there were a few others, but them were t'days ;)

Re: Re: (4) Dividing and format
by Ninthwave (Chaplain) on Nov 27, 2003 at 22:39 UTC

    No I missed a step that is all. The idea is to seperate the integers from the floating points. I had a good think on the train and I am sure it is mixing floating points and the int statement in the maths that is causing it. So the steps are multiply by ten to the power of decimal places plus one. Take an integer of this to drop all deimcals and add 5. Divide this number by ten. Take the integer of this. Divide the result by 10 to the power of decimal places.

    Well the test code I tried using that idea and got this. Even more weird.

    So from that we modify the code so more.

    Now the error is in the divide by ten and not the int function. So no matter what happens int of 1265 is returning 1264. We have something in the number Change 12650 to 12652 and the output is

    Actual: 1.2652 1265.2 1265 1270 127 127 1.27
    So it is not int that is the problem it is perls use of numbers.

    The Perl Man Page says:
    Scalars aren't necessarily one thing or another. There's no place to declare a scalar variable to be of type "string", type "number", type "reference", or anything else. Because of the automatic conversion of scalars, operations that return scalars don't need to care (and in fact, cannot care) whether their caller is looking for a string, a number, or a reference.
    The int function.
    The question is are all numbers floating points and int just changes what is supplied as output? It seems that the number is a floating point as it is passed through out memory into different memory space, it characteristics come with it. That is why the my $val1 = int(($number * $exp) * 10); gives you 1264 in the first example and my $val2 = int($val1); yields the same. Even though in the second example $val1 is 1265. There has to be some floating point garbage floating around.
    Floating point math
    Native Numbers in Perl
    This is a good document. From that: . Forcing a numeric value to a particular format does not change the number stored in the value. So if any of the decimal values can not be stored as a binary fraction nothing using int will strip that value away and you get the repeating .999999 which when moving between int and float gives you the error.

    And there are modules to help, so the game of using maths to do this doesn't work without external help. So there is no bug outside of the limitation of computers as is, which I think we felt when doing this, but it is funny how this conversion under the hood can introduce errors in simple programming.

    Update:After reading Man on Modlib the integer will force integer maths instead of the standard double. So after alot of research and the obvious is now staring me in the face all maths in perl use double so you have to watch for binary fractions when you divide causing inmprecision. I am sure this was obvious to most some here but it was a revelation to me which means how good for me the original question was. I really like perlmonks this is such a better way to continue learning than just books and code.

    "No matter where you go, there you are." BB
      When you print (or otherwise stringize) a number, perl will slightly round it. Replace your print "$varn\n";'s with something like printf "%.20g\n", $varn; to see where floating point's inability to represent any decimal fraction is messing you up.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://310582]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others romping around the Monastery: (5)
As of 2024-03-28 16:38 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found