Stats

  • Replies 7
  • Subscribers 159
  • Views 21148
  • Members are here 0
More Content

Rounding of floating numbers

archive

I am comparing testpoint locations layout-to-fixture. Some Via testpoints are not on a 1 mil grid, and the round function in allegro seems to work differently than our manufacturer's fixture software round function. example; Allegro: round(145.47) - result 145 Fixture: 145.47 gets rounded to 146 If I know anything about rounding it seems that the fixture number is rounded correctly. How can I get allegro to round a number like the Fixture example?


Originally posted in cdnusers.org by Geoffm

  • Use ceiling. ceiling(145.47) -> 146


    Originally posted in cdnusers.org by Dave Elder

  • ...And no - Allegro does it correctly. rounding 145.47 mathematically should return 145. I suspect that the fixture is rounding twice - the first time to one decimal place = 145.5, this rounds to 146.


    Originally posted in cdnusers.org by Dave Elder

  • I Guess the following examples will be more clear for your usage.!!
    fix( n_arg ) => x_result
    The largest integer not greater than n_arg. If an integer is given as an argument, it returns the argument.
    fix(1.9) => 1
    fix(-5.6) => -6
    fix(100) => 100

    floor( n_number ) => x_integer
    Returns the largest integer not larger than the given argument.
    (floor -4.3) => -5
    (floor 3.5) => 3

    ceiling( n_number )
    Returns the smallest integer not smaller than the given argument.
    (ceiling -4.3) => -4
    (ceiling 3.5) => 4

    round( n_arg ) => x_result
    round(1.5) => 2
    round(-1.49) => -1
    round(1.49) => 1


    Originally posted in cdnusers.org by sagirameshraju

  • Take care with fix. fix(4.1 * 100) returns 409 - not 410 as you might expect. Cadence explanation: The real issue is that some numbers can't be represented exactly in the standard floating point representation. As IEEE floating point numbers represent real numbers by what are essentially binary fractions, what you might normally expect is not what you necessarily get. For example: the fraction 1/3 cannot be exactly represented in base ten fractions, but it can be in base 2. Conversley, 1/10 (0.1) cannot be exactly represented in base 2, although it can be in base 10. And that's what's happening here. 4.1 is not exact in IEEE floating point. It's a very well known phenomena, usually turns up in Computer Science 101, and is present in all computer languages. See http://www.lahey.com/float.htm for a nice write up in Fortran. So what can you do? One technique feels that works (but feels wrong) is to add a 'precision' factor to the result of the mulitplication. You do have to have a feel for what is reasonable for your calculation though. A smarter way is to know the strengths of the format. IEEE precision is greatest for numbers (excluding exponent) between 0 and 1.0. In this case if you adjust things to take account of that, you will find that fix(0.41 * 1000) 410.0


    Originally posted in cdnusers.org by Dave Elder

  • What's a Fortran?


    ;-)


    Originally posted in cdnusers.org by kerchunk
Cadence Guidelines

Community Guidelines

The Cadence Design Communities support Cadence users and technologists interacting to exchange ideas, news, technical information, and best practices to solve problems and get the most from Cadence technology. The community is open to everyone, and to provide the most value, we require participants to follow our Community Guidelines that facilitate a quality exchange of ideas and information. By accessing, contributing, using or downloading any materials from the site, you agree to be bound by the full Community Guidelines.