Skip to content
Home » Blog » Python for Network Engineers Blog 13: Scientific Notation

Python for Network Engineers Blog 13: Scientific Notation

main blog post image for the python Scientific Notation post showing different bandwidths in notation

Python Scientific Notation – Stop Calculating Planetary Distances

Right, so you’ve got variables and basic data types working haven’t you. Numbers, strings, booleans, that whole bit. Now we’re getting to something that catches loads of people out when they start working with real network data – python scientific notation.

Python for Network Engineers Blog 12: Python Type Conversion

Now here’s where most Python courses completely cock it up again. They’ll have you calculating the distance to Mars or working out how many atoms are in a grain of sand or figuring out the mass of the sun. I’m sitting there thinking, that’s lovely mate but I’ve got SNMP counters showing 9.87654321e+08 and latency measurements coming back as 1.5e-03. How’s calculating interplanetary distances going to help me understand what my network monitoring data actually means then?

Thing is, I made this exact mistake when I started. Couple of years back, was trying to write a script to analyse interface statistics from our core router. Had bandwidth utilisation coming in from SNMP as something like 9.87654321e+08 bits per second. Couldn’t work out what the hell that number actually meant. Spent ages trying to convert it manually with a calculator. Complete waste of time.

Few months later, needed to parse some network monitoring data that had response times in microseconds. Thought there’s got to be a better way than manually converting scientific notation every time.

Found someone who explained python scientific notation properly, this one actually used networking examples. Made much more sense straight away. Instead of calculating how many electrons are in a copper wire, I’m working with 1.5e-03 seconds for network latency and 1e+09 for gigabit speeds.

So anyway, let’s do python scientific notation properly using network stuff that matters.

What Python Scientific Notation Actually Is

Right so python scientific notation is just a way of writing very large or very small numbers without having to type loads of zeros everywhere. It’s basically shorthand for powers of ten. Instead of writing 1000000000, you write 1e+09. Instead of 0.000001, you write 1e-06.

Dead simple. Number followed by ‘e’ followed by the power of 10.

# Large numbers - typical in networking
bandwidth_bps = 1e+09        # 1 billion bits per second (1 Gbps)
packet_count = 5.2e+06       # 5.2 million packets
bytes_transferred = 3.7e+12  # 3.7 terabytes

# Small numbers - also common in networking
latency_seconds = 1.5e-03    # 1.5 milliseconds
jitter_seconds = 2.3e-06     # 2.3 microseconds
packet_loss = 4.5e-04        # 0.045% packet loss

print(f"Bandwidth: {bandwidth_bps} bps")
print(f"Latency: {latency_seconds} seconds") 
print(f"Packet loss: {packet_loss}")

See? Network measurements that actually matter. Not calculating how many photons are in a laser beam.

Now here’s something I didn’t know when I started. Python automatically switches to scientific notation when numbers get too big or too small to display sensibly. Got SNMP counters that have been running for months? They’ll probably show up in scientific notation without you doing anything.

Had this come up last month actually. Was pulling interface statistics from our core switch that had been up for 6 months. The byte counters were showing as 2.4e+12 automatically. Turns out that’s 2.4 terabytes of traffic. Much easier to read than 2400000000000.

Why This Matters for Network Engineers

Look, networking’s absolutely stuffed with massive numbers and tiny measurements, isn’t it? Bandwidth in bits per second that run into the billions. Byte counters that hit the trillions after a few months. Latency measurements in microseconds. Everything’s got extreme values attached.

Understanding python scientific notation properly means you can handle real network monitoring data without going mental. Makes your scripts much more readable when you’re dealing with SNMP counters or performance metrics.

# Real network monitoring data
interface_stats = {
    "input_bytes": 4.2e+11,     # 420 billion bytes in
    "output_bytes": 3.8e+11,    # 380 billion bytes out  
    "input_packets": 2.1e+08,   # 210 million packets in
    "error_rate": 1.2e-05       # 0.000012 error rate
}

# Calculate utilisation on 10 Gbps link
link_capacity = 1.25e+09  # 10 Gbps = 1.25 GB/s
utilisation = interface_stats["output_bytes"] / link_capacity
print(f"Link utilisation: {utilisation:.2f}%")

But here’s where people get confused. When does Python decide to show you scientific notation versus normal decimal format?

