I still enjoy using Apple products and prefer them over alternatives, but in recent years, an increasing number of small bugs has made using them less pleasant. No single bug is fatal, but they add up. I wanted to document them to make it more likely that they will be fixed.
There are two main topics:
| import argparse | |
| import numpy as np | |
| from chainer import Variable, FunctionSet, optimizers, cuda | |
| import chainer.functions as F | |
| import cv2 | |
| import random | |
| import cPickle as pickle | |
| import sys | |
| class ConvolutionalAutoencoder(FunctionSet): |
Just a quickie test in Python 3 (using Requests) to see if Google Cloud Vision can be used to effectively OCR a scanned data table and preserve its structure, in the way that products such as ABBYY FineReader can OCR an image and provide Excel-ready output.
The short answer: No. While Cloud Vision provides bounding polygon coordinates in its output, it doesn't provide it at the word or region level, which would be needed to then calculate the data delimiters.
On the other hand, the OCR quality is pretty good, if you just need to identify text anywhere in an image, without regards to its physical coordinates. I've included two examples:
####### 1. A low-resolution photo of road signs
| worker_processes 1; | |
| user nginx; | |
| error_log /var/log/nginx/error.log warn; | |
| pid /var/run/nginx.pid; | |
| events { | |
| worker_connections 1024; # increase if you have lots of clients | |
| accept_mutex off; # set to 'on' if nginx worker_processes > 1 | |
| } |
This query is to find geolocation of an IP address including latitude, longitude, city and country.
Legacy SQL doesn't support range conditions such as BETWEEN when using JOIN, so we need to filter data by WHERE.
This means if IP address does not match any of the data inside geolite_city_bq_b2b, records will not be able to receive.
Use Standard SQL if you want to receive records no matter you succeed to find geolocation or not.
Please refer to the following post for more detail.
https://cloudplatform.googleblog.com/2014/03/geoip-geolocation-with-google-bigquery.html
| create table hex_r8 as ( | |
| with envelope as ( | |
| select st_envelope(wkb_geometry) geom from quartiers_sociologiques | |
| ), h3_id as ( | |
| select h3_polyfill(geom, 8) id from envelope | |
| ) | |
| select id, st_setsrid(h3_h3index_to_geoboundary(id), 4326) geom from h3_id | |
| ); |
| from ortools.sat.python import cp_model | |
| ''' course: https://www.coursera.org/learn/solving-algorithms-discrete-optimization#about | |
| About how cp works and intro to solver strategies''' | |
| def patchingThe9HeavensProblem(): #sudoku problem | |
| model = cp_model.CpModel() |
| # (Variant #4 for exercise 16.2 on EPI (Elements of Programming Interviews)) (September 2018 edition) | |
| # The core idea is calculate the levenshtein distance, while taking into account the special cases of the regex expression | |
| # *, +, ? and . were taken into account for the regex expression. Expression blocks are not supported | |
| # This algorithm uses recursion with memoization (could be transposed to a DP solution), yielding a O(mn) time complexity, O(mn) auxiliary space for cache and O(max(m,n)) function call stack | |
| # (m and n are the lengths of regex and target strings respectively) | |
| # | |
| # Version using dynamic programming: https://gist.github.com/lopespm/2362a77e7bd230a4622a43709c195826 | |
| def regex_dist(regex: str, target: str): | |
| def regex_dist_aux(r_i, t_i): |