When Python Shows Scientific Notation Automatically

This catches people out constantly. When does Python decide to show numbers in scientific notation versus normal format?

Simple rule I use. If the number has more than about 16 significant digits or the decimal part has more than about 4 leading zeros, Python switches to scientific notation automatically. You don’t get to choose. Python decides what’s most readable.

# Python shows these normally
normal_numbers = [1000000, 0.0001, 123.456789]

# Python switches to scientific notation for these
scientific_numbers = [10000000000000000, 0.00000001, 1.23456789e+20]

for num in normal_numbers:
    print(f"Normal: {num}")
    
for num in scientific_numbers:
    print(f"Scientific: {num}")

There we go. You can see that Python decides based on the number size.

A screenshot-style image displaying Python terminal output. The output shows bandwidth and packet counts first in standard decimal form and then in python scientific notation, making it clear how Python formats each

Got caught out by this early on actually. Had a script that was calculating total bytes transferred across all interfaces on a chassis switch. Couldn’t work out why the output looked weird. Turns out Python was automatically switching to scientific notation because the total was over 10^16 bytes. Spent ages debugging before I realised it was just the display format. Proper embarrassing that was.

Reading Scientific Notation in Network Context

Right so here’s something that confused the hell out of me when I started. How do you actually work with numbers that are in scientific notation? What does all this e+09 and e-06 business actually mean?

When you see network data in scientific notation, you need to understand what it actually represents:

# SNMP data often comes back in scientific notation
snmp_data = {
    "ifInOctets": 3.2e+11,      # 320 billion bytes received
    "ifOutOctets": 2.8e+11,     # 280 billion bytes sent
    "ifInErrors": 1.5e+03,      # 1,500 input errors
    "sysUpTime": 2.5e+07        # 25 million centiseconds uptime
}

# Convert to human readable formats
bytes_in_gb = snmp_data["ifInOctets"] / 1e+09
uptime_days = snmp_data["sysUpTime"] / 100 / 86400  # centiseconds to days

print(f"Data received: {bytes_in_gb:.1f} GB")
print(f"System uptime: {uptime_days:.1f} days")

Brilliant. The key thing is remembering that ‘e+09’ means “multiply by 10 to the power of 9” and ‘e-06’ means “multiply by 10 to the power of minus 6”.

Sometimes you want to use python scientific notation in your own calculations. Especially when working with standard network values:

# Standard network values in scientific notation
gigabit_bps = 1e+09          # 1 billion bits per second
megabit_bps = 1e+06          # 1 million bits per second  
kilobit_bps = 1e+03          # 1 thousand bits per second

# Calculate bandwidth utilisation
current_usage = 750000000    # 750 Mbps current usage
utilisation_pct = (current_usage / gigabit_bps) * 100

print(f"Current utilisation: {utilisation_pct:.1f}%")

# Working with microsecond latency measurements
ping_times_us = [1.2e+03, 1.5e+03, 2.1e+03, 1.8e+03]  # microseconds
ping_times_ms = [time / 1e+03 for time in ping_times_us]  # convert to milliseconds

print(f"Ping times (ms): {ping_times_ms}")

Much cleaner than writing out 1000000000 every time you need a gigabit.

Common Python Scientific Notation Cock-ups

Let me tell you about cock-ups I see network engineers make when learning python scientific notation. Made most of these myself at some point.

Getting the sign wrong is a massive one:

# Wrong understanding
latency_seconds = 1.5e+03    # This is 1500 seconds (25 minutes!) 
bandwidth_mbps = 100e-06     # This is 0.0001 Mbps (basically nothing)

# Right way
latency_seconds = 1.5e-03    # This is 0.0015 seconds (1.5 ms)
bandwidth_mbps = 100e+06     # This is 100 million bps (100 Mbps)

The sign after the ‘e’ matters massively. Plus means make the number bigger. Minus means make it smaller.

Took me ages to figure this out the first time it happened. Had a latency monitoring script that was showing response times of several minutes instead of milliseconds. Couldn’t understand why our network appeared to be completely broken. Eventually realised I’d used e+03 instead of e-03 for the millisecond conversion. Don’t be like me. Check your signs.

Inline image showing a side-by-side comparison of incorrect and correct python scientific notation formats for network measurements, with annotations explaining each mistake

Mixing up units when converting bit me badly once:

# Wrong - mixing up bytes and bits
bandwidth_gbps = 10          # 10 Gbps
transfer_time = file_size_gb / bandwidth_gbps  # This is wrong!

# Right - convert to same units first  
bandwidth_gbps = 10
bandwidth_gbytes_per_sec = bandwidth_gbps / 8  # Convert bits to bytes
transfer_time = file_size_gb / bandwidth_gbytes_per_sec

print(f"Transfer time: {transfer_time:.2f} seconds")

Always check your units when working with scientific notation. Bits versus bytes. Seconds versus milliseconds. That sort of thing.

Not understanding automatic formatting catches people out constantly:

# Python automatically formats large numbers
total_bytes = 0
for interface in ["Gi0/1", "Gi0/2", "Gi0/3"]:
    total_bytes += 4.2e+11  # Add interface counter

print(f"Total bytes: {total_bytes}")  # Shows: 1.26e+12

# If you want normal formatting, force it
print(f"Total bytes: {total_bytes:,.0f}")  # Shows: 1,260,000,000,000

Python decides the display format based on the number size. If you want specific formatting, you need to tell it explicitly.

Actually Useful Applications

Once you get python scientific notation sorted, loads of networking tasks become much easier. Let me show you some practical applications.

When you’re doing capacity planning, you’re often working with projections that involve very large numbers:

# Current monthly data transfer
current_monthly_gb = 15000  # 15 TB per month

# Project growth over 5 years at 20% annual increase
growth_rate = 1.20
years = 5
projected_monthly = current_monthly_gb * (growth_rate ** years)

# Convert to scientific notation for readability
projected_bytes = projected_monthly * 1e+09  # GB to bytes
print(f"Projected monthly transfer: {projected_bytes:.2e} bytes")
print(f"That's {projected_monthly:.0f} GB per month")

# Calculate required bandwidth (assuming 30% utilisation target)
required_mbps = (projected_bytes * 8) / (30 * 24 * 3600) / 0.3
print(f"Required bandwidth: {required_mbps:.0f} Mbps")

Scientific notation makes these calculations much more readable than dealing with strings of zeros.

When you’re analysing performance data, you often get measurements in scientific notation from monitoring tools:

# Latency measurements from network monitoring (in seconds)
latency_samples = [
    1.2e-03, 1.5e-03, 2.1e-03, 1.8e-03, 3.2e-03,
    1.1e-03, 1.9e-03, 2.5e-03, 1.6e-03, 2.0e-03
]

# Calculate statistics
avg_latency = sum(latency_samples) / len(latency_samples)
max_latency = max(latency_samples)
min_latency = min(latency_samples)

# Convert to milliseconds for reporting
avg_ms = avg_latency * 1e+03
max_ms = max_latency * 1e+03  
min_ms = min_latency * 1e+03

print(f"Average latency: {avg_ms:.1f} ms")
print(f"Maximum latency: {max_ms:.1f} ms") 
print(f"Minimum latency: {min_ms:.1f} ms")

# Check if any samples exceed SLA threshold
sla_threshold = 5e-03  # 5 milliseconds
violations = [sample for sample in latency_samples if sample > sla_threshold]
print(f"SLA violations: {len(violations)}")

Much easier to work with 1.5e-03 than 0.0015 when you’re doing lots of calculations.

SNMP counters often return values in scientific notation. Especially for high-traffic interfaces:

# Simulated SNMP counter data from our switches
snmp_counters = {
    "SW1-ACCESS": {
        "ifInOctets": 2.3e+11,    # 230 GB total input
        "ifOutOctets": 1.8e+11,   # 180 GB total output
        "ifInUcastPkts": 1.5e+08, # 150 million unicast packets
        "ifInErrors": 2.1e+03     # 2,100 input errors
    },
    "SW2-ACCESS": {
        "ifInOctets": 3.1e+11,
        "ifOutOctets": 2.9e+11, 
        "ifInUcastPkts": 2.1e+08,
        "ifInErrors": 1.2e+03
    }
}

# Calculate error rates
for switch, counters in snmp_counters.items():
    error_rate = counters["ifInErrors"] / counters["ifInUcastPkts"]
    error_pct = error_rate * 100
    
    # Convert bytes to GB for reporting
    total_gb = (counters["ifInOctets"] + counters["ifOutOctets"]) / 1e+09
    
    print(f"{switch}:")
    print(f"  Total traffic: {total_gb:.1f} GB")
    print(f"  Error rate: {error_pct:.4f}%")

Great stuff. Scientific notation makes it much easier to handle the massive counter values you get from busy network interfaces.

Real Network Examples

Let me show you actual scenarios where python scientific notation matters.

When you’re processing monitoring data from network devices:

# Simulated monitoring data over 24 hours from R1-EDGE-RTR
monitoring_data = [
    {"timestamp": "00:00", "bytes_in": 2.3e+08, "bytes_out": 1.8e+08},
    {"timestamp": "01:00", "bytes_in": 1.9e+08, "bytes_out": 1.5e+08}, 
    {"timestamp": "02:00", "bytes_in": 1.2e+08, "bytes_out": 9.8e+07},
    {"timestamp": "03:00", "bytes_in": 8.7e+07, "bytes_out": 7.2e+07}
]

# Calculate hourly usage in Mbps
for data in monitoring_data:
    # Convert bytes to bits, then to Mbps (divided by 3600 seconds)
    input_mbps = (data["bytes_in"] * 8) / 3600 / 1e+06
    output_mbps = (data["bytes_out"] * 8) / 3600 / 1e+06
    
    print(f"{data['timestamp']}: In {input_mbps:.1f} Mbps, Out {output_mbps:.1f} Mbps")

# Calculate 24-hour totals
total_bytes_in = sum(data["bytes_in"] for data in monitoring_data)
total_bytes_out = sum(data["bytes_out"] for data in monitoring_data)

print(f"24-hour totals: {total_bytes_in:.2e} bytes in, {total_bytes_out:.2e} bytes out")

Brilliant. Scientific notation makes it much easier to work with the large byte counts you get from network monitoring.

When you’re planning network capacity upgrades:

# Current network utilisation data
current_data = {
    "peak_monthly_gb": 2.5e+03,     # 2.5 TB peak month
    "growth_rate_annual": 0.25,      # 25% annual growth
    "current_link_gbps": 1e+00       # 1 Gbps current link
}

# Project requirements for next 3 years
years_ahead = 3
projected_monthly = current_data["peak_monthly_gb"] * (1 + current_data["growth_rate_annual"]) ** years_ahead

# Convert to required bandwidth (assume 30% utilisation target)
monthly_seconds = 30 * 24 * 3600
projected_bits = projected_monthly * 8 * 1e+09  # GB to bits
required_bps = projected_bits / monthly_seconds / 0.3

# Express in terms of standard link speeds
required_gbps = required_bps / 1e+09

print(f"Current peak: {current_data['peak_monthly_gb']:.1e} GB/month")
print(f"Projected peak: {projected_monthly:.1e} GB/month") 
print(f"Required bandwidth: {required_gbps:.1f} Gbps")

if required_gbps > 10:
    print("Recommendation: Upgrade to 10+ Gbps link")
elif required_gbps > 1:
    print("Recommendation: Upgrade to 10 Gbps link")
else:
    print("Current 1 Gbps link sufficient")

Fantastic. Scientific notation makes these projections much more manageable to calculate and understand.

Advanced Scientific Notation Concepts

Now here’s something that catches people out when they start doing more complex network calculations.

When you’re working with network counters that reset periodically:

# 64-bit counter approaching maximum value
max_64bit = 2**64 - 1  # Maximum unsigned 64-bit integer
current_counter = 1.8e+19  # Getting close to maximum

print(f"Maximum 64-bit value: {max_64bit:.2e}")
print(f"Current counter: {current_counter:.2e}")

# Calculate remaining capacity
remaining = max_64bit - current_counter
remaining_gb = remaining / 1e+09

print(f"Remaining capacity: {remaining_gb:.0f} GB before counter reset")

# Predict when counter will reset based on current rate
bytes_per_second = 1.2e+08  # 120 MB/s transfer rate
seconds_to_reset = remaining / bytes_per_second
hours_to_reset = seconds_to_reset / 3600

print(f"Counter will reset in approximately {hours_to_reset:.1f} hours")

Understanding how scientific notation handles very large numbers helps with counter wraparound calculations.

Inline image showing a graph of an SNMP counter increasing over time, approaching the 64-bit maximum value, with Y-axis and data point labels in python scientific notation

Had this come up recently actually. Was monitoring an uplink that had been running flat out for months. SNMP counters were showing values like 1.8e+19. Getting close to the 64-bit maximum. Using scientific notation made it much easier to calculate when the counter would wrap around and reset to zero.

When you’re modelling network growth or calculating compound effects:

# Network traffic growth modelling
initial_traffic_gbps = 1.5e+00  # 1.5 Gbps current
monthly_growth_rate = 1.05       # 5% monthly growth

# Calculate traffic growth over 24 months
months = 24
projected_traffic = initial_traffic_gbps * (monthly_growth_rate ** months)

print(f"Initial traffic: {initial_traffic_gbps:.1f} Gbps")
print(f"Projected traffic: {projected_traffic:.2e} Gbps")
print(f"That's {projected_traffic:.1f} Gbps after {months} months")

# Determine when traffic will exceed link capacity
link_capacity_gbps = 1e+01  # 10 Gbps link
month = 0
current_traffic = initial_traffic_gbps

while current_traffic < link_capacity_gbps:
    month += 1
    current_traffic = initial_traffic_gbps * (monthly_growth_rate ** month)

print(f"Link capacity exceeded in month {month}")
print(f"Traffic will be {current_traffic:.1f} Gbps")

Alright. Scientific notation makes exponential calculations much easier to follow.

PCEP Requirements for Scientific Notation

The PCEP exam covers specific aspects of python scientific notation that you need to understand properly.

You need to know how to write scientific notation literals in your code:

# Valid scientific notation literals
valid_formats = [
    1e5,        # 100000.0
    1.5e+3,     # 1500.0  
    2.3e-4,     # 0.00023
    1E+6,       # 1000000.0 (uppercase E works too)
    .5e3,       # 500.0 (leading decimal point)
    5.e2        # 500.0 (trailing decimal point)
]

for value in valid_formats:
    print(f"{value}")

All these formats are valid Python scientific notation.

Scientific notation always creates float types. Even if the number could be an integer:

# These all create float types
scientific_numbers = [1e3, 2e+0, 3e-0]

for num in scientific_numbers:
    print(f"Value: {num}, Type: {type(num)}")

# Converting to integers when needed for network config
network_values = {
    "vlan_id": int(1e2),        # 100
    "port_count": int(4.8e1),   # 48  
    "subnet_size": int(2.56e2)  # 256
}

print(network_values)

Understanding type conversion is important for network configuration scripts where you need integer values.

Scientific notation numbers behave exactly like regular floats in calculations:

# Mixed operations with scientific notation
gigabit = 1e+09
current_usage = 750000000

# All these calculations work normally
utilisation = current_usage / gigabit
percentage = utilisation * 100
overhead = gigabit * 0.1
available = gigabit - current_usage - overhead

print(f"Utilisation: {percentage:.1f}%")
print(f"Available bandwidth: {available:.0f} bps")

You can mix scientific notation with regular numbers in any mathematical operation.

Why This All Actually Matters

Look, understanding python scientific notation properly is fundamental to everything else you’ll do with network data analysis. Without it, you’ll struggle with SNMP counters. Performance metrics. Capacity planning calculations.

Get python scientific notation wrong and you’ll spend ages converting between different number formats manually. Misreading monitoring data. Creating scripts that fail when they encounter large counter values. Get it right and you can handle any network measurement Python throws at you.

The key thing is using python scientific notation for actual network measurements and calculations. Bandwidth utilisation. Latency analysis. Capacity planning. Performance monitoring. Not calculating astronomical distances or molecular weights that you’ll never use.

Understanding scientific notation means your network automation scripts can handle real-world data scales properly. From microsecond timing measurements to terabyte transfer volumes. Makes you much more effective at analysing and automating network operations.

That’s python scientific notation sorted properly. You understand how to read it. Write it. Use it for network engineering calculations. Much better than generic examples that teach you nothing useful for actual networking work.


External Link: IEEE 754 Floating Point Standard – technical specification for floating point arithmetic used in scientific notation

1 thought on “Python for Network Engineers Blog 13: Scientific Notation”

  1. Pingback: Python for Network Engineers Blog 14: Arithmetic Operators - RichardKilleen

Leave a Reply

Your email address will not be published. Required fields are marked *